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