<mtrbot-ml>
[mattermost] <npulido> npulido joined the team.
npulido has joined #m-labs
proteusguy has quit [Ping timeout: 246 seconds]
npulido has left #m-labs [#m-labs]
proteusguy has joined #m-labs
npulido has joined #m-labs
mauz555 has joined #m-labs
npulido has left #m-labs [#m-labs]
npulido has joined #m-labs
<mtrbot-ml>
[mattermost] <rjo> rjo joined the team.
mauz555 has quit [Remote host closed the connection]
<npulido>
Hi, I posted a question last Friday to artiq@lists.m-labs.hk, but I did not recieve a copy and it does not appear in the list's archives. Is the list still working?
<rjo>
npulido: you need to be subscribed. if not, you have received a notification.
<npulido>
I am subscribed and actually have posted once in the past.
<sb0>
npulido: i'll check
<sb0>
thanks for letting us know there might be a problem
<npulido>
alright, thank you guys
<sb0>
BTW I've been wondering if we should replace the list with some web-based forum e.g. with discourse. not many people are using the list anymore, and a forum based on some FLOSS solution is something I can reasonably host myself
<cr1901_modern>
Discourse is good
mauz555 has joined #m-labs
<cr1901_modern>
And idk why the mailing list frequency went down so much- does the m-labs (not artiq) mailing list still work?
<sb0>
the mailing lists are down now, but that's a recent issue. the frequency went down because people are using IRC, GitHub and a bit of Twitter
mauz555 has quit [Read error: Connection reset by peer]
mauz555 has joined #m-labs
<cr1901_modern>
>the frequency went down because people are using IRC, GitHub and a bit of Twitter
<cr1901_modern>
^Well that's fair, but I would've expected that to have been true in 2016, which was the last time I posted to the mailing list.
<cr1901_modern>
:P
<cr1901_modern>
I dunno... I never found mailing lists all that great. I mainly used it because for a long while patches had to be sent through the list (until you decided to cave (?) and use GH's features).
<sb0>
the reason for the "caving" is GH added features that addressed the problems I had with pull requests
<cr1901_modern>
You mean the option to rebase PRs?
<sb0>
yes, for example
<cr1901_modern>
Tbh, until today, I figured that you not using GH was more that you wanted as much of your infrastructure to be FOSS as possible (nothing wrong w/ that).
<cr1901_modern>
Hosting the repo on GH was a concession for maximum reach. I.e. you had a private repo for migen, artiq, etc on your webserver and you just pushed to GH as a mirror.
<sb0>
not really
<sb0>
GH was the only git web interface with a decent UI back then
<sb0>
and I don't have private mirrors for migen, artiq etc.
<sb0>
I've installed gitea recently to try it, but it's still missing some features from GH, though it is generally quite good (and a remarkable copy of GH)
<cr1901_modern>
never heard of them
<sb0>
I've also installed Gitlab, but promptly removed it due to unreasonable bloat, it's eating like a gigabyte of RAM and using 1% CPU all the time when doing nothing
<sb0>
gitea is very lightweight and also supports a simple sqlite database for small installation
<sb0>
with gitlab you need redis + postgresql right away, among many other things
<cr1901_modern>
That's good for my VPS... I only _have_ 1GB of RAM lmao
<cr1901_modern>
Failing that, I could fallback to gitweb
<cr1901_modern>
(although clearly all that affords me is r/o webview)
<cr1901_modern>
sb0: Also, that repo is interesting although since it's so nix heavy I can't use it (even if I were on Linux)
<sb0>
try it in WSL
<sb0>
for CLI stuff it seems to work
<cr1901_modern>
I use 7, so no WSL
<cr1901_modern>
(Yes this will change within a year whether I want to or not)
<sb0>
discourse is another postgresql + redis monster, which only supports a docker image for installation
<sb0>
I guess I can try out that docker image and then measure CPU/RAM usage to see if it's worth going further with this stuff...
<cr1901_modern>
Probably not
<cr1901_modern>
I just love how everything punted on "libraries coexisting is hard"
<sb0>
I suppose docker also gives them postgresql and redis already set up
<sb0>
and running
<sb0>
of course they should add sqlite support and make that a non-issue...
<cr1901_modern>
well yes, and that is very convenient (and filling out config files for you is orthogonal to "libraries coexisting is hard"). I'm just being grumpy.
<sb0>
Note: Discourse requires a swap file if you are using 1 GB of RAM
<sb0>
it's a damn web forum application...
<cr1901_modern>
Any free "bulliten board" forums not called phpBB?
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has quit [Read error: Connection reset by peer]
mauz555 has quit [Remote host closed the connection]
<lkcl>
sb0: ping, are you in touch with jean-paul of minerva? or, do you happen to know if there are any outstanding patches to nmigen related to Record that he might be using?
<sb0>
lkcl: ask key2
<lkcl>
sb0: ack, thx
<whitequark>
sb0: sqlite isn't useful for something like discourse
<sb0>
whitequark: why is postgresql better?
<lkcl>
key2: ping, hello, love minerva. have encountered a discrepancy, it doesn't build
<key2>
lkcl: i JUST asked whitequark to commit it
<key2>
:)
<lkcl>
Record, as imported from the nmigen location... ah :)
<whitequark>
sb0: sqlite doesn't work well if you have any parallel queries and its full text search is quite bad
<lkcl>
very cool, because it's functionality that we really need in our design as well (missing the "connect" function)
<lkcl>
and Record.eq
<whitequark>
it has a single global write lock
<lkcl>
and Record.flatten()
<whitequark>
so the moment you have multiple writes your application grinds to a halt
<lkcl>
i've had to write substitutes as a workaround
<whitequark>
since the write lock prevents reads too
<lkcl>
whitequark: ping, when you have a moment, i created an experimental Record.__setattr__ which works well
<whitequark>
lkcl: we've discussed this before, i do not think Record.__setattr__ should exist in nmigen at all
<whitequark>
you are of course free to do it in your codebase
<lkcl>
we identified that it would be dangerous to modify the fields after first use
<whitequark>
it's more than that
<whitequark>
the interface of a Record depends on the field order
<whitequark>
and with __setattr__ the field order is implicitly defined by what runs first
<lkcl>
yes. so that would be part of the specification during the creation of a Record-derived object.
<whitequark>
I think you're trying to use the wrong abstraction here
<lkcl>
even without that, if it's considered to be a "problem" then, well... don't use Record.__setattr__ to create the fields!
<lkcl>
in a simple design, i would agree absolutely.
<whitequark>
this problem is worse for complex designs, not better
<whitequark>
because in complex designs it is harder to understand what you are dealing with without explicit layouts.
<lkcl>
we are creating a full out-of-order vector processor. having Object management is absolutely crucial.
<lkcl>
i do not have such a problem.
<lkcl>
why would it be a problem?
<lkcl>
i have over twenty multi-layered objects in the IEEE754 FPU pipeline code, and i do not have a problem with any of them.
<lkcl>
the order of addition to the Record-object defines the order of the fields.
<lkcl>
simple.
<lkcl>
done.
<lkcl>
what is the problem?
<whitequark>
so now you have to consult the implementation to see what the fields are and what their order is
<whitequark>
trace each method call at any point in the program where that RecordObject is used.
<whitequark>
I don't think that's good design at all.
<lkcl>
and that is a problem,,, why?
<lkcl>
that's a problem that's solved by running "epydoc" and using it to view the code hierarchy
<whitequark>
because to understand something as simple as the layout of a record you have to consult an unknown, potentially large amount of code in your complex project
<lkcl>
just as you would with any other standard large python codebase
<lkcl>
... and?
<lkcl>
that's a standard project management issue.
<lkcl>
associated with any large project.
<whitequark>
and it's completely avoidable by not using this pattern.
<lkcl>
with the result that the project becomes massively complex and unmanageable as a result.
<whitequark>
it's the opposite...
<lkcl>
*not* having this option is much worse than having it, from a project management perspective
<lkcl>
we define base classes (Records) that are extended by their derivatives
<lkcl>
this is standard OO python for any large project
<lkcl>
without that capability, it's a god-awful mess
<lkcl>
we'd be forced to jury-rig some sort of god-awful substitute for standard OO inheritance practices
<lkcl>
constructing field layouts through a function call
<lkcl>
perhaps even be forced to use python meta-classes
<whitequark>
like I mentioned, in that case Record is the wrong abstraction entirely, because it has never been designed for extensibility or inheritance
<whitequark>
Record is essentially namedtuple
<lkcl>
precisely.
<whitequark>
so the solution is to not add ad-hoc functionality to Records that makes it much harder to understand what's going on without reading all associated code
<whitequark>
the solution is to use an abstraction that matches your use case
<lkcl>
yet, through the addition of a single function (__setattr_) that's around 8-10 lines, it evolves into something much more extensible.
<whitequark>
this is just short-term thinking that favors ease of writing code over ease of understanding code
<whitequark>
yes. it is always easier to add something ad-hoc that solves your immediate problem.
<whitequark>
but that doesn't make it good design
<whitequark>
I am thinking that a proper solution for your problem would be defining explicit container classes, so just Python classes, that you could actually inherit from
<whitequark>
they might not even be Values themselves
<whitequark>
(and if they aren't Values they can be prototyped outside of nmigen as well)
<lkcl>
yes: and the result is that we have had to create global functions, eq() and flatten() are two that we've been forced to create (so far)
<lkcl>
it's getting to the point where it's ridiculous
<lkcl>
and all it would take to *not* have that ridiculousness would be... the addition of a mere 8-10 lines to Record.
<whitequark>
no.
<lkcl>
so we are forced to duplicate much of the functionality of nmigen?
<whitequark>
you're not forced to do anything...
<lkcl>
we are not "forced" to complete the goal that has been set
<whitequark>
I don't see why this has anything to do with Record at all
<lkcl>
Record already has __getattr__ which makes it look like an object
<whitequark>
so?
<whitequark>
that doesn't make it the right solutio
<lkcl>
Record(layout=("src1, 20))
<lkcl>
can access that as r.src1
<whitequark>
yes, you can shoehorn it into this design, with bad consequences, to make it kind of work
<whitequark>
that does't mean you should
<lkcl>
when the alternative means that we are forced to write replacements for eq() and many other functions that already exist in the nmigen Value API, alternatives begin to be investigated
<lkcl>
and yes, "forced" is the right word. giving up on the goal is not an option.
<whitequark>
to be clear, there are two separate issues here.
<lkcl>
(from our prior discussion, i did take on board that there is the long-term maintainability of nmigen to consider)
<whitequark>
first, you want your __setattr__ hack to be upstream. that's not going to happen, because i consider it an instance of bad design, i explained why, and nothing you have said so far has convinced me otherwise; if something i am only more certain that it is bad design.
<whitequark>
however, you do not need it to be upstream
<whitequark>
you can keep using it in your project indefinitely.
<whitequark>
you can freely use your RecordObject as long as you want and it will work like you want and this specific goal of yours will be achieved.
<lkcl>
yes: i'm considering deploying monkey-patching as a substitute for having to derive from Record to add one single function
<whitequark>
that's awful
<whitequark>
it just makes it unclear that your Record has a different functionality...
<lkcl>
it's awful... however i'm concerned that deriving from a class may confuse nmigen. i'll need to investigate.
<whitequark>
it will not
<whitequark>
i told you before that i guarantee to you that this kind of deriving will work forever
<lkcl>
we've 18+ months ahead of us, and need a stable (and flexible) codebase.
<whitequark>
anyway, the second issue, is that you have (quite correctly) noted that Record does not support extensibility or inheritance.
<whitequark>
because it wasn't designed to do so at all.
<lkcl>
it does... when __setattr__ is added.
<whitequark>
no.
<whitequark>
and I've explained to you why already.
<lkcl>
i'm planning to add a class-decorator system that walks all of the functions of Record
<lkcl>
i already have classes based on RecordObject that do exactly that!
<lkcl>
they *are* inheritable!
<lkcl>
and the only functions that will be permitted to add to the fields/layout will be __setattr__ and __init__.
<lkcl>
any functions other than those, adding to the fields, will be prohibited.
<whitequark>
so why not make it a first-class feature instead of something that piggybacks on Record?
<lkcl>
and that's enough.
<whitequark>
I think it's well important enough to be a first-class feature instead of some hack with decorators.
<lkcl>
do you mean, why not create a completely separate base class that has this capability yet is not based on Record?
<whitequark>
yes.
<lkcl>
i tried: it failed when it came to passing objects based on that class
<lkcl>
the ir generators complained that they were "unknown objects"
<whitequark>
just like not all Python classes are based on namedtuple, not all nmigen classes should be based on Record
<lkcl>
and it wouldn't generate the .il (or verilog)
<whitequark>
so we can fix that...
<whitequark>
there are many ways to fix that, in fact
<whitequark>
e.g. there could be a UserValue that knows how to lower itself on lhs and rhs, then anyone could add their own Values based on existing nmigen classes.
<lkcl>
that would be a good capability to have in nmigen, to have the visitor infrastructure be extensible
<whitequark>
I'm not sure if the visitor infrastructure can be made extensible
<lkcl>
i would be very surprised if it was used often
<whitequark>
but it's possible to add lowering
<lkcl>
lowering?
<lkcl>
would that be for example by flattening the object (or whatever) to e.g. a Signal?
<whitequark>
basically, yes
<lkcl>
(of width equal to the object's width)
rohitksingh has joined #m-labs
<lkcl>
yeah that would work. or, perhaps, walk it into a Record (with a fixed, recursively-analysed layout)
<lkcl>
this could work very well.
<whitequark>
adding this lowering is very straightforward, it allows great flexibility, and it would allow people to experiment without awful hacks like __setattr__ on record
<lkcl>
:)
<whitequark>
so, this would be good design.
<whitequark>
do you understand my approach now?
<whitequark>
you have an "XY" problem. you have problem X, but you ask me to do Y, which would coincidentally solve X.
<lkcl>
yeah it's a... "safe" approach.
<whitequark>
yes.
<lkcl>
our interim solution is to go with the (lovely) RecordObject as a temporary middle ground that can, if everything derives from it, be replaced with something that does the "lowering"
<lkcl>
later.
<whitequark>
sure, that works.
<lkcl>
ok. anyway, apologies for distracting you from what you were talking about with sb0 (and key2)
<lkcl>
thank you, whitequark.
<_whitenotifier-1>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjmAX
<_whitenotifier-1>
[m-labs/nmigen] whitequark 50fa251 - hdl.ast: fix some type checks.