<somlo>
has anyone encountered "ABC: malloc(): largebin double linked list corrupted (bk)" during an "8.48.18.4. Executing ABC9_EXE pass" ?
<ZirconiumX>
Report it as a bug
<somlo>
ZirconiumX: I'll need a bit of help before doing that -- I'm using ABCEXTERNAL (with abc git commit 97c826a from *today*); I wanted to re-run the test with abc commit fd2c9b1 as shown in the yosys Makefile's $ABCREV, but the weird thing is I can't find that commit in upstream ABC's git log
<ZirconiumX>
somlo: because "upstream ABC" is now YosysHQ/abc
<somlo>
hmmm... that's going to complicate packaging, but good to know
<somlo>
so on a scale from "bundling for convenience" to "full-on libreoffice vs. openoffice fork", where does yosyshq/abc stand, roughly speaking ?
<whitequark>
more former than latter
<whitequark>
abc had pull requests with no activity for years
<whitequark>
on top of being a pretty awful codebase to work with in first place
<ZirconiumX>
A lot of good ideas in there, but the only person who can understand Mishchenko's code seems to be Mishchenko himself
<whitequark>
yep
<somlo>
do you expect you'll still be tracking berkeley-abc? Right now I see 7 commits on top of berkeley, which is not too horrific. Is it still a goal to keep divergence to a minimum ?
<whitequark>
someone could submit the WASI patches on top of berkeley-abc
<ZirconiumX>
But whether they'd get merged is...another question
<whitequark>
yeah that's why i won't be the one doing it
<ZirconiumX>
It's possible - depending on what your packaging team thinks - to carry these patches on top of berkeley-abc/abc
<ZirconiumX>
I suppose WASI isn't as important to...Fedora, I think you're using?
<somlo>
ZirconiumX: that's what I was wondering -- carrying the patches on top of berkeley makes sense, as long as the set is likely to remain more or less bounded
<whitequark>
you don't even need them if you don't arget WASM
<somlo>
yeah, I wasn't seeing it on the list of deltas between upstream and yosyshq/abc :)
<ZirconiumX>
Okay, so, it *should* work fine with upstream berkeley-abc/abc
<ZirconiumX>
But obviously the ABCREV should be changed
<somlo>
ok, so with yosys 8b074cc and upstream ABC I'm getting that ABC malloc error... Guess that's really on ABC, not yosys
<ZirconiumX>
Yep
<somlo>
ok, I'll file a bug against berkeley-abc, see what happens... Thanks for the the context and back-story on how the moving parts fit together :)
<az0re>
ZirconiumX> A lot of good ideas in there, but the only person who can understand Mishchenko's code seems to be Mishchenko himself
<az0re>
Hah, true, although I've found him to be very helpful if you just ask
<ZirconiumX>
What's a code comment, anyway?
<ZirconiumX>
/s
<sorear>
a "code smell", I am told
<qu1j0t3>
lol
<ZirconiumX>
I've often found that I've found the Venn diagram between people who believe code should be self-documenting and people who do not write self-documenting code to be a near-perfect circle
<ZirconiumX>
I will confess to having been in that circle at one point
<qu1j0t3>
yeah i remember being about 16 and never writing comments
Cerpin has joined #yosys
<somlo>
"if it was hard to write, it should, rightfully, be hard to understand", right? ;)
jakobwenzel has joined #yosys
<qu1j0t3>
eek.
<qu1j0t3>
i first encountered that around 1982/3:)
<qu1j0t3>
"Real Programmers don't eat quiche."
jakobwenzel has quit [Ping timeout: 272 seconds]
jakobwenzel has joined #yosys
Laksen has quit [Remote host closed the connection]
jakobwenzel has quit [Ping timeout: 256 seconds]
zkms has joined #yosys
BinaryLust has joined #yosys
zkms has quit [Client Quit]
zkms has joined #yosys
kraiskil_ has quit [Ping timeout: 260 seconds]
rlee287 has joined #yosys
kraiskil_ has joined #yosys
kraiskil_ has quit [Ping timeout: 256 seconds]
zkms has quit [Quit: uguu]
zkms has joined #yosys
zkms has quit [Client Quit]
smkz has joined #yosys
BinaryLust has quit [Ping timeout: 260 seconds]
vidbina has joined #yosys
BinaryLust has joined #yosys
Cerpin has quit [Read error: Connection reset by peer]