| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Read error: Connection reset by peer) | 00:21 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 00:37 | |
| *** Degi_ <[email protected]> has joined #litex | 01:52 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 01:52 | |
| *** Degi_ is now known as Degi | 01:52 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 02:42 | |
| *** TMM_ <[email protected]> has joined #litex | 02:42 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 07:01 | |
| *** RaYmAn <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 08:19 | |
| *** lexano <[email protected]> has joined #litex | 12:38 | |
| *** RodolfoAzevedo <RodolfoAzevedo!~RodolfoAz@2801:8a:c811:1:ec78:31b6:35ff:a9f5> has joined #litex | 13:19 | |
| *** _whitelogger <[email protected]> has quit IRC (Remote host closed the connection) | 13:21 | |
| *** _whitelogger <[email protected]> has joined #litex | 13:23 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 13:30 | |
| *** TMM_ <[email protected]> has joined #litex | 13:31 | |
| *** RodolfoAzevedo <RodolfoAzevedo!~RodolfoAz@2801:8a:c811:1:ec78:31b6:35ff:a9f5> has quit IRC (Quit: Client closed) | 16:07 | |
| *** RodolfoAzevedo <RodolfoAzevedo!~RodolfoAz@2801:8a:c811:1:ec78:31b6:35ff:a9f5> has joined #litex | 16:27 | |
| RodolfoAzevedo | Hello. I am having trouble using litex. I followed the install procedures and everything went fine. After that, I tried to execute the board demo (tang_nano_9k.py) and it complained: ModuleNotFoundError: No module named 'litex' | 16:27 |
|---|---|---|
| RodolfoAzevedo | Hello. I am having trouble using litex. I followed the install procedures and everything went fine. After that, I tried to execute the board demo (tang_nano_9k.py) and it complained: ModuleNotFoundError: No module named 'litex' | 16:27 |
| RodolfoAzevedo | I followed the tutorial from here: https://github.com/enjoy-digital/litex/wiki/Installation | 16:28 |
| josuah | Hello RodolfoAzevedo! Did anything go wrong with this command? ./litex_setup.py --init --install | 16:32 |
| josuah | This is what was expected to install the various modules. | 16:32 |
| josuah | It will install everything to the current directory, so you might want to create a ./litex/ directory first | 16:32 |
| josuah | and then: cd litex | 16:33 |
| josuah | and then: ./litex_setup.py --init --install | 16:33 |
| RodolfoAzevedo | I added the --user option and it went fine | 16:33 |
| josuah | nice! | 16:33 |
| RodolfoAzevedo | I created litex, cd to it. | 16:33 |
| RodolfoAzevedo | and the --user in the command line: ./litex_setup.py --init --install --user | 16:34 |
| RodolfoAzevedo | without --user it does not work | 16:34 |
| josuah | what does this give to you? python --version | 16:35 |
| RodolfoAzevedo | python3 --version | 16:35 |
| RodolfoAzevedo | Python 3.8.6 | 16:35 |
| RodolfoAzevedo | python --version | 16:35 |
| RodolfoAzevedo | Python 3.11.4 | 16:35 |
| RodolfoAzevedo | I have oss_cad_suite installed | 16:35 |
| RodolfoAzevedo | with python3 | 16:35 |
| josuah | oh, it looks like you have different python versions running around here | 16:35 |
| RodolfoAzevedo | should I install litex outside it? | 16:35 |
| josuah | python -m litex | 16:36 |
| RodolfoAzevedo | the 3.8.6 is oss_cad_suite version, the 3.11.4 is systemwide | 16:36 |
| josuah | python3 -m litex | 16:36 |
| josuah | do these two give you different result? | 16:36 |
| josuah | You are expected to get the same error message about 'litex' is a package and cannot be directly executed | 16:36 |
| RodolfoAzevedo | both give error, | 16:36 |
| RodolfoAzevedo | No module named litex | 16:37 |
| josuah | you might have to use the same python implementation that installed litex | 16:37 |
| josuah | which operating system is it/ | 16:37 |
| josuah | s,/,?, | 16:37 |
| RodolfoAzevedo | I am using ubuntu 23.04 | 16:37 |
| RodolfoAzevedo | it has that new thing on pip | 16:38 |
| RodolfoAzevedo | I can not pip to install | 16:38 |
| RodolfoAzevedo | (I think) | 16:38 |
| josuah | it tells you something about virtualenvs? | 16:38 |
| josuah | "This environment is externally managed" | 16:39 |
| RodolfoAzevedo | yes, pip complains about messing the system. It recommends using pipx | 16:39 |
| RodolfoAzevedo | Am I supposed to install outside any virtualenv or other environment? | 16:40 |
| somlo | I might be late to the party, and y'all have likely gotten it all figured out; but `--user` will install (links to) your litex & friends' python modules in ~/.local | 16:40 |
| somlo | *not* using `--user` will try (and likely fail) to install everything system-wide | 16:40 |
| RodolfoAzevedo | side note: I did it two months ago and it worked (even configured my board) | 16:40 |
| josuah | somlo: which might not work anymore as per python EXTERNALLY_MANAGED flag enabled for the system python, AFAIK | 16:41 |
| josuah | RodolfoAzevedo: what is the error message when trying to use pip? | 16:41 |
| RodolfoAzevedo | × This environment is externally managed | 16:41 |
| RodolfoAzevedo | ╰─> To install Python packages system-wide, try apt install | 16:41 |
| RodolfoAzevedo | python3-xyz, where xyz is the package you are trying to | 16:41 |
| RodolfoAzevedo | install. | 16:41 |
| RodolfoAzevedo | If you wish to install a non-Debian-packaged Python package, | 16:41 |
| RodolfoAzevedo | create a virtual environment using python3 -m venv path/to/venv. | 16:41 |
| RodolfoAzevedo | Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make | 16:41 |
| RodolfoAzevedo | sure you have python3-full installed. | 16:41 |
| RodolfoAzevedo | If you wish to install a non-Debian packaged Python application, | 16:41 |
| RodolfoAzevedo | it may be easiest to use pipx install xyz, which will manage a | 16:41 |
| RodolfoAzevedo | virtual environment for you. Make sure you have pipx installed. | 16:41 |
| RodolfoAzevedo | See /usr/share/doc/python3.11/README.venv for more information. | 16:41 |
| josuah | somlo: to be honest, I am surprised that the python community did not want to tolerate per-use packages and pushes everyone to use virtualenvs for everything. | 16:42 |
| RodolfoAzevedo | I tried again as fresh install without oss_cad_suite environment | 16:42 |
| whitequark[cis] | per-use packages? do you mean pypackages? | 16:43 |
| whitequark[cis] | s/pypackages?/`__pypackages__`?/ | 16:43 |
| josuah | whitequark[cis]: that is the cure to the problem! ^_^' | 16:43 |
| whitequark[cis] | I'm just unsure what "per-use packages" are | 16:43 |
| josuah | I think per-user packages as ~/.local, the `--user` flag to pip | 16:43 |
| whitequark[cis] | oh, per-user, not per-use | 16:44 |
| josuah | whitequark[cis]: I wish PEP 582 was adopted https://peps.python.org/pep-0582/ | 16:44 |
| tpb | Title: PEP 582 – Python local packages directory | peps.python.orgSelected dark colour schemeSelected light colour scheme (at peps.python.org) | 16:44 |
| somlo | I'm still using the ~/.local stuff installed (a long time ago) with `--user` on fedora; updating litex repos from git works fine as long as all the ~/.local stuff is still there | 16:44 |
| josuah | oh my bad, typo of mine! | 16:44 |
| whitequark[cis] | josuah: the problem is that if you have a global system binary, e.g. `/usr/bin/systemapplication`, and it uses Python, it will pick up both Python packages from `/usr`, as well as from `~/.local` | 16:44 |
| somlo | I get the occasional need to re-install when python versions change and the directory name under ~/.local goes obsolete | 16:44 |
| whitequark[cis] | this means that if LiteX installs some random dependency of it into ~/.local, it can break completely unrelated system packages | 16:45 |
| somlo | maybe ubuntu and other distros are getting more prickly with their python setups, dunno about that | 16:45 |
| whitequark[cis] | and I actually had this happen multiple times on my system, it is a PITA to debug | 16:45 |
| josuah | RodolfoAzevedo: you might need to lear about virtualenvs. I use python's venv or pdm (thanks to whitequark[cis]). | 16:45 |
| RodolfoAzevedo | I had it working two months ago. then I decided to use it in a course I am teaching this semester. | 16:46 |
| RodolfoAzevedo | I will look to virtualenvs | 16:46 |
| RodolfoAzevedo | thanks! | 16:46 |
| josuah | this likely came all of a sudden with a python update, maybe an automated one | 16:46 |
| somlo | I only have the litex stuff in ~/.local, any non-litex "dependencies" are installed as distro packages (I am a fan of distro packages, if I haven't made that clear enough in the past :P ) | 16:46 |
| josuah | RodolfoAzevedo: crash course: cd ~/litex; python -m .venv; . .venv/bin/activate | 16:47 |
| whitequark[cis] | josuah RodolfoAzevedo: you could use PDM to simplify venv management, this is what we do in Amaranth | 16:48 |
| whitequark[cis] | you can see a simple PDM setup here: https://github.com/amaranth-lang/template-fpga | 16:48 |
| josuah | RodolfoAzevedo: that is for creating a virtual environment, and then you'd be able to use it with just `cd ~/litex; . .venv/bin/activate`, that is the rawest possible venv | 16:48 |
| whitequark[cis] | the pyproject.toml is sufficient: https://github.com/amaranth-lang/template-fpga/blob/main/pyproject.toml | 16:48 |
| whitequark[cis] | the main utility of using PDM is that you can check the lockfile, containing the actual solved package versions, into VCS, and have reproducible installs | 16:48 |
| josuah | whitequark[cis]: do you use `__pypackages__` with them? | 16:49 |
| whitequark[cis] | josuah: no, venvs only | 16:49 |
| whitequark[cis] | __pypackages__ PEP was rejected so I do not use them | 16:49 |
| whitequark[cis] | venvs are standard | 16:49 |
| josuah | thanks! this makes sense | 16:50 |
| RodolfoAzevedo | thank you. I will follow these tips | 16:50 |
| josuah | nice! https://github.com/amaranth-lang/template-fpga/blob/main/pyproject.toml#L17 | 16:50 |
| josuah | RodolfoAzevedo: https://pdm.fming.dev/latest/ this is the PDM it is all about | 16:50 |
| tpb | Title: Introduction - PDM (at pdm.fming.dev) | 16:50 |
| RodolfoAzevedo | Amaranth is the new migen, right? Litex install still requires migen? | 16:56 |
| whitequark[cis] | LiteX is a fork of Migen, Amaranth is a new language borrowing from Migen's syntax | 17:02 |
| whitequark[cis] | I am linking you the example because it shows the use of PDM; I am not suggesting you use Amaranth (if you want to use LiteX, at the moment, it's not very useful to you) | 17:03 |
| josuah | related: https://github.com/enjoy-digital/litex/wiki/Migen-Amaranth | 17:12 |
| *** pbsds <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 17:31 | |
| *** pbsds <[email protected]> has joined #litex | 17:32 | |
| whitequark[cis] | note that the 2nd paragraph is currently being rethought | 17:38 |
| somlo | whitequark: "LiteX is a fork of Migen" -- maybe you meant "LiteX uses Migen" ? :) | 18:49 |
| somlo | or "is written in migen", or something :D | 18:49 |
| whitequark[cis] | I was fairly sure LiteX includes the source code of Migen and builds of it | 18:50 |
| whitequark[cis] | s/of/on/ | 18:50 |
| somlo | migen is a dependency of litex, perhaps one of those things you don't want installed in your ~/.local (fedora has it packaged as an "official" rpm) | 18:51 |
| whitequark[cis] | ohhh I see, LiteX stopped doing that, uh, many years ago apparently | 18:51 |
| whitequark[cis] | I think back in 2015 or so when I first encountered LiteX it did that and I think it got changed shortly after; my apologies for the confusion | 18:52 |
| whitequark[cis] | this is actually relevant to my work on having LiteX be Amaranth-compatible because I thought I'd be able to modify of the vendored-copy-of-Migen-sources-in-LiteX but I guess that won't be the case | 18:53 |
| somlo | 2015 was a bit before my time; so I understand what you're saying as "litex used to use a vendored/bundled version of migen, and it got unbundled in the mean time" or some such | 18:53 |
| whitequark[cis] | no, it was also renamed to be under the litex namespace | 18:53 |
| whitequark[cis] | this is functionally a fork | 18:53 |
| somlo | from where I'm looking at it, the problem is one of *porting* litex from migen to amaranth :) | 18:53 |
| somlo | it's like "rocketchip is written in chisel" === "litex is written in migen" (at least as of right now, no idea on how it evolved to be like that) | 18:55 |
| somlo | (and yeah, the rocketchip repo has a bunch of sub-repos pulling in chisel, sbt, and the kitchen sink, but that's neither here nor there :D :D) | 18:56 |
| whitequark[cis] | if rocketchip pulled in an entire copy of chisel and renamed it to be under "rocketchip" namespace I would consider that a fork of chisel, fwiw | 18:57 |
| whitequark[cis] | but since litex does not do that anymore (and I honestly have a hard time remembering exactly what happened a decade ago) none of this especially matters | 18:57 |
| whitequark[cis] | it would actually be easier if litex was 'written in litex', because then I would not have to consider doing questionable things like installing amaranth.compat under migen in the Python package namespace | 18:58 |
| somlo | whitequark: looks like one day in the near term future I might need to package https://github.com/amaranth-lang/amaranth as a fedora RPM (same as the way I have migen packaged currently) -- any death traps I should be aware of ? :) | 19:02 |
| whitequark[cis] | none I can think of | 19:02 |
| whitequark[cis] | you'll want to wait until the 0.4 release since most software is currently using a git checkout | 19:02 |
| whitequark[cis] | but this will change with the said release, which has many highly anticipated features | 19:03 |
| somlo | right, I'll most likely wait until litex can be viably built with amaranth as a dependency instead of migen | 19:03 |
| whitequark[cis] | I don't think you will see it built with amaranth instead | 19:04 |
| whitequark[cis] | neither me nor Florent have concrete plans for that | 19:04 |
| whitequark[cis] | instead, the current plan is to take the current amaranth.compat module out of Amaranth (it was deprecated since 2018) or even rewrite it so that LiteX could evaluate Amaranth as a replacement in a piecewise fashion instead of replacing the entire thing at once | 19:05 |
| whitequark[cis] | the reason is that LiteX has a lot of code and there is only one Florent, and it would take a lot of effort, more than can be spared, to revalidate literally everything on top of Amaranth | 19:06 |
| somlo | ok, maybe I misunderstood then -- the "amaranth.compat" module is what might end up as an alternative to today's "migen", then? | 19:06 |
| whitequark[cis] | no | 19:07 |
| whitequark[cis] | to try and clarify once again: I have no interest in maintaining amaranth.compat and I would like to remove it entirely. however LiteX is the largest potential user of amaranth.compat which was also precluded from using it due to certain technical constraints | 19:07 |
| whitequark[cis] | to align our interests, there is a plan to take amaranth.compat out of Amaranth proper, (perhaps to a separate repo, perhaps to LiteX), update it so that it does not have to be a part of upstream Amaranth, and let LiteX use it as Florent and the LiteX community see fit | 19:08 |
| somlo | oh so you're talking about litex *incorporating* amaranth.compat as a "glue layer" between litex (which expects things to look like migen) and amaranth (which can use amaranth.compat to *make things look like migen*) ? | 19:09 |
| whitequark[cis] | correct | 19:09 |
| somlo | I see; in that case, what I said: litex (post-amaranth.compat-assimilation, or whatever) will end up depending on amaranth instead of "old" migen | 19:10 |
| somlo | and then it will be possible to "viably build litex with amaranth instead of migen", and I will need amaranth to be a packaged rpm on fedora so I can do that without too much fuss :) | 19:11 |
| whitequark[cis] | yes. the misunderstanding there is that I thought you had envisioned some other use for Amaranth | 19:11 |
| somlo | I mean, once it exists as an rpm and someone installs it, they can do whatever *else* (besides litex) they want with it, I'm sure litex isn't the only thing it's for ;) | 19:15 |
| somlo | but thanks for helping clear things up, makes perfect sense in retrospect! | 19:15 |
| whitequark[cis] | no problem | 19:15 |
| cr1901 | Yea, LiteX was a fork from Migen/MiSoC, and has changed so much since then that it effectively its own unique ecosystem that uses Migen as a git dep. What about updating litex_setup.py to point to a different Migen repo? | 21:34 |
| somlo | cr1901: litex_setup.py assumes none of the "significant" dependencies are installed, and pulls them all in (including m-labs/migen). You wouldn't *want* to point it at another migen repo unless/until the amaranth.compat thing whitequark was talking about actually happens) | 21:47 |
| somlo | having a *packaged* systemwide install of m-labs/migen (like on Fedora) is a different thing (I just edit out the part of litex_setup.py that pulls in migen explicitly, since I already have it available locally) | 21:47 |
| cr1901 | Hmmm... I figured you could just rm -rf the existing migen repo and check out the new one. But I realize that actually breaks _my_ own setup as well where migen is a symlink to the copy I've kept around since 2015 | 21:50 |
| cr1901 | w/ all its history, branches, etc | 21:50 |
| somlo | m-labs/migen has slowed down *a lot* over the last few years -- there's the occasional maintenance commit (e.g. to support python 3.11), but what's in Fedora right now is practically equivalent to the current tip of the m-labs/migen git repo | 21:52 |
| somlo | admittedly, there *might* be a few things that changed since 2015 :) | 21:52 |
| somlo | and if you're not using fedora or simply run litex_setup.py, you essentially get the same thing | 21:53 |
| cr1901 | I'm a little bit surprised if a Litex design builds w/ a Migen from 2015. I didn't think the language changed _that_ little since 2015. | 21:54 |
| somlo | personally, I'm no expert, only know enough to be a slight danger to myself :) But it's *infinitely* more legible than e.g. Chisel ;P | 21:54 |
| gurki | somlo: how much effort does litex / enjoy digital actually put into migen maintenance? | 21:55 |
| somlo | i.e, even if you're a [n]migen / amaranth n00b, one can still follow what's actually going on by reading the sources, which is most definitely *not* nothing :D | 21:56 |
| somlo | gurki: I think that's the entire point of whitequark and _florent_ working on adding a "glue layer" that would alow litex to use amaranth instead of migen | 21:57 |
| gurki | but why wouldnt people just continue developing migen? | 21:58 |
| gurki | as in: whats the problem with migen? | 21:58 |
| somlo | amaranth is actively maintained (by whitequark, mainly, afaik) -- and migen not so much, from my observation | 21:58 |
| gurki | i found https://github.com/enjoy-digital/litex/wiki/Migen-Amaranth which kinda would stop me using litex for production, honestly | 21:58 |
| gurki | well. theres a company ultimately making $$$ out of it, they could have sb do things :) | 21:59 |
| gurki | (sorry for jumping this conversation, i was not aware of this ...) | 21:59 |
| somlo | I'll have to step back and let others speak more authoritatively about that sort of thing -- I don't have any insider knowledge, just a rando on the internet issuing observation based opinions :D | 21:59 |
| cr1901 | Programming does not exist in a technical vacuum | 22:01 |
| somlo | cr1901: 100% agree -- it's one of the main reasons I'm volunteering to package things for my distro of choice -- I like to know how the tools I use (or the dependencies of things I care about) hang together, where they come from, and their "health and sustainability" status... | 22:04 |
| somlo | which makes the current trend of "vendoring" I've noticed in many projects somewhat ... suboptimal (at least from that specific angle) | 22:07 |
| mithro | https://www.researchgate.net/profile/Sergiu-Mosanu/publication/372986669_PiMulator_A_Processing-in-Memory_Emulation_Platform/links/64d3fefab684851d3d9494d7/PiMulator-A-Processing-in-Memory-Emulation-Platform.pdf | 22:25 |
| mithro | Seems to mention LiteX and LiteDRAM quite a lot | 22:28 |
| *** RodolfoAzevedo <RodolfoAzevedo!~RodolfoAz@2801:8a:c811:1:ec78:31b6:35ff:a9f5> has quit IRC (Quit: Client closed) | 22:40 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!