ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting July 27th
emeb has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
emeb has quit [Client Quit]
Ekho has quit [Ping timeout: 256 seconds]
Ekho- has joined #nmigen
Ekho- is now known as Ekho
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
jfng has quit [*.net *.split]
Cynthia has quit [*.net *.split]
cesar[m] has quit [*.net *.split]
gravejac has quit [*.net *.split]
bubble_buster has quit [*.net *.split]
sorear has quit [*.net *.split]
jfng has joined #nmigen
cesar[m] has joined #nmigen
sorear has joined #nmigen
bubble_buster has joined #nmigen
Cynthia has joined #nmigen
gravejac has joined #nmigen
nurelin has quit [Remote host closed the connection]
Guest80879 has quit [Write error: Connection reset by peer]
cesar[m] has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
cesar[m] has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
emily has joined #nmigen
jfng has joined #nmigen
nurelin has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
hitomi2505 has joined #nmigen
jeanthom has joined #nmigen
<MadHacker> The wonders of python. You can do nearly anything, but you may regret doing so. :)
<whitequark> DaKnig: to add to what ktemkin said, there are a few implicit protocols that python will check your objects against
<whitequark> for example, something that implements __len__ and __getitem__ becomes an iterable even if it doesn't implement __iter__
proteus-guy has joined #nmigen
<whitequark> python is a bit odd in that the __dunder__ methods are *mostly* just ordinary methods that syntax desugars into, but some of them are genuinely special in complex ways
<whitequark> for comparison, ruby has very little such behavior. lots of the names are effectively reserved (... in the very same namespace where your own names go, sigh) because they're a part of an ubiquitous contract, but the behavior of the methods is effectively unrestricted
<whitequark> python will complain if you return a value from __init__; in ruby you can override any part of the class machinery you want and replace it with complete nonsense and it'll do its best
hitomi2505 has quit [Read error: Connection reset by peer]
hitomi2505 has joined #nmigen
<MadHacker> I don't remember python doing that historically; I wonder when that check got introduced. I've definitely made that mistake before.
<MadHacker> It's a good improvement.
<whitequark> i think dunder methods are fascinating
hitomi2506 has joined #nmigen
<whitequark> it's an amalgamation of formal and informal
<whitequark> they look almost pure convention, but behave in complex ways
hitomi2505 has quit [Ping timeout: 264 seconds]
<MadHacker> Truly. One of my friends did his PhD on the use of clifford algebras to represent spacetime, and he ended up building a whole python implementation of clifford algebra just by abusing __coerce__ really heavily.
<whitequark> *huh*
<whitequark> wait, what's __coerce__
<whitequark> oh i see it's deprecated
<MadHacker> Historical. Doesn't exist any more.
<MadHacker> Given two numerical(hah!) types, coerces them into the same type.
<MadHacker> The various __op__ methods were less flexible at the time.
<MadHacker> In context, it enabled things like adding an integer to a complex (e.g. literal complex number or quaternion or similar) object and vice-versa in a sane-ish way.
jeanthom has quit [Ping timeout: 256 seconds]
<whitequark> right, i figured
<MadHacker> http://theses.gla.ac.uk/74219/1/10800611.pdf page 79 section 3.4.4 justifies it, but it's entirely historical. Anyway, yeah, dunder methods are fundamentally intriguing for letting you do weird things to the nature of the language.
proteus-guy has quit [Ping timeout: 256 seconds]
Asu has joined #nmigen
chipmuenk has joined #nmigen
<anuejn> whitequark: re the soc discussion:
<anuejn> we came up with a "callback based" approach
<anuejn> where we just have a generic bus slave (that could be part of any bus) that gets two functions which insert logic into the read / write paths of that bus
<anuejn> it has several downsides but maybe it is a source of inspiration
<whitequark> hm, I think I need more context for that
<whitequark> (who "we"?)
<whitequark> ohhh
<anuejn> one downside is that the logic of the peripheral ends up in the wrong elaboratable
<anuejn> one upside is that you can make simple peripherals fully bus agnostic
<anuejn> (there is also quite some wired fiddeling with the platform going on, but that is not the thing i wanted to show here
jeanthom has joined #nmigen
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JJubc
<_whitenotifier-b> [YoWASP/yosys] whitequark a092b8f - Update wasmtime.
<_whitenotifier-b> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2] https://git.io/JJuxn
<_whitenotifier-b> [YoWASP/nextpnr] whitequark 301956c - Update wasmtime.
<lkcl__> whitequark: ping, NLNet MoU signed, you can submit an RFP for the cxxsim work, yay! i've sent you a template email to forward on to NLNet.
<lkcl__> we can follow up with _another_ RFP for bug-fixing cxxsim later btw :) there's an additional EUR 3000 available for you should you want it (and some other "spare" place-holders as well in places) https://bugs.libre-soc.org/show_bug.cgi?id=362
electronic_eel has joined #nmigen
<jeanthom> Why are we constrained to 8/16/32/64 for the data widths in nmigen-soc?
<jeanthom> Is this part of the wishbone spec?
<lkcl__> jeanthom: yes. wishbone cannot go above 64 bit.
<lkcl__> in libre-soc we'll need *FOUR* 64-bit wishbone Data paths down to L1, L2 and to memory, just to keep the GPU fed.
<lkcl__> and that's the *small* version! it's completely mental.
<lkcl__> WB4 spec "3.5.3 Data Organization for 64-bit Ports"
<lkcl__> 3.5.4-3.5.6 cover 32/16/8 - there's no 128 or 256 bit.
<lkcl__> hey cole updated the diagram. nice! https://libre-soc.org/3d_gpu/architecture/memory_and_cache/
<zignig> ktemkin: ping
<lkcl__> jeanthom: you can see from that diagram, we've had to "stripe" memory, firstly into odd/even 128-bit (separate) L1 caches and *may* actually have to divide into *four* independent (striped) L1 64-bit caches
<zignig> I am trying to put the LUNA acm interface into a FIFO and i'm not sure what to do with the first,last. do I need a state machine to flip the frame ?
<lkcl__> each would be addressed by bits 4-5 of the incoming memory request.
<lkcl__> jeanthom: hope this insight helps.
<DaKnig> @whitequark I really cant find the best lang for me . C is very simple so this means theres very little hidden assumptions and you know *exactly* what + does without looking at many lines of documentation and code. tats my fav lang. C++ does the operator overload stuff better than python imo- you can overload `operator+` for any two input types, so you can overload `operator[]` for `std::list,nmigen::Value`.
<DaKnig> this would have been nicer here. the problem is, tho, C++ takes like 3x more code to do anything compared to python...
<DaKnig> either give up ease of writing or being able to be more explicit and override more behaviors
<jeanthom> lkcl__, hi, yup that answers my question
<agg> DaKnig: what do you want to do in python? it's famously pretty generous with types, so while you can't just extend the behaviour of a list for all lists, lists can add anything that can be an interator, so it's not hard to make a custom type that can be added to a list
<agg> or conversely to make a thing that looks like a list, can be used like a list, but supports adding weird things
<agg> e.g. in nmigen `m.d.sync += a.eq(b)` works and so does `m.d.sync += [a.eq(b), b.eq(c)]`
<DaKnig> yeah python is very relaxed with types, and sometimes you can add features to specific instances of a class
<DaKnig> as opposed to adding them to the whole class
hitomi2506 has quit [Ping timeout: 246 seconds]
hitomi2506 has joined #nmigen
hitomi2507 has joined #nmigen
hitomi2506 has quit [Ping timeout: 240 seconds]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb has joined #nmigen
chipmuenk has joined #nmigen
<_whitenotifier-b> [nmigen] jeanthom opened issue #453: submodules are allowed inside If blocks - https://git.io/JJznm
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk has joined #nmigen
<FL4SHK> Now making a Binutils port for my CPU
<FL4SHK> I decided to just make a Binutils port because I wanted to be able to make GCC work
<FL4SHK> that and GDB
<FL4SHK> thinking of making some addresses be non-cached
<FL4SHK> probably like 0x0 to 0x3ffff
<FL4SHK> but might do 0x0 to 0xfffff
<FL4SHK> plenty of room for MMIO if I do that
<jeanthom> how wide is your address bus?
<FL4SHK> 32-bit
<FL4SHK> I don't want to just say to set the top bit of an address to 1 to say it's not cached
<FL4SHK> that halves the size of the address space
<FL4SHK> 32-bit addresses, 32-bit CPU
<jeanthom> I was about to suggest that
<FL4SHK> I might be dealing with GBs of RAM at some point
<jeanthom> Do you have a CPU instruction to clear caches?
<FL4SHK> not currently...
<FL4SHK> the machine doesn't have any supervisor mode
<FL4SHK> it does have interrupts
<FL4SHK> I have yet to develop a processor with a real supervisor mode
<d1b2> <emeb> How... egalitarian.
<FL4SHK> I don't even know what that word means
<emeb> equal rights
<FL4SHK> with that definition, I have no idea what you mean
<emeb> all processes are equal in the eyes of the CPU
<FL4SHK> no support for multiple processes, really, for this machine
<FL4SHK> unless you count the interrupts support
<FL4SHK> it does support those
<FL4SHK> but they're not supported via a supervisor mode of any sort
<emeb> well I suppose you could do software based context switching
<FL4SHK> yeah, but the machine isn't really intended for that.
<FL4SHK> just like all the other CPUs I've developed.
<FL4SHK> It's not intended to run an OS, either
<jeanthom> FL4SHK, How hard it is to port binutils to a new arch?
hitomi2507 has quit [Read error: Connection reset by peer]
hitomi2507 has joined #nmigen
<Lofty> I think the next meeting date should be updated, whitequark
<FL4SHK> jeanthom: it doesn't seem hard
<FL4SHK> I've done it before
<FL4SHK> it's just been three years since I did so
<FL4SHK> I'm doing it in advance of making a GCC backend for this target
<FL4SHK> I've built a GCC backend before, but there was no corresponding Binutils for that target
<FL4SHK> that target also didn't have the most optimized GCC backend
<FL4SHK> also, here is a new project I want to work on
<FL4SHK> nMigen simulations on the GPU
<FL4SHK> I don't know how to make the memory access pattern fast
<FL4SHK> so I might try simulated annealing.
<FL4SHK> I want GPUs to serve as a hardware implementation method over FPGAs
<FL4SHK> I have previously worked on such a thing
<FL4SHK> but I never got the memory access patterns to be fast enough.
<FL4SHK> the simulations only ended up being about twice as fast on the GPU IIRC
<jeanthom> What API are you using for GPGPU simulations? OpenCL? CUDA?
<FL4SHK> I *was* using CUDA for it
<FL4SHK> again, never really got it going as fast as it needed to be
<FL4SHK> I think I want to use OpenCL now
<daveshah> GPU simulations are ideal for the case of running a number of different vectors in parallel through a simple design
<FL4SHK> GPUs can be really, really fast if they have the right memory access patterns
<lkcl__> FL4SHK: doing binutils first is very sensible. you can then write assembly code and test that out, first, before getting gcc to then generate .S assembly listings
<FL4SHK> I've done it in reverse order before, actually
<FL4SHK> just without making the Binutils prt
<FL4SHK> Here's what I did: examined the assembly output
<FL4SHK> I'm likely to do that again even if a Binutils port exists for the machine
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
hitomi2507 has quit [Read error: Connection reset by peer]
<DaKnig> FL4SHK: you can just have an interrupt (timer based? or something more complex) that switches in a list of processes and such
hitomi2507 has joined #nmigen
hitomi2507 has quit [Read error: Connection reset by peer]
hitomi2507 has joined #nmigen
hitomi2507 has quit [Ping timeout: 240 seconds]
hitomi2507 has joined #nmigen
<emeb> Interesting - tried creating a Memory to use as a ROM with init data generated via some math using numpy. Synthesis worked fine, but simulation failed. Falling back to ordinary arrays for the init data and simulation works.
<agg> assuming your init is an array, does .tolist() (or wrapping in list()) fix it?
<agg> mmm, it seems like it shouldn't make a difference as Memory's init setter wraps the new value in list() anyway
<emeb> neither data.tolist(), or data = list(data) fixes issue
<agg> what dtype is the numpy array?
<emeb> numpy.int
<emeb> code for the curious: https://pastebin.com/rLfLn5zh
<agg> won't that numpy call return a float?
<emeb> I guess it does.
<agg> oh, sorry, I missed that data is an np array in the second case
<agg> i still had the [0]*len in my head
<emeb> still not clear about all the details of python type conversion
<agg> this should be ok, the only scope for weirdness is that the list nmigen ends up with contains np.int16 types instead of ints
<emeb> but wrapping the expression in int() doesn't help
<agg> no, because it's converting to an np.int64 when it gets saved to data
<agg> if you had data=[0]*sine_len and also used int(np.floor(...)), you should end up with a regular list of integers, but
<agg> nmigen does already do a conversion to integer on each member of the list, so it's not clear why that should really make a difference
<agg> (np.pi exists, incidentally)
<emeb> cool
<agg> i'm sure i've passed an np array into memory init before, for a rom, but it was quite a while ago...
<emeb> yeah. very odd that synthesis and simulation don't behave the same
<agg> it's not too surprising as memory has a lot of machinery specifically for simulation
<emeb> full traceback: https://pastebin.com/sLV23Rqh
<agg> what is the nature of the simulation failure?
<agg> ah, should have asked that question earlier, heh
<emeb> what you see there in the paste above
<emeb> then it stops
<emeb> with a zero-length .vcd file
<awygle> oh good my cygwin python install is _completely_ fucked on this machine. wonder how that happened lol
jeanthom has quit [Ping timeout: 240 seconds]
<awygle> yknow, one of the best things about nmigen is that when it tells you what you meant to do, it's generally correct. none of this "you should run python -m pip" "no module pip" nonsense
<awygle> so to initialize BRAM, i need a Memory object with a big init= list, and i can just populate that from the normal Python "read in from file" infrastructure. yes?
<agg> emeb: how weird. it looks like you have a slightly old 'vcd' python library version, but the changes don't look material; it looks like the error happens when the value is not an integer type, but it prints 129 which obviously is an integer; notably an np.int64 will fail its integer-type-check but nmigen converts the values to ints, and has done since june last year, so... ???
<agg> it might be worth updating vcd just in case i guess. did using a list of plain ints help?
<agg> awygle: yes
<awygle> cool
<agg> awygle: honestly it's one of the best things, so much of my code generates the rom contents in python at runtime (elaboration-time?)
<emeb> agg: very interesting. wonder if I should update my vcd lib?
<agg> e.g. building font tables from an otf file, computing CRC lookup tables, saving build date and git version into a rom, that sort of thing
<awygle> gotta resist the urge to loop a whole mips assembler/c compiler into my nmigen infrastructure :p
<emeb> or building a wavetable ;)
<agg> exactly! I had a really compact DDS synth
<agg> but now i can't find it
<emeb> messy workbench - stacks of githubs everywhere.
<awygle> every workspace in my life is a mess, from my actual desk to my computer desktop to the hundreds of open tabs to my Github to my kitchen :p
<agg> oh yea it was on imgur (???) https://imgur.com/a/hXYbh
<agg> anyway like 15 lines of migen for an NCO with phase, frequency, and amplitude modulation
<emeb> nice
<agg> but this is omigen (note self.specials and self.comb)
<agg> probably be even fewer loc in nmigen :p
hitomi2507 has quit [Read error: Connection reset by peer]
<agg> very cute and worked really well though
<emeb> there are many ?migens
<agg> (notably it also took an nmigen array for init)
hitomi2507 has joined #nmigen
<agg> did using a list and wrapping the numpy call in int() work, btw?
<awygle> wow that's a really clean output too
<agg> awygle: it was feeding this 100MS/s 14-bit DAC https://imgur.com/a/lLyca
<agg> it turns out you can get silly sample rates with simple parallel connections for no money at all these days
<agg> the board also has a 100MS/s (or 200?) 2-channel ADC
<agg> 10 bits
<emeb> agg: neither list() nor int() helped
<awygle> what's that siglent, a scope or a specan?
<emeb> but upgrading vcd causes a new and different failure
<agg> emeb: sorry, I meant, using "data=[0]*sine_len" instead of np.zeros, and then using int(np.floor(...)) when you assign to it
<awygle> i guess it's a scope in FFT mode...
* emeb scowls at the house of cards that is python
<agg> that way the `data` you pass to memory.init should be exactly a regular list of integers
<agg> awygle: both
<awygle> ah ok
<agg> the scope captures are a siglent scope, the specan are a signeltn specan :p
<awygle> i thought it looked like my SSA3021X
<awygle> but then some of it was clearly a scope lol
<agg> sds 1202x-e and ssa3021x indeed
<awygle> i went with the DS1054Z for my scope
<agg> ssa30"2"1x anyway
<awygle> seems to be six of one half dozen of the other, except the Siglent has a nicer screen :p
<agg> yea
<agg> i got a sds 1104x-e at work for throwing around and it's nice and cheap, i think today it's a better shout than the somewhat old ds1054z
<awygle> i feel bad for my SSA3021X, when i got it it was used every day and i haven't turned it on in more than 2 years
<agg> still the 2ch siglent plus external trigger in was enough to debug and implement an sdram controller
<agg> albeit by painstakingly sampling the same trigger 3 times to get 6 channels
<agg> same... i was doing loads of rf at the time and haven't touched it in ages
<agg> it's now a stand for my video conferencing laptop on my other desk
<agg> (thinkpad is the only thing with a webcam)
<awygle> for me it's a nice way to waste 4U of rack space
<agg> mine has been demoted from the rack :P
<awygle> it might make a comeback soon to do some pre-compliance emi stuff
<awygle> that'll be fun
<awygle> gotta find my near-fields tho
<emeb> agg: interesting - just did some upgrades on my packages and started getting a slightly different error
<agg> emeb: ooh, do paste
<emeb> ValueError: vector init value must be int, bool, str, or None
<emeb> so now it's a bit more specific
<agg> presumably that's still coming from vcd?
<emeb> and I tried the change you suggested and that fixed it.
<agg> i'd be deeply unhappy if that change didn't fix it
<agg> but nevertheless an array of numpy ints should be just fine
<emeb> so something about the numpy.int that it didn't like?
<agg> awygle: except now i'm jealous of all the people buying the new models with vector demodulation, constellation analysis, built in VNA, etc
<awygle> yeahhhhhhhhh no kidding. i have zero need for a VNA, but... want.
<miek> here i am not used to seeing a specan that doesn't have a CRT :p
<agg> it's annoying just because again the base model can be upgraded to do all that, and if i was buying it today instead of in 2017 i'd have got that, but
<agg> impossible to justify buying a new one again especially given i'm barely using it
* emeb is very happy with his sds1104x-e
<awygle> i did get the TG
<awygle> i wonder if the rest of that is software
<agg> i have an old tank agilent e4406a "transmitter tester" which can do vector demod but it's a chore to do useful things that aren't gsm analysis
<awygle> i think the last time i used mine was to do noise figure analysis on an LNB
<emeb> my e4402b specan just keeps running. I had to replace the Dallas CMOS battery a few years ago tho
<agg> slightly more 'industrial' GUI than the siglent, for sure https://imgur.com/a/kfyrq
<emeb> looks very familiar
<emeb> note to self - get the screen capture utility ported to linux.
<agg> is yours on the network?
<emeb> no - mine only has RS-232 port
<agg> ah, shame
<agg> does it do SCPI over that?
<miek> my scope's got a little web server that you can grab a screenshot from, it's great
<agg> i have a python script for screen capture over scpi (over tcp socket in this case) https://dpaste.com/FU55KP4PB
<emeb> Dunno - I've got a usb/serial dongle on a windows box that runs a little cmd utility I wrote years ago to do screen captures
<agg> miek: yea, it's all about network screen capture of everything
<emeb> miek: that amalthea board is yours?
<miek> emeb: yeah
<emeb> nice work. Was looking at that RF chip you're using last night. I/Q mode is handy.
<miek> thanks! yeah, it's a really neat chip. i've been wanting to do something with it for years - finally all fell into place :)
<emeb> amazingly inexpensive for what it does. Too bad that the sub 1GHz LO has so few bands though.
jeanthom has joined #nmigen
<awygle> "amalthea" is a good name
<awygle> sort of independent from what it's the name of
<awygle> just sounds pleasant
<agg> emeb: I think i've probably tracked down the bug... if you create the memory read port with transparent=true does it fix it?
<emeb> agg: that doesn't seem to help
<agg> sorry, transparent=False
<agg> (true is the default)
<emeb> still fails.
<agg> huh... i get the exact same error as you with transparent=True and it goes away with transparent=False
<agg> that's an argument to read_port(), right?
<agg> could you try this test script and see what happens for you with transparent true/false on line 16? https://dpaste.com/497FKR3QQ
<emeb> OK - bad syntax for my transparent=
<emeb> with False it works
<emeb> I tried false -> no worky
<emeb> so then tried "False" which also didn't work but didn't complain about the argument
* emeb is still learning python
<miek> when you tried casting the init values to int, how did you do it? can you paste some code?
<_whitenotifier-b> [nmigen] adamgreig opened pull request #454: Cast reset value for transparent read ports to integer - https://git.io/JJzV0
<emeb> miek: line 24 here -> https://pastebin.com/xVEf6ccR
<miek> ah, i think that'll end up casting back to np.int as that's still the array type
<emeb> yes - that made no difference
hitomi2507 has quit [Ping timeout: 246 seconds]
<emeb> agg: so I guess that was a real bug, not just me being a n00b. :)
<agg> yep
<agg> you might find you do want transparent=False anyway though, especially for a ROM
<agg> (well... maybe it will specifically make no synthesis difference for a ROM, actually...)
<miek> emeb: what if you do `init = map(int, data)` for line 28?
<emeb> agg: OK - that was my first exposure to Memory() and I was just guessing what to do.
<emeb> didn't even know about transparent - out of curiosity, what's the best way to find out all the options for these? Is it written down somewhere or is it best to go to the source?
<agg> miek: given the bug (see pr ^) i'm sure that map would fix it
<agg> emeb: in a python shell, import nmigen; help(nmigen.Memory), is a good start
<emeb> agg: nice. kinda like matlab doc <foo>
<agg> i suspect at some point the online docs will include those docs, or otherwise include memory related docs, but they don't yet
<agg> the source has the same docs but various things in nmigen generate those docs at runtime by pasting together other docs, so using the built in help can be more convenient
<miek> ah right, missed that
<emeb> miek: yes, that works.
<_whitenotifier-b> [nmigen] adamgreig commented on pull request #454: Cast reset value for transparent read ports to integer - https://git.io/JJzwa
hitomi2507 has joined #nmigen
<emeb> interestingly, no detail on Memory.read_port() arguments
hitomi2507 has quit [Read error: Connection reset by peer]
hitomi2507 has joined #nmigen
FL4SHK has quit [Ping timeout: 264 seconds]
Asu has quit [Remote host closed the connection]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 256 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined #nmigen
FL4SHK has joined #nmigen
<ktemkin> awygle: re: Amalthea's name: we're naming all the LUNA-derived boards after moons :)
<awygle> nice :)
* emeb waits for Mimas
<awygle> don't forget 1985 U 1, the best moon name ever
<ktemkin> miek: Amalthea was a good choice; it's apparently only two spaces from the Jupiter Space Dock~
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
<emeb> shorter grocery runs?
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
<miek> lol, that's a very niche reference
<awygle> i used to love that game
_whitelogger has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]