#emc-devel | Logs for 2007-04-04

[00:01:14] <christel> [Global Notice] Hi all! Wanted to do a quick reminder about FOSSCON, the conference we are arranging in Sunny San Diego, September 22nd and 23rd! The Call for papers is out: http://fosscon.org/cfp and we'd love to have your submissions. If your project or organization is interested in a booth, please get in touch at nfp@fosscon.org Have a great day, and thank you for flying freenode!
[00:39:50] <cradek> has anyone checked out chris morley's CL patch?
[00:40:06] <cradek> I hate to leave him hanging, but I'm clueless about CL
[00:40:20] <jmkasunich> so am I
[00:40:32] <jmkasunich> I looked (briefly) at it - its not a small patch
[00:41:22] <cradek> I agree
[00:41:41] <jmkasunich> some of the changes are not the fixes he put in
[00:41:58] <jmkasunich> he's doing things like changing the program name from "classicladder" to "emcladder"
[00:42:34] <cradek> hmm
[00:44:33] <jmkasunich> yeah, thats what I said
[03:50:07] <elson> Hello, all!
[03:50:38] <SWPLinux> hi Jon
[03:50:42] <SWPLinux> how are things?
[03:51:13] <elson> Chris, I'm having a problem getting Axis installed on a new system. I got a complete CVS update, and then fooled around with getting the right packages installed.
[03:51:31] <elson> Steve, really great! I just got a pick and place machine installed here.
[03:51:37] <SWPLinux> cool
[03:53:34] <elson> Finally got all packages so I think Axis is compiled, but I get a message: Import error: libemchal.so.0: cannot open shared object: no such file - but the file is really there. Maybe an env. variable problem or something?
[03:54:04] <elson> EMC runs fine with tkemc, but I get this error with Axis.
[03:54:56] <SWPLinux> are you compiling then installing, or doing run-in-place?
[03:55:32] <elson> I'm doing the run-in-place thing.
[03:56:16] <SWPLinux> ok, are you running as root or a normal user?
[03:56:32] <SWPLinux> (ie, did you do 'sudo make setuid'?)
[03:56:40] <elson> normal user, but i do the sudo make install
[03:57:22] <SWPLinux> ok
[03:57:24] <elson> no, no, I mean sudo make setuid
[03:57:51] <SWPLinux> ok - that's what I read anyway ;)
[03:59:00] <SWPLinux> it surprises me that the file wouldn't be found (though that may not be the real problem)
[03:59:13] <SWPLinux> let me start a compile and see what happens
[03:59:35] <SWPLinux> when did you get the CVS update?
[03:59:41] <elson> Yes, the file is there, so I guess it must be looking somewhere else.
[04:00:01] <SWPLinux> try sourcing scripts/emc-environment
[04:00:03] <elson> I got it over the weekend - Saturday, I think.
[04:00:07] <SWPLinux> ok
[04:00:51] <elson> Umm, not sure what you mean by "sourcing"
[04:01:26] <SWPLinux> either use a period or the keyword "source"
[04:01:39] <SWPLinux> like '. scripts/emc-environment'
[04:01:55] <elson> OK, I'll try it.
[04:02:19] <SWPLinux> that puts the environment variables into the current shell, rather than spawning a subshell (which then gets the changes, but they don't get passed back to the shell you typed in)
[04:02:58] <SWPLinux> err - subprocess, not subshell ...
[04:04:17] <elson> OK, I did the . scripts/emc-environment and then tried to run emc and got the same message.
[04:04:28] <SWPLinux> ok
[04:05:02] <SWPLinux> well, we'll see how long the compile takes on this P3 laptop ...
[04:05:25] <elson> I guess tkemc doesn't connect directly to HAL, so it doesn't try to connect to the same library.
[04:05:46] <SWPLinux> right - any of the emcsh programs won't be affected by this library
[04:10:20] <SWPLinux> well, I can truthfully say that compiling on a single P3@1GHz is slower than quad opteron cores at 2.2 GHz
[04:11:05] <elson> Hmm, it compiles pretty quickly on my 600-700 MHz Dell boxes. But, it may be 5-10 minutes.
[04:11:27] <SWPLinux> real 6m13.138s
[04:11:29] <SWPLinux> user 4m29.655s
[04:11:30] <SWPLinux> sys 0m26.233s
[04:11:36] <SWPLinux> not too bad for a full build, I guess
[04:12:41] <SWPLinux> well, it loads fine for me here ...
[04:12:54] <elson> Geez, I just moved my home data logging software over to Linux from the MicroVAX II. Scanning a day's worth of data on the VAX took about 2 minutes, less than a second on the 700 MHz P2.
[04:13:05] <SWPLinux> I did ./configure, then make, then make setuid
[04:13:07] <SWPLinux> heh
[04:13:33] <elson> Yes, that is what I did here. I can't figure out what I did wrong.
[04:13:53] <SWPLinux> is this an Ubuntu system or one based on some BDI of yore?
[04:13:57] <elson> Maybe you shouldn't have the user account named "emc", but again, it works with tkemc.
[04:14:35] <elson> Ubuntu.
[04:15:07] <SWPLinux> err - don't you choose the user account name when you install?
[04:15:12] <elson> Oh, I did the ./configure --enable-run-in-place
[04:15:18] <SWPLinux> yep, me too
[04:15:24] <elson> Yes, I chose emc.
[04:15:34] <SWPLinux> ah
[04:15:43] <SWPLinux> I don't think the username should mater
[04:15:45] <SWPLinux> matter
[04:16:58] <elson> it shouldn't. I'm grabbing at straws. I did have the directory structure not the way I wanted it, and moved the emc2 home directory. That didn't work, so I did the whole config,make,seuid process over. Maybe that messed it up.
[04:17:39] <SWPLinux> well, I'll say "it shouldn't have", but then again I don't know exactly what you did, or if it could have screwed things up
[04:17:58] <SWPLinux> actually, you probably do need to make clean after changing directories
[04:18:13] <jmkasunich> yeah, and probably configure too (for run in place)
[04:18:18] <elson> Yes, I was thinking the same thing. I will try that now.
[04:18:19] <SWPLinux> he did that
[04:18:22] <jmkasunich> because it codes paths to the in-place stuff
[04:18:41] <elson> Hello, John!
[04:18:42] <jmkasunich> hi
[04:18:42] <SWPLinux> right - things like RT modules and the like, as well as paths in the run script
[04:19:03] <elson> But, I didn't do make clean
[04:19:50] <jmkasunich> that shouldn't be needed, but might as well try it
[04:19:51] <SWPLinux> in theory, make should overwrite baically everythingwhen you rerun configure, but it may not
[04:20:14] <jmkasunich> the error you are having sounds vaguely familiar
[04:20:19] <elson> Well, I'm going to try a make clean, then the full configure, etc. be back in a few min.
[04:20:24] <jmkasunich> like somebody had it some months ago
[04:23:06] <SWPLinux> July 7, 2006 is the only mention I can find with google (which indexes these IRC discussions)
[04:23:18] <SWPLinux> there's a patch to a Submakefile on the same day
[04:23:55] <jmkasunich> that qualifies as "some months ago" ;-)
[04:24:04] <SWPLinux> heh - I guess so
[04:32:51] <elson> That DID it! Thanks, guys! Now I can pack this system up and send it to another EMC convert!
[04:33:14] <SWPLinux> yay!
[04:33:47] <SWPLinux> um - any reason to do a compiled version for a customer, rather than installed packages? ...
[04:34:05] <jmkasunich> yeah, that is very disturbing.....
[04:34:06] <SWPLinux> (just curious)
[04:35:13] <elson> John, you may not have seen it, I just got a pick and place machine.
[04:35:47] <jmkasunich> what does that have to do with shipping a cvs checkout to a customer, instead of a released version?
[04:36:04] <elson> John must be busy - well, thanks Steve, I think I'm going to do some testing and pack this up. I'm anxious to see all you guys at the EMC fets.
[04:36:17] <jmkasunich> which john, me?
[04:36:48] <SWPLinux> should be fun. I guess I should make some reservations and stuff (and pay the workshop fees)
[04:36:58] <elson> Oh, the 6.06 Ubuntu ISO doesn't have my latest driver changes. If I'm going to update, I might as well verify that the system is configured to be able to compile EMC2 from CVS.
[04:37:18] <jmkasunich> so you are shipping a checkout from CVS Head?
[04:38:08] <elson> Umm, yes. I suppose there is some danger there. But, if the customer can get it on the net, he should be able to update it again if there's a problem.
[04:38:24] <elson> I mean, that's what I run here!
[04:38:40] <jmkasunich> its certainly not a bad thing to be able to compile - but it will be easier to support your users if they can say "I'm running 2.1.4" because then everybody knows exactly what they have
[04:38:56] <elson> Yes, I suppose that's true.
[04:39:00] <SWPLinux> it makes sense to ship a machine that can compile head, but making the default emc be a run-in-place seems like a bad idea
[04:39:06] <SWPLinux> err - trunk
[04:39:20] <jmkasunich> your driver changes - they are in trunk but not in the 2.1 branch?
[04:39:37] <SWPLinux> they'll get update notices, but updates won't do anything for the RIP versions, so they'll update but not see any changes ...
[04:39:39] <elson> I just haven't done an update from the binary release.
[04:40:00] <elson> The 6.06 ISO is from fall 2006. My last change was mid January.
[04:40:22] <elson> Oh, I see.
[04:40:23] <SWPLinux> an update should get that change then
[04:40:25] <jmkasunich> when you say 6.06 iso, do you mean our iso, or a vanilla ubuntu one?
[04:40:43] <SWPLinux> it must be ours, 6.06 came out in June
[04:40:45] <elson> the linuxcnc.org iso file.
[04:41:03] <jmkasunich> a linuxcnc.org iso has 2.0.something on it if you got it back in the fall
[04:41:25] <SWPLinux> it's 2.1.something now though, isn't it?
[04:41:35] <jmkasunich> 2.1.5
[04:41:38] <SWPLinux> ok, the latest
[04:41:40] <jmkasunich> 2.1.0 came out in januare I think
[04:41:41] <SWPLinux> (?)
[04:41:57] <jmkasunich> maybe 2.1.4
[04:42:18] <SWPLinux> in any case, there are isues with updates and TRUNK / RIP
[04:42:31] <jmkasunich> yes, 2.1.4 right now
[04:43:07] <SWPLinux> since emc is installed, the update manager will tell the user when there are updates, but if the desktop icons are set to use a RIP version, then the updates will have no effect
[04:43:16] <elson> Well, I may have to re-think how I'm setting up these systems for users to manage/update.
[04:43:20] <jmkasunich> which can coufuse the hell out of users
[04:43:30] <SWPLinux> however, the menu version will probably be from the installed package, so that will also cause confusion
[04:43:48] <jmkasunich> you are shipping boxes with two differnet EMCs installed
[04:44:04] <jmkasunich> and unless you go to some pains, its probably easy for the user to run the wrong one
[04:44:12] <elson> I just downloaded the ISO file 2 days ago, and it was the same file as I got months ago. Same size, same filename, same checksum.
[04:44:15] <jmkasunich> I use "installed" loosely
[04:44:16] <SWPLinux> yeah - packaging is genereally not very compatible with self-compiled installations (in terms of management, of course the software still works)
[04:44:54] <jmkasunich> elson: if you run EMC from somewhere NOT in your CVS tree, what version number does it print as it starts?
[04:45:04] <elson> I will have to warn the user about this situation. I'd hope he'd keep in contact with me.
[04:46:00] <jmkasunich> jmkasunich@ke-main-1006:~$ emc
[04:46:00] <jmkasunich> EMC2 - 2.1.4
[04:46:14] <jmkasunich> that is my installed version
[04:46:43] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2.1$ scripts/emc
[04:46:43] <jmkasunich> EMC2 - pre-2.1.5
[04:46:52] <jmkasunich> my 2,1 checkout (run in place)
[04:47:11] <SWPLinux> steve@steve-laptop:/Project/emc2$ ./scripts/emc
[04:47:13] <SWPLinux> EMC2 - pre-2.2 CVS HEAD
[04:47:14] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2head$ scripts/emc
[04:47:14] <jmkasunich> EMC2 - pre-2.2 CVS HEAD
[04:47:15] <SWPLinux> interesting
[04:47:19] <elson> I get PRE 2.2 CVS HEAD
[04:47:22] <SWPLinux> ah
[04:47:23] <jmkasunich> and my head run-in-place checkout
[04:47:48] <jmkasunich> elson: you get PRE 2.2 even when you run it from outside the CVS checkout directory?
[04:48:03] <elson> I think so, yes. I don't know why.
[04:48:11] <SWPLinux> emc-environment
[04:48:17] <jmkasunich> oh, maybe
[04:48:25] <jmkasunich> open a fresh shell and try it
[04:48:37] <SWPLinux> not ctrl-shift-T
[04:48:42] <elson> But, then, I just typed "emc" - I have already changed the menu entry to point to my new one.
[04:49:08] <SWPLinux> that'll change back if an update is done, I think
[04:49:08] <jmkasunich> emc-environment puts your run-in-place copy in your path
[04:49:15] <jmkasunich> so "emc" finds it
[04:49:36] <jmkasunich> but when your user powers up, emc-environment won't be in effect
[04:49:38] <elson> OK, that gives EMC2 2.0.3
[04:49:47] <jmkasunich> yuck, ancient
[04:49:52] <SWPLinux> hmmm. that can't be the same ISO then
[04:50:00] <jmkasunich> if it was my customer there is no way I would ship like that
[04:50:36] <jmkasunich> if 2.1.4 doesn't meet your needs (no driver fixes for example) then I would remove the installed package completely
[04:50:45] <jmkasunich> shipping two versions is just asking for trouble
[04:50:51] <SWPLinux> elson: follow these instructions: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.1
[04:50:59] <SWPLinux> and update the installed version to 2.1.x
[04:51:05] <elson> Well, I installed from my old CD because I THOUGHT that the ISO on linuxcnc.org was still the same. I could have messed up, there.
[04:51:09] <jmkasunich> SWPLinux: first he needs to decide if 2.1.x will meet his needs
[04:51:15] <SWPLinux> the latest "stable" version should have all your changes
[04:51:39] <SWPLinux> jmkasunich: if TRUNK does, then 2.1 should as well, since the main reason for CVS was driver changes (AFAIK)
[04:51:47] <jmkasunich> elson: you don't need to get the latest ISO, just the latest package
[04:52:11] <SWPLinux> though you have a point that threading or some of the other changes in TRUNK may be desirable
[04:52:23] <jmkasunich> or they may be broken
[04:52:30] <SWPLinux> indeed
[04:52:28] <jmkasunich> trunk isn't production ready
[04:52:31] <elson> Umm, 2.1 doesn't have threading?
[04:52:37] <jmkasunich> yes it does
[04:53:03] <SWPLinux> it does - I think there have been some improvements and additions in TRUNK though (could be wrong about that, been traveling for a couple of weeks)
[04:53:03] <jmkasunich> might not have G76, you'd need to read changelogs
[04:53:08] <jmkasunich> but it certainly has G33
[04:53:13] <elson> I know there is potential risk using trunk. I'm just doing what I know how to, even if it is ill-advised.
[04:53:37] <jmkasunich> well, we're here to help you "know how to" do it better ;-)
[04:53:55] <SWPLinux> it'll be a problem when updates come along, since the menu item pointing to the CVS version will be overwritten, and the environment won't point to the RIP install, but to the installed package (every reboot)
[04:54:01] <elson> Yeah, it is all just a matter of time. I only work 16 hours a day.
[04:54:03] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_ppmc.c?graph=1
[04:54:22] <jmkasunich> there ARE changes to your driver in TRUNK that aren't in 2.1
[04:54:41] <SWPLinux> heh - "people who own their own business only have to work half time. the other 12 hours a day they get to themselves" ;)
[04:55:01] <jmkasunich> they probably should have been backported to 2.1
[04:56:01] <jmkasunich> you finished your changes in mid january - there have been many (lost) opportunities to backport them to 2.1
[04:56:25] <elson> OK, I have no idea how to do that!
[04:56:41] <jmkasunich> again, we'de be happy to help you
[04:56:49] <elson> OK, help!
[04:56:56] <jmkasunich> but you tend to fall out of touch sometimes
[04:57:04] <jmkasunich> I guess I don't realize just how heavily we use IRC
[04:57:29] <elson> I'm up to my eyeballs in stuff that really needs to be done, I'm just treading water.
[04:57:37] <jmkasunich> (before every release we ask each other "any thing else that should be in this release?"
[04:58:24] <jmkasunich> does the version of your driver in TRUNK work "perfectly" ?
[04:58:30] <jmkasunich> I mean, no known bugs
[04:59:55] <jmkasunich> oh, duh
[05:00:02] <jmkasunich> it is backported - alex did it
[05:00:07] <elson> Well, a couple unofficial beta testers have run my Jan. driver through the wringer better than I ever could. I have it running on my Bridgeport. here, and got homing with index working right. I also have it threading on the minimill. Stuart Stevenson in Wichita really has been testing heavily with it.
[05:00:18] <jmkasunich> ok
[05:00:35] <jmkasunich> I with the revision graph didn't cut off commit messages.....
[05:00:39] <SWPLinux> heh - it's been in all 2.1.x releases ;)
[05:00:46] <jmkasunich> all your changes WERE backported to 2.1
[05:01:02] <jmkasunich> elson: have you seen this: http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_ppmc.c?graph=1
[05:01:11] <jmkasunich> that is the history of your driver
[05:01:49] <jmkasunich> on the top right is the current 2.1 release version - on 1/20, alex backported your changes from TRUNK (top left) to 2.1
[05:02:17] <jmkasunich> the green tags show that it hasn't changed during the entire 2.1.x release cycle
[05:02:42] <jmkasunich> if you scroll down to file version 1.22, you'll see the 2.0 release cycle
[05:03:14] <jmkasunich> your driver was the same from 2.0.0 thru 2.0.4, then changed for 2.0.5
[05:03:38] <jmkasunich> are you following this?
[05:03:39] <elson> OK, thanks, glad to know it is taken care of. Took a while to get that graph up - I'll have to spend some time learning how to read it.
[05:03:58] <jmkasunich> there is one for every file in EMC
[05:04:02] <jmkasunich> here is another important one:
[05:04:03] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/VERSION?graph=1
[05:04:16] <jmkasunich> VERSION is the file with the version tag in it
[05:04:25] <jmkasunich> so that graph shows the complete release history
[05:04:30] <jmkasunich> when every version was released
[05:05:50] <jmkasunich> now, this is the one that should scare you: http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?graph=1
[05:06:03] <jmkasunich> control.c is a core motion controller file
[05:06:13] <jmkasunich> we branched 2.1 off at control.c version 1.80
[05:06:22] <jmkasunich> its now at 1.107
[05:06:33] <jmkasunich> you are shipping all that unreleased code to your customer
[05:06:42] <elson> 134 revs
[05:07:05] <SWPLinux> well, it's about time for bed. I strongly recommend updating EMC2 to 2.1.x as outlined in the wiki, and getting rid of the RIP / CVS version - it'll only cuase confusion
[05:07:20] <jmkasunich> I second that - 2.1.4 has all of your driver updates in it
[05:07:36] <SWPLinux> it is a good thing that you've prepared the system for complation though, that may come in handy in the future
[05:08:02] <SWPLinux> (if for no other reason that the machine actually has compilers installed now, so the customer won't have to get them if they're ever needed)
[05:08:03] <elson> I think I'll leave the trunk build there, but put in the 2.1.x update as you say, since it DOES have all the stuff I want to be there.
[05:08:18] <jmkasunich> yeah - and set it up to run the 2.1.x version
[05:08:31] <SWPLinux> that should work, since the install should overwrite the menu item to use the 2.1.x version
[05:08:39] <elson> And, I'll set up the menu links to the 2.1.x if it doesn't do that automatically.
[05:08:48] <SWPLinux> check that though - it's prettyimportant that the menu run the package-managed version
[05:09:03] <elson> I need to get to bed, too. Been up a lot playing with the pick and place.
[05:09:09] <jmkasunich> ok, goodnight
[05:09:13] <SWPLinux> lucky bastid
[05:09:18] <SWPLinux> night guys
[05:09:46] <SWPLinux> oh hey- before I go to bed, I had an interesting discussion about parallel port chips today
[05:09:56] <SWPLinux> with a guy from SMSC
[05:10:08] <elson> Well, this was a real step into the void! I got this thing for a song ($2500) but had to have doors cut, shipping, palletizing, it seems like it will never end!
[05:10:52] <elson> parallel port chips? The bane of my existence, but they are getting better. I'm having a lot less incompatibility problems than 3 years ago.
[05:11:14] <SWPLinux> apparently, they're mostly based on either the SMSC or the Winbond implementation
[05:11:26] <elson> Yes.
[05:11:48] <elson> I'm not sure what Dell uses, though.
[05:12:03] <SWPLinux> depends on whether it's a desktop or a laptop, apparently
[05:12:35] <elson> Yes, could be. I'm mostly working with Dell Optiplex (commercial) desktop boxes.
[05:12:36] <SWPLinux> also, apparently some manufacturers have some custom things in the chipsets, so nobody outside the manufacturer will ever see the full specs, due to IP issues
[05:13:15] <elson> Maybe. If Dell is using off-the-shelf chips, I can't imagine too many others are going custom.
[05:13:18] <SWPLinux> this guy actually had an old BDI install for his Wells-Index mill and LeBlond lathe ...
[05:13:36] <elson> Cool, another hidden EMC user out there.
[05:13:42] <SWPLinux> I wanted to get more info from him, but he was concerened about losing his job on the spot
[05:13:47] <SWPLinux> (IP crap)
[05:14:21] <elson> Geez, I mean there's real IP out there, but a parallel port chip?
[05:14:25] <SWPLinux> yeah, also, in the morning session on realtime linux, I mentioned linuxcnc.org, and the guy I was talking to had heard of it
[05:14:30] <SWPLinux> heh
[05:14:41] <jmkasunich> cool
[05:15:03] <elson> Anyway, I want to do this update so I can get to bed tonight!
[05:15:18] <SWPLinux> interestingly, the founder of SMSC had the patent on CMOS (!), and traded patent rights with various companies for their UART, parport, floppy controller, etc
[05:15:22] <elson> Thanks, guys! I'll try to be in touch more!
[05:15:33] <SWPLinux> eventually, they had all the IP for a "super-IO chip", and were the only ones ...
[05:15:35] <jmkasunich> goodnight
[05:15:47] <SWPLinux> night, Jon
[05:15:56] <elson> Huh? The patent on CMOS had to expire at least 10 years ago?!?
[05:16:10] <SWPLinux> yeah, this was around 30 years ago :)
[05:16:24] <SWPLinux> SMSC has been around a while, I guess
[05:16:32] <elson> OH. Didn't know these multi-IO chips went that far back.
[05:16:49] <SWPLinux> those don't, but they were wround in the late '80s at least
[05:16:50] <SWPLinux> around
[05:16:57] <elson> Yes, I have (or had) some very old catalogs from them.
[05:17:21] <elson> Well, good night again!
[05:17:26] <SWPLinux> anyway - cool stuff here. I've also been talking to every embedded PC manufacturer (and there are a lot of them) about RT latency
[05:17:46] <SWPLinux> good night again :)
[05:18:55] <elson> Oh,here we go again! Is there going to ever be a chip as good as Pentium II? I saw a doc somewhere that indicated the reason the RT latency was so good on the P-II was that it was used in the flight control system of the F-16, and Intel worked real hard to make some mil supplier happy on that one.
[05:19:30] <SWPLinux> heh - can't go to sleep when there are interesting historical discussions, huh? ;)
[05:20:02] <SWPLinux> I suspect that the RT latency issues on later chips are due to extensive pipelining and other throughput optimizations
[05:20:05] <elson> The P-3 doesn't seem as good, and the "other" makers seems even worse.
[05:20:26] <SWPLinux> I know the AMD ELan SC520 (a 486-alike at 133 MHz internal) sucked big time
[05:20:35] <elson> Historical? You mean like IBM 360, Bendix G-15 and PDP-5?
[05:20:48] <SWPLinux> but then again, it's no worse than a celeron 500
[05:20:50] <elson> I got to get off here, soory!
[05:20:51] <SWPLinux> heh
[05:20:54] <SWPLinux> see ya
[05:21:09] <jmkasunich> heh
[05:38:22] <alex_joni> morning
[05:38:28] <jmkasunich> hi
[05:38:36] <alex_joni> up late?
[05:38:40] <jmkasunich> if you are awake, then I should be asleep
[05:38:45] <jmkasunich> 1:38am
[05:38:46] <SWPLinux> me, too
[05:38:50] <alex_joni> heh.. it's early here..
[05:38:53] <jmkasunich> late, but not super late
[05:38:53] <alex_joni> 08:37
[05:38:54] <SWPLinux> too bad I'm in CA
[05:40:22] <alex_joni> * alex_joni reads back
[05:43:11] <jmkasunich> well, I should go to bed
[05:43:29] <jmkasunich> I think my brain is too tired to understand VHDL right now
[05:55:20] <alex_joni> heh
[05:55:27] <alex_joni> finished reading.. I totally agree
[05:55:38] <alex_joni> pre-2.2 shouldn't be used by users
[09:07:54] <a-l-p-h-a> lerneaen_hydra!
[09:08:12] <lerneaen_hydra> a-l-p-h-a!
[09:53:00] <a-l-p-h-a> sleep time again
[12:40:22] <a-l-p-h-a> http://www.gleeker.com/file/336-the-sexiest-obstacle-course.html oh damn.
[12:42:24] <alex_joni> that's not really -devel related .. is it?
[12:43:24] <skunkworks> a axis.
[12:43:49] <skunkworks> or c?
[12:46:00] <a-l-p-h-a> damn it... wrong chan again.
[17:34:50] <DavidMTL> Is there a way to control the maximum velocity allowed during a direction change (velocity changes sign)?
[20:00:23] <dmwaters> {global notice} Hi all! Freenode is currently looking for more leaf and hub servers for both the US and Europe, as well as AU and other countries. If you would be interested in possibley hosting a server, please see 'http://freenode.net/hosting_ircd.shtml' for more information.