Back
[00:52:16] <jmkasunich> jepler: around?
[00:52:57] <jepler> jmkasunich: at the moment, but not for long
[00:53:14] <jepler> we have to make pesto out of the basil ingrid harvested out of the garden on sunday before our first freeze
[00:53:17] <jepler> big job
[00:53:22] <jmkasunich> ah
[00:53:44] <jmkasunich> I've been thinking about halscope
[00:54:13] <jmkasunich> I'd like user A to be able to capture some data, post it, and have user B be able to open that file and pan, zoom, etc, without having the same HAL config running
[00:54:26] <jepler> yeah that would be very nice
[00:54:35] <jmkasunich> I don't know whether that viewer should be another binary, or another mode, or somehow be tied into halscope modelessly
[00:54:45] <jmkasunich> there are a lot of things you can't do when viewing someone elses file
[00:55:06] <jmkasunich> like change sample rate, memory depth, trigger source, channel selections, etc
[00:55:11] <jepler> it seems like it should share substantial code with halscope, though -- horizontal and vertical
[00:55:16] <jepler> and of course the drawing code itself
[00:55:25] <jmkasunich> yes, definitely don't want to duplicate code
[00:55:33] <jepler> 5% of me thinks it's time to write halscope2 with all the new features we want
[00:55:37] <jepler> maybe 10%
[00:55:39] <jmkasunich> heh
[00:55:54] <jmkasunich> halscope1 is definitely not well designed
[00:56:14] <jmkasunich> 1st non-trivial gui project, and it shows
[00:56:26] <jmkasunich> it is rather tightly tied to the presence of a working HAL
[00:57:06] <jepler> I'd try the incremental approach first. step 1) allow loading traces 2) don't require running hal
[00:57:40] <jepler> once step 1 is done I bet step 2 is not that hard .. remove some "error checking" and grey out / delete some controls
[00:57:40] <jmkasunich> well, 1 is by far the bigger chunk
[00:57:48] <jmkasunich> gotta disable a lot of stuff
[00:58:48] <jmkasunich> from a UI point of view, how would a user decide "I want to view a stored file, disable all that stuff", vs. "I want to prepare to capture a trace, so I need to set all my channels to point to things that exist in MY hal, etc"
[00:58:53] <BigJohnT> so you have a save to file, and a playback mode so to speak...
[00:59:49] <jmkasunich> yeah, playback, view, whatever you want to call it
[01:00:09] <jmkasunich> I almost think the viewer should be a separate user space app
[01:00:28] <cradek> jmkasunich: 'read the data file' could switch to the viewer mode - maybe selecting a thread again would go back to normal
[01:00:37] <jepler> possibly, "load trace" would go into "view only" mode if the signals/pins/parameters to be scoped don't all match up with the current configuration, and "clear" / "load config" would get back into a sampling mode.
[01:01:27] <cradek> seems like the gui could work several different ways - it's not the hard part
[01:01:43] <cradek> heck if a command line argument starts it in view mode, that's good enough for the first try - who cares
[01:02:03] <jmkasunich> you gotta be kidding
[01:02:08] <jmkasunich> this project is all about the GUI
[01:02:15] <cradek> really?
[01:02:20] <jmkasunich> reading a file into the memory buffer is trivial
[01:02:29] <jmkasunich> displaying it once its there is trivial
[01:02:44] <jepler> you got peanut butter in my chocolate!
[01:02:52] <jepler> it sounds like you guys each volunteered to write half of this
[01:03:07] <cradek> maybe so
[01:03:48] <jmkasunich> the code to do display is already there - the hard part will be figuring out how many lies we have to tell it to prevent it from barfing when things don't match up
[01:04:10] <cradek> I already put "File/Open Data File" on the menu. I'll add "File/Close Data File" and call it good design, if that would help you get started
[01:04:25] <cradek> yes that's what I figured was hard about it
[01:04:49] <jmkasunich> I'm sure I could figure out how to add another item to the menu
[01:04:49] <cradek> I guess I don't know the design/structure of the data handling
[01:05:04] <jmkasunich> the design/structure is very ad-hoc
[01:05:07] <cradek> I agree
[01:05:18] <cradek> so what can I do to help?
[01:05:37] <jmkasunich> help me decide what is the right way to do it
[01:06:13] <jmkasunich> had to create a thread before I could even load halscope - that is an annoyance right there
[01:06:33] <jmkasunich> I agree that maybe "hal-free" operation is step 2, but it should be in mind from the beginning
[01:06:54] <jmkasunich> ok, I'm finally looking at it
[01:07:10] <jmkasunich> I wonder if there is an equivalent to "grayed out" for sliders in GTK
[01:07:12] <cradek> so when it's in view mode, however it gets there, the following are greyed out: 'samples' 'run mode' 'trigger'
[01:07:38] <jmkasunich> right
[01:07:52] <jmkasunich> and the "selected channel" button
[01:07:52] <cradek> also the 'pick the pin' button at the bottom will show the pin name but not be a button
[01:08:32] <jmkasunich> offset should still work, dunno about "chan off"
[01:08:53] <jmkasunich> trigger source and rising/falling buttons should display but not be pushable
[01:08:57] <cradek> chan off could hide that channel - you can turn it back on with the number button
[01:09:09] <jmkasunich> yeah, thats what I was thinking
[01:09:10] <cradek> yes I was just thinking that
[01:09:51] <jmkasunich> this is gonna take some code studying
[01:11:10] <jmkasunich> practically the first thing the program does (after parsing the command line) is connect to HAL
[01:11:25] <jmkasunich> I really think that problem should be solved first
[01:11:52] <jmkasunich> in fact, connected/not-connected is the state variable that should control all the other stuff maybe?
[01:15:54] <cradek> that sounds reasonable
[01:17:13] <jmkasunich> currently it connects on startup, bails if no HAL, loads scope_rt if not found, complains if scope_rt isn't running at least a few times per second, sets up data structures to communicate with scope_rt
[01:18:03] <jmkasunich> it's so tempting to write "scope_viewer.c" and link it with most of the other modules (tweaked as needed) to make a new binary halscope_viewer
[01:18:17] <jmkasunich> instead of trying to make one program do two very different things
[01:19:08] <jmkasunich> is that horrible from a usability point of view?
[01:19:53] <cradek> mmmmmmm
[01:19:56] <cradek> I dunno
[01:20:43] <cradek> my gut says it seems unnecessary to have two separate programs, but I am having trouble saying why I think it's bad
[01:20:54] <jmkasunich> I'm in about the same boat
[01:21:08] <jmkasunich> I know it will be a lot easier to write (and probably have fewer bugs) as two programs
[01:21:29] <jmkasunich> but there's this nagging feeling that it's a cop-out
[01:22:48] <cradek> I think two programs would have more bugs
[01:22:56] <cradek> or rather, more divergence (bugs fixed in one)
[01:23:26] <jmkasunich> I certainly hope most code would be common to both
[01:27:09] <jmkasunich> wow, it looks like you get to do the graying and disabling of GTK buttons yourself
[01:27:39] <cradek> how else?
[01:27:49] <jmkasunich> there is a property to set the relief (make the button appear flat), but making it ignore clicks needs to be done separately
[01:27:58] <jmkasunich> I was hoping there would be a "disabled" property
[01:28:04] <cradek> oh I see what you mean
[01:28:15] <cradek> you have to do several things
[01:28:23] <jmkasunich> you probably also have to set properties on the contained label if you want to gray it
[01:32:12] <jmkasunich> I don't see any way to gray or disable a slider either
[01:32:32] <jmkasunich> the only sliders we need to disable are the trigger position and level ones
[01:33:12] <jmkasunich> if I did a separate program, I'd discard the trigger sliders, the Normal/Auto radiobuttons, and the Force button
[01:33:37] <jmkasunich> also discard the RunMode radiobuttons, and stuff the trigger level, source, and polarity displays into the runmode spot
[01:34:21] <cradek> can you undisplay them?
[01:34:46] <jmkasunich> dunno, still doing my GTK refresher course
[01:35:07] <cradek> if you shuffle the display much, you'll baffle people who have learned to use it
[01:38:23] <jmkasunich> true
[01:38:43] <jmkasunich> but taking up screen real-estate with sliders that don't slide and buttons that don't butt seems dumb
[01:40:18] <jmkasunich> I just thought of a use case where a separate viewer would be nice
[01:40:35] <jmkasunich> live halscope and viewer side-by-side
[01:40:41] <cradek> yes
[01:40:43] <jmkasunich> during tuning for example, you could have before and after
[01:40:46] <cradek> 'it did this yesterday'
[01:41:03] <jmkasunich> a button on the viewer to "read file from live instance" would be real handy
[01:41:13] <jmkasunich> when you are using the viewer for "it did this 30 seconds ago"
[01:41:14] <cradek> but note that is not an argument for separate apps: 'halscope --viewer-only'
[01:41:36] <jmkasunich> it is a complexity thing
[01:41:50] <jmkasunich> the modes are very different
[01:42:13] <cradek> the second halscope could even notice one is already attached and come up in viewer mode.
[01:42:31] <jmkasunich> it has to - since you can only have one live one
[01:42:50] <jmkasunich> as written today, it registers itself as a hal component, and you get a duplicate comp if you try to start another
[01:43:06] <cradek> gotcha
[01:43:25] <jmkasunich> the naming issue could be worked aroumd, but if it was _not_ prohibited, you;d get as mess as two GUIs try to control one sampler
[01:43:33] <cradek> yes, ick
[01:43:39] <cradek> no reason for that anyway.
[01:44:25] <jmkasunich> the main reason I want two progs is because it will practically need to have two main() functions
[01:44:53] <jmkasunich> changing modes after startup will be really messy
[01:45:32] <cradek> can you worry about that later?
[01:45:51] <jmkasunich> I don't see how
[01:46:02] <cradek> don't allow changing modes
[01:46:07] <cradek> halscope --viewer
[01:46:10] <cradek> or whatever
[01:46:31] <jmkasunich> that leads to an if/else at the start of the program
[01:46:34] <jmkasunich> which would be OK
[01:46:39] <jmkasunich> but converting it later, not so OK
[01:47:21] <jmkasunich> there are all kinds of things that simple aren't there when you aren't connected to HAL
[01:47:32] <jmkasunich> global vars like pointers to the shared memory structures
[01:49:48] <jmkasunich> this is gonna need refactored I think
[01:50:26] <jmkasunich> (to some degree anyway)
[01:51:02] <jmkasunich> for example, in scope_trig.c, I have init_trigger_mode_window(), which mostly sets up GUI widgets, but it also sets the trigger mode in the shared memory structure
[01:51:12] <jmkasunich> (which view mode won't have)
[01:52:02] <SWPadnos> whether you're connected to HAL or not may not be a good criteria for going into "viewer mode"
[01:52:20] <cradek> echo!
[01:52:38] <SWPadnos> instead of having two programs running, I'd probably want to load the saved trace data into the same program for display
[01:52:58] <SWPadnos> and I'd want to be able to link multiple channels together (offset/scale) so I can compare them easily
[01:53:04] <jmkasunich> SWPadnos: unless you want to view live and file side-by-side
[01:53:36] <SWPadnos> sure, you can look at them side by side, but overlaid on the same display is likely much more useful
[01:53:43] <SWPadnos> like stored traces on a digital scope
[01:53:48] <jmkasunich> then you need more buttons
[01:53:58] <SWPadnos> or you assign some channels as "saved traces"
[01:54:09] <jmkasunich> if the data file can contain 16 traces, and you have another 16 live traces, how do you tell them apart?
[01:54:20] <SWPadnos> you can't do that
[01:54:27] <SWPadnos> you can show 16 traces, live or saved
[01:54:38] <SWPadnos> (or more, if they're added)
[01:55:04] <jmkasunich> I think I get it - you are treating a trace as the thing that is saved and restored
[01:55:07] <SWPadnos> yep
[01:55:17] <SWPadnos> not the whole halscope state
[01:55:20] <jmkasunich> I'm planning to treat an entire acquisition as the thing that is saved and restored
[01:55:23] <cradek> interesting
[01:55:49] <SWPadnos> they're both useful, so you add some checkboxes to the load dialog
[01:55:49] <jmkasunich> I think traces as entities can get really messy
[01:56:00] <jmkasunich> what happens when you have traces with several different sample rates?
[01:56:05] <SWPadnos> load settings, load traces (maybe checkboxes for each)
[01:56:15] <SWPadnos> I'm not sure
[01:56:16] <jmkasunich> what happens when one has the trigger at 10% of the screen width, and another has it at 90%
[01:56:46] <SWPadnos> you could provide for offsets and scaling, but I don't think it's necessary
[01:57:02] <cradek> where you normally pick the channel source, the loaded traces could be another tab
[01:57:03] <SWPadnos> could be useful, but maybe not necessary
[01:57:08] <SWPadnos> sure
[01:57:14] <jmkasunich> I'm more interested in being able to get a single file from a user, and know that it contains a single event that I need to help him interpret
[01:57:25] <SWPadnos> there are several use cases
[01:57:33] <cradek> true that's the use case I always have, too
[01:57:40] <SWPadnos> one is the ability to look at data that someone else captured, with hardware that you don't have
[01:57:48] <SWPadnos> that's the "pure viewer" mode
[01:57:56] <jmkasunich> or even just a HAL config that I don't have or don't feel like starting
[01:57:57] <SWPadnos> (could use sim for that too)
[01:57:59] <SWPadnos> sure
[01:58:03] <cradek> I don't recall ever wanting SWPadnos's use case, but I also never thought about it.
[01:58:39] <SWPadnos> if you want to compare the PID tuning on several joints, you could save the final result of one, then change all the signals to another, but leave the previous one there as a target
[01:58:49] <SWPadnos> as a saved trace
[01:59:11] <SWPadnos> much harder to do when they're in separate windows
[01:59:48] <jmkasunich> overlaying traces might be nice, but managing all that data would be a nightmare
[02:00:10] <jmkasunich> the overlay only makes sense when the traces have the same sample rates, etc
[02:00:44] <SWPadnos> separate timebases for different traces is a SMOP
[02:00:57] <jmkasunich> but how would you display them?
[02:01:14] <jmkasunich> scale them to the same timebase, I hope
[02:01:20] <SWPadnos> the scope has arbitrary horizontal scaling, you just use different constants for each trace
[02:01:21] <jmkasunich> anything else would be very confusing
[02:01:29] <SWPadnos> oops "just" use different constants :)
[02:01:34] <SWPadnos> yes
[02:01:47] <SWPadnos> you don't have to resample, just display with a different horizontal scale
[02:01:59] <jmkasunich> so when you zoom out, one trace will be full screen width, another might only be 1/10 of the screen wide
[02:02:24] <jmkasunich> and as you zoom in, one will get "steppy", the other will remain smoother (higher sample rate)
[02:02:30] <SWPadnos> could be, but as you say, that's not very useful. I'll bet that would be an accidental occurrence more often than not
[02:02:59] <SWPadnos> so you could also just do it by sample number, and leave it up to the user to know that they're doing something that makes no sense (to us)
[02:03:11] <jmkasunich> ick
[02:03:18] <jmkasunich> would you have one file per trace then?
[02:03:29] <SWPadnos> (ie, I may want double the accel on one joint, so I might intentionally sample at half the rate on one run)
[02:03:40] <jmkasunich> ick ick ick
[02:03:57] <SWPadnos> no, I'd have all the traces and the setup in one file, but I'd allow you to selectively load things
[02:04:10] <jmkasunich> if the scale is Xms per div, everything on that screen should be Xms per div
[02:04:12] <SWPadnos> that's how my scope does it, incidentally
[02:04:15] <jmkasunich> otherwise you are lying
[02:04:17] <SWPadnos> heh
[02:04:50] <SWPadnos> the caveat to my scope is that it saves a screen-resolution trace, not a fully zoomable buffer. you get a drawing on the "backdrop", and it doesn't change scale
[02:04:59] <jmkasunich> for my most common use case (view all the traces in a single file, with nothing else), I want one-click loading
[02:04:59] <SWPadnos> that has its uses and drawbacks
[02:05:08] <jmkasunich> I shouldn't have to do anything on a per-channel basis
[02:05:09] <SWPadnos> sure, load, done
[02:05:25] <jmkasunich> SWPadnos: screen resolution is useless
[02:05:30] <jmkasunich> we can do that today with imagebin
[02:05:40] <SWPadnos> but not as a backdrop in the scope
[02:05:47] <SWPadnos> as I said, it has its uses and drawbacks
[02:05:59] <SWPadnos> (we don't do much with eye diagrams here, so it's mostly drawbacks)
[02:06:12] <jmkasunich> in my use case, that is useless - I can't run the live scope cause I have neither the hw, the time, or the desire to set up a HAL that will let me run it live
[02:07:21] <SWPadnos> well, you can force the user to use the same timebase and trigger position as the saved traces - error check at load time
[02:07:54] <cradek> SWPadnos: are you really arguing for screen resolution snapshots that can't be zoomed?
[02:07:55] <jmkasunich> we are talking about use cases that are so far apart we are talking past one another
[02:08:08] <SWPadnos> if they try to load from files with different timebases, let them choose whether to use the already loaded ones or the new ones
[02:08:09] <jmkasunich> in my mind, the presence of live mode is NOT a feature, it is a bug
[02:08:35] <SWPadnos> cradek, no, I'm not. I pointed out that that's a caveat when considering how my scope does things
[02:09:03] <cradek> oh, ok
[02:09:10] <cradek> I guess I don't care about that :-)
[02:09:12] <SWPadnos> regarding the ability to save/load setup or trace information
[02:09:17] <SWPadnos> or both
[02:09:39] <jmkasunich> the tek scopes we use at work have the ability to copy a trace to a "ref trace" and then to put that on screen
[02:09:45] <jmkasunich> which is sometimes nice
[02:09:57] <jmkasunich> but also broken, in that when you change timebase, the ref trace doesn't change
[02:10:06] <SWPadnos> right
[02:10:16] <SWPadnos> that's sometimes useful, but often times not
[02:10:37] <cradek> to me this is like "halscope should have a HPIB port to hook to my pen plotter" - so far from the use case we always have that it's silly
[02:10:55] <cradek> someone captures an event, we want to examine it
[02:11:02] <jmkasunich> right
[02:11:41] <SWPadnos> I think there are at least 3 use cases here
[02:11:52] <jmkasunich> if I am using it during tuning, I will use two screens side by side, one live, one viewer, and I'll want a button that does "save from live; load into viewer"
[02:12:05] <SWPadnos> 1) what we have now: live monitoring of a running HAL
[02:12:31] <SWPadnos> 2) the ability to load someone else's data so we can zoom around in it, without requiring HAL/RT/their hardware config
[02:12:32] <jmkasunich> 1a) review of an event captured on a running HAL
[02:12:40] <jmkasunich> (locally)
[02:13:00] <SWPadnos> that's 2 in my view - you can still look at stuff you captured if you can look at stuff others have captured
[02:13:09] <jmkasunich> you can do 1a today
[02:13:29] <SWPadnos> oh, without re-triggering, just looking at what you've got?
[02:13:56] <jmkasunich> yeah, 99% of what I do with a scope is "trigger on something that is weird, examine it till I understand it"
[02:13:57] <SWPadnos> 3) the ability to compare newly captured data with previously captured data
[02:14:01] <SWPadnos> right
[02:14:25] <jmkasunich> right now, when we attempt the "examine it" part, we are seriously handicapped
[02:14:35] <SWPadnos> are there any other use cases?
[02:14:51] <SWPadnos> oh, saving and loading a configuration, but I think we have that now
[02:14:56] <jmkasunich> yeah
[02:15:57] <jmkasunich> SWPadnos: if you reword 3 a little, it becomes easier
[02:16:20] <SWPadnos> well, I don't want to ;)
[02:16:29] <jmkasunich> instead of "compare newly captured data with previously captured data", say "compare two sets of captured data"
[02:16:43] <jmkasunich> the difference is that you are still in "view mode"
[02:16:54] <jmkasunich> and buttons that make no sense in view mode can be grayed out
[02:17:11] <SWPadnos> ok, not a problem
[02:17:13] <SWPadnos> you still have all the scaling problems
[02:17:32] <jmkasunich> to a degree
[02:17:44] <SWPadnos> if I change something in the trigger setup or offset and then hit the "move to viewer" button, there's the same issue
[02:18:12] <jmkasunich> I can see the viewer as a tabbed thing
[02:18:14] <jmkasunich> one tab per file
[02:18:25] <jmkasunich> and the ability to define a custom view tab
[02:18:34] <SWPadnos> hmmm. I think flipping between tabs is an icky solution
[02:18:41] <jmkasunich> on the custom view, the button that lets you select a trace is live
[02:18:47] <SWPadnos> and you still can't see all the traces on the same time scale at the same time
[02:18:54] <jmkasunich> instead of bringing up a pin/sig/param list, it brings up a trace list
[02:19:19] <jmkasunich> in a custom view tab, the traces would all be scaled properly
[02:20:10] <jmkasunich> so, two tabs called "test1" and "after-tuning" (or whatever the files are named)
[02:20:25] <jmkasunich> then create a custom tab, which starts with 16 empty channels
[02:20:27] <SWPadnos> or you can add a list of loaded traces to the "signal selector" dialog
[02:20:36] <SWPadnos> and have them on the live version as well
[02:20:45] <jmkasunich> select test1.foo, test1.bar, and after-tuning.baz for the first three channels
[02:21:10] <jmkasunich> if you want the viewer to interact with the live version, you get to write it yourself
[02:21:17] <SWPadnos> heh
[02:21:27] <jmkasunich> trust me, that would NOT be pretty
[02:22:09] <SWPadnos> yeah, the startup stuff is a problem
[02:22:23] <SWPadnos> but then again, you can run scope in sim, so that can be worked around
[02:23:05] <seb_kuzminsky> hi friends
[02:23:33] <SWPadnos> hi
[02:23:58] <jmkasunich> SWPadnos: sim still has to have a running HAL
[02:24:19] <SWPadnos> sure, but that's trivial and userspace
[02:24:30] <jmkasunich> no it is not trivial
[02:24:37] <SWPadnos> well, trivial because it already exists anyway
[02:24:52] <jmkasunich> just now I wanted to look at halscope to see what the screen looks like (which widgets need grayed, etc)
[02:25:00] <jmkasunich> this is a sim box
[02:25:58] <jmkasunich> I had to do halrun; loadrt threads name1=foo period1=1000000; loadusr halscope; start;" and I think a couple other clicks before I could see the scope
[02:26:12] <jmkasunich> if I'm trying to review a file from some user, none of that should be needed
[02:26:21] <jmkasunich> a viewer is exactly that - a viewer
[02:26:55] <SWPadnos> hmmm, ok, so the second use case isn't quite handled by sim
[02:27:11] <cradek> jmkasunich: my procedure: emc -l; click machine/halscope
[02:27:36] <jmkasunich> that assumes that you have a convenient working config around
[02:27:48] <cradek> everyone always has a variety of sim configs.
[02:27:54] <jmkasunich> heh
[02:28:00] <cradek> really
[02:30:13] <SWPadnos> it works, but I agree it's not ideal
[02:30:17] <SWPadnos> expedient but not ideal
[02:30:35] <SWPadnos> halscope --no-hal
[02:32:50] <jmkasunich> I guess I simply see the viewer as a _viewer_ rather than a mode of a larger tool
[02:33:43] <SWPadnos> a viewer would be fine, but I would also like to be able to load saved traces into a halscope that's conected to a running HAL and capturing live data
[02:34:16] <SWPadnos> I think whether they're two programs onr one is a code maintenance decision more than a usability decision
[02:36:31] <jmkasunich> SWPadnos: I think what you are asking is a much harder thing to do
[02:37:07] <SWPadnos> it may be, I'm just trying to define what the program might be used for
[02:37:22] <SWPadnos> then the tradeoffs between usefulness and implementation can be made
[02:38:54] <CIA-37> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder.c: must intialize modbus after loading ladder project now
[02:44:33] <seb_kuzminsky> ho hum, accidentally updated to top-of-trunk which is all borken
[02:44:49] <seb_kuzminsky> cradek: did you get my blurb about bzr
[02:44:54] <lerman__> lerman__ is now known as lerman
[02:46:52] <cradek> seb_kuzminsky: how is trunk borken? I think it's not bad now
[02:47:46] <seb_kuzminsky> it compiled, but when i tried to start it my machine locked up
[02:47:53] <seb_kuzminsky> could be an operator error on this side i guess
[02:48:11] <cradek> hmm
[02:52:37] <cradek> seb_kuzminsky: I did - I typed something in response earlier
[02:53:07] <jmkasunich> oh, that reminds me - I saw the discussion about testing earlier
[02:53:18] <jmkasunich> should I add the test suite (such as it is) to the compile farm?
[02:53:19] <seb_kuzminsky> cradek: oic, in #emc
[02:53:30] <seb_kuzminsky> jmkasunich: that would surely rock my world
[02:53:31] <cradek> do you see it? I was trying to find it.
[02:53:52] <seb_kuzminsky> cradek: i see it
[02:54:03] <jmkasunich> my main concern is that if tests cause lockups, nobody would know (since silence from the farm is considered success)
[02:54:16] <seb_kuzminsky> you want to see the end-points of lines of development that never got merged
[02:54:32] <cradek> seb_kuzminsky: I fixed a bunch of errant pointers earlier. it's possible I missed one and that's your lockup
[02:54:38] <jmkasunich> "never got" or "have not yet been"
[02:55:11] <cradek> for instance I wrote a new cutter comp. it is on a cvs branch. if I am hit by a bus (or more likely, have a bad backup system), someone can finish it in a year
[02:55:21] <seb_kuzminsky> sure
[02:56:01] <seb_kuzminsky> you want a list of branches then? whether they've been merged or not, and whether or not there's a local working directory?
[02:56:48] <cradek> ideally I want a thing like the image I showed you - not necessarily the image, but that kind of structure reflected in the main shared repository everyone pushes to
[02:57:16] <seb_kuzminsky> bzr tracks the information you want, but i think there's not yet a gui that shows it
[02:57:33] <cradek> I don't really care about the gui
[02:57:42] <seb_kuzminsky> "bzr heads" shows "all revisions in a repository not having descendants"
[02:57:53] <seb_kuzminsky> that means "all branch heads in the repo"
[02:58:07] <seb_kuzminsky> from that you can check out any branch, see its commit history, merge it, etc
[02:58:23] <cradek> man bzr
[02:58:32] <seb_kuzminsky> bzr help commands | more
[02:59:00] <seb_kuzminsky> note, this is on a branch basis, not a file basis
[02:59:39] <cradek> yes I understand the 'things' on the 'tree' are like change sets, not file versions (that's a feature)
[02:59:55] <cradek> chris@rover:~$ bzr heads
[02:59:55] <cradek> bzr: ERROR: unknown command 'heads'
[03:00:05] <seb_kuzminsky> bzr --version?
[03:00:16] <cradek> bzr (bazaar-ng) 0.8.2
[03:00:19] <seb_kuzminsky> ugh
[03:00:20] <cradek> (dapper)
[03:00:30] <seb_kuzminsky> well that wont work :-/
[03:00:38] <cradek> right, I have to find another one, I've done it before
[03:00:44] <cradek> some other deb repo ... somewhere
[03:00:47] <seb_kuzminsky> intrepid is on 1.6.1
[03:01:15] <seb_kuzminsky> there's always "bzr checkout lp:bzr" ... ;-)
[03:01:58] <cradek> deb
http://ppa.launchpad.net/bzr/ubuntu dapper main
[03:02:18] <jmkasunich> I'm lazy, how do I run the tests?
[03:02:22] <cradek> runtests
[03:02:32] <jmkasunich> from /src, or top level?
[03:02:40] <jmkasunich> src I see
[03:02:43] <cradek> anywhere after emc-enviornment
[03:03:00] <jmkasunich> ah, so I need to add emc-env to the buildscripts too
[03:04:50] <jmkasunich> cradek: I just did a fresh update and build of trunk, and 18 tests failed
[03:04:59] <jmkasunich> (sim, on dapper)
[03:05:21] <jmkasunich> doing a clean build
[03:05:51] <cradek> you didn't have hal or emc running did you?
[03:06:06] <jmkasunich> don't think so
[03:06:30] <jmkasunich> I just realized when you asked that I checked by doing lsmod and looking at the head of the list - useless on sim
[03:06:39] <cradek> Bazaar (bzr) 1.8
[03:06:43] <cradek> bzr: ERROR: unknown command "heads"
[03:07:03] <cradek> grrr
[03:07:23] <cradek> what version should I have??
[03:08:33] <seb_kuzminsky> cradek: sorry, you need the bzrtools plugin too
[03:10:32] <jmkasunich> I had HAL running, better (but not all better) now
[03:10:33] <jmkasunich> http://www.pastebin.ca/1239293
[03:10:40] <jmkasunich> what is test "."?
[03:10:56] <cradek> good question, I haven't seen that
[03:11:11] <jmkasunich> and why isn't the overrun failure reported at the end?
[03:11:20] <cradek> '1 expected'
[03:11:30] <cradek> it's supposed to fail - that's a success
[03:11:35] <jmkasunich> XFAIL = expected fail
[03:22:03] <jmkasunich> well, seems I'm not doing RIP builds on the farm
[03:22:36] <jmkasunich> I'll look into it more tomorrow - I don't want to enable the tests and then go to bed just in time for a storm of FAILs
[03:26:59] <seb_kuzminsky> thanks for looking in to it
[03:27:37] <jmkasunich> if somebody who knows the test system could tell me what's up with the . test, I'd appreciate it (jepler) ;-)
[03:29:57] <cradek> jmkasunich: I don't get that
[03:30:32] <jmkasunich> running it in the top directory?
[03:30:45] <cradek> all mine error - rebuilding after today's fixes
[03:31:30] <cradek> Runtest: 25 tests run, 24 successful, 0 failed + 1 expected
[03:31:46] <cradek> running from anywhere - doesn't matter
[03:34:12] <jmkasunich> I have 23 subdirs in tests (including CVS/)
[03:34:15] <jmkasunich> same there?
[03:34:54] <jmkasunich> ok, if I run it from tests/, it works
[03:35:04] <jmkasunich> run it from top level, I get the . test, and it fails
[03:35:10] <cradek> huh
[03:35:23] <jmkasunich> let me try a fresh shell, maybe emc-environment has changed
[03:35:32] <jmkasunich> (this shell may have been open for weeks or months)
[03:35:55] <jmkasunich> nope, same thing
[03:36:30] <jmkasunich> Running test: .
[03:36:30] <jmkasunich> *** .: FAIL: test run exited with 1
[03:36:43] <jmkasunich> note that it doesn't say "test . exited with 1"
[03:37:02] <cradek> if [ -f test.hal -o -f test.sh ]; then
[03:37:02] <cradek> set -- .
[03:37:14] <cradek> have some crap in your top dir?
[03:37:30] <jmkasunich> yes, test.hal
[03:37:34] <cradek> tada
[03:37:38] <jmkasunich> I was using that to test something
[03:37:38] <cradek> I rtfs'd
[03:38:33] <jmkasunich> mv'ed the file, works now
[03:38:52] <jmkasunich> getting late, I'll add to the farm tomorrow
[03:39:05] <jmkasunich> I wonder if there is a good reason I'm not doing RIP on the farm?
[03:39:50] <cradek> we all test rip all the time
[03:40:12] <jmkasunich> the test suite won't work if I'm not doing RIP tho
[03:40:25] <jmkasunich> (I can't install on the farm, since I have multiple trees checked out)
[03:40:31] <cradek> hmmm
[03:41:37] <jmkasunich> btw, we probably should have an 8.04 farm machine
[03:41:59] <jmkasunich> anybody have a 24/7 PC that can handle a VM running 8.04? wanna host a farm slot?
[03:42:23] <jmkasunich> the alternative is I buy some more RAM for this box (not much $) and shut down long enough to install it
[03:42:32] <jmkasunich> I hate shutting down
[03:49:57] <seb_kuzminsky> i'll try to find a spot for an 8.04 emc2 vm
[03:50:55] <jmkasunich> seb_kuzminsky:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/infrastructure/farm-scripts/README?rev=1.6
[03:51:05] <jmkasunich> if you have any questions don't hesitate to ask
[03:51:31] <seb_kuzminsky> http://highlab.com/~seb/lots-of-pins
[03:51:42] <jmkasunich> technically it doesn't require a VM, you could run it on a regular machine, just have to decide if there are any security risks (see the readme)
[03:51:54] <jmkasunich> wow
[03:53:14] <cradek> seb_kuzminsky: does the watchdog disable the outputs? on hal_m5i20 it doesn't
[03:53:20] <jmkasunich> hmm, I just read that readme again - it probably is a lot simpler if I continue to host the farm slots
[03:53:30] <jmkasunich> since the results need to be uploaded to my account on dreamhost
[03:53:49] <seb_kuzminsky> if the watchdog bites, all io pins become weakly-pulled-high input pins
[03:53:57] <cradek> perfect
[03:54:15] <seb_kuzminsky> if the user then sets .watchdog.has_bit to 0, it resets all pins to what they should be and keeps going
[03:54:24] <cradek> if that's what disables the 7i33 outputs anyway
[03:54:28] <seb_kuzminsky> but at that point you've lost encoder count and all other state
[03:54:37] <cradek> err 7i33, 7i37
[03:54:55] <cradek> oh, ouch
[03:54:58] <seb_kuzminsky> i think the mesa daughter boards all use active-low enables on the power amps for this reason
[03:55:22] <seb_kuzminsky> at least i think that stuff's gotten lost, maybe not?
[03:55:29] <seb_kuzminsky> hm, i should test that, hold on
[03:55:53] <cradek> jepler fixed hal_m5i20's watchdog for me - pretty sure the encoders still work when it disables the outputs
[03:56:06] <cradek> well I guess I'm not sure of that
[03:56:19] <seb_kuzminsky> yeah i bet you're right, i bet that's how it works on hostmot2 also
[03:59:33] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog TODO hm2_pci.c hm2_pci.h):
[03:59:33] <CIA-37> EMC: This adds support for the 5i23 and 4i68.
[03:59:33] <CIA-37> EMC: All EPP, PCI, and PC-104/Plus AnyIO boards are now supported.
[03:59:34] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i23/ (6 files):
[03:59:34] <CIA-37> EMC: This adds support for the 5i23 and 4i68.
[03:59:36] <CIA-37> EMC: All EPP, PCI, and PC-104/Plus AnyIO boards are now supported.
[03:59:38] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/ (hm2_pci.9 hostmot2.9):
[03:59:40] <CIA-37> EMC: This adds support for the 5i23 and 4i68.
[03:59:42] <CIA-37> EMC: All EPP, PCI, and PC-104/Plus AnyIO boards are now supported.
[03:59:44] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/4i68/ (SV12.BIT SVST4_8.BIT SVST8_4.BIT):
[03:59:47] <CIA-37> EMC: This adds support for the 5i23 and 4i68.
[03:59:49] <CIA-37> EMC: All EPP, PCI, and PC-104/Plus AnyIO boards are now supported.
[04:00:08] <cradek> wow
[04:15:39] <seb_kuzminsky> i maintain that the top of TRUNK is horked
[04:17:05] <lerman___> lerman___ is now known as lerman
[04:17:05] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (17 files): updated HostMot2 firmware source from Peter Wallace at Mesa Electronics
[04:18:39] <CIA-37> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/5i22/ (SV16B.BIT SV16S.BIT SVST8_8B.BIT SVST8_8S.BIT): updated 5i22 firmware images from PCW
[05:28:45] <seb_kuzminsky> cradek: i was wrong
[05:29:12] <seb_kuzminsky> hostmot2 doesnt lose its quadrature count on watchdog bite
[05:30:02] <seb_kuzminsky> the driver detects the bite and resyncs *its* state to the fpga, and gets the fpga's state and it all keeps going nicely
[05:30:08] <seb_kuzminsky> no loss of position etc
[05:30:27] <seb_kuzminsky> uhh, that's it, i'm going to bed now
[05:44:55] <lerman___> lerman___ is now known as lerman
[10:17:20] <BigJohnT> just running configure on a fresh cvs on a hardy machine and I get "configure: errror: no convert, documentation cannot be built"
[10:17:54] <BigJohnT> I thought I saw this somewhere but it is real early in the morning
[10:56:15] <alex_joni> did you install all deps?
[10:56:29] <alex_joni> I assume it's TRUNK you're trying out..
[10:56:46] <alex_joni> apt-get build-dep gets you the deps for 2.2.x
[10:56:55] <BigJohnT> afaik yep and yep
[10:56:58] <alex_joni> for TRUNK there might be other packages, check debian/*
[10:57:53] <BigJohnT> i did apt-get build-dep emc2
[10:58:06] <BigJohnT> * BigJohnT looking
[10:59:49] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/debian/control.in?rev=1.24
[10:59:50] <BigJohnT> alex_joni: what am I looking for ?
[11:00:16] <alex_joni> build-depends
[11:07:33] <BigJohnT> does it have something to do with this "move lyx build-dependency to EXTRA_BUILD, this way it can be configured depending of target (note: lyx|lyx-qt doesn't work for Build-Depends)" in control.in
[11:09:28] <BigJohnT> I did an apt-get install emc2-dev
[11:10:10] <alex_joni> BigJohnT: nope
[11:10:22] <BigJohnT> :/
[11:10:23] <alex_joni> you simply need the packages listed in the link I gave you
[11:10:48] <alex_joni> g++,make,libc6-dev,tcl8.4-dev,tk8.4-dev,libgtk2.0-dev,libncurses-dev,gettext,libxaw7-dev,libreadline5-dev,lyx,python,tetex-bin,python-dev,libglu1-mesa-dev,libgl1-mesa-dev,libgnomeprintui2.2-dev,bwidget,tetex-extra
[11:11:42] <alex_joni> I think convert is part of imagemagick, but I'm not sure
[11:11:53] <alex_joni> try typing 'convert' and see what happens..
[11:12:18] <BigJohnT> ah ha ... imagemagick was one thing missing from the 6.06 machine
[11:12:27] <alex_joni> (btw, teh default build-deps should only give you deps needed to rebuild the emc2 package, which means only pdf documentation)
[11:12:43] <alex_joni> if you want to build html documentation aswell, then you probably need other packages aswell
[11:13:31] <BigJohnT> yep when I typed convert it said that they are in imagemagic...
[11:13:40] <alex_joni> +k
[11:30:33] <lerman_____> lerman_____ is now known as lerman
[11:45:29] <cradek_> cradek_ is now known as cradek
[11:46:31] <alex_joni> morning chris
[11:55:29] <BigJohnT> hmmm, the make broke with "make: *** [../docs/src/Master_User.pdf] Error 1 :(
[11:57:52] <alex_joni> BigJohnT: jepler asked tissf (who complained about the same error) to add some debugging to the submakefile
[11:58:03] <alex_joni> logger_dev: bookmark
[11:58:03] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-29.txt
[11:58:08] <alex_joni> I think it was 1-2 days ago
[11:58:31] <BigJohnT> I kinda remember that I was in and out that day
[11:59:10] <alex_joni> tissf: then you need to add "-dbg any" to the lyx commandline by editing docs/src/Submakefile and let me look at the output it makes
[11:59:46] <alex_joni> @$(LYX) -dbg any --export pdf2 $<
[12:00:53] <alex_joni> http://pastebin.com/m29566b2c
[12:00:58] <alex_joni> (if the link is still valid ..)
[12:01:59] <BigJohnT> I'll have to look this evening time to "exit stage left" :)
[12:02:17] <alex_joni> okay
[13:20:06] <Guest942> Guest942 is now known as skunkworks_
[14:08:23] <cradek> jepler: I could add it to the guts and halui and let the gui authors worry about it later if they want
[14:09:09] <jepler> I think that would be fine
[14:10:18] <cradek> I might try that if I decide I have the guts
[14:10:59] <cradek> today I will try to use "guts" in every sentence
[14:11:13] <SWPadnos> that's gutsy
[14:14:38] <SWPadnos> so what are you adding (if your guts allow it)?
[14:15:39] <cradek> feed limit
[14:15:44] <SWPadnos> oh, cool
[15:15:19] <cradek> jepler: fixed?
https://sourceforge.net/tracker/index.php?func=detail&aid=1650938&group_id=6744&atid=106744
[15:16:01] <jepler> cradek: yeah
[20:36:04] <seb_kuzminsky> cradek: are you around?
[20:38:04] <cradek> uh-oh
[20:38:59] <seb_kuzminsky> nothing bad, just wanted to let you know that hostmot2 watchdog bites *dont* lose position
[20:39:08] <cradek> neat
[20:39:17] <seb_kuzminsky> we were talking about it last night and i did the test after you left
[20:39:24] <seb_kuzminsky> that's all
[20:39:41] <cradek> cool.
[20:52:13] <jepler> a spreadsheet that carries units with every cell would be neat
[20:52:38] <jepler> so that it would automatically figure out to show that the result cell is in kHz
[21:45:38] <cradek> seb_kuzminsky: is updated trunk working for you now, or does it still lock up your machine?
[21:46:09] <seb_kuzminsky> top of trunk was not working for me as of last night
[21:46:20] <cradek> repeatable machine lockup?
[21:46:37] <seb_kuzminsky> repeatable, but i now think it's not quite a lockup
[21:46:46] <cradek> can you give me anything to go on?
[21:47:23] <seb_kuzminsky> it looked locked up, but i noticed that if i hit a key it would do a little bit of work (ie, the clock on my X desktop would update)
[21:47:37] <cradek> hmmm
[21:47:37] <seb_kuzminsky> i start realtime & load some hal files via a shell script
[21:47:42] <seb_kuzminsky> that shell script never returned
[21:47:45] <seb_kuzminsky> the mouse never responded
[21:47:52] <cradek> what modules did you load?
[21:47:55] <seb_kuzminsky> but each time i hit a key, the clock would update...
[21:47:55] <alex_joni> any components in the hal file?
[21:48:01] <alex_joni> besides mesa stuff
[21:48:04] <cradek> err components
[21:48:18] <alex_joni> surely something I borked :/
[21:48:20] <cradek> (what all did you loadrt)
[21:48:28] <cradek> yeah surely alex borke it... :-)
[21:48:52] <seb_kuzminsky> this hal file:
http://highlab.com/~seb/bzr/emc2/hostmot2/configs/hostmot2/hm2.hal
[21:49:10] <cradek> pid...
[21:49:11] <alex_joni> hmm.. pid
[21:49:18] <cradek> pid was one that was bogus, bug I think I fixed it
[21:49:23] <cradek> sure you were fully updated?
[21:49:30] <cradek> ... but I think ...
[21:50:00] <alex_joni> still updating here .. :/
[21:50:10] <seb_kuzminsky> i thought i might have borken it, but i tested it as follows:
[21:51:19] <seb_kuzminsky> update to top of tree, then revert everything except src/hal/drivers/mesa-hostmot2 to the way it was on Oct 24
[21:51:45] <alex_joni> is 'foo=-*(bar);' valid?
[21:51:54] <seb_kuzminsky> make clean; cd debian; ./configure -r; cd ../src; ./configure --enable-run-in-place --enable-build-documentation; make
[21:52:01] <seb_kuzminsky> sudo make setuid
[21:52:03] <alex_joni> or does it need to be foo=-(*bar);
[21:52:22] <cradek> hm, sim/servo_sim won't start for me
[21:54:39] <cradek> unary minus and dereference have the same precedence so they are evaluated right to left
[21:55:09] <cradek> foo = -*bar means foo = -(*bar)
[21:55:18] <cradek> http://www.difranco.net/cop2220/op-prec.htm
[21:55:43] <alex_joni> thanks..
[21:55:53] <alex_joni> I can confirm servo_sim not running
[21:56:03] <cradek> so yes, something is still borked
[21:56:08] <alex_joni> the error messages indicate that the motion controller isn't running
[21:56:19] <alex_joni> but that means that maybe hal isn't running or something
[22:01:57] <alex_joni> where do rtapi message go when using sim?
[22:02:17] <cradek> nowhere
[22:02:31] <cradek> static int msg_level = RTAPI_MSG_ALL;/* message printing level */
[22:02:31] <alex_joni> hrmm.. not really nice for debugging :)
[22:02:35] <cradek> change this in sim_common.h
[22:02:46] <alex_joni> it'll end up on the console?
[22:02:49] <cradek> yes
[22:03:08] <cradek> I suspect 'encoder'
[22:03:35] <cradek> although it seems to run
[22:03:47] <alex_joni> I doubt seb uses encoder
[22:03:55] <cradek> well true.
[22:04:29] <seb_kuzminsky> i dont use encoder
[22:04:38] <cradek> I suspect it's not 'encoder'
[22:04:43] <cradek> *sigh*
[22:04:48] <seb_kuzminsky> pid, probe_parport, & some of my mesa stuff
[22:05:53] <alex_joni> * alex_joni still thinks it's pid..
[22:05:58] <cradek> maybe I still missed something in pid.
[22:06:12] <alex_joni> seb_kuzminsky: can you try checking out the older rev of pid?
[22:06:36] <cradek> yep it's pid
[22:06:53] <alex_joni> 1.35
[22:07:44] <cradek> turn on debug=1 and it will work
[22:07:57] <cradek> pid has the same problem as stepgen
[22:08:32] <alex_joni> ah, error_i and error_d
[22:09:02] <alex_joni> I'd be inclined to just export them always
[22:09:35] <alex_joni> or maybe an else {} for malloc'ing them
[22:10:24] <seb_kuzminsky> yay you found it!
[22:10:32] <cradek> the quickest fixes would be to always export them or revert
[22:10:59] <cradek> dang I should have seen this. I saw the problem but only fixed part of it.
[22:12:03] <seb_kuzminsky> yeah geez cradek, pay attention
[22:12:03] <cradek> alex_joni: are you fixing it or should I?
[22:12:08] <alex_joni> jas
[22:12:18] <seb_kuzminsky> ;-)
[22:13:12] <alex_joni> pastebin.ca/1240043
[22:13:15] <alex_joni> that fixes it for me
[22:14:07] <cradek> you misspelled (hal_float_t *) in 4 places :-)
[22:14:30] <cradek> but other than that, it looks fine
[22:14:36] <cradek> you could do the same thing to fix stepgen.
[22:15:14] <alex_joni> I'll do this one, and see what jmkasunich thinks about it
[22:16:59] <CIA-37> EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/components/pid.c: temp fix for debug pins (don't always get exported as pins, but we need the address for keeping the data), might decide later to do it differently
[22:17:58] <alex_joni> seb_kuzminsky: sorry 'bout this..
[22:18:21] <seb_kuzminsky> no prob, i know how it goes
[22:18:30] <seb_kuzminsky> thanks for fixing it quickly :-)
[22:18:51] <alex_joni> well, I wasn't really convinced about the whole change, but sometimes it's better to just jump ahead and see what happens
[22:19:15] <seb_kuzminsky> well, that's what branches are for... :-P
[22:19:55] <alex_joni> yeah, but doing it on a branch means quite often doing it alone
[22:20:34] <seb_kuzminsky> true, that's a problem
[22:20:41] <seb_kuzminsky> good test suites can help somewhat with that
[22:21:07] <seb_kuzminsky> converting from params to pins is a worthy endeavour, thanks for dealing with it
[22:21:08] <alex_joni> well.. a running emc2 should have been a good enough test suite here..
[22:21:37] <alex_joni> well, I hope to catch jmk sometimes online and see if we come up with a plan
[22:23:56] <cradek> these changes broke virtually all the regression tests and some of the sample sim configurations... it's not a matter of the lack of proper tests - I think alex just misjudged how safe the changes were.
[22:24:13] <alex_joni> indeed
[22:24:35] <alex_joni> but it might have been for the greater good, I think jmk plans to have the farm run the tests
[22:24:44] <seb_kuzminsky> i was excited to learn yesterday that there's a test suite
[22:24:45] <cradek> (I know I've done that before too, lots of times)
[22:25:00] <seb_kuzminsky> sure, we all do it, no big deal
[22:25:28] <cradek> also I flogged the tests into all working again - they had bitrotted some
[22:25:35] <jepler> seb_kuzminsky: I'll be excited when you add your first test to it
[22:25:36] <cradek> that's another good outcome
[22:25:39] <seb_kuzminsky> i hope jmk gets the buildbot running the test suite
[22:25:55] <cradek> dinnertime...
[22:26:11] <seb_kuzminsky> jepler: me too :-)
[22:26:32] <seb_kuzminsky> i've been thinking about an hm2_test driver, that provides canned hostmot2-like responses to the hostmot2 generic driver
[22:27:03] <alex_joni> you can do a lookup based one
[22:28:11] <jepler> seb_kuzminsky: ah, interesting -- it took me a minute to figure out what you were saying, but I like it
[22:28:28] <jepler> bbl
[22:29:01] <seb_kuzminsky> later guys
[23:46:06] <lerman______> lerman______ is now known as lerman