<cr1901_modern>
sb0__: I was unable to get an answer on how to fix the view problems on qt forums. I'm currently implementing a double slider in the link rjo gave to me and moving all the shared code to that file. Give me an hour and I'll update you. I'm knocking this out this morning.
<cr1901_modern>
(I don't think I'll be done in an hour. I'm just going to ping at semi-regular intervals)
sb0__ has quit [Ping timeout: 252 seconds]
sb0___ has joined #m-labs
FabM has joined #m-labs
sb0___ has quit [Ping timeout: 252 seconds]
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<sb0__>
"Threads in other processes can open a handle to an existing semaphore object by specifying its name in a call to the OpenSemaphore function."
<sb0__>
so your idea of shared memory IPC (with the notification problem) can actually be done portably.
sb0__ has quit [Ping timeout: 252 seconds]
<whitequark>
sb0: so, futexes+devshm on linux and shared memory+semaphores on windows?
sb0__ has joined #m-labs
<sb0__>
there are sysv semaphores too... but anyway, pipes seem better supported by asyncio
<sb0__>
i'm on some shitty hotel wifi right now that blocks everything except http and disconnects you every hour, sending you to a page telling you to accept their conditions (again)
<sb0__>
interestingly, windows doesn't support overlapped IO on anonymous pipes, only named ones...
<sb0__>
i guess this comes from this stupid overlapped flag you need to specify at file open time and cannot change later
<sb0__>
since you cannot know if the other end of the pipe will need overlapped or not
<sb0__>
and instead of fixing this crap, microsoft developers implemented remote connections to named pipes. pure mission creep. one would use TCP in this case...
<sb0__>
oh, actually windows named pipes should be easy with the (undocumented) ProactorEventLoop.create_pipe_connection() ...
<sb0__>
they're bidirectional, even
sb0__ has quit [Ping timeout: 252 seconds]
sb0__ has joined #m-labs
<sb0__>
i wonder how many applications that define a signal handler process -EINTR without bugs
<rjo>
sb0__: i'm happy to get the heat for the artiq->artiq.language transition. ok if i just go ahead?
<rjo>
or does anybody have a significant thing pending that this would conflict with?
<sb0__>
rjo: ok. just make sure to inform Joe or there will be drama again...
<rjo>
sure. there iwll be an email
<rjo>
will
<rjo>
sb0__: why are the PHASE_* constants handled specially in the imports but not all the other things from coredevice.dds?
<sb0__>
the other things are normally created via the DDB
<rjo>
ah. ...or emitted byt the compiler.
<sb0__>
importing them in artiq is not the best thing to do, so if you have a better idea, I'm all ears
<rjo>
make them attributes of DDSBus?
<sb0__>
of course, they could easily be defined as self.dds.PHASE_*, but that makes the syntax cluttered
<rjo>
anyway i feel there is a "DDS_" missing in the constant name
<rjo>
or string them
<sb0__>
that would work... assuming the new compiler is smart with strings (the old one was not)
<rjo>
set_phase_mode("tracking")
<sb0__>
whitequark: can the new compiler do constant folding/propagation and DCE with strings?
<rjo>
ah. right. that might be nasty.
<whitequark>
sb0__: for a dozenth time, it can (this is a trivial IR transform), but i don't think it should do it in ways that affect semantics, because of what I have described many times
<sb0__>
well, more than that would be needed, as the phase mode is stored in the object
<sb0__>
what would actually be needed is some sort of string -> int map that is built at compile time
<whitequark>
(well, not entirely trivial, monomorphism checking has to be moved later and i have to be able to represent untyped code in IR, but it doesn't need much labor)
<whitequark>
can you elaborate on the problem with DDS constants? I don't understand it
<whitequark>
set_phase_mode("tracking") is gross
<rjo>
it is pythonic
<rjo>
at least half-pythonic
<whitequark>
frankly, if yes then being pythonic is wrong
<whitequark>
well, whatever, not like my opinion of the language can get worse
<whitequark>
anyway, yes, I can support what you want quite elegantly
<rjo>
problem is objects being created (in self) but other material from the module does not end up in the namespace
<whitequark>
the string literals will become polymorphic in their type and they would automatically coerce to anonymous sum types
<whitequark>
this is basically how integer literals work (you can compare int32's and int64's to zero, for example), but applied in a different way
ylamarre has quit [Quit: ylamarre]
<rjo>
and the comparison and the argument are folded?
<whitequark>
the strings used in such a fashion are interned, so comparisons on them are just pointer comparisons
<whitequark>
I can also give LLVM the information about exhaustiveness, but that's unlikely to matter outside very hot code
<sb0__>
whitequark: i'm sure it can, my question was whether it does. there isn't much time for more compiler stuff right now...
<whitequark>
rjo: note, you will not be able to pass a string to such a method from an RPC.
<whitequark>
(this is implementable but requiers lots of runtime machinery, which i think we don't have time to make)
<rjo>
ack. sounds complicated enough to not do any of this right now.
<rjo>
otoh, i have nothing against artiq.language cross-importing lots of things from artiq.coredevice, especially since a large part of the language is a language for the coredevice.
<sb0__>
maybe the PHASE_* constant can be put into a 'generic DDS' module... but that would be a very small one.
<sb0__>
*constants
<rjo>
and then be part of the language?
<whitequark>
rjo: it is not very complicated
<sb0__>
for a wide definition of language, yes
<whitequark>
rjo: actually, you can use it right now, string literals are *already* interned
<whitequark>
(but you get a small performance hit because it falls back to strcmp)
<rjo>
sb0__: specifically it would be artiq.language.dds(_constants)
<sb0__>
sounds ok
<rjo>
whitequark: no need ;)
<rjo>
sb0__: ack.
<rjo>
sb0__: but then there would be something similar for 'from artiq.coredevice.exceptions import RTIOUnderflow'
<sb0__>
yes...
<sb0__>
maybe have "artiq.common" that imports the commonly-used stuff in experiments...
<sb0__>
from both language and coredevice
<rjo>
or we can just elevate these constants/exceptions, little tools to artiq.coredevice and then experiments can do "from artiq.language import *" and "from artiq.coredevice import *"
<rjo>
that's the latter
<sb0__>
two imports instead of one...
<rjo>
that would be fine by me.
<rjo>
or we put both of them (and maybe others) into "from artiq.experiment import *" and recommend that.
<sb0__>
yes
<rjo>
ok. i'll do that then.
<rjo>
also. have you silently agreed to relative imports ("from . import stuff")? whitequark is using them heavily in compiler but i remember it caused problems if you are running from artiq top level and do not have PYTHONPATH=. and artiq is not accessed through sys.path
<whitequark>
oh yeah there was something like that
<whitequark>
i think whatever change was necessary to my workflow was so simple that i never managed hit that again
<whitequark>
i /think/ doing python setup.py develop --user does some symlink magic that alleviates that?
<rjo>
yes sure. i remember pointing that out when it came up. but still. we should agree that relative imports are ok (or not).
<whitequark>
i say develop --user is unobtrustive enough
<GitHub63>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vzP9Q