#emc | Logs for 2007-03-06

[00:02:30] <ejholmgren> does anyone want some snow? ... http://imagebin.org/7510
[00:03:08] <ejholmgren> I can send it fob
[00:03:24] <mshaver> re: parts - the c++ stuff - the interpreter interface - abstract the emc interface to ipc mechanism, etc.
[00:03:44] <CIA-6> 03cradek 07rigid_tap * 10emc2/src/emc/nml_intf/emc.cc: fix debug output for rigid tap message
[00:04:32] <petev> matt, I have been looking at the higher level code and have quite a few ideas for refactor
[00:04:59] <petev> also have a new interp that is written in ANTLR, a LL parser generator
[00:05:21] <petev> been trying to figure out a good way to make changes without totally breaking everything
[00:05:37] <mshaver> ANTLR - must look at that now
[00:05:45] <mshaver> i don't think it's possible
[00:06:04] <petev> I have a few ideas that might work
[00:06:16] <petev> but at some point, things may be broken for a while
[00:06:23] <mshaver> we need to make a fresh tree with a skeletal build system & get each thing working on it's own
[00:06:50] <petev> there are two things that need abstracting and isolating before the major changes
[00:07:14] <mshaver> bring in the interp & run it stand alone, bring in moation & run it with usrmot, etc.
[00:07:18] <petev> those are the config data from INI file, etc., and the comm mechanism (NML, or whatever else)
[00:07:26] <mshaver> YES!
[00:07:40] <petev> the interp already runs standalone
[00:07:43] <mshaver> INI date is read out in at least 3 ways, maybe more
[00:08:18] <petev> and there are plenty of memory leaks and duplicated code
[00:08:22] <petev> made me sick
[00:08:36] <mshaver> yes, it does, but we need to specifiy it's interface to the rest of the system to make interp substitution easier
[00:08:48] <petev> I would like to make a config object
[00:08:54] <ds3> anyone try building the simulator only under cygwin?
[00:09:08] <mshaver> mu thought stoo - config object
[00:09:14] <petev> it will read all the config data (except HAL) at one time, then pass it around to other objects
[00:09:34] <cradek> ds3: I haven't heard of anyone, but if you can manage to get all the dependencies (a large task I bet) it may work
[00:09:48] <petev> that way the config format can be changed easily, if we want to try XML or whatever
[00:10:08] <mshaver> actually, there are two config sources, ini & vars
[00:10:18] <petev> interp vars?
[00:11:10] <ds3> cradek: large dependencies? is it any worse then on Unix?
[00:11:21] <mshaver> my opinion is: .ini is for constants (don't change during run time) & vars (rs274ngc.var) is for anything that the emc might want to write out
[00:11:26] <cradek> ds3: sure, because there's no packages ready for you to use
[00:11:49] <petev> yes, I thought about putting all in one place, but didn't like the idea or mixing R/W with R only
[00:12:01] <cradek> ds3: (vmware running linux might be easier)
[00:12:04] <mshaver> petev: you ever use a fanus or yasnac or similar?
[00:12:18] <petev> used a fanuc a little
[00:12:18] <ds3> cradek: not sure I understand what you mean; I built everything needed for the simulator into /opt/emc32 on a Unix box.... it there more than that?
[00:12:23] <petev> and some okuma
[00:12:27] <mshaver> s /fanus/ /fanuc/
[00:12:36] <cradek> ds3: I don't know, sorry, I don't use windows
[00:13:04] <mshaver> so you know about numbered parameters in commercial controls
[00:13:09] <petev> yes
[00:13:21] <ds3> cradek: neither do I... but I know a local community college instructor looking for a cheap/free G-code simulator
[00:13:23] <mshaver> we have then in rs274ngc.var (or whatever.var)
[00:13:29] <petev> yes
[00:13:41] <petev> I don't mind keeping stuff like that separate
[00:13:46] <cradek> ds3: hand him some EMC2 live CDs :-)
[00:13:53] <petev> I think the interp is the only place that needs to see that info now
[00:14:05] <ds3> cradek: he can barely keep up with Windows... (he's a machinist)
[00:14:21] <mshaver> the interp reads the ini, only to get the var file name I think
[00:14:22] <cradek> ds3: sorry, I'll quit "helping" now
[00:14:30] <ds3> =)
[00:14:31] <petev> that's correct
[00:14:46] <ds3> can't hurt to try, right? =)
[00:14:52] <mshaver> let me run this by you:
[00:15:01] <cradek> ds3: well, I think it would hurt, but that's just me
[00:15:02] <anonimasu> http://www.cncsimulator.com/
[00:15:05] <anonimasu> works.
[00:15:36] <anonimasu> the local schools use it for simulation over here..
[00:15:36] <mshaver> we only run the interp once per gcode input file and write a .canon file out to disk
[00:16:07] <petev> mshaver, you want to move to dev list so we don't bother eveyone and log in the right spot?
[00:16:29] <mshaver> yep, changing windows now
[00:16:32] <petev> ok
[00:16:34] <skunkworks> ejholmgren: don't talk to me about snow - I am near lacrosse. http://www.electronicsam.com/images/house/shop.JPG
[00:16:52] <skunkworks> developers - jeeze - they think they own the place. ;)
[00:17:01] <anonimasu> ^_^
[00:17:10] <jepler_> jepler_ is now known as jepler
[00:19:00] <robin_sz> skunkworks, what that whit stuff?
[00:19:43] <skunkworks> you don't get any over there?
[00:19:49] <robin_sz> mmm .. nope
[00:20:05] <robin_sz> not had any to speak of for years
[00:20:13] <skunkworks> http://www.electronicsam.com/images/house/scion.JPG
[00:20:28] <robin_sz> we got 100mm .. lasted 2 days or so this year
[00:20:31] <ds3> maybe it would hurt... :/
[00:20:52] <ds3> scratch that idea...back to real work
[00:21:15] <robin_sz> mmm ...
[00:21:31] <robin_sz> looks like a bit of insualtion in the roof might be an idea :)
[00:22:09] <robin_sz> or at least some fences to keep the snow on the roof
[00:22:18] <skunkworks> :)
[00:22:41] <skunkworks> it made it to the ground in one piece before it broke up.
[00:22:48] <robin_sz> heh
[00:23:05] <robin_sz> they reckon if you can keep the snow on, its warmer
[00:23:16] <skunkworks> right
[00:23:37] <robin_sz> a bit of 0 degrees, static snow is way better than -20 wind
[00:23:43] <skunkworks> it is a bit easier to heat with snow on the roof - I think it only has 6 inches of insulation
[00:23:49] <robin_sz> coo
[00:24:06] <robin_sz> not much ...
[00:24:18] <skunkworks> nope
[00:24:20] <robin_sz> that 6" being fibreglass wool?
[00:24:24] <skunkworks> yes
[00:24:38] <skunkworks> it was insulated on a budjet
[00:24:41] <skunkworks> buget
[00:24:44] <skunkworks> whatever
[00:24:47] <robin_sz> polyurethan foam sheets are the way to go
[00:25:02] <robin_sz> the foil covered stuff
[00:25:04] <anonimasu> hm, fibreglass wool works..
[00:25:36] <robin_sz> 50mm of polyurethane foam is like 200mm of fibreglass
[00:26:07] <anonimasu> robin_sz: well, it's not like you can switch when your shop/house whatever's finished easily ;)
[00:26:26] <robin_sz> depends I guess
[00:26:46] <robin_sz> loft spaces are easy to change and add to
[00:27:44] <robin_sz> skunkworks, where is that?
[00:28:05] <skunkworks> holmen, WI
[00:28:16] <skunkworks> near lacrosse
[00:28:24] <robin_sz> coo
[00:50:48] <skunkworks> we had an oversized load try to get under an overpass this weekend - it didn't make it. Now I90 westbound(I think) is closed until summer.
[00:52:10] <skunkworks> (at the overpass)
[00:52:38] <jmkasunich> thats gonna be an expensive insurance claim
[00:52:57] <skunkworks> http://www.lacrossetribune.com/articles/2007/03/05/news/02i90.txt
[00:52:58] <jmkasunich> "repair interstate highway: $220,000"
[00:52:59] <skunkworks> Yes it is
[00:53:12] <jmkasunich> "downtime: $10,000,000"
[00:54:05] <skunkworks> Early estimates show the project will cost about $500,000-600,000 to complete. 
[00:55:37] <skunkworks> it is the second time this is happened locally. someone forgot to lay the excavator's arm down
[00:55:56] <skunkworks> wasn't as bad though. didn't have to close the bridgy
[00:56:00] <skunkworks> bridge
[00:56:29] <jmkasunich> not your average load
[00:56:31] <jmkasunich> 75 tons
[00:57:39] <SWPadnos> lots of momentum there
[00:57:57] <jmkasunich> hey SWP! I was just gonna ping you
[00:58:02] <skunkworks> yes - and that road under the bridge is posted 55
[00:58:05] <skunkworks> mph
[00:58:12] <SWPadnos> hi
[00:58:22] <jmkasunich> hi ;-)
[00:58:24] <SWPadnos> hold on one sec - my wife hears a sound in the house ...
[00:58:28] <jmkasunich> ok
[00:58:33] <jmkasunich> no rush
[01:02:33] <SWPadnos> ok, it was just her dying UPS
[01:02:38] <jmkasunich> thats not good
[01:03:10] <SWPadnos> at least it's not the dying wiring or a dying raccoon or something
[01:03:29] <jmkasunich> true
[01:03:46] <jmkasunich> I'm trying to figure out some naming conventions and such
[01:03:50] <SWPadnos> ok
[01:03:59] <jmkasunich> as has been pointed out lately, CVS doesn't like it when you rename files
[01:04:05] <SWPadnos> heh
[01:04:12] <jmkasunich> I'm not touching that discussion with a 10-foot pole, but
[01:04:24] <jmkasunich> I have some 5i20 stuff that I probalby should quit hoarding and commit
[01:04:36] <jmkasunich> but I want to have a plan for naming it first
[01:04:50] <jmkasunich> fer instance
[01:05:22] <jmkasunich> the driver - the idea is that an FPGA can have multiple different functional blocks in it, and the driver will figure out what is there
[01:05:46] <jmkasunich> its tempting to put the code for each widget (encoder, stepgen, etc) in a separate source file
[01:05:54] <jmkasunich> instead of making a huge long driver
[01:06:40] <SWPadnos> there is the assumption that the blocks are independent (share no config data on the FPGA) and have independent driver "shards" - with separate read/write functions, right?
[01:06:51] <jmkasunich> yeah
[01:07:07] <jmkasunich> I'm not entirely sure how well the assumption will hold up, but its a goal
[01:07:12] <SWPadnos> the one place where I see that breaking down would be in a shared clock source or something, but that's no biggie
[01:07:44] <SWPadnos> well, here's a place where hierarchicalk HAL pin/func naming would be handy ... :)
[01:07:49] <SWPadnos> -k
[01:08:19] <jmkasunich> 5i20.N.stepgen.M.vel-cmd, etc
[01:08:23] <jmkasunich> already got that part coded
[01:08:37] <SWPadnos> I mean really hiererchical, but that's not important right now
[01:08:41] <SWPadnos> garh
[01:08:54] <SWPadnos> if only I ould type as well as I think
[01:09:15] <jmkasunich> general I/O is 5i20.0.p1-03 for I/O 3 on connector 1
[01:09:27] <jmkasunich> p1-03-out, -in, etc
[01:09:35] <SWPadnos> anyway, yes - I'd say that separate mini-drivers would be ideal - they could even be separate modules that are loaded by the main driver as it doscovers FPGA functions
[01:09:50] <jmkasunich> I don't want to go that far
[01:09:58] <jmkasunich> the loading api is NOT simple
[01:10:01] <petev> if not, how will it save memory?
[01:10:14] <jmkasunich> I'm not worried about memory
[01:10:24] <SWPadnos> not loading separate configs, but loading kernel modules based on what it finds in the loaded config
[01:10:46] <SWPadnos> or are you planning on building the FPGA config into the driver similar to how it's done now?
[01:11:03] <jmkasunich> you are saying (I think?) load the core module, and when it finds stuff in the fpga, load other modules to deal with the stuff
[01:11:07] <SWPadnos> yes
[01:11:17] <jmkasunich> except loading one module from the init code of another is non-trivial at best
[01:11:19] <SWPadnos> that's the extreme of the approach I think you're talking about
[01:11:21] <SWPadnos> sure
[01:11:33] <SWPadnos> I haven't gotten that far yet :)
[01:11:34] <jmkasunich> I'm not even remotely that extreme
[01:11:42] <jmkasunich> I'm just talking about organizing the source code
[01:11:48] <jmkasunich> it will compile into one module
[01:11:54] <jmkasunich> which will probably only be a few K
[01:11:58] <SWPadnos> in any case, separate source files per function make a lot of sense
[01:12:10] <jmkasunich> I will NOT be embedding the FPGA code into the driver
[01:12:13] <SWPadnos> per FPGA function, not per C function, obviously ...
[01:12:21] <SWPadnos> ok
[01:12:22] <jmkasunich> right
[01:12:39] <jmkasunich> 5i20.c, 5i20stepgen.c, 5i20encoder.c 5i20pwm.c, etc
[01:12:44] <jmkasunich> with .h files to go along
[01:12:47] <petev> no default FPGA config in the driver will be a pain for the average user
[01:12:55] <SWPadnos> so as long as the config conforms to some standard (has an ID/magic number in the right range, and a valid function descriptor block), the module loads and inits whatever is needed for what's there
[01:13:25] <jmkasunich> too many topics at one time
[01:13:36] <jmkasunich> lets talk about FPGA config loading, since pete brought it up
[01:13:36] <SWPadnos> all functions load, but only those that are needed are actually used - similar to the PPMC init system
[01:13:39] <SWPadnos> ok
[01:14:04] <jmkasunich> my plan at the moment is for the hal file to look like:
[01:14:26] <jmkasunich> loadusr -w m5i20cfg <bitfile-name> <boardnum>
[01:14:37] <jmkasunich> loadrt hal_5i20
[01:14:55] <jmkasunich> if you have two boards, you could have two loadusr lines
[01:15:00] <jmkasunich> the driver will find all boards
[01:15:12] <SWPadnos> does m5i20cfg check the current config to see if reprogramming is needed, or does it always reprogram the FPGA?
[01:15:17] <petev> sure, but that assumes the user really knows what he's doing and god forbid there is any version problems
[01:15:26] <jmkasunich> it loads a config from a bitfile
[01:15:29] <petev> it uses a module param now
[01:15:32] <jmkasunich> whatever is in there gets wiped and replaced
[01:15:51] <petev> you can tell it not to load the config
[01:15:53] <jepler> will m5i20cfg be made setuid? it requires direct hardware access to program the firmware.
[01:16:06] <jmkasunich> jepler: I suspect so
[01:16:16] <petev> yeah, it's a kludge the way it works
[01:16:24] <jmkasunich> thats a detail right now
[01:16:45] <jmkasunich> what I do NOT want to do is embed many K of some "preferred" config in the driver
[01:16:50] <SWPadnos> sure
[01:17:08] <SWPadnos> I wonder if a pseudo-block driver could be made for the config space, and stuck in the HAL driver
[01:17:18] <SWPadnos> or a separate driver
[01:17:17] <jmkasunich> the new configs have a 256x32 rom/ram in them, that will be used to identify what config is loaded, and what it has in it
[01:17:30] <petev> anything from the RT environment is tough
[01:17:55] <SWPadnos> yeah - a non-RT module would likely be simpler
[01:18:07] <jmkasunich> the config is in a file - user code is good at dealing with files - IMO a user space loader just makes sense
[01:18:26] <jepler> with a few seconds more thought, I don't mind m5i20cfg being setuid
[01:18:30] <petev> only problem is the one now is a bit ugly
[01:18:31] <SWPadnos> with a block device to cat things into, it's even easier
[01:18:45] <jmkasunich> SWPadnos: is it?
[01:19:01] <jmkasunich> you gotta load the block driver, then do the cat, then load the HAL driver
[01:19:28] <SWPadnos> the block driver can be loaded at any time (not necessarily as part of emc)
[01:19:38] <jmkasunich> you want the config present when you load the HAL driver, because when it returns as "loaded", all the pins should be exported
[01:19:41] <petev> I think the user space app can be cleaned up to open a driver and avoid the setuid problem and IOPL stuff
[01:19:42] <SWPadnos> then you can read the config to see if you need to update
[01:19:51] <CIA-6> 03jepler 07TRUNK * 10emc2/debian/ (changelog emc2.files.in): split libemcini and libposemath from libnml
[01:19:51] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/iotask/Submakefile: split libemcini and libposemath from libnml
[01:19:52] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/Submakefile: split libemcini and libposemath from libnml
[01:19:52] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/sai/Submakefile: split libemcini and libposemath from libnml
[01:19:52] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/task/Submakefile: split libemcini and libposemath from libnml
[01:19:52] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/Submakefile: split libemcini and libposemath from libnml
[01:19:56] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/utils/Submakefile: split libemcini and libposemath from libnml
[01:19:56] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/Submakefile: split libemcini and libposemath from libnml
[01:20:00] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/inifile/Submakefile: split libemcini and libposemath from libnml
[01:20:02] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/posemath/Submakefile: split libemcini and libposemath from libnml
[01:20:02] <jmkasunich> * jmkasunich gets boots
[01:20:08] <SWPadnos> heh
[01:21:01] <jmkasunich> can we ignore the mechanics of getting the config into the FPGA? leave it at "some user space process gets run, and when its finished, the config is in there"
[01:21:08] <SWPadnos> yes
[01:21:10] <jepler> yes
[01:21:13] <petev> ok
[01:21:26] <mshaver> do those commits mean what they seem to mean, to me?
[01:21:51] <SWPadnos> they're just in the submakefiles, so "probably, but not all of it" :)
[01:22:01] <mshaver> ok
[01:22:12] <mshaver> but, good!
[01:22:17] <SWPadnos> of course, I'd have to look at them to have a valid comment
[01:22:22] <SWPadnos> (which I haven't)
[01:22:31] <jmkasunich> so, we have a config sitting in the FPGA, and there is a 256x32 ROM at the beginning of the address space
[01:22:39] <mshaver> sorry, you guys carry on...
[01:23:12] <jmkasunich> first few words will be something to say "yep, I'm a 5i20 config, and my ROM format follows version 1.0 of the standard"
[01:23:16] <jepler> the source files are in the same locations, but there are now 3 separate libraries instead of just one libnml
[01:23:36] <petev> nice
[01:23:37] <jmkasunich> good
[01:23:41] <SWPadnos> yay!
[01:23:44] <mshaver> great!
[01:23:54] <jmkasunich> it always bugged me that ini and posemath stuff was considered part of NML
[01:23:59] <mshaver> me too
[01:24:16] <SWPadnos> if I had ever understood it, I'm sure it would have bugged me too :)
[01:24:20] <mshaver> now, to move it to src/emc somewhere
[01:24:36] <jmkasunich> that dates back to the rcslib days - rcslib was "a lib of handy stuff for Realtime Control Systems"
[01:24:50] <jmkasunich> which included ini, posemath, nml, and some other stuff all on one pile
[01:26:17] <SWPadnos> so - do you know what format you want to use to describe functions, or is that up for duscussion now?
[01:26:22] <SWPadnos> or discussion
[01:26:31] <jmkasunich> thats part of it
[01:26:42] <jmkasunich> part of it is just deciding what the files will be named
[01:27:07] <jmkasunich> we have the existing m5i20 (both m5i20.c, m5i20.h, and a m5i20 directory with the existing VHDL in it)
[01:27:14] <jmkasunich> I don't want to break that
[01:27:25] <petev> we still have the old broken FPGA config too
[01:27:29] <jmkasunich> so the "new style" driver and configs need to go elsewhere and be named differntly
[01:27:39] <SWPadnos> how about {function}_m5i20.[ch] for the individual functions
[01:27:54] <petev> better to start with the m5i20_
[01:27:59] <jmkasunich> right
[01:27:58] <SWPadnos> I think there's a subdir under m5i20 already
[01:28:12] <jmkasunich> if they're not in their own directory, then I want them to sort together
[01:28:11] <petev> yes, it has VHLD in it
[01:28:43] <jmkasunich> the new config VHDL (with the ROM) and the new driver need to be completely decoupled from the old
[01:28:44] <SWPadnos> I think separate dirs are a good idea for the 5i20, and I think there's a tree there now
[01:29:01] <petev> the driver is in the main driver dir
[01:29:09] <petev> there is a tree for the VHDL configs
[01:29:15] <jmkasunich> there is stuff everywhere ;-(
[01:29:21] <jmkasunich> driver in the main driver dir
[01:29:26] <petev> not that bad
[01:29:27] <SWPadnos> look under m5i20 - there are additional configs there
[01:29:29] <jmkasunich> fpga loader utility in hal/utils
[01:29:32] <SWPadnos> hostmot_*
[01:29:39] <petev> just delete the old config in the m5i20 dir
[01:29:38] <jmkasunich> vhdl in m5i20/
[01:29:45] <petev> each of the other configs has it's own dir
[01:29:52] <petev> the old one is broken anyhow
[01:29:56] <SWPadnos> right - I think that's the way to go
[01:30:09] <petev> the one in m5i20 is the old one
[01:30:10] <jmkasunich> and then several .h files
[01:30:25] <jmkasunich> petev: we can delete the old vhdl
[01:30:34] <petev> yes, and change the makefile
[01:30:43] <jmkasunich> but not the old bitfile (unless we decide to force people to use the new driver)
[01:30:48] <SWPadnos> stick the misc stuff (loader, common headers) in m5i20/, and each config gets its own subdir under there
[01:30:57] <jmkasunich> I guess thats a key decision - support the old driver, or force a change?
[01:30:57] <petev> no, you can delete the bit file too, it's bad
[01:31:04] <SWPadnos> there's a new bitfile with some bugfixes
[01:31:14] <petev> there is a new version there that works with the driver (at least it should)
[01:31:18] <SWPadnos> or there should be (I think PeteW provided that in the tar)
[01:31:30] <petev> they are all checked in
[01:31:39] <jmkasunich> the problem with the old one is just the extra encoder channels, right?
[01:31:41] <petev> yes
[01:31:50] <jmkasunich> IOW, there might be people using the "broken" one right now
[01:31:51] <petev> but there is a new config that fixes it
[01:31:59] <petev> it's just not being used by the makefile
[01:32:21] <petev> there were some reg bit changes, but I don't think anything that effects the driver
[01:32:26] <jmkasunich> ok, here's the question I want to get answered, before we digress any farther
[01:33:06] <jmkasunich> are we going to have two drivers, one that uses old "style" configs (we have several, the fact that one is broken is irrelevant) and one that uses new style configs (with the ROM in them)
[01:33:22] <jmkasunich> or are we going to deprecate the old style for 2.2
[01:33:46] <petev> will all the new configs still fit in the older boards with smaller FPGAs?
[01:33:49] <SWPadnos> I'd only replace the old style if the new style has identical pinouts
[01:33:57] <jmkasunich> what older boards?
[01:33:58] <SWPadnos> smaller than 200k?
[01:33:59] <petev> good point
[01:34:08] <petev> there were 2 rev boards from what I understood
[01:34:15] <jmkasunich> a config that has the same end results as the existing ones is a given
[01:34:26] <petev> some of the old ones had smaller FPGAs was my understanding
[01:34:46] <jmkasunich> the bitfiles are specific to a device - you can't put a 200K bitfile into a smaller chip
[01:34:54] <jmkasunich> if there is a board with a smaller chip, its already busted
[01:35:11] <petev> as long as the same config (end results) can be put on all the cards in the field, then I see no reason to maintain 2 drivers
[01:35:36] <petev> ok, so everything you're doing fits on 200K devices then?
[01:35:38] <SWPadnos> agreed here
[01:35:40] <jmkasunich> some things will probably be a bit different on the HAL side (pin naming conventions, etc)
[01:35:48] <SWPadnos> that's what we all have for development :)
[01:35:57] <jmkasunich> yeah, today's 5i20 board is the benchmark
[01:36:03] <jmkasunich> someday theres gonna be a 5i22
[01:36:04] <petev> ok
[01:36:21] <jmkasunich> with a fscking huge chip (1.5M gates) and 96 I/O instead of 72
[01:36:41] <jmkasunich> hopefully when that happens the driver will only require tweaking, not a rewrite
[01:36:42] <petev> hmm, maybe peter has taken way longer, I thought he said the larger FPGA version was already shipping last year
[01:36:56] <jmkasunich> no, its still in the future
[01:37:04] <SWPadnos> he has a 400kgate version of some boards, but not the 5i20 that I've seen (on the website)
[01:37:14] <petev> ok
[01:37:16] <jmkasunich> (he was in here yesterday, and I also talked to him on the phone a couple days ago)
[01:37:37] <jmkasunich> he might have decided to skip the 400K generation and go straight to 1.5M
[01:38:13] <jmkasunich> anyway, we're back to the same decision
[01:38:31] <jmkasunich> I can delete the old driver and commit some new code in its place today
[01:38:49] <petev> true, we need svn ;-)
[01:38:47] <jmkasunich> but that code will not provide full functionality quite yet
[01:39:06] <jmkasunich> are you volunteering to set up and maintain the svn server?
[01:39:16] <petev> I already have one running
[01:39:25] <jmkasunich> and to make sure all developers and advanced users have svn on their boxes
[01:39:31] <petev> if you guys want to put up with my bandwidth, no problem
[01:39:34] <SWPadnos> dreamhost offers svn
[01:39:44] <SWPadnos> but we don't get full admin rights, I think
[01:39:46] <jmkasunich> lets not go there (svn in general)
[01:39:56] <petev> there are svn packages for ubuntu and tortoise for doze
[01:39:59] <SWPadnos> well, we can have a repo if we want - that's not the issue
[01:40:07] <petev> lets see what the board says on that
[01:40:36] <jmkasunich> its been less than a year since we decided that forcing all devs to use svn wasn't a good idea
[01:40:43] <petev> how about putting the new driver files in the m5i20 dir?
[01:40:57] <petev> why, I didn't hear about that?
[01:40:59] <jmkasunich> back on topic - you're a good man pete!
[01:41:14] <petev> we can delete the old driver after the new one is working
[01:41:31] <jmkasunich> this was when we switched from sourceforge to our own server - dunno if you were active then
[01:41:31] <petev> there are so many 5i20 files, I think it's own dir is ok
[01:41:46] <petev> yeah, but I didn't hear svn talk
[01:42:07] <jmkasunich> well, we had to decide what to do quickly - the SF downtime was killing us
[01:42:13] <petev> we can delete the old VHDL now and the dir will be clean, with sub dirs for VHDL
[01:42:24] <jmkasunich> the decision to move was made in a couple of days, and implemnetd in a couple more
[01:42:42] <jmkasunich> changing servers was disruptive enough (and gave one person something to gripe about)
[01:42:50] <jmkasunich> changing tools at the same time would have been rough
[01:42:54] <petev> I can guess who
[01:43:12] <jmkasunich> anyway, back to fpgas
[01:43:16] <SWPadnos> there was a reasonable consensus on the point, actually. it wasn't any single person
[01:43:20] <jmkasunich> I agree - m5i20 can contain driver source
[01:43:29] <jmkasunich> and subdirs from there can contain configs (vhdl)
[01:44:00] <jmkasunich> SWPadnos: on which point?
[01:44:20] <SWPadnos> svn
[01:44:50] <jmkasunich> the concensus was "we don't want to do that to our users/developers" I believe
[01:45:12] <petev> hmm, the commands are similar and tortoise is pretty easy
[01:45:18] <petev> anyhow...
[01:45:23] <jmkasunich> wtf is this tortise thing?
[01:45:33] <petev> its a client for doze
[01:45:36] <petev> both cvs and svn
[01:45:40] <jmkasunich> so why do we care about it?
[01:45:47] <jmkasunich> ;-)
[01:45:48] <petev> very nice and integrated with explorer
[01:45:48] <SWPadnos> it's a very nice CVS interface that integrates with the windows shell (explorer, that is)
[01:45:56] <petev> I edit from a doze box
[01:46:02] <jmkasunich> you mean its all pointy clicky?
[01:46:01] <jmkasunich> ewwwww
[01:46:06] <petev> better IDE, etc.
[01:46:19] <petev> yeah, that too
[01:46:24] <petev> but it is nice
[01:46:31] <SWPadnos> well, it lets you see CVS status in the icons in window views
[01:46:34] <petev> has status icons on each file, etc.
[01:46:41] <jmkasunich> I assume that svn can be used properly though? (ie from the command line)
[01:46:46] <petev> yes
[01:46:52] <petev> very similar to cvs
[01:46:52] <SWPadnos> it's very slick, and is one of the better Windows programs out there
[01:46:54] <jmkasunich> sorry, I'm being a wiseass
[01:47:07] <SWPadnos> svn is supposed to be *almost* cvs-compatible in command-line options (I think)
[01:47:28] <SWPadnos> it can be used properly, just no by anyone we know ;)
[01:47:35] <jmkasunich> the biggest difference between now and when we made the server change is a lack of time pressure
[01:47:51] <jmkasunich> before, we needed to solve the SF problem in the least disruptive way possible
[01:48:09] <SWPadnos> well, history is pretty important. if that would be lost in a move to SVN, then I'd bet it's a non-starter
[01:48:18] <jmkasunich> that too
[01:48:35] <petev> yeah, we would have to keep the old cvs as the svn data format is different
[01:48:50] <SWPadnos> I think there are repository porting tools, but I have no idea if they work
[01:48:56] <jepler> most newer-than-cvs systems have some kind of import functionality which keeps old history. I don't know how well it works.
[01:49:02] <petev> it doesn't use RCS
[01:49:05] <jepler> python changed from cvs to svn, for instance
[01:49:09] <jmkasunich> if there is no way to translate/port the history, it ain't gonna fly with most devs
[01:49:11] <jepler> git can import cvs history as well
[01:49:23] <SWPadnos> we should move to git rather than svn
[01:49:24] <petev> hmm, haven't tried that
[01:49:33] <jepler> I think that most of these conversions rely on 'cvsps' so they are of similar quality
[01:49:40] <petev> seeing how the same guy that wrote cvs did svn, maybe it works
[01:49:52] <SWPadnos> it has nice tiongs like a "bisect" command, that can automagically do a binary search through a patchset to find where a bug was introduced
[01:49:57] <SWPadnos> s/tiongs/things/
[01:50:09] <jmkasunich> personally, any change will break a few little scripts that I use (no biggie) and will break the compile farm scripts (more of an issue, they parse CVS output and were a bit of a pain to get working)
[01:51:03] <jmkasunich> one thing I know for sure - any decision needs to be made on the dev list, not by the board alone
[01:51:06] <jepler> personally I don't think there's anything "wrong enough" with cvs to justify changing to something else
[01:51:22] <jmkasunich> I will NOT be accused of trying to force out developers again
[01:51:24] <petev> changing filenames and dir structure is a pain
[01:51:30] <jmkasunich> by certain people who will remain unnamed
[01:51:39] <petev> the only way would be a delete and add and then history is gone
[01:51:56] <SWPadnos> hmm. that's true
[01:52:03] <jmkasunich> my attitude is pretty mich like jepler's
[01:52:19] <jepler> petev: apparently, git preserves history over renames
[01:52:25] <jmkasunich> cvs has some issues, but none severe enough to be worth a major change
[01:52:28] <petev> so does svn
[01:52:31] <petev> and you can move dirs
[01:52:37] <petev> thats the whole point
[01:52:43] <petev> or else I wouldn't care
[01:53:02] <SWPadnos> well, the history thing is important. if Pete wants to split the ini file stuff into two files, then the new files have none of the original history
[01:53:17] <SWPadnos> unless one of them keeps the same name
[01:53:36] <jmkasunich> petev: something to keep in mind - when you do this proposed housecleaning, you will wind up with a house that you understand very well, and that all the oither developers have to stumble around in and rediscover
[01:53:54] <jepler> I also don't want to volunteer chris to set up the version control server again -- it was a lot of work
[01:53:56] <petev> I hope not, the code is a mess now
[01:54:11] <jmkasunich> not saying that might not be worth the effort, but the gain has to be big enough to be worth it
[01:54:14] <petev> I think it can be much better organized and everyone will understand better
[01:54:31] <petev> did you look at matts include graph?
[01:54:41] <jmkasunich> yeah, I know where you are coming from
[01:54:51] <petev> I don't think anyone fulls grasps it
[01:54:52] <jmkasunich> In fact I've stood on the other side of this discussion before
[01:56:32] <petev> how many fof the developers understand OO programming and C++?
[01:57:05] <SWPadnos> about 3, I think
[01:57:10] <SWPadnos> maybe 4
[01:57:11] <jmkasunich> I don't
[01:57:13] <petev> really?
[01:57:20] <jmkasunich> I do not do C++
[01:57:34] <petev> yes, but you do OO and you won't have a problem when you see it
[01:57:35] <jmkasunich> I believe in some of the concepts - such as data hiding, etc
[01:57:54] <jmkasunich> but I don't use C++ and have absolutely no intention of learning it
[01:58:07] <SWPadnos> HAL is completely OO, and if the kernel were friendly to C++, HAL would be about 1/3 the code (maybe less)
[01:58:12] <petev> when you see it, you will pick it up easily
[01:58:18] <jmkasunich> C has been accused of being a high level assembly - I think thats its greatest feature
[01:58:22] <petev> its just a few keyword adiitions to C for you
[01:58:24] <SWPadnos> heh
[01:58:44] <SWPadnos> well, the language is just a little "more" than C, but to do it "right", there's a bit more to it
[01:58:59] <jmkasunich> SWPadnos: the code would be smaller because you'd be relying on little C++ gnomes hiding in some library to do things
[01:59:01] <petev> yes, but jmk already knows how to do it right, that's my point
[01:59:05] <jmkasunich> I don't like that for RT code
[01:59:15] <petev> you can't do it for RT anyhow
[01:59:22] <petev> the environement doesn't support it
[01:59:33] <SWPadnos> you'd be relying on little very well-designed and implemented gnomes to do things (much the same way we rely on the kernel, RTAI, and NML to do things)
[01:59:47] <petev> there is a bunch of C++ stuff in EMC that is a joke
[01:59:52] <SWPadnos> yeah
[01:59:58] <petev> it's only C++ to include the other C++ stuff
[02:00:14] <SWPadnos> from the early days of C++, maintaining compatibility with gcc ans MS VC++
[02:00:40] <petev> some of the libnml stuff is C++ and so the other stuff has to be
[02:00:43] <SWPadnos> the oldest code was win/unix/linux C++
[02:00:46] <SWPadnos> right
[02:00:50] <petev> but that's about the extent of it IMHO
[02:00:55] <SWPadnos> and lots of extern C{ in $ifdefs
[02:01:01] <SWPadnos> #ifdefs
[02:01:01] <petev> yes
[02:01:18] <cradek> as I see it, we have some hard-earned stability that came from the 2.0-2.1 process. I'd like to hear some of everyone's ideas about how reorganization would benefit our users in the short and long term
[02:01:22] <petev> and globals and headers that don't even have the same name as the implementation and other bad practices
[02:01:32] <SWPadnos> it's crappy pseudo-c++, and I'd be very wary of C++ if it were the only example I'd seen
[02:01:42] <petev> agreed
[02:02:28] <petev> cradek, if you like, I did the new interp I was working on with ANTLR and C++
[02:02:31] <SWPadnos> cradek, I'd bet that reorganization will have no near-term benefits for users, but would for developers
[02:02:44] <petev> I can check it in somewhere so people can give their thoughts
[02:02:55] <jmkasunich> petev: forgive me, but I can't see us discarding the NIST interp and replacing it with yours
[02:02:57] <cradek> petev: ok, but that's not an answer to my question
[02:03:05] <petev> I'm not saying that
[02:03:17] <petev> I'm just saying as an example of C++
[02:03:37] <jmkasunich> petev: nobody is disputing the fact that some of the EMC code is absolutely terrible to look at
[02:03:45] <SWPadnos> or understand
[02:03:54] <jmkasunich> but you have to acknowledge the fact that is has tons of testing and use behind it
[02:04:00] <cradek> the interp is some of the most stable and clearly documented code we have
[02:04:10] <petev> after yesterdays discussion, It became apparent that we can't even fix simple stuff like the spindle problem
[02:04:09] <jmkasunich> a major restructure is guaranteed to introduce new bugs
[02:04:20] <SWPadnos> hold on - that's a tangent
[02:04:35] <petev> jmk, I think if structured right, bugs would be minimal
[02:04:36] <jmkasunich> in the long run, the result will probably be a big improvement, but in the short run, EMC will get a lot worse for users before it gets better
[02:04:37] <SWPadnos> pete was offering an interpreter he wrote as an example of better C++ code, not as a replacement (at this stage)
[02:04:53] <petev> I have done many complex embedded systems with very little debugging involved
[02:05:09] <petev> you have to break things down into peices
[02:05:12] <petev> and test each one
[02:05:19] <petev> then put them together
[02:05:29] <petev> you can't do that without clear interfaces
[02:05:31] <jmkasunich> petev: preaching to the choir - HAL is all about that
[02:05:46] <SWPadnos> and it all works if you separate the problems correctly
[02:05:52] <jmkasunich> but the fact remains, some chunks of a machine control just don't break down that easily
[02:06:06] <jmkasunich> there will always be complex interactions between the pieces
[02:06:20] <petev> I have looked at a lot of whats' there and it doesn't look like that big a problem
[02:06:33] <petev> to be honest, I think the hardest stuff is arleady in RT
[02:06:40] <SWPadnos> however, it looks like the original factoring of the problem domain is no longer suitable for the way EMC2 works now, hence the pressure toward a refactor
[02:06:55] <SWPadnos> (was that enough management terms? :) )
[02:07:16] <skunkworks> synergy I tell you - synergy
[02:07:16] <jmkasunich> lets look at the spindle issue
[02:07:22] <petev> ok
[02:07:33] <jmkasunich> its a good example of these complex interactions between motion, task, guis, etc
[02:07:58] <cradek> can someone give me a problem statement - I don't know of a spindle problem
[02:08:12] <jmkasunich> I don't recall all the details from yesterday, but I do not think I heard "thats a perfect way to deal with this, its a shame EMC won't let us do it"
[02:08:18] <petev> I sent an email to the dev list yesterday
[02:08:36] <jmkasunich> cradek: spindle start - you gotta hold off motion until the spindle is up to speed
[02:08:40] <petev> the main problem is motion doesn't wait for the spindle to be up to speed
[02:08:50] <cradek> ok
[02:08:53] <jmkasunich> on some machines that means until the operator has cranked the bport head speed adjuster to the right place
[02:09:04] <petev> or the VFD has ramped
[02:09:25] <SWPadnos> but, as usual, there are complications due to the myriad types of machine we want to support
[02:09:27] <jmkasunich> or the user has manually flipped the spindle on switch
[02:09:31] <cradek> why is that not trivial to fix? it seems a lot like feedhold
[02:09:38] <cradek> feedhold OR tool change loopback
[02:09:40] <SWPadnos> feedhold can be disabled in g-code
[02:09:41] <cradek> we could do it either way
[02:09:48] <cradek> SWPadnos: *like* feedhold
[02:09:52] <jmkasunich> tool-change loopback is the right path IMO
[02:09:53] <SWPadnos> sure
[02:10:06] <cradek> ok so why do we need to switch to svn and move a lot of directories to do that?
[02:10:12] <cradek> and rewrite things in C++?
[02:10:13] <SWPadnos> that was the proposal - add a "spindle-at-speed" input pin
[02:10:13] <petev> but tool change and spindle are different issues
[02:10:37] <cradek> sorry, that was bordering on trolling, but I'm very puzzled
[02:10:38] <jmkasunich> petev: not "tool-change loopback" LIKE tool-change loopback
[02:10:47] <petev> when we went throught it yesterday, it turned out some of the higher level code needed changing
[02:11:05] <petev> no one wanted to touch it or really understood it well
[02:11:09] <jmkasunich> or not, its just easy to go winging off in that direction
[02:11:18] <jmkasunich> we started talking about pre and post conditions
[02:11:30] <SWPadnos> which gets you into interp / task / nml ...
[02:11:31] <jmkasunich> it seems like "spindle at speed" should be a precondition for motion
[02:11:39] <jmkasunich> thats how the original EMC did a lot of its logic
[02:11:56] <SWPadnos> a precondition for some motion - not G0 (as discussed)
[02:12:02] <petev> right
[02:12:16] <jmkasunich> I remember that now - policy stuff
[02:12:26] <cradek> we could easily do that today
[02:12:26] <SWPadnos> which can't be done at the traj level, since it doesn't know the difference between g0 and g1
[02:12:33] <cradek> yes it does
[02:12:38] <jmkasunich> some people will say "G0 is not a cutting move, I should be able to do a G0 while the spindle is ramping up"
[02:12:46] <petev> the motion command struct has a motion type field
[02:12:50] <jmkasunich> others will say "no, hold all motion until spindle is at speed"
[02:12:59] <SWPadnos> oh - we thought it didn't - since they both end p as STRAIGHT_FEED canonicals
[02:13:02] <SWPadnos> s/p/up/
[02:13:06] <cradek> well it does
[02:13:12] <jmkasunich> how?
[02:13:15] <SWPadnos> excellent
[02:13:17] <petev> I don't know how it's used, but I saw it there today
[02:13:29] <jmkasunich> petev: it?
[02:13:38] <petev> the motion type field
[02:13:44] <SWPadnos> the motion type field in the motion command struct
[02:13:44] <jmkasunich> ok
[02:13:44] <cradek> linearMoveMsg.type = EMC_MOTION_TYPE_FEED;
[02:13:48] <petev> I don't know if it's always set right or what
[02:13:50] <cradek> see emccanon.cc
[02:13:58] <cradek> petev: it is
[02:14:12] <jmkasunich> the other one is EMC_MOTION_TYPE_TRAVERSE?
[02:14:17] <cradek> yes
[02:14:23] <cradek> and there's one for tool change motion too
[02:14:31] <cradek> and soon, probably one for rigid taps
[02:14:32] <jmkasunich> ok, I'm not sure whose point is being proved here ;-)
[02:14:49] <jmkasunich> cradek just proved that the rest of us don't understand the code well enough
[02:14:50] <petev> alex said he wanted to do it right ;-)
[02:14:52] <cradek> I just think people declared something impossible without looking at the code
[02:15:17] <SWPadnos> well, alex pasted this:
[02:15:20] <jmkasunich> I know I wasn't looking at code - I was trying to work on a hardware driver ;-)
[02:15:37] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> void STRAIGHT_TRAVERSE(double x, double y, double z,
[02:15:39] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> double a, double b, double c)
[02:15:40] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> {
[02:15:41] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> double vel, acc;
[02:15:43] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> EMC_TRAJ_LINEAR_MOVE linearMoveMsg;
[02:15:45] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> ...
[02:15:46] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> void STRAIGHT_FEED(double x, double y, double z, double a, double b,
[02:15:46] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> double c)
[02:15:48] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> {
[02:15:49] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> EMC_TRAJ_LINEAR_MOVE linearMoveMsg;
[02:15:51] <SWPadnos> [3/4/2007 5:21 PM] <alex_joni> ..
[02:15:54] <SWPadnos> so they looked the same to us ...
[02:16:11] <cradek> ok, so you have to look at how the fields of linearMoveMsg are filled out
[02:16:12] <jmkasunich> I remember that now ;-)
[02:16:24] <cradek> it's ... nearby
[02:16:28] <SWPadnos> yep - it's all Alex's fault!
[02:17:23] <petev> so cradek, back to the cleanup
[02:17:31] <cradek> no, back to the problem statement
[02:17:39] <petev> do you think the code is well organized and understandable now?
[02:18:19] <jmkasunich> IMO, it could be better, but massive changes in the name of making it better will NOT make it better in the short term (or even the mid term)
[02:18:21] <SWPadnos> that's one problem statement (question)
[02:18:23] <cradek> not optimally, I'm sure
[02:18:44] <petev> the problem needs to be sovled for 2 spindle types IMHO
[02:18:52] <petev> for servo and for all others
[02:19:03] <petev> the servo spindle is for the future
[02:19:07] <jmkasunich> servo spindles are not even in the picture
[02:19:11] <petev> as emc doesn't support it now
[02:19:20] <SWPadnos> there should be no difference in tra/task/motion/whatever it's called
[02:19:26] <SWPadnos> traj, that was
[02:19:27] <cradek> I don't see how moving directories will help that.
[02:19:39] <petev> I wanted to do some basic cleanup
[02:19:37] <cradek> I think incremental improvements are great
[02:19:47] <petev> there is INI code and NML everywhere
[02:19:55] <cradek> incremental cleanup is fine too
[02:20:06] <petev> I thought INI should be in one place and a config object passed about
[02:20:10] <SWPadnos> at some point, the code should be refactored. Maybe it's an EMC3 thing, but I think it should be done
[02:20:16] <SWPadnos> it's been discussed for at least 2 years
[02:20:24] <petev> NML only belongs in the comm area between client/server
[02:20:31] <jmkasunich> discussion is easy, doing is the hard part
[02:20:31] <cradek> SWPadnos: if the core team does that, they'll be 2-3 years without a release again.
[02:20:36] <petev> I don't see why comm stuff is all throughout the code
[02:20:38] <jmkasunich> and doing is what breaks things
[02:20:45] <cradek> SWPadnos: not one of our users would want that, and I don't either
[02:20:55] <SWPadnos> I understand that
[02:21:16] <SWPadnos> but we have someone here who is willing to do it, and knows how to do the job
[02:21:21] <cradek> I think making powerful machine control software trumps making a program that is optimally beautiful to the coder
[02:21:32] <SWPadnos> it seems that we should try to figure out how to use that resource well
[02:21:32] <jmkasunich> petev: earlier you said something about breaking a program into individually testable chunks
[02:21:38] <petev> yes
[02:22:02] <jmkasunich> I dunno if you said or I inferred that there also have to be well defined interfaces between the chunks
[02:22:03] <petev> the INI code for instance is all over and duplicated and with bugs
[02:22:12] <SWPadnos> jmk: both
[02:22:13] <jmkasunich> so, define the interfaces
[02:22:15] <petev> that is not re-using a tested peice of code
[02:22:25] <petev> for one I would have a config object
[02:22:39] <jmkasunich> wtf is an config object
[02:22:41] <petev> it reads the files and has an interface for retreiving vars
[02:22:45] <petev> a C++ class
[02:22:56] <petev> you call methods and get the param you want
[02:22:57] <SWPadnos> it's a struct with config info in it, and procedures for getting the data out
[02:23:06] <jmkasunich> the interface for retreiving a var is "gimme_var(section, name)
[02:23:07] <petev> no INI or XML parsing or anything anywhere else
[02:23:10] <SWPadnos> (class == struct)
[02:23:13] <petev> no it's not
[02:23:17] <jmkasunich> why not?
[02:23:22] <petev> then there is a bunch of scanf and other crap
[02:23:29] <petev> with memory leaks and all
[02:23:35] <jmkasunich> that is the implementation of gimme_var
[02:23:41] <jmkasunich> if its busted, fix it
[02:23:45] <petev> thats what we have today
[02:23:49] <jmkasunich> don't invent a fscking class to confuse things
[02:23:54] <petev> and each module opens and reads the file
[02:23:55] <SWPadnos> it's already a class
[02:24:02] <petev> what?
[02:24:09] <petev> there is IniFile class today
[02:24:13] <petev> and it sux
[02:24:15] <jmkasunich> well, one of the several interfaces to the inifile is a class
[02:24:21] <jmkasunich> lord know why
[02:24:24] <petev> and then there is a bunch of code all over
[02:24:34] <petev> it's not well done
[02:24:41] <petev> it could be better
[02:24:41] <SWPadnos> because the interp (also a class) needs to be able to use ini vars?
[02:24:42] <jmkasunich> if you assume that the inifile is human write, program read, then all you need is gimme_var(section, name)
[02:24:52] <petev> and then an EmcIni class should be derived from it
[02:25:13] <petev> what's there now gives you strings
[02:25:22] <jepler> petev: do you have a list of these specific memory leaks or mistaken uses of sprintf? I'd be happy to begin fixing them.
[02:25:25] <jmkasunich> ini vars are strings, of course it gives you strings
[02:25:26] <petev> then you need to covnert to float or int and error check and all that
[02:25:48] <petev> yes, some of the IniFile news are not deleted on errors
[02:26:00] <petev> the error cleanup is a mess
[02:26:08] <petev> much duplicated code there too
[02:26:14] <jmkasunich> if there wasn't a C++ class, there wouldn't be any news
[02:26:23] <SWPadnos> ?
[02:26:24] <petev> jmk: but the code wants ints and floats
[02:26:35] <petev> so it would be malloc
[02:26:37] <petev> whatever
[02:26:40] <petev> the same thing
[02:26:47] <SWPadnos> ah
[02:27:06] <jmkasunich> gimme_var (char *dest, int destlen, char *section, char *name)
[02:27:15] <jmkasunich> no dynamic memory allocation is needed
[02:27:19] <jmkasunich> therefore no leaks
[02:27:24] <petev> we don't have that today
[02:27:55] <petev> jmk, you problem is you are afraid of C++, but what you don't realize is you already know most of it
[02:27:59] <jmkasunich> I'm not arguing that its perfect today, I'm arguing that a C++ class isn't the answer
[02:28:20] <petev> if you saw how the syntax helped you, I think you would like it
[02:28:22] <jmkasunich> I know I don't want dynamic memory allocation unless I ask for it
[02:28:25] <SWPadnos> where in the hell is inivar or inifile?
[02:28:31] <SWPadnos> it should be in the ini/ dir, no?
[02:28:32] <cradek> in the short term, we could fix the bugs...
[02:28:36] <petev> you have to ask for new just like malloc
[02:28:45] <petev> and didn't write the code
[02:28:50] <jmkasunich> src/libnml/inifile.cc
[02:29:00] <SWPadnos> oh, of course
[02:29:07] <petev> no, the leaks are in the emc code, not libnml
[02:29:20] <SWPadnos> I was just looking for the damned thing
[02:29:35] <petev> I think the IniFile class can be extended with some methods to covert to float and int
[02:29:42] <jmkasunich> leaks because the emc code asks for an ini variable and is handed a dynamically allocated string?
[02:29:43] <cradek> you could sure fix Inifile:: incrementally
[02:29:59] <petev> and then an EmcIni derived from it that knows the structure of an EMC INI file
[02:30:10] <petev> yes, absolutely
[02:30:18] <cradek> even with cvs :-)
[02:30:29] <petev> these were ideas for incremental improvement
[02:30:33] <SWPadnos> other than moving it to src/emc/ini :)
[02:30:48] <petev> but some of the header and partitioning is a mess and would be difficult with cvs
[02:31:11] <petev> I could send jepler and email each time to rename a file, but that doesn't seem productive ;-)
[02:31:16] <cradek> in the short and medium term, I suspect we'll have to only do the things that are possible using cvs
[02:31:18] <jmkasunich> SWPadnos: I think we all agree that it would be nice to have inivar.cc in src/ini instead of src/libnml/ini, but it ain't worth changing servers over it
[02:31:26] <SWPadnos> nope
[02:31:26] <cradek> we can't rename files because we have other (stable) branches.
[02:32:05] <petev> hmm, that makes svn even more attractive then
[02:32:16] <jmkasunich> why?
[02:32:24] <petev> it handles going back to revs with other names since it knows about the renames
[02:32:42] <jmkasunich> if you move a file from one dir to another, regardless of the version control system, you now have a file in one place in TRUNK and another place in the 2.1 branch
[02:33:12] <petev> when you checkout the branch it puts stuff in the right place
[02:33:12] <cradek> jmkasunich: that would be the goal, I think
[02:33:12] <SWPadnos> and they're the same file with svn, I think (at least they share the same history)
[02:33:13] <jmkasunich> backporting a patch from trunk to 2.1, or the other way around, isn't gonna be pretty
[02:33:39] <petev> backporting branch development is another issue
[02:33:47] <jmkasunich> its an important issue
[02:33:55] <petev> being able to checkout an old brand and build it is something else
[02:33:55] <jmkasunich> we need to maintain 2.1 and to a lesser extent 2.0
[02:34:02] <jmkasunich> that is every bit as important as progress on TRUNK
[02:34:05] <cradek> I think talking about svn is not useful right now
[02:34:19] <petev> if you have to merge, and you've changed names/dirs it will always be tough
[02:34:31] <cradek> in April the board decided to stick with CVS and today it's the same board in about the same boat (but with a reliable CVS server) :-)
[02:34:42] <jmkasunich> right - so SVN is not the issue - large scale changes is the issue
[02:34:55] <petev> ok, so are you saying we can't rename and move files at all?
[02:35:16] <cradek> that's what I'm saying. You could remove files and make new ones if you have to, but it's best not to.
[02:35:21] <jmkasunich> if moving the ini stuff from one directoy to another has no benefit except making it a little easier to find, there has to be very little downside to make it worthwhile
[02:35:50] <petev> cradek, I don't see the difference
[02:35:57] <SWPadnos> losing history would be a definite downside
[02:36:02] <cradek> petev: then you don't understand cvs
[02:36:13] <petev> if a file is deleted and a new one created, how will that help a merge?
[02:36:51] <cradek> I wasn't talking about merge - I was talking about not destroying all the non-trunk branches
[02:36:57] <jmkasunich> petev: cradek is saying that moving stuff around is not a good idea
[02:37:18] <petev> moving stuff in cvs doesn't work, we all agree to that
[02:37:20] <jepler> some people advocate doing a "cvs rename" by moving the RCS file around in the repository -- that's an absolute "do not do this"
[02:37:21] <SWPadnos> that's what petev has been saying all along
[02:37:25] <jmkasunich> svn makes it a _little_ better, but there are still plenty of reasons not to do it, like branches
[02:37:28] <cradek> ok
[02:37:51] <petev> I thought jmk was saying we needed to backport a branch too?
[02:37:57] <jmkasunich> petev: you are saying "moving stuff in cvs = bad", I'm saying "moving stuff = bad"
[02:38:13] <SWPadnos> moving stuff in svn is "less bad" ...
[02:38:19] <jmkasunich> moving stuff = bad
[02:38:29] <petev> jmk I agree with the first part
[02:38:41] <jmkasunich> you gotta show a very large benefit before it outweighs the bad
[02:38:51] <jmkasunich> svn only reduces that a little bit
[02:39:06] <petev> what is the bad? difficulty in backporting?
[02:39:19] <jmkasunich> yes
[02:39:21] <cradek> switching servers and retraining the developers is a bad
[02:39:24] <jmkasunich> general maintainence issues
[02:39:31] <SWPadnos> argh
[02:39:49] <petev> major changes will always make backporting difficult
[02:39:58] <petev> cradek, have you used svn?
[02:40:03] <cradek> no
[02:40:11] <jmkasunich> and therefore major changes have to offer major benefits to outweigh that
[02:40:28] <jmkasunich> fixing the spindle problem does not require major changes
[02:40:30] <petev> it's very similar to cvs
[02:40:37] <petev> I think the learing curve is minimal
[02:40:38] <jmkasunich> fixing the inifile problems should not require major changes
[02:41:13] <SWPadnos> 1) a shitload of work would need to be done to EMC to make it viewable by mortals. this would provide little to no end-user benefits in the short term, but hopefully some good developer benefits in the mid- and long terms
[02:41:17] <jmkasunich> petev: are you volunteering to fix the half dozen wiki pages that tell people how to do a cvs checkout?
[02:41:32] <jmkasunich> theres a lot more infrastructure here than just a few developers
[02:41:38] <SWPadnos> 2) some of the problems recently identified can be fixed in an incremental way that breaks no naming or versioning systems
[02:41:48] <cradek> I say yay for #2
[02:41:56] <petev> why would we have checkout info in 1/2 dozen places?
[02:42:02] <jmkasunich> I agree with both 1 and 2
[02:42:09] <jmkasunich> because wikis evolve
[02:42:10] <SWPadnos> 3) exploration of furture upgrades to both the functionality, code, and maintenance of EMC should always be explored, but carefully considered before implementation
[02:42:14] <jmkasunich> documentation evolves
[02:42:33] <petev> and it will evolve to be correct again
[02:42:34] <jmkasunich> if you think the code is bad - the wiki is worse
[02:42:52] <petev> there is plenty now that is not, but we shouldn't stop all dev work until it's all correct
[02:43:02] <jmkasunich> petev: you're not proposing evolution, you're proposing intelligent design ;-)
[02:43:11] <SWPadnos> heh
[02:43:21] <SWPadnos> if only we had some of that
[02:43:21] <cradek> petev: can you start the most important of these incremental changes now?
[02:43:23] <SWPadnos> :)
[02:43:40] <petev> I think INI file stuff is faily straight forward
[02:43:49] <petev> NML is going to be a little more painfull
[02:43:58] <jmkasunich> lets start small ini
[02:44:08] <petev> the NML change may be easier to do with a refactor
[02:44:12] <jmkasunich> btw, there needs to be a C interface to the ini stuff
[02:44:17] <jmkasunich> because halcmd reads the ini file
[02:44:22] <jmkasunich> and halcmd is C
[02:44:45] <petev> well, it must have a wrapper now, as the base class is C++
[02:44:52] <SWPadnos> even the C interface should be asked for a particular type, and should do all error checking / parsing of the string for the "client"
[02:45:04] <petev> BTW, some of the motion init is C++ for just this reason
[02:45:17] <SWPadnos> there's a single function at the end of inifile.cc
[02:45:24] <jmkasunich> hal treats all inifile vars as strings, there is no reason to typecheck
[02:45:36] <SWPadnos> that returns an ini var as a string (everything after the "=" is returned)
[02:45:39] <jmkasunich> (it does variable substitution in a hal file before exectuing the commands)
[02:45:41] <SWPadnos> it shouldn't do that
[02:45:41] <petev> I wasn't even considering HAL config files
[02:46:02] <SWPadnos> ah - right. strings are good for halcmd
[02:46:06] <petev> I don't think the HAL stuff needs fixing right now
[02:46:08] <jmkasunich> I didn't say anthing about HAL files
[02:46:21] <petev> so you mean the motion stuff?
[02:46:28] <SWPadnos> that's one of the main things that's been discussed, actually - getting whole configs into single files
[02:46:42] <jmkasunich> hal cmd reads a hal file - the hal file syntax allows inifile variable substitution, so you can write something generic in the hal file and the actual value comes from the ini
[02:46:43] <SWPadnos> HAL files can use ini vars as config items
[02:46:59] <jmkasunich> halcmd implements a scripting language
[02:47:16] <jmkasunich> that will NOT go away if I have anything to say about it
[02:47:19] <petev> so as long as the INI format stays the same, it will still work, no?
[02:47:23] <SWPadnos> that's all the "[AXIS_0]P" kind of stuff in the HAL files
[02:47:46] <SWPadnos> as long as halcmd can still ask for a string from a section and varname, it will work
[02:48:05] <jmkasunich> as long as halcmd, a C program, can call gimme_var(char *dst, int len, char *section, char *name) or something like it, Its ok
[02:48:05] <petev> I will have to look at the halcmd code and see what it's calling for parsing
[02:48:14] <jmkasunich> but that is not and cannot be a C++ class
[02:48:30] <petev> the code emc uses now is already C++
[02:48:38] <petev> so I don't know what halcmd uses
[02:48:50] <SWPadnos> it does its own parsing, partly die to the various hal types
[02:48:53] <cradek> inifile.cc:iniFind is C
[02:48:57] <jmkasunich> this one:
[02:48:58] <jmkasunich> const char *iniFind(void *fp, const char *tag, const char *section)
[02:49:09] <SWPadnos> halcmd probably uses only inifind, which is in the bottom of inifile.cc
[02:49:22] <petev> so I guess we have even more duplication of INI code than I have found already
[02:49:27] <SWPadnos> it's declared as a C or extern C { function in inifind.hh
[02:49:47] <SWPadnos> yep - it's even duplicated in the same file :)
[02:49:55] <jmkasunich> any sane implementation would do one by calling the other
[02:50:08] <SWPadnos> well, sort of
[02:50:39] <petev> jmk, worst case you could change the .c to .cc and call the C++ code ;-)
[02:50:45] <petev> motion does this now
[02:50:54] <jmkasunich> char *Inifile::skip_white(char *string)
[02:50:56] <jmkasunich> static char *skipwhite(char *string)
[02:51:02] <jmkasunich> that is just dumb
[02:51:23] <jmkasunich> * jmkasunich should stay out of this discussion - I hates classes with a passion
[02:51:24] <cradek> cvs diff -r1.17 -r1.18 inifile.cc
[02:51:40] <cradek> ^^ for a good laugh
[02:51:43] <petev> jmk, what is the difference between a class and an object to you?
[02:51:55] <petev> you uses objects in HAL all the time
[02:51:58] <jmkasunich> neither one is relavent here
[02:52:12] <jmkasunich> its a flipping string and you want to skip the whitespace
[02:52:23] <petev> a class instance is an object in C++
[02:52:36] <jmkasunich> why does everything have to be an object?
[02:52:45] <petev> I'm not saying any of the C++ in emc is done right
[02:52:46] <SWPadnos> it's just a different name, for the most part
[02:52:51] <petev> wo I won't argue that
[02:53:09] <petev> the objects define the data and the functions that operate on it
[02:53:15] <petev> they make the interfaces clear
[02:53:32] <jmkasunich> lets just agree to disagree, okj
[02:53:45] <SWPadnos> (proper) ini handling would make the code much more readable - you could do things like assign a float like P=iniread(sectionname, varname);
[02:53:57] <petev> ok, but you already do OO in the HAL so I don't understand why you have a mental block for C++
[02:53:59] <jmkasunich> iniread_float(file, section, name)
[02:54:03] <SWPadnos> and it would throw an error if that var isn't a float
[02:54:30] <jmkasunich> because I don't know what it means, and its trying to be smarter than me
[02:54:34] <cradek> in C: float p = iniget_float(section, var);
[02:54:33] <petev> jmk, where's the error handling in that?
[02:54:52] <cradek> * cradek shrugs
[02:54:55] <jmkasunich> cradek: gotta tell it the file too
[02:54:58] <cradek> whatever
[02:55:10] <petev> all the more reason for a class
[02:55:24] <jmkasunich> petev: why is that a reason for a class?
[02:55:26] <petev> all that is taken care of without globals all over or having to pass more args
[02:55:39] <petev> the class can store it's private data
[02:55:41] <jmkasunich> the class instance is an arg that is being passed
[02:55:50] <petev> it's hidden
[02:55:54] <jmkasunich> so, its still being passed
[02:55:55] <petev> you don't see it in the code
[02:56:04] <SWPadnos> note that the C ini functions reread the file every time
[02:56:06] <jmkasunich> that's supposed to be a good thing?
[02:56:19] <SWPadnos> minor with fast CPUs and large disk caches
[02:56:22] <petev> yes, but I can construct an EmcIni object giving it the file name
[02:56:24] <petev> then I can pass it around
[02:56:38] <petev> now I don't need that filename all over th code
[02:56:43] <jmkasunich> so you have "open", "get_var", and "close" calls that act on the file
[02:57:00] <jmkasunich> and you pass what is essentially a file handle
[02:57:03] <jmkasunich> fine, I like that
[02:57:17] <SWPadnos> yoiu'd probably have a class that reads all vars once, then hands them out when asked by name
[02:57:17] <jmkasunich> why try to hide the fact that you are passing a handle around
[02:57:20] <petev> I would pass the object pointer
[02:57:27] <petev> then call methods to extract the vars
[02:57:32] <jmkasunich> I used "handle" as a generic term
[02:57:43] <SWPadnos> ok, so it's the same thing, what's the problem?
[02:57:48] <petev> jmk, it's all about layering and information hiding
[02:57:51] <jmkasunich> object pointer is just another way of saying "a handle for an instance of this object"
[02:58:00] <SWPadnos> if the code does the same thing, but is easier to read and maintain, it's better code
[02:58:03] <petev> if you don't, complex problems become a mess
[02:58:29] <jmkasunich> ok, what is the C++ syntax for opening the inifile, getting a var from it, and closing it?
[02:58:48] <petev> you wouldn't have to do the open/close in each module
[02:58:49] <SWPadnos> you wouldn't do that from a client function
[02:58:54] <petev> just get the vars
[02:59:01] <jmkasunich> then who opens it?
[02:59:05] <jmkasunich> and when?
[02:59:08] <petev> the C++ destructor could take care of close
[02:59:10] <jmkasunich> and when does it get closed>?
[02:59:15] <SWPadnos> the class would do that the first time it's referenced
[02:59:21] <petev> and constructor or Init() opens it
[02:59:21] <jmkasunich> show me the syntax
[02:59:24] <SWPadnos> and the close is done at destruction time
[02:59:40] <petev> pEmcConfig->GetMaxVelocity();
[02:59:47] <petev> stuff like that
[03:00:14] <SWPadnos> client code: myvar = myIni->Read("section", "name");
[03:00:28] <SWPadnos> (for the more C-like crowd)
[03:00:32] <jmkasunich> client code is the guy who's calling it, right?
[03:00:47] <petev> pEmcConfig could be on the stack in task main() or newed or whatever
[03:01:05] <jmkasunich> ok, lemme do the C version, then you splain to me the C++ version
[03:01:09] <petev> you could have EmcConfig emcConfig;
[03:01:10] <SWPadnos> we have to be able to support as-yet-unknown ini cars, so having a func like getMaxVelocity(axisnum) wouldn't work generically
[03:01:15] <jmkasunich> cause right now you might as well be speaking greek
[03:01:19] <petev> the pass &emcConfig to the modules
[03:01:20] <cradek> so when you add a possible field in the ini, you have to enlarge this object and add accessor functions?
[03:01:21] <SWPadnos> s/cars/vars/
[03:01:31] <jepler> OK, let's just draw the line in the sand at hungarian notation
[03:01:36] <jmkasunich> ini_file_t *foo;
[03:01:36] <cradek> haha
[03:01:40] <SWPadnos> bork bork bork
[03:01:39] <petev> the EmcConfig, not the IniFile
[03:01:52] <jmkasunich> foo = ini_open("blat.ini");
[03:01:52] <petev> and you have to do it now in multiple places
[03:02:11] <petev> jepler, I'm with you on that
[03:02:16] <jmkasunich> stuff = ini_get("[FOO]", "bar");
[03:02:19] <petev> I use p for pointer and that's it
[03:02:24] <jmkasunich> repeat as needed
[03:02:36] <jmkasunich> and use ini_get_float(), ini_get_str(), etc
[03:02:45] <jmkasunich> then ini_close(foo)
[03:02:52] <cradek> I don't see why C makes you code the open everywhere
[03:02:57] <cradek> there's only one ini per run
[03:03:08] <petev> jmk, ther is no error handling in that and every module is opening and closing and needs filename
[03:03:14] <jmkasunich> there are half a dozen processes that have absolutely no connection
[03:03:31] <petev> cradek, every module does an open/close now
[03:03:43] <jmkasunich> emc is not A program, its a bunch of programs
[03:03:51] <jmkasunich> running in separate address spaces
[03:04:04] <jmkasunich> I don't see how each one can avoid opening the ini file
[03:04:05] <petev> I only see 3, UI, task, and IO
[03:04:12] <jmkasunich> halcmd
[03:04:21] <petev> thats not required
[03:04:26] <jmkasunich> during startup it sure as hell is
[03:04:40] <jmkasunich> it is what parses the hal file and does _all_ the hal config
[03:05:09] <SWPadnos> it's trivial to have halcmd do ini var reading - it only uses strings
[03:05:21] <jmkasunich> sure its trivial - thats how it works now
[03:05:31] <SWPadnos> it can't use other types because the type isn't known at read time
[03:05:50] <SWPadnos> it's trivial whether it's C or C++, so that's a moot point
[03:05:50] <jmkasunich> but your whole point seems to be that there should be some single "thing" thats managing ini access
[03:06:10] <petev> yes, it should be in one place in the code, ideally
[03:06:10] <SWPadnos> that would be ideal, though I don't understand how it would work across processes either
[03:06:19] <jmkasunich> halcmd is a separate process, gui is a separate process, task is a separate process, and motion (which also needs ini info) is in kernel space
[03:06:24] <SWPadnos> what I wuold like would be to eliminate code like this though:
[03:06:28] <petev> that minimizes duplicated code, allows re-use of tested code, etc.
[03:06:38] <SWPadnos> if (NULL != (inistring = axisInifile->find("MAX_LIMIT", axisString))) {
[03:06:39] <jmkasunich> is should be the same SOURCE in all those places
[03:06:40] <SWPadnos> if (1 == sscanf(inistring, "%lf", &limit)) {
[03:06:41] <SWPadnos> // found, and valid
[03:06:43] <SWPadnos> } else {
[03:06:44] <SWPadnos> // found, but invalid
[03:06:46] <SWPadnos> if (EMC_DEBUG & EMC_DEBUG_INVALID) {
[03:06:47] <petev> we are talking about code, not instances of it running
[03:06:47] <SWPadnos> rcs_print_error
[03:06:47] <SWPadnos> ("invalid inifile value for [%s] MAX_LIMIT: %s\n",
[03:06:50] <SWPadnos> axisString, inistring);
[03:06:51] <jmkasunich> but it will be different instances, and each will have to open the file
[03:06:50] <SWPadnos> }
[03:06:52] <SWPadnos> limit = 1;// default for max limit
[03:06:53] <SWPadnos> }
[03:06:55] <SWPadnos> } else {
[03:06:57] <SWPadnos> // not found at all
[03:06:58] <SWPadnos> limit = 1;// default for max limit
[03:07:01] <SWPadnos> if (EMC_DEBUG & EMC_DEBUG_DEFAULTS) {
[03:07:03] <SWPadnos> rcs_print_error("can't find [%s] MAX_LIMIT, using default\n",
[03:07:03] <SWPadnos> axisString);
[03:07:04] <SWPadnos> }
[03:07:07] <SWPadnos> }
[03:07:09] <SWPadnos> that is one single var read in iniaxis.cc
[03:07:20] <jmkasunich> well that is just dumb
[03:07:20] <petev> jmk, that's fine
[03:07:31] <petev> you run ls in different dirs don't you?
[03:07:43] <petev> you don't write a new ls for each dir?
[03:07:57] <jmkasunich> a few minutes ago, you wanted to know why I was opening the file
[03:08:05] <jmkasunich> I told you - I'm a separate process, I gotta open the file
[03:08:14] <petev> but there are multiple opens in emc now that don't need to be there
[03:08:28] <jepler> jmkasunich: you're not thinking big enough. maybe we could have some kind of daemon process (let's call it "lsd" as a working name)
[03:08:40] <jmkasunich> well, thats emc's bug - calling open too many times can be done just as easily with a class as with a C open_ini function
[03:08:42] <jepler> jmkasunich: you'd parse /etc/services to find out how to connect to it, send an xml formatted SOAP request, and await a response
[03:08:50] <cradek> troll!
[03:08:58] <SWPadnos> ^2
[03:09:07] <jmkasunich> ^3
[03:09:09] <petev> do u guys want to clean up the code or not?
[03:09:11] <jepler> sorry -- but I hope the idea of "lsd" was funny enough
[03:09:46] <SWPadnos> I think we should wash out jeplers mouth (and keyboard) with SOAP
[03:09:52] <jmkasunich> I want to clean up the bad stuff
[03:09:54] <cradek> incrementally, without changing servers, without wholesale breakage, yes
[03:10:12] <jmkasunich> I do not see classes as riding in on a white stallion and making things all better
[03:10:37] <jepler> yay I just finished getting rid of the errors on dh_shlibdeps when building the package
[03:10:46] <petev> jmk, why don't you give me an example problem and I'll write some C++ for you
[03:11:03] <petev> the base of EMC is already C++, so I don't really see the objection
[03:11:09] <petev> all of the NML is C++
[03:11:28] <petev> if you let me get rid of that I'll write C code for you ;-)
[03:11:37] <jmkasunich> the base of the parts of EMC that I don't work on are C++
[03:11:46] <jmkasunich> I don't work on them because they are C++
[03:11:55] <SWPadnos> not that there's any bias there ;)
[03:11:59] <petev> no, because they are poorly written
[03:12:05] <jmkasunich> hey, I'm not claiming to be unbiased
[03:12:10] <SWPadnos> heh
[03:12:43] <cradek> that's mostly autogenerated code that no longer autogenerates - now we wade through it
[03:12:48] <jepler> but it doesn't run -- bah, there are always trade-offs
[03:13:00] <cradek> but the number of minutes that costs me every day is ~ 0
[03:13:11] <cradek> I'd be happy if it were better
[03:13:18] <petev> well I look at stuff and still scratch my head
[03:13:25] <petev> like what is all that estop crap in task?
[03:13:59] <cradek> but if we have to make emc3 and not have any improvements (that let our users do things with their machines) for two years, I say a great big "no way"
[03:14:20] <petev> 2 years?
[03:14:26] <petev> I'm thinking 2 weeks
[03:14:40] <jmkasunich> get serious
[03:14:59] <petev> if we doled out tasks to everyone, there is not that much to do
[03:15:05] <cradek> you think you can make emc3 with the comm layers cleaned and replaced in 2 weeks?
[03:15:05] <SWPadnos> he did a new interpreter in 2 hours or so, and tweaked it in 2 days, as I recall
[03:15:13] <petev> 2 days
[03:15:34] <petev> cradek, I think the dev team could
[03:15:36] <jmkasunich> and has it been tested for all the corner conditions and strange g-code that people throw at the emc interpreter?
[03:15:43] <petev> with one person it would take longer
[03:15:51] <jmkasunich> petev: I have a day job
[03:15:52] <cradek> petev: I think you're crazy then
[03:16:03] <cradek> sorry, but I have to be honest
[03:16:05] <petev> jmk, I will send you a standalone if you want to try it
[03:16:08] <jmkasunich> it has taken me two weeks to write a driver for the 5i20 board
[03:16:25] <petev> it parses all of the emc gcode I could find and is coded to kramers spec
[03:16:26] <cradek> petev: half or more of the core team doesn't know C++ very well
[03:16:26] <jmkasunich> no, I don't want to try it, I want to finish this driver, and write some VHDL
[03:16:55] <SWPadnos> I think there are 3 or 4 who know C++
[03:16:55] <jmkasunich> I'm hardly qualified to test an interp anyway, I know about 5 g-codes
[03:17:00] <petev> so how many do we have that could code if the C++ classes were defined for them?
[03:17:03] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/Submakefile: 'import so' failed
[03:17:17] <SWPadnos> I could do some of it
[03:17:23] <SWPadnos> this week even
[03:17:52] <jmkasunich> petev: does your interp do 'o' words?
[03:18:10] <petev> no, that's not standard use, it's kramers spec only
[03:18:19] <cradek> does it do radius comp?
[03:18:22] <petev> but they could be added if people wnat it
[03:18:29] <petev> yes
[03:18:35] <cradek> lathe tool comp?
[03:18:39] <jmkasunich> what does it output? canonicals?
[03:18:56] <petev> the par that is not finished is making cannonical calls and that interface wasnt complete
[03:19:09] <CIA-6> 03jepler 07TRUNK * 10emc2/debian/ (shlibs.pre changelog emc2.files.in rules.in): fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:12] <CIA-6> 03jepler 07TRUNK * 10emc2/src/ (Makefile Submakefile.skel): fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:13] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/iotask/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:15] <petev> jmk, yes I started a cannonical class
[03:19:16] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:16] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/sai/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:17] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/task/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:20] <CIA-6> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:25] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:27] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/classicladder/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:30] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/components/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:34] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/devices/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:37] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/user_comps/vcp/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:41] <CIA-6> 03jepler 07TRUNK * 10emc2/src/hal/utils/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:47] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:50] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/inifile/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:52] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/posemath/Submakefile: fix up debian package build, including getting rid of the dpkg-shlibdeps warningerrors
[03:19:58] <CIA-6> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[03:20:13] <jmkasunich> Matt just got the standalone interp working again (I think) - it reads g-code and prints the canoncials that the integrated interp would have called)
[03:20:24] <petev> that I have
[03:20:32] <jmkasunich> (actually I think it calls the canonicals, but they are stubs that just print)
[03:20:35] <petev> I have a main that will run standalone
[03:20:45] <jmkasunich> make a version of your interp that slots in just like the standalone
[03:20:53] <jmkasunich> and compare their output
[03:21:19] <petev> well, that would require changing my interp or the emc code as mine is a C++ class
[03:21:41] <petev> but I can run it standalone and compare canonical output
[03:21:47] <SWPadnos> the emc interp is also a class, if it's based on the one on the later BDIs
[03:22:10] <jepler> it's a class only in the sense that the "class" keyword can be found in the relevant source file
[03:22:11] <petev> I'll have to look again, last I looked it wasn't
[03:22:14] <SWPadnos> right
[03:22:19] <jmkasunich> but of course no two C++ programmers ever agree on the class interface
[03:22:40] <petev> I tried to follow kramer interp spec
[03:22:38] <SWPadnos> the idea was to eventually allow a STEP interpreter or an STL interpreter (or whatever) to be stuck in there instead
[03:22:48] <petev> it was the only decent spec I could find
[03:22:49] <jmkasunich> so petes interp class and the emc interp class are not interchangable
[03:23:10] <petev> mine uses a base class with virtuals
[03:23:11] <SWPadnos> that's way easierto see than if two C programers don't agree on what a void pointer points to
[03:23:27] <jmkasunich> void pointers don't point to anything
[03:23:28] <petev> that was any type of interp could be used without changing other emc code
[03:23:33] <jmkasunich> you cast em before you use em
[03:23:38] <SWPadnos> void pointers point to anything
[03:23:46] <jmkasunich> we digres
[03:24:00] <SWPadnos> sure, and if there's no agreement on what they're pointing to, your program explodes but the compiler says nothihng
[03:24:05] <steves_logging> steves_logging is now known as steve_stallings
[03:24:09] <SWPadnos> in C++, the compiler complains
[03:24:11] <jmkasunich> I'd like to see the two interps running a pile of code with G92s and tool offsets and such in there
[03:24:50] <petev> jmk, I don't follow what you want?
[03:24:54] <jmkasunich> we still find a few bugs in the emc interp once in a while - cases that nobody has ever touched, or have never looked at carefully enough to realize that its wrong
[03:25:06] <petev> are you saying you want my interp to interface to the current emc code?
[03:25:08] <jmkasunich> I just can't see how a 2 day project can possibly be more robust than that
[03:25:19] <cradek> I don't think petev said it was
[03:25:37] <SWPadnos> jmkasunich, consider a trivial HAL component made with comp. sum2, for instance
[03:25:41] <jmkasunich> he said fixing emc is a two week project, and put the 2 day interp in the table as evidence
[03:25:45] <cradek> let's not argue for the sake of arguing please? I think we all love to do that
[03:25:46] <jmkasunich> I'm not buying it
[03:25:52] <cradek> jmkasunich: ok, I see your point
[03:25:53] <SWPadnos> take 10 minutes and write it in comp, or a few hours and write it in C - which is more robust?
[03:26:05] <petev> I said 2 weeks for the dev team
[03:26:08] <petev> not me alone
[03:26:30] <petev> to be honest, I think the task code is way more complex than needed
[03:26:34] <jmkasunich> hours are a better unit of time
[03:26:39] <SWPadnos> that schedule would require a very well-defined spec beforehand, and probably a skeleton class that devs could fill out
[03:26:45] <jmkasunich> because 2 weeks for one person might be 100 hours, and for another might be 10
[03:26:58] <petev> I see the top layer as an NML server that interfaces to HALUI, Axis, etc.
[03:26:59] <cradek> well I'm interested in something else right now actually
[03:27:08] <petev> I'm talking full days of work
[03:27:17] <cradek> I don't see anything like a commitment from the whole team
[03:27:18] <petev> if you want part time stuff then extend the time
[03:27:27] <jmkasunich> you aren't getting that from the core developers
[03:27:31] <jmkasunich> part time is a given
[03:27:33] <SWPadnos> oh - I forgot to mention that of the 3 or 4 devs who know C++, at least one doesn't like it :)
[03:27:55] <cradek> SWPadnos: you forget: nobody likes C++
[03:28:05] <SWPadnos> actually, I like it
[03:28:05] <cradek> (troll!)
[03:28:11] <SWPadnos> bastid!
[03:28:13] <petev> well I don't want to fight about it, if nobody want to refactor the upper layers than so be it
[03:28:17] <CIA-6> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build PASSED
[03:28:47] <cradek> petev: I think the inifile changes would be good
[03:29:02] <jmkasunich> I would like it to be better, but I see the "work in" to "benefits gained" equation balancing far differently than you do
[03:29:23] <petev> hmm, I guess that's what Paul thought about HAL too
[03:29:29] <cradek> petev: I think rewriting NML would be like swimming in mud, and I don't really see the payoff
[03:29:43] <petev> I see many gains and improvements to be made on the upper layers
[03:29:56] <petev> cradek, I don't want to touch NML
[03:30:02] <petev> I want to quarantine it
[03:30:11] <petev> it's all over the code now
[03:30:15] <jmkasunich> petev: don't think I don't realize that some of what I'm saying this evening sounds alot like what he said a year or two ago
[03:30:19] <petev> it only belongs in the comm
[03:30:57] <steve_stallings> <soapbox>
[03:30:57] <steve_stallings> We are losing the distinction between "emc" and "emc-devel" channels. Yes, developers generate most of the traffic on both, but tend to discuss extremely technical stuff related to coding improvements on the plain "emc" channel.
[03:30:57] <steve_stallings> IRC is great for promoting good communication, but I fear that all the developers discussion on the regualar "emc" channel is going to intimidate or scare off users who might otherwise begin to utilize the channel to enhance their ability to USE the EMC software as opposed to worry about altering it.
[03:30:57] <steve_stallings> We have a developer's channel, lets use it when discussing EMC development as opposed to installation, integration, and use of EMC.
[03:30:59] <steve_stallings> And while on the soapbox, would compile farm messages be better moved to "emc-devel"?
[03:31:01] <steve_stallings> </soapbox>
[03:31:28] <jmkasunich> hi steve_stallings ;-)
[03:31:42] <cradek> you sure know how to make an entrance
[03:31:42] <jmkasunich> I thought about suggesting a move (about 2 hours ago)
[03:31:44] <steve_stallings> What, no boo - hiss
[03:32:13] <jmkasunich> compile farm messages go the same place where commit messages go - they go thru the same CIA bot
[03:32:24] <steve_stallings> Sorry, been holding back waiting for a pause in the heavy, but useful discussion...
[03:32:50] <jmkasunich> and I for one like the commit messages here - lets people know we're doing more than talking
[03:32:52] <jmkasunich> or at least jepler is
[03:32:59] <cradek> haha
[03:33:00] <jepler> *snort*
[03:33:24] <jmkasunich> I haven't written a line in the last two hours
[03:33:27] <cradek> I fixed a bug tonight
[03:33:29] <jmkasunich> unless you count IRC
[03:34:54] <jmkasunich> petev: lets go back to the inifile thing
[03:35:02] <petev> u want to switch to dev?
[03:35:07] <jmkasunich> good idea
[03:35:11] <petev> ok
[03:35:40] <steve_stallings> My soapbox issue is that the deveolpers already have a community, its time we gave users a chance to create one also.
[03:35:49] <steve_stallings> developers even...
[03:36:01] <SWPadnos> hey - if you want to talk to developers, do it in the dev channel
[03:36:04] <SWPadnos> ;)
[03:51:33] <K`zan> Gee, I thought this channel was for users to meet and chat.
[03:51:54] <cradek> It is - steve_stallings kicked us back on track
[03:52:28] <K`zan> Those 1" steel rounds I got a great deal on, I think are stainless based on all the bitching my HSS cutoff tool is doing :-/.
[03:52:57] <K`zan> Why can't devs and users coexist here, seems to have been working that way for quite some time.
[03:54:22] <K`zan> Yow, carbide cutoff tools ain't cheap :-(.
[04:17:00] <steve_stallings> Devs would not abandon this channel, just not discuss highly technical software coding issues here.
[04:30:28] <K`zan> I suppose that I am the only one who doesn't care if they do.
[04:33:15] <steve_stallings> Probably not, many coders here, but my concern was for those who are not coders, just users.
[04:35:15] <jmkasunich> steve_stallings is right - we started one discussion at 20:00 (my time) and its still going on -devel
[04:35:21] <K`zan> I don't see the significance of the separation, so far it has been working.
[04:35:39] <jmkasunich> nobody would be able to discuss carbide tools or stainless barstock here if we were still going at it here
[04:35:45] <K`zan> Never know, I might learn something :).
[04:35:53] <SWPadnos> how's your C++?
[04:35:56] <jmkasunich> btw, its 23:35 her enow
[04:36:00] <jmkasunich> here now
[04:36:09] <K`zan> Interesting, multiple conversations going on rather continuously in other channels.
[04:36:20] <jmkasunich> K^zan you are always welcome to join #emc-devel
[04:36:23] <jmkasunich> its not private or anything
[04:36:26] <K`zan> * K`zan loathes the joke C++ ;-)
[04:36:30] <jtr> Actually, I was enjoying the discussion, and I still am, just over on the dev chan. I don't feel I can add value to that discussion, but I'm listening.
[04:36:59] <K`zan> I wasn't even aware there was a dev channel :-).
[04:37:08] <K`zan> See, I did learn something :-)!
[05:22:04] <steve_stallings> steve_stallings is now known as steves_logging
[05:51:32] <alex_joni> morning all
[05:53:01] <cradek> haha hi alex
[05:53:23] <cradek> why am I not in bed you might ask? I wonder that too
[05:54:09] <alex_joni> why am *I* not in bed?
[05:54:15] <alex_joni> :-P
[05:54:18] <cradek> yeah it's pretty early for you, isn't it
[05:54:26] <alex_joni> just before 8
[05:54:34] <cradek> don't you dare complain about that :-)
[05:54:35] <alex_joni> not _that_ early actually
[05:54:52] <alex_joni> * alex_joni smiles
[05:56:49] <alex_joni> darn you guys talk a lot
[05:56:59] <crepincdotcom> * crepincdotcom is in canada
[05:57:16] <crepincdotcom> ... ok i admit that was completly unrelated
[05:57:23] <alex_joni> crepincdotcom: that's no excuse
[05:57:48] <crepincdotcom> well its not late here. that was the point i was making.
[05:57:57] <SWPadnos> * SWPadnos is not is Canuckia
[05:58:04] <SWPadnos> and it is late here
[05:58:23] <alex_joni> * alex_joni goes to wok
[05:58:24] <alex_joni> later guys
[05:58:29] <SWPadnos> see you later
[06:52:51] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa_5i2x/5i20_vhdl/Makefile: experimental Makefile for building FPGA bitfiles from VHDL source
[06:53:42] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/Makefile: initial commit of new mesa 5i2x driver - not working yet
[06:53:45] <CIA-6> 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa_5i2x/hal_5i2x.c: initial commit of new mesa 5i2x driver - not working yet
[07:33:53] <K`zan> Night folks
[10:53:51] <xemet> hi
[14:24:11] <skunkworks> nobody seemed to lose life or limb last night.. even with SWPadnos threat of using inbm (inter-neighborhood balistic missles)
[14:24:26] <SWPadnos> that's intra-neighborhood :)
[14:24:38] <skunkworks> ;)
[14:25:00] <SWPadnos> http://www.videoranch.com/html/frhomepage.html
[14:25:05] <SWPadnos> click on "videos"
[14:25:29] <SWPadnos> they're all good (for some value of good)
[14:27:24] <skunkworks> that is funny :)
[14:27:56] <SWPadnos> Elephant Parts is a very funny movie (if you can call a series of unrelated skits a movie)
[14:28:31] <SWPadnos> I wish Television Parts were available on DVD - there's a great Garry Shandling skit where he takes a car to the shop for service
[14:28:32] <skunkworks> http://www.youtube.com/watch?v=uj9tusl33sc
[14:28:57] <SWPadnos> heh - I've seen that one :)
[14:29:38] <skunkworks> I want my name cubed..
[14:30:43] <skunkworks> an then there is any monty python skit ;)
[14:30:59] <SWPadnos> heh - yep
[14:32:47] <SWPadnos> oh - if you can find Tape Heads somewhere, rent it. it's a pretty funny movie
[14:48:54] <xemet2> jepler: are you there?
[15:00:12] <CIA-6> 03cradek 07TRUNK * 10emc2/docs/man/man1/halcmd.1: typo
[15:00:36] <CIA-6> 03cradek 07v2_1_branch * 10emc2/docs/man/man1/halcmd.1: typo
[15:00:41] <SWPadnos> you know - I was wondering why the water wouldn't get hot, and I found out it's because it's 5 below outside
[15:00:46] <SWPadnos> in the sun
[15:07:36] <duerz> In order to run EMC from your home directory - and start to build system. How do you run in fake mode?
[15:08:02] <SWPadnos> do you mean simulator mode?
[15:08:12] <duerz> yes
[15:08:34] <SWPadnos> if you have the source, you can run ./configure --enable-simulator --enable-run-in-place
[15:08:42] <xemet2> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Getting_the_source_with_CVS
[15:09:18] <SWPadnos> yep - that's it
[15:16:51] <duerz> boy sure sounds easy - i must be a dummy.
[15:17:20] <xemet2> duerz, everything is easy when you know how to do it...
[15:17:21] <duerz> I installed ubuntu from cd, then i installed emc by the script file.
[15:17:26] <duerz> :)
[15:17:45] <duerz> Now i chose VTI as a starting point
[15:17:57] <xemet2> so you installed EMC, not run in place
[15:18:03] <duerz> I let it create the files in hoome directory
[15:18:15] <duerz> i dont know
[15:18:39] <duerz> is there a difference?
[15:18:42] <cradek> you don't want the simulator if you want VTI - the simulator can't run any hardware
[15:18:59] <xemet2> well, run in place means that you download the sources in a directory for example /home/emc2.1.1
[15:19:06] <xemet2> after that
[15:19:25] <xemet2> you compile the sources and you can run emc from that directory
[15:19:27] <xemet2> while
[15:19:30] <cradek> duerz: can we back up - please say what you're trying to do
[15:19:44] <cradek> duerz: I think people are not understanding your original question
[15:19:54] <xemet2> when you install it in your system all files are copied in the system directories
[15:20:18] <xemet2> I've three emc installed in my system at this moment :)
[15:20:29] <cradek> xemet2: I don't think he wants to compile it, he wants to start integration
[15:20:31] <xemet2> one standard installation and two run in place
[15:20:48] <duerz> yes
[15:20:49] <SWPadnos> ah - build system, vs the build system :)
[15:20:50] <duerz> :)
[15:20:50] <xemet2> one 2.1.1 and other cvs-head (that is the latest development version)
[15:21:25] <xemet2> ok
[15:21:28] <cradek> duerz: ok we'll all stop while you ask your question again :-)
[15:21:35] <duerz> I was getting real worried :)
[15:21:35] <xemet2> sorry
[15:21:48] <duerz> way over my head
[15:21:53] <cradek> ok let's all start over
[15:21:57] <SWPadnos> ehwn you run emc, it should present you with a tree of configurations, and if you copied one to your home directory (~/emc2/configs or similar), that config should be in the tree, probably at the top
[15:22:03] <SWPadnos> when, not ewhn
[15:22:31] <duerz> yes it is
[15:22:36] <duerz> vti
[15:22:46] <xemet2> ok
[15:22:47] <cradek> ok that's the one you can start modifying now
[15:22:50] <duerz> under my config's
[15:23:01] <cradek> yes
[15:23:06] <xemet2> in /home/yourname/emc2/configs
[15:23:16] <SWPadnos> ah - do you have the VTI card installed in this computer?
[15:23:21] <duerz> not yet?
[15:23:40] <SWPadnos> ok - you won't be able to use that config until the hardware is installed
[15:23:46] <duerz> that is why i wanted to start to build with out it looking at the hardware
[15:23:51] <cradek> ah
[15:23:57] <SWPadnos> right - that's a problem :(
[15:24:04] <cradek> then open the sample configs and pick sim/something
[15:24:07] <cradek> those run without any special hardware
[15:24:16] <cradek> try sample configs / sim / axis
[15:24:58] <duerz> i see- that is why i get a page full of error when i try to open it
[15:25:04] <SWPadnos> heh - yep
[15:25:22] <duerz> if i installed the card - will the errors go away
[15:25:29] <cradek> yes
[15:25:33] <SWPadnos> they should
[15:25:48] <xemet2> you will became familiar with pages full of error in linux :) (at least...that was for me :) )
[15:26:50] <xemet2> when you get a bunch of errors, just copy and paste them here and SWPadnow or cradek or jepler or someone else will tell you what to do :)
[15:27:24] <SWPadnos> I'll tell you what to do :)
[15:27:31] <duerz> really - :)
[15:27:55] <duerz> wow - you guys are here 24/7? hehe
[15:28:17] <cradek> we're all here off and on
[15:28:17] <duerz> just kidding
[15:28:26] <SWPadnos> 24 minutes per 7 hour period
[15:28:40] <cradek> usually asking a question will get someone to answer pretty soon
[15:28:46] <skunkworks> It is nice having people all over the world ;)
[15:29:00] <cradek> yes
[15:29:08] <duerz> well- ive integrated OpenCNC - but not this - as you can tell
[15:29:29] <duerz> Dabled with Fidia controls also
[15:30:08] <duerz> This stuff is really free?
[15:30:30] <SWPadnos> which stuff?
[15:30:33] <duerz> emc2
[15:30:38] <xemet2> YES
[15:30:40] <SWPadnos> EMC is GPL, so it's Free and free
[15:30:50] <xemet2> I've pid a penny :)
[15:30:52] <xemet2> paid
[15:31:00] <xemet2> I've not sorry
[15:31:16] <duerz> can a person charge for integration services of emc - but not charge for software?
[15:31:24] <cradek> both "free beer" and "free speech"
[15:31:30] <cradek> duerz: yes
[15:31:39] <SWPadnos> you can charge for your time, and for support, etc.
[15:31:53] <duerz> man- sweet deal
[15:32:04] <SWPadnos> you can't prevent someone from giving away EMC though, and you can't prevent them from changing it or looking at the source code
[15:32:08] <cradek> duerz: the integrator would have to pass along all the rights to the user, including the rights to modify and learn from the software
[15:32:52] <duerz> meaning -rights?
[15:33:08] <jepler> read and understand /usr/share/common-licenses/GPL-2
[15:33:09] <SWPadnos> and to copy and distribute it
[15:33:42] <cradek> duerz: yes read the GPL2 - it's very nice to know your rights as a user of Free software
[15:33:53] <xemet> jepler, I've a little (or big I don't know...) problem
[15:34:14] <xemet> let's see if you can help me
[15:34:14] <jepler> xemet: hi, what's up?
[15:34:17] <cradek> http://www.gnu.org/copyleft/gpl.html
[15:34:18] <xemet> hi
[15:34:44] <xemet> I've done a canon call NURBS_FEED in the emccanon.cc
[15:34:54] <xemet> this function takes as argument a vector
[15:35:02] <xemet> everything compiled correctly
[15:35:14] <xemet> but I've a problem with AXIS,
[15:35:19] <xemet> it works with tkemc
[15:35:37] <xemet> with axis it gives me this error:
[15:35:40] <xemet> http://www.pastebin.ca/383450
[15:35:48] <xemet> is it a thing I can fix easily?
[15:36:13] <jepler> c++filt _Z10NURBS_FEEDSt6vectorI13CONTROL_POINTSaIS0_EEj
[15:36:13] <jepler> NURBS_FEED(std::vector<CONTROL_POINT, std::allocator<CONTROL_POINT> >, unsigned int)
[15:36:31] <jepler> xemet: you must define NURBS_FEED in gcodemodule.cc
[15:36:38] <xemet> ah!
[15:36:44] <jepler> xemet: AXIS needs an implementation of the NURBS canon call(s) so that it can show them in the preview
[15:36:58] <xemet> understood
[15:37:03] <jepler> "c++filt" is a program that will show you the C++ name when you see a "mangled" name like that in an error message
[15:37:34] <xemet> ok,
[15:38:09] <xemet> really the NURBS_FEED is not completely defined yet...I explain, I've added it in order to view if all links works,
[15:38:18] <xemet> but really it does nothing at this moment
[15:38:30] <xemet> it prints "hello"...
[15:39:17] <xemet> so the gcodemodule.cc is for AXIS preview
[15:39:19] <xemet> right?
[15:39:57] <jepler> xemet: yes
[15:40:10] <jepler> and for any other Python program that wants to interpret g-code
[15:41:05] <SWPadnos> are others getting duplicated user group messages?
[15:41:23] <cradek> no
[15:41:29] <SWPadnos> ok - must be me
[15:42:42] <xemet> jepler: so please explain me what your SPLINE_FEED does in gcodemodule, it calculates the spline expression, after that it calculates points, and after it link them with lines (STRAIGH_FEED), right?
[15:44:40] <jepler> xemet: yes
[15:44:45] <xemet> ok
[15:44:52] <xemet> thank you as always
[15:53:44] <xemet> jepler: now it works :)
[15:53:55] <jepler> good!
[16:57:31] <CIA-6> 03mshaver 07TRUNK * 10emc2/src/emc/sai/ (driver.cc saicanon.cc): Added GPL, removed debug lines and changed to sim.tbl and sim.var as default files to be read
[16:58:12] <rayh> good on ya mshaver
[16:59:57] <mshaver> cradek: can you get rid of rs274ngc.tool_defaul and rs274ngc.var in src/emc/sai? They're not used for anything anymore...
[17:00:07] <mshaver> hey ray!
[17:12:12] <a-l-p-h-a> who's got a lathe, and wants to do some work?
[17:12:19] <a-l-p-h-a> CNC lathe...
[17:12:21] <SWPadnos> not me, me
[17:12:30] <a-l-p-h-a> SWPadnos, I know you got a mill.
[17:12:32] <a-l-p-h-a> :P
[17:12:42] <SWPadnos> I have no CNC at all, actually :)
[17:12:55] <a-l-p-h-a> liar.
[17:12:57] <a-l-p-h-a> or laz
[17:12:58] <a-l-p-h-a> y
[17:13:13] <a-l-p-h-a> need something of 25-50 units of something pumped out... and feel like farming it out instead of doing it myself.
[17:13:18] <SWPadnos> lazy
[17:13:57] <SWPadnos> hmmm - I should check on my lathe, but I'm kind of getting used to parking in the garage again
[18:01:04] <a-l-p-h-a> SWPadnos, what of yours is CNCd?
[18:01:14] <SWPadnos> my brain
[18:01:28] <SWPadnos> I have no CNC equipment that's "done"
[18:01:30] <a-l-p-h-a> clever, too bad it's broke.
[18:01:35] <a-l-p-h-a> oh
[18:01:37] <SWPadnos> I have a manual bridgeport and lots of parts
[18:01:50] <a-l-p-h-a> too cold to do? or just too lazy to finish? :)
[18:02:40] <SWPadnos> too lazy
[18:02:49] <SWPadnos> err - I mean yeah, too cold out there
[18:03:29] <a-l-p-h-a> http://www.theweathernetwork.com/weather/cities/can/Pages/CAON0696.htm feels like -25°C
[18:05:12] <SWPadnos> wimpy: http://www.wunderground.com/cgi-bin/findweather/getForecast?query=05452
[18:05:29] <SWPadnos> up from -10 this morning, and -5 at around noon
[18:05:47] <a-l-p-h-a> you're warm compared to me.
[18:06:12] <a-l-p-h-a> last night with windchill, it was -35°C.
[18:53:51] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/inifile/Submakefile: otherwise, libemcini.so is not found by inivar
[18:56:30] <CIA-6> 03jepler 07TRUNK * 10emc2/src/libnml/inifile/ (inifile.cc inifile.hh): get rid of duplicated code while preserving the "C" API for libemcini
[19:54:39] <lerneaen_hydra> 'lo
[21:12:11] <a-l-p-h-a> lerneaen_hydra, ut99?
[21:12:49] <lerneaen_hydra> a-l-p-h-a; hmm, I'm copying lots of data over disks at the moment, gaming would not be pretty :(
[21:15:21] <skunkworks> decent?
[21:15:38] <alex_joni> indecent
[21:20:41] <a-l-p-h-a> exposed
[21:20:57] <a-l-p-h-a> skunkworks, decent was soooo... 1994. :)
[21:21:02] <a-l-p-h-a> great game though
[21:21:08] <skunkworks> descent
[21:21:08] <a-l-p-h-a> really need a joystick for that game.
[21:21:18] <a-l-p-h-a> "descent" fine. :P
[21:21:34] <skunkworks> I had 2 joysticks for that game.. worked great
[21:21:43] <a-l-p-h-a> 1995.
[21:21:53] <a-l-p-h-a> http://en.wikipedia.org/wiki/Descent_%28computer_game%29
[21:23:08] <a-l-p-h-a> brings back memories. :)
[21:23:32] <a-l-p-h-a> spent the last 2 hrs, looking for 3.5" floopies that had my old NC files.
[21:23:32] <skunkworks> I wasted way to much time on that game
[21:23:36] <a-l-p-h-a> got an order this morning...
[21:23:44] <a-l-p-h-a> anyone want to do some lathe work??
[21:23:54] <a-l-p-h-a> just boring small holes. :)
[21:31:55] <alex_joni> boring..
[21:41:56] <a-l-p-h-a> anyone made a CNC simulator?
[21:41:59] <a-l-p-h-a> just wondering.
[21:42:09] <alex_joni> simulator?
[21:42:35] <jepler> what aspect do you want to simulate?
[21:42:45] <alex_joni> cutting forces
[21:42:44] <a-l-p-h-a> lathe
[21:42:51] <a-l-p-h-a> part outcome
[21:43:00] <a-l-p-h-a> after analysis of gcode. :)
[21:43:14] <a-l-p-h-a> with cutter geometry. :)
[21:43:50] <jepler> http://axis.unpy.net/01169521961 is currently for 3-axis milling and takes into account cutter geometry
[21:44:59] <jepler> it could be adapted to threading and turning on a lathe, but it's harder to add facing / boring
[21:45:49] <jepler> it only simulates an ideal tool (no deflection, infinite chip load possible, cutting surface all the way "up", etc)
[21:47:10] <a-l-p-h-a> I see.
[21:47:47] <a-l-p-h-a> anyone wanna quote?
[21:47:47] <a-l-p-h-a> 6061-T6 material
[21:47:47] <a-l-p-h-a> Item #1. 3/8" dia x 1.25" length, with a #30drilled .75-.8" deep. Need 50 of them.
[21:47:47] <a-l-p-h-a> Item #2. 5/8" dia x 5.5" length, with a #30drilled .75-.8" deep on each end.. Need 25 of them.
[21:48:25] <a-l-p-h-a> #30= 0.1285"... it's slightly larger than a 1/8". Which is important.
[21:48:54] <jepler> basically to adapt it to lathe threading and turning, you wrap the "y" axis around the cylinder for display, change the tool shape computation, and mill at (x, theta, z) with theta based on the g33 pitch or s-word speed
[21:49:29] <cradek> I wouldn't quote anything without tolerances specified...
[21:51:15] <a-l-p-h-a> Lengths, +/- 0.05". Drilled depth is stated. Drilled hole diameter to be between 0.126-0.13".
[21:52:23] <cradek> sounds like a pretty quick job for someone with the right setup
[21:52:50] <a-l-p-h-a> you got the right setup? :)
[21:52:56] <cradek> I wish I did
[21:53:58] <a-l-p-h-a> hmm... wonder if I can find a small child to sit in front of a lathe to work it.
[21:54:08] <SWPadnos> that would be perfect for the lathe I should have sometime around now-ish
[21:54:11] <a-l-p-h-a> it's not child labour if it's 14+ right?
[21:54:28] <a-l-p-h-a> SWPadnos, want to make a quote? :)
[21:57:15] <SWPadnos> well there's a snag, you see. I don't actually have the lathe
[21:57:13] <a-l-p-h-a> ETA?
[21:57:13] <a-l-p-h-a> 1week?
[21:57:13] <SWPadnos> when I get it, I guess
[21:57:13] <a-l-p-h-a> heh
[21:57:13] <SWPadnos> it's not a CNC though, only NC
[21:57:13] <a-l-p-h-a> what are these used for? http://www.use-enco.com/CGI/INSRIT?DCMP=EMC-934000&PMAKA=ZY505-2153
[21:57:13] <SWPadnos> I can put you in touch with a local machine shop though (local to you)
[21:57:30] <a-l-p-h-a> SWPadnos, someone you know personally? or just someone you're gonna pull from a phone book?
[21:57:40] <a-l-p-h-a> http://www.use-enco.com/CGI/INSRIT?DCMP=EMC-934000&PMAKA=ZY890-9807 <-- not a bad deal. though I have everything in there.
[21:57:44] <a-l-p-h-a> except the lathe dogs.
[21:57:50] <SWPadnos> someone I know from an online forum
[21:58:02] <SWPadnos> never met in person (kind of like you ;) )
[21:58:51] <a-l-p-h-a> I'll grab it off your if I really need it.
[21:58:57] <SWPadnos> ok
[21:59:09] <a-l-p-h-a> Maybe I'll get my sister, mom, or dad to sit in front of the lathe. :)
[22:00:25] <a-l-p-h-a> Pretty sure the GF wouldn't go for it... my sister might though...
[22:23:04] <skunkworks> hmm :) http://www.icculus.org/d2x/
[22:27:16] <skunkworks> might have to try that tonight
[22:59:08] <robin_sz> a-l-p-h-a, a word of advice for you ...
[22:59:08] <anonimasu> ^_^
[22:59:08] <SWPLinux> don't pet a burning dog
[22:59:08] <robin_sz> if you do manage to get your GF/sister to pose in front of the lathe ... try to avoid using the phrase "lathe dogs" ... just in case. confusion might lead to a swift kick in the nuts.
[22:59:08] <anonimasu> SWPLinux: what kind of nc lathe are you getting?
[22:59:49] <SWPLinux> Hardinge HNC
[23:00:03] <robin_sz> mmm ... nice enough
[23:00:16] <anonimasu> nice
[23:00:19] <SWPLinux> still holds 0.001-0.002 tolerances
[23:00:25] <SWPLinux> oops - 0.0001-0,.0002
[23:01:28] <robin_sz> thas more like it
[23:01:49] <robin_sz> I always fancied an HLV as a manual lathe
[23:02:33] <robin_sz> an HNC is a very good lathe with a poor control .. so ideal for a retrofit
[23:02:38] <anonimasu> yep
[23:02:41] <SWPLinux> you wouldn't believe how clean it is
[23:02:55] <SWPLinux> there aren't even any scratches on the tooling plate
[23:03:03] <SWPLinux> never used with coolant, only oil
[23:03:27] <SWPLinux> in a shop that does aerospace stuff (the exceedingly clean one I posted a link to a couple of months ago)
[23:04:46] <anonimasu> :)
[23:05:13] <robin_sz> nice
[23:05:39] <robin_sz> go on, make us sick .. what are you paying for it?
[23:06:05] <anonimasu> I really need a cnc/nc lathe soon :)
[23:06:10] <SWPLinux> $500, with a spare tooling plate, I think
[23:06:14] <anonimasu> *jealous*
[23:06:24] <SWPLinux> and the control (which still works, but is a behemoth)
[23:06:25] <robin_sz> git.
[23:06:37] <anonimasu> almost free :)
[23:06:38] <anonimasu> :p
[23:06:42] <SWPLinux> oh yeah - that's only 250 UKP :)
[23:07:53] <SWPLinux> of course, I don't have it yet, so who knows
[23:09:55] <robin_sz> an HLV will cost ... 10 times that at least over here
[23:10:43] <SWPLinux> this one is only viable because it's 5 miles from me
[23:11:01] <SWPLinux> and I know people who know people with flatbed tow trucks :)
[23:12:54] <SWPLinux> ah yes: http://www.preci.com/photos.htm
[23:23:18] <robin_sz> http://www.csparks.com/hardinge/index.html
[23:41:30] <CIA-6> 03petev 07TRUNK * 10emc2/src/libnml/inifile/ (inifile.cc inifile.hh inivar.cc): Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:31] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/motion/usrmotintf.cc: Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:31] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:32] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/ini/ (iniaxis.cc initool.cc initraj.cc): Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:34] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/usr_intf/ (emcsh.cc halui.cc iosh.cc keystick.cc shcom.cc xemc.cc): Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:38] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc_pre.cc: Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:43] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/task/ (emcsvr.cc emctask.cc emctaskmain.cc taskintf.cc): Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.
[23:41:46] <CIA-6> 03petev 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: Initial step to INI file handling clean up. Added exception throwing to IniFile class and fixed memory leaks in error recovery.