sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling__ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
fengling__ has quit [Quit: WeeChat 1.2]
fengling has joined #m-labs
fengling has quit [Quit: WeeChat 1.2]
fengling has joined #m-labs
<rjo>
sb0: by the way: if Modules define a list of [Signal, Constant, Module, Record], it would be straight forward to extract verilog modules from them and map the submodule hierarchy into verilog modules. probably only helps readability and floorplanning but still.
<sb0>
do something like self.attr_io() similar to artiq attr_device?
<rjo>
yeah. i must have missed EnvExperiment and attr_device. what is that? (compared to DbKeys, Device, Experiment).
<sb0>
that would be less flexible... passing signals in a non-hierarchical way is nice sometimes, e.g. with CSRs
<sb0>
what I like with the current one is there is zero __getattr__/__setattr__ trickery
<sb0>
everything is explicit and regular Python
<rjo>
same for traitlets.
<rjo>
and yes. __getattr__/__setattr__ would not be a smooth implementation.
<rjo>
The somewhat ugly thing about self.attr_device("x", Device()) is the string and the amount of repeated typing. It is nicer to do x = Device()
<sb0>
yes, but it's less trickery and it's consistent with the other Environment APIs
<sb0>
also, device request is only a small part of an experiment code
<rjo>
Argument/Parameter definition is a significant part.
<rjo>
what are the other Environment APIs?
<sb0>
results
<sb0>
for parameters you definitely want the explicit API
<sb0>
to make local caching problems explicit
<rjo>
what is consistent with what here?
<rjo>
which explicit API?
<sb0>
if you do "x = Parameter()" like what was done with DBKeys
<sb0>
it is not clear when the parameter DB is accessed
<sb0>
is it at experiment init? at getattr?
<sb0>
whereas x = get_parameter("parameter_name") is clearly a function call that does a DB access
<sb0>
and there is the convenience function attr_parameter that accesses the DB and sets the result as attribute
<sb0>
device management is consistent with that
<rjo>
That sounds entirely applicable to traits.
nicksydney has joined #m-labs
<rjo>
There is also the weird side-effect in your implementation that somehow the attributes get created with None values even though they are defined and assigned in build()
<rjo>
on scanning the repository
<sb0>
traits don't solve: worker/master comms, ARTIQ GUI integration, scans. what problem do they solve?
nicksydney_ has quit [Ping timeout: 272 seconds]
<sb0>
oh, and scanning.
<rjo>
they solve the ugly syntax, they show what they really do. they solve the backend of gui creation (discovery of traits).
<rjo>
I mean HasTraits does that.
<sb0>
for simple experiments the None value is not an issue. if you are doing complicated things, then you should know what you are doing...
<rjo>
Your *Value() and Device would still need to be implemented.
<sb0>
and yes, serialization is also a problem with traits, which is why there is this "processor" mechanism
<sb0>
how do they show better what they really do?
<sb0>
they do not look better to me as they introduce the problem of implicit parameter value caching
<rjo>
what is the problem with serialization? they support that.
<sb0>
serializing a Scannable?
<rjo>
well self.attr_device("name", Type()) is convoluted for "i would like to declare that this attribute of myself shall be of this type and shall be initialized, validated, represented serialized such and such". the pythonic way would be "name = Type()"
<rjo>
and your editor helps you detect that you do have that attribute in your class.
<sb0>
fine. self.name = get_parameter("name")
<rjo>
sure the individual traits from traitlets don't do much for us. but the HasTraits is superior to your HasEnvironment
<sb0>
if you don't like the duplicated name, we can have migen-style code analysis to retrieve it from the self. assignment
<rjo>
then there is still the scanning of the repo. with traits they are already there at the class level.
<sb0>
in what way?
<rjo>
because of the above reasons. "x = Type()" is nicer, shorter, editor friendly, and available at class level than "self.name = get_type("name")"
<sb0>
wouldn't that be self.x = Type()
<sb0>
?
<sb0>
ah, you put it in the class
<sb0>
not build()
<rjo>
no. you do them at class level.
<rjo>
yes
<rjo>
that is the smooth way to support introspection without instantiation and calling build()
<rjo>
if you detest trait(let)s then at least we should do that way (with __new__ and a metaclass).
<sb0>
whether the code is run in build() or at class definition doesn't make much of a difference
<sb0>
also, I thought you wanted things like linking the default value of a parameter to another
<rjo>
if somebody needs dynamic traits (algorithmically generated, they can still do that in build() but they would not be visible on introspection of the class.
<sb0>
e.g. x = get_parameter("foo"), y = get_parameter("bar", default=x)
<rjo>
but that would be done with notifications.
<rjo>
in the traits language.
<sb0>
and again: x = Parameter() in the class doesn't make it clear when the PDB is accessed
<sb0>
you can actually use my API anywhere, not only in build()
<rjo>
Parameters are loaded from PDB at build() time. That would be the definition of the Parameter.
<sb0>
what if you pause and want to fetch a new parameter value afterwards?
<rjo>
yes. you are basically doing only dynamic traits and it happens that there is a workaround that supports some introspection of those that happen to be defined in build().
<sb0>
workarounds...
<rjo>
then you say: self.x = self.pdb[...]
<rjo>
or pdb.get()
<rjo>
actually validation/notification is much more appropriate than the simple linkage above.
<whitequark>
rjo: ok I see. so you want LTO for that case.
<rjo>
the functions could also all be static.
<whitequark>
*nod*
<GitHub183>
[artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYhtg
<GitHub183>
artiq/new-py2llvm 1e3911e whitequark: Use try..finally in compiler.targets.Target.link.
<whitequark>
sb0: can I rename kserver.c to something else? it's not loading or running on kernel CPU and its name irritates me greatly
<sb0>
rjo, bits_for(value), value < 0 -> value_bits_sign ?
<sb0>
whitequark, yesa
<sb0>
-a
<whitequark>
sb0: just had a realization: the exception handler in crt0 is almost identical to libunwind's exception handler
<whitequark>
we could make traps unwind! e.g. for DIV/0
key2 has joined #m-labs
<whitequark>
(I don't know if it actually traps on DIV/0)
<sb0>
it does i think. but that's another non-portable thing we'd have to deal with if/when changing CPUs.
<whitequark>
sure. I don't insist. it's just something we can do to make it faster.
<whitequark>
with floating-point exceptions, that's the only reasonable option, I think
<whitequark>
as a side note, we'll have to port libunwind to another CPU anyway, which means we'll likely end up in the same situation as right now with OR1K
fengling has quit [Ping timeout: 245 seconds]
<whitequark>
oh i see, so the model you had was function-based. an object contained a bunch of functions, you loaded them all, and then you could run any of them on the kernel CPU
<whitequark>
whereas i made the compiler to the python's module-based model
<whitequark>
let me think about this
_florent_ has joined #m-labs
fengling has joined #m-labs
<whitequark>
sb0: does the possibility of running some code before you run the kernel itself strike you as useful?
<whitequark>
e.g. some kind of computation. produce a table, I dunno
<sb0>
why not just put that code at the beginning of the kernel?
<sb0>
or do you mean at the experiment level? yes. and that is done by not decorating run with @kernel
<whitequark>
well, yes, but then it's computed on host
<whitequark>
I mean at the experiment level and on the device.
<sb0>
then why not put it into the kernel?
<whitequark>
what if it doesn't change between kernel runs?
<whitequark>
let me put it another way
<whitequark>
the new compiler was designed with the assumption that it would be useful. I can expose it now in the runtime or don't bother
<whitequark>
the amount of work in each case is about same
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
_florent_ has quit [Quit: Leaving]
<whitequark>
sb0?
bentley` has quit [Ping timeout: 272 seconds]
<GitHub125>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYjId
<sb0>
and why do you need to change the runtime anyway?
<sb0>
besides exceptions, linker and communication for strings
<whitequark>
oh, I don't change anything except that
<whitequark>
this is a part of the change to the linker, since I can't just go and run a random compiled function
<whitequark>
(it expects an initialized environment as its first argument, which would contain e.g. other functions)
<sb0>
where would that precomputed data be stored?
<sb0>
heap_
<sb0>
?
<whitequark>
no
<whitequark>
stack
<whitequark>
there's no heap...
<sb0>
I know, but maybe you were thinking of adding one
<whitequark>
I think you've been very clear on that you don't want a heap
<sb0>
so: 1st kernel terminates, and leaves some stuff on the stack for the next one?
<whitequark>
yes
<whitequark>
during library load, the initialization code would run, executing any code that's on the "file level"
<whitequark>
and then it waits for any request to run a kernel.
<sb0>
ok, I see
<sb0>
it's like the init/fini sections on linux, right?
<whitequark>
I'm even using DT_INIT for that.
<sb0>
I can't just go and run a random compiled function < why is that?
<whitequark>
every Python function is a closure, so it wants an environment as the first argument
<whitequark>
you need to get it somewhere. the module initialization code creates that closure and fills it, at least, with the address of the closure itself
<whitequark>
(def f... creates a local variable, which it may then itself use.)
<sb0>
ok
<sb0>
no, I don't really see a use for loading user code into the init section
<sb0>
that doesn't really fit into the "JIT" model
<whitequark>
ok
<sb0>
we may want some caching mechanism at some point, but that would be between kernels (functions), not between init and kernels
<whitequark>
that's actually the same thing
<whitequark>
hm, no, not really
<sb0>
in any case, there is no time for that right now
<whitequark>
since currently allocations inside a kernel will never survive termination of that kernel
<whitequark>
sure.
key2 has quit [Remote host closed the connection]
ylamarre has joined #m-labs
ylamarre has quit [Read error: No route to host]
ylamarre has joined #m-labs
<sb0>
rjo, another argument against traits. the order of arguments is not guaranteed (due to the use of a python dictionary internally) resulting in a lack of control of the widget order in the GUI
<sb0>
and yes, there are hacks and workarounds against that, but the bottom line is I don't like this traits stuff
<whitequark>
traits?
ylamarre has quit [Read error: No route to host]
ylamarre has joined #m-labs
<sb0>
a library whose main feature compared to the current system is to replace things like self.attr_parameter("xxx") in build() with xxx = Parameter() at the class level
<sb0>
and which also has lots of missing features that artiq needs.
<sb0>
and is complex.
balrog has quit [Ping timeout: 255 seconds]
balrog has joined #m-labs
* sb0
just noticed HK has 73x the population of Boulder, CO and about the same number of GitHub users
<whitequark>
an amazing feature of ELF is that you cannot enumerate all the exported symbols in a dynamic library
<whitequark>
the format does not give you the size of the symbol table or the amount of entries.
<cr1901_modern>
can't one of readelf's options show all the symbols? So you could keep a counter or something for each string you parsed? *confused*
<cr1901_modern>
sb0: What's significant about Boulder?
<whitequark>
there's a hash table for symbol lookup in the library
<whitequark>
if you traverse the entire table and look at the highest index it mentions, you get a lower bound on the symbol table
<whitequark>
which is what readelf uses
ylamarre has quit [Quit: ylamarre]
<sb0>
hippies, dietary supplements, homeopathy, yoga, and sometimes, science
<cr1901_modern>
So you'd fit right in is what you're saying? :P
<whitequark>
you don't seem to like boulder very much.
<sb0>
oh, it's not too bad. just joking :)
<sb0>
and it definitely is an interesting place for science/tech.
<cr1901_modern>
And nice views. I almost was about to say I knew it as a vacation retreat, but that's Aspen* lol
<sb0>
yeah, parks/mountains are nice too. and beer :)
bentley` has joined #m-labs
<cr1901_modern>
Lol, yes. Beer is good (if made well). I really only drink it to augment my food tho, not socially.
mithro has quit [Remote host closed the connection]
<cr1901_modern>
sb0: In mibuild/xilinx/programmer.py, FpgaProg class, how can you specify the address at which to load the data_file (the function will raise if address != 0)
<sb0>
the exception error message is pretty clear about what the problem is.
<sb0>
use xc3sprog, or better, openocd
<sb0>
if openocd works well with all boards, we can probably trash all other programmers in mibuild
<cr1901_modern>
I thought you were against using openocd b/c of the meritocracy approach for approving changes?
<sb0>
in the worst case, that can be solved by forking
<sb0>
the code quality of xc3sprog and fpgaprog is a more annoying issue
<cr1901_modern>
In any case, ignore the patch I sent for mercury programmer support. It's a stop gap.
<cr1901_modern>
I can just add support for it into my local files until I figure out how OpenOCD can support it
<cr1901_modern>
(basically, it's bitbanging an SPI interface using libftdi with specific pins)
<cr1901_modern>
That awkward moment when you realize that the code you wrote was in fact a waste b/c you didn't do your research o.0;
Gurty has quit [Ping timeout: 250 seconds]
Gurty has joined #m-labs
mithro has joined #m-labs
ylamarre has joined #m-labs
<whitequark>
ok, the runtime parts should be finished
<whitequark>
let's try the idle experiment...
<rjo>
whitequark, sb0: how is the fixing of CI coming along?
<rjo>
sb0: i'll let it sink in. maybe once you have implemented notification/verification etc the situation is a bit clearer.
<rjo>
sb0: gui element ordering alphabetic is ok. the Experiment Hierarchy will automatically do grouping. Also the pdb is only alphabetically ordered. That matches the Experiments.
<rjo>
gui conscious experiments would want to override the automatic building of the gui anyway.
<rjo>
you are misrepresenting traits. it is certainly not complex compared to what your implementation will be once it it complete.
_whitelogger____ has joined #m-labs
mithro has joined #m-labs
aeris has quit [Ping timeout: 255 seconds]
aeris has joined #m-labs
mumptai has quit [Ping timeout: 250 seconds]
mumptai has joined #m-labs
aeris has quit [Read error: Connection reset by peer]
aeris has joined #m-labs
<GitHub22>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vOJxa
<cr1901_modern>
whitequark:https://twitter.com/whitequark/status/626897235717046272 Is this the reason that closures essentially require GC? I.e. get around the "lifetime problem"?
<whitequark>
well, no, Rust has closures without GC
<whitequark>
but to get Python's "look and feel", yes, you will need it
<cr1901_modern>
Good point: What's different about Rust's closures- the ones that escape the scope where they are defined and have to be malloc'ed? I.e. "closures with deterministic lifetimes"
<whitequark>
Rust closures don't have a true existential inside; their type depends on the type of elements of their environment
<whitequark>
and their lifetime is tied to the lifetime of those
<whitequark>
in other words, they are less powerful than closures in a dynlang
<cr1901_modern>
Huh, so every single environment with different types of variables forms a different type in Rust?
<cr1901_modern>
different type of closure*
<whitequark>
no, it's only the lifetimes
<cr1901_modern>
Oh! I see... that means it's not actually possible to make a closure that escapes the scope where it's defined, doesn't it? Once the variable in the largest scope goes out of scope, the closure has lost it's environment.
<whitequark>
smallest
<whitequark>
but yes
<GitHub145>
[misoc] whitequark pushed 3 new commits to master: http://git.io/vOUuv
<GitHub145>
misoc/master 9031405 whitequark: Implement a dynamic linker.
<GitHub145>
misoc/master eb643f1 whitequark: Export _cache_init from crt0.S.
<whitequark>
sb0: ok the linker is implemented and works
<whitequark>
i was looking at mailbox.c though and one thing baffles me
<whitequark>
it flushes dcache in mailbox_receive but not mailbox_send_and_wait
<whitequark>
which strikes me as something that doesn't make sense
<cr1901_modern>
Okay, read the Rust documentation: As I understand it, closures CAN escape the scope where they were defined, but it's done by actually moving the captured environment where up stack frames. So the scope problem doesn't disappear. Ick.
<cr1901_modern>
I need to go back to that Boehm paper I was reading before I get in over my head. Thanks for the help!