<sb0>
rjo, for the browser, I propose this workflow :
<sb0>
opening a HDF5 pops a new window with the argument editor, and those arguments come entirely from the HDF5
<sb0>
there is no experiment associated with it at some point. at the bottom of the argument editor, there is a filename entry (might be initialized to something sensible) to associate an experiment.
fengling has quit [Ping timeout: 240 seconds]
<sb0>
*at this point
<sb0>
there is also a "class name" entry, which is initialized from the hdf5 and typically untouched
<sb0>
there won't be much code shared with the dashboard's ExperimentManager
fengling has joined #m-labs
<rjo>
i have no particular prefference. since that tuple is what start_time serializes to there is probably a reason for it. it would also be very relevant when matching on equality.
<sb0>
afaict the reason is only that the structure is tuple-like, so h5py treats it as an array
<rjo>
why do you want to _not_ associate an experiment with the results of an experiment?
<sb0>
I imagine users will be tweaking a local copy of the experiment code when re-analyzing
<sb0>
so the association should be weak
<rjo>
yes. but is should be there.
<rjo>
on start_time: i would be hesitant to use a float unix timestamp here.
<sb0>
initializing the filename field sounds sufficient to me
<rjo>
fine with integer ns/us/ms
<sb0>
with root path preliminary configured browser-wide by the user + path from the hdf5
<sb0>
(expid)
<sb0>
and it should display the commit id somewhere, but I don't think it should check out
<sb0>
at least not automatically
<sb0>
as convenience, we can have a "check out repository in temporary folder and position filename filed" button
<rjo>
it needs to check out to build the correct experiment dock.
<sb0>
not if the worker adds the argument descriptions to the hdf5s
<rjo>
we don't do that currently.
<rjo>
it also needs to chack out if you want to run a different revid on the data.
<sb0>
no, you check out manually
<sb0>
and use the file selector
<sb0>
that's the point of the weak association, not reinvent a git ui
<rjo>
that is an ugly, slow and complicated work flow.
<sb0>
plus the case of tweaking a local file
<sb0>
how do you list the revids?
<rjo>
it's already there in the dashboard.
<rjo>
no listing. a field.
<sb0>
what is already there?
<sb0>
yes, but how will the user fill in that field?
<sb0>
git log, right? they might as well type git checkout right after that
<rjo>
the ability to "tweak an experiment"
<rjo>
and the ability to run specific revisions.
<rjo>
nobody wants to reinvent a git gui
<rjo>
it's the same infrastructure, the same ui experience and a very analogous workflow.
<rjo>
the user fills in/changes the revision field the exact same way they do in the dashboard.
<sb0>
ok, so we keep the first part of the workflow (opening a hdf5 gets all the arguments without touching the repos)
<sb0>
but instead of having only a filename entry, we can specify things in the repository
<sb0>
when re-analyzing
<sb0>
yes, we don't store the argument descriptions in the hdf5 right now, but that's a dozen lines of code compared to having threads and what not in the GUI
<rjo>
threads?
<sb0>
and reprocessing old hdf5 files, if any, to add argument descriptions is also straightforward
<sb0>
yes, or subprocess, you'll want to do the repo checkout + examine asynchronously, to avoid freezing or crashing the GUI
<rjo>
subprocesses need to be done anyway to run the workers
<rjo>
no threads.
<sb0>
still more complicated
<sb0>
than adding descriptions to hdf5
<sb0>
plus, with the descriptions, you can view the arguments in the browser without configuring the repos
<rjo>
but to extract a desccription of a repo experiment you need that infrastructure.
<rjo>
if you associate a different experiment with the data.
<sb0>
the master/worker has it
<sb0>
and that different experiment needs to have the same argument signature, there is no way around that
<sb0>
otherwise it's not even a replay, more some external python script that processes a hdf5 in a certain way
<rjo>
different experiments don't need the same signature.
<sb0>
why would you run them on the same data?
<sb0>
and if they have wildly different arguments, what to do with the arguments from the h5 expid?
<rjo>
what i would do is this: a) be able to build an experiment dock from an hdf5: get the arguments from the hdf5, their ui description from somewhere, fill in rev, logging verbosity etc. b) build an experiment dock from a specific file, arguments and ui description as from build(), run that thing on the current data.
<rjo>
needs all the inspection/subprocess handling infrastructure for b)
<rjo>
can use serialized (in h5) or reconstructed (from the repo) ui description for a)
<rjo>
the revid ui field in a) would be read-only.
<sb0>
what is the use case for a)? tweaking fit arguments?
<rjo>
serializing the ui into the hdf5 seems problematic for several reasons.
<rjo>
yes
<sb0>
why is that problematic?
<rjo>
and actually seeing what the arguments/revid/logging verbosuity/start time were.
<rjo>
that schema is tricky. how do we manage changing ui formats for the future? forward/backward compatible serialization schemata.
<sb0>
same problem with the argument values, especially the complicated ones like scans
<rjo>
no. not the same problem. with argument values we pay specific attention to simplicity and future-proofness.
<whitequark>
bb-m-labs: force build --props=package=pygit2 conda-all
<bb-m-labs>
build forced [ETA 4m12s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
you are now mixing in a serialization of the user interface state.
<rjo>
that API does not need to bridge historic hdf5 data and current code.
<sb0>
checking out repositories is slow, examine is slow, the experiment may import something that is not available on the browser machine and arguments cannot be viewed
<rjo>
then they can't be run either.
fengling has joined #m-labs
<sb0>
the user may not configure or want a repository
<sb0>
well, for this one, there is the "bare filesystem" backend
<sb0>
but it still needs configuring
<whitequark>
hmm, debug symbols don't seem to be installed...
<rjo>
then let's decouple all of this: implement a read-only way to see expid. and implement open-dock-from-local-file.
<rjo>
no ui-serialization, no git involved at all.
<rjo>
inspection only on open-dock-from-local-file.
<rjo>
then the user can use git or not as they like.
<rjo>
the read-only way to see expid could either be in the listview (then multiple columns)
<sb0>
something like the datasets dock?
<sb0>
which behaves the same, too
<rjo>
or it could be its own dock. yes.
<sb0>
probably, we also want something to load (or attempt to load) the expid arguments into a dock-from-local-file
<whitequark>
bb-m-labs: force build --props=package=libgit2 conda-all
<sb0>
and same in the dashboard: load h5 expid arguments into a experiment dock
<bb-m-labs>
build forced [ETA 2m55s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
the actual experiment replay (including build()/prepare()/run() as well) from an hdf5 still needs to be done. but that looks more like a job for the dashboard.
<sb0>
recompute all arguments runs from the last scanned revid, changing that so it takes into consideration the revid field in the GUI may be the right thing to do
<rjo>
hmm. they probably will. for current changes it's not that dramatic because they can just close and reopen. but for old stuff this is a bit nasty.
<rjo>
that artiq_client scan-repository old-revid has a couple sideffects, right?
<sb0>
close/reopen doesn't change arguments, "recompute" does
<rjo>
yes. recompute.
<sb0>
yes, that's not a good technique
<sb0>
and it's slow
<rjo>
what happens if an experiment corresponding to a dock disappears due to repo-scan?
<sb0>
clicking run will error
<rjo>
yeah. at some point we have to think about the repo-scan, the ui-building, the repo-checkout and caching...
<rjo>
ok.
<rjo>
hmm. how about you look into doing the dasboard "set-arguments-to-values-from-hdf5"?
<rjo>
then we can reuse a lot of that stuff for the browser.
<sb0>
I don't think that much can be reused
<sb0>
what I'm going to do is wire recompute arguments to the revid widget
<rjo>
so automatic recompute?
fengling has quit [Ping timeout: 240 seconds]
<sb0>
+ automatic recompute with a load from the h5 expid arguments at the end
<sb0>
standard file open dialog box, select h5, then the process is: set revid, recompute all arguments, set all other fields
<sb0>
do we want to save current arguments to h5 (from the dashbord) as well?
<rjo>
ack.
<rjo>
we are saving them with expid.
<sb0>
and ok i'll do that then
<rjo>
good. then i'll do the ExperimentManager/Dock for these experiments in the browser. Unless you have stuff in the pipeline there.
<rjo>
I'll look at that read-only expid widget later.
<whitequark>
sb0: okay, I have debug symbols and everything
<whitequark>
this has shed exactly no light on the root cause of the problem
<whitequark>
it's crashing while trying to read the entirety of ...repo/.git/config
<whitequark>
the fd is valid (it's successfully did stat on it just before), the buffer is valid (allocated just before with the right size), the count is valid (less than buffer size)
<whitequark>
more importantly, why does msvcrt decide to crash???
<whitequark>
oh
<whitequark>
I disassembled the relevant part of msvcrt and just before crashing it sets errno to -EBADF
<sb0>
rjo, no, I didn't touch that
<whitequark>
sb0: *facedesk*
<whitequark>
of COURSE it does not work
<whitequark>
python is linked with msvcrt140 and libgit2 uses msvcrt120
<whitequark>
you were right, it's an ABI incompatibility, though unrelated to calling conventions, of course
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.2/20160407164938]]
<sb0>
whitequark, thanks
<rjo>
we should also change that start_time format for release-1 even though it changes the format. it will be a mess otherwise.
<whitequark>
rjo: I'm not particularly interested in wasting many more hours figuring out what sort of obscure bugs conda has in that code
<rjo>
are you saying that you are not going to bitch around and fix it without complaining if this breaks again because the packages were not built properly?
<whitequark>
oh, I'm going to complain in either case
<rjo>
that's what i thought.
<whitequark>
btw, right after I figured out the bug, I spent some time figuring out how to add that dependency
<whitequark>
of course, it's completely undocumented
<sb0>
there is no start_time in release-1
rohitksingh1 has quit [Ping timeout: 250 seconds]
<rjo>
let's cherry-pick the changes that add expid and start_time then.
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0>
rjo, ok, go ahead. you are most familiar with those changes
<rjo>
ack
<whitequark>
sb0: any more changes you'd like to get into 1.0?
<sb0>
for 1.0 no
<sb0>
but there is a pile of 2.0 items...
<whitequark>
ok, I will do those.
<sb0>
whitequark, where would you get a kit for terminating fibre optics?
<whitequark>
you realize you're looking at ~$3k, right?
<whitequark>
otherwise I can dig out the name of a good chinese vendor
<whitequark>
sb0: it might mke a lot of sense to rent it and not buy, I think.
<sb0>
ah nevermind, i found the magic strings to type into taobao to get all sorts of nice pre-assembled fibers