<whitequark>
no problem, a few days or a few weeks even
<cr1901_modern>
Works for me, tbh.
<kbeckmann>
i started working on a Gowin platform for nMigen. initially i wanted to target apicula but since it's in a quite early state i moved on to support the official toolchain instead. there is still a lot left to do, but if anyone is curious and want to try it out and/or give feedback, i keep my changes on the following branch https://github.com/kbeckmann/nmigen/commits/gowin_gw1n
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
Shari2_ has joined #nmigen
Shari2 has quit [Ping timeout: 256 seconds]
<whitequark>
kbeckmann: lots of other platforms require bash but don't put it in required tools
<whitequark>
i assume any *nix system at least *has* bash. seems safe.
<d1b2>
<OmniTechnoMancer> Does it need bash specifically or a shell?
<d1b2>
<Darius> screams in FreeBSD
<d1b2>
<Darius> (although so long as you call bash when you want bashisms we're all good..)
<whitequark>
Darius: every toolchain that requires bash ships as linux binaries anyway
<whitequark>
if you can run that, you can run bash just fine
<d1b2>
<Darius> ahh yep
noknok has joined #nmigen
noknok has quit [Ping timeout: 256 seconds]
<d1b2>
<OmniTechnoMancer> Yea as long as it runs bash and doesn't expect sh to be bash it should be okay
<d1b2>
<Darius> although I would humbly suggest #!/usr/bin/env bash if you are
<d1b2>
<OmniTechnoMancer> It is annoying that that trick requires /usr/bin/env, Haiku has a special case for it for that reason, though Haiku will also lookup the shebang command in the PATH so its weird
<whitequark>
the scripts run under any sh but restart themselves under bash if the shell is not bash
<d1b2>
<Darius> ahh neat
emeb_mac has quit [Quit: Leaving.]
noknok has joined #nmigen
noknok has quit [Ping timeout: 256 seconds]
Shari2_ has quit [Quit: Leaving]
Shari2_ has joined #nmigen
Shari2_ has quit [Client Quit]
Asu has joined #nmigen
korken89 has joined #nmigen
noknok has joined #nmigen
Shari2 has joined #nmigen
chipmuenk has joined #nmigen
noknok has quit [Ping timeout: 256 seconds]
korken89 has quit [Remote host closed the connection]
korken89 has joined #nmigen
lambda has quit [Read error: Connection reset by peer]
lambda has joined #nmigen
korken89 has quit [Remote host closed the connection]
noknok has joined #nmigen
korken89 has joined #nmigen
noknok has quit [Ping timeout: 246 seconds]
noknok has joined #nmigen
noknok has quit [Ping timeout: 256 seconds]
_whitelogger has joined #nmigen
<Shari2>
@ktemkin target_ulpi.data.oe .eq(~target_ulpi.dir) TypeError: bad operand type for unary ~: 'Pin'. Is this a know issue? Currently trying to build master 70db91ced with python3 applets/interactive-test.py --dry-run.
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #nmigen
<vup>
:)
<kbeckmann>
is there a way to avoid the use of '\' in the generated verilog from nMigen? I am having some trouble when synthesizing the generated verilog for Gowin. it leads to a synthesized verilog file that later on generates syntax errors when fed into the PnR tool unfortunately.
<kbeckmann>
i am sure that the nmigen output is valid, but the tools seem less than perfect..
korken89 has quit [Remote host closed the connection]
<kbeckmann>
hmm please disregard the above. it seems that the synthesizer itself injects backslashes sometimes for some reason i don't understand, which leads to problems in PnR later on. it's a beta toolchain after all.
<daveshah>
Backslashes are usually used to escape names containing non-alphanumeric chars, fwiw
<kbeckmann>
alright, that sounds like it makes sense. this tool however just decided that when I use an IOBUF it starts using backslashes all of a sudden
<kbeckmann>
however i am not sure how i can work around this..
<kbeckmann>
post process the generated .vg file before pnr?
<daveshah>
Heh perhaps
<kbeckmann>
maybe i'm just missing some configuration flags for the synth tool. i am not specifying too much as it is, so maybe it's using some strange defaults.
<daveshah>
It's a strange failure as I can't see anything in the input that should cause this
<kbeckmann>
yeah exactly.. it's quite weird :)
<d1b2>
<OmniTechnoMancer> Are you allowed non breaking space in the escaped verilog name?
<daveshah>
I don't know what the standard says, but afaik any UTF-8 encoded Unicode works with Yosys at least...
<daveshah>
in escaped names
<d1b2>
<OmniTechnoMancer> are there any forbidden characters in such an escaped name?
<d1b2>
<OmniTechnoMancer> can you emit evil verilog that uses nonbreaking space to have a name that looks like its verilog code but actually is just a very strange name?
<d1b2>
<OmniTechnoMancer> Clearly this calls for an obfuscated verilog competition
<kbeckmann>
ok i think i'll give up on this vendor tool. it seems to be completely broken in multiple ways... it optimizes away stuff and loses inversions and stuff. maybe i should just use yosys instead.
<kbeckmann>
it's a beta after all :).
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #nmigen
<d1b2>
<DX-MON> not using a broken vendor tool and instead using Yosys sounds like an excellent idea to me
<kbeckmann>
yeah :)
<ktemkin>
I thought "broken vendor tool" was saying the same thing twice
<kbeckmann>
:)
<d1b2>
<DX-MON> haha, good point Kate
<whitequark>
sorry, i can't make the meeting today
Shari2 has quit [Quit: Leaving]
<lkcl>
whitequark: ok
<awygle>
my status for the meeting is "writing unit tests for record bug, will submit PR today"
<lkcl>
good here. on track for dec 3rd 180nm tapeout
<mwk>
hmm
<mwk>
should (Signal(8) - Signal(8)) be unsigned?
<whitequark>
sure
<mwk>
feels to me it should have shape signed(9), not unsigned(9)?
samlittlewood_ has joined #nmigen
<whitequark>
the rule is that you get a signed operation if any operand is signed
<whitequark>
unsigned otherwise
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood_ is now known as samlittlewood
<mwk>
this doesn't seem to be the case for unary -
<whitequark>
yup, i was talking about binary ones
<mwk>
okay... so if I want to get the proper arithmetic result of that, I need to manually cast the result with as_signed?
<whitequark>
i think so
<whitequark>
better check though because i'm too sick atm to think about arithmetics correctly
<lsneff>
Does nmigen produce some sort of IR which is then lowered into verilog, or does it go straight for verilog?
<awygle>
it produces RTLIL which is the Yosys IL
<d1b2>
<dub_dub_11> > good here. on track for dec 3rd 180nm tapeout @lkcl#0000 wait is that TSMC 180nm?
<whitequark>
it is impossibly hard to produce correct verilog in general
<whitequark>
even yosys barely manages
<whitequark>
and that's with CPU days of randomized testing
<lsneff>
Ah, I see, thanks
<lsneff>
Was just curious whether adding other language dsl frontends was feasible, seems like it would be, but wouldn't be related to nmigen
<d1b2>
<dub_dub_11> Cause if so, that might mean your ASIC is on the same MPW as my coursework :D
<whitequark>
lsneff: check out the yosys connect_rpc pass
<lsneff>
Ah, that does look interesting. Used for instantiating modules from any supported hdl?
<whitequark>
from any HDL that can talk a simple JSON protocol
<whitequark>
including mutually recursive modules from different HDLs
<lsneff>
If I have a few month or two at some point, I'll look whether a rust-based hdl would work.
<lsneff>
Oh, exciting
<awygle>
ha
<awygle>
i am not aware of any rust-based HDLs but there _must_ be one
<awygle>
in some quarter-finished crate somplace if nothing else
<lsneff>
Yeah, I bet there is somewhere
<lsneff>
I'm actually really interested to see if the type system could enforce invariants more effectively then the "runtime" checks of nmigen/etc
<agg>
hoodlum is more like its own standalone HDL that has a rust tool that compiles it to verilog
<agg>
kaze is more like nmigen, you use rust to runtime-generate a circuit
<lsneff>
Yeah, I was thinking more in the direction of kaze, but that doesn't look particularly usable
<agg>
yea, i think the model of embedding inside a language is best
<agg>
it's a huge part of what makes nmigen outrageously productive i think
<agg>
I wonder how a rust equivalent to pysim would perform compared to cxxrtl/cxxsim
<lsneff>
Probably a few orders of mag better than pysim
<lsneff>
Likely similar to cxxtrl/cxxsim
<agg>
i dunno, you have to include rust compile times
<lsneff>
You do?
<agg>
though vendor toolchain synthesis might be the only thing slower at compiling than rust, heh
pdp7 has left #nmigen [#nmigen]
<lsneff>
Well, you can get that pretty small if you're careful
<lsneff>
And the new debug compiler backend is pretty fast, but not quite really for primetime yet
<whitequark>
i strongly doubt it will be similar to cxxrtl
<agg>
you'd have to recompile your rust code to rebuild your circuit, which might take as long as pysim does to run your entire simple simulation
<whitequark>
cxxrtl has static scheduling, pysim has not
<agg>
whitequark: yea, i'd expect cxxrtl would be way faster than pysim-but-in-rust
<lsneff>
Ah, I see, yeah
<agg>
and no point writing "rustrtl"
<lsneff>
It's true compile times would be pretty bad
<lsneff>
I sometimes wish there was "rust-but-jit"
<agg>
heh
<awygle>
isn't that cranelift? or one of the use cases for cranelift anyway
<awygle>
it's weird to say this in the nmigen irc channel but i'm still not really convinced by "hardware language inside software language"
<awygle>
if nothing else, purely from an optics perspective i think it gives a bad impression
<whitequark>
not to people who tried to use generate statements in verilog
<agg>
you'd rather have essentially a better verilog?
<whitequark>
or to people who wrote preprocessors to generate verilog
<whitequark>
or... you get the idea
<whitequark>
where i think nmigen positively falls flat is staged compilation. it's implicit
<awygle>
i wouldn't put it like that, and i'm not sure i'd "rather" have anything in particular, but i think a fully separate language would make a better first impression on me than an eDSL
<whitequark>
something like MetaOCaml would be more appropriate
<whitequark>
ultimately, i think it boils down to what you think about python
<awygle>
like, come to me and say "this is an HDL that i built based on the ideas of MetaOCaml", i'd be like "hell yeah that sounds great"
<lsneff>
Cranelift was actually originally intended to compile wasm to machine code
<awygle>
come to me and say "this is an HDL built inside of MetaOCaml", and i'm quite a bit more skeptical
<lsneff>
But someone realized they could use it as a rust backend
<whitequark>
lots of people think python is the best thing since sliced bread, so a HDL embedded in Python sounds amazing to them
<lsneff>
And I suspect something *like* jit will eventually happen with it
<awygle>
it basically comes down to me being worried about impedance mismatches between the software and hardware models. a la "attempted to convert nmigen value to boolean", as a benign example
<agg>
eHDLs also get to re-use all the language tooling like syntax highlighting, linters, test frameworks, that sort of stuff
<sorear>
there are a couple of different places you can have very slow rust compiles: (a) you used too much type-level metaprogramming (b) you have a lot of layers of indirection that need to be inlined out (c) you have a lot of code and llvm is not super fast at any opt level
<whitequark>
agg: awygle is sorta right even in that context: the highlighting doesn't take nmigen idioms into account, neither do linters
<lsneff>
And it totally possible to organize things so only a small part of your code will actually end getting re-compiled.
<agg>
for me, once it was very clear that you were writing a python program that generates a circuit, rather than yourself describing a circuit, both metaprogramming and avoiding confusing software/hardware models got much easier
<awygle>
i do understand the benefits of eHDLs, but my personal bias is towards a turing-complete metaprogramming language around a hardware-focused HDL
<whitequark>
basically, i agree with awygle that philosophically, something like nmigen isn't necessarily a good idea
<agg>
whitequark: but most of my hdl in nmigen is python, and wants python linters and highlighting
<awygle>
i'm obviously open to being proven wrong tho or i wouldn't be here
<sorear>
how do the people in this debate feel about bsv
<whitequark>
i just stopped caring about philosophy because i wanted to get things (like glasgow) done
<awygle>
^ that too, there's a productivity argument which is compelling
<agg>
awygle: I guess the question is why not have that metaprogramming language be an existing language, rather than having to make your own?
<ktemkin>
the thing is, if nmigen was its own metaprogramming language, it wouldn't support like 70% of my use cases
<awygle>
especially since the design space isn't super well explored imo, so prototyping in python et al makes sense
<whitequark>
i'll take a fundamentally unsatisfying idea (eDSL) in a fundamentally unsatisfying language (Python) and make the best of it
<agg>
i think i'm the opposite, my ideal is an eHDL inside a language like python or rust that i'm using anyway
<agg>
the value of the metaprogramming is well worth the warts in the hdl part
<whitequark>
ktemkin: agg: there are metaprogramming languages better suited to embedding a HDL than Python!
<ktemkin>
I have _lots_ of things that have python functionality (GNURadio, FaceDancer, etc), and being able to use the existing code to orchestrate gateware construction *is* what I need
<lsneff>
agg: As in, you'd have a ehdl that's parsed by a rust macro?
<awygle>
the integration point is a good one, but with an eDSL you accidentally privilege a particular ecosystem for that integration
<agg>
lsneff: that sounds a bit cursed, I mean like nmigen where you're writing a program that builds up the circuit at runtime
<sorear>
no reason something like nmigen couldn't have "concrete syntax" as an alternate way to generate objects
<awygle>
like great GNURadio has a good Python API, but if i want to integrate with a Rust crate i'm SOL (except via indirection through C)
<agg>
whitequark: for sure there are, but not as popular or widely used as python or with as developed tooling, for all python is unsatisfying
<whitequark>
awygle: accidentally? no, very much intentionally
<agg>
awygle: I guess if you could somehow separate the metaprogramming/integration and the circuit description parts, the latter could be a nice standalone language that you could plug in to whatever integration you wanted
<awygle>
i want that problem solved generically (but now we're back to productivity argument, as that's not an easy problem)
<whitequark>
general cross-language integration is a fool's errand anyway
<whitequark>
the last serious contender there was COM and that's pretty much dead as a concept
<agg>
awygle: I guess like the opencl concept of kernels in one language and an API in several host languages that can template and compile the kernels and load them onto hw
<awygle>
:( i'm genuinely kinda sad to hear you say that wq
<agg>
basically opencl but for gateware...
<whitequark>
i would very much like to work on better COM, but i'd first need to find someone to pay me for five years for a project that will be never adopted by anything that matters
<awygle>
because that's my particular bugbear, and you're a person whose opinion i take seriously
<awygle>
oh yeah sure
<awygle>
first step, post-scarcity society
<whitequark>
there are so many philosophically nice ideas which you can't use to build a HDL that will matter to people today
<awygle>
second step, cross-language integration
<lsneff>
Well, there's actually something coming from wasm that could be adapted into a next-gen kind of COM
<whitequark>
lol
* sorear
mumbles about Parrot
<ktemkin>
there's a huge problem in that there's a limited number of People Who Can Do The Thing
<lsneff>
wasm interface types could be adopted to work between native languages
<awygle>
WASI is pretty cool conceptually, i hope i get a (paid) chance to learn more about it
<whitequark>
wasm interface types are nice but i'm not sure if they really solve the same problem
<ktemkin>
the more compatibility and abstraction you add, the more you spread those people out across things
<awygle>
ktemkin: that's true and kinda falls into the "first step" category, because i don't think that's a fundamental state of being so much as a fucked-up industry
<lsneff>
Well, (assuming that can be adapted to work without wasm at all) they'd solve the language interoperability problem completely and utterly.
<whitequark>
that's just not true
<ktemkin>
awygle: the thing is, you can't just throw good developers at e.g. whitequark and expect that'd make things more productive
<lsneff>
You're right, they're actually all that, but I'm curious what problems they couldn't solve
<lsneff>
*not actually
<whitequark>
the hard problem of language interoperability is integrating languages with different computation models
<awygle>
no, of course not. this is a whole other thing but i basically don't believe more than 3 people can productively work on anything at the same time lol. but in a better world we could nurture more people who can perform at the level of a whitequark
<whitequark>
think of how you could use interface types to integrate e.g. ocaml and haskell
<whitequark>
or e.g. com-style c++ and rust
<lsneff>
I actually haven't written any ocaml, but would the incompatibility be largely around haskell's laziness?
<whitequark>
if language A pervasively uses some idiom and language B's type or runtime system makes that idiom inexpressible, using language A from language B would not be nice even if you solve the problem of C ABI being utterly insufficient
<awygle>
language integration is a lot more about API design than it is about ABIs tbh
<whitequark>
^ that
<awygle>
i just had a strong vision of azonenberg >_>
<whitequark>
something like COM is a reasonably nice way to interop between, say, Ruby, Python, and C#, which are all based on a similar model... except when it isn't when you talk about things like value types
<whitequark>
but it stops being even reasonably nice once you stop trying to interop between extremely similar languages
<whitequark>
don't get me wrong, this is a problem i'm excited about (and would like to work on)
<whitequark>
i just think it is infinitely far from being solved yet. we barely even started
<awygle>
see step one above :p
<sorear>
except for the part where cross-heap GC integration is a hard problem
<whitequark>
you can solve that one with Graal
<awygle>
yeah we haven't even started talking about ownership
<sorear>
it's a good way to interop C++ and VB6
<lsneff>
I do think that's true, many languages just express things in an incompatible way
<whitequark>
well, you can avoid solving that one with Graal.
<ktemkin>
look at what happened after COM, though
<whitequark>
(and wasm can solve it in a similar way by also being a shared substrate)
<awygle>
microservices are brutalism for API design, since you _must_ draw clear boundaries and all that
<ktemkin>
a lot of the development on that side shifted from "come up with a common interop" to "modify all of our _languages_ to behave closer to the same"
<sorear>
is that really a bad thing?
<lsneff>
Yeah, I'm not confident that's a bad thing
<awygle>
which, mine or ktemkin's? i think ktemkin's is a bad thing
<whitequark>
i don't think language monocultures are necessarily good
<awygle>
language homogeneity something something sapir-whorf
<whitequark>
i mean, if language monocultures were a bit more entrenched, we'd never get rust
<whitequark>
(and rust isn't even that different)
<sorear>
basically every mainstream language _does_ have a shared subset, the platform C ABI, it just sucks
<lsneff>
Rust is fundamentally similar to C++ imo, just with some extra PL on top
<sorear>
I don't think rust would have been precluded if there were a somewhat richer lingua franca
<ktemkin>
"microservices are brutalism for API design, since you _must_ draw clear boundaries and all that" <-- this is a *lot* easier to do if the boundaries are already known, rather than something that becomes apparent over the course of development
<awygle>
it sucks _and_ it doesn't address things like cross-heap gc integration (like at all)
<ktemkin>
but development is as often exploratory as it is implementative
<awygle>
i take your word that that is true even though it is not my style
<ktemkin>
awygle: I mean, how often have you changed your architecture upon realizing something while developing?
<Sarayan>
ktemkin: so, was it your code or was it usb being usb?
<ktemkin>
Sarayan: haven't done any USB stuff yet; been in meetings
<lsneff>
I will say that interface types do try to work with both eager and lazy evaluation representations of data.
<awygle>
ktemkin: it really depends how you define those terms. i change my architecture between development cycles all the time, but rarely make major shifts within development cycles
<Sarayan>
ktemkin: we shall know later then :-)
<awygle>
design and implementation are very separate phases for me
<ktemkin>
awygle: I'll often modify my design / APIs as I implement, as challenges become apparent and/or I have better ideas
<Sarayan>
I've pretty much never seen a design being perfect and complete on the first try
<awygle>
like i said, i believe you, it's just not really how i work
<ktemkin>
my point is, there are costs to loose coupling
<whitequark>
lsneff: Rust doesn't even have inheritance
<whitequark>
its ownership model is similar to what the C++ world eventually arrived in, that much is true
<awygle>
i mean, i used the word "brutalism", i wan't intending to indicate it was the 100% best solution in all cases :p
<whitequark>
but actually trying to interop Rust and C++ (check out what the chromium folks wrote about it) shows they're rather dissimilar
<lsneff>
The object-model is different between rust and C++, that's true.
<awygle>
there are definitely costs to loose coupling. there are costs to tight coupling too.
<ktemkin>
elegance lives in theory
<awygle>
~*~engineering~*~ :D
<ktemkin>
and once you pull things out of theory and into the usable, you wind up leaving little bits of elegance behind
<whitequark>
my view is that the degree of coupling is best decided by the amount of cohesion between the people who develop the respective components
<awygle>
ktemkin: i both agree with that statement and will fight against it until my death
<awygle>
(or until my shrink breaks me of the habit i guess)
<ktemkin>
awygle: I've learned to find beauty in the inelegance that emerges when you actualize things
<ktemkin>
I think it may be the only way to survive in tech without having your soul crushed =P
<awygle>
i think people read me as more frustrated that the world isn't perfect than i actually am
<awygle>
i am pretty happy working to make the world incrementally less imperfect, while not abandoning the belief that it can eventually become perfect
<ktemkin>
personally, I read you as staring wistfully out a window at the beauty hovering out of reach =P
<awygle>
heh
<lsneff>
So, I think what I've gotten out of this discussion is that we're more likely to become a post-scarcity society than solve language interoperability.
<awygle>
not unfair
<whitequark>
being vocal about your drive to perfection tends to feed the worst impulses of other perfectionists around you
<awygle>
well, if we all thought the same way, the world wouldn't be any fun i guess
<awygle>
whitequark: what do you mean?
<whitequark>
positive feedback
<Sarayan>
lsneff
<Sarayan>
lsneff: the replicator is more probable than the universal translator, technically :-)
<awygle>
meaning vocal perfectionism validates and reinforces others' perfectionism, even in cases where that perfectionism hurts them? i see the point, and also believe in talking to people in their language. although unaimed public discourse probably falls more on your side.
<ktemkin>
at this point, I don't really know if I'd consider myself a perfectionist, anymore
<whitequark>
i think you don't really appreciate how much effort went into leaving as few flaws in nmigen as it has now, and how much more went into making it actually usable to people today, as opposed to being some abstract ideal of a language
<whitequark>
ktemkin: i kind of generally stopped considering myself... anything in particular. i try to discuss traits and their consequences while tying them as little as possible to identity
<ktemkin>
I mean, I'm referring to an label derived from observation of myself, rather than anything tied to identity
<whitequark>
right; it's not always clear what any given person uses labels for, specifically
<ktemkin>
personally, I think nMigen does a pretty damned awesome job of being elegant within the constraints of practicality
<awygle>
whitequark: i think i do, as much as i can given that i wasn't here for most of it and wasn't you for any of it. you've done an enormous amount of excellent work, i didn't mean to belittle that and if that's the impression i gave i apologize for communicating badly
<whitequark>
awygle: yeah. i don't think you intend to, but it seems an inevitable consequence of any conversation about perfectionism around people prone to it that isn't explicitly and strongly biased against the concept (re: talking to people in their language)
<awygle>
ah i see
<awygle>
that's fair enough
<awygle>
i'll keep that in mind in the future
<whitequark>
just... something to keep in mind, since you mentioned earlier that people misread your intent. this, i think, is a part of why.
<whitequark>
I didn't understand that tweet back when I first read it, but I think I do now
<awygle>
yeah same, oof.
<ktemkin>
yeah, this conversation seems closer to what I meant, there
<lsneff>
I felt like that a lot when I was working at wasmer.
<whitequark>
oh neat, you worked on wasmer!
<ktemkin>
awygle: I think a lot of this theory is super fun to discuss, and would be great for conversation-over-a-beer-style-discussion
<lsneff>
I kind of regret it now, but yeah, I was the first or second employee at wasmer.
<ktemkin>
awygle: but generally, I like to keep my philosophical conversations like that nice and distant from any actual implementation
<whitequark>
i agree with ktemkin
<whitequark>
lsneff: oh no. i hope nothing too bad happened
<awygle>
i clearly fucked up this conversation rather badly, because i thought i _was_ doing that (except the venue of course)
<lsneff>
whitequark: It was really cool tech, but there were political problems between wasmer and mozilla.
<whitequark>
lsneff: i see
<lsneff>
I do hope wasmer the best, but I try not to be associated with them anymore.
<whitequark>
understandable
<ktemkin>
awygle: it didn't feel like "fucked up badly" territory; I just recognized "I don't know if I like <thing you happen to be doing>" as something that would have triggered my guilt-reflex
<whitequark>
i find it pretty easy to share the sentiment of not liking something i work on, but getting into the ways it *could* be perfect is pretty depressing
<ktemkin>
mm
<whitequark>
although i should clarify
<whitequark>
that there's different kinds of "not liking" and some of them are more adversarial than the others. specifically, i find it fairly easy to share a sentiment of constructive dislike, as in "we both know this has flaws and we know that's fine; this is how this world works"
<whitequark>
but it's something that is not easy to communicate precisely
<awygle>
i guess it goes back to "staring out the window" - i was basically discussing things in the abstract and for myself without realizing how it could be received as criticism of the ongoing work of others.
<awygle>
blanket apologies all around, and i'll definitely reflect on this conversation going forward :/
<whitequark>
yeah
<ktemkin>
awygle: apologies from over here, too, for being critical/argumentative. I'm sure I was projecting a fair amount through the discussion. >.>
<ktemkin>
was just hoping to provide context; I really don't want to make you feel bad
<awygle>
lol i was just typing "and thank you both for taking the time to educate me instead of just filing me in the Jerk Bin"
<ktemkin>
awygle: we've had way more purely-positive conversations than I've ever had critiques
<ktemkin>
you're pretty far from the Jerk Bin
<whitequark>
awygle: absolutely not; I think your feedback on the project has been very valuable so far, and the fact that our opinions (both technical and philosophical) sometimes differ a lot only makes it more valuable
<awygle>
still, i know you two both get _way more_ than your fair share of bullshit to deal with, so i appreciate it :)
<_whitenotifier-f>
[nmigen] awygle opened pull request #541: Fix Record Operators - https://git.io/JkUdM
<whitequark>
those are some very exhaustive tests :)
<_whitenotifier-f>
[nmigen] codecov[bot] commented on pull request #541: Fix Record Operators - https://git.io/JkUdN
<awygle>
don't wanna break anuejn's code again :p
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #541: Fix Record Operators - https://git.io/JkUdN
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #541: Fix Record Operators - https://git.io/JkUdN
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #541: Fix Record Operators - https://git.io/JkUdN
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #541: Fix Record Operators - https://git.io/JkUdN
<d1b2>
<dub_dub_11> the discord-irc bot is relaying messages from the notifier bot about comments made on github by the code testing bot
<d1b2>
<dub_dub_11> this is getting a little confusing 😄
<_whitenotifier-f>
[nmigen] whitequark closed issue #533: Breaking change in Record - https://git.io/JkeoE
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JkUFX
<_whitenotifier-f>
[nmigen] whitequark commented on pull request #541: Fix Record Operators - https://git.io/JkUF1
<awygle>
yay
<awygle>
oh that's a much better explanation lol
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JkUFQ
<_whitenotifier-f>
[nmigen/nmigen] whitequark e4ea1a6 - Deploying to gh-pages from @ ea94c9cc45c1c6d47673160a4c6edcfa9e37141d 🚀
<ktemkin>
incidentally, I feel bad that I haven't made more of a meaningful contribution to nMigen thus far
<ktemkin>
I owe y'all that at some point
<lkcl>
dlb2 / dub_dub_ll - IMEC Shuttle service using TSMC 180nm, yes.
<lkcl>
lsneff: there's one already underway, somewhere (rust-derived HDL compiler).
<lkcl>
the lesson learned from bluespec is that by directly compiling the BSV code (not as an HDL) you get 20x faster simulation time than if you compiled to verilog and ran it through e.g. verilator
<lkcl>
ktemkin: regarding use-cases if nmigen was its own language: yyep, i hear you. hilariously quite a lot of libre-soc is like this:
<lkcl>
that's 99.5% python and about 6 lines of nmigen!
<lkcl>
also, when i found the cocotb example that took the opencores JPEG verilog code and co-simulated it against python-imaging PIL library to check that the output was correct? i thought that was *the* coolest thing evva :)
<lkcl>
whitequark: lots of people drastically underestimate COM and it's been an absolute nuisance for free software that nobody properly "got it".
<lkcl>
XPCOM (mozilla) they failed to add co-classes and it caused 15 years of absolute hell for mozilla/xulrunner 3rd party developers
<lkcl>
i did at one point seriously consider extracting MSRPC and DCOM out of Wine as stand-alone. believe it or not they were forced (for compatibility with win32/64) to *correctly* implement DCOM!
<lkcl>
btw i just have to say, re-reading that conversation - you're all fascinating people :)
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 265 seconds]
jeanthom has joined #nmigen
umarcor has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #403: Records don't work in Assert - https://git.io/JkTej
<_whitenotifier-f>
[nmigen] whitequark closed issue #403: Records don't work in Assert - https://git.io/JfQsY