Back
[00:31:03] <Guest708> Guest708 is now known as skunkworks_
[01:52:35] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: some more notes on what to do and how to do it
[01:53:22] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (11 files):
[01:53:22] <CIA-2> EMC: Rename all the logging macros, so my WARN() doesn't collide with the
[01:53:22] <CIA-2> EMC: one added in 2.6.27 (problem found by acemi).
[14:08:37] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/ (m5i20.lyx opto22.lyx pico_ppmc.lyx): clean up
[14:12:32] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/spindle.lyx: clean up
[14:22:02] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/ (image-to-gcode.lyx tkemc.lyx): clean up
[14:30:01] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/install/compiling_emc2.lyx: clean up
[14:38:32] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (11 files): clean up
[15:31:41] <cradek> is richard acosta actaully asking how to use AC motors and VFDs for axis positioning?
[15:32:27] <SWPadnos> no idea
[15:33:14] <SWPadnos> until I saw who it was, I assumed it was a question about how to connect a voltage-to-frequency converter to the 7i43 (as some sort of feedback)
[15:33:21] <SWPadnos> that may have been pre-coffee too
[15:34:35] <SWPadnos> hi Matt. did you fix it?
[15:35:01] <SWPadnos> or maybe I should ask if you borke it ...
[15:35:17] <SWPadnos> s/borke/broke|borked/
[15:39:57] <mshaver> It runs, by careful setting of stepgen maxaccel, but It's not really right either.
[15:40:26] <skunkworks> we still need an update from jmkasunich
[15:40:27] <mshaver> I think you said the magic words, "It's all FF", rather than all P
[15:41:09] <mshaver> for systems with no physical feedback mechanism
[15:41:28] <mshaver> because there will never be a "real" error term
[15:47:04] <cradek> sounds interesting - what's the problem?
[15:52:20] <cradek> SWPadnos:
http://www.mail-archive.com/emc-users@lists.sourceforge.net/msg12778.html
[15:52:28] <cradek> so, yes, that's what he's asking about
[15:54:17] <cradek> bbl
[16:33:06] <alex_joni> seems SF is adding git repos
[16:50:26] <seb_kuzminsky> * seb_kuzminsky is reading dave gingery
[16:51:47] <BigJohnT> what are you going to make seb_kuzminsky ?
[16:52:06] <seb_kuzminsky> heh, prolly nothing for a long time
[16:52:19] <seb_kuzminsky> i still have a cnc conversion i should be concentrating on
[16:52:35] <seb_kuzminsky> it's just impressive what he accomplished
[16:52:36] <BigJohnT> you gotta wonder how those machines worked...
[16:52:50] <seb_kuzminsky> how well they worked you mean? how precise they were?
[16:53:01] <BigJohnT> that too
[16:53:39] <seb_kuzminsky> the operation of the machines themselves are pretty well covered in "Build your own metal working shop from scrap"
[16:55:26] <seb_kuzminsky> mshaver: you around? any new info on the hm2 stepgen ferror problem?
[16:56:46] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/classic_ladder.lyx: update images
[16:56:52] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/images/ (15 files): update images
[17:02:54] <buildmaster> build #694 of hardy-x86-trunk-realtime-deb is complete: Failure [failed compile] Build details are at
http://emc2-buildbot.colorado.edu/buildbot/builders/hardy-x86-trunk-realtime-deb/builds/694
[17:03:06] <seb_kuzminsky> ruh roh
[17:03:26] <seb_kuzminsky> ../docs/src/Submakefile:388: *** Required image file ../docs/src/ladder/images/Bit_Status.png does not exist. Stop.
[17:06:29] <buildmaster> build #660 of dapper-x86-trunk-realtime-deb is complete: Failure [failed compile] Build details are at
http://emc2-buildbot.colorado.edu/buildbot/builders/dapper-x86-trunk-realtime-deb/builds/660
[17:23:54] <BigJohnT> hmmm
[17:27:50] <BigJohnT> seb_kuzminsky: looks like it takes a dump every time I replace an image with a new one with a different name
[17:29:04] <alex_joni> BigJohnT: according to
http://cvs.linuxcnc.org/cvs/emc2/docs/src/ladder/images/
[17:29:12] <alex_joni> I don't see a Bit_Status.png
[17:29:49] <BigJohnT> and it is no longer used in the lyx
[17:30:29] <BigJohnT> and I'm totally messed up :/
[17:32:26] <BigJohnT> time to start drinking
[17:33:09] <BigJohnT> * BigJohnT kicks CIA-2
[17:33:09] <CIA-2> ow
[17:34:23] <BigJohnT> cvs is slow today
[17:35:38] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/images/Bit_Status.png: do not forget to add the images
[17:35:43] <BigJohnT> I'm glad I deleted crack monkey from the commit log
[17:35:53] <alex_joni> ;)
[17:35:58] <alex_joni> forgot the cvs add?
[17:36:11] <BigJohnT> one of the three...
[17:36:35] <seb_kuzminsky> BigJohnT: the drinking helped!
[17:36:50] <BigJohnT> heh
[17:36:55] <alex_joni> except for the vapours
[17:37:19] <BigJohnT> now I need to go purchase my drinking buddy some sharp tools for his 72nd birthday party today
[17:39:40] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/tool_compensation.lyx: add info on touchoff thanks for the excellent example Chris
[17:40:03] <alex_joni> BigJohnT: some pictures to go with that would be best
[17:40:23] <BigJohnT> working on that :)
[17:40:26] <alex_joni> seb_kuzminsky: short question
[17:40:32] <seb_kuzminsky> shoot
[17:40:39] <alex_joni> is there a way to make buildbot announce a success after a fail ?
[17:40:40] <BigJohnT> oh crap forgot to cvs add the image
[17:41:00] <seb_kuzminsky> alex_joni: no :-(
[17:41:05] <seb_kuzminsky> i wish there was
[17:41:10] <alex_joni> seb_kuzminsky: CF does that :D
[17:41:23] <alex_joni> don't sweat it
[17:41:39] <alex_joni> it's great to have announcements about broken packaging anyways
[17:42:26] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/images/ToolTable-TouchOff.png: add image first!
[17:43:05] <BigJohnT> heh I think I made under the time limit :)
[17:43:42] <alex_joni> seb_kuzminsky: does a new commit abort an older compile?
[17:43:50] <seb_kuzminsky> alex_joni: no
[17:43:57] <alex_joni> or does it trigger a post-build (finish the current build, then start a new one)
[17:44:05] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_HAL.lyx: move halshow to integrators manual
[17:44:06] <seb_kuzminsky> the builds stack up
[17:44:10] <alex_joni> right, ok
[17:44:31] <BigJohnT> but it waits 2 minutes right?
[17:44:49] <seb_kuzminsky> if you look at the waterfall now, notice hardy-x86-trunk-realtime-rip has 2 builds pending but hardy-x86-trunk-sim has only
[17:44:51] <seb_kuzminsky> only 1
[17:45:09] <alex_joni> ah
[17:45:11] <BigJohnT> * BigJohnT is off to town if no one else wants to test the build failure
[17:45:15] <seb_kuzminsky> that's because there's only one hardy buildslave, and each buildslave is configured to do only one build at a time
[17:46:29] <seb_kuzminsky> speaking of which, if anyone wants to run a buildslave vm, we could get more parallelism in the builds ... <wink>
[17:47:02] <BigJohnT> you have to have an "always on" connection for that right?
[17:47:05] <seb_kuzminsky> it's a kvm/qemu vm, all set up, all it needs is a linux host to run on and the ability to make outgoing tcp connections
[17:47:15] <seb_kuzminsky> always on internet is required, yes
[17:47:27] <BigJohnT> I'm on a string
[17:47:33] <BigJohnT> and two tin cans
[17:47:49] <seb_kuzminsky> bitrate's no problem ;-)
[17:48:23] <BigJohnT> but hogging the line is not liked by my ISP
[17:48:29] <BigJohnT> or my wife
[17:48:32] <seb_kuzminsky> heh
[17:48:47] <BigJohnT> ./me has got to get that tower up
[17:49:58] <BigJohnT> talk to you guys later
[17:50:08] <seb_kuzminsky> seeya BigJohnT
[17:50:33] <BigJohnT> hey seb_kuzminsky I could do it at my machine shop when I get the linux box going over there...
[17:50:45] <BigJohnT> we have cable internet there
[17:50:52] <seb_kuzminsky> oohh, cool!
[17:51:03] <BigJohnT> gotta go
[17:51:07] <seb_kuzminsky> it really doesnt take much resources to set up or to run
[17:51:13] <seb_kuzminsky> ok later :-)
[17:52:32] <alex_joni> same here.. back in 1-2 hours
[17:52:46] <alex_joni> seb_kuzminsky: I could run one, but my box isn't always on
[17:52:59] <alex_joni> do you have one that can be ron on non-X systems?
[17:53:27] <alex_joni> s/ron/run/
[17:53:36] <seb_kuzminsky> yes the buildslave vms dont need X
[17:54:13] <alex_joni> hmm.. then I could probably run one
[17:56:12] <seb_kuzminsky> yay :-D
[17:57:41] <seb_kuzminsky> the version of kvm i'm running is linked against some of the X client libs, but the machine i'm running it on doesnt have an x server, and the kvms are running without X windows displaying anywhere
[17:57:56] <seb_kuzminsky> they're exporting vnc displays for their consoles, but i never connect to them ;-)
[18:44:55] <alex_joni> seb_kuzminsky: I have a lenny VM with gcc 4.3 on it
[18:46:31] <SWPadnos> hmmm. Jaunty probably uses 4.3 as well
[18:47:00] <alex_joni> I think even 8.10 might
[18:47:13] <SWPadnos> I Guess I'll find out once it's booted :)
[18:47:35] <SWPadnos> running alpha is pretty funny - there are about 100M of updates per day
[18:47:52] <SWPadnos> they sure did get the boot a bit faster in Jaunty
[18:47:55] <alex_joni> if you wait a week, you might just download a new CD
[18:48:05] <SWPadnos> yeah, once I get back from Hawai'i
[18:48:10] <alex_joni> heh
[18:48:34] <SWPadnos> yep. 4.3.3
[18:50:35] <SWPadnos> I wonder if that 's contributing to the segfault I get running Axis
[18:50:59] <SWPadnos> (if they build Tkinter / python / whatever with gcc 4,3)
[18:51:43] <alex_joni> still getting the segfault?
[18:51:51] <mshaver> alex_joni: are you making a Jaunty/EMC cd?
[18:51:59] <alex_joni> mshaver: nope
[18:52:15] <alex_joni> I try to keep myself busy with LTS releases
[18:52:46] <mshaver> just your previous comment to swp was, "if you wait a week, you might just download a new CD"
[18:52:47] <SWPadnos> huh. only ~12M of updates since midnight or so :)
[18:52:55] <SWPadnos> a new jaunty Alpha/Beta CD
[18:52:58] <alex_joni> mshaver: a new jaunty CD
[18:53:00] <SWPadnos> should be out on the 25th I think
[18:53:05] <alex_joni> instead of 100MB daily
[18:53:05] <SWPadnos> or March 1 or something
[18:53:11] <mshaver> ah, ok
[19:12:44] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/ (shcom.cc shcom.hh): fix a couple more places where LINELEN was incorrectly used. In later versions LINELEN should be increased, and it should replace all those defines
[19:23:46] <SWPadnos> so, anyone interested in running a benchmark for me (and jmkasunich, even if he's not interested :) ), please download
http://www.thothsystems.com/images/dsc_0291.nef, and let me know the result of "time dcraw -q 3 dsc_0291.nef"
[19:23:59] <SWPadnos> you may need to install dcraw, of course (should be a package available)
[19:24:24] <SWPadnos> (jmkasunich - I'm specifically interested in results on the atom)
[19:24:48] <jmkasunich> SWPadnos: 404
[19:24:51] <SWPadnos> hmmm
[19:24:56] <SWPadnos> take out the comma
[19:25:05] <jmkasunich> what is a nef file anyway?
[19:25:13] <SWPadnos> Nikon raw file
[19:25:23] <jmkasunich> ah
[19:25:30] <jmkasunich> at the moment the atom board is at work
[19:25:40] <SWPadnos> ok, no rush
[19:25:41] <jmkasunich> and I'm recovering
[19:25:45] <SWPadnos> heh
[19:25:47] <SWPadnos> how did it go?
[19:25:51] <jmkasunich> it didn't
[19:25:56] <SWPadnos> bummer :(
[19:26:01] <alex_joni> bummer
[19:26:22] <jmkasunich> I worked all night thursday, at the 9am friday morning deadline it still wasn't working
[19:26:30] <alex_joni> SWPadnos: interested in a time from dapper/VM ?
[19:26:37] <SWPadnos> was the comma at the end of the link the problem, or does the download work now?
[19:26:40] <SWPadnos> alex_joni, no, thanks :)
[19:26:49] <alex_joni> hardy/VM then?
[19:26:56] <SWPadnos> how about native ... ;)
[19:27:04] <jmkasunich> I can follow paths that I already know exist, and I can sometimes detect intersections, etc when I see them (I know what needs to be done to make that more reliable)
[19:27:07] <SWPadnos> (even on Windows - there's a dcraw.exe
[19:27:09] <jmkasunich> but I just didn't have enough time
[19:27:20] <alex_joni> hmm.. ok
[19:27:21] <SWPadnos> yeah, "seeing" the maze is a pretty big job
[19:27:34] <jmkasunich> SWPadnos: it seems to work now - I didn't bother saving the file tho
[19:27:37] <SWPadnos> oh, and if you can tell me the CPU type/speed, that would be good
[19:27:55] <SWPadnos> jmkasunich, ok. like I said - no rush. I['m headed for Honolulu on Monday, so I won't care much until March ;)
[19:29:05] <jmkasunich> if you can email me the file (or the URL) and what you want me to do with it I'll be more likely to remember
[19:29:05] <alex_joni> SWPadnos: got dcraw, waiting on the download for the nef
[19:29:17] <SWPadnos> hmmm. odd. is it dribbling through?
[19:29:28] <SWPadnos> jmkasunich, ok, will do (id I remember)
[19:29:37] <SWPadnos> I wonder how you time something on Windows
[19:29:54] <alex_joni> SWPadnos: unix-tools
[19:30:15] <SWPadnos> those are native?
[19:30:30] <SWPadnos> ie, no extra library loading that's part of the timing ...
[19:30:36] <alex_joni> I think so
[19:30:44] <alex_joni> http://sourceforge.net/project/showfiles.php?group_id=9328
[19:32:56] <alex_joni> hmm.. no time :/
[19:32:57] <alex_joni> bummer
[19:33:10] <SWPadnos> bummer
[19:33:42] <SWPadnos> you may be able to use a batch file that has time /t | dcraw ... | time /t
[19:33:51] <SWPadnos> but I don't know if the /t option is from take command
[19:34:05] <alex_joni> found ptime
[19:34:10] <jmkasunich> SWPadnos: got the email, will do
[19:34:13] <SWPadnos> nope, it should be there in a regular prompt as well
[19:34:15] <SWPadnos> thanks
[19:34:17] <alex_joni> http://www.pc-tools.net/win32/ptime/
[19:34:51] <SWPadnos> cool, but where's teh screenchot(s) ;)
[19:34:54] <SWPadnos> gah
[19:35:15] <alex_joni> 3 mins eta on the download :/
[19:35:23] <SWPadnos> odd. it's only 8M
[19:35:23] <alex_joni> my wire is clogged today
[19:35:31] <alex_joni> it's dribblingin at about 17kB
[19:35:31] <SWPadnos> or 11.6 or something :)
[19:35:35] <SWPadnos> bummer
[19:35:46] <SWPadnos> that's about my upload speed
[19:35:48] <alex_joni> 7.9/11.1 now
[19:35:53] <jmkasunich> SWPadnos: jmkasunich@mahan:~/downloads$ time dcraw -q 3 dsc_0291.nef
[19:35:53] <jmkasunich> dsc_0291.nef: Corrupt data near 0x13bfc1
[19:35:53] <jmkasunich> real 0m6.576s
[19:35:53] <jmkasunich> user 0m5.684s
[19:35:53] <jmkasunich> sys 0m0.540s
[19:36:06] <alex_joni> bad download?
[19:36:06] <SWPadnos> corrupt data. interesting
[19:36:15] <alex_joni> SWPadnos: md5sum it
[19:36:18] <jmkasunich> md5sum it and.
[19:36:19] <SWPadnos> yeah
[19:37:13] <jmkasunich> the ppm result is a few random color speckles on a black background
[19:37:19] <jmkasunich> somehow I think that isn't right
[19:37:26] <SWPLinux> 9830cdfb25ccf07232d2e84e5a1a7113 dsc_0291.nef
[19:37:28] <SWPLinux> nope
[19:38:00] <jmkasunich> the md5sum matches
[19:38:06] <SWPLinux> hmmm
[19:38:18] <jmkasunich> and I can view the original ned - its a board on a keyboard
[19:38:26] <SWPLinux> yep
[19:38:35] <jmkasunich> although it seems to have a strong bluish tint
[19:38:51] <jmkasunich> is that just because it is raw, no white balance yet?
[19:38:59] <alex_joni> probably so
[19:39:00] <SWPLinux> yeah, it's kind of weird. the ppm would have correct color balance
[19:39:19] <jmkasunich> its also only 160x120
[19:39:23] <SWPLinux> I can't see the NEF file without converting it to something first
[19:39:25] <alex_joni> for some reason chrome decided to append .tiff to the filename
[19:39:34] <alex_joni> dsc_0291.nef.tiff
[19:39:36] <SWPLinux> oh, that's the preview image stuck in there by the camera
[19:39:38] <SWPLinux> heh
[19:39:40] <jmkasunich> ah
[19:39:48] <seb_kuzminsky> alex_joni: does your lenny vm have rtai?
[19:39:54] <alex_joni> yeah
[19:39:54] <jmkasunich> I was just starting to suspect something of that sort
[19:40:01] <SWPLinux> I noticed that the jpegs were blue-shifted, when saving raw+jpeg
[19:40:02] <seb_kuzminsky> suh-weet
[19:40:40] <jmkasunich> SWPLinux: if you run the exact same command you don't get the corrupt data message?
[19:40:54] <SWPLinux> the actual file is 4320x2868
[19:40:58] <SWPLinux> one sec
[19:41:31] <jmkasunich> my dcraw is v8.77
[19:41:37] <SWPLinux> let me download it and try on the downloaded version (I changed the name, which shouldn't have an effect)
[19:41:55] <jmkasunich> ISTR I downloaded it about a year back, when I was trying to process pentax raw images
[19:42:15] <jmkasunich> I also STR that I was doing some fiddlefarting around with different versions
[19:42:49] <SWPLinux> I've got 8.86
[19:42:54] <jmkasunich> hmm, dpkg says I have dcraw package 7.94-1ubunu1 installed
[19:43:08] <jmkasunich> I bet I have both - package and something newer that I built from source
[19:43:11] <SWPLinux> you may have downloaded a newer one directly
[19:43:14] <SWPLinux> yep
[19:43:21] <SWPLinux> is there a newer package?
[19:43:51] <jmkasunich> probably not for dapper
[19:44:01] <jmkasunich> (or I would have been updated already)
[19:44:04] <SWPLinux> heh, true
[19:44:10] <jmkasunich> the atom has hardy on it
[19:44:39] <SWPLinux> oh, dapper
[19:44:50] <SWPLinux> here I was thinking that was 8.04
[19:45:07] <jmkasunich> if it ain't broke, don't fix it, is my motto
[19:45:11] <jmkasunich> especially for my main PC
[19:45:16] <SWPLinux> it's 8.80-1 on hardy and intrepid
[19:45:17] <SWPLinux> yep
[19:45:53] <alex_joni> finally it's doing somehting
[19:45:56] <jmkasunich> yesterday I just dumped everything in the lab and went home disgusted
[19:46:25] <jmkasunich> to top off the 'failure to meet the contest target", I also had "failure to even do a demo run"
[19:46:58] <jmkasunich> I was gonna do a run showing tracking of lines, given pre-knowledge of the maze - I entered the maze config so the code could solve it and run the path
[19:47:14] <SWPLinux> it was a big project. you got a lot further than anyone else I know would have
[19:47:25] <jmkasunich> and then, 5 mins before the demo (just as the real runs were finishing up) a FET in the motor driver board failed shorted
[19:47:37] <SWPLinux> next week, DARPA challenge :)
[19:47:41] <SWPLinux> that's a real lbummer
[19:47:45] <SWPLinux> -l
[19:48:15] <jmkasunich> I had some neat code working
[19:48:20] <alex_joni> SWPLinux: 58.418s
[19:48:21] <SWPadnos> you sure did
[19:48:27] <SWPadnos> heh
[19:48:32] <SWPadnos> is that on a Commodore 64?
[19:48:50] <jmkasunich> for recognizing the intersections, one problem is that an intersection is slightly bigger than the distance from "maximum range of camera" to "obstructed by vehicle's own front bumper"
[19:48:50] <alex_joni> I suspect the dcraw is badly compiled
[19:48:55] <SWPadnos> I should try it on my Windows PC
[19:48:59] <jmkasunich> so I merged multiple images
[19:49:06] <alex_joni> the first one I found (optimized) needs some dll's I don't have
[19:49:11] <alex_joni> (cygwin stuff)
[19:50:20] <jmkasunich> on an almost complete unrelated note - found a weird bug? with the atom
[19:50:25] <SWPadnos> ??
[19:50:35] <jmkasunich> the webcam works fine plugged into the back panel USB jacks
[19:50:38] <SWPadnos> alex_joni, a cygwin version would naturally suck
[19:50:42] <jmkasunich> but we didn't want the long cord
[19:50:44] <seb_kuzminsky> what does "const struct foo **blargh" mean? what part of that is const?
[19:51:05] <jmkasunich> so we cut it off and made a connector that would fit one of the motherboard USB headers
[19:51:13] <alex_joni> SWPadnos: 12.290s for the MS compiler version
[19:51:22] <jmkasunich> that didn't work
[19:51:44] <jmkasunich> seb_kuzminsky: damn good question
[19:52:03] <jmkasunich> I'd think "blarg is a const pointer to a (non-const) pointer to a struct foo
[19:52:16] <SWPadnos> I think it means that the struct can't be modified
[19:52:24] <alex_joni> btw, I can view it just fine in picassa (without converting)
[19:52:26] <SWPadnos> but it could be that the pointer that's pointed to can't be modified
[19:52:49] <jmkasunich> const makes me confused at times
[19:52:58] <seb_kuzminsky> the "clockwise/spiral" rules says blargh is a pointer to a pointer to a struct foo constant"
[19:53:03] <seb_kuzminsky> which i think is what SWPadnos said
[19:53:30] <jmkasunich> that actually would be more usefull than my interpretation
[19:53:40] <jmkasunich> (which was strictly off-the cuff and without clue)
[19:53:45] <SWPadnos> seb_kuzminsky, that's how I read it - backwards
[19:54:08] <SWPadnos> blarg pointer to pointer to foo struct const
[19:54:15] <seb_kuzminsky> thanks guys
[19:54:40] <SWPadnos> could be wrong though. try writing stuff and see what the compiler error is :)
[19:55:06] <jmkasunich> try writing it, and then modifying various parts, see what the compiler yells about
[19:55:57] <jmkasunich> blarg++; (*blarg)++; (*blarg)->some_member++;
[19:56:09] <alex_joni> wonder how you write a const pointer to a const pointer to a const struct foo
[19:57:09] <jmkasunich> const struct foo const *const *blargh; maybe?
[19:57:47] <jmkasunich> const pointers aren't much fun tho - might as well just statically allocate things
[19:57:54] <alex_joni> const struct foo * const *const blargh
[19:58:29] <alex_joni> ROFLMAO:
[19:58:31] <alex_joni> In C, you merely shoot yourself in the foot.
[19:58:38] <alex_joni> In C++, you accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible, because you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."
[19:59:45] <alex_joni> it's definately that "const foo *a" a points to a const foo
[19:59:57] <alex_joni> so you can't use *a = ... to change the value
[20:00:32] <seb_kuzminsky> agreed, but "foo *b = a; *b = 666;" works
[20:01:13] <alex_joni> sure it does
[20:01:57] <SWPLinux> argh. the bastids who built this windows dcraw make it refuse to write to stdout
[20:02:19] <SWPLinux> I noticed on my machine that the disk light is on for 5-10 seconds, so I wanted to pipe to NUL
[20:02:24] <SWPLinux> but nooooooo
[20:03:28] <alex_joni> heh
[20:03:31] <SWPLinux> incidentally, const foo * const * blah could be appropriate
[20:03:37] <alex_joni> yup
[20:03:54] <alex_joni> make a pointer which can't be changed or pointed someplace else
[20:03:57] <SWPLinux> if it means "a pointer that I won't modify which points to a pointer I won't modify which points to data I won't modify"
[20:04:08] <SWPLinux> with as many consts as you want
[20:04:13] <alex_joni> yeah, missed one :P
[20:04:15] <SWPLinux> and it's still better than static allocation
[20:04:17] <SWPLinux> heh
[20:04:35] <SWPLinux> since const in a function is a promise not to modify something
[20:04:51] <SWPLinux> the compiler will error if you attempt to write to something you said you wouldn't write to
[20:04:56] <SWPLinux> \rather than waiting for a runtime error
[20:05:00] <SWPLinux> -\
[20:06:13] <alex_joni> yup
[20:06:23] <alex_joni> gcc 4.3.x is really smart ;)
[20:06:36] <SWPLinux> I'm sure that has been there since gcc 1 or 2 :)
[20:06:49] <SWPLinux> (since that's the whole point behind const)
[20:07:09] <alex_joni> ah, didn't mean const now.. but gcc 4.3.x is really getting smarter
[20:07:15] <SWPLinux> heh
[20:07:24] <seb_kuzminsky> yeah, FORTIFY_SOURCE is good stuff
[20:07:33] <SWPLinux> yeah, I think I agree, but I don't have enough comparative experience to really know for sure
[20:08:13] <seb_kuzminsky> i'm happy to wade through lots of false-positive warnings if there's a true-positive warning that alerts me to a real error every once in a while ;-)
[20:09:05] <SWPLinux> I'm the kind of guy who will spend a lot of time eliminating all warnings if possible
[20:09:38] <SWPLinux> and if it's not possible, then I'm not above using comments and pragmas to kill the warnings in the source file
[20:10:02] <seb_kuzminsky> it's super annoying when there's no way to soothe programs *cough*mandb*cough* about false positives
[20:10:05] <SWPLinux> instead of having to ignore them at build time or set project-wide options that may miss other places where I would want to see it
[20:10:15] <SWPLinux> 0 stray cats added!
[20:11:02] <SWPLinux> alex_joni: what's the CPU in that WIndows box you tried?
[20:11:35] <SWPLinux> oh, and where did you get the executable, or did you build it yourself?
[20:12:12] <SWPLinux> hmmm
[20:12:32] <SWPLinux> the command line should be changed to dcraw -q 3 -c dsc0291.nef > /dev/null
[20:12:44] <SWPLinux> no sense benchmarking disk store time
[20:18:49] <alex_joni> I don't have /dev/null :)
[20:19:54] <alex_joni> execution time: 11.392s
[20:20:10] <alex_joni> SWPLinux: T5300 running at 800 MHz
[20:20:48] <alex_joni> (was on battery)
[20:22:29] <alex_joni> seems CPU doesn't make a difference
[20:22:36] <alex_joni> now running at 1.73GHz, same time
[20:24:41] <SWPLinux> huh. it doesn't increase the clock when under heavy CPU load?
[20:25:01] <alex_joni> the CPU frequency changed from 800 to 1730 Mhz
[20:25:01] <SWPLinux> I used cygwin to privide /dev/null and time ;)
[20:25:13] <alex_joni> but the time on the dcrawms didn't change
[20:25:45] <alex_joni> (the dcrawMS.exe is compiled with MS compiler)
[20:25:53] <alex_joni> http://www.insflug.org/raw/file_download/8/dcrawMS.exe
[20:25:57] <SWPLinux> I guess I'm asking if, when you ran it on battery, the CPU might have been stepped up to 1.7 GHz while it was running
[20:25:59] <alex_joni> might work faster for you too
[20:26:08] <SWPLinux> ok, I'll check that one
[20:26:13] <alex_joni> no, I ran it a couple times on battery
[20:26:16] <alex_joni> it stayed at 800
[20:26:26] <SWPLinux> I got 22.335s on my Athlon 1800 (windows 2000)
[20:26:33] <SWPLinux> huh
[20:27:14] <SWPLinux> does it have an SSD disk?
[20:27:27] <alex_joni> nope
[20:27:45] <SWPLinux> so did you use cygwin to get "time"?
[20:27:49] <alex_joni> ~ 120G HDD
[20:27:53] <alex_joni> I used ptime
[20:28:01] <alex_joni> http://www.pc-tools.net/win32/ptime/
[20:28:46] <SWPLinux> oh, duh
[20:28:48] <SWPLinux> :)
[20:29:25] <SWPLinux> huh. that was 0.4 seconds slower than the other one I had downloaded
[20:30:09] <alex_joni> odd
[20:30:27] <SWPLinux> and now I don't know where it came from, even though I downloaded it less than 20 minutes ago
[20:30:35] <SWPLinux> oh - firefox instead of Mozilla
[20:31:23] <SWPLinux> huh. the one I have is from the same place, except there's a "3" instead of the "8"
[20:32:00] <alex_joni> * alex_joni wonders what SWPLinux is talking about
[20:33:00] <SWPLinux> the version of dcraw that I got was from the same site, but I got the non-optimized one since I have win2k
[20:33:01] <seb_kuzminsky> we all wonder that sometimes
[20:33:08] <SWPLinux> insflug.org
[20:33:13] <SWPLinux> * SWPLinux too
[20:33:18] <seb_kuzminsky> heh
[20:33:51] <alex_joni> SWPLinux: since you have cygwin, there are some other optimized compiles
[20:33:55] <SWPLinux> the MS compiled one refulsed to run unless I piped the output through cat or type to NUL
[20:34:21] <SWPLinux> sure, but I'm not as interested in Windows performance as I am in Linux performance
[20:34:37] <alex_joni> SWPLinux:
http://benniswelt.wordpress.com/?tag=dcraw
[20:34:39] <SWPLinux> it's a heck of a lot easier to make a headless Linux machine than it is to make a headless Windows machine
[20:34:57] <alex_joni> I'm sure it's easier to use the conversion in the camera :D
[20:39:46] <SWPadnos> heh
[20:40:32] <SWPadnos> I'm not sure I'll be using raw files, I'm more curious about relative performance of different processors using these kinds of tools
[20:40:39] <SWPadnos> the next benchmark will be with imagemagick ;)
[20:41:03] <alex_joni> http://www.reghardware.co.uk/2009/02/21/video_sony_ericsson_w995/ -> looks nice
[20:41:35] <SWPLinux> if only it weren't a Sony
[20:42:38] <SWPLinux> one day, the OpenMoko will be usable :)
[20:42:46] <alex_joni> I love my sony ;)
[20:42:58] <SWPLinux> in fact, I think mine would be if I were in Europe
[20:43:07] <SWPLinux> I don't particularly like Sony the company
[20:43:17] <SWPLinux> the original "proprietary format lock-in" company
[20:44:08] <SWPLinux> those cygwin-based builds are terribly slow
[20:44:21] <SWPLinux> 1m5s or so, instead of 22 s
[21:01:34] <alex_joni> it's actually sony-ericsson
[21:01:40] <alex_joni> and more important, it ain't nokia :D
[21:01:45] <alex_joni> which everybody has around here
[22:22:46] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/pci_8255.c: add copyright information
[22:32:06] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/debian/control.in: xsltproc and groff are needed by the configure script now
[23:04:20] <seb_kuzminsky> buildmaster: list builders
[23:04:20] <buildmaster> Configured builders: dapper-x86-2.2-realtime-deb dapper-x86-2.2-realtime-rip dapper-x86-2.2-sim dapper-x86-trunk-realtime-deb dapper-x86-trunk-realtime-rip dapper-x86-trunk-sim hardy-x86-2.2-realtime-deb hardy-x86-2.2-realtime-rip hardy-x86-2.2-sim hardy-x86-trunk-realtime-deb hardy-x86-trunk-realtime-rip hardy-x86-trunk-sim lenny-x86-trunk-realtime-deb lenny-x86-trunk-realtime-rip lenny-x86-trunk-sim
[23:06:10] <alex_joni> yay ;)
[23:07:22] <seb_kuzminsky> well let's see if it works
[23:08:12] <alex_joni> http://emc2-buildbot.colorado.edu/buildbot/one_box_per_builder <- getting long ;)
[23:12:21] <seb_kuzminsky> buildmaster: notify failed
[23:12:21] <buildmaster> try 'notify on|off <EVENT>'
[23:12:30] <seb_kuzminsky> buildmaster: notify on failed
[23:12:30] <buildmaster> The following events are being notified: ['failed']
[23:13:07] <seb_kuzminsky> heh, that initial checkout takes a bit
[23:13:25] <alex_joni> yeah, getting pretty long
[23:13:39] <alex_joni> btw,
http://eneas.juve.ro/~juve/stats/emc2
[23:13:47] <buildmaster> build #0 of lenny-x86-trunk-sim is complete: Failure [failed environment-report configuring autotools] Build details are at
http://emc2-buildbot.colorado.edu/buildbot/builders/lenny-x86-trunk-sim/builds/0
[23:15:01] <alex_joni> gotta install some depends
[23:15:22] <seb_kuzminsky> heh
[23:15:36] <alex_joni> and I have a fix for the debian/configure part
[23:15:42] <alex_joni> can you change the command that gets run?
[23:16:50] <alex_joni> seb_kuzminsky:
http://emc2-buildbot.colorado.edu/buildbot/builders/lenny-x86-trunk-sim/builds/0/steps/environment-report/logs/stdio <- how is that triggered ?
[23:19:06] <seb_kuzminsky> alex_joni: the buildmaster has "builds", each of which is a sequence of build-steps
[23:19:23] <seb_kuzminsky> the environment-report is the first build-step of all the builds
[23:19:32] <seb_kuzminsky> just as a sanity check more than anything
[23:19:47] <alex_joni> I noticed on debian there is no /etc/lsb_release
[23:20:45] <alex_joni> (talk about standards..)
[23:21:22] <seb_kuzminsky> 0 seb@lenny-rtai-x86 /home/seb> lsb_release
[23:21:27] <seb_kuzminsky> No LSB modules are available.
[23:22:12] <alex_joni> lsb_release -a ?
[23:22:16] <seb_kuzminsky> yeah
[23:22:25] <alex_joni> I mean, try running it with -a
[23:23:21] <seb_kuzminsky> the buildbot does run with --all
[23:23:30] <seb_kuzminsky> see the env-check output from the second lenny builder
[23:23:44] <seb_kuzminsky> yay it worked!
[23:24:19] <seb_kuzminsky> wow, big pile of warnings from rtai 3.6.1...
[23:26:11] <seb_kuzminsky> libpth-dev is needed for sim but not for rt
[23:26:23] <seb_kuzminsky> i think that means libpth-dev should be part of Build-Depends:
[23:26:30] <seb_kuzminsky> all in favor say "aye"
[23:26:40] <alex_joni> I think so
[23:26:42] <seb_kuzminsky> aye
[23:27:08] <alex_joni> wonder what's up with all those rtai_lxrt warnings
[23:30:16] <buildmaster> build #0 of lenny-x86-trunk-realtime-deb is complete: Failure [failed compile] Build details are at
http://emc2-buildbot.colorado.edu/buildbot/builders/lenny-x86-trunk-realtime-deb/builds/0
[23:32:00] <alex_joni> forgot to install fakeroot ;)
[23:32:09] <alex_joni> but that's not a Build-Depend
[23:32:51] <seb_kuzminsky> yeah
[23:33:00] <seb_kuzminsky> i added it to the buildslave-admin-guide ;-)
[23:38:16] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/debian/control.in: need libpth-dev to build sim
[23:40:29] <seb_kuzminsky> heh
[23:40:30] <seb_kuzminsky> dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if "debian/emc2/usr/bin/halscope debian/emc2/usr/bin/classicladder debian/emc2/usr/bin/halmeter" were not uselessly linked against it (they use none of its symbols).
[23:41:42] <seb_kuzminsky> my work on this planet is finished
[23:41:47] <seb_kuzminsky> i must now return to my home
[23:41:51] <seb_kuzminsky> on the planet Zarkon
[23:44:35] <alex_joni> you're from Zarkon?
[23:44:48] <alex_joni> then we're pretty much neighbours
[23:45:03] <alex_joni> * alex_joni is also from the Agoraea cluster
[23:46:03] <jepler> seb_kuzminsky: should be that debian/configure puts it in the generated debian/control -- unless you've changed all that around while I've been away
[23:47:05] <jepler> (it = libpth-dev)
[23:47:15] <seb_kuzminsky> jepler: i haven't touched it
[23:47:23] <seb_kuzminsky> at least not intentionally
[23:48:14] <seb_kuzminsky> oh i see
[23:48:29] <seb_kuzminsky> i installed the build-deps for realtime but not for sim
[23:48:44] <seb_kuzminsky> i'll clean up the mess i made...
[23:51:02] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/debian/control.in:
[23:51:02] <CIA-2> EMC: revert my previous checkin...
[23:51:02] <CIA-2> EMC: only sim needs libpth-dev, and it gets it when you run "debian/configure sim"
[23:53:02] <seb_kuzminsky> thanks for setting me straight jeff