<cesar>
esden: to give arguments to a simulation process, we are using a wrapper, like this: https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/util.py;h=6f22179eff5ae8078d45f2a0b001a4f6f2045401;hb=HEAD#l44
<d1b2>
<esden> @cesar ok thank you. Creating a wrapper brings me further but then I am getting some "missing reset" errors not sure what that is about. :/
<d1b2>
<esden> will play with it bit more... let's see if I can figure it out
<d1b2>
<esden> @cr1901 ... useful heads up none the less 😄
<cr1901>
I do not know if I ran into a bug or something else though. pip lost its GD mind trying to uninstall nmigen via "pip uninstall nmigen". So I deleted the .egg-links manually
<whitequark>
okay, a few things here
<whitequark>
Degi: yes, you can do s/nmigen/amaranth/g s/NMIGEN/AMARANTH/g and have everything work fine
<whitequark>
cr1901: you don't need the nmigen pip package to be installed for imports to work
<whitequark>
there are compatibility shims that let you `import nmigen` if you have only amaranth installed
<cr1901>
whitequark: Ignore me, I'm a dumbass
<cr1901>
python -m "import nmigen" <-- of course that don't work
<cr1901>
python -c "import nmigen" works fine
<cr1901>
litex uses litex_setup.py as dependency management. I symlink the amaranth dep to a single copy of the amaranth repo. 1/2
<cr1901>
After I did "pip install -e ." in amaranth source tree, pip _did not like_ this at all, complaining that .egg-links were moved and/or "no files left to uninstall"
<cr1901>
when I tried uninstalling the stale nmigen packages
<whitequark>
yeah there's a pip bug somewhere there
<cr1901>
So I removed the .egg-links manually from /lib/python/site-packages/ and amaranth's source root
<cr1901>
I _thought_ this broke nmigen imports, but no... I just did python -m "import nmigen" to test, which is wrong
<cr1901>
False alarm
<cr1901>
whitequark: I summarized what to do in #litex, sorry for the false alarm
<cr1901>
I moved everything on my main laptop to amaranth w/o problems
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
emeb has quit [Quit: Leaving.]
bl0x has quit [Ping timeout: 250 seconds]
bl0x has joined #amaranth-lang
<_whitenotifier-e>
[amaranth] whitequark commented on issue #565: cxxsim: random garbage in memory traces - https://git.io/JDnn9
<_whitenotifier-e>
[amaranth] whitequark closed issue #565: cxxsim: random garbage in memory traces - https://git.io/JDnnH
<whitequark>
cesar: I'm finishing up a bunch of cxxsim work, would you be able to test the changes?
kbeckmann has quit [Ping timeout: 268 seconds]
<cr1901>
whitequark: Have you seen this yet on Debian? http://ix.io/3HMA Seems to be a pip bug, I'll find it
<cr1901>
Command line is: pip3 install --user --editable .
<cr1901>
* git branch -m master main (Idk when the main transition happened, but fixing it now)
<cr1901>
* git pull --set-upstream origin main
<cr1901>
* git remote set-head origin -a
<cr1901>
Then install for each of the amaranth repos
<cr1901>
Workaround for pip install woes is "python3 setup.py develop --user" if you don't need extras. I don't remember the syntax for adding the extras
<d1b2>
<Qyriad> Honestly I've just gotten used to setting $PYTHONPATH to avoid all of these issues in the first place
<cr1901>
PYTHONPATH scares me. YMMV
<tpw_rules>
is there a plan to make a stable release anytime soon?
<whitequark>
yes
<whitequark>
the current major blocker is cxxsim
<tpw_rules>
is this a day, week, or month problem? wanted to know when it was appropriate to distros
<tpw_rules>
appropriate to update distros*
Lord_Nightmare has joined #amaranth-lang
<whitequark>
month
<whitequark>
you know, it may actually be appropriate to release 0.3 soon and bump cxxsim to 0.4
<tpw_rules>
i think that would be better if the next version is still a month away. people who want something stable can get the name change now
<cr1901>
^I don't use stable, but I second this idea
<cr1901>
There was someone who I went to uni with who was interested in nmigen (completely independent of me, I might add). I should reach out and let him know of the name change
<tpw_rules>
i think it would also be good to add transition guidelines to the readme. are there compatibility modules for amaranth-soc and amaranth-boards?
<whitequark>
boards, yes. soc, not currently
emeb_mac has quit [Quit: Leaving.]
<d1b2>
<TheManiacalLemon> Are there any plans to make more fundamental changes under the hood with the rebranding now that there's no name-relation to migen? I don't know how much of the compatibility layers affected the overall design considerations
<whitequark>
none that weren't there before
<_whitenotifier-e>
[amaranth-boards] esden opened pull request #187: icebreaker-bitsy: Increase the programming routine flexibility. - https://git.io/JDnp1
<_whitenotifier-e>
[amaranth-lang/amaranth-boards] whitequark pushed 1 commit to main [+0/-0/±1] https://git.io/JDnhW
<d1b2>
<widlarizer> Is it possible to have simulation-only signals? That can be driven from anything can't drive signals other than sim-only? Could this be implemented through a magic domain with this driving rule?
<lofty>
@widlarizer: you know how the elaborate() function takes a platform argument that's normally unused? Well, in a sim this is always None (IIRC?), so you can use `if platform is None:` for those signals.
<d1b2>
<widlarizer> That's going to turn into a bit of boilerplate, but it will do for my usecase. Though as you build your design in sim it won't have the guarantee that it won't break your design when the signals are removed outside of sim - that would reuqire a signal subclass or magic domain
<d1b2>
<widlarizer> I mean nMigen checks a bunch of things at elaboration time, right, it could do this too
<d1b2>
<bob_twinkles> Python already does that check for you if you use the if platform is None: initialize_test_sigs() approach I think, the test-only signals will either be completely out of scope or None during real-hardware elaboration