(A) it's happening in linux, so it shouldn't (B) but if you have measurements I won't argue with you
I don't have measurements
oh I see -- "why ain't it there" is the question?
* jepler_ reads his e-mail
but I do have experience with other filesystem-related things causing problems (notably kjournald)
heh, yeah - I'm assuming it was left out for no apparent reason
"less cluttered/bloated" and all
I assume it was an accidental omission
yeah, not one I'd expect us to be concerned about
I'm not sure I'd add it to our RT kernel, but he can certainly compile his own if he likes :)
EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder_gtk.c: Add cofirmation box before quitting
EMC: 03cmorley 07v2_2_branch * 10emc2/src/hal/classicladder/classicladder_gtk.c: Add confirmation box before quitting
jepler_ is now known as jepler
how's it going up north?
my crazy cat is trying to eat the mouse pointer.
jmkasunich, you don't need to re-sort the name list for aliases
keep the alias list sorted, and do an on-the-fly merge sort when you traverse the list
the only snag there is that you skip any item in the pin list which has an alias (for list, show, and save anyway)
that won't work - you need data from the pin list, like the signal linked to, or the value
duh, it will work, there are links both ways
the alias list has an owner pointer, no?
that idea has a lot going for it
I should have said you need to skip pin list items with aliases, since they'll be seen from the aliases list
one ptr to pin list, one to alias list, compare the names, and do whichever is first in sort order
when advancing the pin pointer, skip any pin with an alias
there will need to be another method though
for find_pin_by_name, you want to match either the alias or original name
so you don't want to skip pin list items with aliases
find_pin_by_name doesnt' care about order, and doesn't need to traverse the alias list at all
(or you just go through the pin list and compare both)
it slightly bugs me that find_pin_by_name is O(n) instead of say O(log(n)), but it's been that way all along
if we ever start seeing speed issues, then I'll make the jump to AVL trees instead of linear lists
I wonder if there are suitable routines in the kernel already
they'd have to be available in both kernel and user space, with the same API
hmmm. that's true
the actual AVL code isn't the issue - I wrote some AVL code a couple years ago
the work would be integrating it into all the existing code and structs
yep, and dealing with the various functions (mostly (all?) in halcmd) that do their own list traversal
thats why it can wait till we actually see a speed problem
and then, we profile before assuming the cause
and then, we divide the problem by a lot by (a) hashing names or (b) using a hierarchy or (c) making a bunch of head pointers (one for each character, for example) ...
many many ways to optimize
I think the reasoning behind the AVL was to avoid having halcmd and such doing their own traversal
though algorithmic optimization (like switching from flat to tree) is usually the best
have a hal_lib api that is "get_next(name)"
right, add get list functions and stuff
the trouble is that I think that requires a lock on hal_data
EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/togl.c: fix a segfault
that's from coverity :)
EMC: 03seb 07TRUNK * 10emc2/src/hal/user_comps/vcp/tokenizer.h: note that tf_get_token() returns NULL on error
traversing a linear list with get_next is O(n^2), but with AVL it is O(n*log(n))
EMC: 03seb 07TRUNK * 10emc2/src/hal/user_comps/vcp/vcp_main.c: dont leak memory
I wonder if seb realizes that vcp is deprecated?
it should only be O(n)
guess a bug is a bug
SWPadnos: nope, not if you aren't holding a lock the entire time
if you're assuming that you have to find the last known entry again N times, you're still subject to that entry going away
given a name, you have to find it ( On or OlogN depending on the struct), then get the next (O1)
though you can still find the first entry greater than the last one returned
exactly, you don't search for ==, search for >
wonder how many of these 'return null' just move the error up
yeah, I was wondering whether the fixes are all correct or not
some of them are simple - if (a==NULL) don't deference a
apparently we don't trigger them (often?) anyway
but return instead may or may not be correct
most are unusual error conditions
(that's why I haven't done anything other than mark one "false")
huh. the fix(es) in vcp_main.c look wrong
if item_name has already been incremented to the end of an entry (a "}" character), then freeing it shouldn't work since it no longer points to the beginning of the allocated block
(still updating here)
I'm just reading the commit mesasge
ah, ok. "}" may be returned as a token
yeah, I don't see anyplace where item_name is advanced
nope - my bad. looking at the whole file is better than the few context lines in the commit message :)
tokenizer.h says 'tf_get_token()' returns the next token from the file. It is returned as a malloc'ed string, and should be freed when the program is done with it.
right, and the tokenizer only runs once anyway
well, the file is parsed once anyway
tf_open only opens the file and stashes some data (like the list of delimiters, etc)
tf_get_token() parses one token and updates a pointer to the current location in the file
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/regmap: This looks like a big diff, but all it does is remove all the ^M characters.
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/regmap: new regmap from Peter
he probably noted that the new regmap has no ^M, and that diff would be both huge and contain some real changes
so he did one diff with the ^M removal, and then another with the real changes
right - figured it out finally :)
EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder.c: Add a debug option so all RTAPI messages can be read in the terminal
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/opto22.lyx: add a bit more to the opto22 info
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/ (AX5214H.lyx opto22.lyx): add driver files
EMC: 03tissf 07TRUNK * 10emc2/configs/sim/axis.ini: french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (6 files): french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (9 files): french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/ (stepconf_fr.lyx stepper_fr.lyx): french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/examples/ (gcode_fr.lyx spindle_fr.lyx): french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/ (12 files): french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/install/Latency_Test_fr.lyx: french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/quickstart/stepper_quickstart_fr.lyx: french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/components_fr.lyx: french translation massive update
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation massive update
BigJohnT: it remains only the doc of Ladder to translate
this is a big piece
tissf: I think you may have missed an image file
+`/home/francis/emc2.TRUNK/docs/src/common/xemc_fr.png', needed by
actually I guess it's a wrong path
it is possible
ok sorry I commit it now
jepler: bad path ! the image already commited
oops I made a mistake with xemc_fr.png and tkemc_fr.png I have to cvs remove :(
rhaaa ! I can't compile anymore the _fr docs! no error message...
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ioport.c: remove a now-unused variable
tissf: are you compiling html docs or pdf docs or both?
wow - paul actually gave an example..
yeah but he's still full of shit
EMC: 03seb 07TRUNK * 10emc2/src/rtapi/rtai_rtapi.c: Made the function match the prototype (to fix a couple of compile warnings).
tissf: when you get your mess fixed you can fix the one I have too :)
John what is your mess ?
I added a directory and a file :?
and I missed something in the submakefile
so I get IOError: [Errno 2] No such file or directory: 'drivers_AX5214H.xml'
I'll work on it in a bit the dog want's to take me out for a walk
be back in a bit
tissf: looks like your "french translation massive update" commit this morning (2008 Nov 22 16:12 UTC) broke it, though i'm not sure what part was problematic
jepler: gnucash is just what I was looking for thanks
aram needs a link to the help menu :/
BigJohnT, I think he's using tkEMC
does tkEMC have the help menu?
so the cycle start function may be a different key or nonexistent, and the help menu my not give much help
yep it is right there
yes, but I don't see anything that specifically talks about cycle start
wow a dro for old farts
there are pause and resume buttons, but I don't know if they're the same
you gotta scroll down a while
did that :)
ok, then I'm confused
I don't see "cycle" anywhere in there, but who knows
it's not exactly easy to search that text (as presented by tkemc)
nope, it's not there
I thought he wanted to resume a program that was stopped with M1?
yes, that's what I thought too
I don't know whether you need to "pause", "run", or something else to do that though
well OK then :)
wow, I finally figured out how to make tkEMC run
load sim/tkenmc ??
or do you meant "run a G-code program"?
hmmm it don't stop at M1
that's optional stop, you need to set the correct HAL pin to make it stop
yep the optional stop button did the trick
oh right - I forgot that Alex added that
I guess I shuold have looked at the screen a little more :)
argh. can't type (again)
time to start drinking :)
EMC: 03cradek 07TRUNK * 10emc2/configs/sim/axis.ini: I don't think he meant to do this
EMC: 03seb 07TRUNK * 10emc2/docs/src/gui/ (mini_fr.lyx tkemc_fr.lyx): use relative paths instead of tissf's home dir
EMC: 03seb 07TRUNK * 10emc2/docs/src/common/user_intro_fr.lyx:
EMC: Even though the included .png file and the .lyx file are both in
EMC: docs/src/common/ already, the .lyx file is included in another .lyx
EMC: file in docs/src/gui/, so the path to the .png file needs to explicitly
EMC: find common/
EMC: I think.
seb_kuzminsky: I had that happen before
the include path thing?
neat, looks like chris M fixed save in CL - I'll try it later
yea, hmm it needed to be in the same directory or a subdirectory below the lyx file or something like that
cradek: yep chester fixed it
cradek: hm2 still working well for you?
or lyx I think would put the whole path in there ie your home directory
seb_kuzminsky: yes! I haven't used it much but it is working.
seb_kuzminsky: I'm anxious for the envoder velocity output now - I always want something don't I?
i'm hoping to do encoder velocity stuff tonight
cool, I will help you test it later then.
don't they use envoders on warp drives :)
will it be safe across an index?
do you want it to be?
(the way I have to do it now freaks out on index)
ok then yes it will be ;-)
BigJohnT: my cat sits on my left arm, so the letters on the left side of the keyboard are only approximate
my last cat would snuggle under my armpit while I watched tv and it weighed 20 lbs
and I don't have any excuse for my typos :)
ok the docs build again, i'm taking off for the afternoon
see y'all tonight
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/ (tkemc.png tkemc_fr.png tkemc_fr.lyx): french translation fix images wrong path solved by duplicating the images!
EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (4 files): french translation fix images wrong path solved by duplicating the images!
hey tissf I finally found my typo in the submakefile
have you had a chance to look at asciidoc?
no :( I have them a failure of the Internet for 8 days!
heck it takes me 8 days to download anything out here in the woods
:) finally, a new modem solved my problem