00:57:08 <rayh> rayh has quit
03:50:17 <SWPadnos> hmmm - cradek, shouldn't those chown/chmod lines use $(DESTDIR)$(bindir)?
03:50:44 <SWPadnos> (or just $(BIN_DIR) )
03:51:24 <cradek> well, they're a hack for run-in-place
03:52:07 <SWPadnos> ah - OK
03:52:25 <cradek> make install sets everything right using DESTDIR etc
03:52:46 <SWPadnos> ok - I just saw the commit, didn't see which part of the file it was in
03:53:37 <SWPadnos> out of curiosity, do you know a reasonably easy way to boot an old computer from CDROM (using some form of grub boot disk or the like)?
03:53:53 <cradek> there's a floppy that sometimes works
03:53:56 <SWPadnos> actually, to start a CDROM, booting from floppy
03:54:16 <SWPadnos> I tried grub and isolinux, but neither knows about my SCSI CDROM
03:54:21 <cradek> http://timeguy.com/cradek/smartboot
03:54:24 <SWPadnos> sorry - syslinux
03:54:33 <cradek> SCSI CDROM will need support in the SCSI card's BIOS
03:54:40 <cradek> it rarely works.
03:54:51 <cradek> try smartboot...
03:55:02 <SWPadnos> got that, but the mainboard BIOS doesn't seem to like it (even though it has CDROM and lots of other boot options)
03:55:31 <cradek> drop an IDE CD in it temporarily
03:55:34 <SWPadnos> heh
03:55:40 <cradek> really
03:55:46 <cradek> booting from SCSI CD usually doesn't work.
03:55:51 <SWPadnos> you'd think that Adaptec and Supermicro parts would work, but oh, well
03:55:59 <SWPadnos> (and an NEC CDROM)
03:56:07 <SWPadnos> maybe I should throw in the Toshiba?
03:56:16 <SWPadnos> hmmm - I think it's in the Indigo2 right now
04:06:21 <rayh> rayh has joined #emc-devel
04:06:38 <SWPadnos> hiya Ray
04:07:51 <rayh> Hi Steven
04:08:57 <SWPadnos> did you see the post on CCED from the guy who wrote software to run the Galil motion cards (in Windows)?
04:09:34 <rayh> No I don't go there much anymore.
04:09:43 <rayh> What was the gist of it.
04:10:48 <SWPadnos> well - he wrote software that can drive the Galil DMC18xx PCI servo cards
04:10:58 <SWPadnos> plus some CAM sofwtare to convert DXF to G-Code
04:11:12 <SWPadnos> it's a work in progress though
04:11:26 <rayh> both or the converter?
04:12:27 <SWPadnos> both, I gather
04:12:46 <SWPadnos> though apparently the card works well enough for his laser machine
04:13:17 <SWPadnos> I emailed him asking if he'd open-source the driver and DXF converter, and gave him links to EMC info
04:13:36 <rayh> Mitts had a Galil clone and 95 long years ago.
04:13:42 <SWPadnos> (haven't heard back yet)
04:13:59 <SWPadnos> Mitts?
04:14:09 <rayh> Mittsubishi
04:14:20 <rayh> maybe that's one t
04:14:22 <SWPadnos>  - got one of their VFDs
04:14:27 <SWPadnos> ah ...
04:14:33 <SWPadnos> one day, I'll hook it up
04:14:47 <rayh> They build the control and drive hardware for Mazak.
04:15:02 <SWPadnos> cool
04:16:06 <rayh> You and jmk get anywhere with halwatch?
04:16:13 <SWPadnos> not really
04:16:44 <SWPadnos> I'm making some benchmarking code, so I can see just how bad the name-based searches are
04:17:13 <rayh> I'll put a wait statement in the watch stuff and see if that cures the early return problem.
04:17:38 <SWPadnos> hmm - can you refresh my memory about the "early return problem" ??
04:18:06 <rayh> it's a race condition I think.
04:18:35 <rayh> I set up a loop with after x000 {loopWatch}
04:18:57 <rayh> Then proceed to add additional variables with a mouse click.
04:19:13 <rayh> Great when it works but...
04:20:15 <rayh> One problem with tcl is that you can't stop the after command.
04:20:24 <rayh> It has to complete.
04:20:56 <rayh> So you sit there twiddling thumbs until x000 time has passed.
04:21:22 <SWPadnos> so after ... isn't a "yield" - it spins?
04:21:41 <rayh> It looks like that to me.
04:21:59 <SWPadnos> ok, where's the race?
04:22:00 <rayh> after registers the script after it with the event handler.
04:22:12 <SWPadnos> ok - so it shouldn't be spinning - it's a timer
04:22:29 <rayh> Well if the click to add a new signal is very close to the end of the time
04:22:46 <rayh> you get overlapping or missed returns from halcmd.
04:23:23 <SWPadnos> ah - OK.  you're calling exHAL from both WatchHAL and watchloop
04:23:36 <SWPadnos> naughty naughty
04:23:42 <rayh> I tried putting a flag in the system.  To redirect the return.
04:23:49 <rayh> that was a bust.
04:24:04 <rayh> yep.
04:24:12 <rayh> and several other places as well.
04:24:14 <SWPadnos> actaully, either of those should work fine
04:24:32 <SWPadnos> lemme look at this for a sec
04:25:47 <SWPadnos> exHAL should protect itself with a "busy" flag
04:26:41 <rayh> Yes it should.
04:27:08 <SWPadnos> presumably, if exHAL is executing (because of the after clause), and someone clicks on a new watch (causing WatchHAL to riun exHAL), they'll be different instances of the function?
04:27:21 <SWPadnos> (ie, local variables will be different)
04:28:26 <rayh> true for building the new widgets but the return from the timer
04:28:48 <rayh> seems to get seen by the new.
04:29:50 <SWPadnos> watchHAL should just add to the list, and let the next refresh take care of the data update
04:30:46 <rayh> But it must read a return from the var to know what kind of widget to use to show it.
04:31:42 <SWPadnos> ah - watchloop doesn't create widgets, it only changes their appearance
04:32:27 <SWPadnos> ok - so the thing to do is make a separate list of watch variables in watchHAL  "newWatches"
04:32:58 <SWPadnos> and watchloop actually creates widgets for anything in newWatches, and removes the items from that list as the widgets are created
04:33:48 <SWPadnos> as long as watchHAL is appending, and watchLoop is taking off the front of the array, it should work even if watchHAL is called during a run of watchLoop
04:34:14 <rayh> values converted to led or value
04:34:32 <SWPadnos> ?
04:35:03 <rayh> all watchHAL does is read values and set widgets.
04:35:22 <SWPadnos> right - I'm saying that it should be the "watch display manager"
04:35:30 <rayh> I has to do it for the entire list of displayed vars on each loop.
04:35:38 <SWPadnos> anything you want to display should be created in that function
04:36:20 <rayh> sort of an "oh this is new, let's make a display for it.
04:36:24 <SWPadnos> yep
04:36:44 <SWPadnos> or "here's the list of new things to add widgets for"
04:37:00 <SWPadnos> watchloop moves items from the new list to the displayed list
04:37:05 <rayh> so watchHAL sets its list of vars to oldlist and compares each loop?
04:37:05 <SWPadnos> as it creates the widgets
04:37:29 <SWPadnos> it could do that, but a "newWatches" list would do just as well
04:37:36 <rayh> You can't click leaves fast enough to get a list of new.
04:37:53 <SWPadnos> it may be one element long then ;)
04:38:09 <rayh> I don't understand  "newWatches" at all
04:38:28 <rayh> How does a newWatch get merged with the running list.
04:38:38 <SWPadnos> ok - here's how I envision it
04:39:09 <SWPadnos> when the user clicks on a tree node, the item gets added to "NewWatches" by WatchHAL
04:39:32 <SWPadnos> WatchHAL no longer creates the widgets, so it doesn't need to run exHAL to get the type
04:40:19 <SWPadnos> watchLoop will run through the normal watch list ($which), just like it does now
04:41:08 <SWPadnos> after doing that, it will run through $NewWatches, and will add widgets for each item in that list (and delete the item from the list as the widget is added)
04:41:56 <SWPadnos> since you get the data value when you get the type from exHAL, it hardly takes any extra effort
04:42:39 <SWPadnos> I'd still have watchHAL check both the NewWatches list and the "which" list for duplicates, so that watchLoop doesn't have the burden
04:43:06 <SWPadnos> (though it might be more efficient for weatchLoop to check when it's about to move an item from $NewWatches to $which)
04:43:15 <SWPadnos> did that make sense?
04:44:23 <rayh> sorta.  I'll copy it and read over in the morning.
04:44:28 <SWPadnos> heh - OK
04:44:36 <SWPadnos> there are probably details that I haven't thought through
04:44:46 <SWPadnos> (almost guaranteed, in fact)
04:45:03 <rayh> That is exactly how I feel about my own work.
04:45:30 <SWPadnos> well - those get sorted out eventually
04:46:28 <rayh> By the time they do, I usually have such a glob of junk that it is hard to make sence of any of it.
04:47:02 <rayh> Thanks for the ideas.
04:47:17 <SWPadnos> well - this stuff is sensible, but tcl/tk doesn't seem to have any good synchronization primitives (semaphores / mutexes), so it makes pseudo-multi-threaded stuff hard
04:47:23 <SWPadnos> sure - happy to help
04:48:03 <rayh> Yes.  I wonder how it does real threading.
04:48:18 <rayh> For a while we got 3 versions of emcsh each startup.
04:48:31 <SWPadnos> weird
04:48:36 <rayh> They wouldn't shut down using the emc script either.
04:48:46 <SWPadnos> weirder
04:48:56 <SWPadnos> it uses killall, doesn't it?
04:49:09 <rayh> Had to recompile the tcl source without multiple threading.
04:49:35 <SWPadnos> hmm
04:49:39 <rayh> Yes it does but the threads were interlocked so you could not kill except by starting at one end.
04:49:52 <SWPadnos> wish has near-threading, since events cause non-linear execution
04:50:07 <SWPadnos> but it's only "near"
04:50:15 <rayh> Yep.
04:50:44 <rayh> I've often wished that we could marry emc's status variables with corresponding
04:51:11 <rayh> tcl vars.  Then we could just register all the variables with the event loop
04:51:25 <rayh> and forget the after and that update proc.
04:51:32 <SWPadnos> that would be nice
04:52:02 <rayh> I tried it on some test stuff but don't know c well enough to pull it off.
04:52:16 <SWPadnos> I wonder if a check of chanflag at the beginning of exHAL would help anything
04:52:36 <SWPadnos> like (while chanflag == rd) wait
04:52:57 <rayh> I tried something like that but don't remember the result.
04:53:04 <rayh> I'll try that in the morning as well.
04:53:35 <rayh> While is so prone to locking up the system that I try to avoid it.
04:53:50 <SWPadnos> do global variables get created when they're first referenced as globals in a function?
04:53:51 <SWPadnos> heh
04:53:54 <rayh> My use of while needs a watchdog.
04:53:59 <SWPadnos> gotta love possibly-infinite-loops
04:54:04 <SWPadnos> yep
04:54:05 <rayh> Yes.
04:54:21 <SWPadnos> ok - I didn't see a declaration of chanflag anywhere
04:54:59 <SWPadnos> the loop could be while (chanflag == rd && count < 100000) { after 100 count = count + 1}
04:55:11 <SWPadnos> make that count < 100
04:55:37 <rayh> sure.
04:56:12 <rayh> chanflag is global in exHAL
04:56:27 <SWPadnos> I saw that - that's why I asked about creation
04:57:00 <rayh> Some coders do tend to put a global list at the start of their program.
04:57:17 <SWPadnos> probably people who are used to C ;)
04:58:31 <rayh> Don't you type the vars there also.
04:58:50 <SWPadnos> yep - hence the global list at the beginning of the program
04:59:27 <SWPadnos> you don't need to explicitly declare them as globals in functions though - they'll be used automatically (unless there's also a local variable of the same name)
05:00:07 <rayh> Using namespaces it is possible to work vars from a distance but I've never gotten the hang of it.
05:00:18 <rayh> Almost like pointers.
05:00:22 <SWPadnos> heh
05:00:27 <SWPadnos> almost
05:00:50 <SWPadnos> I'd say C++ is better with pointers, but somebody might throw things at me
05:01:25 <rayh> not me.
05:01:30 <SWPadnos> nope
05:01:57 <SWPadnos> it's funny - a lot of the stuff that jmk did with pin types and that kind of thing would be nearly automatic in C++
05:02:09 <rayh> Gotta get out of here.  Hope to finish up most of halconfig tomorrow
05:02:13 <rayh> Really.
05:02:20 <SWPadnos> ok - see you.  have a good night
05:02:26 <rayh> like inheritance
05:02:47 <SWPadnos> yes - inheritance, "virtual tables", run-time type information ...
05:03:00 <SWPadnos> the ability to "overload" functions
05:03:15 <SWPadnos> (some people hate it, but I think it's great)
05:03:22 <rayh> "overload" ?
05:03:43 <SWPadnos> yep - you can define several functions with the same name, but different arguments
05:04:13 <SWPadnos> so you can have, say, 6 versions of hal_pin_new, each of which takes a differnet pin type, and does the right thing with it
05:04:38 <SWPadnos> but you always call a function called "hal_pin_new" with your type that inherits from "hal_pin"
05:05:03 <SWPadnos> (or signals - call one version with a bool, one with an int, and one with a float ...)
05:05:27 <SWPadnos> you can even add definitions for symbols, like +, - * etc
05:05:36 <rayh> I can feel nightmares on the horizon.
05:05:40 <SWPadnos> heh
05:05:56 <rayh> I remember some discussion about redefining things like +
05:05:58 <SWPadnos> I wouldn't suggest that HAL be rewritten in C++, don't worry
05:06:16 <SWPadnos> like I said - it's great if used well, but it does hide what's "actually happening"
05:06:30 <SWPadnos> Paul made a C++ class out of the emcPose, remember?
05:06:53 <SWPadnos> so you can say "Pose1 = Pose2+Pose3", and it does the right thing
05:06:53 <rayh> vaguely
05:07:20 <SWPadnos> but it's a function call hidden behind a plus sign, so some people don't like it
05:08:07 <SWPadnos> what's interesting about it is that you could also do things like having kinematics be automatic
05:09:00 <rayh> by automatic you mean ready to be used if needed or defined.
05:09:05 <SWPadnos> reassign the = so that a variable of WorldPoseType can be directly assigned to MachinePoseType, and the correct kinematic transform gets called
05:09:31 <SWPadnos> so "MachinePose = WorldPose" would just work
05:09:44 <SWPadnos> it would call the kinematic transform function
05:10:10 <SWPadnos> (if you write the overloaded = correctly)
05:11:27 <SWPadnos> I wish I could find my C++ book - I should read up on this stuff more
05:11:32 <rayh> I can see how the line reads okay to represent the transform.
05:12:07 <SWPadnos> yep, but it can be hard to tell how much work a simple little '=' will have to do, hence the issues
05:12:21 <SWPadnos> conceptually, it's great
05:12:27 <SWPadnos> in RT, it can be deadly
05:12:27 <rayh> I can also see how the overload of the function can cause massive debug issues.
05:13:07 <SWPadnos> yeah - though a debugger will show the real function call (to the function "operator=" )
05:14:19 <SWPadnos> anyway - you wanted to get to bed, I should stop blathering
05:14:28 <rayh> It's a question of getting from the simple looking formula  "MachinePose = WorldPose" down to the function and back.
05:14:46 <SWPadnos> how do you mean?
05:15:34 <rayh> Well machinepose is made up of many elements/variables
05:15:46 <SWPadnos> when the source code "MachinePose = WorldPose" is encountered, the compiler inserts the function call "MachinePose.operator=(&MachinePose, &WorldPose)"
05:16:26 <SWPadnos> so it's just a function call, as though one had done "InverseKinematics(&MachinePose, &WorldPose)"
05:16:38 <SWPadnos> (the ampersand means "the address of")
05:17:31 <SWPadnos> the programmer still writes those functions though, there's no way around that ;)
05:17:53 <rayh> I guess I was thinking of the load of variables on each side of the equals
05:18:02 <SWPadnos> right
05:18:14 <SWPadnos> even worse is the fact that a machine may not be cartesian
05:18:19 <rayh> and how each is properly handled by the maths hidden behind it.
05:18:38 <SWPadnos> right.  hiding complexity is good at some levels, and bad at others
05:18:47 <rayh> Well trivkins is a bit easier although genhexkins isn't that bad conceptually.
05:19:10 <SWPadnos> "octapodkins" would still look the same, which is a benefit and a problem
05:19:22 <SWPadnos> depending on how you look at it
05:19:32 <rayh> Sagar's scarakins was really quite easy to see.
05:19:52 <SWPadnos> that's the radial arm with a quill-like Z?
05:20:02 <SWPadnos> actually, two horizontal joints
05:20:04 <SWPadnos> ?
05:20:50 <rayh> Yes.  Looks like a shoulder and elbow
05:21:06 <rayh> with z at the hand and no wrist
05:21:08 <SWPadnos> right - I saw that one.  looks cool for some PCB-style applications
05:21:10 <SWPadnos> yep
05:21:29 <rayh> gotta crash.  see you guys.
05:21:35 <rayh> rayh has quit
15:27:30 <rayh> rayh has joined #emc-devel
20:39:31 <rayh> I see that we are missing the old help files from emc.
20:40:02 <rayh> what do you think of emc2/docs/help as a location for these.
20:40:18 <alex_joni> fine with me
20:40:46 <rayh> I'd like to make the names of each help file refer to the program that uses it.
20:41:22 <rayh> so one file might look like emc2/docs/help/tkemchelp.txt
20:41:28 <rayh> or some such.
20:41:57 <alex_joni> how about tkemc.help (or tkemc.hlp) ?
20:43:11 <rayh> that should be okay. If we expanded the help function in tkemc to include html we'd name it tkemc.html
20:43:57 <alex_joni> right
20:44:24 <rayh> Okay.  If others don't object, I'll do that bit of work tomorrow.
20:44:46 <rayh> Then modify all the ini files to find it there.
20:45:01 <alex_joni> don't
20:45:15 <alex_joni> that complicates run-in-place vs. install
20:45:24 <alex_joni> I'd rather have tkemc find it on it's own
20:45:36 <alex_joni> maybe based on the runscript
20:49:28 <alex_joni> how does that sound?
21:05:49 <rayh> rayh has quit
22:16:16 <logger_devel> logger_devel has joined #emc-devel
22:16:16 <niven.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:16:16 <niven.freenode.net> Users on #emc-devel: logger_devel LawrenceG cradek steves_logging @ChanServ SWPadnos anonimasu jtr_ alex_joni