man I really need to figure out why latex2html craps all over some of those very nice images in the documentation
maybe that should go on the task manager...
[03:41:50] <jepler> https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=133070&group_id=6744&group_project_id=46285
SWPadnos_ is now known as SWPadnos
[Global Notice] Hi all. You may have noticed that services is currently offline. We're working to restore it quickly; however, if its downtime necessitates assistance, please feel free to contact me or any other on-duty staffer ( /stats p ). Thanks again.
I requested that gmane pick up the emc lists, and it appears they have begun to archive the posts. http://news.gmane.org/gmane.linux.distributions.emc.user
they have a process for incorporating old archives in mbox format; we should figure out who has the most complete one and go through that
that sounds good but emc isn't a linux distribution
that's not the group name I requested
* jepler shrugs
I wonder if there's any chance of fixing it
I don't know
[Global Notice] Hi all! Services should be back up and running. If you notice any issues, please contact an on-duty staffer ( /stats p )
Lerneaen_Hydra_ is now known as Lerneaen_Hydra
SWPadnos_ is now known as SWPLinux
hmmm. so, readline is a little bit random sometimes
I noticed in halcmd that just pressing return will re-use the last command
which of course isn;t so great if you just press return after loading halcmd, since there is no last command
yeah - though my initial analysis isn't correct
I fixed the problem for the initial <enter> case
readline always returns an initialized pointer, so you get a non-null pointer to a null string if there's no input
is it a feature that the previous line gets re-executed if you press enter?
useful for "show pin yaddayadda"
not so useful for "loadrt threads ..."
I guess the qquestion is, should I try to get rid of that feature? ;)
I think the feature is worth the inconvenience(?) of not being able to hit enter willy-nilly
I'm trying to think of what it hurts to leave it
ok. I can check in the fix for the "first line" problem
yeah definitely fix that
when the cat walked between me and the screen, I clicked the window to try to raise it above the cat
did it work? ;)
luckily, I'm wearing cat-colored pants right now
they always end up that way, I guess
this cat has both white and black fur, to make that impossible
ok, now this is weird
I haev a fixed version of halcmd, but if I remove the debugging prints, it's no longer fixed
literally, add 2 sets of // to printf lines, and it's back to being buggy
nice bug list in the readline man page:
"It’s too big and too slow."
hmmm. well, it seems I was able to fix both problems at once, reagardless of whether I want to or not
ok - it looks like that's the correct fix, since he old behavior isn't really to repeat the last line
it actually only uses the first word on the line, and uses all blank parameters (so "show pin blend" becomes "show", and "loadrt foo" becomes "loadrt")
hmm, that's not very useful
gdb repeats the whole line
the real problem here is in the tokenizer, I think
the line doesn't get reused, but some of the tokensend up with the previous values
arrgh, I don't know how much time I've spent tracking this "interp bug" only to find it's in AXIS somewhere
which one is that?
the first motion after an O code has the wrong sequence (line) number
aren't sequence numbers independent of line numbers?
I don't think so...?
ie, a loop will have increasing sequence numbers, but still execute the same lines
no, the sequence numbers loop too
hmmm - is that the right thing to do?
depends what a sequence number is
I thought the sequence number was an NML thing, for identifying the command for status/response reasons
emc uses them to say 'the motion right now is because of line XXX'
no, that might be a different thing with the same name
serial number maybe?
ok - it's probably my assumption, not any documentation or anything
argh. pointers(/strings) are totally confused in halcmd
I don't think I want to fix it right now
you guys are starting to scare me now.
why's that rayh?
because normally we look like we know what we're doing?
Nah. I know you guys know what you're doing.
I'm really impressed with the recent work. Great stuff.
oh god, we've still got you tricked then
Yep and I plan to remain that way.
btw I talked with alex_joni a bit about a qt4 lib.
Got a guy in the philippines(sp) working on one.
If there is any interest here I believe we could get it lgpl and into the repository.
a lib of what?
emc related commands.
built into qt's signals and slots sort of thing.
is it a NML<->qt interface of some kind? like emcsh?
* alex_joni just came in
finished reading back
the gangs all here
rayh: so the question is: do we want the NML<->qt lib in emc2 under LGPL
or leave it to the guys who developed it (still LGPL because they need to use the emc.hh)
That's about it.
well .. it can be usefull at some point I guess :)
how bad would it be if we do it after 2.1 ?
It could also be thought of as cluttering up the repository by requiring one more dev.
it's not the cluttering.. but it adds to the dependencies
and it will be a bit of work to get it right (configure & co to search for Qt)
IMO the machines using it will be out about the same time or soon after as 2.1 is released.
so if it's going in it should be before 2.1
Well it's not necessary to include with emc2.
I wonder if a gnome-related lib would be more appropriate, considering that ubuntu is gnome-based
not that we can decide for them what they want to do :)
you mean gtk ?
yeah, kind of
more like "gtk controls that know what to do with EMC/NML"
like swp I'm a little sad to see reliance on another new toolkit (lerman's doing this too)
like my dad making fun of my mom for buying all the different ziploc bags: "I think there's a size you don't have yet"
cradek: we can do this using suggests
so only people who install it can use it
that's a packaging issue, I thought we were talking about putting it in our source tree (and compiling it)
IMO there are significant advantages to the qt toolkit.
That is why I suggested it to the customer.
there are some, but aI don't know wnough about gtx+-2.xx to know if there are equivalents
It's not a question of the size of the bag it is the double lock zipper that makes the difference.
argh - ignore typos, please ;)
yea me to, what he said.
would this require I install a bunch of qt/kde stuff to build cvs emc?
cradek: not if we mark it optional
or do modern systems have all of it already?
alex_joni: you mean with configure or something?
and not build it if the required isnt present
ok I see
if you intsall even one KDE program (like Kate, in my case), you have pretty much everything you need
_can't_ demand that people have all that stuff though
jmkasunich: I totally agree
not to compile something that only 10% of less of users will even want
I agree with jmk on that
we don't require Gtk now.. and it's very usefull for halmeter & scope
ok I see how it's the same as the scheme we already have
has anyone verified that you get a usable EMC without gtk?
(obviously no halmeter, scope, or CL, but can you use the rest?)
I did at some point
one problem with qt is that any apps created with that toolkit won't have the same look as the other GUI emc apps
but itmight hav emorphed a lot since then ;)
SWPLinux: show me two emc apps that look the same :D
halmeter and halscope have the same widget sets
We have some issues with different look and feel between the guis now.
SWPLinux: still.. worlds appart
I don't think that matters really
the only one I can think of is xemc & tkemc ;)
still different toolkits
and backplot - don't forget backplot
anyways.. that's a sideissue
I think my opinion is that if we can help/coerce/nudge a vendor into making part of their software free, we should, because partially free is better than not free.
I'm pretty certain we don't want to buy into qt the way kde has.
Although a customer might want it all to be qt.
alex - was it you who was collaborating on the qt toolkit with Paul and me?
I also want those vendors' customers to be able to eschew the non-free part of the software as much as possible (for instance, they might decide to use AXIS)
That would not happen.
ok - must have been anon or some other "a" person :)
Certainly a sherline customer can use axis. I believe quite a few do.
I have the basis for some qt controls that know what to do with NML - such as a position readout that attaches to an axis
I was working on an axis control, with jog buttons, readout, homing stuff, etc.
I meant AXIS as just an example.
Is it a bit like the old vaporgui that I put up in the dropbox -- back when we had one.
but working with Qt was a pain, and it wasn't clear how to make the components usable in a user-designed layout (using Qt Designer or KDevelop)
Sure I understand, Chris.
oh yeah - alex - should we restore all those dropbox items? :)
The qtdesigner is what the current library is aimed at.
SWPLinux: working on it already
* rayh answers for alex -- no
uh - withe rway :)
rayh: I have it locally
I don't know what vaporgui is/was
a misty interface
* alex_joni guesses
vapor.tgz, 75059 bytes, March 15, 2005 :)
Back in the day when paul was threatening qt I wrote a display using designer.
I put a screenshot on the dropbox.
ok - that's around the time we were working on the NML-aware controls
That is a nice concept. NML-aware controls.
Or a nice way to describe such things.
yeah - partly for the GUI designer thing that Robin keeps harping on
rayh: I see a vapor.tgz is that it?
Seems like that is what I called it.
wow - what's in the 32M file "mazak-atc.tar"?
Alex: I can transfer those directly to DH if you like, unless you're doing that already
SWPLinux: all kinds of information about mazak
that's big enough for a full kernel, or several copies of the emc source tree
mazak-atc.tar contains a crapload of pics that tomp took
wires & pinouts & schematics and all
ok - pdf or image files and the like
SWPLinux: I copied most of the stuff, left out some big files
in 5 minutes maybe you can put the rest (I assume your connection is faster)
ok. I'm not worried about space or bandwidth. if you think it may be useful to have them there, stick them on
I'd just wget from a DH login
the dropbox is available on metalwroking.net again
heh.. good idea.. forgot the old page is online again
you found the dir I made?
interestingly, linuxcnc.org is up to ~15G/day of transfer
are there live-CDs in that mix?
that's quite a bit
only one ;)
plus ~3.5G/day at cncgear, which has some BDI ISOs still
seems like quite a ration (15 vs. 3.5)
it's only BDI on cncgear, and I think there are other mirrors
the bdis at cncgear are rather old aren't they?
no, I think 4.50 or 4.52 is on there
[23:25:16] <alex_joni> http://www.linuxcnc.org/dropbox/emc-man3.png
rayh: was that it?
ok - it looks like the transfer from metalworking will be done in a minute or two
unless his server chokes first ;)
well guys.. if there's nothing else.. I'll head for bed
getting late, and I'm travelling tomorrow to a customer