Back
[01:14:21] <jepler> cradek: my impression is that the import is of a single branch, but I'm not 100% sure of that
[01:41:49] <seb_kuzminsky> cradek: jeff is right, they've imported TRUNK only, unfortunately
[04:15:05] <cradek> hm, I wonder if we can get a better import somehow. I'd be a lot less enthusiastic about switching if we would have to throw away history.
[04:33:23] <seb_kuzminsky> cradek: me too, history is good stuff
[04:37:13] <seb_kuzminsky> there's a log of branches... it seems like most are long-dormant feature-branches
[04:37:43] <seb_kuzminsky> i meant "a lot of branches"
[04:38:27] <cradek> true, but several are important. One is our current stable release branch, and another is an 80%-finished feature I want to revive
[04:39:09] <cradek> (a lot of them are surely crap)
[04:51:18] <SWPadnos> I think there are branches that have some HAL refactor work in them
[04:51:24] <SWPadnos> not sure if that's pre-EMC2 though
[04:51:41] <SWPadnos> damn. anyone have a DB25M-DM25M cable I can borrow
[04:51:49] <SWPadnos> err, DB, not DM
[04:51:58] <cradek> also important joint-axes stuff, and free mode planner refactor iirc
[05:06:27] <SWPadnos> does anyone (like jepler) know how hard it would be to make the file paths in stepconf relative to the directory the .stepconf file is in?
[05:56:53] <seb_kuzminsky> my c++ is pretty rusty
[05:58:18] <SWPadnos> no problem - it's only needed for the interp and nml (for the most part)
[05:58:32] <seb_kuzminsky> that's like half of our coverity issues
[05:58:40] <SWPadnos> oh, right :)
[05:59:09] <seb_kuzminsky> much of it related to silly stuff like the linked list implementation and the ini-file parser
[05:59:39] <SWPadnos> and constructor/destructor silliness (allocate but don't deallocate, etc)
[06:00:08] <seb_kuzminsky> has anyone though about using something modern like glib for the basics like linked lists and other data structures, ini-file stuff (and logging)
[06:00:24] <SWPadnos> well, I don't think so
[06:00:46] <SWPadnos> but consider that anything HAL related has to have a straight C implementation that doesn't depend on libraries
[06:01:05] <SWPadnos> at least anything that deals with low level HAL structures
[06:01:48] <SWPadnos> I'd be happy making extensive use of the STL and various C++ lanugage features for a lot of other stuff though
[06:02:56] <seb_kuzminsky> STL is the standard template library for c++, right?
[06:03:00] <SWPadnos> yes
[06:03:24] <SWPadnos> lists, maps, vectors, etc for storage classes
[06:03:34] <SWPadnos> and lots of stuff I don't know about :)
[06:05:46] <seb_kuzminsky> libnml is from the old nist days, right?
[06:06:09] <seb_kuzminsky> that stuff gives me the heebie jeebies
[06:06:32] <SWPadnos> actually, the libnml we have is mich simpler and smaller than the full libnml
[06:06:48] <SWPadnos> I think that stuff was auto-generated by a java program
[06:07:09] <SWPadnos> Paul did a lot of work streamlining that code
[06:07:16] <seb_kuzminsky> oh...
[06:07:44] <seb_kuzminsky> nml can communicate over lots of different transports; do we use anything other than TCP anywhere?
[06:07:49] <seb_kuzminsky> shm maybe?
[06:08:01] <SWPadnos> yes
[06:08:18] <SWPadnos> shared memory is the most common. tcp/ip is next, and serial is effectively unused I think
[06:08:25] <seb_kuzminsky> lol @ serial
[06:09:05] <SWPadnos> don't laugh - the idea is that a microcontroller can deal with a remote panel (for instance), and send commands over a serial link
[06:09:10] <seb_kuzminsky> nml is message-oriented; how does it signal message transmission over shm? signals? polling?
[06:09:37] <SWPadnos> there's a queue mechanism (another container class provided by the STL)
[06:09:46] <seb_kuzminsky> yes but
[06:09:55] <seb_kuzminsky> does the receiver poll the queue?
[06:10:06] <SWPadnos> I don't know that code well, so I won't be able to answer many more questions about it :)
[06:10:13] <SWPadnos> I'm not sure - probably
[06:11:03] <seb_kuzminsky> i'm curious, because in my day job i'm developing a pub/sub message-passing framework, so some of this stuff is on my mind
[06:11:16] <SWPadnos> publisher/subscriber?
[06:11:23] <seb_kuzminsky> yeah
[06:11:26] <SWPadnos> ok
[06:11:35] <seb_kuzminsky> nml is point-to-point?
[06:12:00] <SWPadnos> hmmm
[06:12:32] <SWPadnos> I don't think so, since you can have multiple UIs that all talk to task
[06:12:44] <seb_kuzminsky> right
[06:12:53] <SWPadnos> so it's point to multipoint
[06:13:16] <seb_kuzminsky> multicast
[06:13:24] <SWPadnos> no, multipoint
[06:13:41] <seb_kuzminsky> sometimes point-to-multipoint is called multicast
[06:13:50] <seb_kuzminsky> as opposed to point-to-point: unicast
[06:13:58] <SWPadnos> multicast is a specific implementation of multipoint distribution, which actually splits messages up when they need to go to different lpaces
[06:14:33] <SWPadnos> I see multicast as the specific tcp/ip implementation of a point to multipoint protocol
[06:14:39] <SWPadnos> but anyway
[06:15:16] <seb_kuzminsky> the ip multicast i'm familiar with works with udp but not tcp
[06:15:26] <SWPadnos> nml is directional though - there's generally a command, status, and error channel for a given link
[06:15:30] <SWPadnos> ok, UDP - sorry :)
[06:15:55] <SWPadnos> I guess it can't be TCP, since there would need to be connections for the multiple points, which would be a PITA
[06:16:15] <seb_kuzminsky> with the multiple ui's all getting status and error from the machine controller, and the machine controller getting commands from all the uis?
[06:16:30] <SWPadnos> yes
[06:16:34] <SWPadnos> but there are issues
[06:16:40] <seb_kuzminsky> oh good :-)
[06:16:43] <SWPadnos> heh
[06:17:02] <SWPadnos> I'd talk to Alex and/or Chris about it though, I think they're the experts at this point
[06:17:11] <SWPadnos> (don't let them tell you otherwise ;) )
[06:29:26] <seb_kuzminsky> SWPadnos: are you still there?
[06:29:31] <SWPadnos> partly
[06:29:47] <seb_kuzminsky> can you code-review a simple c++ patch for me?
[06:30:01] <SWPadnos> yes, but I may claim tiredness and go to bed :)
[06:30:59] <seb_kuzminsky> http://highlab.com/~seb/patch
[06:31:44] <SWPadnos> ok, that's to fix the "possible uncaught exception" error from coverity?
[06:31:51] <seb_kuzminsky> right
[06:32:34] <seb_kuzminsky> if main() doesnt catch the exception (and no called function catches it before it gets to main), does the program exit?
[06:33:04] <SWPadnos> I think that's what should happen - it would exit with an uncaught exception error of some kind
[06:33:17] <SWPadnos> but it may be controllable (ie, ignore vs exit)
[06:33:25] <seb_kuzminsky> hm
[06:33:54] <SWPadnos> I don't know that, just thinking out loud
[06:35:00] <SWPadnos> your patch looks correct, though I'm not sure you need to return from the catch block
[06:35:45] <seb_kuzminsky> i'll look into that
[06:35:56] <SWPadnos> the ini file will be closed just after the catch anyway, and if posfile isn't set, 0 will be returned (may not be waht you want, but I'd check the caller to be sure that -1 will mean something)
[06:36:15] <SWPadnos> versus 0 which is returned if it's not found
[06:37:05] <SWPadnos> crap. I do need to get to bed. thanks for looking at all this stuff
[06:37:16] <seb_kuzminsky> thanks for chatting :-)
[06:37:40] <SWPadnos> sure
[06:38:16] <seb_kuzminsky> what's the return value of a function that throws an exception? can i rely on it being 0 in this case?
[06:38:25] <seb_kuzminsky> n/m, i'll look up the answer
[06:38:27] <seb_kuzminsky> goodnight :-)
[06:38:28] <SWPadnos> I bet it's undefined
[06:38:42] <seb_kuzminsky> so the return in the catch block would be needed in that case
[06:38:44] <SWPadnos> the function doesn't return actually, so it may not change the variable
[06:39:03] <SWPadnos> if you set posfile to null or 0, that might help :)
[06:39:17] <SWPadnos> yes, if that's true it would be needed
[06:39:22] <seb_kuzminsky> i think i like returning explicitly better
[06:39:31] <seb_kuzminsky> seems clearer to me
[06:39:36] <seb_kuzminsky> but then i suck at c++
[06:39:41] <SWPadnos> yep - just check that -1 means something though
[06:39:50] <SWPadnos> since 0 is returned in other cases
[06:39:57] <seb_kuzminsky> -1 is what the other error paths in that function return
[06:40:02] <SWPadnos> ok
[06:40:35] <SWPadnos> that's another example of not quite well used c++
[06:40:53] <seb_kuzminsky> what do you mean?
[06:41:04] <SWPadnos> what you should be able to do is do all the processing in sequence, within a single try block
[06:41:16] <SWPadnos> then you can have multiple catch statements at the end, to catch any errors
[06:41:28] <seb_kuzminsky> i see
[06:41:47] <SWPadnos> if any error happens while processing, there should be an exception returned (unless the error is locally generated)
[06:41:50] <seb_kuzminsky> that's assuming the different functions you call in the try block throw different kinds of exceptions, i guess
[06:42:04] <SWPadnos> yes - that would be proper use of exceptions :)
[06:42:06] <seb_kuzminsky> and that they dont build up state that needs to be unwound/freed
[06:42:29] <SWPadnos> or that the state can't be determined by which exception was thrown
[06:42:45] <seb_kuzminsky> s/can't/can/ ??
[06:43:01] <SWPadnos> if you call 6 fiunctions in a row, and they return different exception classes, the different catch blocks can do whatever unwinding is needed
[06:43:41] <SWPadnos> well, if you call open() twice, you can't tell which time it threw the exception in the catch block
[06:43:49] <seb_kuzminsky> yeah it gets icky
[06:43:58] <seb_kuzminsky> this is when i reach for goto ;-)
[06:44:20] <SWPadnos> no more icky than call_func(); if (retval==crap) { unwind_some_stuff; return someerrorcode }; ...
[06:44:51] <seb_kuzminsky> wait, i dont get that
[06:45:15] <seb_kuzminsky> the problem is: in your try { }, you call open twice, and in your catch, you dont know which one failed
[06:45:16] <SWPadnos> the difference is that if all your functions behave correctly, and throw errors correctly, you can assume that everything has gone well unless you end up in a catch block
[06:45:27] <seb_kuzminsky> i agree with that
[06:45:53] <SWPadnos> right, and handling that is no more icky than having 3 lines of check this / return if not OK after every function call
[06:46:15] <SWPadnos> you can always use a state variable
[06:46:21] <seb_kuzminsky> if (!open(file1)) goto fail1;
[06:46:24] <SWPadnos> past_fopen1
[06:46:27] <SWPadnos> =1
[06:46:33] <seb_kuzminsky> if (!open(file2)) goto fail2;
[06:46:53] <seb_kuzminsky> then fail1 and fail2 fall through, so the unwinding happens naturally
[06:47:00] <SWPadnos> sure
[06:47:07] <seb_kuzminsky> you jump into the full-function cleanup code at just the right place
[06:47:18] <SWPadnos> yes, that's done in the kernel a lot
[06:47:38] <seb_kuzminsky> i think that's where i picked it up from
[06:47:44] <SWPadnos> anyway - bedtime. good night :)
[06:47:51] <seb_kuzminsky> okey, sleep well ;-)
[06:47:53] <seb_kuzminsky> thanks again
[06:51:00] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/task/taskintf.cc:
[06:51:00] <CIA-42> EMC: catch an uncaught exception
[06:51:00] <CIA-42> EMC: I *think* this is the way to go, but my C++ is 15 years rusty and I dont
[06:51:00] <CIA-42> EMC: really know the code i'm monkeying with.
[07:07:16] <seb_kuzminsky> SWPadnos: uncaught exceptions terminate the process
[07:08:49] <seb_kuzminsky> heh
[07:08:52] <seb_kuzminsky> http://cvs.linuxcnc.org/cvs/emc2/src/libnml/inifile/inifile.cc?rev=1.29
[07:09:03] <seb_kuzminsky> throw(err); return(err);
[07:09:08] <seb_kuzminsky> all over the place
[15:10:32] <jepler> seb_kuzminsky: I'm pretty sure that the 'possible uncaught exception' there and otherwise is spurious.
[15:10:44] <jepler> er, and elsewhere
[15:11:02] <jepler> the inifile stuff can now optionally throw exceptions, but as far as I know it's always configured not to
[15:11:54] <jepler> a nonzero first argument to the inifile constructor or a call to EnableExceptions would be required, and there's not one there
[15:13:49] <jepler> imo we should either ditch the exception-throwing mode altogether, or we should fully embrace it
[15:22:02] <seb_kuzminsky> jepler: ah
[15:22:37] <seb_kuzminsky> yeah, having piles of disabled code cluttering up the tree is no good
[15:24:32] <seb_kuzminsky> "One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
[15:25:25] <seb_kuzminsky> does anyone actually prefer C++ to C? If not maybe we should be transitioning away...
[16:16:17] <SWPadnos> seb_kuzminsky, I think you'll find either fear or hatred of c++ more than a preference for it
[16:16:59] <SWPadnos> I'm not very good with c++ language features (I usually use some classes and the rest straight C), but I see that there are several places where c++ should be better
[16:17:17] <SWPadnos> so I guess you'd say that I'm the advocate for c++, but not a very good one :)
[16:17:42] <SWPadnos> (Pete V also likes c++, and is more skilled with the language features, so he'd be an advocate if he were around)
[16:20:30] <jepler> I have a love-hate relationship with C++
[16:20:41] <SWPadnos> you love to hate it? :)
[16:20:45] <jepler> the language itself is very complex, and there are a lot of gotchas
[16:21:31] <jepler> on the other hand, it lets you do things like strings, containers, smart pointers, and other stuff that makes life much easier
[16:22:17] <SWPadnos> there's also the problem of interfacing with C structs and code, since you can't use (much) c++ in the kernel
[16:22:33] <jepler> yeah, in emc there's the practical consideration about kernel space
[16:24:18] <SWPadnos> userspace code could benefit quite a bit, but then we'd have two codebases for the same HAL stuff
[16:25:26] <jepler> right: hal linked lists could be much nicer to work with in C++, but you have to have the kernel-side implementation in C or decide to always and forever support C++ in the kernel
[16:25:36] <jepler> neither of those appeals to me
[16:25:44] <SWPadnos> heh
[16:26:02] <SWPadnos> there is (was?) some RTAI support for c++ in the kernel
[16:26:13] <SWPadnos> but I don;t know what subset that was, or if it ever worked
[16:26:18] <jepler> heh
[16:26:35] <jepler> if you can get kbuild to invoke the compiler in C++ mode, you quickly find out that all kernel header files are C++-hostile
[16:26:55] <SWPadnos> as are the developers ;)
[16:27:00] <jepler> coincidence?
[16:27:06] <SWPadnos> I don't think so
[16:28:05] <seb_kuzminsky> c++ is the only language where your friends can access your private parts
[16:28:23] <SWPadnos> ok, time to make pies, or there will be several unhappy people after dinner tonight. bbl
[16:35:54] <alex_joni> hi
[16:39:29] <seb_kuzminsky> hi alex
[16:39:53] <alex_joni> hi seb, what's up?
[16:40:00] <alex_joni> I noticed the talk about branches on lp
[16:40:08] <alex_joni> I can always ask for more branches to be imported from cvs
[16:40:19] <seb_kuzminsky> that may or may not be useful
[16:40:35] <seb_kuzminsky> the vcs-imports team provides a read-only pull from the CVS repo
[16:40:58] <alex_joni> right.. I used -d:ext:anon@cvs...
[16:41:00] <seb_kuzminsky> so i dont think it will be very convenient for folks to actually use to accomplish work
[16:41:13] <seb_kuzminsky> you can log, diff, branch, commit, etc
[16:41:18] <seb_kuzminsky> but you can't push
[16:41:22] <seb_kuzminsky> brb
[16:41:27] <alex_joni> well, it might if we (ever) stop using cvs.linuxcnc and start using lp only
[16:44:43] <seb_kuzminsky> yes then it will be very good
[16:44:54] <seb_kuzminsky> my workflow is this
[16:45:21] <seb_kuzminsky> i did a cvs checkout, then a bzr init in the checkout directory
[16:45:47] <seb_kuzminsky> (so that's not an import; it lost all cvs history and is just a snapshot)
[16:45:56] <seb_kuzminsky> i call that "upstream"
[16:46:13] <seb_kuzminsky> i bzr branched upstream to a couple of branches on my various work computers
[16:46:40] <seb_kuzminsky> when i'm happy with something in a branch on a working computer, i bzr push it to my upstream branch, and cvs commit from there
[16:46:46] <seb_kuzminsky> it aint pretty
[16:46:50] <seb_kuzminsky> but it works pretty well
[16:47:09] <seb_kuzminsky> i often start my day with "cvs up && bzr commit" in the upstream branch
[16:55:16] <alex_joni> I see
[16:55:48] <alex_joni> but could you do a cvs import to a bzr repo?
[16:57:26] <seb_kuzminsky> here's how the mozilla guys did cvs->bzr:
https://wiki.mozilla.org/Importing_Mozilla_CVS_to_Bazaar
[16:57:33] <seb_kuzminsky> i gotta go - turkey duty
[16:59:53] <alex_joni> ok, have fun
[21:15:22] <BigJohnT_> BigJohnT_ is now known as BigJohnT