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.).

I’ve heard a number of people say things along the lines of “protected is bad” or “protected breaks encapsulation and leads to coupling” and I’m here to tell you that these people don’t know what they are talking about. Don’t get me wrong, I think the whole class-based encapsulation thing that C++ does is super cringe, but there’s nothing wrong with protected if you buy into the rest of it. The real problem is that people don’t understand it and use it wrong.

protected is public.

That should demystify my position, but assuming it doesn’t, let me explain.

Scrutiny

protected marks a class member as being visible to classes which inherit from it, but not to “user” code. This is opposed to private where the member is not visible to both users and heirs and public where the member is visible to both users and heirs.

The whole system seems to be designed to create built-in support for two contextual interfaces for a class; one being “user” and the other “heir”. You could complain this is too simplistic, there are many possible contextual interfaces for a class, but these two are extremely common so they get official recognition¹.

Synthesis

So it’s best to think of protected as public, but in the context of the heir. And this understanding is what dispels most of the bad arguments against protected.

It breaks encapsulation!

Only if you let it… Exposing data members publicly? Yeah, of course that breaks encapsulation; so don’t.

It creates coupling!

Users are supposed to use public API? I don’t get how this is an argument. Unless you want to complain that all use of public API creates coupling. You’d be correct, it does, but that’s an inevitability.

Conclusion

Most programmers understand that carefully designing a public API is important. You are going to have to live with it for a very long time. You can’t just break it willy-nilly. However, most people don’t seem to apply the same caution to protected.

Start.

Further Thoughts

Of course, that’s easy to say and ignores the obvious fact that protected is rarely used (in my experience) to encode a well-crafted public API for heirs; but instead exists to share implementation with subclasses written by the same author as the parent class, often in the same file. This underscores the larger conceptual issue with class-based encapsulation as a way to encode encapsulation that I alluded to earlier. There is no easy way for implementors to simply share all the private details of a class with other classes they have written in the same library without either using protected, or by making everything private and making all the classes friends².

What many other languages use is module/package-based encapsulation. For example, in Java, the default privacy mode is “package private”. This means members appear private to users of the package, but appears public to all code within the package. Translating to C++… this is like making all classes and functions in a package friends. The recommendation in Java is to only use public and package private³.

A package is usually implemented and maintained by a single entity (often just one person), so there’s no need to hide details about the implementation from itself. If a codebase gets so big one needs to employ encapsulation to make it manageable, maybe the codebase should be multiple packages?

I bring this up because package/module-based encapsulation is probably a more coder-friendly solution to encapsulation than class-based. With C++20’s modules, “package private” class members could become possible in the future, though I don’t see any interest in it right now.

Footnotes and Asides