This new tool needs to…

• Work cross-platform.
• Not do anything but exactly what I tell it. Namely, it shouldn’t attempt to build venvs or try to make everything appear like a test when most project automation isn’t a test; or at least have a way to turn all that off.
• Support passing options.
• Support running commands in an easy way.
• Ideally not require learning anything new.
• Ideally support reuse by allowing tasks to mark other tasks as dependencies, or at least call out tasks in a recursive manner.

There are a bunch of tools that are typically recommended for project automation:

• just
• tox
• nox
• invoke
• make (as in Makefiles)
• doit

There are a number of issues with these tools however that cause them to not meet the requirements.

make is not cross-platform, there’s no native support on Windows without a POSIX environment like msys2. Next make simply runs shell commands, so whatever you do write is tied to the shell environment and shell language features. This makes even cross-platform support even between Unixes like MacOS and Linux difficult, as the shells and common tools like grep have different features. just has the same issues, as does invoke.

make and just also don’t necessarily respect ordering requirements. In the below make example, c needs b to run then a, but b depends on a so a must run first. make silent ignores the conflict and runs a first. Perfectly fine for a build system, but not necessarily for a task system where side effects mean the order matters.

a:
    @echo "a"

b: a
    @echo "b"

c: b a
    @echo "c"

make and just also have the downside of being bespoke languages for scripting the tasks themselves. And tox is declarative and is simply not capable of being a very flexible project automation tool without leaning on the shell or Python scripts. why should I ever have to learn what the following line means?

 print-%: ; @echo $*=$($*)

Python is fine, which is what makes nox, invoke and doit the standouts. They are distributed via pip which runs everywhere; are implemented in Python which runs everywhere; the tasks are described in Python which runs everywhere; and Python is an incredibly capable language. Being implemented in Python and writing tasks in Python is a goodness.

tox and nox are Python-focused and run every “environment” in its own virtual environment. This is what is currently getting in the way in cocotb and coconext. I need automation to be able to run in the current global environment and not isolated ones to maintain flexibility. The venv isolation can be great for things like isolated dev tests for CI and isolation package builds, but I’d rather develop out of a single persistent development environment.

I haven’t complained about doit yet. It’s task are generators which yield bespoke dicts for describing dependencies without any typing support, so it just feels weird and kinda bad. Otherwise, its technically good. I’m allowed to make decisions based on aesthetics!

nox can call out other sessions in a recursive way, and you can pass options; but it does not support declarative and de-duplicated dependencies like Makefiles. invoke does support this, but task arguments must be bound when declaring the dependency relationship rather than just joining the argument namespace like Makefiles do conceptually by hvaing all options be globals.

Of all the options, nox, invoke, and doit are the closest to the mark, but all have at least one issue…

So I’ll make my own.

Dexter

I started dexter (name subject to change) to fill these needs.

It will…

• Be implemented in Python
• Be distributed via PyPI
• Tasks will be written in Python
• Tasks will be able to list out other Tasks as dependencies
• Task Flows will be checked to ensure a serialization order is possible where all ordering constraints are satisfied, or fail
• All Tasks in a Flow will share arguments
• Tasks will be easy to write, using decorated functions much like nox or invoke
• Tasks will have access to special “session” object to contain session-wide environment variables, and simplified run functions like nox or invoke
• Tasks will run commands with execve, not shell scripts

It will reach a minimal viable product in a couple weeks. It’s housed here. Feel free to suggest names in a Github issue.

The premise: You aren’t cool or better because you have an “internal monologue.” In fact, you are probably worse for it.

So what is this “internal monologue?” It’s that voice you hear in your head. No, not the one reading this out to you. It’s your own voice reflecting upon things as they are happening and conveying them back to you in prose. It’s your brain narrativizing your experience as it happens.

This is not a good thing. Self-narrativization is self-harm. Narrativization of reality is always unethical. It’s a violence against the plural of experience towards a singular. That singular is always shaped by valuation. Since we cannot escape value standards imposed by our society, we are destroying our experiences, selves, and others to match up with the standard of narrative of the society.

It’s very strange that I see therapists and some in the mental health advocacy realm recommend this practice. In fact, they frame journaling as a ritual in narrativization. “Making sense of the world around you and yourself” is how they frame it.

So we should do this to make the world make sense? So we can self-craft our place in it? This seems like caving into the lesser parts of the self: the neurotic (“I cannot handle a world that isn’t rational and thus predictable”), the external validation seeking (“I must fit into socially accepted narratives”), and the hopelessly idealistic (“I wish my life to be meaningful by approximating it to that which myself and others find beautiful”).

What is lost in the process?

• The experiences and motives leading to behavior that don’t fit the narrative. Perhaps those things deserve even more consideration than typical things do.
• Understandings of others that lie outside of our own worldview. You will misunderstand others and you will mistreat them if you can only approach them from your own point of view.
• A whole lot of meaningless fun.

To bring this back: I don’t think an internal monologue is indicative of intelligence, but personality defect. The world isn’t a book; maybe you should visit it some time.

A “metric” ton is a real unit of weight; I knew this, but not really what it was. I’d guess since it’s called a “ton” it’d be close in weight to an “Imperial” ton. Since there’s a hair over 2 pounds to a kilogram and metric is all based on powers of 10, I’d guess it’d be 1000 kilograms… I’d be correct.

“But isn’t that just a megagram?”

No sooner had the words left my mouth when I realized what an absurdity that word is.

(Please read in circus announcer voice)

You’ve heard of the gram. Smallest unit of weight you’ll measure on any given day. Now… let me introduce to you, it’s MUCH bigger cousin… Larger than any human can lift.. the MEGAGRAM!!

Even folks back in the 19th century people were familiar with the colloquial meaning of the “ton” and snake oil salesmen, and would arrive at the same decision that maybe “metric ton” was a bit more linguistically appealing.

Finally, I saw this on Colfax today. I like weird, but this might be a stretch.

This friend of course had to look through Mark’s disco and found the song “This Is My First Day and I’m Indian and I Work At a Gas Station” which is THE Midwest-est song title of all time.

Anyways, this all went down at my local bar which was hosting a Karaoke night after the Broncos game. It was a small gathering mostly inhabited by the servers/bartenders who had some interest in belting ABBA at the top of their lungs on company time (no shame). I was asked if I wanted to sing and I declined because “I don’t know anything but sad songs.” I don’t think they’d love to hear The Anvil Will Fall by Harvey Milk or Tango Till They’re Sore by Tom Waits.

An otrovert is a term for a personality type, coined by psychiatrist Dr. Rami Kaminski, that describes individuals who do not seek to belong to groups but instead embrace their sense of “otherness” and independent thought.

The main difference between an “introvert” or “extravert,” and an “otrovert” (I will leave the parenthesis out from now on, but please read it as if they are still there =) is that an otrovert may enjoy social contact, but does not orient their social behavior towards the group. This is opposed to both introverts and extroverts, which, while having different focuses, still orient their social behavior towards the group.

An introvert may eventually grow tired of socializing and prefer personal time, but when they are socializing they interact with other individuals via their group identity and shared values. Otroverts will interact with other individuals as Unique (capitalization on purpose), disregard group identity, and give little importance to what is shared.

I can think of a couple such people, myself included.

While, this is fine an all, but just adds another arbitrary species in an incomplete taxonomy. We should instead create species from conjunction of criteria and not simply ad-hoc.

So what are those criteria? What is being classified by introvert, extrovert, and otrovert?

Well the answer is one’s relationship to the various “others.” Give me a second to dig through a couple years worth of diary entries…

Now, lets enumerate the “others” an individual can come into relation with:

• their material being
• themselves, spiritually
• themselves, through the lens of the group (religiously)
• themselves, through the lens of another individual (introspectively)
• another individual
• the group
• the god

The introvert will prioritize relation with themselves, their material being, and possible the god both externally and internally reflective; with the group and other individuals as secondary. The extrovert will prioritize their relation with the group and god, both externally and internally. The otrovert will reject the group and god and prioritize their spirituality, being, and possibly individual relations.

There are possibly more and better criteria for otherness and I’m simply unaware, or it hasn’t been reasonably studied.

You know what I wanted to be when I was younger? Well I was obsessed with dinosaurs like every white boy. I was actually the only white boy I knew who was obsessed with them, but IYKYK. So I wanted to be a student of the dinosaur, but not the extinction dinosaur, not the archeologist, but the study of the alive-again dinosaur, a zoologist.

That’d still be cool. Eh… maybe next year.

This section is titled after how Bohumil Hrabal described his style of writing. Read “Too Loud A Solitude” if you haven’t.

It all made me quite nostalgic for the olden days, so I pulled my PS3 out of storage to replay the Ratchet and Clank series only to be met with disk-read issues and the now-defunct PSN activity message on all of my friend’s profiles “Last seen 10 years ago.”

Holymotherfuck. 10fuckingyears?

One of my friends who was the longest AFK was one I met playing on the PS2 and I randomly ran into during a game of S&D on Array on BOps 1 on the PS3 before re-adding him. His name was Chaos; we first met when I was 12 or 13. 19 years ago…

And of course a flood of people came back from that experience: Sheri, Aaron, Ghost and his wife, Maddog, JMan…

“Last online 10 years ago”… “19 years ago”…

I truly cannot fathom the fact I was alive and interacting with the world at large so long ago. It was a very different world too: flip phones, Christian youth groups where everyone fucked and did PCP, queer was just a passing fad, my pet rabbit Spencer (female, lol, rabbits are hard to sex) was my best friend, driving random fuckheads all across the shore in my (dad’s) truck so I could make friends, being suicidally depressed most of the summer and only awakening from staring-at-the-ceiling catatonia to ensure my AP summer work was done, blowing off classes and walking around the zoo and park, reading webcomics, or trying to break into the school’s computer system.

There are multiple lifetimes of my own I could go on about, but I don’t even remember enough to do so. Every time I go home I hear about shit I used to do when I was young and I can only just nod along and suggest “Yeah, that sounds like me, lol.”

There’s something to be said there about self-narrativization, about distilling experience into an easily digestible form for others (and now I’m realizing, my own) benefit, but that’s a multi-pager when I’m a bit less drunk.

There’s yet another post about nostalgia, oblivescence, and the meaning making of lost consciousness that me and Jaime had conversations about a couple years ago now that I should transcribe before I lose them. “I Will Not Forget That I Have Forgotten.”

But what’s more interesting to me is the lifetimes of the people I’ve missed out on. What have they done since middle school? Yeah, you hold the world record in downhill derby times, you struggled fitting in at the new school, then you became popular and dropped me, but then what? Special Ed teacher? Animal Crossing enthusiast? You hurt me, but I still want more for you. Even if it’s not “more”, I want to know its enough for you.

Anyways, I’ve been listening to Man’s Gin - Smiling Dogs a lot recently and it’s a great album for a Denverite to get into.

I randomly bumped into someone when picking up my keys for the new place and told her I was moving in and we petted each other’s dogs. She sent me a welcome letter and invited me to a community clean-up event on Sunday. I never got anything like that at my last place; they would often just ignore you if you gave them a friendly “hi.”

Then yesterday went to the neighborhood bar and talked to the bartenders a bit and got free tickets to the concert going on down the street. I had no idea who was playing, it was sold to me as “folk,” and why not? I didn’t have anything better to do… But Willi Carlisle is the kind of folk people are talking about when they say “American Folk Music,” it’s bluegrass and old country mixed with old union songs. Think Woody Guthrie or Pete Seeger. It’s not really my thing, more my dad’s thing, but it was a cool experience never the less.

History of cocotb

cocotb started in 2013 as a part of a startup by the original authors (Chris Higgs and Stuart Hodgson). They worked on it until after the dissolution of the venture (date unknown) and a bit longer into 2016. During that time they released the 1.0 version. Then there was a period of no activity, prompting the popular issue originally posted by Patrick Lehmman “Is Cocotb dead?”. But it was not dead yet…

In late 2018 the project was taken over by FOSSi, under the stead of Philipp Wagner. He added the first new maintainers: Tomasz Hemperek, Colin Marquardt, and Eric Weiser. Finally adding me and Marlon James in 2019 and 2020, respectively. Since then, the cocotb maintainers have done 9 major releases in 7 years, with a tenth (2.0) looming.

The new ownership brought a new development/maintenance system: the shared maintainer model, where the maintainers share responsibility for reviewing and merging contributions from other users rather than directly developing the code. This was fine as the project had reached the limit of its scope, it had hit 1.0, it just needed bug fixes, documentation improvements, etc. “Maintenance.”

Not to speak ill of the original authors, they had great a great idea and developed a fairly complete prototype to prove that idea worked. But as I said, they developed a prototype. The new maintainers have spent the last 7 years fixing bugs and refactoring the code to increase the code quality, usability, and re-usability of the code, all while trying not to break the ever-increasing user base.

We are very much trying to be a mature project that doesn’t need to massive rewrites that inadvertently break things. 2.0 is well over-due in that regard. I’ve wanted to work on an API breaking change for years now, but haven’t been in a good enough place to accomplish that, nor have the other maintainers.

But now the future looks bright. Well, almost…

The Future Of cocotb

If you asked me “Is cocotb the future?” I’d say “No. cocotb is now”.

“But will cocotb also be the future, say, 10 years from now?” “Almost certainly not in its current form.”

It already fails to do what many users need it to do. People need performance and that comes in the form of moving more into the simulator with DPI and RTL Drivers and Monitors. People need reuse of existing testbench infrastructure, such as UVM agents and TLM-based Drivers. People need better reusability for with hardware testing. People need a more featureful regression system. And while all of that is currently possible, it isn’t readily available. And cocotb is not “developing” any more.

cocotb will someday die, but it will live on, and not just in memory, if it’s up to me. This will be accomplished by making the cocotb codebase more extensible and modular.

Against Prevailing Sentiments

EDA tooling hasn’t quite escaped the monolithic design style that is often valuable in commercial tools (“please become dependent on our walled garden!”). Even some FOSS EDA tools fail to escape that mental box. But open source software hasn’t operated in that way in decades.

Modern open source software is built to do one thing and do it well. And it does this by reusing and extending existing libraries. Tools fall out of favor, but the useful pieces will live on and mature. Over time the useful pieces will ossify and become “core libraries/tools”. That is how I see cocotb surviving into the next decade.

There are useful reusable pieces of cocotb like the GPI and PyGPI in any other Python-based cosimulation framework, and the scheduler, tasks, triggers, etc. in shared HW/simulation testing. And there are less useful pieces, like the Makefiles and Python runner that most serious cocotb users have already ditched.

However the useful pieces aren’t in a state to be reusable right now. Putting cocotb into that state will be the focus of my efforts on cocotb going forward. I would hate to see useful software and tens of thousands of hours of development time go to waste.

Change In Attitude

As I mentioned cocotb uses a shared maintainer model, which is best fit for a post-main-development project. However, if you ask me the cocotb of now still has a lot of improvement potential. To me, how cocotb is maintained and and what I’d like to do with it don’t really align. So I decided early last week that I was going to change how I was going to work on cocotb.

I started coconext with the idea that it would be where I would develop new cocotb features; where “massive rewrites that cause inadvertent changes” that are necessary for new development would be done. All while letting the cocotb repo do what it should be doing and maturing.

Of course I will need to do changes to cocotb still, but I will do so even more judiciously than I already have been. My current modus operandi has been to focus on refactors, bugs fixes, and new features to create improvements over existing functionality. But I will no longer focus on developing new features in the cocotb repo; that will be reserved for coconext. The majority of my work going forward will be the necessary changes to cocotb to support features in coconext, as well as refactoring changes to make cocotb more extensible and modular (plus the obvious bugfixes, documentation improvements, etc.).