#emc-devel | Logs for 2010-03-14

[01:11:12] <seb_kuzminsky> jepler: ok thanks, i just wasnt sure since i'd messed one of the commits up, and there was some question about the validity of that line of development
[02:08:50] <CIA-2> EMC: 03jepler 07master * r518ccfa235ed 10/ (2 files in 2 dirs): improve progress bar during long program load
[02:08:52] <CIA-2> EMC: 03jepler 07master * r6fdba5aac2d2 10/ (3 files in 3 dirs): calculate extents in C++
[02:08:53] <CIA-2> EMC: 03jepler 07master * r8f011ced508e 10/lib/python/rs274/ (glcanon.py interpret.py): reduce python overhead in arcs
[02:08:53] <CIA-2> EMC: 03jepler 07master * re499bf122aa7 10/lib/python/rs274/interpret.py: micro-optimize arc_feed loop
[02:08:54] <CIA-2> EMC: 03jepler 07master * r9e6dec4e80e8 10/lib/python/rs274/interpret.py: Optimize XY rotation
[02:08:58] <CIA-2> EMC: 03jepler 07master * rcab1eeadf6e1 10/lib/python/rs274/glcanon.py: make it possible to declare a dlist "stale"
[02:09:31] <CIA-2> EMC: 03jepler 07master * r52f87d268d32 10/ (2 files in 2 dirs): Convert arcs to segments in C
[02:09:32] <CIA-2> EMC: 03jepler 07master * r3ecdca0af134 10/docs/src/config/ini_config.lyx: document new inifile item
[02:09:33] <CIA-2> EMC: 03jepler 07master * r944506929cd9 10/src/emc/rs274ngc/gcodemodule.cc: reduce minimum number of arc segments
[02:09:45] <CIA-2> EMC: 03jepler 07master * re711664f51ba 10/ (2 files in 2 dirs): defer creating the display and selection lists
[02:09:50] <CIA-2> EMC: 03jepler 07master * r04b296005d08 10/src/emc/usr_intf/axis/scripts/axis.py: allow inifile to set arc subdivision
[02:09:57] <CIA-2> EMC: 03jepler 07master * rcdcc1ce574a4 10/ (2 files in 2 dirs): reduce default number of segments
[02:09:58] <CIA-2> EMC: 03jepler 07master * r6f5025ae1843 10/lib/python/rs274/interpret.py: allow tuning of arc subdivision at this layer
[02:16:42] <seb_kuzminsky> dapper didnt like that
[02:16:49] <seb_kuzminsky> the other dists seem fine
[02:19:51] <jepler> we don't care whether dapper builds master (or 2.4 for that matter)
[02:20:25] <jepler> looks like dapper's python is so old that some API isn't const enough for the code I wrote
[02:54:07] <seb_kuzminsky> are we dropping dapper support for 2.4? if so i'll be happy to kill those builds (and hopefully replace them with lucid builds later)
[02:59:25] <CIA-2> EMC: 03jepler 07master * rac5bbac14f24 10/src/emc/rs274ngc/gcodemodule.cc: make it build with python2.4
[03:00:09] <jepler> seb_kuzminsky: yes. dapper left desktop support in June 2009 and isn't a supported platform for emc2.4
[03:00:24] <jepler> imo, feel free to drop it from buildbot
[03:01:18] <jepler> we already can't build packages on dapper due to lyx version choices
[03:02:10] <seb_kuzminsky> ok, i'll remove it
[03:02:31] <seb_kuzminsky> for 2.4 and master, i'll keep it around for 2.3 builds until we officially end-of-life 2.3
[03:03:01] <jepler> ok
[03:44:58] <jepler> 'night all
[03:48:01] <seb_kuzminsky> ok, we no longer build 2.4 or master on dapper
[04:03:53] <CIA-2> EMC: 03seb 07master * ra6c55e13a020 10/src/ (8 files in 8 dirs): Fix some minor linking issues
[04:19:17] <cradek> the end of an era
[04:21:44] <seb_kuzminsky> and good riddance
[04:24:33] <cradek> it is/was a good release
[04:28:21] <seb_kuzminsky> i bet you're right (i was on debian back then so i dont know)
[04:28:43] <seb_kuzminsky> i just can't stay excited about old, obsolete, stable, reliable software :-/
[04:28:58] <seb_kuzminsky> give me novelty or give me death!
[04:29:17] <cradek> I just recently installed dapper for a new project (a pseudo-embedded machine)
[04:30:28] <seb_kuzminsky> the subpanel's going up on wednesday, then i'll be ready to receive the mill :-)
[04:30:35] <cradek> neat
[04:30:55] <seb_kuzminsky> my bro's fixing the brake controller for the trailer, on his truck
[04:31:10] <cradek> ah, that's important
[04:31:12] <seb_kuzminsky> then there's this pesky family vacation to get over with, then i can come pick it up :-)
[04:31:29] <cradek> too bad jeff isn't going to be here.
[04:31:35] <seb_kuzminsky> i hope the weather's good that weekend
[04:31:41] <cradek> me too.
[04:31:54] <cradek> no big deal if you have to tarp it, I guess
[04:32:01] <cradek> just bring duct tape, and also some more duct tape
[04:32:10] <seb_kuzminsky> heh
[04:32:34] <seb_kuzminsky> on the way back to boulder last time there was this weird freezing mist that coated the road with about 1/8" ice
[04:32:43] <seb_kuzminsky> that was fun, at 20 mph in a light truck
[04:32:53] <cradek> the trip back from here?
[04:32:53] <seb_kuzminsky> can't imagine what it would have been like pulling 2 tons of mill
[04:32:59] <seb_kuzminsky> from your place
[04:33:12] <cradek> oh heck, I didn't know you had trouble going back
[04:33:19] <seb_kuzminsky> no trouble, just slow
[04:33:32] <cradek> yeah, that would be time to stop wherever you are.
[04:34:02] <seb_kuzminsky> it was only a short stretch, a dozen miles maybe, then the road was dry again
[04:35:05] <seb_kuzminsky> sigh, the buildbot vms sometimes still get stuck waiting for the network, like right now: http://emc2-buildbot.colorado.edu/buildbot/waterfall
[04:35:49] <seb_kuzminsky> if i log in to the hardy-sim-i386 vm, it's got a child of apt sitting in select, waiting to hear back from one of its deb archives
[04:35:54] <cradek> I just did a git pull and it took about 1 second
[04:36:08] <seb_kuzminsky> if i kill it (thereby failing that particular build) and run apt-get by hand, it works fine
[04:36:17] <cradek> oh it's not git
[04:38:48] <seb_kuzminsky> there's a bunch of TCP connections to canonical in the CLOSE_WAIT state
[04:40:57] <seb_kuzminsky> wonder why the tcp shutdown's not happening
[04:41:06] <seb_kuzminsky> ugh, a debugging session for another night
[04:41:08] <seb_kuzminsky> seeya cradek
[04:41:15] <cradek> goodnight
[11:27:54] <CIA-2> EMC: 03jthornton 07master * rf1c8587d1a32 10/docs/src/ladder/classic_ladder.lyx: change double dash font to typewriter font.
[11:31:28] <JT-Dev> well looks like that worked :)
[15:26:53] <jepler> huh, I just found a bug in emc's inifile handling
[15:27:01] <jepler> or at least the python wrapper
[15:27:34] <jepler> http://pastebin.ca/1839525
[16:03:17] <CIA-2> EMC: 03jthornton 07v2.4_branch * r898a45d23c1a 10/docs/src/ladder/classic_ladder.lyx: change double dash font to typewriter font
[16:23:27] <CIA-2> EMC: 03jepler 07v2.4_branch * ra242646d8b85 10/src/libnml/inifile/inifile.cc: Fix a bug when one tag is a prefix of another
[16:44:41] <alex_joni> jepler: I think that's always been like that
[16:44:59] <alex_joni> I recently used inifile.c from emc1, and it does the same thing
[17:14:10] <jepler> yeah, I looked at old versions and it looks like it's had that bug ever since the "num" or "num_" parameter was introduced
[17:54:49] <alex_joni> * alex_joni mourns the BOFH
[20:10:17] <JT-Hardinge> check out the front and back angle after loading the tool table editor back up http://imagebin.ca/view/Zmq8yeXW.html
[20:18:29] <SWPadnos> looks like something needs a slightly different printf format string
[20:28:26] <JT-Hardinge> if I knew where it was I would break it for sure :)
[20:41:40] <micges> JT-Hardinge: are angles correct wroted in tool table?
[20:49:56] <dgar> JT-Hardinge: you might prefer this for format:http://www.panix.com/~dgarrett/stuff/different_angle_format.patch
[20:49:58] <JT-Hardinge> micges: as far as I know
[20:51:09] <JT-Hardinge> I put 60 and 120 on tool 4 saved it the opened it back up
[20:52:13] <JT-Hardinge> micges: no
[20:52:28] <JT-Hardinge> T4 P4 X-.1 Z-4 D0.03 I6e+01 J1e+02 Q6 ;od threading
[20:52:51] <JT-Hardinge> I finally understood what you meant I think
[20:53:24] <micges> yes exactly that, what format are they wroted on tool table
[20:54:09] <JT-Hardinge> T3 P3 X-0.1 Z-1.273 D0.125 I9e+01 J9e+01 Q6 ;parting tool
[20:58:05] <micges> JT-Hardinge: you're on master?
[20:59:17] <JT-Hardinge> 2.4~pre
[22:35:15] <micges> aystarik: Axis loads files really fast after your and jepler work on this subject
[22:45:52] <aystarik> well, I want it even faster :)
[22:47:15] <aystarik> there is room for improvement in draw_lines. (2x may be)
[22:49:19] <aystarik> jeff mentioned you were looking into this area too?
[22:52:20] <micges> yes but only part that were affecting my programs
[22:53:20] <micges> I speeded up dwells, and I locally did some part of your arc patches
[22:57:43] <aystarik> "some part of my arc patches" -- what do you mean?
[22:58:18] <aystarik> is there anything not yet commited?
[22:58:31] <micges> simply I was going the same way as you :)
[23:03:14] <aystarik> too bad you did not mentioned it...
[23:03:32] <aystarik> might have saved some time
[23:05:05] <aystarik> len, is it safe to assume u16 to be the same as u8[2]?
[23:05:31] <aystarik> ups... wrong thread...
[23:07:05] <alex_joni> aystarik: I'm not sure that's ok on all architectures
[23:08:49] <aystarik> alex_joni: interesting are only Intel-related. For them it should hold... :)
[23:09:05] <aystarik> little-endian
[23:09:09] <alex_joni> for intel it's probably always true
[23:25:01] <aystarik> micges: what did you change to speed up dwells?
[23:25:37] <micges> move code that draws them to c++ (draw_dwells)
[23:27:04] <aystarik> do you see any other area for imrovement? beside of moving all glcanon to c++?
[23:29:10] <micges> no idea, I will test master soon in production machine and we will see
[23:29:42] <micges> on sim there is noticeable speed up
[23:32:34] <micges> aystarik: move whole canon and opengl code to c++ will be the best
[23:35:44] <aystarik> this is on my todo list :)
[23:35:44] <aystarik> also to drop Tk in favor of Qt4 :)
[23:35:44] <aystarik> wonder if it means a fork of AXIS?
[23:35:44] <micges> I don't know ask jepler
[23:35:44] <micges> I think he doesn't want to drop tk
[23:35:50] <micges> but this is only my opinion
[23:36:04] <cradek> I'd be happy to hear about some of the benefits that would bring - for instance I'd like to have the handle that lets me drag the boundary between the program listing and the above stuff, so more or fewer lines could be shown
[23:36:05] <aystarik> All his new additions are GTK-python.
[23:36:42] <aystarik> creadek: I have a patch in my tree to do so...
[23:36:43] <cradek> true, gtk would find much easier acceptance than qt because of the additional dependencies
[23:37:19] <aystarik> actually two handles -- one vertical and one horisontal.
[23:38:06] <cradek> in the existing toolkit you mean? I thought we tried (long time ago) and it worked badly. Maybe it's better today...?
[23:38:54] <aystarik> I've tried only on 8.5, can't tell if 8.4 is broken
[23:39:45] <cradek> neat, I'd like that improvement.
[23:43:41] <aystarik> jeff seems to be reimplementing all of my changes from his POV... why?