EMC: 03jthornton 07master * r1b143079b190 10/docs/src/config/ini_config.lyx: add wrapped rotary
EMC: 03jthornton 07master * re33ad489aee6 10/docs/src/gcode/ (main.lyx tool_compensation.lyx): add tool table changes
you guys all rock
what's that? oh, it's the sound of seb hard at work!
and jthornton and micges
jepler: did you see dgarr's patch earlier?
is there anything under GPL v3 in emc2? would there be a problem using that for something that might go in emc2?
you can use the 'GPL2 or at your option any later version' one though, I think we have some
this is because gpl2 and gpl3 are incompatible licenses
ok, I don't know enough about the differences.
I see. is there a reason to say to write the fsf via snail mail for a copy of the gpl anymore?
why not just put a link to it?
there's a faq about stuff like this
gpl2 was written in 1989? 1991? and it was totally reasonable to think that someone might get gnu/gpl software but not have web access
I don't see any harm in keeping the whole text, personally
they sure tried to cover every possibility :-)
hmm, " You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
from the faq :)
I was just looking for it...
[04:11:07] <mozmck> http://www.gnu.org/licenses/gpl-howto.html
huh, now gpl3 assumes everyone has internet access
[04:12:19] <cradek> http://www.gnu.org/licenses/gpl-faq.html#DistributeWithSourceOnInternet
yeah gpl2 was 1991
that's the howto linked from the gpl2 faq http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#CouldYouHelpApplyGPL
EMC: 03seb 07master * r6dc8abbf4be5 10/debian/control.in: dont build-depend on build-essential packages
EMC: 03seb 07master * r83912b08465d 10/debian/control.in: specify a valid Standards-Version
thanks for the info. I'll use the "GPL2 or at your option any later version" line :)
git sure lets us effortlessly do stuff we didn't dare before
micges_work1 is now known as micges
dgarr, cradek: no, I'd missed the patch earlier. will apply.
EMC: 03jepler 07master * rd1e6ea19a18d 10/lib/python/rs274/glcanon.py: remove extra def for comment that masks original def
this is odd, I'm running dev pulled this morning and rebuilt and I get an error no matter which config I try and run
Starting EMC2 DISPLAY program: axis
libnml/buffer/physmem.cc 143: PHYSMEM_HANDLE: Can't write 10748 bytes at offset 60 from buffer of size 10208.
libnml/cms/cms_in.cc 1383: CMS:(emcStatus) Error writing 10748 bytes to global memory at offset 81F8CD8
(See libnml/cms/cms_in.cc line 1386.)
you have local emc.nml ?
neither of those files has changed since April 2008
here is the whole error http://pastebin.ca/1766494
and that was only to remove CVS keywords - the last substantive change was in 2005
[13:27:10] <micges> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=c2ec26d
don't know why it isn't work
does the emc.nml file get read from the common dir, or is it copied into the individual configs?
SWPadnos: if it's not specified in the inifile it's read from a common location
-B emcStatus SHMEM localhost 10240 0 0 2 16 1002 TCP=5005
+B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005
that's the change micges linked to
micges: yes I have a local emc.nml in each config
ok, then change that line
If I revert that I get errors like
libnml/buffer/physmem.cc 143: PHYSMEM_HANDLE: Can't write 11568 bytes at offset 72 from buffer of size 10208.
so I think jt-dev somehow has the old emc.nml
and the sizes probably differ because of 32 vs 64 bits
custom ones in each config, which wouldn't have been automatically updated
yes and I changed the 10240 to 16384 and the config ran
jt-dev: are you using different configs than the ones that are in master?
I'll send mail about that isse to emc list
yes I create a copy to try out things with
jt-dev: you copy them from master or from somewhere else (like v2.3)
I usually run emc from the scripts dir
micges: please also add it to http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
micges, I don't know if we have a wiki page yet, but it might be a good idea to put this in a list of things to do when upgrading to 2.4
jepler: always from dev
jt-dev: that's extremely odd, as all the configs in master are supposed to refer to the central copy of emc.nml
oh. that wiki page
I see configs/smithy/* are an exception
one was from running step conf wizard to get a classicladder config
jt-dev: well I'm left scratching my head; stepconf in master won't use a copy of emc.nml either
hmmm, I might have used 2.3 stepconf then changed the path to emc in dev
I've been known to do that before :)
thanks for the help guys
EMC: 03jepler 07master * r07b7e7a1c4f3 10/configs/smithy/ (12 files): use the common copy of emc.nml
* jt-dev is off to deliver a machine to a customer
micges: for users who haven't customized emc.nml (almost all of them!) the right corrective measure is probably to remove NMLFILE = emc.nml from the .ini unless running the same config with 2.3 and master is a goal
I'll bbl too
I added some words about emc.nml and tool table changes to http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
mark p fails at reading...
not enough time I guess :)
jepler: thanks for wiki update
I think both 2.3 and 2.4 will nuke the other's tool table. do we want to do something about that?
maybe detect old format and make backup?
cradek: do you have a suggestion?
I had thought maybe 2.4 could autodetect the old formats and migrate
I don't care about 2.4 -> 2.3
I don't know what my suggestion is. Seems like we could refuse to run, or detect and rename it, or try to autoconvert
nuking it silently is the worst possible behavior and I think that's what we currently have
I think I'd be happy with any of the others
I think we could detect the old formats with egrep -q '^ *[-+0-9]' (any line starting with a number, ignoring leading whitespace)
are you thinking the emc script would do the conversion, or iotask?
make the default name/extension something else for 2.4, and have the conversion tool convert/copy to the new name
the filename is specified in the ini
I agree with jepler, 2.4 -> 2.4 is fairly uninteresting to me
yes, but there's a default
there is no default name or extension
well, like e,c.nml is the "default" nml file
we're talking about not nuking the tool table in people's machine configs
the tool table filename is specified in their ini file
it may be named anything
are you suggesting we change their ini file, or something else?
yes, I guess so
which may be a bad idea
depending on the complexity of the necessary changes, a migration script that massages the ini file as well as converting the tool table might be a good solution
another way of looking at the problem: iotask reads the tool table, discarding anything it doesn't understand. then it rewrites it. maybe it should keep lines it doesn't understand as comments, and rewrite them
does it already do this with comments?
yes it does save and rewrite comments
I mean it discard unknown lines
ok, figured that we'd have lost a lot of header information if it didn't
in 2.4 if you find no parsable letter words, you could call the whole line a comment and save it. then it will get rewritten with ; in front of it.
if you find no tools, should that be an error?
ie, from a 2.3-style table
so it would silently load and not understand the old style ...
I think saving old lines as a comments is good idea
it gives us a bonus in the future too: if someone makes a mistake writing a tool table line, it doesn't just disappear
cradek: this is instead of or in addition to parsing the old-format lines?
I was thinking instead of
hmm, we have one comment per pocket - they're tied together, so ... ick
I would like also add some message window that tool table is empty
micges: I bet > 50% of our users run with no tool table.
micges: but that's not an error. I don't use a tool table on my machine..
I know that's not error
but I also don't want to see that message over and over
when you run with no tool table, do you still have a tool table file specified in the ini?
yes I think it's an error to not be able to open/read the tool table
SWPadnos: yes, I think that's how my machine is set up. I'm not sure what happens if the file is unspecified in the ini..
not loading a tool table shouldn't be an error (or warning). loading one and not finding any valid tools in it should be
the file can sure be empty though
that should be a warning IMO
as long as no tool table specified is valid
you might be right about that, but it would be warning about how many (surely most) users have it
if there si no tool table specified there is only warning
oh ok, I didn't actually try
cradek, err, parse error :)
I wonder if we should have the emc2 version in the ini file
how would that be used?
maybe read by the runscript
to detect incompatible ini files
Looking at the UPDATING page, none of the 2.2 -> 2.3 differences seem to make it impossible to have an inifile that works with both
[Global Notice] Hi all, we're four days away from the ircd migration -- if you are a tor-gpg user, a organisation with a current iline or a project which utilises dircbot we would as you to have a glance over at http://bit.ly/9yTy70
Thank you for reading and for using freenode.
jepler: I know
it's just something to have planned ahead
although we can always add something to the ini that wasn't there before
it's hard to rely on tokens like that in user-editable text files
"I just upgraded, so I'll change that" ...
grr, enco sent me a 20% coupon today
you reminded them to do that by placing an order yesterday
SWPadnos: how about the hash from the version tag?
I foubt regular users will know that :P
sure, something like that could work
I'm not sure it's reliable though