Cyclopedia Square

I started out trying to write an eloquent essay on the merits of different ways of sharing new ideas and information in order to further the art of digital design verification (in other words, how to market this stuff), but I couldn't make it sound right. Instead, let me just point to some recent examples: Good examples Namespaces, Build Order, and Chickens Cadence's UVM video series These are brief and to-the-point. If you have a question, they quickly give you answer. If you are taking 2 or 3 minutes to browse the internet while waiting for a simulation to finish, maybe even on your phone while you take a little time away from your desk, you can get all the info in that time. Perfect. Examples of Ideas That Could be Marketed Better Monitoring signals by name, for the UVM register package and more and: A 30 Minute Project Makeover Using Continuous Integration First of all, kudos to Verilab for sharing ideas, knowledge, and source code as much they do. The...

This whole virtualenv thing is pretty cool, but it has always seemed too specific to Python for me. Let me see if I can explain. At first I had no use for virtualenv whatsoever, I could just sudo apt-get install python-whatever and get what I needed. As my distro got older and I didn't want to update my whole system, I started using virtualenv and pip to install and manage python packages instead of apt. It's great, except that the postgresql packages that came with my distro were getting crusty too. Because postgresql is not a python package, I get no help from virtualenv. Does anyone else have this problem? How do you deal with it? This reminds me of a very old problem from the chip design (EDA, ASIC design, whatever you want to call it) world. To design chips you buy licenses for expensive simulators and synthesis tools, and those tools are constantly being revved, fixing old bugs, introducing new features, and unfortunately, introducing new bugs. Because of that...

Mercurial 2.2.1 is out, and, among other new features and improvements, the commit command now has a --amend option. Git has had this for a while. Before 2.2 you could get the same functionality in Mercurial by using the mq extension, but it took at least 3 commands (qimport, qrefresh, qfinish). It's nice that you can do it with just one command now. Mercurial's relatively new phases come into play with --amend in that, by default, they will prevent you from amending a commit that has been pushed to or pulled from a remote repository. It's a nice little safety net to have, and of course you can override that behavior if you need. It's nice to see this incredibly capable and easy-to-use tool get even better.

In my last post I pondered (ranted?) on the reluctance of Mercurial people to edit repository history, especially as compared to git people. Today I noticed that Mercurial 2.1 has been released, and it has a new feature that makes editing your local repository much safer, phases (more detail here ). To me this looks like a really cool idea. Phases explicitly mark changesets as either public (have been pushed or pulled, and should not be edited) or draft (still local to your repository and can be freely edited). Changesets are given a phase automatically behind the scenes (though you can override this, of course), and history editing tools respect phases so that now it is even harder to shoot yourself in the foot when editing your repository history with tools like rebase or mq. There is also one more phase, secret, that can be enabled for use with patches in your Mercurial Queues. Secret changesets will not be pushed, pulled, or cloned (or even show up in the output of incomi...

I just installed the very latest version of mercurial, 2.0.2 . It added a new little feature that warns you when you create a branch. Huh? This is what it looks like: $ hg branch foo marked working directory as branch foo (branches are permanent and global, did you want a bookmark?) Really? Have we let the git advocates push us this far? Do we really need to start discouraging named branches? I googled around to see if I could find where the self-hate for mercurial's named branches is coming from and I found things like this , "it is almost never a good idea to use this facility for short-term branching, since branches created this way are inherently 'eternal'." (those quotes around eternal are good, actually, but you didn't explain why they should be there), and this , "you can never really delete branches (since that would mean altering older commits)." (editing history, oh noes!), and others like this. And these were all written by a...

Running emacs -nw in Terminal.app on my Mac has been pretty frustrating, until today. To fix the experience, download and install KeyRemap4MacBook (I sure hope it's not malware). Click on "Change Key." Scroll down until you find "For Applications." Expand that to "Enable at only Terminal" and select "Change Command_L to Option_l." Expand "Change Slash(/) Key" and select "Control+Slash(/) to Control+Underscore(_)." You might also want to select "Switch next and prev tab in terminal with shift and arrows (like Gnome term)." All better.

A co-worker who is annoyed with the verbosity of our verilog simulations just asked me if I subscribed to the Dark Cockpit Theory. I immediately replied, "no." I've had this argument a number of times with other engineers and I have already decided that more information is better than less. I had to google "dark cockpit theory" later because I'd never heard of it referred to that. For me it has always been the UNIX "Rule of Silence" . Same idea, I think. Just to be clear, I do like the Rule of Silence when it's software that I trust isn't going to do weird things or silently hang. There isn't a lot of code that I trust that much, though, and if it's software I don't trust, I want to know what it's doing, or at least that it's doing something . As I thought about this more, it's the same with people. When a person you trust is doing something for you, they can go do it without giving you any intermediat...