05:03 <sb000> whitequark: you forgot the playback trigger slowness

05:06 <whitequark> I didnot

05:06 <whitequark> just the wrong keyword for github

05:07 <whitequark> sb000: there's a problem though

05:07 <whitequark> we are currently unable to create user-defined objects on the core device

05:07 <whitequark> so that will have to be implemented first

05:07 <whitequark> which is what I'm doing

05:44 <sb000> is that a lot better than using integers?

05:48 <whitequark> um

05:48 <whitequark> that's the only way to make it safe, I think

09:55 <whitequark> hrm, user-defined objects are a really hairy thing

09:55 <whitequark> I think I should do some stopgap solution...

10:04 <whitequark> hm, there's nothing I'm super happy about

10:17 <whitequark> the "file descriptor" solution is bad (there's an ABA problem); the "handle" solution is bad (object creation is quite hard, and addresses leak into ARTIQ Python land); the shared BTreeMap solution is bad (the people asking for fast replay will not be happy with mandatory string lookup)

10:19 <whitequark> well, whichever way we go, safety in ARTIQ Python is more or less forfeited. e.g. adding two CoreDMA devices makes it quite easy to crash the DMA core, at least.

10:19 <whitequark> actually, hm

10:19 <whitequark> that's still memory-safe for now, and you can't crash the SoC anymore, but with DMA input events I think it will not be safe.

10:22 <whitequark> I *suppose* we could make it safe for DMA input events by restricting that to some region of memory.

10:22 <whitequark> anyway, I digress.

15:20 <GitHub> [artiq] sbourdeauducq commented on issue #668: @cjbe Do you insist on this or can we close this pull request? https://github.com/m-labs/artiq/pull/668#issuecomment-294357134

15:28 <GitHub> [artiq] sbourdeauducq opened issue #721: github buildbot triggers broken https://github.com/m-labs/artiq/issues/721

15:28 <sb0> bb-m-labs, force build artiq

15:28 <bb-m-labs> build #1465 forced

15:28 <bb-m-labs> I'll give a shout when the build finishes

15:39 <bb-m-labs> build #519 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/519

15:39 <bb-m-labs> build #1465 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1465

16:27 <sb0> whitequark, what ABA problem exactly? if you use the counter trick it's fine, no?

16:28 <sb0> it's only "unsafe" because users can modify the integers manually, right?

16:28 <sb0> but a wrong integer would only result in a detectable error, or some random DMA sequence being played, afaict

18:30 <whitequark> ABA problem: let's say I give an integer to the user, then they erase it, then they get another handle, which is for a different sequence but happens to make the old one valid

18:30 <whitequark> that is very hard to debug

18:30 <whitequark> unsafe: it's probably safe as long as we only have playback

18:31 <whitequark> it's probably not going to be safe once we have DMA input

19:04 <GitHub> [artiq] cjbe commented on issue #668: Lets close it - I still think absolute imports are really useful, but this is not the right way of doing it.

21:27 <klickverbot> whitequark: I'm sure you thought this through, but couldn't you completely avoid the ABA issue in practice (i.e., unless you keep a handle alive for more than a year but cycle the others with kHz rate or something like that) with an epoch tag in the descriptor?

21:29 <klickverbot> (This is assuming that the handles are opaque on the Python side, which seems to be the only sane design decision, but I see how implementing user-defined value types might be tricky)

21:30 <whitequark> klickverbot: well, yes, we don't have user-defined types constructable on the ARTIQ Python side

21:30 <whitequark> value types or non-value types

21:30 <whitequark> and what this requires is a control flow analysis to ensure that every field is initialized

21:30 <whitequark> and that is not a project for one evening

21:31 <klickverbot> Yah, that's what I meant. And as for initialization, you can possibly cheat by only allowing default construction (with all fields explicitly given)

21:32 <whitequark> I don't think that works

21:33 <whitequark> I don't actually see any way to implement that without adding some sort of implicit default value

21:33 <whitequark> for every type

21:33 <klickverbot> Why not? Of course, you need a canonical list of fields somewhere (which is usually implicit in Python), but if you have type Foo with fields a and b, you only ever allow Foo(a, b)

21:33 <klickverbot> The (trivial) constructors then can't unwind, etc., so you don't have that sort of issue

21:34 <whitequark> if you have a __init__ then semantics diverges

21:34 <whitequark> if you don't have a __init__ then Foo(a, b) is invalid

21:34 <whitequark> also, the constructor is the key for type inference here, I am quite sure

21:34 <klickverbot> Oh, right, forgot about that. Make it artiqpy.make(Foo, a, b) or something like that then

21:35 <whitequark> ew.

21:35 <whitequark> no.

21:35 <whitequark> that's not even significantly less work

21:35 <whitequark> I have to add an AST (or IR) matcher for this construct, verify every corner case...

21:36 <whitequark> it's not an evening project either

21:36 <whitequark> conversely, verifying that all fields are initialized isn't *that* hard, it's just a lattice

21:36 <whitequark> we actually already do that for variables

21:36 <klickverbot> You don't need control flow analysis, and I assumed "intrinsics" like that were cheap to add. But of course, if you can do a proper job with the other option, it might be preferrable

21:37 <whitequark> intrinsics are cheap to add, but this isn't an intrinsic

21:37 <klickverbot> Hm, true (already doing it for variables)

21:38 <klickverbot> I guess you are referring to needing to match/look up the type parameter on the AST level for that make construct?

21:39 <whitequark> it's just a really weird construct overall

21:41 <whitequark> like it's not that it doesn't fit, it's that it duplicates machinery that's already there

21:41 <whitequark> all we're missing hs proper handling of the __init__ function

21:42 <klickverbot> Not if you come from a language with generics – make!Foo(a, b) would be natural in D (or make<Foo>(a, b) in C++). But yeah, I agree that your proposal is probably better, since you can just constrain the admissible programs to fit your CFA (and are already doing that anyway)

21:43 <whitequark> um, no

21:44 <whitequark> in a language with generics type-level and value-level parameters are separate

21:44 <whitequark> unless it's dependently-typed but those are a whole separate bag of hell

21:50 <klickverbot> Of course (well, it's type- *and* value-level for one of them in C++/D, s/generics/templates/ if that's closer to your favourite terminology), but as I amused to reading that style of code, the make(Foo, …) thing just parses as the Python equivalent of that

21:53 <klickverbot> (From my personal experience only of course, but that's one after reading lots of D and modern C++ code, and working on compilers for both)

21:56 <klickverbot> Anyway, no non-trivial destructurs and being able to do with quite limited CFA definitely changes my feeling from "you don't want to be doing this" to just "not a project for one evening". So: Have fun. ;P

22:05 <klickverbot> (Hmm, another bad idea for just requiring a trivial __init__: Use a class decorator that is recognized by the compiler and just generates the corresponding __init__ for regular Python. Probably still not worth it, though.)