Back
[12:45:12] <andypugh> Does anyone know offhand in which circumstances "comp" gives this error?
[12:45:13] <andypugh> File "/usr/bin/comp", line 411, in parse
[12:45:13] <andypugh> a, b = f.split("\n;;\n", 1)
[12:45:14] <andypugh> ValueError: need more than 1 value to unpack
[12:46:21] <seb_kuzminsky> no idea
[12:47:01] <andypugh> Looking it it properly for the first time... Is that the part that splits out the preface from the code?
[12:47:15] <andypugh> Does it seem likley that his file is tainted by Windows?
[12:47:44] <andypugh> (So he has "/crlf;;/crlf" in effect?
[12:47:45] <seb_kuzminsky> it'd be cool if comp didn't barf when fed windows line endings
[12:52:07] <andypugh> Hmm, how can I deliberately add some Windows cruft to check this theory?
[13:02:02] <andypugh> Aha! Yes, that is exactly the error you get if the file goes via Windows.
[13:02:39] <andypugh> I wish I hadn't been pushing the guy through a week of debugging and upgrades in an attempt to fix it..
[13:07:25] <archivist> failing to deal with various line endings should perhaps be regarded as a bug
[13:08:15] <pcw_home> yeah line parsing should be early and universal
[13:15:40] <andypugh> It seems that Gedit puts the cr/lf back in even if you remove them, once the file has been "tainted". That's unhelpful.
[13:17:07] <archivist> crlf pre-dates unix
[13:17:24] <pcw_home> dos2unix
[13:19:36] <pcw_home> I guess Gedit decides what type the file is when it read it in and keeps it that way
[13:20:33] <andypugh> So it seems.
[13:20:54] <jepler> based on that line you pasted, it means ";;" can't have any space before or after it either
[13:21:55] <andypugh> Ah! I just noticed an option in the gedit save-as dialog..
[13:23:06] <archivist> if you have meld installed for diff and editing that throws a dialog when you try to save to ask which end you want
[13:25:12] <andypugh> jepler: Aye, adding a space after ;; is equally effective at triggering an unpacking error.
[13:26:17] <andypugh> This sounds like a job for.. <fanfare> Regex Man!
[13:26:36] <pcw_home> Ahh yes gedits default save mode depends on the original file line endings
[13:41:10] <jepler> Or reject with an error any .comp file that has a "\r" in it
[13:44:05] <andypugh> That's probably easier, and would give a perfectly intelligible clue at least.
[13:44:44] <pcw_home> Thats would at least avoid wasting time chasing obscure errors
[13:45:03] <andypugh> (Though I am cursing that I only actually _read_ the error message when I posted it here. Previously I had been scanning past the code thinking "ah, yes, that would be unintellible Python code"
[13:52:55] <jepler> you could also try / except ValueError: raise SystemExit, "Helpful error message"
[13:54:20] <andypugh> Ah, but for me to do it I would have to overcome my ophidiophobia
[13:55:08] <jepler> or your misconceptions
[13:55:22] <andypugh> :-)
[13:55:29] <jepler> the Python language is a reference to Monty Python; this was true in 1993 and it's still true even if the snake-worshippers have the doctrinal upper hand these days
[14:03:25] <andypugh> I get all the fun error messages: [ 1724.258891] kernel BUG at /home/moses/Projects/emc2/ubuntu-lucid/mm/slub.c:2969!
[16:02:18] <skunkworks> Tort take about the same time on mach vs linuxcnc with the same settings... (just over a minute) (I will time it better tomorrow..)
[16:03:14] <skunkworks> (running tort as fast as it can go with 30in/sec/sec and 500ipm max per axis. both setup the same as far as I can tell.. :)
[16:04:10] <skunkworks> I was expecting mach to go twice as fast...
[16:06:06] <skunkworks> I wanted to goof around and compare so at least I could get a feeling of linuxcnc's limits.. (or machs)
[16:06:45] <skunkworks> I will try some files with short line segments - like chips and some other ones I have.