Back
[01:04:17] <CIA-5> EMC: 03jthornton 07master * r1b143079b190 10/docs/src/config/ini_config.lyx: add wrapped rotary
[01:04:21] <CIA-5> EMC: 03jthornton 07master * re33ad489aee6 10/docs/src/gcode/ (main.lyx tool_compensation.lyx): add tool table changes
[01:54:17] <cradek> cool, docs
[01:54:20] <cradek> you guys all rock
[04:00:17] <jepler> what's that? oh, it's the sound of seb hard at work!
[04:00:38] <cradek> and jthornton and micges
[04:00:48] <cradek> jepler: did you see dgarr's patch earlier?
[04:07:02] <mozmck> is there anything under GPL v3 in emc2? would there be a problem using that for something that might go in emc2?
[04:07:11] <cradek> no, yes
[04:07:37] <cradek> you can use the 'GPL2 or at your option any later version' one though, I think we have some
[04:08:00] <cradek> this is because gpl2 and gpl3 are incompatible licenses
[04:08:09] <mozmck> ok, I don't know enough about the differences.
[04:09:00] <mozmck> I see. is there a reason to say to write the fsf via snail mail for a copy of the gpl anymore?
[04:09:13] <cradek> heh
[04:09:15] <mozmck> why not just put a link to it?
[04:09:24] <cradek> there's a faq about stuff like this
[04:09:47] <cradek> 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
[04:10:12] <cradek> I don't see any harm in keeping the whole text, personally
[04:10:27] <cradek> they sure tried to cover every possibility :-)
[04:10:34] <mozmck> 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/>. "
[04:10:40] <mozmck> from the faq :)
[04:10:51] <cradek> haha
[04:11:05] <cradek> I was just looking for it...
[04:11:07] <mozmck> http://www.gnu.org/licenses/gpl-howto.html
[04:12:11] <cradek> huh, now gpl3 assumes everyone has internet access
[04:12:19] <cradek> http://www.gnu.org/licenses/gpl-faq.html#DistributeWithSourceOnInternet
[04:12:45] <cradek> yeah gpl2 was 1991
[04:12:52] <mozmck> that's the howto linked from the gpl2 faq
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#CouldYouHelpApplyGPL
[04:14:07] <CIA-5> EMC: 03seb 07master * r6dc8abbf4be5 10/debian/control.in: dont build-depend on build-essential packages
[04:14:07] <CIA-5> EMC: 03seb 07master * r83912b08465d 10/debian/control.in: specify a valid Standards-Version
[04:14:13] <mozmck> thanks for the info. I'll use the "GPL2 or at your option any later version" line :)
[04:14:26] <cradek> anytime
[04:20:32] <cradek> git sure lets us effortlessly do stuff we didn't dare before
[07:56:04] <micges_work> good morning
[08:04:07] <alex_joni> hi
[10:17:43] <micges_work1> micges_work1 is now known as micges
[13:15:05] <jepler> dgarr, cradek: no, I'd missed the patch earlier. will apply.
[13:16:34] <CIA-5> EMC: 03jepler 07master * rd1e6ea19a18d 10/lib/python/rs274/glcanon.py: remove extra def for comment that masks original def
[13:24:27] <jt-dev> 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
[13:24:44] <jt-dev> Starting EMC2 DISPLAY program: axis
[13:24:45] <jt-dev> libnml/buffer/physmem.cc 143: PHYSMEM_HANDLE: Can't write 10748 bytes at offset 60 from buffer of size 10208.
[13:24:47] <jt-dev> libnml/cms/cms_in.cc 1383: CMS:(emcStatus) Error writing 10748 bytes to global memory at offset 81F8CD8
[13:24:49] <jt-dev> (See libnml/cms/cms_in.cc line 1386.)
[13:26:06] <micges> you have local emc.nml ?
[13:26:28] <SWPadnos> neither of those files has changed since April 2008
[13:26:33] <jt-dev> not sure
[13:26:44] <jt-dev> here is the whole error
http://pastebin.ca/1766494
[13:26:45] <SWPadnos> 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
[13:27:25] <micges> don't know why it isn't work
[13:29:02] <jt-dev> dmesg
http://pastebin.ca/1766498
[13:29:04] <SWPadnos> does the emc.nml file get read from the common dir, or is it copied into the individual configs?
[13:29:32] <jepler> SWPadnos: if it's not specified in the inifile it's read from a common location
[13:29:39] <SWPadnos> ok
[13:31:23] <jepler> -B emcStatus SHMEM localhost 10240 0 0 2 16 1002 TCP=5005
[13:31:26] <jepler> +B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005
[13:31:41] <SWPadnos> that
[13:31:49] <SWPadnos> that's the change micges linked to
[13:32:02] <jepler> ah oops
[13:33:21] <jt-dev> micges: yes I have a local emc.nml in each config
[13:33:33] <SWPadnos> ok, then change that line
[13:33:48] <jepler> If I revert that I get errors like
[13:33:49] <jepler> libnml/buffer/physmem.cc 143: PHYSMEM_HANDLE: Can't write 11568 bytes at offset 72 from buffer of size 10208.
[13:34:03] <jepler> so I think jt-dev somehow has the old emc.nml
[13:34:12] <jepler> and the sizes probably differ because of 32 vs 64 bits
[13:34:31] <SWPadnos> custom ones in each config, which wouldn't have been automatically updated
[13:34:32] <jt-dev> yes and I changed the 10240 to 16384 and the config ran
[13:35:06] <jepler> jt-dev: are you using different configs than the ones that are in master?
[13:35:20] <micges> I'll send mail about that isse to emc list
[13:35:25] <micges> issue
[13:35:29] <jt-dev> yes I create a copy to try out things with
[13:36:46] <jepler> jt-dev: you copy them from master or from somewhere else (like v2.3)
[13:36:47] <jepler> ?
[13:37:07] <jt-dev> I usually run emc from the scripts dir
[13:37:07] <jepler> micges: please also add it to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[13:37:17] <SWPadnos> 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
[13:37:44] <jt-dev> jepler: always from dev
[13:38:27] <micges> jepler: ok
[13:38:33] <jepler> jt-dev: that's extremely odd, as all the configs in master are supposed to refer to the central copy of emc.nml
[13:38:42] <SWPadnos> oh. that wiki page
[13:38:43] <jepler> I see configs/smithy/* are an exception
[13:38:44] <SWPadnos> (geex)
[13:38:46] <SWPadnos> z
[13:39:51] <jt-dev> one was from running step conf wizard to get a classicladder config
[13:41:22] <jepler> jt-dev: well I'm left scratching my head; stepconf in master won't use a copy of emc.nml either
[13:42:08] <jt-dev> hmmm, I might have used 2.3 stepconf then changed the path to emc in dev
[13:42:25] <jt-dev> I've been known to do that before :)
[13:43:52] <jt-dev> thanks for the help guys
[13:44:01] <CIA-5> EMC: 03jepler 07master * r07b7e7a1c4f3 10/configs/smithy/ (12 files): use the common copy of emc.nml
[13:44:13] <jt-dev> * jt-dev is off to deliver a machine to a customer
[13:44:16] <jepler> see you
[13:46:43] <jepler> 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
[13:47:07] <jepler> I'll bbl too
[13:48:12] <micges> bbl
[15:56:50] <jepler> I added some words about emc.nml and tool table changes to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[16:04:44] <cradek> mark p fails at reading...
[16:05:58] <SWPadnos> indeed
[16:06:03] <SWPadnos> not enough time I guess :)
[16:43:33] <micges> jepler: thanks for wiki update
[16:45:50] <cradek> I think both 2.3 and 2.4 will nuke the other's tool table. do we want to do something about that?
[16:46:58] <micges> maybe detect old format and make backup?
[16:47:01] <jepler> cradek: do you have a suggestion?
[16:47:12] <jepler> I had thought maybe 2.4 could autodetect the old formats and migrate
[16:47:28] <jepler> I don't care about 2.4 -> 2.3
[16:51:05] <cradek> I don't know what my suggestion is. Seems like we could refuse to run, or detect and rename it, or try to autoconvert
[16:51:28] <cradek> nuking it silently is the worst possible behavior and I think that's what we currently have
[16:51:36] <cradek> I think I'd be happy with any of the others
[16:55:33] <cradek> I think we could detect the old formats with egrep -q '^ *[-+0-9]' (any line starting with a number, ignoring leading whitespace)
[16:57:59] <cradek> are you thinking the emc script would do the conversion, or iotask?
[16:59:45] <SWPadnos> make the default name/extension something else for 2.4, and have the conversion tool convert/copy to the new name
[17:00:16] <cradek> the filename is specified in the ini
[17:00:17] <SWPadnos> I agree with jepler, 2.4 -> 2.4 is fairly uninteresting to me
[17:00:24] <SWPadnos> yes, but there's a default
[17:00:30] <cradek> there is no default name or extension
[17:00:48] <SWPadnos> well, like e,c.nml is the "default" nml file
[17:00:53] <SWPadnos> err, emc.nml
[17:00:56] <cradek> hang on
[17:01:07] <cradek> we're talking about not nuking the tool table in people's machine configs
[17:01:14] <cradek> the tool table filename is specified in their ini file
[17:01:36] <cradek> it may be named anything
[17:01:47] <SWPadnos> ok, sure
[17:02:02] <cradek> are you suggesting we change their ini file, or something else?
[17:02:18] <SWPadnos> yes, I guess so
[17:02:21] <SWPadnos> which may be a bad idea
[17:03:51] <SWPadnos> 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
[17:03:57] <cradek> 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
[17:04:19] <SWPadnos> sure
[17:04:34] <SWPadnos> does it already do this with comments?
[17:04:40] <micges> nope
[17:04:43] <SWPadnos> bummer
[17:04:57] <cradek> yes it does save and rewrite comments
[17:05:10] <micges> I mean it discard unknown lines
[17:05:23] <SWPadnos> ok, figured that we'd have lost a lot of header information if it didn't
[17:05:36] <cradek> 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.
[17:06:03] <SWPadnos> if you find no tools, should that be an error?
[17:06:07] <cradek> no
[17:06:11] <SWPadnos> ie, from a 2.3-style table
[17:06:23] <SWPadnos> so it would silently load and not understand the old style ...
[17:06:34] <micges> I think saving old lines as a comments is good idea
[17:12:33] <cradek> it gives us a bonus in the future too: if someone makes a mistake writing a tool table line, it doesn't just disappear
[17:12:51] <jepler> cradek: this is instead of or in addition to parsing the old-format lines?
[17:12:58] <cradek> I was thinking instead of
[17:13:22] <micges> me too
[17:13:23] <cradek> hmm, we have one comment per pocket - they're tied together, so ... ick
[17:14:51] <micges> I would like also add some message window that tool table is empty
[17:15:36] <cradek> micges: I bet > 50% of our users run with no tool table.
[17:15:39] <jepler> micges: but that's not an error. I don't use a tool table on my machine..
[17:16:05] <micges> I know that's not error
[17:16:36] <micges> but I also don't want to see that message over and over
[17:16:38] <micges> :P
[17:17:32] <SWPadnos> when you run with no tool table, do you still have a tool table file specified in the ini?
[17:17:58] <cradek> yes I think it's an error to not be able to open/read the tool table
[17:18:02] <jepler> 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..
[17:18:03] <SWPadnos> not loading a tool table shouldn't be an error (or warning). loading one and not finding any valid tools in it should be
[17:18:09] <cradek> the file can sure be empty though
[17:18:09] <SWPadnos> hmmm
[17:18:27] <SWPadnos> that should be a warning IMO
[17:18:36] <SWPadnos> as long as no tool table specified is valid
[17:18:53] <cradek> you might be right about that, but it would be warning about how many (surely most) users have it
[17:19:00] <micges> if there si no tool table specified there is only warning
[17:19:15] <cradek> oh ok, I didn't actually try
[17:19:20] <SWPadnos> cradek, err, parse error :)
[17:27:42] <alex_joni> I wonder if we should have the emc2 version in the ini file
[17:31:53] <cradek> how would that be used?
[17:32:26] <alex_joni> maybe read by the runscript
[17:32:47] <alex_joni> to detect incompatible ini files
[17:37:41] <jepler> 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
[17:49:49] <christel> [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.
[18:24:43] <alex_joni> jepler: I know
[18:24:54] <alex_joni> it's just something to have planned ahead
[18:25:07] <alex_joni> although we can always add something to the ini that wasn't there before
[18:25:43] <SWPadnos> it's hard to rely on tokens like that in user-editable text files
[18:25:54] <SWPadnos> "I just upgraded, so I'll change that" ...
[18:46:24] <cradek> grr, enco sent me a 20% coupon today
[18:46:52] <jepler> doh
[18:47:53] <SWPadnos> you reminded them to do that by placing an order yesterday
[18:50:30] <cradek> exactly
[20:02:22] <alex_joni> SWPadnos: how about the hash from the version tag?
[20:02:39] <alex_joni> I foubt regular users will know that :P
[20:02:46] <alex_joni> doubt even
[20:03:04] <SWPadnos> sure, something like that could work
[20:03:23] <SWPadnos> I'm not sure it's reliable though
[20:03:51] <alex_joni> or needed