jmkasunich: when you're around, I want to talk about the test I wrote called tests/threads.0.
it seems to fail on x86-64
jmkasunich: when I print your diagram, the pointers virtually disappear (I think they are one pixel wide at 600 dpi)
all the thin lines do, actually
I set the thinest lines to 0 width (one printer pixel) because they were too wide for me
I can change that quite easily
well I got what you asked for
maybe your printer is not giving you 600dpi?
I'm trying to maintain a noticible difference between the toolpaths (widest) and the rest
I imagine they'll have at least 600 or 1200
they are *very* noticeable on my printout
hard to say - lemme try the printer here
yeah on screen it's fine - I don't trust it - 100 is very different from 600/1200
the dashes are much better
they better be - the are individual line and arc segments now
don't miss the point targets and tool circles
miss = forget to change their widths too
on my printer it looks great as is
if only we knew what it would look like on the final printer
are you printing the pdf?
jepler: I don't know if hal intends to promise a specific ratio of runs between slow and fast threads, or the best possible approach to the specified periods
whatever my printer does
I'm pretty sure you don't want to tell any "good" printer to give you 1 pixel wide lines
jmkasunich: (in the test, the fast thread is not actually that fast, and the clock granularity is different than I stated -- those are just the first values I picked that gave the result I wanted)
jmkasunich: heh, that's why I was asking
I'll take a photo of mine
jmkasunich: you could try setting the lines to .0034 inch or .085mm (about 300dpi) and see if it prints about the same on your device
I was thinking about that
[00:28:04] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010002.jpg
that's actually a good representation of how it looks here
I think yours is actually 75dpi
I see big jaggies on the circles
its probably 300
still flogging the 9-pin dot matrix along, I see
maybe it's 150
anyway, don't trust it
the big circles are 1" in diameter
count the jaggies
sorry, my time left on the planet is too precious for that
interestingly enough, it looked pretty much exactly the same on the printer at work
huh, maybe it's misconfigured too :-P
(I had to work pretty hard to get mine to do 600)
by the way, that "COMP ON" line really helps me understand the diagrams
there was a complete look of noncomprehension on my face when chris showed me the prior version this morning
(though maybe part of that was that it was about 7AM)
cradek passed along your comments, thanks
I have to run some errands, then I'll fire up my doze lappy (easycad is much nicer to use when the mouse doesn't lag) and fiddle with the line widths
cradek: I'm surprized that the tool circles are messed up on your print
IIRC, they are 0.005" wide, as os the outline (inside and out) of the comp part
the arrows, on/off marks, point targets, and section lines are 0.000
and the tool path lines are 0.010
they appear to be two "zero" width circles separated by a bit
the fill style must be set to hollow
in fact, that might get interesting
if you draw a circle with a zero with line and fill style solid, the circle gets filled in
if you set a non-zero width, the line gets filled in
they were orginally zero width, so I had them set to hollow
that I can fix!
I'll try 0.003/0.005/0.010
cradek: does this ring a bell (from make-kpkg): Warning: The file include/linux/version.h exists The contained UTS_VERSION string: "" does not match expectations:
in fact, lemme do that before I go, then you guys can test it on various printers, etc
I can't get the nvidia kernel module to build for this fricking kernel
In file included from /usr/src/modules/nvidia-kernel/nv/nv.c:14:
/usr/src/modules/nvidia-kernel/nv/nv-linux.h:17:26: error: linux/config.h: No such file or directory
jepler: want a pci matrox millenium II?
cradek: sorry, all PCI slots are used up
(I got a mini-atx board which I may decide was a mistake)
is it agp?
I've got a matrix g400+ here
ah, SOL as far as my parts supply goes
jmkasunich: I think the text on the comp diagram should be left justified - it looks kind of "random" like this
the colons lining up might give some grouping too: comp on:/comp off: are a group, g42:/g41: are a group
oh apparently linux/config.h is removed since 2.6.19..
I can left justify, or line up colons, take your pick
(its not a monospaced font)
[00:54:54] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-back.pdf
check line widths, I'll re-arrange text when I get back
do you suppose a machine with lat_max 121618 would be OK for a "servo-thread only" machine?
(that's should be in ns, it's from testsuite/kern/latency)
I'd avoid that machine
(not that that's an answer to your question)
I finally got the nvidia driver, but the results are like you'd expect...
* cradek spits on the nvidia driver
* jmkasunich spits at places that roll up the sidewalks at 9pm
jmkasunich: how about you -- lat_max 120us OK for 1kHz servo thread?
depends on how critical the machine is
the PID loop won't be aware that some periods are longer than others, so the D term might be a bit messed up
likewise some movements might jitter a bit
but in the mechanical world, 120uS is a damn short time
if you are single point diamond turning the mirror for the next Hubble, you might want something better
for an etch-a-sketch, you could tolerate a lot more
it would be tempting to try passing "wall time between invocations" to all the HAL functions -- that might or might not make PID behave better
there are some things that might benefit from that, and some that might not like it
has anybody looked at / printed the latest PDF?
* jmkasunich is feeling a bit under the gun at the moment
I didn't print - I'll go do it
the tool circles are still hollow
they're solid here
argh, wget bit me in the ass, sorry
that must hurt
I get used to it, using computers and all
the circles are great now, but the narrow lines are still the same kind of invisible
so they are much narrower than the tool circles?
yes 1/4 as wide or less
arrows/section lines/point targets = 0.003, tool circles and part outline 0.005, paths 0.010
unless I borked something up
when I take care to run only one OpenGL program at a time, I can't get ovl max over 40us
jmkasunich: .003*600 is only 1.8 pixels wide, maybe that's still just too small
but, I don't think I see any change at all
firing up the other PC...
cradek: are the arrows better?
on this one, or should I download a new one?
it looks like the section lines wound up still at 0.000 (pebkac), but they arrows are now 0.003
no, the arrows are no better
the one you already have
right, no better
ok, I'm gonna make one special just for you, stand by
argh clicking "+" is still busted in AXIS on trunk
I could have sworn I tested it after the last round of fixes
jepler: let's test that in 2.1 soon too
DO NOT WANT
cradek: refresh and try again
21:13:09 ERROR 403: Forbidden.
fsck, hang on
I also told pdf995 to do 1200 dpi, not 600
this has good arrows
it can go up to 4000 ;-)
all the lines, even .003, are fine
I think I changed the arrows to 0.004
but I bet the real key was exporting at 1200
the .003 is nothing like the invisible lines you had before
I don't think my printer is 1200, pretty sure it's 600
is there a decent contrast between the section lines and the part outline?
or should I shrink those back down to 0.003
I would not make the arrows any lighter
your 600 dpi printer probably does the best it can with 1200 dpi data, but if you give it 600 dpi data the infomation isn't there at all
if you want the part outline to stand out above all else, make it wider
I want three levels, section lines, part outline, and toolpath
maybe the section lines should be 0.003, but the arrows, etc, should be 0.005 like the outline
I think a thicker tool path
guess it doesn't hurt to try
at least as thick as those circles
(the circles seem thicker)
the arc circles are toolpaths, 0.010
ok must be the shape that does it then
refresh and try again
0.012 paths, 0.005 tool circles and outline, 0.004 arrows, 0.003 section lines
and 2400 dpi output (which is what I did last time, not 1200)
I'm not sure I see any difference in this one
I'll do another photo, hang on
I was aiming for section lines thinner, tool paths thicker
but it may be down in the mud
why does this code always get more complicated when I try to fix it?
what are you "fixing"
now I discovered the case where you: start X jogging with the mouse on the "+" key, then press "Y", and hold "-" to start that axis jogging
now, press Z and then release everything ...
and the machine runs out the door and down the road
[02:31:27] <cradek> http://timeguy.com/cradek-files/emc/DSCN6319.JPG
pardon my photography skills
well, I think I can live with that
I wonder if I should bump the toolpaths up to 0.015?
re the text
left justify it?
yes I think so
ok, I'll see how that looks
I need to see if theres an easy way to import text
for the area below - O words and expressions
do you still have that text I wrote?
has anybody tried seeing if the front page will pack two to a page, and is proportioned correctly?
or are we gonna leave that to the printer?
we also need to make sure there's room for a punch hole - hence the space above the comp figure
I printed the front page at the right size
is there space for a hole in the top left?
top right would be better, everything is left aligned
looking for my file...
damn, that makes it top left on the back
I could swap the arc and comp drawings pretty easily
part of me wishes both files were coming from easycad, so I'd no that everything lines up
[02:38:13] <cradek> http://timeguy.com/cradek-files/emc/gcode.ps
umm, how does the justification have any effect on the hole location?
the whole thing is rectangular
there's useless space at the right
or are you thinking to punch right thru the table
there are critical things on the left
I don't see much choice actually
(I'm not sold on us needing a hole)
to be honest, neither am I
when I view that .ps, the aspect ration does NOT make it fit nicely on a half sheet
argh -- now, key repeat on the "-" and "=" keys is causing repeated incremental jogs
I just can't win!
you and me bot
jepler: how did you print that on a half sheet?
cradek: mpage -2 -somethingelse
I bet we could send this file as-is and they can scale it onto the paper
they've got to be better at that kind of thing than we are
I'm not so much worried about their skill as about our ability or inability to communicate what we want, and the resulting "oh shit" when we see the finished, laminated, and not cheap result
that's easy to deal with--just blame stephen and stick him with the full bill^U
it seems like a simple job - two sides, it's obvious which way they should be oriented
they ought to be centered
I mean how hard can it be?
and failing that, I like jepler's plan
with the heat of a thousand suns I hate GUI programming
I had a plan?
I deny it!
logger_aj: format C:
would a good web page (s) be better than a printed handout?
tomp2: you can't put a webpage on the machine - laminated reference card is grease resistant
well, that's good too, but this is better
both is best, and thats what we're gonna have
actually you can put a webpage on the machine - we do
since the PDFs will be online
silly Q, is it EMC2 or EMC-2
I think it's EMC2
so do I
it just looked a little funny on paper
I think I'm about done as AXIS maintainer
that's ok, since it's about finished
either that or 2.2 will remove about half the different ways you can jog
cradek: I can't seem to find the O-word / expression stuff
darn, he's hiding
hijmk. I'm in for a sec
hi <space> jmk :)
I just opened the pdf you sent me
try this one
[03:40:53] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-back.pdf
(thats old too, but its newer than the one I sent you)
ah - now I get it
I wasn't understanding the "comp off" label on the outside comp example
it looked a little bit like the word "start" went with "comp off"
ok, lemme check the layout - I've moved labels around some since then already
for the arcs, would it make more sense to just label them "R > 0" and "R < 0" instead of R+ and R- (with the key below)?
yes, excellent idea
maybe use a comma: "G2, R > 0" ...
the oword stuff was on pastebin, looking...
I need to hit the sack - I didn't get to bed at all last night.
If you have something you like, I can send it to Janet tomorrow morning
or if you like, you can send it directly - winooskipress at verizon dot net
(I can do it though, so don't fell you have to)
I'd rather let you do it
do you already have the front page?
sounds good. she knows me :)
err - no
thats kinda important
the G-code ref is on jepler's site?
[03:50:33] <jmkasunich> http://axis.unpy.net/files/01142603825/gcode.pdf
and that's this: http://linuxcnc.org/docs/2.1/html/gcode.html
the pdf is probably more printer friendly
no! that's an old one
[03:51:08] <cradek> http://timeguy.com/cradek-files/emc/gcode.ps
the unpy is old, the linuxcnc is newer? (I hope ...)
oh - then the wiki shouldn't be pointing at it
well it's the 2.1 version
I thought I had fixed that link
err maybe not I dunno
too many websites
ok, which one were you saying NO at, the html, or the pdf?
so the ps is the one?
that's the most recent one I made from cvs
I have no idea if it's in a useful format, but it fills a page nicely
unfortunately, I can't seem to view it
print shops must be used to postscript
to be honest I like the formatting of the pdf better - those gray and black bars aren't so nice
SWPadnos is probably using doze, I couldn't view it with my doze machine either
the gray and black help to read it when it's wide
my version of Corel Draw is very old, and I only get a rectangular box for the region
OOO does the same thing
yes, this is a doze box
and Acrobat doesn't read it either (!)
I think we really want a pdf
I have Ghosescrript - let's see what that does for me
well, it was pretty ugly
[03:56:02] <cradek> http://timeguy.com/cradek-files/emc/gcode.pdf
aaaahhhhhhh - much better :)
thats the ticket
mostly OK. the strokes are a little heavy
minor quibble - the tops of the letters almost touch the top of each "bar"
so the ones that are just below the white-on-black bars look kinda bad
I hope it'll be ok printed
I don't have any clue how to doctor it, and we don't really have time anyway
maybe the print shop can do some magic?
* jmkasunich goes back to working on the back side
jmkasunich: did you see http://timeguy.com/cradek-files/emc/operators
I wouldn't expect any magic from the print shop for such a small run, with all the extra time we're leaving for them to do the job ...
saw operators, oword I only saw the pastebin
I copied it so it's more permanent
same thing tho?
I'm tweaking a bit, trying to shorten the few longest lines
SWPadnos: I'll be happy if they get the stuff centered on the page and they don't clip off any edges
cradek: how did you do the ps -> pdf conversion?
hmm, no logical NOT?
well, it looks good, and I'm too tired to think about perfect. I'll send that one off for the front if I don't get something else by morning-ish
there's a typo on the quick ref
in the (DEBUG,...#123 ...) line, the word "like" is duplicated
I'm looking at the devel/HTML docs on linuxcnc.org
cradek: how did you do the html to ps?
[04:05:41] <SWPadnos> http://linuxcnc.org/docs/devel/html/gcode.html
don't just say "firefox"
print to a ps printer driver
I twiddled settings in the gui for 15 minutes, and then magically it printed on one page
or save as HTML, the load into OO as html and click the pdf button (which I'm about to try)
so I could maybe tweak the html (slightly smaller font, fix the typo) then run thru the process to make the ps and pdf
* jmkasunich is a perfectionist, and stays up late
heh - me, too. I've been up since Sunday morning ;)
but I'd rather work on the back page, so please, try OO ;-)
I started work at 6:30 today - I really should go but I hate to stick you guys with this
so I've passed the perfectionist stage tonight :)
that "(index -1)" should be removed too
in (...) there's a " missing
OOO isn't all that nice for viewing, but it may do OK for editing
thanks guys, this will be great if we/you can pull it off
jmkasunich: when you're our age you'll understand
I'm past there, and you know it already
turned 45 on sunday ;-)
happy birthday. bummer for you :)
my nephew turned 4 today
(the local one anyway)
I'd sure rather be 45 than 4
maybe the geometric mean or something
see - now there's one of those funny things I don't remember. I remember the name, but I'm not sure I remember what the geometric mean is
sqrt of the product
well, that's no good then :)
so, looking through the reference, I see another little nit to pick
13's better than 4
the "plane selection" description should have pairs of dots, not triplets
or hyphens, or the word "through"
somebody, please edit the html, don't just announce what you've found
I'm editing it in OOO
the toss it on pastebin, and I'll see what I can do
hopefully it'll be viewable in FF afterwards
did you get my two fixes?
or whatever it is that does the colors
the headers aren't inverted, if that's JS
it isn't showing up right, but I'm hoping it won't be broken
I recommend editing the .html in cvs
I bet any gui editor will surely toast it
yep - it's borked by OOO
is that HTML autogenerated or is it in CVS?
I fixed those two things
ok, the two you found plus link link?
err - like like
jmkasunich: you might be able to monkey with border-top in the css if you want more space
ok. the ellipsis thing isn't an error, and it is shorter
it uses … whatever that means
jmkasunich: to print it, you have to turn on "print colors and stuff" checkbox in the print config somewhere
that "colors/backgrounds" checkbox is in the page settings dialog
good night again from me too. thanks for sticking with it
SWPadnos: so where are your edits?
cradek did them in CVS
did cradek fix them, or do I need to read back
ok, didn't know if he got them all
I didn't change anything other than the extra like, and the two he noticed
sure. I don't know how long it will be before the docs are updated on linuxcnc
all I care about tonight is the pdfs for the printer
night. enjoy :)
if we're gonna immortalize things in dead trees wrapped in polymerized petroleum, I want it right
yeah, otherwise they're just fun to write on with a grease pencil ;)
remember the punched hole too. the g-code ref doesn't really have room (unless it's on the relatively unused top right side)
yeah, I swapped sides between the arc and comp drawings, so the top left has some space, that will match up with the top right
are you gonna have the printer do that?
that's included in the $28.00
on card stock, even
what size hold in the paper? (laminate hole will be smaller I assume, so there's a seal around the ID)
I'm not sure. I suspect that 1/4 and possibly a slightly larger one are the standard sizes
I can draw a circle and put "punch here" in little letters inside
if they want 1/4 in the plastic, that needs maybe 3/8 in the paper?
yeah, though I'm not sure it really needs a full 1/4
fsck I hate last minute swirls
with insufficient information
and I don't think the quote includes drilling after lamination, but I think that's pretty cheap
ok. the phone is plugged in, the junk from my pockets is on the desk. I'm really going to bed now ;)
good night, Alex :)
figured your handout yet?
trying to figure out how to explain O-words and expressions in 20 lines or less each
any place to see the progress?
[04:42:42] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-back.pdf
some hours old now
[04:43:00] <jmkasunich> http://jmkasunich.dyndns.org/pics/operators.txt
[04:43:07] <jmkasunich> http://jmkasunich.dyndns.org/pics/owords.txt
current work, will go below the drawings
I'm not at all happy with the text yet
I watched your conversation a bit.. what are you using to generate the pdf?
two things going on at once
swp and cradek were messing with the front, which is a PDF of the g-code quick ref that jepler did a while back
.html -> firefox print -> .ps -> ps2pdf -> .pdf
I'm doing the back drawings, easycad print to pdf
was wondering if I can help with layout & graphics
but I don't have easycad
the graphics are about done - the version you see is before I did a bunch of cleanup and arranging
anyways, it seems your doing a nice job anyways ;)
I need to get the oword and operator text to be 1) correct and 2) usefull
* alex_joni goes to get ready for work
maybe you can mail me the stuff when you're hading for bed, I'll try to work on it during the day :)
[07:10:15] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-back-single.pdf
[07:10:25] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-back-double.pdf
send them both, let the printer decide which one to use
[07:16:15] <jmkasunich> http://jmkasunich.dyndns.org/pics/gcode-ref-front-single.pdf
I'm less than thrilled with the front, we'll see how it turns out
I'll email them too
jon elson's commit of the ppmc.ini file puts back this claim that "EMC always overwrites (OUTPUT_SCALE) on shutdown"
I assume/hope he did not mean to do that
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-06-05.txt
my god. I can not believe how fucking stupid Adobe is
and akamai - they're at least as bad
like you need a JAVA APPLICATION TO DOWNLOAD A FRIGGIN PROGRAM!!!!
and more than that, one that gives you a nice save dialog (with dir tree and stuff) that looks exactly like the standard windows one, but IT ISN'T THE SAME - IT'S A STUPID JAVA APPLICATION!!!
not that I'm frustrated or anything
SWPadnos: try getting a newer logitech keyboard
freaking drivers are about 50MB updates
cause they are done in java
I have that problem with my old Matrox video card
you need .Net, of course
obviously I don't
of course you do!
oh great. now that I've suffered through the excruciating download and extraction process, I now need to close down basically everyting running because acrobat setup wants to change some shared files
I think it may be better to just pay the printer to fiddle with the PDF pieces
* alex_joni uses PDFCreator
free and decent
I'm trying to take two separate 8.5x11 files, and scale the contents so it's readable on a half-sheet, and put them in the same file as 2 pages
I think also that the G-code quick-ref table should be split into two pieces and stuck next to each other (but the table needs to be narrowed a bit to make that fit)
alex_joni: bah don't mention pdfcreator to me
I just installed it yesterday, and if my sysadmin hadn't been looking over my shoulder when I did it, it would have installed some spyware "toolbar" for IE as well
fuck them if installing spyware on my computer is the way they think they can be paid for their GPL software
hmm.. didn't happen to me
but then again I don't use IE either
then what makes you think it didn't install it?
you have to scroll down through a list and uncheck it if you don't want it
I think I did that
in the license window where you're forced to "agree" to the GPL (which is contrary to the GPL), they have the shitware license appended
" Some software packaging systems have a place which requires you to click through or otherwise indicate assent to the terms of the GPL. This is neither required nor forbidden. With or without a click through, the GPL's rules remain the same.
I think it's entirely possible that they're within the letter of the GPL, but that doesn't mean that their practice isn't unethical
arrgh I tried to head off the editor thread, with no success
nano is missing from that thread
and 172 others :D
cradek, u there?
hey - so I brought the stuff over to the printer today. it looks like they can laminate with an extra inch or so of plastic on the top edge
I thought that might be good for the lanyard hole
is there any easy way to upgrade an ubuntu distribution without breaking the kernel/rtai/compiler dependencies?
upgrade like to 7.04 or something?
the package support on dapper seems hopelessly out of date
I don't think there's any way that would count as "easy"
I'm tired of having to build from source
build stuff like what?
cmake, qt, etc.
lots of dev packages
I guess firefox is old too, among other apps
all the newer packages from feisty use newer libs
seems like the only solution is to dist-upgrade or keep building packages from source
yep. I think you'll have trouble
which is a pain
it may be the lesser of evils to have to recompile the kernel/RTAI/EMC2
does cradek have a feisty kernel package ?
rather than everything else
not that I know of
yeah, that's what I'm thinking
I think we'll be trying some things with the kernel/RTAI at fest. it may not be reasonable to keep with 6.06 until 2009, when desktop support ends
it's a nice idea to use the LTS version, but it may not be realistic
yeah, I think it's already seen its usefull days if ubuntu don't make newer packages available
it's still quite useful for the average user (and they're still doing security updates)
but for someone who's trying to push the envelope (possibly by writing new envelopes :) ), it's getting old
petev: if we are going to support an additional version of ubuntu, such as 7.04, what we need is a developer who is going to be using that version, and take responsibility for stuff like building each new released version of emc into a deb.
petev: would you like to be that developer?
(of course the kernel and rtai package too)
(and a live CD would be nice, but not essential...)
jepler, I'm not an expert at building debs
hmmm. I wonder if I should get some extra SATA drives so we can experiment a bit with my big machine
if you can give some guidance, I don't mind doing the work
SWPadnos: I could bring some scsi drives
I can bring a SCSI controller, so that could work
I can probably give it a go in a couple of weeks
as long as they're >4G or so ;)
but is 7.04 something fixed?
or should it rather be 7.10?
actually, I can bring a dozen or so SCSI drives as well, so don't worry about it
petev: I also don't feel like I know much about packages, particularly kernel packages. however, using cradek's old instructions I was able to succesfully build a realtime-enabled kernel of my own: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UbuntuBreezyPackages
section "Rebuilding linux-image-2.6.12-magma and rtai-modules-2.6.12-magma"
(though I applied those steps to building a 184.108.40.206 kernel on a 64-bit machine)
I'm ok at building kernels, it's more the stuff in the debian dir I really don't know yet
petev: the most frustrating thing about building the realtime kernel is not getting it to work on your machine, or getting the output to be a .deb that works right -- it's making it work on nearly all machines that is difficult
so making up all the packaging info is the problem
petev: in that case, I think the UbuntuBreezyPackages page will get you the rest of the way there
how were the current kernel pakages tested? or were a lot of things just enabled as modules?
we made the minimum changes necessary, starting with the ubuntu config
petev: a few weeks (maybe even months) of iterative testing with the help of other people on IRC
ok, I guess I can diff the configs from the current kernel and see what's going on
"nope, that one also hangs my computer at boot every time"
(1 hour passes) "OK, try 2.6.12-magma-cjr13 from the same website"
sheesh, I wanted to spend my time on new stuff for EMC, but old packages are getting in the way
guess I got lucky
it seems like supporting a new kernel will also take some time to do it right
I only got to -aj4
with another 4-5 unpublished versions
petev: perhaps it helps you understand why we don't jump to support 2 new ubuntu versions per year
what about having a new package just for dev work? we do need a way to test/build new stuff for future releases
petev: you can run sim on most any ubuntu
I don't mind building a new kernel and rtai, that shouldn't take too long
I don't understand what you're working on that needs the bleeding edge of any library
petev: I agree that it shouldn't take too long
I think it would be a bad idea to make emc depend on any bleeding edge library
cradek, you can't even install a newer qt than 4.1 on dapper
pete does other development - it's not necessarily EMC that needs the latest and greatest
but supporting users switching from dapper to feisty will be a nightmare
I will veto any new major component that won't run on systems 1 year old (dapper)
(I don't know anything about qt versions)
the packages available for dapper seem quite out of date
I think more than 1 year old
6.06 - exactly one year old ...
it's not the kernel/dapper itself, it's the packages available
SWPadnos, I mean thepackages are older
the entire emc 2.2 release cycle will run on dapper and maybe also something newer
if putting features in 2.2 is important to you, you/we will have to figure out how to target dapper
hmm, I have been building many packages from source because the ones for dapper are too old
we're talking past each other
and I have to go
it's wasting so much of my spare time, I can't get the real work done
* alex_joni heads to bed too
good night all
petev, is your aim to use an EMC-capable machine as a development station for other things as well?
SWPadnos, what are your feelings on this?
or are you saying that you need newer versions of packages for EMC-related development?
no, that is not a big concern
I know I'm pushing the envelope with some stuff
maybe R&D type stuff
well, I'd love to have a kernel/RTAI set for newer versions of Ubuntu
but dapper packages are hopless
but cradek seems dead against anything that won't run on dapper
we used to support 2.2.x until a couple months ago
I'm having a hard time thinking of something for EMC2 that would require QT 4.3 instead of 4.1 ...
all the newer ubuntu packages require newer libs, etc.
there are many new calls added in qt4.2
cradek is dead set against anything that can't be used by someone with a <1 year old install
some are essential for basic QTextEdit stuff
and newer systems can't run QT 4.1 programs?
Qt4.1 is too old, doesn't have the methods
that wasn't the question :)
the newer Qt packages can't be installed on dapper
why would you want to run an old qt on a new system?
what I'm wondering is if the end user needs something that must be compiled with the newer version
and also whether the code can be written to work on multiple versions of QT
well I guess you could tyr and link all the libs statically, but that seems counter productive
(note some of the GTK shenanigans in the UI code)
there is a huge diff between qt3 and 4
dapper has qt 4.1 in univers, but only 3 in the official support
ok. I thought you said you couldn't install anything past 4.1 on dapper (was that supposed to be 3.x?)
of course, libqt3 is already a package that is not on the live CD
and trolltech don't seem too concerned about backward compatibility
anything that grows the required set of packages by much is also problematic since we've made it a goal to fit on a live CD
that would be a black mark for using their library
(I Understand it looks nice and people are used to it, so that's a potential problem)
well it does build nice GUIs and with a proper widget set would allow the users to use designer and make their own
that's definitely a goal I'd support :)
that's one of the things I have been experimenting with
I even tried to code it a couple of years ago, but didn't get tto far
I have basic functionality now
(actually, several of us made a small attempt)
but still need to develope widgets
* alex_joni even has a lib like that
heh - it's probably the same one :)
although I don't know what license it's under
SWPadnos: it's a recent one
I have a pretty complete qt/nml lib
was that you me and Paul?
SWPadnos: no, this is 2006.11
no, it is much more than what paul had
it's for qt 4.1.4 it seems
pauls was for qt3
if qt4.1 is available in universe, that must mean that it's possible to compile 4.2 for dapper as well
clearly all things are possible :-P
sometimes it's in some not-very-useful sense
yes, I have been compiling packages from source
but it's a paing and doesn't make it easy for anyone else
ok. so the thing to do may be to maintain a qt4 package for dapper, at least until the one in universe gets to 4.2
or the one in backports
the one in backports won't install
it has a bunch of other deps
* alex_joni really goes to bed now
is there a 4.2 in dapper-backports? did you report it as a bug that it wouldn't install?
I'll have bad dreams from tolls & tech
(I looked here but didn't see it: http://packages.ubuntu.com/dapper-backports/allpackages)
I tried several packages from backports, I thought I tried qt also, but maybe that was from edgy or fiesty
I know the bacport cmake would not install
I'm running this command now, I'll let you know if it works: sudo apt-get install cmake=2.4.3-1ubuntu1~dapper1
(after enabling the backports repository, which I hadn't done yet)
I got a bunch of need to install version XXX but veriosn YYY to be installed
huh it worked for me
Unpacking cmake (from .../cmake_2.4.3-1ubuntu1~dapper1_i386.deb) ...
Setting up cmake (2.4.3-1ubuntu1~dapper1) ...
% cmake --version
cmake version 2.4-patch 3
let me try again, Ill remove one I built from source
petev, adding features (specifically a UI design kit) is great. requiring an OS upgrade for existing users is to be avoided if at all possible
I think that's the source of the resistance to feisty-dependent packages
I agree, but I keep hitting the wall with old packages
is it the case that you can't (you being "a programmer") write a qt3 app and have it compile with qt4?
actually, that's an irrelevant question
qt4 has some legacy qt3 support, but it is not recommended to be used in new apps
I should have asked about 4.1 vs 4.(something > 1)
ie, can you (as the programmer) use only 4.1 features, and still have it work when compiled for 4.2?
yes, there is some missing functionality in the qt4.1 classes
ok - that's a separat question
they have added it in newer versions
speaking of the author of the most recent new GUI, it's quite possible for that GUI to ship separately from the main program, and not even run everywhere the main program runs
I don't know ehough about the qt libs to be able to gauge how much of the code would be duplicated within #ifdef QT41 constructs
arg, there is no make uninstall target
later, when the distributions have moved on and enough people in the community want it, it will be time to integrate it
if I could see a way to do it easily in 4.1 I would just do that
yep, that's another approach
petev, ok. not a problem. I'm just trying to separate what's required (for the new software) from what's desired (by you :) )
* jepler -- ever the masochist -- starts a "dpkg-buildpackage" on his dapper machine inside qt4-x11 source from feisty
petev: any idea how long this will take on a 1.5GHz machine?
ooy, that takes forever
* SWPadnos thinks it might not take too long on the dual Opteron
a long time
took a few hours on my machine
hah, cmake unistall worked
bah -- uninstall
petev, do you suppose we can have a look at the code you've got sometime next week (during Fest, where we can talk about it :) )?
"I think every package should implement its own shitty packaging system"
yeah, that's what I meant
you remember fengli from the lists?
she is working on the GUI, I just tried to help with all the qt/NML library and some custom widgets
cool. I guess we may see it there anyway then
she had several problems, and it seemed that 4.1 just didn't have the functionality to get around them
she in using 4.3
so even the qt version in feisty (4.2.3) isn't good enough?
no, I think it probably is
it looks like most of the stuff was added in 4.2
in a few hours, when my laptop's fan is stopped again
well, it looks like gutsy <whatever it is> will have 4.3
jepler, this is what I ran into when I last tried cmake
[22:14:01] <petev> http://packages.ubuntu.com/dapper-backports/devel/cmake
but it looks like it's installing now, so maybe these dependant packages have since been added
is there a feature of cmake that is required, which gnu make doesn't provide?
cmake is totally different
it is a cross platform make
I understand it's different, I'm wondering if it's required :)
I wanted to experiment with it, and was looking at some examples
in the qt3 days, qmake would generate normal makefiles
they all seemed to be using some new stuff that was added in 2.4 or something around there
yes, cmake was not for qt stuff
qmake does still generate normal make files
ok. so that's a related issue, but not directly part of emc development concerns
which I still haven't wuite figured out how to integrate to the EMC Submakefile ;-)
yeah - I'm sure it's set up for recursive make
it was for EMC, just not for the qt stuff
yes, I was getting a bit upset with the current make system at the time ;-)
it's already necessary to install build tools to compile EMC2, so adding another one may not be a killer
the only problem with the current build system that I know of, is that nobody else understands it
trying to convince people to move over from gnu make would very likely result in some lkillings ;)
heh - that is a problem ;)
this is nothing I'm advocating we do, I just wante to experiment
I'm convinced that it's better though - build times went way down and it seems a lot better at deciding when things need to be rebuilt
the main problem I have is that it's not heirachical
do you mean recursive? For the most part, each Submakefile is concerned with items in that directory and below.
yes, each node is not dependant of parent nodes
that's true in general for recursive make as well - the lower level makefiles often depend on variables from higher level makefiles
I've not run into much issue with that, it's usually only the target var
jepler, is it reasonably accurate to say that the current make system effectively "includes" submakefiles (internally generating a single flat map of the build), rather than doing separate builds within subdirectories?
that's my understanding
yes -- and I think that each Submakefile has rules about similar targets to the ones the corresponding recursive Makefiles would have rules about
the only difference is, with the non-recursive system you can always get a fast and correct build from the top directory after you modify one or a few source files
is there a wiki page on how to use the current system?
with a recursive system, you get a slow build if you 'make' at the top directory (and often an incorrect build if you use -j)
-j really flies on EMC2
especially with several fast cores
petev: to use it? You type "make" in the src directory. There is a Submakefile.skel that talks about common operations in a submakefile. There are comments in the top-level Makefile that clarify some things
how to use it from a developers point of view, I think he meant :)
the philosophy behind the makefile system is described in the paper "recursive make considered harmful" http://miller.emu.id.au/pmiller/books/rmch/
not to run it, but to write Submakefile, something that describes the vars that are used, etc.
ok, I'll read that
really leaving this time...
heh - fan still running?
lap very hot
you know, it's really amazing that hard drives cost roughly $0.25 a gigabyte these days
even less, for some drives (like a 320G for $70 - roughly 22 cents/gig)
I remember when $1 meg was good
$80/meg when I was in high school
now it's less than $80 for 320G, delivered :)
we have info about a really old HP hard drive on the wall at work
$5000, 10MB or something
qt still building :-P
and nobody even bothers with enough decimal points to accurately resolve the entire old drive capacity
hmmm. should I get the 320G, or the 320.01G drive? decisions decisions ;)
jepler, I remember those old ones (not as a professional though - I'm not that old)
give or take a GB - who cares :)
a few of us went to a bank to remove one of those old drives (I think it was DEC though)
it was still several hundred pounds after we had removed lots of parts (inlcuding the disk packs)
I remember when they used to rate the hd by what the double spaced amount was.
heh - yep
and in the really small print was the actuall hd size :)
it's like tape drives today
130GB COMPRESSED CAPACITY
right - but until recently that was a pretty good estimate. 2X compression. But with us - the art files we use have pretty decent compression already. So we don't get much over the native capacity.
mostly illistrator files.