<emaste[m]>
hrm, there's a compatibility note that says
<emaste[m]>
> The “selectable” entry points were introduced in importlib_metadata 3.6 and Python 3.10. Prior to those changes, entry_points accepted no parameters and always returned a dictionary of entry points, keyed by group.
<esden[m]>
sorry but it will stay what it is for the time being. I will not be making any "tuning" at this point.
<emaste[m]>
LEDs are just too efficient these days
<esden[m]>
feel free to tape over it. It is fine when used with a case.
<emaste[m]>
It's in a case
<SnoopJ>
oh right, that error is from elsewhere in the `plugin` module, so you *did* fix the problem but there are other parts of the code that are assuming the newer `importlib.metadata` surface
<esden[m]>
ok well, I was fine with it, but I tend to have a lot light in my work areas. It is bit individual what is too much or too little.
<whitequark[cis]>
yeah I think I know how to fix this
<SnoopJ>
you could maybe getattr() your way out of the bag there but `importlib-metadata` is the "it just works as if I had the modern one" fix
<novakov[m]>
my glasgow arrived today (a lot quicker than I expected) after a bit of play with it I'm curious - did you think about using IPython as repl?
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] github-merge-queue[bot] 954813a - Deploying to gh-pages from @ GlasgowEmbedded/glasgow@62e27d9941bf22d1fdb73681af7eb74e96be775a 🚀
<lle_bout[m]>
I see, 3.8 still has security support but EOL in October 2024, it was initially released in October 2019 apparently - https://devguide.python.org/versions/ - but I think that in practice not many people are still gonna be on debian oldoldstable which has Python 3.7 so it's reasonable to expect newer, I use debian as a reference because most commonly available LTS distros are debian derivatives
<SnoopJ>
Debian has thankfully woken up and gotten with the times instead of continuing to live on the trailing edge of Python
<SnoopJ>
probably in no small part because there's been a lot more cooperation between the core and distros (PEP 668 being a particularly recent/controversial example)
<whitequark[cis]>
emaste: wasmtime isn't a hard dep; instead it's a way to ship yosys, nextpnr-ice40, and icepack to people without having them download something like https://github.com/YosysHQ/oss-cad-suite-build
<whitequark[cis]>
I think basically no one in the Python or open FPGA tools ecosystem ships binaries for FreeBSD
notgull has quit [Ping timeout: 260 seconds]
<emaste[m]>
I'm not really sure why they'd _need_ to (as opposed to using the FreeBSD package collection)
<whitequark[cis]>
does FreeBSD package yosys, nextpnr-ice40 and icepack?
<emaste[m]>
yosys-0.33
<whitequark[cis]>
that's good enough
<emaste[m]>
nextpnr-0.4_1,1 Portable FPGA place and route tool
<whitequark[cis]>
good enough
<whitequark[cis]>
(which architectures?)
<emaste[m]>
hmm, no -ice40 though, not sure what's in that nextpnr package (will look), no icepack
<emaste[m]>
I was going to say that copy-pasting a sudo example on FreeBSD is generally going to work, but then anyone running glasgow on FreeBSD is probably a few standard deviations away from the norm 🙂
<whitequark[cis]>
yeah it should probably not use external abc
<emaste[m]>
it's been there since the initial submission (https://reviews.freebsd.org/D15632), I'll ping the current maintainer and see if they can undo it
brolin has quit [Ping timeout: 272 seconds]
<emaste[m]>
thanks so much for all of your help on the FreeBSD bits!
<lle_bout[m]>
Either way, too bad, I guess I'll have to wait until I really get one to help in any way, I very well see how many protocols could break under the radar if everything isnt being tested constantly
<lle_bout[m]>
* many protocols (as they add up) could break
<whitequark[cis]>
oh I think I know what's going on with caching on our CI
<whitequark[cis]>
bleugh
<lle_bout[m]>
Since I don't have a glasgow, a virtual/simulated version of glasgow would allow me to help test/develop the CLI, and then since that error from this issue we were just talking about happened with a common command people are supposed to run (at least I believe); I was mumbling about adding integration tests to the CI since you were speaking about it. But since the CI can't have a real glasgow device, then it also needs a simulated
<lle_bout[m]>
version of one for that. Considering the quantity of proprietary protocols that exists, I was thinking that if people contribute code and then nobody uses it for a while because it's not such a common protocol then it could break and bit-rot (don't really know the specifics of the API to realize how main glasgow could interfere with an applet). I don't really know the design of glasgow yet or if there is some API for applets that's
<lle_bout[m]>
gonna change at some point so that applets need to update. I am thinking that in many cases people will develop applets for proprietary protocols once and then never come back to maintain it.. that's why I tend to think it will break/bitrot fast
<lle_bout[m]>
* maintain it (and not many people will have access to the actual hardware to test the proprietary protocol impl).. that's
<whitequark[cis]>
basically, right now we are just not set up for an influx of people submitting applets period
<whitequark[cis]>
since i started the project i got significantly more disabled, had to move (escape, really) across two countries, leave several abusive environments, and so on, which isn't really conducive to software development
<whitequark[cis]>
there is some support for record/replay based verification of applets on CI
<whitequark[cis]>
but it's at best vestigial, and there are plenty of other issues meaning we just cannot handle a big influx of applets
<lle_bout[m]>
yeah.. we spoke about that before. no worries, well I'll have to study the code abit more then I will have a more informed take on potential issues
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] github-merge-queue[bot] 0abe135 - Deploying to gh-pages from @ GlasgowEmbedded/glasgow@0192561adc344df958790ad0720414f7b161558e 🚀
duskwuff[m] has joined #glasgow
<duskwuff[m]>
I wonder how viable (if at all) it'd be to have applets talk to software simulations instead of real or synthesized hardware. write a simulated serial flash chip, hook an appropriate applet up to that
<whitequark[cis]>
who's gonna write all the simulation models?
<whitequark[cis]>
that's even more work than the applet
<lle_bout[m]>
If for all applets the tests cases include an analog or digital sample of some signals then the applets are tested against that all the time and make it a requirement for third party applets contribution to ease maintenance, sounds good to me, so that if the contributor disappears there's still a way to know the applet works even if you don't have the hardware it's supposed to work with
<lle_bout[m]>
I think making an actual full simulation of glasgow is not very practical, just for purposes of CI and testing to cover some cases probably but that's it
<lle_bout[m]>
The simulations are not gonna be behaving exactly like hardware and no one cares about applets that work only with simulations (e.g. in CI), so I think samples from real hardware is better, you can always add more samples as you find hardware with different behavior causing bugs
<lle_bout[m]>
But the sample strategy works for read operations but not for writing, however
<whitequark[cis]>
it works for any operation, actually
<lle_bout[m]>
like if glasgow generate some signals to write to some NAND flash, how to test that glasgow generated proper signals the NAND flash will understand?
<whitequark[cis]>
read afterwardS?
<whitequark[cis]>
* read afterward?
<lle_bout[m]>
I mean, in CI
<lle_bout[m]>
without any hardware, glasgow or NAND flash chip
<whitequark[cis]>
sorry, I don't understand; the exact same record/replay mechanism for reads can be used for writes
<whitequark[cis]>
you verify the replay log
<lle_bout[m]>
Okay, since I don't even know how this replay thing works, I think we can postpone this discussion when I studied glasgow CLI more
<whitequark[cis]>
oh I figured out the infuriating caching issue
<whitequark[cis]>
it's because when GHA has a cache hit, it doesn't overwrite the key
<Attie[m]>
Seems they all say "Cache hit occurred on the primary key [...], not saving cache." to me?
<Attie[m]>
I'm struggling to see how this cache is useful - it's a one-time fill, many-times retrieve
<whitequark[cis]>
you use the source file hash as your primary key
<whitequark[cis]>
and if it doesn't find that it retrieves the most recent one with the same prefix
<whitequark[cis]>
it's ... weird
<Attie[m]>
but then you'll either end up with a new/empty cache (if any files change), or the cache won't be stored again (even if you run different paths, etc...)
<Attie[m]>
i think it's intended more as a "build" then "consume" process in the same pipeline(??)
<tpw_rules>
wow the case even came with the allen keys to put it together <3
<Attie[m]>
i wonder if these in combination may be more what we're after:
<tpw_rules>
is there a way to set the analyzer rate? i get a fifo overrun error after a little while
<whitequark[cis]>
<Attie[m]> "i wonder if these in combination..." <- no.
<whitequark[cis]>
the cache is the right thing to use here
<whitequark[cis]>
I'm fixing it up
<tpw_rules>
oh maybe because i was a bad boy and didn't turn on the pull resistors
<tpw_rules>
this thing is already awesome, very excited
<esden[cis]>
glad you got it and having fun with it tpw_rules :)
<esden[cis]>
And regarding allen wrench. I knew that if I don't include it it will be a problem for some people in all kinds of ways. Every time I get something that needs an allen wrench it comes with a wrench in most coses... even ikea furniture ... sooo I tried to clear the ikea furture bar.
<tpw_rules>
how does the bitstream caching work? i don't think nixpkgs patched that out
<tpw_rules>
ah it's a rather older version, ignore me