<ggangliu>
Hi, I'm using 0.4.2 now. I got this info "DeprecationWarning: The `add_sync_process` method is deprecated per RFC 47. Use `add_process` or `add_testbench` instead.", after using add_process, I met a new error "Received default command from process '/home/ggang/first-riscv/tutorial/up_counter.py:52' that was added with add_process(); did you
<ggangliu>
mean to add this process with add_sync_process() instead?", it seems that yield command trigers this issue. So I'am confused that what I should to do for it ? Thanks for help in advance
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
<ggangliu>
I have handled it by "pip3 install --user --upgrade 'amaranth[builtin-yosys]'", maybe it caused by local different python version matching
ggangliu has quit [Quit: Client closed]
cr1901_ has joined #amaranth-lang
cr1901 has quit [Read error: Connection reset by peer]
<whitequark[cis]>
<cr1901> "This isn't actionable right now,..." <- it's not possible to add this lint
ggangliu has joined #amaranth-lang
ggangliu has quit [Client Quit]
<Wanda[cis]>
took a shot at immutable AST nodes; turns out we modify src_loc after the fact in some places
<Wanda[cis]>
hdl/_xfrm.py and lib/wiring.py specifically
frgo has quit [Read error: Connection reset by peer]
frgo has joined #amaranth-lang
<Wanda[cis]>
I'm inclined to just hack around it in hdl/_xfrm.py; for lib/wiring.py I think what we need is Value constructors that take src_loc, not just src_loc_at
<whitequark[cis]>
tbqh we could also just leave src_loc out of the contract
<whitequark[cis]>
doesn't seem consequential
<Wanda[cis]>
true
notgull has quit [Ping timeout: 264 seconds]
<Wanda[cis]>
hrm.
<Wanda[cis]>
Signal name is also set from ClockDomain.rename for obvious reasons
<Wanda[cis]>
I'm not sure why we even have it in the first place?
<whitequark[cis]>
hmm
<whitequark[cis]>
should we allow setting both name and src_loc? name is more semantically important, though
<Wanda[cis]>
idk
<whitequark[cis]>
(this is about more than just ClockDomain.rename)
<Wanda[cis]>
I already fixed the src_loc thing by adding constructor arg though
<whitequark[cis]>
so to expand on this, when I wanted to make nodes immutable, I didn't want to deal with like... ok, can we change an Operator's operands? or a Cat parts?
<whitequark[cis]>
the answer to that is clearly no
<Wanda[cis]>
yeah
<whitequark[cis]>
but I can see having legitimate reasons to change name or src_loc
<whitequark[cis]>
we kinda don't document how to read them for good reason (the data type within is garbage)
<whitequark[cis]>
so, do you wanna fix the data type being garbage first? I have that on the roadmap already even
<Wanda[cis]>
yeah I see it's on 0.5 list
<Wanda[cis]>
let's see... still opaque to user, but internally represented as a list of (filename, start line+col, end line+col), wrapped in a nice class, and providing some sort of combining function (+ operator maybe even?) that gives you a new SrcLoc with all of the included locations in order?
<whitequark[cis]>
class SourceRange: filename [absolute], start_line, start_col, stop_line, stop_col
<whitequark[cis]>
class DebugLocation: def __iter__(self) -> Iterator[SourceRange]
<whitequark[cis]>
this is what I've been thinking about
<whitequark[cis]>
yeah basically, + works
<whitequark[cis]>
actually
<whitequark[cis]>
tbh I think we could have just one class which is the container for any number of locations rather than have two
<whitequark[cis]>
makes the algebra simpler
<Wanda[cis]>
yup
<whitequark[cis]>
yeah just go ahead with your design, it's nicer and was my original one before i decided to make it more complicated for no reason
<Wanda[cis]>
or at least
<Wanda[cis]>
well
<Wanda[cis]>
only one of those would be user-facing, right?
<Wanda[cis]>
I do think we still need both a "list" and "list item" class
<Wanda[cis]>
(that or just use a tuple as list item ...)
<Wanda[cis]>
but also, as I understand it, we cannot actually get columns or more than one line with tracer, right?
<Wanda[cis]>
oh
<Wanda[cis]>
wait
<Wanda[cis]>
they changed it recently, didn't they
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] d928432 - Deploying to main from @ amaranth-lang/amaranth@8af9fe2606314d37daf079c533a48e6ce0df9bd5 🚀
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9e61b0f - Deploying to main from @ amaranth-lang/amaranth@1dd2e6150c4c3524a44a8d371802758699e19c4a 🚀
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark d8065bf - Deploying to main from @ amaranth-lang/amaranth@597b1b883924d8949061b52270eb55b97a7cfb76 🚀
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] d40c187 - Deploying to main from @ amaranth-lang/amaranth-stdio@ae774a5709321d5bffddbcebed09b0e350cb6282 🚀
<whitequark[cis]>
not only that, but also have, as the default UART in soc, one which lets you configure independent baud rates for the receive and transmit half
<whitequark[cis]>
(and of course a 16550-compatible one, for Linux etc)
<jfng[m]>
yeah, also as some have noticed here before (zyp, iirc), you can't do connect() on the -stdio AsyncSerial due to the way it is built
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] b19c19d - Deploying to main from @ amaranth-lang/amaranth@f2dab705ee245e82f71a0b1d283a1652d6d026c7 🚀
<jfng[m]>
<whitequark[cis]> "or I guess InputOnly, PushPull..." <- in OpenDrain mode, you'd only drive `oe` if `o` is 0 ?
<whitequark[cis]>
yes
<whitequark[cis]>
well, you always drive o=0, and you do oe=OData or whatever the field was called
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0d2e326 - Deploying to main from @ amaranth-lang/amaranth@2356e8d06b3c5222b587d9478607105b3297580b 🚀
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 4d198fe - Deploying to main from @ amaranth-lang/amaranth@aa9f48ccb29c0bed95b16fb346f6fb73bcdcf29a 🚀
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 7ed6514 - Deploying to main from @ amaranth-lang/amaranth@544258354bdcc2773b037c29c77b95ba01e6cd17 🚀
<cr1901>
>it's not possible to add this lint. Why?
<whitequark[cis]>
how would you suppress it?
<cr1901>
# noqa: AMA10x (I was thinking an external linter. Is there any reason why this is impossible other than "it's out of scope", which btw is perfectly reasonable)
<whitequark[cis]>
Amaranth doesn't do hot comments in the middle of the file
<whitequark[cis]>
any lint that is added must have a way to suppress it with just normal Amaranth syntax
<cr1901>
You're already embedded into Python, with all it's facilities. Why are hot comments out of scope?
<whitequark[cis]>
(I also find the # noqa: pattern so egregious that I will never accept the use of a tool that requires it in any project I maintain)
<whitequark[cis]>
cr1901: because they're syntactically foreign to the language
<Wanda[cis]>
we're currently not doing any crimes that require actually parsing the file ourselves
<whitequark[cis]>
a hot comment is attached to what? the line? the expression? the preceding text? the following text? the entire block after?
<whitequark[cis]>
Wanda[cis]: except for the `# amaranth: UnusedElaboratable` thing
<whitequark[cis]>
which is both problematic enough, and janky enough that it doesn't work (I think the open bug was filed by cr1901 even?)
<Wanda[cis]>
barely counts as parsing
<Wanda[cis]>
heh
<whitequark[cis]>
but yeah, # amaranth: doesn't require parsing as it has to be the very first thing in the file
<_whitenotifier-5>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-1172-544258354bdcc2773b037c29c77b95ba01e6cd17 - https://github.com/amaranth-lang/amaranth
<whitequark[cis]>
so thinking more about this, I think we maybe can do `my_sig_with_intenum_shape == (MyVariant & cond1 & cond2).bool()` ?
<whitequark[cis]>
that is: warn on a comparison where one operand has a non-unsigned(1) shape and the other is a logical expression which isn't wrapped in .bool()
<cr1901>
That would detect all the errors I made last night
<cr1901>
(Transforming m.If(a & b & c): to m.If(d == e & b & c): via find-replace without thinking to include parens)
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] ba05d29 - Deploying to main from @ amaranth-lang/amaranth@3a1f0a7c32cb1999ba4db6d6a397bc393457ab23 🚀
<whitequark[cis]>
something that can't be reasonably suppressed when you do want it has no right to be a lint, no matter what else
<cr1901>
I don't know how you actually write that without triggering a lint
<whitequark[cis]>
then it can't be a lint
<whitequark[cis]>
every single one of our lints has an immediately applicable "here's how you make the compiler shut up if you actually want this" section in the message
<cr1901>
I almost said "add parens", but that won't help since the parens aren't there by the time you're doing the lint
<whitequark[cis]>
like... the whole point of having a diagnostic as a lint is because it can have false positives
<whitequark[cis]>
if it never has false positives it should be a hard error, yes?
<whitequark[cis]>
and if it does have false positives it must be suppressable without making you do busywork that you will hate, because if that happens a few times in a row people will just suppress all lints globally (or write you hate mail, or both)
<cr1901>
Yes, it could have false positives. "I cannot comprehend the confusion" where the current behavior is desirable, but that doesn't mean those situations don't exist.
<whitequark[cis]>
it's not super difficult to imagine a situation where it's desirable
<whitequark[cis]>
depending on how restrictive the conditions for the lint firing are, it may or may not fire for all of the variations there. e.g. you could exclude any logical expressions whose both operands have a non-boolean shape
<whitequark[cis]>
however `with m.If(flags == (1 & old_flags)):` is still basically reasonable to write
<cr1901>
Yes, all the use cases I debugged yesterday were transforming an If expression of bools into "If expression of bools and an IntEnum flag"
<whitequark[cis]>
if it wasn't an IntEnum we could have made Enum.__eq__ fire a warning on comparison with non-enum
<whitequark[cis]>
but with IntEnum this is explicitly allowed
<cr1901>
Something else broke when I used plain old enum, and had to use IntEnum. I'll check after breakfast.
<cr1901>
Maybe that condition is gone/no longer applies and I can go back to plain old enums
<whitequark[cis]>
actually
<whitequark[cis]>
Wanda has implemented the check in Enum.__eq__, right?
<whitequark[cis]>
yeah, she did! so this should've been covered already if you weren't using an IntEnum
<cr1901>
Yea I don't need IntEnum, I made a mistake in my tbs
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] eb2d102 - Deploying to main from @ amaranth-lang/amaranth@f8e2d26b8f366fe88980f485c03873b2e897bb6a 🚀
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark a973998 - Deploying to main from @ amaranth-lang/playground@89cbf9e4f51c2635d12fcee975636924c2dccaec 🚀
<Wanda[cis]>
eg. due to some server shitting itself
<whitequark[cis]>
because failure to build docs prevents a PR from being mergeable, and failure of an external party to keep their website up should not
<whitequark[cis]>
the only things that should prevent a PR from being mergeable are those which are under our control or GitHub's
<whitequark[cis]>
this is mostly true right now, in particular, launchpad going down breaks Amaranth builds because formal
<whitequark[cis]>
cr1901: btw, can you remind me the status of yowasp-boolector? is it generally usable?
<whitequark[cis]>
did it need a better SAT engine plugged in or something?
<cr1901>
It needs a better SAT engine, I got it working locally w/ MiniSAT for far better performance (about half as good as Cadical, the best), but I haven't upstreamed any of the required patches yet
<whitequark[cis]>
gotcha
<whitequark[cis]>
any timeline on that? it seems like the current published version is basically unusable, which I should probably make a note about, or just unpublish it
<cr1901>
I'll look into it after I get smolarith published (hopefully today or tomorrow)
<whitequark[cis]>
cool, thank you
<whitequark[cis]>
David Sporn was doing yices2, right
<cr1901>
yes
<whitequark[cis]>
if we had yices2, we could remove our dependency on launchpad, which seems to go down quite a bit recently
<cr1901>
TLDR: "minisat, without changes, requires gzip/or similar to build. And boolector actually doesn't link in minisat properly if gzip isn't on the system path. But wait, I don't actually need the gzip crap, so why not upstream a "basic build mode" and patch boolector to know about it?"
<Chips4MakersakaS>
Talking about YoWASP; would you see ngspice falling under that umbrella ? Was packaging ngspice some days ago and would have liked a python installable version. May want to learn how to do it myself (no hard promise though).
<whitequark[cis]>
it's a CLI tool, right? does it spawn subprocesses?
<Chips4MakersakaS>
It can be run as CLI tool but can also have it's own crude X11 interface (I think still Athena widgets...). I don't think it needs subprocess; it can be run multi-threaded though.
<cr1901>
(Of course I found one thing already lmao)
<whitequark[cis]>
Chips4MakersakaS: sounds good. wasm has threads support, so that's not an issue
<Chips4MakersakaS>
So you see YoWASP broader than digital FPGA ? ngspice is clearly analog ASIC focused.
<whitequark[cis]>
cr1901: if you want to be compatible with Amaranth streams with *no upgrade necessary*, use payload/valid/ready
<whitequark[cis]>
Chips4MakersakaS: YoWASP is a software distribution
<cr1901>
Ack
<whitequark[cis]>
I'm happy to ship anything that builds to Wasm and is vaguely EE-related
<whitequark[cis]>
I'll need to refactor a few things to keep maintenance overhead low, but it's not exactly very high already
<Chips4MakersakaS>
Perfect, I will look further coming days; have also interest in getting to know more about WebAssembly.
<cr1901>
Anyone build OCaml C code using WASM? The SAIL RISC-V emulator is painful enough to compile that both olofk and I provide a Linux binary in-line
<whitequark[cis]>
sounds good
<galibert[m]>
does webasm in the browser still require js glue?
<whitequark[cis]>
define JS glue?
<galibert[m]>
iirc it wasn't possible to reach the dom and change it, at least?
<whitequark[cis]>
it still isn't
<galibert[m]>
iow, it's not possible to have no js
<whitequark[cis]>
it's not a particularly high priority goal, though I know people have been working towards that
<whitequark[cis]>
I literally do not care about having no JS
<galibert[m]>
Sure, but I know you'd know the state of things :-)
* tpw_rules
thinks about nix in the corner
<cr1901>
from amaranth.lib.payload import StructLayout <-- whoops
<whitequark[cis]>
tpw_rules: what has worse UX: pip or nix?
<tpw_rules>
definitely nix
<tpw_rules>
that's why i don't say use it :P
<whitequark[cis]>
hehe
<whitequark[cis]>
the cool thing about yowasp is that as we're moving towards wasm components, it should be possible to ship just the wasm file, with the data files embedded inside in a virtual filesystem
<tpw_rules>
maybe i'll set up nix to build the wasm someday, more for my own edification than anything
<whitequark[cis]>
I can already do this for everything except yosys, really
<tpw_rules>
i think that's cool, but it's good to trace back to the source too
mcc111[m] has quit [Quit: Idle timeout reached: 172800s]
<galibert[m]>
what's special with yosys?
<whitequark[cis]>
and then the wasm file is runnable on any embedder that implements wasi
<whitequark[cis]>
galibert: some of the yosys share files are needed by the outside code (CXXRTL, primarily)
<whitequark[cis]>
this is what you'll eventually use to manipulate DOM from Wasm
<tpw_rules>
is webidl related to COM
<whitequark[cis]>
sorta?
<galibert[m]>
"Side effects of reading this code may include facepalming, mouth drops, and a strong desire to rewrite all of it. Proceed at your own risk"
<galibert[m]>
Love that
<whitequark[cis]>
it's related inasmuch as WebIDL and COM both use IDL
<tpw_rules>
that's what i thought
<whitequark[cis]>
at least as a basis
<tpw_rules>
what's old is new again i guess
<whitequark[cis]>
I think IDL predates COM by over five years
<whitequark[cis]>
WebIDL has actually been used all this time
<galibert[m]>
IDL is from the time people thought CORBA was useful :-P
<whitequark[cis]>
wasm components are not entirely unlike corba
<whitequark[cis]>
they use WIT (a type of interface description language, not compatible with IDL) to describe methods that can be called on resources passed between shared-nothing (as opposed to shared-memory) components
<galibert[m]>
the layers of interpretation/jit allow for transparent serializing i guess when needed
<whitequark[cis]>
more of the abstract execution model, but yeah
<whitequark[cis]>
* more it is the abstract execution model that allows it, but yeah
<whitequark[cis]>
since wasm code has to explicitly request every single thing it's using, even a linear memory
<whitequark[cis]>
cr1901: in `:type:` blocks, you can explicitly use e.g. `:func:` and `:class:` etc
<whitequark[cis]>
this gives you cross-referencing at the cost of being kind of verbose
<whitequark[cis]>
<cr1901> "Anyone build OCaml C code..." <- I think there's wasm_of_ocaml now
<whitequark[cis]>
although wasm_of_ocaml requires EH, GC, TC, and JSPI, which is a pretty tall order
<whitequark[cis]>
(I think it means basically "runs in Chrome")
<cr1901>
heh
<cr1901>
SAIL is hell to build only because I'm not exactly great w/ OCaml build systems (especially since everyone seems to be going to Dune now and I've basically no Dune experience)
<cr1901>
Oh, and it takes 30 minutes to compile, but I imagine I could fix that by removing LTO if I actually knew how to ocaml-build-system
<whitequark[cis]>
which of the 11 build systems in wide use?
<whitequark[cis]>
OCamlMakefile, ocamlbuild, omake, topkg, OASIS, dune, ... it's been a while since I've done this
<cr1901>
I only know of two of those lmao
<whitequark[cis]>
you are incredibly lucky
<galibert[m]>
I know none of them, I feel luckier :-)
<cr1901>
The SAIL build does basically "just work" now that I automated it, just... the ppl writing the current conformance tests should provide binaries for the SAIL model. I know ppl who gave up and use the old tests b/c of SAIL and riscof plugins being a pain to write
<whitequark[cis]>
cr1901: > Signature containing the following attributes:
<whitequark[cis]>
Signatures do not have (user-specified) attributes, they have members
<whitequark[cis]>
Interfaces have attributes (which correspond to signature members)
<cr1901>
fixed locally
<cr1901>
Idk if it's a bug, or me not getting the syntax just right, but writing out :class:`amaranth:amaranth.hdl.Signal` in e.g. Attributes section doesn't generate a link
<cr1901>
Generates "
<cr1901>
" verbatim (no hyperlink)
<cr1901>
Type:
<cr1901>
amaranth:amaranth.hdl.Signal
<cr1901>
But it's good to know that you can use these roles in type blocks
<whitequark[cis]>
hm, interesting
<whitequark[cis]>
I might just be wrong, but I thought I used those
<whitequark[cis]>
maybe you need napoleon for that?
<cr1901>
https://twinery.org/ (I confused Twine with Ren'Py, which _is_ a Python game making library. Presumably this is not the same twine)
<whitequark[cis]>
oh, nice
<cr1901>
I've never auto-published packages before, so looking at Amaranth's CI and perhaps stealing the parts that'll work for me
<whitequark[cis]>
ah yeah
<whitequark[cis]>
you'll also need to enable OIDC publishing
jjsuperpower has quit [Ping timeout: 240 seconds]
jjsuperpower has joined #amaranth-lang
<cr1901>
Noted. After taking a look, I might do that next release then, just so I can get a release out the door (and remove more stuff from my current todo stack)
jjsuperpower has quit [Remote host closed the connection]
jjsuperpower has joined #amaranth-lang
mindw0rk has quit [Read error: Connection reset by peer]