Back
[00:31:34] <Dallur> jmkasunich: you here by any chance ?
[00:33:05] <jmkasunich> just arrived
[00:33:39] <Dallur> great, just wanted to let you know that I got around to test minmax and multiply this morning
[00:33:52] <Dallur> multiply works great
[00:34:02] <jmkasunich> ;-)
[00:34:12] <Dallur> minmax has a problem that I know some of the guys have been looking at today
[00:34:18] <jmkasunich> ;-(
[00:34:23] <Dallur> there is nothing wrong with minmax per say
[00:34:31] <Dallur> but it causes the RT stuff to segfault
[00:34:50] <jmkasunich> heh, that's pretty wrong IMO
[00:35:00] <jmkasunich> do you know what exactly makes it happen?
[00:35:01] <Dallur> I know alex, cradek and the others were looking at it before
[00:35:09] <Dallur> most of it is in the logs for today
[00:35:24] <cradek> none of us can spot the problem
[00:35:31] <jepler> I used minmax successfully
[00:35:44] <jepler> 16:24:43 <jepler> here's the .hal I used for testing:
http://pastebin.ca/79907
[00:35:44] <jepler> 16:24:53 <jepler> I jogged around and turned mist on/off to test the 'reset' input
[00:36:11] <cradek> I was using the halui_halvcp sample config
[00:36:32] <Dallur> I was using halui/halvcp components and than I reproduced with halui_halvcp
[00:37:30] <cradek> hmm, I would like to use my lathe to make this part for my lathe, but my lathe is in many pieces
[00:38:40] <cradek> jmkasunich: are these hardware store "dowel pins" too hard to drill and turn comfortably?
[00:38:57] <Dallur> cradek: I can make it for you and ship it over but I'm afraid shipping would probably take long and be expensive
[00:39:12] <A-L-P-H-A> what's being mae?
[00:39:19] <A-L-P-H-A> made
[00:39:29] <jepler> mmm freshly baked scones
[00:39:33] <cradek> Dallur: I appreciate that, but I just have to quit complaining and put it back together!
[00:39:36] <A-L-P-H-A> I don't like scones.
[00:39:46] <cradek> jepler: is there coffee?
[00:40:12] <cradek> oh wait, you didn't invite me yet
[00:40:31] <jepler> cradek: if you want to, come on over. I'll make coffee.
[00:40:53] <cradek> thanks, but I wasn't serious
[00:41:18] <A-L-P-H-A> seriously, what are we talking about?
[00:41:36] <cradek> which conversation?
[00:41:42] <A-L-P-H-A> something being mde
[00:41:44] <A-L-P-H-A> made
[00:41:48] <Dallur> well, cradek claims that cupcakes are better than muffins, that's crazy talk
[00:41:49] <A-L-P-H-A> [20:46:40] <Dallur> cradek: I can make it for you and ship it over but I'm afraid shipping would probably take long and be expensive
[00:42:01] <jepler> Dallur: cradek: what inputs / outputs were you using for minmax in your tests?
[00:42:15] <cradek> jepler: just a signal that I set with sets
[00:42:19] <jmkasunich> read back...
[00:42:19] <Dallur> I was using -fb from my Y axis
[00:42:34] <cradek> jepler: it would usually crash as soon as I attached any signal to any pin (if the function was hooked to a thread)
[00:42:46] <Dallur> I only had problems as soon as I set the reset pin to high, at that point everything blew up
[00:43:04] <cradek> jepler: and if it didn't crash, it still didn't work (did nothing)
[00:43:22] <Dallur> I got minmax to work, just as soon as I hit reset it blew up
[00:43:27] <cradek> A-L-P-H-A: my lathe is apart because I'm converting it to cnc, but I would like to use it to make a part for its conversion
[00:43:42] <jmkasunich> ok, easy one first.... yes cradek, don't even think of doing anything to a dowel pin (unless you grind it)
[00:43:46] <jepler> it worked fine for me, including reset
[00:44:01] <cradek> jmkasunich: ok thanks
[00:44:05] <A-L-P-H-A> cradek oh
[00:44:05] <cradek> jmkasunich: figured as much
[00:44:09] <A-L-P-H-A> cradek, where are you? US?
[00:44:21] <cradek> yes right in the center (Lincoln NE)
[00:44:35] <A-L-P-H-A> NE?
[00:44:41] <cradek> yes
[00:44:44] <A-L-P-H-A> where's NE?
[00:44:44] <jepler> nebraska
[00:44:47] <A-L-P-H-A> OH!
[00:44:49] <cradek> haha
[00:44:56] <A-L-P-H-A> on of the forgotten states.
[00:44:56] <cradek> the fly-over state
[00:45:02] <cradek> I remember it most days
[00:45:06] <A-L-P-H-A> I still don't know where nebraska is.
[00:45:07] <A-L-P-H-A> hahaha
[00:45:09] <fenn> not ohio, nebraska
[00:45:18] <cradek> find a map, point at the middle of the US, there it is
[00:45:46] <Dallur> and remember, even though alaska is right next to california on the map, that does not make it so
[00:45:48] <jmkasunich> ok, minmax
[00:46:15] <jmkasunich> has anybody other than Dallur been able to reproduce the bug?
[00:46:31] <jepler> A-L-P-H-A: it's next to ther famous states like south dakota, iowa, kansas, and wyoming.
[00:46:44] <cradek> jmkasunich: read back
[00:46:54] <jmkasunich> I did
[00:46:56] <cradek> I mean just the last few minutes
[00:47:00] <jmkasunich> I think the answer is no
[00:47:06] <cradek> no it's yes
[00:47:08] <jepler> 19:50:18 <cradek> jepler: it would usually crash as soon as I attached any signal to any pin (if the function was hooked to a thread)
[00:47:13] <jmkasunich> duh
[00:47:29] <jepler> /topic <cradek> no it's yes
[00:48:13] <jmkasunich> so you added the function to a thread, started the thread, and _then_ connected the signal?
[00:48:24] <cradek> I think I tried it both ways
[00:48:35] <cradek> if I connected the signals first, it would crash when I added to the thread
[00:49:13] <Dallur> here is step by step how I reproduced in halui_halvcp config
[00:49:19] <Dallur> change core_sim.hal from: loadrt blocks ddt=6 hypot=2
[00:49:24] <Dallur> and the rest is at:
http://pastebin.ca/79565
[00:50:33] <jmkasunich> are we talking about a "lock up the PC and reboot" crash?
[00:51:10] <A-L-P-H-A> finally look .
http://upload.wikimedia.org/wikipedia/en/a/a5/Map_of_USA_with_state_names.svg
[00:51:18] <Dallur> jmkasunich: nope, gui stops responding to input and dmesg shows: [ 5774.108278] Default Trap Handler: vector 14: Suspend RT task c0b26000
[00:55:16] <jepler> Dallur: that example in pastebin isn't intended to be useful, is it? I don't see why yould set Yvel to the max of Ypos...
[00:55:48] <Dallur> jepler: I skipped a few steps, like the ddt :D
[00:56:23] <Dallur> jepler: it was just me copy pasting from the original hal to the halui_halvcp to reproduce, pin names are bogus
[00:57:48] <CIA-8> 03jepler 07HEAD * 10axis/scripts/axis.py: remove psyco for now, as a user reported uncontrolled memory growth with it enabled
[01:01:20] <Mess> alpha.. you around?
[01:01:23] <A-L-P-H-A> no
[01:02:09] <A-L-P-H-A> oh... jepler, and cradek, live in the same city!
[01:03:08] <jmkasunich> and they work at the same company too!
[01:03:09] <A-L-P-H-A> Mess...what'd you want? :)
[01:03:20] <A-L-P-H-A> wonder if there's a brokeback mountain there too.
[01:03:38] <Mess> what a RETARDED day..... been workin' these 8 PEI grown pivot tubes for the dash 8 nose gear... 12-14 hrs a day since last tuesday.. thru the long weekend.. and today about 5:30... the depth mice said they were all SCRAp.... ; (
[01:03:39] <jmkasunich> not going there
[01:04:03] <A-L-P-H-A> what a waste of money.
[01:04:04] <Mess> mik
[01:04:06] <A-L-P-H-A> mic
[01:04:13] <Mess> micrometer
[01:04:54] <jepler> I still can't get the minmax error
[01:05:32] <jmkasunich> I'm trying to replicate it here
[01:05:44] <Mess> but thank GOD for our investigative and matl alotment... i clean up by about.005"... cutter JUST tickles .. but to spec
[01:05:49] <cradek> that is truly strange then
[01:06:02] <jepler> I used halui_halvcp with minmax=1 and then entered the lines dallur had in his pastebin, but with different signal names (there's already a Yvel)
[01:06:28] <A-L-P-H-A> Mess... so what the hell do you want to do with the incomplete parts I have?
[01:06:44] <A-L-P-H-A> I guess I'm not touching for the time being.
[01:06:53] <cradek> I added minmax=1 and addf minmax.0 servo-thread
[01:07:00] <cradek> newsig in float
[01:07:03] <Mess> lets finish them NEXT weekend ok.... not this one pls.. il run code
[01:07:04] <cradek> linkps minmax.0.in in
[01:07:08] <cradek> then crash
[01:07:27] <jmkasunich> cradek: running one of the stock emc configs?
[01:07:32] <jmkasunich> or ?
[01:07:43] <cradek> yes halui-halvcp
[01:07:57] <cradek> just added those two things to core_sim.hal in there
[01:08:15] <cradek> who took my allen wrenches??
[01:08:26] <Mess> look on the floor..
[01:10:03] <jepler> I've even tried weird things like
[01:10:03] <jepler> halcmd: sets F1 nan
[01:10:03] <jepler> halcmd: linksp F1 minmax.0.in
[01:10:20] <jmkasunich> sets F1 nan?
[01:10:25] <jmkasunich> halcmd accepts that?
[01:10:29] <jmkasunich> eww
[01:10:30] <jepler> looks that way
[01:10:40] <A-L-P-H-A> 'ight
[01:10:46] <A-L-P-H-A> hmm...
[01:10:49] <A-L-P-H-A> oh ohwell.
[01:11:11] <cradek> ha
[01:11:18] <A-L-P-H-A> cradek? ha?
[01:11:29] <jepler> 05 float R- nan minmax.0.in <== F1
[01:11:29] <jepler> 05 float -W nan minmax.0.max
[01:11:29] <jepler> 05 float -W -inf minmax.0.min
[01:11:41] <Mess> why you need the $$$ or what??
[01:11:45] <jmkasunich> well I'll be darned
[01:11:58] <cradek> halcmd sets A-L-P-H-A nan
[01:12:08] <A-L-P-H-A> anyone got a design for a anti-backlash ballscrews?
[01:12:31] <jmkasunich> two ballnuts, a few bellville washers, done ;-)
[01:13:11] <A-L-P-H-A> yeah... but I ordered a large ballscrew... how do I keep them from spinning apart? drill holes + tap them?
[01:13:21] <jmkasunich> the nuts?
[01:13:34] <jmkasunich> how do they attach to your table (or whatever)?
[01:13:45] <A-L-P-H-A> let me see if I still have photos
[01:13:54] <jmkasunich> you need to attach one rigidly, and the other with spring tension
[01:14:11] <jmkasunich> * jmkasunich gets back to minmax (I'm very easily distracted)
[01:14:37] <A-L-P-H-A> http://lloydleung.com/gallery/Mill_Related/Ballscrews%20mounted/# not a good photo
[01:14:47] <A-L-P-H-A> there's a bracket, where the nut threads into.
[01:14:57] <A-L-P-H-A> held there with a setscrew + locktite.
[01:15:20] <Mess> weld it
[01:15:29] <jmkasunich> you'll need to make a more sophisticated bracked I think
[01:15:38] <Mess> opps sorry not thinkin' right anymore tonite..
[01:15:45] <jmkasunich> well, I can't seem to duplicate the problem
[01:16:08] <jmkasunich> added "minmax=1" to the blocks loadrt line
[01:16:10] <A-L-P-H-A> right now, it's 3 pieces... a piece that looks like a U, where it's bolted to the Y gantry.
[01:16:23] <jmkasunich> added "addf minmax.0 servo_thread"
[01:16:29] <A-L-P-H-A> a bracket that bolts to the U. The bracket is threaded to mate with the nut.
[01:16:32] <jmkasunich> added "newsig in float"
[01:16:36] <Mess> i can see it in my head Alph... no problem i just cant type it tonite..
[01:16:41] <jmkasunich> added linksp in minmax.0.in
[01:16:43] <jepler> are you doing the "addf" before or after the other threads?
[01:16:44] <A-L-P-H-A> http://lloydleung.com/gallery/Mill_Related/Mill%20Brackets/#
[01:17:00] <jmkasunich> looking at minmax.0.max with halmeter, changing in does what I expect
[01:17:13] <jmkasunich> afer
[01:17:14] <jmkasunich> after
[01:17:40] <jmkasunich> (running halui_halvcp, added it right after the second addf hypot line
[01:18:23] <jmkasunich> cradek: did you have to take the machine out of estop or anything like that?
[01:18:37] <Dallur> jmkasunich: out of estop and enable for me
[01:18:52] <cradek> I don't think so
[01:19:00] <cradek> let me try it here
[01:20:26] <jepler> I've tried putting the thread first or last. I've tried entering the commands in an interactive 'halcmd' or not. I've tried turning the machine on.
[01:20:51] <cradek> hmm, working for me now
[01:20:56] <jmkasunich> so jepler and I can't reproduce it... Dallur and cradek can
[01:21:03] <jmkasunich> s/can/could/ ?
[01:22:26] <jepler> cradek: if you haven't changed the source on the other machine, maybe there's something in 'cvs diff -rBASE -rHEAD' ?
[01:23:39] <cradek> nope nothing
[01:24:01] <jmkasunich> cradek: you're using "in" as the input for minmax?
[01:24:05] <cradek> yes
[01:24:07] <jmkasunich> so its doing nothing
[01:24:09] <cradek> I'm sure that's what I did
[01:24:25] <jmkasunich> wonder if a changing signal is needed to invoke the error?
[01:24:37] <jepler> I've tested with the input having a writer and with the input not having a writer
[01:25:15] <jmkasunich> Dallur: (or Rugludallur), did the crash happen instantly when you connected a signal to a pin? or some time later?
[01:26:06] <cradek> [1813956.416174] Default Trap Handler: vector 14: Suspend RT task c1820800
[01:26:14] <Rugludallur> jmkasunich: 1. I changed the loadrt block to include the minmax
[01:26:18] <jmkasunich> cradek: just now?
[01:26:20] <cradek> got it, I had to hook to both in and reset
[01:26:21] <cradek> yes
[01:26:47] <jmkasunich> did it happen instantly when you did the linksp, or sometime after?
[01:26:51] <Rugludallur> 2. I launch emc, hook up pins input, max and reset
[01:27:02] <jmkasunich> you did the hookup manually?
[01:27:03] <Rugludallur> 3. come out of estop and turn machine on and than it happens
[01:27:07] <cradek> yes
[01:27:09] <Rugludallur> yes
[01:27:11] <cradek> let me check further, standy
[01:27:13] <cradek> b
[01:28:06] <jmkasunich> so for Rugludallur, it doesn't happen as soon as the pins are hooked up, it happens when you do machine on
[01:28:16] <Rugludallur> jmkasunich: correct
[01:29:22] <cradek> is there any reason to think using the 2.0.1 halcmd against head would cause this?
[01:29:54] <jepler> 05 float R- -9.73350e-01 minmax.0.in <== f
[01:29:54] <jepler> 05 float -W -9.74756e-01 minmax.0.max ==> g
[01:29:54] <jepler> 05 float -W -9.74756e-01 minmax.0.min
[01:29:54] <jepler> 05 bit R- TRUE minmax.0.reset <== b
[01:29:55] <Rugludallur> cradek: hmm there is a thought
[01:29:56] <jmkasunich> yes
[01:30:06] <jmkasunich> thou shalt not mix versions
[01:30:27] <jepler> I suppose this is no surprise, it's running on servo thread
[01:30:27] <Rugludallur> * Rugludallur bonks himself on his head while trying to find a cliff to jump off
[01:30:29] <cradek> I'll leave you with that thought and get back to my part-making
[01:30:33] <jmkasunich> usually you can get away with it, but I just recently added a member to one of the hal internal structs
[01:30:42] <jmkasunich> thou SHALT NOT mix versions
[01:31:05] <Rugludallur> thou shalt not have emc in path
[01:31:25] <jepler> I guess I was extra careful because I have local hal changes (for the 'user comp ready' flag)
[01:31:48] <jmkasunich> as long as you don't change any of the structs in shmem you are OK
[01:32:13] <jmkasunich> I wonder if there should be a version code in the shmem, and hal_init() should check it...
[01:32:48] <jepler> that's fine, just don't do it by using $Version$
[01:32:57] <jmkasunich> because?
[01:34:01] <jmkasunich> jepler: whats wrong with using $Version$ ?
[01:34:09] <cradek> argh now I can't find the handwheel
[01:34:10] <jepler> because only humans know when to bump bersion numbers, and because not all version control systems have $Version$
[01:34:29] <jepler> I mean, a human should decide when to bump the halcmd "interface version"
[01:34:49] <jmkasunich> trying to maintain compatibility across versions?
[01:35:41] <jepler> maybe my intuition is wrong, but it seems like most changes to hal will turn out to be compatible
[01:36:08] <jmkasunich> any change to the structs defined in hal_priv.h will be an issue
[01:36:59] <jmkasunich> I'm not sure we should jump to the conclusion that this is a version issue, btw
[01:37:27] <jmkasunich> not until Dallur has a chance to test with everything matching and verify that the problem is gone
[01:37:37] <Rugludallur> Im about to finish testing it
[01:38:22] <jepler> it would be nice if we could try to guarantee forward compatability. For instance, adding new fields at the end of the linked-list private structures would be a good practice and would probably have meant the new 'pid' field would not have broken old components
[01:39:11] <jmkasunich> yes it would
[01:39:19] <cradek> so move it?
[01:39:31] <jmkasunich> "yes it would" break old components
[01:39:53] <jmkasunich> the problem isn't old components per-se, its old copies of hal_lib.c
[01:40:09] <Rugludallur> gone, the problem was just old halcmd
[01:40:39] <Rugludallur> Rugludallur is now known as Dallur
[01:41:00] <jepler> jmkasunich: I meant "old binary components"
[01:41:15] <jmkasunich> if hal_vcp in userspace is linked against old hal_lib, it adds an old comp struct to the list, then a RT component adds a new comp struct to the list, then a halcmd traverses the list, and gets a mix of old and new structs
[01:41:36] <jmkasunich> even if the pid were at the end, if halcmd accesses the pid member, some structs won't have it
[01:41:45] <jmkasunich> and the access will touch who-knows-what
[01:41:46] <Dallur> Is there any reason to maintain backwards compatability, will there ever be a partial build or someone that needs to use old binaries with new ones ?
[01:41:57] <Dallur> or should there ever be?
[01:42:07] <jepler> jmkasunich: hm, I notice that hal_lib.c is lgpl, but it includes the gpl hal_priv.h
[01:42:19] <jmkasunich> argh
[01:42:41] <fenn> "bugger that"
[01:42:57] <jmkasunich> my intent is to permit, but discourage, the writing of proprietary hal modules
[01:43:23] <jmkasunich> if someone has a super-duper transfer function for example, I'm willing to let them embedd it in a hal module
[01:44:44] <jmkasunich> I guess I should change the license on hal_priv.h to lgpl
[01:44:46] <jepler> jmkasunich: you made that change fairly recently, with the note "Cleaned up some licenseing issues" .. why did you change it from lgpl to gpl?
[01:45:02] <jepler> rev 1.13
[01:45:08] <jmkasunich> I did that?
[01:45:12] <jepler> yes
[01:45:31] <jepler> you've made all the revs since 1.13 so it's clearly no problem if you wish to re-license it lgpl .. again
[01:45:47] <jmkasunich> checking repository... I certainly didn't intend that
[01:46:30] <jmkasunich> strange
[01:46:45] <jepler> I can't tell from here but I assume it was part of some shotgun license fixes?
[01:46:53] <jmkasunich> I think so
[01:47:01] <jmkasunich> digging in commit logs to see
[01:48:55] <jmkasunich> I think it was a case of me not understanding the viral nature of the GPL
[01:49:19] <jmkasunich> I explicitly made the hal.h LGPL, that is the definition of the interface as seen by a user
[01:49:30] <jmkasunich> (user = programmer writing a module)
[01:49:51] <jmkasunich> the programmer needs to link to hal_lib.c, which is also LGPL to allow that
[01:50:05] <jmkasunich> I didn't realise that everything that hal_lib.c included needed to be LGPL
[01:50:31] <jmkasunich> hal_priv.h is _internals_ of the hal library, that the user (proprietary or not) never sees
[01:50:47] <jmkasunich> so why do I have to LGPL it?
[01:52:50] <jmkasunich> I hate lawyering
[01:53:16] <jmkasunich> http://sourceforge.net/mailarchive/message.php?msg_id=14537143
[01:53:26] <jmkasunich> the relavent message
[01:53:48] <jmkasunich> specifically, this was the intent:
[01:53:49] <jmkasunich> +COPYING - implies that everything is GPL, revise to mention that
[01:53:49] <jmkasunich> +interfaces are LGPL
[01:54:05] <jmkasunich> I didn't see hal_priv.h as an interface
[01:54:11] <jmkasunich> I guess I'll change it back
[01:55:08] <jmkasunich> fsck, I don't want to change it back
[01:55:48] <jmkasunich> specifically - if somebody is writing code that interacts with those structs, I _don't_ want that code to be proprietary
[01:56:46] <jmkasunich> if they use _only_ the hal.h API, then they can go proprietary if they insist... any more "intimate" with hal's internals and it needs to be GPL
[01:56:55] <jmkasunich> the license on hal_priv.h stays as it is
[01:57:20] <jmkasunich> jepler: only you would notice that little inconsistency
[01:57:35] <jepler> yeah, everyone thinks I'm such a prick about licenses
[01:58:01] <jmkasunich> well changing hal_priv.h to LGPL would allow more proprietary stuff than I intend
[01:58:14] <jmkasunich> I'm gonna error on the side of less rather than more
[01:58:40] <jmkasunich> how is that normally handled by library writers?
[01:58:48] <jepler> I don't know.
[01:59:04] <jmkasunich> where you want to allow non-GPL use of the lib, but not allow wholesale copying of the lib code or use of its internals
[01:59:42] <jmkasunich> I think the licensing as it is now reflects my intent as well as anything I can come up with
[01:59:48] <jepler> are you sure the LGPL doesn't give you the protection you want? I haven't read it for a long time, but I think it tries to draw a distinction between the act of using the library vs the act of extending it.
[02:00:02] <jmkasunich> you can include hal.h and link to hal_lib.h, and that is all
[02:00:16] <jmkasunich> I have no intention of reading licenses tonight
[02:00:28] <jepler> I think I understand what you would like to do, but I think a license prick would say that hal_lib.o is GPL and thus yourhalcomponent.o (which links hal_lib.o) is GPL
[02:00:37] <jmkasunich> I'm gonna code some version testing stuff and pretend you didn't bring up the (L)GPL thing
[02:01:07] <jepler> please don't let me keep you from it
[02:01:19] <jmkasunich> if I make hal_priv.h LGPL, then someone could write a proprietary halcmd
[02:01:45] <jmkasunich> because with the struct definitions, they can go in and do all the linked list stuff that halcmd does
[02:02:33] <jmkasunich> I want to allow prop. hal modules, but not prop. utilities
[02:03:53] <jmkasunich> to be honest, a license prick could raise all kinds of issues... the simple fact that hal stuff is kernel modules gets into a gray area where there is massive debate
[02:04:26] <jmkasunich> ain't going there
[02:04:32] <jepler> go do your version checking thing
[02:04:36] <jmkasunich> right
[02:05:27] <fenn> um, whats wrong with someone writing a proprietary halcmd?
[02:05:46] <fenn> * fenn snarks
[02:05:51] <jmkasunich> cause I don't want them doing it, thats why!
[02:06:29] <fenn> cant you make halcmd part of hal_lib somehow?
[02:06:39] <jmkasunich> I can accept the possibility of some proprietary process control algorithm, or machine characteristics, that needs to be embedded inside a prop. module
[02:06:53] <jmkasunich> but everything else related to HAL needs to be open/free
[02:07:49] <jmkasunich> fenn: maybe... its possible that if/when we do a refactor, many of the halcmd "commands" might be implemented in the lib instead
[02:07:58] <fenn> i mean hal_lib is really worthless without halcmd
[02:08:29] <jmkasunich> so?
[02:08:46] <jmkasunich> gcc is GPL, but you can use it to compile prop. programs
[02:08:58] <fenn> eh, nevermind.. i dont understand how all this library license propagation stuff
[02:09:03] <jmkasunich> halcmd is GPL, but you can _use_ it to build prop. systems
[02:10:28] <jepler> jmkasunich: will you be around tomorrow? I want to talk again about adding the "(user) component ready" flag, but not tonight.
[02:10:42] <fenn> i do think a lot of stuff in halcmd should be functions in the lib (namely every last thing with a mutex in it)
[02:10:45] <jmkasunich> I think so
[02:10:55] <jmkasunich> fenn: someday
[02:16:49] <jmkasunich> hmm, one way to do the version check is to use a different shmem key...
[02:17:30] <jmkasunich> the downside to that is that you might wind up with two completely independent hal's
[02:17:42] <jmkasunich> with some components in one of them and others in the other one
[02:17:46] <jmkasunich> nasty
[02:22:16] <jmkasunich> ok, on this version thing
[02:22:38] <jepler> goodnight guys
[02:22:39] <jmkasunich> (thinking out loud)
[02:22:41] <jmkasunich> goodnight
[02:22:45] <Dallur> night
[02:23:26] <jmkasunich> its easy to make sure that version "tomorrow" and "tommorrow + N" don't conflict
[02:23:33] <jmkasunich> they both know about the version code and check it
[02:23:58] <jmkasunich> its a little harder to prevent versions "yesterday" and "tomorrow" from conflicting
[02:24:50] <Dallur> jmkasunich: you could draw a point here and change the shared mem key so that any version prior to today would not work with any future versions (just repeating what you said before and twisting it)
[02:25:24] <jmkasunich> the problem with changing the key is that the old version would open a shared memory region with the old key, the new version would open one with the new key
[02:25:40] <jmkasunich> things wouldn't work right, but there'd be no apparent reason
[02:25:53] <jmkasunich> however, I think I figured it out...
[02:26:07] <Dallur> make the new versions check if the old key exists and barf ?
[02:26:13] <jmkasunich> there already is a magic number, used to tell subsequent modules that the shmem is already initialzed
[02:26:24] <jmkasunich> I'll use the same key, but introduce a new magic number
[02:26:33] <jmkasunich> if it sees the old magic number, it will barf
[02:26:34] <Dallur> :)
[02:26:42] <jmkasunich> if it sees the new one, it will check the version string
[02:41:26] <jepler> jmkasunich: is there much of a penalty in rtapi for small malloc()s? (for instance, 4 bytes at a time for single 'hal_float_t *'s)
[02:42:00] <jepler> * jepler hasn't actually gone to bed and is instead mulling a Python module for userspace components
[02:42:24] <jmkasunich> hard to say
[02:42:44] <jmkasunich> in rtapi that is... rtapi malloc's go directly to the RTOS and/or kernel
[02:42:50] <jmkasunich> they might use large blocks
[02:43:18] <jmkasunich> if you are talking about hal_malloc (for space in the hal shmem block) then there is no overhead for multiples of 4 bytes
[02:43:50] <jepler> I guess I mean hal_malloc
[02:44:22] <jmkasunich> they you can do any size you want... all blocks will be returned on a 4 byte boundary, thats the only restriction
[02:48:39] <jepler> h = hal.component("test"); h.create_bit("b1", "w"); while 1: h.b1 = not h.b1 # a python hal component might look like this: creates toggling pin 'test.b1'
[02:49:18] <jmkasunich> interesting
[02:49:32] <jmkasunich> hal.component would invoke hal_init()?
[02:49:35] <jepler> yeah
[02:49:54] <jepler> and later you could call h.exit() or rely on python's garbage collection if you feel lucky (punk)
[02:49:58] <jmkasunich> you gotta make sure to invoke hal_exit()
[02:50:22] <jmkasunich> python's garabage collection isn't gonna know about hal_exit() is it?
[02:50:41] <jmkasunich> or would the destructor for
[02:50:43] <jmkasunich> oops
[02:50:46] <jepler> yes
[02:50:56] <jmkasunich> or would the destructor for 'h' invoke hal_exit()?
[02:50:57] <jepler> python can call some code when an object is collected
[02:51:17] <jmkasunich> interesting
[02:51:41] <jmkasunich> that API seems to imply that the following is possible:
[02:51:54] <jepler> it's not written yet so currently everything seems possible
[02:52:02] <jmkasunich> h1=hal.component(foo); h2=hal.component(bar)
[02:52:23] <jepler> is that possible in "C" (two hal components in one process)?
[02:52:34] <jmkasunich> I'm not sure what calling hal_init() twice from the same process would do, but I'm pretty certain it wouldn't be pretty
[02:52:41] <jepler> hm .. then it should error
[02:52:49] <jmkasunich> not sure it does tho
[02:53:02] <jepler> then the Python program would raise hal.error at the second call to hal.component()
[02:53:05] <jmkasunich> thats one of the issues that the refactor wants to address
[02:53:31] <jmkasunich> the concept of a component should really be like the individual things inside blocks.c, not like the entire blocks.c
[02:53:47] <jmkasunich> but hal_init() / hal_exit() operate on the entire thing scale
[02:54:05] <jmkasunich> they map/unmap shared memory to the process, for example
[02:54:50] <jmkasunich> for RT modules (like blocks) I want to separate out the loading of the module, from the instantiation of a ddt block
[02:55:02] <jmkasunich> so you would do "loadrtmod blocks"
[02:55:15] <jmkasunich> then "newblock ddt"
[02:55:25] <jmkasunich> or "delblock minmax.0"
[02:55:25] <jmkasunich> etc
[02:55:35] <jmkasunich> that would fit far better into your concept
[02:56:09] <Rugludallur> well, Im heading off to bed, there is one thing I would like to mention before I go to sleep (so I don't forget)
[02:56:47] <Rugludallur> I have been using comp now and I have noticed that when a = b comp does nothing to the output value
[02:57:23] <Rugludallur> which means that the last value before a = b is the one given when a = b, I just wonder if this is the desired functionality ?
[02:57:42] <jepler> Rugludallur: that seems to be by design
[02:57:59] <jepler> Rugludallur: when a=b the difference between a and b doesn't exceed the hysteresis
[02:58:11] <jmkasunich> if a > b, out is hi, if a < b, out is low, if a exactly = b, out is unchanged
[02:58:32] <jmkasunich> oops, I oversimplified
[02:58:45] <jmkasunich> if a is within the hystersis, out is unchanged
[02:59:05] <jmkasunich> if hystersis is zero, then if a exactly = b, out is unchanged
[02:59:14] <Rugludallur> I was just wondering if this was the desired functionality, nothing else :D
[02:59:28] <jmkasunich> depends on who is doing the desiring...
[02:59:34] <Rugludallur> indeed
[02:59:39] <jmkasunich> is it what you desire?
[03:00:06] <jmkasunich> for a comparator, its pretty easy to define what the output should be for a > b and a < b
[03:00:14] <jmkasunich> a = b is ambiguous
[03:01:20] <jmkasunich> heh, there is nothing preventing you from setting a negative hystersis
[03:01:36] <jmkasunich> in which case, for any input within the hystersis range, the output oscillates ;-)
[03:01:52] <Rugludallur> fine with me, I can work around it but I have a funny situation where b is a multiplier of max(a) so when a (and b) get to 0 ... well you see where it goes
[03:02:26] <jmkasunich> it goes nowhere... stays at whatever its current state waw
[03:02:27] <jmkasunich> was
[03:03:05] <Rugludallur> yes which might be a or be depending on which calculation was done last
[03:03:44] <jmkasunich> crap, I just realized my version detector is still no good
[03:03:59] <Rugludallur> but it is not a problem, just add 1 to a or b and I have a >= or <=
[03:04:00] <jmkasunich> the new on can correctly deal with any old one...
[03:04:09] <jmkasunich> yep
[03:04:22] <jmkasunich> the old one will overwrite shmem data from the new one
[03:04:24] <jmkasunich> yuck
[03:04:32] <Rugludallur> gn
[03:04:37] <jmkasunich> night
[03:04:38] <Rugludallur> and gl with the version
[03:04:44] <jmkasunich> ty
[03:05:16] <jmkasunich> damn, I think I do need to use a new shmem key
[03:05:50] <jmkasunich> yuck, yuck, yuck
[03:21:40] <cradek> jmkasunich: bearing mount is done! just have to screw it to the table and make the motor standoffs now
[03:21:53] <jmkasunich> cool
[03:22:03] <jmkasunich> I wish I was making as good progress
[03:22:10] <jmkasunich> backwards compatability sucks
[03:22:35] <jmkasunich> I should have put version checking code in ages ago
[03:23:11] <cradek> I didn't keep up with what you were trying to do
[03:23:46] <cradek> are you trying to protect dummies like me from what I did today?
[03:23:53] <jmkasunich> yes
[03:24:12] <jmkasunich> (if what you (and Dallur) did was use oldhalcmd with new components, or vice versa
[03:24:24] <cradek> sounds hard, us dummies find pretty creative ways to screw stuff up
[03:24:59] <jmkasunich> well, struct definitions that are shared between multiple independent programs should be tagged
[03:25:08] <jmkasunich> I did it for rtapi shmem structs
[03:25:10] <cradek> that's true
[03:25:16] <jmkasunich> pure oversight that I didn't do it for hal
[03:25:25] <jmkasunich> and its much harder to do it after the fact
[03:25:41] <jmkasunich> can I brainstorm with you for a bit?
[03:25:56] <jmkasunich> at first I thought about using differnet shmem keys
[03:26:01] <cradek> sure if you think I can help
[03:26:11] <jmkasunich> but that just means the old halcmd will open one shmem, and the new stuff will open another
[03:26:32] <cradek> so the wrong halcmd won't see any of the stuff?
[03:26:34] <jmkasunich> you'll have two "hals", both of which won't work, but no error messages to explain why
[03:27:12] <cradek> ok that prevents you from screwing it up, but is not ideal
[03:27:57] <cradek> you can't just put a version number at the beginning of the shared structure?
[03:28:13] <jmkasunich> right now there is a magic number there
[03:28:38] <jmkasunich> the first time any hal component is installed, it must init the global struct
[03:28:57] <jmkasunich> subsequent components aren't allowed to erase that data
[03:29:03] <jmkasunich> so the first one sets the magic number
[03:29:17] <cradek> ok
[03:29:25] <jmkasunich> I was gonna have a new magic number for the new code, and have it complain if it sees the old one
[03:29:44] <jmkasunich> but if you run the new code first, then the old code, the old code will overwrite the init done by the new code
[03:29:54] <jmkasunich> result, messy (segfaults, maybe even oopses)
[03:29:59] <cradek> yuck
[03:30:15] <jmkasunich> so thats right out.
[03:30:38] <cradek> the magic number ("this is hal land") and the version number are for two different things
[03:30:44] <jmkasunich> latest is having the same magic number, but have the new code check the version code (which will be located at the end of the master shmem struct)
[03:30:45] <jmkasunich> right
[03:31:01] <cradek> so if you don't try to combine them, is everything fine?
[03:31:06] <jmkasunich> fortunately, the last thing in the old master struct was a char
[03:31:31] <jmkasunich> so if I add a short for the version, it won't overlap the next struct in the shmem block (everything is 4-byte aligned)
[03:31:47] <cradek> seems like the magic number and version should be at the beginning, so you can always find them no matter what's changed in the structs
[03:31:52] <jmkasunich> I suspect, but can't guarantee, that the last 3 bytes of the old struct wil be zero
[03:32:22] <jmkasunich> if I add the version to the new struct, and you run an old program that doesn't check for the version, it can wreak havoc
[03:32:35] <jmkasunich> (if I add it at the beginning)
[03:32:57] <cradek> true I guess
[03:33:35] <jmkasunich> I think maybe I need to use two differnet keys
[03:34:22] <cradek> I see what you mean about this being hard to add after the fact
[03:34:24] <jmkasunich> all new modules would attempt to open a shmem using the old key
[03:35:09] <jmkasunich> if they find an already inited one (magic number in the front), they would exit with an error message
[03:35:21] <jmkasunich> if not, they would close it, and open another with the new key
[03:35:31] <jmkasunich> that one would have a version number at the beginning
[03:36:19] <jmkasunich> someone using the old programs will still have absolutely no clue that things are fscked though
[03:36:53] <cradek> you can't fix the old programs that don't have versioning
[03:36:59] <jmkasunich> no
[03:37:02] <cradek> so screw 'em
[03:37:27] <jmkasunich> but I need to make sure that running an old one after/with a new one won't cause massive bustage
[03:37:35] <jmkasunich> needs to be a benign failure
[03:38:33] <cradek> brb, cat issues
[03:38:39] <jmkasunich> hmm, I might be able to take advantage of they way our realtime script works
[03:38:54] <jmkasunich> we never load rtapi without loading hal_lib.ko
[03:39:36] <jmkasunich> so a user space program (halcmd, halui, halvcp, etc) will _never_ be the first one to open the shmem region
[03:41:33] <jmkasunich> case A: you have a new hal_lib.ko, and one or more old user space progs
[03:41:59] <jmkasunich> case B: you have an old hal_lib.ko, and at least one new user space prog (could have old ones too)
[03:43:12] <jmkasunich> case B is easy, the user space progs can see that there is an old hal_lib.ko loaded by magic number (if I change it for the new), or by the absence of a version code at the end of the struct
[03:46:32] <jmkasunich> gawd I'm an idiot
[03:47:03] <jmkasunich> back on 2004, I changed rtapi_shmem_new() to zero the first 4 bytes of any newly allocated shmem region
[03:47:52] <jmkasunich> that meant instead of checking for a magic number (and having a 1 in 4 billion chance of seeing it when I shouldn't) to decide if the data was already inited, I could simply check for zero
[03:48:21] <jmkasunich> but did I change the code back then? noooooooo.... I'm still checking for the magic, and _anything_ else will result in me re-initing the entire block
[03:50:11] <jmkasunich> I think the right thing to do is change to a complely different key
[04:19:43] <jmkasunich> 23:43: cradek: brb, cat issues
[04:19:52] <jmkasunich> must be nasty issues...
[04:24:10] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/ (hal_lib.c hal_priv.h): added version tagging for HAL shared memory structures, to head off problems that arise when people use old copies of halcmd with newer kernel modules or vice-versa
[04:28:43] <jmkasunich> goodnight
[05:17:08] <Jymmm> hi jmkasunich
[08:41:44] <Bo^Dick> when i draw around 1 amp current the voltage goes down to 14.91 volts from 15.03 volts. is this normal for an LM317 voltage regulator?
[09:17:38] <^Eugenics> maybe a question for ##electronics
[11:55:28] <giacus> hellooo
[11:55:46] <giacus> * giacus goes to fish mullets :P
[13:54:06] <Jymmm> fenn wake up!
[13:54:26] <Jymmm> fenn I have a present for you!
[13:54:40] <Jymmm> fenn
http://www.machinist-toolbox.com/qcode.htm
[14:05:25] <Roguish> good morning all. a little help with linux and X server?
[14:07:32] <SWPadnos_> sure - let's see what we can break
[14:07:34] <SWPadnos_> err - fix
[14:09:04] <Roguish> just got a new mb and cpu. loading Breezy, everything ok (i think) and X server fails.
[14:09:14] <SWPadnos_> what video card?
[14:09:17] <SWPadnos_> or chip
[14:09:42] <Roguish> build in AIT Express 200
[14:09:42] <Roguish> ATI
[14:10:03] <Roguish> the .log file shows it was correctly identified.
[14:10:04] <SWPadnos_> that's the chipset, does it also have integrated graphics?
[14:10:41] <Roguish> yes. it has a plug!
[14:11:30] <Roguish> Ati Tadeon Xpress 200
[14:11:42] <Roguish> Radeon
[14:12:15] <SWPadnos_> well, I've had a lot of problems with the ATI driver in Breezy, and A-L-P-H-A has as well
[14:12:51] <SWPadnos_> I installed the ATI proprietary drivers, and they seem to work, but they're not accelerated (on my Radeon 8500DV)
[14:13:20] <SWPadnos_> they fall back to software rendering, so I get a paltry 100 or so FPS in glxgears
[14:13:41] <SWPadnos_> the other thing to check is that the mouse driver is pointing at the correct /dev file
[14:15:05] <Roguish> is that in xorg.conf?
[14:27:47] <SWPadnos_> yep (sorry - phone)
[14:29:33] <Roguish> everything seems to point correctly.
[14:30:03] <SWPadnos_> ok. I think it changed from /dev/mouse to /dev/input/mice or something like that
[14:30:22] <SWPadnos_> unfortunately, I don't have that machine here right now, so I can't check
[14:30:34] <Roguish> yes.
[14:30:42] <SWPadnos_> brb
[14:32:11] <Jymmm> * Jymmm plays the theme from Jeopardy while Roguish waits for SWPadnos_ return
[14:32:40] <Roguish> has emc2 been installed with ubuntu 6?
[14:33:08] <Dallur2> Dallur2 is now known as Dallur
[14:35:59] <jepler> Roguish: yes -- if you have a "dapper" 6.06 machine, you can install emc2 on it by changing each "breezy" to "dapper" in the emc2-install.sh script
[14:36:16] <Roguish> that's it?
[14:38:14] <Roguish> if ATI works better in dapper, i'll try that.
[14:39:01] <jepler> I don't know if there's any big difference in video card support between the two
[14:47:39] <Dallur2> If anyone in Germany wants a cheap Large CNC Plasma cutting table there is one on Ebay which is currently listed at 1000 Euro
[14:47:39] <Dallur2> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ih=007&item=170002010721&rd=1&sspagename=STRK%3AMEWA%3AIT&rd=1
[14:53:43] <SWPadnos_> oops - I hadn't had enough caffeine - I had problems in dapper, but it worked fine in breezy
[14:54:32] <Roguish> i'm using breezy. very frustrating.
[14:55:20] <cradek> my ati laptop worked in breezy without doing anything special
[14:55:21] <SWPadnos_> I think A-L-P-H-A found that there's a problem with XOrg 7.0 and ATI. he was waiting (im)patiently for ubuntu to release XOrg 7.1
[14:55:27] <cradek> you could always try the vesa driver
[14:55:36] <Roguish> 'fatal server error: Caught signal 4. Server aborting'
[14:55:55] <Roguish> how do i do the vesa driver?
[14:56:07] <cradek> change xorg.conf to say Driver "vesa"
[14:56:30] <cradek> where it probably says Driver "ati" currently
[14:58:26] <Roguish> cool, now i get a screen with nothing on it other than the cursor x
[15:00:47] <SWPadnos_> no X weave background?
[15:00:54] <Jymmm> Roguish do you have two video cards?
[15:01:02] <Roguish> no
[15:01:07] <Jymmm> ok , nm
[15:02:23] <cradek> there's no longer a weave background - the default is black
[15:02:44] <cradek> Roguish: try rebooting it now, maybe gdm is confused
[15:05:30] <Roguish> i think gdm is sick. after booting, the ubuntu load screeen show, then the monitor goes black and shows 'out of range'
[15:09:08] <cradek> maybe the video mode is wrong
[15:09:49] <Roguish> that was after i changed 'ati' to 'vesa'
[15:18:10] <Rugludallur> Ahhaa, time to bring out the shotgun and visit my neighbor, since he is now working outside with an angle grinder I have noticed that whenever he is using alot of power my internet stops working, that bastard
[15:18:47] <jepler> Rugludallur: hah
[15:19:15] <Rugludallur> It must be that the em field generated from his power cables somehow cross with my phone/dsl line and .....
[15:19:36] <Rugludallur> That is the only logical expl. that I can think off
[15:21:27] <Rugludallur> on something a bit more related to emc, I have been using the feedback signal from stepgen and I have noticed that it is really jerky
[15:21:37] <Rugludallur> is that normal ?
[15:21:49] <Jymmm> Rugludallur: STOP ROLLING OVER THE NETWORK CABLE WITH YOUR CHAIR!
[15:22:02] <Rugludallur> Jymmm: ahh yahhh sorry
[15:22:15] <Jymmm> (looking out the window at your neighbor =)
[15:23:30] <Jymmm> True story --> "The computer resets itself every time the toilet is flushed"
[15:23:45] <SWPadnos_> don't put the computer in the toilet
[15:25:34] <Jymmm> Guy called Dell T/S and said that. they all thought he was full of shit for three weeks. Finally one tech listened a tad longer and figure this guy is in a rural area and has an electric water well on the property and was causing a brown out.
[15:29:37] <jepler> Rugludallur: the feedback position will be updated each servo cycle, not each base_period.
[15:35:59] <SWPadnos_> hi Ray
[15:36:04] <Jymmm> Ray! ltns
[15:37:42] <rayh> Hi guys.
[15:37:52] <rayh> What's happening today?
[15:38:20] <SWPadnos_> not much, it seems
[15:39:07] <fenn> wow jymmm that qcode program almost does as much as jon elson's 20 year old C programs
[15:39:26] <Jymmm> fenn is that a good thing?
[15:39:30] <SWPadnos_> see - nothing new has been invented since the Concorde
[15:39:39] <fenn> jymmm not really
[15:40:07] <SWPadnos_> heh - I wrote software that's older than you!
[15:40:10] <SWPadnos_> what a funny line
[15:40:16] <Jymmm> fenn then crawl back under your blue foam rock!
[15:40:30] <fenn> * fenn goes back to lisping
[15:40:34] <Jymmm> lol
[15:40:48] <fenn> Jymmm: lisp is like XML from hell
[15:40:57] <bill203> but with more parens
[15:40:59] <Jymmm> fenn please tell me your kidding about using lisp
[15:41:05] <SWPadnos_> jsut remember all the curly braces or parentheses or whatever
[15:41:31] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[15:41:52] <bill203> and the smug sense of satisfaction.
[15:41:57] <Jymmm> fenn and XML is the spawn of satan btw.
[15:43:24] <fenn> then lisp must be satan
[15:43:38] <fenn> * fenn smugs helplessly
[15:43:51] <Jymmm> fenn: I know it's old, but is it that bad?
[15:44:06] <cradek> lisp is only bad until you get to know it
[15:44:19] <cradek> (that might be true about xml too, but I have my doubts)
[15:44:25] <bill203> xml is ok.
[15:44:31] <fenn> aside for the parentheses lisp seems pretty cool actually
[15:44:35] <fenn> from*
[15:44:45] <jepler> <lisp><paren>+ 3 2</paren></lisp>
[15:45:05] <Jymmm> RPN ?
[15:45:24] <cradek> if you aren't using emacs (or another editor that formats lisp correctly) it sucks
[15:45:27] <jepler> No, in RPN the + would come last
[15:45:35] <Jymmm> ah
[15:45:56] <cradek> if you aren't using emacs (or another editor that formats lisp correctly and has good paren matching) it sucks
[15:46:36] <fenn> well i'm just playing around so far
[15:47:27] <Jymmm> fenn any particular reasonign for your lisp madness?
[15:47:46] <fenn> my PLAN TO TAKE OVER THE WORLD
[15:48:07] <fenn> why else?
[15:48:07] <Jymmm> fenn Well, Good Luck with that!
[15:49:30] <cradek> the real problem with lisp as I see it is the libraries are nonexistent - where you can do http/smtp/opengl?/tk? easily with python/perl/ruby it's not that way with lisp.
[15:49:54] <cradek> 'asok
[15:49:57] <cradek> oops
[15:50:38] <fenn> why is that anyway?
[15:50:46] <fenn> i mean python didnt just magically appear some day
[15:50:56] <cradek> I don't really know
[15:51:10] <cradek> both (python/lisp) are easily? extensible in C
[15:51:43] <Jymmm> probably sick and tired of PHP and tried python and just took off
[15:51:47] <fenn> i see a lot of things i like about python that they actually "stole" from lisp
[15:58:38] <jepler> cradek: causes a following error on the 'max' configuration: G20 F999 / G00 X1.5 Y0 Z1 / G00 Z1.1 / G01 Z1 / M2
[16:00:17] <cradek> that's without segment joining even turned on right?
[16:00:49] <cradek> before you just rip it out, let me look at it
[16:01:44] <jepler> I strongly suspect it's another external vs internal units thing
[16:01:57] <jepler> maybe I'm using the wrong units in the list of points to be merged or something
[16:03:37] <jepler> the first error appeared to be on a G1 -> G0, this one is G0 -> G1
[16:07:41] <cradek> it might be toExtVel (linear_move and friends aren't set in flush_segments)
[16:08:36] <jepler> well, reverting the "merge" code fixes this problem
[16:09:06] <cradek> what sets those globals when pulling chained_points off?
[16:10:31] <jepler> only in the case 'linear_move && !angular_move' would points be combined so I blew off updating the globals
[16:11:00] <cradek> ok
[16:13:38] <jepler> and anyway that's the case through this whole example program
[16:14:37] <cradek> ok, the queue is in external units, but getStraightVel/Acc should be called in internal units
[16:14:47] <cradek> in flush_segments you're calling them in external units
[16:15:13] <cradek> you should make the queue internal units I think
[16:15:24] <cradek> or something
[16:19:24] <jepler> yeah
[16:22:55] <jepler> you're right, that fixes it
[16:23:03] <cradek> whee
[16:23:04] <jepler> I wonder why I didn't see it right the first time you ran into the problem
[16:23:24] <cradek> because it's a tangled mess of units?
[16:23:43] <Jymmm> * Jymmm quietly removes the bottle of whiskey from jepler's desk.
[16:24:47] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/task/emccanon.cc:
[16:24:47] <CIA-8> store internal units in chained_points. fixes the "following error" bug in the
[16:24:47] <CIA-8> right way.
[16:26:03] <jepler> Jymmm: thanks, but the problem is not so simple as mere substance abuse
[16:26:38] <Jymmm> jepler One step at a time, one step at a time.
[16:30:39] <Jymmm> jepler: First, you must admit that you have a substance abuse problem, no, I don't care if don't actually have one, you must admit that you do as the first step!
[16:31:02] <fenn> * fenn has a substance abuse problem!
[16:31:14] <Jymmm> fenn lack of ?
[16:31:33] <Jymmm> or did you spill the whiskey (again) ?
[16:32:04] <fenn> i hyperventilate.
[16:32:24] <Jymmm> * Jymmm hands fenn a paper bag.
[16:40:31] <Jymmm> SWPadnos: Do you have any bright clear red led's (3mm) ?
[16:40:38] <SWPadnos> nope
[16:41:04] <Jymmm> SWPadnos: Thanks. I think I'll order some of the pinks ones too.
[16:41:10] <Jymmm> -s
[17:21:56] <Jymmm> lo Mess
[17:30:05] <Mess> Hello...
[17:31:51] <Jymmm> Still traveling?
[18:07:56] <jepler> pink LEDs?
[18:08:08] <SWPadnos> to go with the pinnk tutu
[18:08:12] <SWPadnos> -n
[18:12:57] <Jymmm> Yeah, hold on...
[18:14:13] <Jymmm> http://search.ebay.com/160005313817
[18:21:49] <Roguish> ok, got it working, not sure how, but oh well. got emc2 testing tarball and extracted. now, trying to build for run in place and get 'no acceptable C compiler found...........'
[18:21:52] <Roguish> what now?
[18:22:14] <Roguish> did i leave out a step?
[18:23:15] <giacus> you have to install a bunch of packages before proceed compiling Emc2
[18:23:39] <Roguish> i already have emc2 released installed.
[18:23:58] <Roguish> and working
[18:24:07] <Jymmm> Roguish: Do you have any dev tools intalled? A compiler maybe?
[18:24:17] <Jymmm> gcc?
[18:24:21] <Roguish> how would i know?
[18:24:37] <Roguish> brand new everything.
[18:24:46] <Jymmm> THAT, I wouldn't know. Try typing gcc in a shell and see what happens
[18:24:49] <giacus> this page could help
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Installing_EMC2
[18:25:03] <Roguish> command not found
[18:25:21] <Jymmm> Roguish: sudo updatedb;locate gcc
[18:25:27] <Roguish> and i'm on that page.
[18:25:35] <giacus> gcc is just to start .. I suppose you have to install 20-30 packages yet ..
[18:26:38] <Jymmm> Roguish if you've never ran updatedb before, it'll take a few minutes.
[18:26:52] <fenn> Roguish: type this: sudo apt-get build-dep emc2-axis
[18:26:58] <Roguish> ok, it shows lots of gcc stuff
[18:27:41] <Roguish> working, getting lots of packages.
[18:27:45] <fenn> yay
[18:27:57] <Jymmm> fenn You took over the world?
[18:27:58] <Roguish> i HATE computers.
[18:28:04] <Jymmm> Me too!
[18:28:10] <giacus> I hate peoples !
[18:28:16] <giacus> and love computers :P
[18:28:23] <Jymmm> * Jymmm runs away with Anna
[18:28:25] <giacus> just need to do it right
[18:28:29] <giacus> haha
[18:28:47] <Jymmm> giacus: Yeah, I bet you dont hate people THAT much now, do you!
[18:28:54] <giacus> Jymmm: got no luck fishing today: 0
[18:29:03] <Roguish> ok, now it's buildign a lot more.
[18:29:04] <fenn> o/~ I hate the world and the world hates me o/~
[18:29:09] <Jymmm> giacus bait or fly, shore or boat?
[18:29:13] <giacus> I'll back tomorrow .. :D
[18:29:23] <giacus> surfacsting
[18:29:30] <giacus> surfcasting*
[18:29:37] <Jymmm> giacus boat or shore?
[18:29:42] <giacus> bait for mullets
[18:29:45] <giacus> shore
[18:30:00] <Roguish> compiling
[18:30:10] <giacus> I think its a bad lunar phase right now
[18:30:14] <Jymmm> ah, I dont' think I've ever salt water fished, and never on the shore.
[18:30:17] <giacus> moon*
[18:30:43] <Jymmm> But, I did catch my very first fish with a string on a stick =)
[18:30:58] <giacus> have to re-try tomorrow ;)
[18:31:03] <Jymmm> 10" rainbow trout
[18:31:25] <giacus> nicee
[18:31:25] <Roguish> works!!!!!!!
[18:31:36] <Roguish> thanks all..........................
[18:34:08] <Jymmm> Roguish: Dont thank us, just sponsor the "Fenn taking over the world fund", for just $0.50/day, the mere cost of a newspaper, Fenn will be able to take over and rule the world!
[18:34:18] <fenn> its true
[18:34:43] <fenn> and if you sign up today to become one of my minions or henchmen, you get a free jetpack!
[18:35:23] <Jymmm> * Jymmm could be a henchmen, been a bouncer, not much difference.
[18:35:37] <fenn> offer void where prohibited, some rules may apply, consult your doctor before taking anything for granted
[18:36:07] <Jymmm> Hello, Dr Seuss....
[18:37:56] <SWPadnos> "if a packet hits a pocket on a socket on a port ..."
[18:38:08] <SWPadnos> "then the socket packet pocket has an error to report"
[18:41:57] <Jymmm> lol... that's the best network geek joke I've heard =)
[18:42:13] <SWPadnos> there's more - I just can't remember it all
[18:42:36] <Jymmm> That's a tounge twister in itself as it is!
[18:42:37] <SWPadnos> http://web.mit.edu/adorai/www/seuss-technical-writing.html
[19:10:37] <Jymmm> SWPadnos you know much about RF ?
[19:10:52] <SWPadnos> yeah - it makes radios work
[19:11:27] <Jymmm> SWPadnos: How hard would this be to duplicate functionality wise?
http://electronicsusa.com/csd.html
[19:14:41] <SWPadnos> not too hard, as long as the frequency range is limited
[19:16:12] <jepler> it's an RF transmission detector? it seems like that would be pretty simple.
[19:16:32] <SWPadnos> yep
[19:17:16] <SWPadnos> but it would have to be fairly narrow band, so it doesn't get falsely triggered by nearby stations
[19:18:41] <SWPadnos> I think there are RF microcontrollers that could do this with one chip and a couple of discrete parts
[19:18:50] <jepler> surely 5W at 10' is going to be much more powerful than any station at any distance
[19:18:59] <jepler> maybe my intuition is wrong about that
[19:19:05] <SWPadnos> heh
[19:19:20] <SWPadnos> depends somewhat on the quality of the transsmitter
[19:20:01] <Jymmm> since it's from hf to UHF... I'm thinking every cordless phone and wifi is gonna trigger it.
[19:20:10] <SWPadnos> but you're right - that one just has adjustable sensitivity, and is wideband
[19:20:22] <SWPadnos> right - you want tunability
[19:20:33] <Jymmm> No, not really.
[19:20:52] <Jymmm> wideband is good. no notch filters
[19:21:32] <SWPadnos> but all power in the passband goes to the detector, so as you said, every radio device in the area will add to the net detected
[19:21:37] <SWPadnos> power
[19:22:09] <Jymmm> they say 5w+, no unlicensed Tx is close to that.
[19:23:14] <Jymmm> I wonder if I could rip apart one of those wifi detectors and do somethign with that.
[19:23:18] <SWPadnos> ok - I hadn't noticed the power spec
[19:23:21] <SWPadnos> wrong band
[19:23:26] <SWPadnos> those are 2.45 GHz
[19:23:36] <SWPadnos> this should be ~80-250 MHz
[19:23:48] <jepler> I don't understand RF but I found this "simple field strength meter", claims 30MHz to 2GHz:
http://www.qsl.net/n9zia/wireless/appendixF.html#3
[19:23:51] <Jymmm> 20KHz - 1.2GHz
[19:25:13] <Jymmm> looking...
[19:29:27] <Jymmm> Hot Damn!
http://geocities.com/ajpotts19/wavemeter.html
[19:29:38] <Jymmm> 1MHZ to 950MHz
[19:29:45] <Jymmm> Thanks jepler !!!
[19:31:08] <Jymmm> Shit, could get much simpler than that!
[19:31:12] <Jymmm> couldn't
[19:32:09] <SWPadnos> yeah - that looks way simpler than anything I would have done ;)
[19:32:59] <Jymmm> SWPadnos: You're just a digital guy, but I would hold that againest ya =)
[19:33:10] <Jymmm> s/would/won't/
[19:33:27] <SWPadnos> I'm used to radio designs that need to work from ~1600 feet, 99.99999% of the time, and in ~300-500 uS
[19:33:45] <SWPadnos> so the "diode detector" is a little beneath me
[19:33:54] <SWPadnos> * SWPadnos holds nose up in the air
[19:34:11] <SWPadnos> not that I did the hardware design on those anyway ;)
[19:34:32] <Jymmm> wth is this uS chit?!
[19:34:49] <Jymmm> you and your digital mumbo jumbo!
[19:35:03] <Jymmm> Speed of Light baby!
[19:35:09] <SWPadnos> microseconds - I know it's hard to understand metric prefixes and ISO standard units ;)
[19:36:05] <Jymmm> oh I know what it means, but when you have a delay on a radio (other than hitting the PTT), you gots to be talk'n digital.
[19:36:15] <SWPadnos> but of course
[19:36:40] <SWPadnos> channelized digital with sub-channels encoded and all that jazz
[19:36:59] <Jymmm> Yeah, trunking/celluar type stuff.
[19:37:06] <SWPadnos> err - no
[19:37:16] <SWPadnos> http://www.pocketwizard.com/HTML/products.asp
[19:37:43] <SWPadnos> stupid flash web designers
[19:37:46] <Jymmm> SWPadnos: I'll take four please
[19:37:58] <SWPadnos> ok - that'll be $1200 please
[19:38:01] <Jymmm> WEll, one Tx, 3 Rx
[19:38:08] <SWPadnos> they're transceivers
[19:38:11] <Jymmm> SWPadnos just put it on my acnt
[19:38:21] <SWPadnos> you're over limit ;)
[19:38:37] <Jymmm> Fine, put it on YOUR acnt.
[19:38:43] <SWPadnos> ok
[19:39:15] <Jymmm> 4 would be $1200 ?
[19:39:16] <SWPadnos> the funny thing is, I co-founded the company and wrote all the software for the products (not these, but an earlier generation), and I don't even own any
[19:39:42] <SWPadnos> B&H will give you a good price ...
[19:40:07] <Jymmm> AH, abouttthe same as SB-800
[19:40:15] <SWPadnos> yeah - the high end one is $300 per unit, the plus II is ~$160
[19:40:34] <SWPadnos> but the SB-800 won't trigger a camera
[19:41:01] <Jymmm> No, it acts as a master, and triggers the slaves WITH TTL.
[19:41:13] <SWPadnos> right, but not the camera ;)
[19:41:18] <SWPadnos> and only more SB-800s
[19:41:27] <SWPadnos> (or other compatible Nikon flashes)
[19:41:29] <Jymmm> or SB-600 slaves
[19:41:42] <Jymmm> What, those have TTL ?
[19:41:59] <SWPadnos> the PW should get TTL soon (though Jim's been saying that for years), and at that point, it'll work with any camera and strobe that do TTL
[19:42:35] <SWPadnos> also, there are Sekonic light meters that have the transmitters built in, as well as several strobe manufacturers with built-in receivers
[19:43:18] <Jymmm> ah, cool. Sounds like this is getting REALLY expensive now =)
[19:43:50] <SWPadnos> I don't really keep track. I just wait for the quarterly stock dividend checks ;)
[19:44:00] <SWPadnos> so buy lots, right now!
[19:44:09] <Jymmm> I could use two SB-600 slaves and be alright for most.
[19:44:11] <Jymmm> lol
[19:45:00] <Jymmm> I'm not up to par going full manual yet, dont even have a light meter.
[19:45:13] <SWPadnos> the camera has one
[19:45:25] <Jymmm> HEll, I don't even know how to program the SB-800 flash!
[19:45:34] <SWPadnos> I just stick it on automatic, look at the settings it would use, then change them a bit
[19:46:18] <SWPadnos> actually, the P mode on the F100 is pretty nice - use the back wheel (I think) to change the shutter speed / aperture mix
[19:46:32] <Jymmm> The lat time I setup RC flash, I had to call Nikon to ask about setting the channel in the camera to trigger it. It's like one line in the 300 page manual that tells you.
[19:46:33] <SWPadnos> same exposure, but different depth of field and "streaks"
[19:46:42] <SWPadnos> heh
[19:47:08] <Jymmm> 'A' mode isnt' too shabby
[19:47:26] <SWPadnos> isn't A the "aperture priority" mode?
[19:47:34] <Jymmm> nod
[19:48:00] <SWPadnos> I usually use P, then scroll through the combos for the aperture or speed I want
[19:48:36] <SWPadnos> and I think the other wheel allows over/underexposure control
[19:48:47] <Jymmm> Gas has been so high lately, I really haven't had a chance to do a alot of shooting.
[19:48:51] <SWPadnos> I guess I could take the camera out of the case ;)
[19:49:16] <SWPadnos> speaking of gas, maybe I'll go make a bowl of chili
[19:49:31] <Jymmm> gimme a sec, I'll show you my latest...
[19:50:29] <Jymmm> SWPadnos:
http://static.flickr.com/71/176115969_d894084b87_o.jpg
[19:50:50] <jepler> mmmm chili
[19:51:05] <Jymmm> I found that location after driving around 40 miles.
[19:51:23] <SWPadnos> cool
[19:51:37] <jepler> actually, since it's summer, gazpacho is the thing .. not chili
[19:51:50] <SWPadnos> true, but I have canned chili in the cupboard
[19:52:02] <jepler> woah -- hold on here -- canned chili?
[19:52:03] <SWPadnos> and spinakopita
[19:52:12] <SWPadnos> not canned - in the fridge
[19:52:21] <SWPadnos> yep - from Costco
[19:52:28] <SWPadnos> tasty (enough)
[21:14:04] <A-L-P-H-A> yes, I was waiting impatiently on an xorg 7.1 release with ubuntu.
[21:17:02] <Jymmm> You know, I really enjoy Knoppix... It just works.
[21:21:07] <Jymmm> Sounds like a marketing slogan, but I've had very good luck with it.
[21:22:11] <Jymmm> much more than ubuntu
[21:25:35] <SWPadnos> if you like Knoppix, try Mepis
[21:25:59] <SWPadnos> it worked better for me than Knoppix, on my laptop at least
[21:26:16] <Jymmm> SWPadnos what wifi chipset do you have on your laptop?
[21:26:24] <SWPadnos> I dunno
[21:26:26] <Jymmm> Atheros?
[21:26:39] <Jymmm> k
[21:26:58] <SWPadnos> it's a 5 year old clone P3
[21:27:04] <Jymmm> AH, ok.
[21:27:38] <SWPadnos> on which Mepis installed and ran perfectly, including correctly detecting hte 1400x1050 LCD
[21:28:12] <SWPadnos> the Knoppix of the era missed that, and didn't configure power saving stuff (and CPU fan control) correctly either
[21:29:17] <Jymmm> I'm not sure if knoppix did the apc or not (never looked), did every thing but the wifi, but I think that's something I have todo, and just dont understand the README's
[21:30:09] <SWPadnos> I've never taken the time to get wifi working under Linux - I have a windows HD for the laptop
[21:30:28] <SWPadnos> one day I will, but probably not with this pcmcia card ;)
[21:30:49] <Jymmm> hehm mine IS supported, I just dont "get it" instructions wise.
[21:31:24] <Jymmm> Mine is a portable desktop anyway...
[21:31:36] <SWPadnos> this was one of the first 802.11a/b cards, so who knows
[21:31:43] <SWPadnos> or b/g - whichever
[21:31:48] <SWPadnos> don't remember
[21:31:52] <Jymmm> b/g
[21:32:02] <Jymmm> b/g == 2.4GHz
[21:32:08] <SWPadnos> a = 5.8
[21:32:08] <Jymmm> 1 == 5.?? GHz
[21:32:19] <Jymmm> s/1/a/
[21:33:10] <cradek> ][[[[[[[[[[56~~~~4
[21:34:29] <Jymmm> cradek More cat issues I see.
[21:34:37] <cradek> yep sorry
[21:34:46] <Jymmm> cradek: It's all good =)
[21:34:57] <SWPadnos> mine is sitting in my lap, peacefully sleeping
[21:35:02] <SWPadnos> no claws even
[21:35:33] <cradek> mine's stomping around on me purring loudly
[21:35:40] <SWPadnos> heh
[21:58:29] <jepler> my python hal module works
[21:58:41] <jepler> this python program creates a component that counts up about 5 times per second:
[21:58:42] <jepler> import hal, time
[21:58:42] <jepler> h = hal.component("test")
[21:58:42] <jepler> h.newpin("i", hal.HAL_S32, hal.HAL_RD)
[21:58:42] <jepler> while 1:
[21:58:44] <jepler> time.sleep(.2)
[21:58:47] <jepler> h.i = h.i + 1
[23:01:04] <robin_sz> meep?
[23:01:06] <robin_sz> sigh ...
[23:01:23] <robin_sz> when you UPS goes bad, you know its not going to be a fun evening
