Back
[01:20:23] <jepler> maybe everything works now using /docview/ -- seems slow, though, and there's the problem with the style being narrow.. on the other hand, I don't intend to take away the "other" location of the docs..
[02:05:31] <fenn> alex_joni: better late then never i guess: href=[A-Z,a-z,0-9]
[02:05:51] <SWPadnos> *
[02:06:06] <SWPadnos> and no commas I think
[02:17:52] <jepler> the question is, how little of the structure of an HTML document can you afford to parse to perform this task (writing URLs so that displaying them inside joomla doesn't break them) ..
[02:29:27] <fenn> i dont see any advantage to putting this stuff inside joomla
[02:29:38] <fenn> just give it a CSS that matches
[02:31:15] <jepler> with this "solution", I don't have to change a second copy of the joomla style when the main site changes
[02:33:27] <SWPadnos> I think this should only be used for release documentation. I think joomla keeps prior revisions in the database, and there's no sense making that grow unnecessarily
[02:34:05] <SWPadnos> unless of course it isn't putting this stuff in the database
[02:34:06] <jepler> this doesn't keep the documentation inside joomla
[02:34:37] <SWPadnos> ok, so it just filters what's elsewhere on the site?
[02:34:47] <jepler> right
[02:34:58] <SWPadnos> ok. that's good
[02:35:06] <SWPadnos> hmmm. I should switch that DreamHost plan
[02:35:28] <SWPadnos> they just came out with a "one size fits all" plan, that's $9.99/month
[02:46:03] <jepler> SWPadnos: is that plan much different (less expensive?) than the one you're on now?
[02:46:21] <SWPadnos> yes
[02:46:46] <SWPadnos> it starts at $10.95 with no pre-payment. the one I'm on is $19.95 except taht I pr-pay for 2-year blocks, so I get it for $15.95
[02:47:32] <SWPadnos> they will apply credit to a plan switch, so I can swap plans, prepay for 2 years, and have it only cost a few bucks (I'm about 6 months into a 2-year contract now)
[02:48:05] <SWPadnos> I haven't done it because I want to be sure there are no glitches with LinuxCNC.org, and I haven't had the time to ask them any questions about it
[12:20:39] <Guest787> Guest787 is now known as skunkworks_
[12:21:54] <skunkworks_> skunkworks_ is now known as skunkworks
[13:06:08] <alex_joni> morning jeff
[13:15:26] <alex_joni> bbl
[13:15:38] <alex_joni> jepler: nice fixing the docview stuff..
[13:25:24] <skunkworks> what is PUM?
[13:41:59] <jepler> Authority-provided utility costs computed per apartment unit per month.
[13:42:00] <jepler> www.hud.gov/offices/pih/programs/ph/phecc/definitions.cfm
[13:43:51] <cradek_> skunkworks: "thump" I think
[13:44:05] <skunkworks> heh - in reference to the list email from jros
[13:44:09] <cradek_> cradek_ is now known as cradek
[13:44:34] <skunkworks> italian for thump?
[13:45:04] <cradek> not entirely sure, but yes I think he's talking about a sound
[13:45:32] <skunkworks> ok - that makes sense.
[13:45:36] <skunkworks> morning
[13:45:37] <jepler> in italian, PUM is dead-man switch (Pedale dell'uomo morto)
[13:46:15] <cradek> oh... hmm
[13:46:20] <skunkworks> so maybe it means estop?
[13:48:00] <jepler> oh -- but he's .es, not .it
[13:53:11] <jepler> so it would be H, not U -- so I dunno what he means
[13:54:07] <cradek> I still think he means 'thump'
[13:54:50] <jepler> But wen using our kins (the only change is the kinematics loaded), and
[13:54:50] <jepler> pressing home, a sudden movement (it sounds like and impact: PUM!) of
[13:54:50] <jepler> the axis happens and the machine stops.
[13:54:56] <jepler> here's what he said the last time, so he must mean it makes a noise
[13:55:42] <jepler> if something is sending a "step" in joint space, some ddts and limit blocks would allow you to capture it in halscope
[14:09:49] <jepler> 227 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[14:09:49] <jepler> Need to get 186MB of archives.
[14:09:49] <jepler> After unpacking 17.7MB disk space will be freed.
[14:09:57] <jepler> huh, usually disk space doesn't get freed up after upgrading
[14:10:16] <cradek> odd
[14:10:35] <cradek> I hope not to start a fight about arcs, but I couldn't just let it go
[14:11:22] <skunkworks> instigator!
[14:11:35] <jepler> cradek: is the linuxcnc.org live cd image with md5sum 6607223ce924e1c49a9e833f560048be the latest one, or were you working on "the next one"?
[14:11:55] <cradek> umm
[14:12:32] <jepler> I forget what it was, but you were going to add development packages or something
[14:12:45] <cradek> I have an iso at home dated 2007-09-01 with sum 905a6ec0c2e90b2f8b92f7b876e725c3 that I used for myself but probably never uploaded
[14:12:58] <cradek> yes I think it has updates and devel packages, cvs, etc
[14:13:44] <cradek> again I say: there's no need for you to figure out dapper livecd stuff, you should use that time to do the next one
[14:13:59] <cradek> I can easily make the "last" dapper cd when 2.2 is released
[14:14:52] <jepler> probably so, but I have to learn on some version, and gutsy is problematic with my current kernel because 'squashfs' was something that didn't compile cleanly (dunno why)
[14:15:40] <jepler> I started with a vanilla kernel .. for some reason they structured it so that the squashfs source was in ubuntu-modules but headers were in the kernel-source or something strange like that
[14:15:46] <jepler> I need to revisit that
[14:16:00] <jepler> anyway nobody's tested the gutsy kernel so there's no point in building a Live CD around it
[14:16:45] <skunkworks> * skunkworks blushes
[14:16:54] <cradek> haha
[14:17:02] <skunkworks> the computer I was testing on lost its video card
[14:18:16] <jepler> if excuses were cabooses, then hobos could ride
[14:20:06] <cradek> * cradek tries to come up with an excuse for not working on stepconf
[14:20:33] <skunkworks> If excuses were the highways, Only procrastinators would be its travellers!
[14:21:01] <cradek> http://bp0.blogger.com/_FBXGhy-QmVw/Rwv4GPyzdLI/AAAAAAAABNQ/atNNWFGj3fQ/s1600-h/card1087.JPG
[14:22:30] <skunkworks> If excuses were nails, many of our houses would fall down~Plato
[14:22:44] <skunkworks> plato era houses used nails?
[14:23:01] <cradek> I was just pondering that
[14:23:59] <skunkworks> it was probably americanized ;)
[14:30:31] <skunkworks> I suppose 'If excuses were pegs, many of our houses would fall down' wouldn't make sense to most people. Or 'If excuses were tendons, many of our houses would fall down'
[14:31:06] <skunkworks> (if that is closer to plato era bulding practices)
[14:32:33] <skunkworks> did they even have wood back then? ;)
[16:08:05] <skunkworks> Fenn: good morning :)
[16:09:21] <fenn> hi. seems my router-toaster died sorta
[16:09:36] <skunkworks> yeck
[16:09:51] <fenn> it works for about 5 seconds after i power cycle it
[16:10:03] <skunkworks> what brand?
[16:10:09] <fenn> netgear
[16:10:46] <skunkworks> I use linksys more - and have had 2 fail so far. I don't think I have personally have a netgear fail.
[16:11:02] <fenn> the ups it was on recently failed too.. i wonder if there's a correlation
[16:11:27] <skunkworks> any good lightning storms lately?
[16:13:02] <skunkworks> * skunkworks wonders if he should risk installing gutsy gibbon on this computer - dual boot
[16:16:19] <skunkworks> wow - the craptastick software (nero) that came with this dvd burner does iso's and it seems to work.
[16:18:31] <fenn> what more could you want
[16:19:24] <skunkworks> it took a bit to find it.
[16:19:37] <skunkworks> at first glance I thought it didn't
[16:28:14] <SWPadnos> skunkworks, gutsy seems to work nicely on my laptop
[16:28:25] <SWPadnos> or gutsy beta anyway
[16:29:01] <skunkworks> I would have to re-size the partition.. I am a bit leary about that..
[16:29:11] <jepler> SWPadnos: x86? did you try my rtai kernel?
[16:29:12] <SWPadnos> oh - I would be too
[16:29:26] <SWPadnos> jepler, no, I haven't, and it's x86-64
[16:30:10] <SWPadnos> I won't have time to do this for a couple of weeks, but I will probably attempt to install it on my kiosk PC (Which should be a hoot)
[16:30:26] <SWPadnos> I wonder how well a Celeron 500 will do with a modern OS ;)
[16:32:10] <skunkworks> I installed gutsy on a 1.4ghz rambus and it was 'ok'
[16:32:29] <skunkworks> I think it only had 256mb ram
[16:32:42] <SWPadnos> this one has 512, so that shouldn't be the (only) problem
[16:33:08] <SWPadnos> I also have an athlon-2400 or so that I can try, but I can't remember if it works at all
[16:33:16] <jepler> emc2 was terribly slow (unresponsive, high realtime latency) on my 1GHz AMD Duron
[16:33:36] <jepler> OTOH it runs great on my "AMD Athlon(tm) XP 2600+"
[16:33:41] <SWPadnos> I've had good luck with that celeron before
[16:34:00] <cradek> your duron seemed worse than my P2
[16:34:07] <SWPadnos> I'm pretty sure one install (some BDI) had latencies no larger than 6000-ish
[16:34:16] <cradek> (well smp P2)
[16:35:32] <jepler> cradek: mksquashfs takes dozens of minutes to run?
[16:35:38] <cradek> yes
[16:35:44] <jepler> ok
[16:35:49] <cradek> well 5 or so?
[16:35:49] <alex_joni> hi guys
[16:35:50] <cradek> long time
[16:35:59] <jepler> already at 6 minutes and "240MB" on the progress report
[16:36:08] <alex_joni> sounds like ages to me
[16:36:11] <cradek> did you remember apt-get clean?
[16:36:12] <jepler> it's CPU bound, not disk
[16:36:14] <jepler> yes I did
[16:36:18] <cradek> yeah it's all cpu
[16:36:25] <jepler> or rather, I didn't the first time
[16:36:25] <cradek> (my machine is pretty fast)
[16:36:35] <jepler> this is the "2600+" I just mentioned..
[16:36:50] <alex_joni> * alex_joni used to do that on his 1600+
[16:37:01] <alex_joni> can't remember how long it took though
[16:38:08] <jepler> 2.3Gedit
[16:38:37] <jepler> seems unlikely this is going to compress down enough .. I installed extra stuff
[16:39:36] <jepler> the internet tells me the limit for an 80-minute cd is 737280000 bytes in data mode
[16:47:06] <jepler> yep, 800475136 bytes
[16:47:25] <cradek> welcome to this world
[16:47:46] <SWPadnos> is this for a gutsy-based liveCD?
[16:48:18] <jepler> no, it's dapper
[16:48:18] <cradek> no he's practicing breaking the dapper cd first
[16:48:25] <SWPadnos> oh, excellent! :)
[16:48:32] <jepler> I tried to add the devel stuff including tetex..
[16:48:55] <SWPadnos> no doubt the games can't be removed without removing gnome or ubuntu-desktop
[16:49:13] <SWPadnos> not that they'd free up too much space
[16:49:16] <cradek> real 11m11.646s
[16:49:18] <cradek> Filesystem size 670327.88 Kbytes (654.62 Mbytes)
[16:49:48] <SWPadnos> is that kilobytes or kibibytes?
[16:50:03] <SWPadnos> or whatever the heck they're called
[16:50:52] <cradek> 686415872
[16:50:59] <jepler> must be kibibytes and mibibytes then
[16:51:36] <cradek> remember plenty of other stuff gets added too before you get to the size that counts
[16:52:00] <jepler> yes, I was counting the 'mkisofs' image size
[16:52:32] <jepler> 390857 extents written (763 MB)
[16:52:51] <jepler> mksquashfs said
[16:52:52] <jepler> Filesystem size 746667.60 Kbytes (729.17 Mbytes)
[16:52:52] <jepler> 34.99% of uncompressed filesystem size (2133695.04 Kbytes)
[17:03:46] <cradek> jepler:
http://pastebin.ca/732071
[17:04:02] <fenn> kibbles and mibbles and gibbles of bits
[17:04:22] <cradek> hm, I guess not os.path.exists(destfile)
[17:04:46] <cradek> forgot a dir in cvs maybe?
[17:06:20] <jepler> cradek: looking
[17:06:42] <jepler> cradek: do you have 'convert' installed?
[17:07:03] <cradek> no
[17:07:20] <jepler> you'll need it
[17:07:26] <jepler> package imagemagic I think
[17:07:36] <cradek> ok
[17:07:39] <fenn> ImageMagick with icky capitals
[17:07:39] <cradek> thanks
[17:08:00] <fenn> oh nm that's only on redhat
[17:08:01] <cradek> it's lowercase, but the inexplicable k is there
[18:35:10] <skunkworks> what packages from the /gutsy to test the real time kernel?
[18:36:22] <jepler> kernel-image....deb rtai-modules....deb emc2_2....deb
[18:36:35] <jepler> the others are needed if you want to rebuild the packages, or build emc
[18:36:52] <skunkworks> if I would want to build a rip?
[18:36:54] <skunkworks> also
[18:37:21] <alex_joni> skunkworks: you need the kernel headers for rip
[18:37:30] <jepler> then you also need kernel-headers, cvs, and all the packages listed in debian/control.in under Build-Depends
[18:37:40] <skunkworks> heh
[18:37:48] <jepler> (you can't use 'build-dep' since that directory is not in the right format for an apt repository)
[18:38:17] <jepler> yay I have a .iso that is small enough (I removed ekiga, ooffice, evolution, ..)
[18:38:37] <alex_joni> ooffice should be quite big
[18:38:52] <jepler> 330661 extents written (645 MB)
[18:38:57] <SWPadnos> ooffice - that should free up enough space so you can stick the EMC2/kernel/rtai source on it also
[18:39:24] <cradek> * cradek hesitates to say that users are more likely to want ooffice than tex
[18:40:08] <SWPadnos> users schmoosers
[18:40:09] <jepler> yeah probably
[18:40:46] <jepler> but I needed some "goal" in mind as I built this CD
[18:40:57] <cradek> what was it?
[18:41:14] <jepler> "put all required development stuff on the disc"
[18:41:53] <skunkworksgut> downlaoding rtai 6.0mb deb, linux-image 185m
[18:42:11] <skunkworksgut> which emc2_2. .... deb?
[18:42:39] <jepler> http://linuxcnc.org/experimental/gutsy/emc2_2.2.0pre_i386.deb
[18:42:56] <skunkworksgut> Thank you.. :)
[18:43:48] <alex_joni> is 2.2.0pre a good naming idea?
[18:44:04] <jepler> no, it should have been 2.2.0~pre
[18:49:15] <skunkworks> so - this is 2.2? or is it the 1.whatever flavor?
[18:49:53] <jepler> it's from CVS TRUNK
[18:50:16] <skunkworks> cool
[18:50:42] <skunkworks> so - I should be able to use your cool latency tester?
[18:52:31] <jepler> yes
[18:52:57] <skunkworks> life is good.
[18:54:42] <alex_joni> heh
[18:58:05] <skunkworksgut> huh - the multiverse and stuff is already active by default
[18:59:46] <skunkworksgut> so I installed the rtai deba nd the linux image deb. When I open up- the emc2_2.2.0pre... in the package installer - it says Error: dependency is not satifiable: emc2
[19:00:17] <skunkworksgut> although it spelled satisfiable correctly
[19:00:43] <jepler> probably there's some requirement package (like bwidget) that isn't installed?
[19:01:23] <jepler> you may get a more useful error message if you install it at the terminal
[19:01:24] <skunkworksgut> how would I tell? the package installer doesn't seem to give much info
[19:03:43] <skunkworksgut> sudo dpkg -i
[19:05:44] <skunkworksgut> http://pastebin.ca/732195
[19:08:10] <jepler> for each thing it says is not installed, install it with apt-get install
[19:08:17] <jepler> one or more of them will have an error
[19:09:07] <skunkworksgut> ok
[19:09:16] <skunkworksgut> (that is what I have started doing
[19:09:19] <skunkworksgut> )
[19:09:20] <jepler> alternately, you may wish to try 'dpkg -i --force-depends emc2*.deb; apt-get --fix-broken upgrade'
[19:09:24] <jepler> but there's a big warning on --force-depends
[19:09:34] <jepler> WARNING - use of options marked [!] can seriously damage your installation.
[19:10:09] <skunkworksgut> I think I just did that with synaptic.. It had an option to fix the broken
[19:10:11] <skunkworksgut> one
[19:14:05] <jepler> gabe up, huh?
[19:15:37] <jepler> (if that was a proper apt repository you'd be getting much more help from apt / synaptic and better error messages ..)
[19:18:09] <skunkworksgut> How do I run the latency test?
[19:19:56] <jepler> should be 'latency-test' at the commandline
[19:20:18] <cradek> how novel
[19:20:23] <jepler> (but now that you mention it, the .deb may not include it; new programs and scripts have to be added to the .deb packages by hand, and I might have overlooked it)
[19:20:39] <skunkworksgut> ok - that doesn't work
[19:20:54] <skunkworksgut> emc runs - all be it very choppy
[19:21:08] <skunkworksgut> might be a video problem as it is onboard
[19:21:10] <alex_joni> choppy?
[19:21:29] <alex_joni> jepler: want me to look at the script install stuff?
[19:21:31] <jepler> 'command not found', or some other error?
[19:21:34] <jepler> skunkworksgut: ^^^
[19:21:41] <skunkworksgut> command not found
[19:22:20] <jepler> save this as 'latency-test':
http://cvs.linuxcnc.org/cvs/emc2/scripts/latency-test?rev=1.4;content-type=text%2Fplain
[19:22:25] <skunkworksgut> like menus are simi transparent
[19:22:32] <jepler> then run it with: sh /path/to/latency-test
[19:22:33] <skunkworksgut> flickering
[19:23:28] <alex_joni> hmm.. according to what I read.. it should be in /usr/bin
[19:24:47] <alex_joni> I can see it in the deb too
[19:24:50] <skunkworksgut> sam@sam-desktop:~$ sh latency-test
[19:24:50] <skunkworksgut> trap: 3: SIGINT: bad trap
[19:25:13] <alex_joni> skunkworksgut: he said /path/to/latency-test
[19:25:21] <alex_joni> try sh ./latency-test
[19:25:23] <jepler> run it with bash instead?
[19:25:32] <jepler> bash latency-test
[19:25:39] <jepler> if it's in the current directory, the path is not needed
[19:25:59] <alex_joni> should be in /usr/bin though
[19:26:00] <skunkworksgut> bash worked
[19:26:14] <alex_joni> skunkworksgut: can you ls /usr/bin/latency* ?
[19:27:22] <skunkworksgut> sam@sam-desktop:~$ ls /usr/bin/latency*
[19:27:22] <skunkworksgut> ls: /usr/bin/latency*: No such file or directory
[19:27:22] <skunkworksgut> sam@sam-desktop:~$
[19:27:46] <skunkworksgut> or don't I understand what you want me to do ;)
[19:27:58] <alex_joni> dpkg -L emc2 | grep latency
[19:28:26] <skunkworksgut> I am getting max of 27650
[19:28:46] <skunkworksgut> max jitter of 3153
[19:30:57] <jepler> not bad
[19:31:26] <skunkworksgut> this is a petuum D 3ghz
[19:31:34] <alex_joni> petunium
[19:31:48] <skunkworksgut> it's the keyboard.. I swear
[19:31:59] <alex_joni> http://en.wikipedia.org/wiki/Petunia
[19:32:02] <alex_joni> nicer anyways :P
[19:32:37] <skunkworksgut> alex_joni: when I did the dpkg -L... it didn't seem to do anything
[19:33:33] <alex_joni> that means the file is missing from the package
[19:33:38] <alex_joni> might be from an older TRUNK
[19:33:57] <jepler> it wasn't installed or packaged when I built those .debs
[19:34:25] <jepler> http://cvs.linuxcnc.org/cvs/emc2/src/Makefile#rev1.243 http://cvs.linuxcnc.org/cvs/emc2/debian/emc2.files.in#rev1.21
[19:34:30] <jepler> looks like I subsequently fixed that problem
[19:34:44] <alex_joni> yup, a recent deb I built a couple days ago, has it
[19:34:45] <skunkworksgut> I am thinking it is the video card.. like the axis preview likes to jump forward and stay on top of the browser
[19:34:59] <jepler> that's .. interesting
[19:35:03] <alex_joni> yucky :)
[19:35:25] <skunkworksgut> but it seems to be running..
[19:35:27] <skunkworksgut> :)
[19:35:48] <jepler> what kind of video is it? I particularly wonder about what this prints: glxinfo | grep 'OpenGL.*string'
[19:36:56] <skunkworksgut> sam@sam-desktop:~$ glxinfo | grep 'OpenGL.*string'
[19:36:58] <skunkworksgut> OpenGL vendor string: Tungsten Graphics, Inc
[19:36:58] <skunkworksgut> OpenGL renderer string: Mesa DRI Intel(R) 915G 20061017 x86/MMX/SSE2
[19:36:58] <skunkworksgut> OpenGL version string: 1.3 Mesa 7.0.1
[19:36:58] <skunkworksgut> sam@sam-desktop:~$
[19:37:53] <skunkworksgut> heh = I just backspaced in here and caused the speaker to beep.
[19:38:10] <jepler> do that again with the latency test running .. tell me if it makes the numbers go bad
[19:38:14] <skunkworksgut> now max jitter is 16474659
[19:38:38] <alex_joni> ouchy
[19:39:17] <jepler> it does that on my machine too, with that kernel
[19:39:33] <skunkworksgut> jepler: yes - it raises the max jitter to 20k from 4k
[19:39:49] <skunkworksgut> yah - the beep causes overuns
[19:41:03] <skunkworks> jepler: is that fixable?
[19:41:13] <skunkworks> (beeping)
[19:41:27] <jepler> you can remove the 'pcspkr' module, or force it not to load
[19:41:35] <skunkworks> ok
[19:41:40] <jepler> sudo rmmod pcspkr # at each reboot
[19:42:06] <jepler> or put "install pcspkr /bin/true" in /etc/modprobe.d/nobeep and restart
[19:44:31] <alex_joni> any idea what 'VFS: busy inodes on changed media.' means?
[19:45:29] <cradek> you forgot to umount your cd or floppy
[19:45:43] <alex_joni> it comes from inside a vm
[19:46:04] <cradek> you forgot to umount your virtual cd or floppy
[19:46:38] <alex_joni> coo, thanks
[19:46:54] <alex_joni> it's the pesky automounter
[19:47:10] <alex_joni> if I stick a CD in the guest machine, it mounts it inside the VM too
[19:47:56] <jepler> you can somewhere tell vmware to start with the cdrom device disconnected
[19:50:25] <alex_joni> hello mgouget
[19:50:51] <mgouget> Hello alex!
[19:51:31] <alex_joni> I saw your patch, even read it a bit
[19:51:35] <mgouget> I spent a lot of time in this seemingly simple project!
[19:51:48] <alex_joni> I can see that.. but I guess that's how it goes
[19:51:57] <alex_joni> * alex_joni wanted to build a plasma cutter
[19:52:09] <alex_joni> so I installed emc
[19:52:17] <mgouget> As usual, 5% inspiration, 95% transpiration :)
[19:52:29] <alex_joni> here I am 3 years later.. without any plasma cutter.. but with lots of time spent ;)
[19:53:02] <alex_joni> anyways, your patch
[19:53:45] <alex_joni> I think the name for the NML channel coule be better chosen
[19:54:13] <mgouget> I am a mechanical engineer, but I runned a software company for 15 years; when I sold it , I wanted to play for the first time with what I learned, so I bought a CNC sherline...
[19:54:46] <mgouget> I have no problem with names, It can be whatever!
[19:56:17] <mgouget> I found no other way to achieve what I wanted without disturbing the existing GUI
[19:56:28] <jepler> I noticed
http://www.linuxcnc.org/docview/devel/html/code_Code_Notes.html#r5_2_1 mentions that a buffer can have a queue (though that's not the syntax that is actually in use in emc2)
[19:56:46] <jepler> is there a way to make the command buffers operate as a queue?
[19:57:05] <mgouget> jepler: yes, although it is not tested...
[19:57:06] <alex_joni> jepler: we tried that
[19:57:14] <jepler> I'm not thrilled about a solution that does not address halui + traditional GUI, which I think is a very common setup
[19:57:21] <jepler> at the same time, I don't understand the issues involved..
[19:57:29] <cradek> I would like to point out that there's nothing wrong with fixing all the other guis if they can be made to interoperate more reliably by doing so
[19:57:51] <alex_joni> jepler: the issue is that 2 channels are used for task<->gui comms
[19:57:55] <mgouget> jepler: it is a problem of synchronisation; there is no handshake, only polling
[19:58:02] <alex_joni> the command channel, and the status channel for ack's
[19:58:32] <mgouget> Using status channel for acks IS an idiotic decision
[19:58:55] <mgouget> You need queues
[19:59:42] <mgouget> The status channel is perfect for getting the status: on/off, estop, position...
[20:00:12] <mgouget> but acks must be delivered to the sender reliably
[20:04:43] <jepler> are we trying to decide on an ultimate solution that will be invasive in all UI programs and which will have to wait for emc2.3, or a short-term solution that can improve things but is non-invasive enough to go into 2.2?
[20:05:29] <alex_joni> well .. both, I think
[20:06:00] <mgouget> I think that my patch fulfill both
[20:06:37] <alex_joni> mgouget: the main point of NML is that the GUI can run on a different PC
[20:07:17] <mgouget> But interactive GUIs don need to change, and are not concerned by this patch.
[20:08:19] <mgouget> alex_joni: correct, but who uses it? if needed, we can run the UI in a frame buffer, such as vnc...
[20:08:44] <alex_joni> mgouget: I'm thinking more about custom UIs like ones running on win
[20:09:47] <mgouget> alex_joni: or use solutions à la emcrsh...
[20:11:09] <mgouget> alex_joni: the problem is: for commanding EMC, we need to know reliably when a command is done, and this can be done with buffers, only queues.
[20:12:09] <mgouget> alex_joni: in addition, we need a mechanism to ensure exclusive access during a certain number of operations.
[20:12:16] <alex_joni> why don't you feed the entire file as a ngc file?
[20:12:31] <alex_joni> I don't say what you did isn't good..
[20:13:08] <mgouget> alex_joni: so queues and semaphores must be used. BUT they can be local (as I did), or TCP based
[20:13:40] <alex_joni> I think I wouldn't have anything against a synchronisation channel
[20:13:55] <alex_joni> with requestSemaphore(my_uid)
[20:14:07] <alex_joni> hmm.. that gives me an idea
[20:14:17] <mgouget> alex_joni: ngc file was my B plan ;) but I wanted to show a progress bar, hence the need to know the state of avancement.
[20:14:18] <alex_joni> how about adding a NML command to grab the mutex
[20:14:39] <alex_joni> the GUI prepares the NML command with it's id or whatever
[20:14:43] <alex_joni> sends it to task
[20:15:00] <alex_joni> when task allocs the mutex to the id requested, it notifies that in status
[20:15:07] <mgouget> alex_joni: sounds OK to me
[20:15:13] <alex_joni> only then is the GUI certain it can do whatever
[20:15:49] <mgouget> But you have to think of what goes on if the task crashes...
[20:16:07] <alex_joni> task crashes?
[20:16:21] <mgouget> semaphores have a nice UUNDO feature
[20:16:43] <mgouget> Sorry, the GUI or druid crashes
[20:16:59] <alex_joni> * alex_joni votes for whipping the programmer
[20:17:09] <mgouget> :)
[20:17:10] <jepler> anything that doesn't fix the 'gui + halui' case isn't an ultimate solution
[20:17:19] <alex_joni> jepler: agreed
[20:17:36] <alex_joni> I'd even go as far as to say 'remote gui + halui' case
[20:17:38] <mgouget> halui can be modified to use this mechanism
[20:18:20] <mgouget> BTW, what is exactly the problem with halui?
[20:19:41] <jepler> isn't it the same problem as gui + druid ?
[20:20:57] <jepler> two programs writing to one one command buffer and reading one echo_serial_number
[20:22:01] <alex_joni> yup
[20:22:42] <mgouget> I am sorry, I have to leave now for about an hour (family duties...), I will be back in 1 hour. I am OK to volunteer for finding a clean solution to remote (GUI+halui+druid), but I think that it can be done with NML alone, we need queues
[20:23:02] <jepler> have fun
[20:23:09] <mgouget> sorry, it cannot be done...
[20:23:15] <mgouget> Ciao
[20:23:39] <alex_joni> NML channels can be set up as queued
[20:46:30] <jepler> I wonder if this CD still works with all the packages I removed .. 510M emc2.1.7-ubuntu-6.06.1-deskop-i386.iso
[20:50:26] <skunkworks> I cannot get a pci video card to work on the computer I was testing gutsy
[20:51:06] <skunkworks> It won't boot off of the live cd with one pluggged in.. odd.
[20:53:25] <cradek> jepler: dumb question, but did you try it before you changed a bunch of stuff? I've had some troubles I never did figure out.
[21:00:19] <jepler> cradek: no, I haven't actually tried it yet
[21:00:27] <jepler> why would I do that?
[21:00:35] <cradek> I know I know
[21:00:51] <cradek> just that I've made a lot of them that wouldn't even boot
[21:01:09] <jepler> anyway, it's not "smaller enough" to really make a difference for people with slow 'net connections
[21:03:50] <jepler> what's the "pool" directory on the cdrom for?
[21:04:01] <jepler> is that stuff that can be installed by apt-cdrom?
[21:24:27] <alex_joni> jepler: I think we shouldn't try to include as many things on the liveCD as possible (devel tools, etc)
[22:00:21] <mgouget> Hello, back again!
