The rules of the courtroom in this case are simply common sense. It seems you can't understand that and would futile to try to explain.

You have notified the AAC world several times, twice recently, that I am on your ignore list. Please keep that promise and ignore me.

You and your side kick don't seem to understand the meaning of rude. Is telling a new member they are on your ignore because of a minor misunderstanding list being polite?

Do we have a short fuse tonight?

 

@jpanhalt---we seem to have gotten off on the wrong foot, for reasons I don't understand. It feels like you formed an impression of me and my goals, and are arguing against that impression. In the spirit of "Remember the human"---a reminder which this website shows me every time I make a post---can I ask you to consider that this impression might be mistaken?

I also looked up the "revised" version on GitHub. One needs to register with Microsoft, which owns GitHub, to access content. That's not going to happen with me.

With respect, that's not accurate. Anyone can clone the repository (i.e., download all the contents and run the scripts) without registering for github at all. (Seriously: I could give you a command you could run from your terminal, which would download the full contents and all git history: no account required! I'm not going to post that command now, because I don't want to be misunderstood as "linking to an external site".)

It is true that one would need a github account in order to contribute directly (i.e., via pull requests). It hadn't occurred to me before that some people might not want to do that---fair enough. But github hosting isn't a necessary property of my contributions.

See, git is a distributed source control system. That means everyone who clones the repo has a full copy of everything, including all history, and every copy is just as good as every other. No copy is more "authoritative" than any other, unless people decide it is by convention.

That means that github isn't anything like a permanent home for the project; it's just one more place that has a copy of it. If we want to host it on a different place (bitbucket, gitlab, anything else), it's trivial to move it. Git is so ubiquitous in the modern world, I'm sure we can find a place to host the repo that respects the maintainers' cultural values.

Moreover that added restriction on redistribution can be viewed as a violation of the Creative Commons license. Without paying that "price," one cannot determine whether other aspects such as authorship and attribution are retained.

I'm sorry, but I don't understand---what added restriction on redistribution? I never intended to add any restrictions on redistribution, and as far as I'm aware, I haven't added any.

It seems pellucidly obvious to me why AAC's ownership does not want the content there with reformatted images. So far as I can see, "chogg" has made no substantive contributions to the work. He/she just wants to distribute it under their identity,.

With respect, you're imputing motivations to me that I do not now have, and have never had. From the beginning, my goal has been to offer these structural improvements to the maintainers, in the same way that so many others have offered their content improvements. I didn't know how to contact the maintainers directly (still don't, in fact!), so I made a forum post. If they thought the changes were a good idea, my next step was going to be to suggest they create a github organization for the allaboutcircuits website, so we could move the "official" home there. I certainly never wanted my github account to be the "primary" home; that would be just weird and confusing.

I have made no "substantive" contributions to the textbooks because my skills are not in electronics. I came here to learn electronics from the textbooks! I wanted to make e-book versions so I could have them on my e-reader. I did achieve a proof of concept e-book version, but I felt that the structure of the files and make rules was too messy and brittle for me to try making "production quality" make rules for it. So, I decided to use the skills I do bring to the table to clean up, simplify, and refactor the structure. Then I decided I'd better see if the changes are acceptable before undertaking the e-book rules.

That's the conversation I'm still waiting to have.

 

I would like to see the bullet point list of the major changes chogg made, along with a brief explanation of why he thinks each one is an improvement. However, if AAC prefers that we don't continue this discussion on the AAC forms, it would be easy to move the discussion into an issue on the new GitHub project website chogg created for the book.

Thanks very much for the kind words! I may end up putting together the bullet point improvement list at some point, even if I don't hear anything more. Not tonight, though---I've already stayed up too late responding as it is.

 

I do have one minor side interest in this discussion - not for the textbook, but for a collection of useful and illustrative LTspice simulations produced my myself and other contributors like @crutschow , @Bordodynov , @ericgibbs , and many others. This site apparently is not interested in hosting such a collection but a Github repository might be just the ticket.

 

I do have one minor side interest in this discussion - not for the textbook, but for a collection of useful and illustrative LTspice simulations produced my myself and other contributors like @crutschow , @Bordodynov , @ericgibbs , and many others. This site apparently is not interested in hosting such a collection but a Github repository might be just the ticket.

Hola PB
One of the others is member @Danko

 

Hola PB
One of the others is member @Danko

Thanks, I know the list is a long one and it was not my purpose to recognize all of the many contributions, nor to slight them by omission.

 

I do have one minor side interest in this discussion - not for the textbook, but for a collection of useful and illustrative LTspice simulations produced my myself and other contributors like @crutschow , @Bordodynov , @ericgibbs , and many others. This site apparently is not interested in hosting such a collection but a Github repository might be just the ticket.

I would be willing to help set up and manage a GitHub repository for these LTspice simulator files. Over the past 6 months I have been modifying a fork I made of the Falstad circuit simulator to make it better fit the unconventional way I teach electrical and electronics classes. I think I could learn quite a bit from these LTspice files that would improve the simulator I am working on.

 

I would be willing to help set up and manage a GitHub repository for these LTspice simulator files. Over the past 6 months I have been modifying a fork I made of the Falstad circuit simulator to make it better fit the unconventional way I teach electrical and electronics classes. I think I could learn quite a bit from these LTspice files that would improve the simulator I am working on.

How would it be organized for browsing and searching?
Rather than hijacking this thread, maybe we should continue here:
https://forum.allaboutcircuits.com/threads/ltspice-examples.169795/

 

Here's my attempt to explain the major structural changes I'm proposing to make.

Maintainers: I expect you'll have lots of questions! Please feel free to ask away, in this venue or any other you choose. I think right now, we're just trying to figure out, "are these changes (or some subset of them) worth pursuing". If yes, then we can work together to figure out the logistical issues for how we get from here to there.


Summary of changes

Migrate to git

This is the Big One. Bringing the content into version control unlocks so many other improvements!

Really, using any version control would be a huge leap forward in maintainability and "collaborability". But git, in particular, is the best of the bunch. It's an open source, widely used, incredibly battle-tested and ubiquitous solution. And since it's so ubiquitous, it also gives you the widest base of potential collaborators.

(Some technical details on the choices I made. Standard best practices dictates to include source files in version control, and exclude generated files; I have done so here. Also, git has historically struggled with binary files, but there is now a standard solution, "git-lfs" (for Large File System); this is what I have used, and it makes the image files "feel like" all the other files.)

In 2020, using some form of version control is table stakes for any project that desires collaborators. Or really, for any project that changes over time. I don't know whether you'll end up accepting my version, but in any case I urge you to take the plunge and use version control---you'll be glad you did!

Clean up the Makefile rules

A fundamental principle of software engineering is "Don't Repeat Yourself" (DRY). Unfortunately, the Makefile rules repeated themselves liberally. Adding a new section, or changing the way something is generated, would have meant remembering to update each file in half a dozen different places.

The new version leverages the powerful pattern matching capabilities that are the fundamental strength of the make language. Adding or rearranging sections, or changing something about the output format, should now be as simple as changing a single location. This let us bring down the file sizes from ~700 lines down to ~100!

Separate output from source files

In the zip file version, when you generate output, it goes right into the same folder as the source files, mixing them together and making an awful mess.

I've redirected the output to a separate folder (which gets created automatically if it's missing). If you get into a funky state and you want to clean it up, or just want to force a full rebuild, it's as simple as "rm -Rf output/".

I've taken pains to preserve both the single-book workflow, and the full-suite workflow. The base output folder has a subfolder for each book. The source folder for each book has a symlink directly to its output folder. You can generate output for individual books, or do all of them at once. You can even go back and forth, in either order, without messing anything up.

• This, along with the move to git, brings another benefit. We no longer need to maintain (7 x 2) separate zip files, because nobody ever needs to download the zip of, e.g., "only the AC book". If someone wants to work on the contents, they simply clone the repo, and they have the source for all the books. Working with just one is as simple as staying in that book's subfolder. See the commit message for 3dc30a75771a3f4eb117b1fd278a188710160b58 in the repo for more details.

Oh, and note that git ignores all of the output folders. So, the outputs you generate won't make your repo "dirty" (i.e., git won't get confused and think they're new changes you want to commit).

Clean up and reorganize the non-source files (images, templates, etc.)

The zip files' structure is really hard to work with. Each folder has hundreds of files, mostly images with ID numbers. One has to hunt to find the content.

My restructuring makes separate subfolders for figures and templates. Now, when we open a book folder (like AC), the content itself is what stands out! Most of what we see are the .sml files. There are a few scripts, and the Makefile is easy to spot. Figures and templates are easy to find in their well-named subfolders. And, there's a symlink to the output folder. Nice and clean!

Clean up files that don't make sense with version control.

The zip files have lots of manually-dated backup copies (with names like, e.g., "index.htm.01182006"). There were also slightly different copies of each of the scripts floating around in the different directories for each book.

I unified all the scripts in the base directory to the latest common version, and replaced the copies with symlinks in each of the subfolders. I also deleted all the manual backup files, since they do in an imperfect and error-prone way what git naturally excels at. (Again, they're not really "gone": you can always check out an old commit and get them back if you really want to!)

Focus support on major outputs.

I think we do much better to focus on the outputs that significantly many people actually care about. Thus, I dropped support for plain-TeX, groff, txt... everything but PDF and HTML.

This is another significant benefit of using version control: it gives us the freedom to delete and clean up without worrying whether we "might need something later". It's all still there, forever!

Doing this unblocked me from switching the latex generation directly to use pdflatex, instead of depending on the antiquated workflow via .dvi intermediates. (A workflow which, I admit, brings me some nostalgia to recall.) The practical benefit of pdflatex (besides turning a multi-stage process into a single step, removing opportunities for errors) is that it lets us eliminate the .eps figure conversions, which in my experience were one of the fussiest and most error prone pieces of the pipeline.

Testing

To test out my changes, I generated both PDF and HTML output, and compared to the publicly hosted versions. I didn't exhaustively compare every single page, but I noticed that the same page number for a PDF had the same exact content every time I did check. This gave me confidence, because a discrepancy early on would throw all the later pages out of whack.

 

How would it be organized for browsing and searching?
Rather than hijacking this thread, maybe we should continue here:
https://forum.allaboutcircuits.com/threads/ltspice-examples.169795/

A GitHub project would mostly be used to provide version control for all of the LTspice file code along with collaboration features such as bug tracking, feature requests, task management, and a wiki.

User friendly browsing and searching of this data may be able to be provided by the GitHub "Pages" site that is associated with each project or it can be provided by a separate website. Either way I would be able to create such a website if people are interested in one.

For example, I currently have a searchable database of around 375 formulas that are commonly used in electrical fundamentals and electronics courses. This enables my students to locate formulas much quicker than flipping through the textbook when solving problems. I would probably write something similar to this software to search a database that contains the LTspice code.

If you would like to move this discussion to the "ltspice-examples" thread that would be okay with me.

 

we seem to have gotten off on the wrong foot, for reasons I don't understand....

Just wanted to say, this is the best online conflict de-escalation I think I've ever seen. If everyone spoke with your skill and patience, most of us would go crazy from the inability to have a good cathartic argument every now and then.

 

A GitHub project would mostly be used to provide version control for all of the LTspice file code along with collaboration features such as bug tracking, feature requests, task management, and a wiki.

User friendly browsing and searching of this data may be able to be provided by the GitHub "Pages" site that is associated with each project or it can be provided by a separate website. Either way I would be able to create such a website if people are interested in one.

For example, I currently have a searchable database of around 375 formulas that are commonly used in electrical fundamentals and electronics courses. This enables my students to locate formulas much quicker than flipping through the textbook when solving problems. I would probably write something similar to this software to search a database that contains the LTspice code.

If you would like to move this discussion to the "ltspice-examples" thread that would be okay with me.

I think that would be a good idea