#emc-devel | Logs for 2007-03-06

[00:16:45] <petev> regarding the run the interp once
[00:16:47] <mshaver> anyway...
[00:17:09] <jepler_> keep in mind that there are now non-terminating g-code programs
[00:17:12] <jepler_> jepler_ is now known as jepler
[00:17:16] <petev> I was thinking about writing out checkpoint data at each tool change or maybe more often for re-starts
[00:17:31] <mshaver> like: pushing "run" calls "make" which "build" a .canon output file if the "source" gcode file has changed
[00:17:41] <petev> I think large programs, like for molds, could be brutal with a run it all ahead of time approach
[00:18:11] <cradek> I think you can't write a .canon if you use probing
[00:18:15] <mshaver> true, but AXIS does it now to draw the picture
[00:18:45] <petev> hmm, that may be a problem with AXIS too
[00:19:02] <cradek> yes, but it doesn't matter that axis shows the entire probing motion
[00:19:03] <mshaver> what does AXIS do with a giant (or non terminating) file
[00:19:09] <jepler> axis assumes all probes end without the probe closing
[00:19:15] <petev> I definitely think the interp needs some way to re-start in the middle of a program with correct context
[00:19:18] <jepler> it loads until you hit ESC (a fact that is hard to discover)
[00:19:24] <cradek> mshaver: lets the user hit escape when he gets tired of waiting
[00:19:48] <cradek> bbl
[00:19:51] <mshaver> i'm not too familiar with how probing works these days
[00:19:54] <jepler> the meaning of any coordinate in a program changes if the g5x or g92 offset changes
[00:20:10] <cradek> or the tool table
[00:21:07] <jmkasunich> hi guys
[00:21:09] <mshaver> the interp could be split
[00:21:12] <jepler> hi jmkasunich
[00:21:17] <petev> hi jmk
[00:21:21] <mshaver> Hi John!
[00:21:27] <jmkasunich> looks like its going hot and heavy today
[00:21:46] <jmkasunich> I had a netsplit so part of its missing (the part where matt joined in)
[00:22:17] <petev> we started talking about a higher level refactor on the user channel
[00:22:36] <jmkasunich> ok, maybe thats it - i haven't read back there yet
[00:23:29] <petev> I wanted to isolate config (INI file, etc.) and comm (NML or whatever) the way they should be
[00:23:59] <petev> I thought that would start the ground work for proper C++ classes and cleaning up the task mess
[00:24:29] <petev> I was looking at the motion interface
[00:24:54] <petev> and I don't see why we can't just make it a queue and queue the command blocks instead of the interp_list
[00:27:45] <mshaver> hmm, if a tool dia changes that would really affect things
[00:27:48] <mshaver> I guess the .canon would have to be rebuilt for any of those changes (tool table, offset table, etc.), at least from your checkpoints forward
[00:27:51] <mshaver> maybe that idea's not going to work :)
[00:28:50] <petev> yes, I figured for a re-start, you would go back to the nearest checkpoint and run forward to the desired starting point
[00:29:31] <mshaver> my net conn is broke...
[00:29:34] <mshaver> bbl
[00:29:53] <petev> mine seems pretty bad too
[00:30:01] <mshaver> hey it's back!
[00:30:31] <mshaver> I gotta go eat dinner, but I'll be back later - I'm with you on comm & ini
[00:30:39] <petev> ok
[03:20:08] <jmkasunich> jepler: are you done now?
[03:20:52] <jepler> jmkasunich: yes, it should build now
[03:21:03] <jepler> jmkasunich: I got one commit out of order, it looks like
[03:21:12] <jmkasunich> I just meant the flood ;-)
[03:21:17] <jepler> I thought I'd already broken it (wouldn't run) so wanted to commit that change first
[03:21:20] <jepler> oh
[03:21:29] <jmkasunich> I was trying to say something and didn't want to get washed away ;-)
[03:21:29] <jepler> yeah that's all from that batch of commits
[03:24:06] <steves_logging> steves_logging is now known as steve_stallings
[03:24:13] <cradek> jepler: built here
[03:24:30] <jepler> cradek: great, thanks for verifying
[03:29:37] <jepler> cradek: I get an error when I 'make tags': find . -type f -name '*.[ch]' |xargs etags -l c --append
[03:29:42] <jepler> etags: Unknown option: -l
[03:29:52] <cradek> strange
[03:30:04] <jepler> lrwxrwxrwx 1 root root 24 2006-12-16 10:01 /etc/alternatives/etags -> /usr/bin/ctags-exuberant
[03:30:10] <jepler> do you have some other etags installed?
[03:30:13] <cradek> xemacs21-bin: /usr/bin/etags.xemacs21
[03:30:39] <cradek> I bet they would autodetect without that - just take out the -l
[03:35:26] <jmkasunich> I think methods to get a float, an int, a string, etc, are a fine idea
[03:35:51] <petev> why not encapsulate the INI strucuture and error checking too?
[03:36:07] <jmkasunich> methods like TrajMaxAccel are horrible though
[03:36:15] <petev> why?
[03:36:30] <petev> they are all over the code with the associated error checking now
[03:36:30] <cradek> because you need to write an accessor for every line that might be in any ini
[03:36:40] <jmkasunich> why should someone who is adding a new ini var to program A have to go and edit the inifile library
[03:36:41] <SWPadnos> because they're not extensible without recompiling
[03:36:41] <petev> whouldn't it be better to have it all in one spot?
[03:36:45] <cradek> that seems dumb
[03:36:57] <jmkasunich> thats what sucks so badly about NML
[03:36:59] <petev> cradek, the code does that now
[03:37:05] <SWPadnos> what would be better would be some accessors for "sommonly used" items, and a generic set of readers for the various types
[03:37:06] <petev> it's just spread all over
[03:37:27] <jmkasunich> its where it belongs
[03:37:34] <SWPadnos> commonly, that was suposed to be
[03:37:41] <petev> so what's the diff between an accessor and code spread out doing the error checks?
[03:37:46] <jmkasunich> parsing strings into floats can and should be centralized
[03:37:54] <petev> if you encapsulate the INI structure you can error check in one spot
[03:38:00] <jmkasunich> but only the guy who is gonna use ini varialbe FOO knows what are legal values for FOO
[03:38:00] <petev> then all the other code is simple
[03:38:03] <cradek> the error checks can be centralized without an accessor function for every entry
[03:38:28] <jmkasunich> why should that knowledge be pulled away from the code where it matters and stuffed in a class library on the other side of the source tree
[03:38:34] <cradek> the reader has to handle "it doesn't exist" and "error" anyway
[03:39:00] <SWPadnos> you'd make a set of "gets" for each type. for instance, a float reader would have variants that take min, max, possibly granularity, etc.
[03:39:08] <petev> there will be much more error recovery if errors can happen all over the place
[03:39:15] <petev> I don't see a way around it
[03:39:18] <jmkasunich> I can see methods that are given the name of the variable, and the allowable limits, by the caller, and then they do error checking
[03:39:20] <cradek> petev: what if they're not errors
[03:39:27] <jmkasunich> but the names themselves should never be in the library
[03:39:33] <cradek> petev: a certain entry that's not in the file isn't necessarily an error
[03:39:34] <SWPadnos> agreed with that
[03:39:51] <cradek> (and only the reader knows that)
[03:39:55] <petev> jmk, that wouldn't make error recovery any easier though
[03:40:05] <SWPadnos> a flag passed to the reader can expose that distinction
[03:40:20] <jmkasunich> is the reader the library, or the code calling the library?
[03:40:25] <SWPadnos> sorry - the library
[03:40:31] <cradek> by reader I meant caller, sorry
[03:40:37] <SWPadnos> heh - oops ;)
[03:40:45] <jmkasunich> I thought there was a disconnect
[03:40:55] <cradek> only the caller knows if a nonexistent [AXIS_2]MAX_WIDGETS is an error
[03:41:06] <jmkasunich> the caller is the one who knows what value is correct, and the caller is the one who has to handle the error
[03:41:14] <cradek> right
[03:41:29] <petev> then error recovery code will have to be everywhere
[03:41:41] <cradek> **they're not all errors**
[03:41:42] <SWPadnos> yes, the caller usually has to handle the error
[03:41:56] <jmkasunich> how can a library possibly handle the errors?
[03:42:05] <cradek> jmkasunich: by aborting
[03:42:10] <petev> cradek, look at the code now and see how much error recovery there is
[03:42:22] <petev> it could be better, but it's still not good
[03:42:24] <jmkasunich> it has to return to its caller, it will either return a value the caller can use, or "sorry"
[03:42:26] <cradek> petev: that's irrelevant. I thought we were designing.
[03:42:42] <petev> cradek, I don't follow
[03:42:45] <jmkasunich> the caller has to take it from there
[03:42:47] <SWPadnos> for most "not found" errors, there's a check to EMC_DEBUG and some other stuff, then a printf("blah blah %s {something different} %s", secname, varname)
[03:42:57] <petev> my idea was to centralize the error checking to file read time and read the file once
[03:43:05] <jmkasunich> can't work
[03:43:11] <SWPadnos> the only thing that's truly different there is "something different"
[03:43:16] <petev> jmk, where do you see issues?
[03:43:27] <SWPadnos> there are two issues with that scheme:
[03:43:33] <jmkasunich> sometimes the "correct" value for item 1 is determined by the value of items 3, 8, and 24
[03:43:37] <jepler> it has to be OK for only one part of the system to know about an ini file item
[03:43:42] <cradek> petev: did you read this: only the caller knows if a nonexistent [AXIS_2]MAX_WIDGETS is an error
[03:43:42] <SWPadnos> the library needs to know the type of every var, and the library needs to know if any vars are missing
[03:43:59] <petev> I don't see why that is the case
[03:44:10] <jmkasunich> who are you replying to?
[03:44:23] <jmkasunich> four statements by four people.....
[03:44:23] <petev> if a user parses the INI file can he not determine if it's in error?
[03:44:26] <petev> cradek
[03:44:45] <SWPadnos> missing [TRAJ]MAX_VELOCITY is an error (I think), but missing [AXIS_0]MAX_VELOCITY isn't (I think)
[03:44:47] <cradek> no, not unless he knows what every line does and how they interact
[03:44:53] <petev> if a user can detect an error, why can't the same checks be built into the library?
[03:44:53] <cradek> SWPadnos: right, that's my point
[03:45:01] <jmkasunich> the user is a human being
[03:45:12] <SWPadnos> there would be a lot of those things that shouldn't be hard-coded into the ini class
[03:45:24] <cradek> the ini class should be a generic ini-file-reader
[03:45:24] <jmkasunich> your library would have to contain the entire logic of EMC in it
[03:45:29] <petev> the tradoff for that is easy error recovery
[03:45:31] <cradek> that's how you can replace it later
[03:45:42] <SWPadnos> well, there's a middle ground
[03:45:54] <petev> right now it's hard to determine what's acceptable because you have to look everywhere
[03:46:06] <petev> I'm not sure it's a bad thing to error check in one place
[03:46:11] <SWPadnos> you can still read the whole thing at once if you like, but you have to store all vars as strings
[03:46:28] <petev> why as string?
[03:46:36] <jmkasunich> because string is type neutral
[03:46:49] <SWPadnos> ini files are meant to be very forgiving - I'm not sure it should be an error if you have a line that isn't in the format var = value, for instance
[03:46:55] <petev> why can't the class know anything about structure?
[03:47:00] <jepler> petev: when some hotshot releases a new user interface that makes use of new sections and items in the .ini file, how will a "validate once" approach work?
[03:47:05] <SWPadnos> right - you don't know if the version will be a number or a string, for instance
[03:47:05] <petev> it's not IniFile, it's EmcIniFile
[03:47:07] <jepler> petev: let's say, for the sake of argument, that the new GUI is written in lisp
[03:47:17] <SWPadnos> ok - that's true
[03:47:23] <jmkasunich> petev: look at it this way: the caller is a large hunk of code with machine control specific logic in it - it may branch based on one var, and not even look at others, or take a different branch, etc, etc
[03:47:23] <SWPadnos> (to petev)
[03:47:34] <petev> jepler, you have to add the code somewhere, why not all in one place?
[03:47:37] <jmkasunich> that logic BELONGS in the caller - the caller is CNC code
[03:47:49] <jmkasunich> the ini lib is not CNC code, why put CNC logic in it
[03:48:00] <SWPadnos> hold on - I've just realized that pete is talking about a system where you have a generic ini interface, then a subclass of that which is an EMC-specific ini class
[03:48:15] <petev> jmk, can you give a specific example of a param you are talking about?
[03:48:26] <jmkasunich> sure
[03:48:29] <jepler> petev: but you can't, because you don't know the requirements of this new GUI at the time you write the single "validate an emc ini" function
[03:48:49] <jmkasunich> EmcIniFile is exactly the wrong way to go about it
[03:48:52] <petev> jepler, what is your goal?
[03:48:51] <jmkasunich> that turns it into NML
[03:49:01] <SWPadnos> so initraj, iniaxis, initool, ini<foo> all get wrapped somehow into the EmcIni class, but there's still a generic [SECTION]VAR class that can be used anywhere
[03:49:48] <jepler> Only the AXIS user interface can know what this means:
[03:49:48] <jmkasunich> * jmkasunich runs away screaming
[03:49:47] <jepler> [FILTER]
[03:49:48] <jepler> PROGRAM_EXTENSION = .png,.gif,.jpg Grayscale Depth Image
[03:49:49] <petev> if it's the goal to extend the INI file without touching EMC code, then you can't encapsultate structure
[03:49:56] <petev> but why is that a requirement?
[03:50:10] <jepler> only HAL can know what the variable referred to by 'loadrt hal_parport cfg=[HAL]PARPORT_ADDRESS' means
[03:50:19] <jmkasunich> because it provides just the kind of decoupling that you consider good
[03:50:19] <petev> it doesn't change that often anyhow and I'm not sure it should have config stuff for other things
[03:50:37] <SWPadnos> well, that's a separate discussion
[03:50:51] <SWPadnos> most ini discussions lately have been about combining everything
[03:51:02] <SWPadnos> (XML-like, if it were human-readable)
[03:51:19] <jmkasunich> there is absolutely no reason why code except GUI code should know or care what vars are in the GUI section, and no reason for any code except HAL code to know about what vars are in the HAL section
[03:51:35] <SWPadnos> I'm not sure that's what's being advocated
[03:51:35] <petev> that will make for many reads and searches of the file and lots of error recovery code
[03:51:47] <jmkasunich> putting a master list of vars (and worse, interrelationshipts between vars) in some other place seems insane to me
[03:52:09] <SWPadnos> consider this: you want a C function that reads strings, then some others that call the string reader and convert to e.g. float, with some error checking
[03:52:13] <petev> jepler, most of the error recovery is because scanf couldn't convert, etc.
[03:52:21] <petev> they are syntax errors, not semantic
[03:52:32] <petev> semantic errors are handled by the caller
[03:52:45] <SWPadnos> instead, a class that generically reads various ini types (string, float, int, bool, units, ...) would be available
[03:52:48] <jmkasunich> symantic errors are the only ones that care about the name of the variable
[03:52:54] <jmkasunich> so let the caller deal with that too
[03:53:00] <petev> it seems stupid to have every module checking if a string can be converted to a float or int, et.c
[03:53:04] <SWPadnos> a subclass of that, which knows about EMC ebcuase it's an *EmcIniFile*, would have additional validation
[03:53:16] <petev> jmk, how is that?
[03:53:24] <petev> unless you add type info to the INI
[03:53:31] <jmkasunich> we've said several times that we agree 100% about basic scanf stuff, there should be methods to get floats, ints, bools, and stings
[03:53:44] <jmkasunich> but there should not be code in the library for every single possible ini variable
[03:53:54] <petev> how can the scanf be done at file read, if the structure is not known?
[03:54:03] <jmkasunich> arrgh
[03:54:22] <jmkasunich> read the file, store everything as "name","string" pairs
[03:54:37] <jmkasunich> then when somebody calls the get_float method, convert the string to a float
[03:54:38] <SWPadnos> is this an accurate problem statement: ini reading/parsing functionality is spread way too far over the code
[03:54:38] <petev> jmk, if a call is used like you suggest, then syntax error checking is everywhere as well
[03:54:43] <jmkasunich> return the value, or error
[03:54:57] <jmkasunich> no, the syntax checking is only in the get_float method
[03:55:08] <petev> so that doens't help error recovery at all
[03:55:30] <jmkasunich> handling the error is something that only the caller know about (and only the caller _should_ know about)
[03:55:35] <petev> you have to distribute the error recovery, unless you want to use C++ exceptions ;-)
[03:55:36] <SWPadnos> ok, so how many kinds of error are there when reading ini files?
[03:55:56] <SWPadnos> 1) variable not found (caller decides if this should be an error)
[03:55:57] <petev> jmk, not true, the syntax errors can be easily handled in the library
[03:56:14] <petev> swpadnos, that's sematic error
[03:56:14] <SWPadnos> 2) variable can't be converted to the requested type
[03:56:22] <jmkasunich> only if the library know before-hand exactly what the type of every variable is
[03:56:34] <petev> jmk, that's right
[03:56:39] <SWPadnos> ok, so syntax and semantic errors - are there any subclasses of semantic errors?
[03:57:11] <jmkasunich> having the library know beforehand the type of every variable violates data hiding so massivlely I can't believe you are evne proposing it
[03:57:19] <jmkasunich> even
[03:57:31] <SWPadnos> let's stop arguing over when we can figure out what's an error. maybe making some lists of possible errors and where they can occur would clear things up a bit
[03:57:39] <petev> in this case I would view it like an XML DTD
[03:57:51] <petev> the library error checks for syntax
[03:58:02] <jmkasunich> so adding an ini file variable means updating some DTD file? yuck
[03:58:08] <petev> if we don't want to change the INI format, we can't make it perfect
[03:58:26] <SWPadnos> it can't be perfect anyway - let's get a little more incremental, shall we?
[03:58:33] <jmkasunich> you have to add it to the caller, and then you have to go edit some central database (DTD) of info that properly should belong only to the caller
[03:58:49] <petev> ok, it's a no brainer to put the scanf in the IniFile class, agreed?
[03:58:55] <SWPadnos> right now, there are 20-line stanzas for every ini variable read (in iniaxis and initraj, at least)
[03:59:12] <jmkasunich> and we all agree those 20 lines stanza are stupid
[03:59:24] <SWPadnos> that can be boiled down to one or two lines per variable if it's properly encapsulated in a class
[03:59:26] <petev> jmk, are you open to C++ exceptions for error recovery then?
[03:59:30] <jmkasunich> no
[03:59:36] <SWPadnos> except for halcmd
[03:59:40] <petev> then you are fixing all of the variables
[03:59:46] <jmkasunich> no I'm not
[03:59:55] <SWPadnos> the other caller code is already C++ and can do exceptions
[04:00:08] <jmkasunich> the caller decides what variables he wants, what their types are, what their legal ranges are, and what to do when they aren't right
[04:00:15] <petev> what you want leaves no choice but to have a bunch of sntax error recover all over
[04:00:43] <jmkasunich> the library parses, and says "yep, this meets your requrements, here is the value" or "nope, this isn't what you want"
[04:00:59] <SWPadnos> no, it can also be done with a somewhat silly class construction that allows the caller to wither get an error back or let the class do the error print
[04:00:58] <petev> and the error recovery code?
[04:01:13] <SWPadnos> s/wither/either/
[04:01:35] <jmkasunich> the error recovery code will vary depending on the variable, what it is used for, and possibly the value of preceding vars
[04:01:53] <petev> so there will be 10 lines of code to get each var?
[04:01:53] <jmkasunich> and the right place for that is in the application specific code, not a generic library
[04:02:02] <petev> it's not a generic library
[04:02:09] <petev> IniFile is the generic lib
[04:02:17] <petev> EmcIniFile is emc specific
[04:02:36] <SWPadnos> no, the right thing to do is make a library that can take care of the most common error tasks, and still provides generic functions for those places where special things need to be done in case of error
[04:02:40] <jmkasunich> I thought you wanted to fix inifile, not add another layer on top of it
[04:02:49] <SWPadnos> stop a sec please
[04:03:02] <petev> no, I want to add the scanf stuff to IniFile, then derive EmcIniFile from it
[04:03:11] <SWPadnos> inifile is functional but drastically incomplete at the moment
[04:03:18] <petev> yes
[04:03:18] <jmkasunich> agreed
[04:03:35] <SWPadnos> step 1 is to do as pete just said - make a complete, type-safe ini interface
[04:03:44] <jmkasunich> agreed
[04:04:10] <SWPadnos> step 2 would be to make an emc-specific class which is derived from the generic class, and has more emc-specific handling of validation and errors
[04:04:23] <jmkasunich> that is the part I just don't get
[04:04:29] <petev> I think IniFile could support optional exceptions for the C++ code
[04:04:41] <petev> then we would have the best of both in most places
[04:04:46] <SWPadnos> the original generic interface would still be available for any program that isn't emc, and the emc ini file reader would have to ignore anything it doesn't need, just as e.g. iniaxis.cc does now
[04:05:04] <SWPadnos> AXIS isn't emc, so it would use a generic interface
[04:05:23] <SWPadnos> halcmd isn't emc, so it would use a generic interface ...
[04:05:33] <jmkasunich> if you have some code that does "for (i = 0 to inivar1) do init_some_object[i], where initing the object means reading more ini vars, why duplicate that logic elsewhere?
[04:05:36] <petev> is there NML for geting INI values now?
[04:05:43] <SWPadnos> no
[04:05:49] <SWPadnos> not that I know of anyway
[04:05:58] <petev> so how does AXIS get INI info without a big KLUDGE?
[04:06:19] <jmkasunich> SWPadnos: what do you mean "axis isn't EMC"
[04:06:24] <jmkasunich> and "halcmd isn't emc"
[04:06:34] <jmkasunich> emc is not a program
[04:06:45] <jmkasunich> emc is a collection of programs that work together
[04:06:49] <jmkasunich> axis is one of htem
[04:06:50] <SWPadnos> yes
[04:06:50] <jmkasunich> halcmd is one of them
[04:06:59] <jmkasunich> there is NO program called EMC
[04:07:00] <SWPadnos> are iniaxis or initraj still used at all?
[04:07:10] <jmkasunich> I think so
[04:07:28] <SWPadnos> ok, that is emc in this context :)
[04:07:40] <jmkasunich> that executable is "task"
[04:07:42] <SWPadnos> emc/ini/* are the main consumers of ini data, I think
[04:07:50] <petev> so how does AXIS get INI values?
[04:07:53] <jmkasunich> (its name isn't task, dunno what it is at the moment)
[04:08:08] <jmkasunich> it probably has its own version of iniFile, in python
[04:08:21] <jmkasunich> the nice generic iniFile that is
[04:08:21] <jepler> petev: it uses a wrapper around the inifile API, I don't remember if it is the C or the C++ API
[04:08:24] <SWPadnos> there's a standalone interpreter that's used by the runscript, and I bet axis gets the ini funcs from libnml
[04:08:39] <petev> jepler, and how does that work from a remote machine?
[04:08:41] <SWPadnos> (until a couple hours ago)
[04:08:52] <SWPadnos> axis doesn't work remote, AFAIK
[04:08:58] <SWPadnos> it has HAL pins
[04:09:03] <cradek> petev: all the guis do that, and none of them work right remotely
[04:09:16] <petev> so what is all this NML BS then?
[04:09:17] <SWPadnos> not remote via NML anyway
[04:09:21] <jmkasunich> cradek: tkemd used to work right remotely
[04:09:37] <jmkasunich> petev: its called bitrot
[04:09:40] <cradek> jmkasunich: nah, only with a copy of the ini and much other hackery
[04:09:45] <SWPadnos> anything that uses no HAL and sits on emcsh should run remotely, I'd imagine
[04:09:52] <jmkasunich> when NIST was doing EMC, remote and NML mattered to them a lot
[04:09:53] <petev> man, you guys are depressing me now
[04:09:57] <SWPadnos> or "should have run remotely" :)
[04:10:04] <petev> let's make that 1 week and get rid of NML ;-)
[04:10:10] <SWPadnos> heh
[04:10:11] <jmkasunich> 99.99% of real users don't use remote GUIs, so as things evolve, that got broken
[04:10:14] <cradek> AXIS actually works remotely better because it doesn't read/write the varfile
[04:10:26] <cradek> jmkasunich: it's exactly as broken as it always was
[04:10:36] <cradek> jmkasunich: since keystick, since xemc
[04:10:37] <petev> I beleive that
[04:10:38] <steve_stallings> ... I hear RayH spinning in his .... bed I would guess....
[04:10:44] <jmkasunich> people have used it
[04:10:53] <jmkasunich> so for some value of "works", it works
[04:11:06] <cradek> jmkasunich: the NML part works, nothing else does - same with AXIS
[04:11:15] <jmkasunich> you may have to do stupid things like have a copy of your g-code on both systems, but it DID work
[04:11:29] <petev> that's called broken
[04:11:38] <SWPadnos> emcsh should issue nml commands to do things, but tkemc et al probably use other interfaces as well
[04:11:38] <cradek> yep
[04:11:40] <jmkasunich> the people using it would disagree
[04:11:47] <cradek> jmkasunich: doubt it :-)
[04:12:03] <jmkasunich> ask ray
[04:12:41] <petev> ok, so how about we add the typed funcs to IniFile and throw exceptions optionally?
[04:12:50] <jmkasunich> yes, it may suck rocks, but its like rabbit ears - once you get used to standing on one foot and holding the tip of the antenna to get a good picture, you say it works
[04:12:56] <jmkasunich> it sucks, but it works
[04:13:57] <SWPadnos> petev, that sounds good, but how will you "optionally" throw exceptions?
[04:14:06] <petev> with a method to enable, pretty simple
[04:14:12] <SWPadnos> ok
[04:14:15] <jmkasunich> method that throw, and methods that don't
[04:14:19] <petev> no
[04:14:21] <jmkasunich> or what pete said
[04:14:31] <petev> one method to enable/disable exceptions
[04:14:37] <SWPadnos> no - a "global" that tells the member funcs to throw or not to throw
[04:14:46] <petev> the same methods to retireve vars
[04:14:49] <SWPadnos> (call it "ThatIsTheQuestion")
[04:14:51] <petev> they either throw or not
[04:15:01] <SWPadnos> ok
[04:15:13] <petev> global to the object, not a real global
[04:15:16] <SWPadnos> that sounds like a good start, since no other code needs to be changed
[04:15:23] <jmkasunich> so if a caller wants to change its mind on a call by call basis it has to make extra calls?
[04:15:24] <SWPadnos> right - private data
[04:15:29] <SWPadnos> yes
[04:15:34] <jmkasunich> eww
[04:15:40] <petev> jmk, and why would that ever be the case?
[04:15:43] <SWPadnos> that isn't the kind of thing you'd change your mind about a lot
[04:15:58] <petev> you either use exceptions for error recovery or not
[04:16:08] <SWPadnos> if you have some CPP code, you'd enable exceptions, do all the inits, then turn exceptions off
[04:16:13] <petev> I really don't see why one peice of code would flip flop around
[04:16:28] <jmkasunich> I suppose it depends on what things the library will call errors, and what it will do about them
[04:16:30] <SWPadnos> though that screws up error reporting (for DEBUG states)
[04:16:41] <SWPadnos> syntax only at this stage
[04:16:47] <petev> no, it doesn't
[04:16:54] <SWPadnos> "he asked for a float, but the var was 'foo'"
[04:16:58] <petev> the exceptions returned has some string in it
[04:17:07] <petev> the caller can print it or whatever
[04:17:07] <jmkasunich> ok, you aren't going to allow limit checks?
[04:17:17] <petev> not in IniFile
[04:17:21] <SWPadnos> why not?
[04:17:36] <SWPadnos> not at first, but that can be easily added
[04:17:37] <petev> IniFile is a generic lib
[04:17:49] <SWPadnos> "read with limits" is pretty generic
[04:17:54] <petev> I suppose you could pass some limit args if we want
[04:18:11] <SWPadnos> yep - just default to -INF and +INF if you want
[04:18:18] <jmkasunich> that gets rid of a couple lines from that stanza
[04:18:28] <petev> more than that with exceptions
[04:18:33] <SWPadnos> that's the beauty of exceptions
[04:18:40] <petev> all of the error recovery can be in one spot
[04:18:48] <jmkasunich> exceptions are kind of like a goto?
[04:18:48] <petev> basically only one time for all vars
[04:18:48] <SWPadnos> you do *all* the ini reads, and if there are no errors, no problem
[04:18:52] <SWPadnos> yes
[04:18:58] <petev> yes, a goto with some data
[04:19:13] <jmkasunich> so how does the exception handler know which read failed?
[04:19:21] <SWPadnos> if there's an error, all the remaining items are skipped and the "catch" block is executed, with error data you have defined
[04:19:21] <jmkasunich> so it can print an appropriate error message
[04:19:26] <petev> you use a try/catch block
[04:19:28] <SWPadnos> you define the data
[04:19:42] <petev> the actual thing you catch, contains whatever data you want
[04:19:53] <SWPadnos> an exception is a base class that you can extend to contain extra user data
[04:19:57] <jmkasunich> can you give me a few lines code as an example
[04:20:08] <jmkasunich> suppose I'm reading foo, bar, and blat
[04:20:07] <SWPadnos> err - sort of
[04:20:09] <SWPadnos> one sec
[04:20:21] <petev> it's like you define a struct with whatever you want in it
[04:20:34] <petev> when the exception is thrown, it goes to the catch block
[04:20:41] <petev> which can examine the struct
[04:20:52] <jmkasunich> lost me
[04:21:03] <petev> like a goto with a struct argument
[04:21:08] <jmkasunich> lemme put something in pastebin the C way, then you tell me the C++ exceptions way
[04:21:18] <petev> the struct is filled in by IniFile before throwing the exception
[04:21:28] <SWPadnos> try {
[04:21:28] <SWPadnos> read (foo)
[04:21:31] <SWPadnos> read (bar)
[04:21:31] <SWPadnos> read (blat)
[04:21:35] <SWPadnos> } catch (MyExceptionType &E) {
[04:21:35] <SWPadnos> printf"you bonehead - we got an error from %s\n", E->Data);
[04:21:36] <SWPadnos> }
[04:21:37] <SWPadnos> or similar
[04:22:00] <petev> and MyExceptionType is defined in the IniFile header
[04:22:02] <SWPadnos> right
[04:22:37] <petev> that make sense?
[04:22:42] <SWPadnos> it can contain any data we want, like ini line number, section name, var name, the actual value read, and why it was wrong
[04:23:21] <jmkasunich> MyExceptionType you mean? (it?)
[04:23:24] <SWPadnos> yes
[04:23:59] <jmkasunich> the type is determined by the library though, and the same for all read calls
[04:24:04] <petev> yes
[04:24:21] <SWPadnos> you can have several types though, and pass the base classs of those (right?)
[04:24:24] <jmkasunich> its just a fancy way of passing back an "error code"
[04:24:33] <petev> yes
[04:24:39] <SWPadnos> yes, but it only needs one handler for the error, not one per call
[04:24:41] <petev> a structured way
[04:24:45] <jmkasunich> there would be one for readfloat, one for readint, etc
[04:24:58] <petev> no, one for all of the reads
[04:25:03] <SWPadnos> it's similar to "result = blah(); if (!result) result = boo(); ..."
[04:25:10] <SWPadnos> but way better
[04:25:32] <petev> I think the line number and maybe the line itself would be good info
[04:25:35] <jmkasunich> but readfloat errors might want to pass back actual, upper limit, lower limit, string, error_type
[04:25:43] <SWPadnos> sure
[04:25:59] <SWPadnos> or just "out of range" (for now)
[04:26:07] <petev> all of the code I have seen just cleans up and aborts
[04:26:26] <jmkasunich> cleans up depends on where you were called from
[04:26:32] <petev> I haven't seen any special stuff if it was a limit error vs a conversion error
[04:26:42] <petev> but that could be included in an error code field
[04:26:47] <SWPadnos> it prints different messages
[04:26:56] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/iniaxis-improvements.patch
[04:27:00] <SWPadnos> "not found", "invalid" ...
[04:27:01] <jmkasunich> possiblilties include:
[04:27:17] <petev> all of the INI vars would be read in one try block
[04:27:32] <jmkasunich> warning: variable "foo" not in inifile, using default value 4"
[04:27:42] <jepler> I probably made errors in the conversion from old-style to this-style, but it shows clearly that you can get rid of a lot of LOC
[04:27:48] <jmkasunich> "errorL variuable "bar" not in inifile, exiting"
[04:28:08] <jepler> emc/ini/iniaxis.hh 34: can't find [COMP_FILE_TYPE]AXIS_0, using default 0
[04:28:08] <jepler> emc/ini/iniaxis.hh 34: can't find [UNITS]AXIS_1, using default 0.0393701
[04:28:08] <jepler> emc/ini/iniaxis.hh 45: can't parse [HOME_IGNORE_LIMITS]AXIS_1=NO, using default -1
[04:28:24] <jepler> this says things like the above if you enable the debug output ^^^ essentially like before
[04:28:39] <petev> and the point being?
[04:28:40] <cradek> jepler: your [] are wrong
[04:28:45] <jepler> in almost all cases, the existing code prefers to continue after an error reading from the input file
[04:28:46] <jepler> cradek: oops
[04:28:57] <petev> not from what I saw
[04:29:04] <petev> I guess it depends on the code you're looking at
[04:29:14] <jmkasunich> petev: you just saw it - it uses a default and carries on
[04:29:36] <petev> I saw plenty of code that aborted
[04:29:43] <jmkasunich> could be
[04:29:44] <SWPadnos> some of them do that, others are critical and cause a return -1;
[04:29:48] <jmkasunich> but there is also plenty that doesn't
[04:30:02] <petev> so I still fail to see the point?
[04:30:14] <petev> aren't we already talking about the calling code making the decision?
[04:30:20] <jmkasunich> just that there is no one correct action to take
[04:30:20] <jmkasunich> right
[04:30:44] <jmkasunich> if 20 vars are read in one try block, does that mean that all errors are handled by one catch?
[04:30:45] <petev> so are you saying there is a problem with the implementation we are discussin?
[04:31:11] <petev> yes, but the catch can swithc on the erorr code or whatever it wants
[04:31:12] <jepler> jmkasunich: yes
[04:31:19] <SWPadnos> there's no requirement to do blocks of reads
[04:31:41] <jmkasunich> you can do try { one var } catch { that var's errormessage }
[04:31:51] <SWPadnos> it's just a nice shorthand for things that are abort-critical
[04:31:56] <petev> yes, but that wouldn't be much better than the current code
[04:32:02] <SWPadnos> yes you can, though it's almost as ugly as the current code
[04:32:05] <jmkasunich> although that starts being just as bad as if (one_var) print(msg)
[04:32:05] <petev> and it's not the norm from what I saw
[04:32:21] <jmkasunich> there would be a mix
[04:32:25] <jmkasunich> not one catch per var
[04:32:26] <SWPadnos> there are 10 or 12 (I forgot the count) return -1 statements in loadaxis
[04:32:31] <jmkasunich> not one huge block either
[04:32:53] <petev> that may be, but this would support it
[04:33:06] <jmkasunich> for example, on var may tell you how many axes there are, then there would be a loop over another block to get data for each axis
[04:33:13] <jepler> SWPadnos: not due to failure to read the value
[04:33:19] <petev> sure
[04:33:24] <jepler> SWPadnos: though I suppose the "next layer down" may be where the range check is
[04:33:31] <SWPadnos> right
[04:33:42] <SWPadnos> "bad return from xyz" kinds of messages
[04:34:36] <jepler> i'm done for the night
[04:34:52] <SWPadnos> that's another nice thing that a good class does for you: anything that wants a "unit" would automatically benefit from something like the addition of degree, inch, mm to the ini parser
[04:35:06] <SWPadnos> night jepler
[04:37:04] <jmkasunich> If I was smart I would have shut up hours ago
[04:37:12] <jmkasunich> dammit, I wanted to work on stepgen this evening
[04:37:22] <SWPadnos> http://www.temporaldoorway.com/programming/cbuilder/techniquesandpatterns/customexceptions.htm
[04:37:34] <jmkasunich> and I actually tried to have a discussion that was relavent to that before it got hijacked
[04:37:47] <SWPadnos> a nice basic (though somewhat CPP Builder-specific) explanation of some exception creation/handling stuff
[04:37:56] <cradek> jmkasunich: I wanted to finish rigid tapping... but I can't really blame it on anything but me
[04:38:02] <jmkasunich> screw that - its my own fault that I stayed here
[04:38:09] <jepler> SWPadnos: ooh I love macros
[04:38:13] <SWPadnos> heh
[04:38:21] <jepler> I say put more macros like that in emc if it will make it more object oriented
[04:38:48] <SWPadnos> at least it shows one example of how exceptions could be better (the first thing, with the access violation) ;)
[04:39:10] <cradek> that's stupid C
[04:39:17] <SWPadnos> I guess I should have read through the whole thing first, huh?
[04:39:25] <petev> wait until we try to get jmk to use templates ;-)
[04:39:32] <cradek> if(p && p->m) ...; else handle(..);
[04:39:45] <jmkasunich> I hope you gots lots of provisions for your wait
[04:39:57] <petev> cradek, that's a null ptr check
[04:39:57] <jmkasunich> the list of languages I want to learn goes like this:
[04:40:01] <SWPadnos> there's Korean Buffet
[04:40:13] <SWPadnos> engrish
[04:40:14] <jmkasunich> VHDL; Python; ...................................................................................
[04:40:20] <jmkasunich> ......................................................C++
[04:40:25] <SWPadnos> what's ...........................................................?
[04:40:40] <cradek> petev: yes, it's the dumbest way to write if(p && p->m) ever
[04:40:40] <jmkasunich> everything else in the world that isn't C++
[04:40:41] <SWPadnos> heh
[04:41:11] <cradek> 8 curlybraces, two ifs, two elses
[04:41:55] <jmkasunich> I'd tend to write it "If (bad thing) { handle bad thing} ; carry on" instead of putting the handler afterwards
[04:42:11] <jmkasunich> after is ok when there is only one bad thing and one action
[04:42:21] <jmkasunich> but when there are a bunch.....
[04:42:25] <petev> I like to put the shortest case first for readbility
[04:42:40] <cradek> if(!p || !p->m) error(); else s();
[04:42:47] <cradek> sure, either way
[04:43:00] <jmkasunich> except I'd drop the else
[04:43:16] <cradek> (ok, assuming error aborts)
[04:43:26] <jmkasunich> if (!p || !p->m) deal with it
[04:43:27] <jmkasunich> carry on
[04:43:36] <jmkasunich> deal with it might mean abort, or might mean fix
[04:43:44] <cradek> "look, C++ is cleaner than the dumbest C ever" is kind of unconvincing...
[04:43:47] <jmkasunich> either way, the carry on code doesn't want to be indented
[04:43:47] <petev> jmk, while your not getting anything done, care to talk about the motion command/status blocks?
[04:43:51] <SWPadnos> this looks better: http://www.flipcode.com/articles/article_exceptionhandling.shtml
[04:43:56] <jmkasunich> because the next step follow it
[04:44:00] <SWPadnos> (at first perusal, anyway)
[04:44:07] <jmkasunich> you'd wind up indented 20 deep
[04:44:27] <jmkasunich> petev: what about em?
[04:44:42] <cradek> SWPadnos: much more convincing
[04:44:45] <petev> how about making a queue to get rid of interp_list?
[04:44:54] <jmkasunich> no, I'd not care to talk about that
[04:45:01] <SWPadnos> yep. I didn't remember that you can have multiple catch blocks for different types
[04:45:34] <jmkasunich> ok, the last URL
[04:45:46] <jmkasunich> where is the C++ closing the file?
[04:45:54] <SWPadnos> it's automatic
[04:45:55] <jmkasunich> and freeing the memory?
[04:46:03] <SWPadnos> as would be the freeing of allocated memory
[04:46:20] <jmkasunich> how does it know what needs to be freed or closed
[04:46:20] <SWPadnos> c++ does that automatically when variables go out of scope anyway
[04:46:31] <petev> not automatically
[04:46:33] <jmkasunich> those two functions do NOT do the same thing
[04:46:39] <petev> it calls the destructor
[04:46:53] <petev> you have to put the code in the desctructor
[04:46:57] <jmkasunich> those two functions do NOT do the same thing
[04:46:56] <SWPadnos> right - mallocs aren't automatic, but news are
[04:47:04] <SWPadnos> which two?
[04:47:17] <jmkasunich> "dark days of C" and the C++ below it
[04:47:41] <SWPadnos> note that he says that
[04:47:52] <SWPadnos> "I'll show you the C++ version of the above function later on. I'm not going to just drop it in your lap and expect you to know everything (even if you do...)."
[04:47:54] <cradek> they could improve the C using gotos instead of all the returns
[04:48:00] <SWPadnos> sure
[04:48:11] <petev> that's a bit ugly too
[04:48:40] <jmkasunich> so where is the C++ that is equivalent to the "dark days of C"
[04:48:44] <cradek> hmm, nobody called `troll'
[04:49:08] <SWPadnos> yeah - so is the C++ implementation - it doesn't look "much nicer" to me
[04:49:15] <jmkasunich> cradek: gotos are perfectly acceptable for cleanup after failure, and are regularly used for that in the kernel
[04:49:23] <SWPadnos> it's just above the "empty throws" section
[04:49:24] <jmkasunich> I didn't consider that a troll
[04:49:37] <jmkasunich> SWPadnos: it is?
[04:49:39] <petev> but they often get abused too
[04:49:39] <SWPadnos> heh - me either. you need more lessons from jepler
[04:49:45] <jmkasunich> so that is somehow better than the shorter C code?
[04:49:46] <cradek> I didn't mean it as one, but I figured I'd get called anyway
[04:50:11] <petev> I think error recovery is one of the few legit uses of goto
[04:50:23] <SWPadnos> jmkasunich, well, not really. he uses a mix of C and C++ constructs, and doesn't even use exceptions, which was supposed to be the point (I thought)
[04:50:54] <jmkasunich> If you don't agree that this looks much nicer and is much easier to use than the C version, I don't know what is. =)
[04:50:56] <SWPadnos> he's using the default exception handler, which will close files for you as it aborts the program
[04:51:00] <jmkasunich> says he
[04:51:05] <jmkasunich> I don't agree at all
[04:51:07] <SWPadnos> yeah - that's what I disagreed with :)
[04:51:16] <cradek> aborting a program closes the files in C...
[04:51:22] <SWPadnos> yes, I know
[04:51:32] <SWPadnos> that's part of why his code is a dumb example
[04:51:37] <SWPadnos> thogh it looked nice at first
[04:51:42] <petev> SWPadnos, did u search for poor examples?
[04:51:47] <SWPadnos> (the explanations above anyway)
[04:51:49] <jmkasunich> yeah, but throwing up your hands in disgust and giving the mess to the OS to clean up isn't a fair comparison
[04:51:52] <SWPadnos> well, no :)
[04:52:03] <jmkasunich> after all, the C could have done __exit() for each error
[04:52:15] <SWPadnos> maybe that's why people hate C++ - there are no good examples out there
[04:52:19] <petev> jmk, my interp uses exceptions
[04:52:41] <petev> think about all the lexer and parser stuff
[04:52:53] <petev> it makes for nice error recovery
[04:53:09] <jmkasunich> SWPadnos: maybe the reason there are no good examples out there is because C++ is a hard language to write good code in
[04:53:15] <jmkasunich> (troll ;-)
[04:53:26] <petev> there are books with good examples
[04:53:27] <cradek> every programmer (rightfully) is wary when someone says "BUT IT'S JUST SO MUCH BETTER"! and that's what I often see about C++
[04:53:29] <SWPadnos> I don't think that's true, but it certainly could be (you trolling bastard) :)
[04:53:37] <SWPadnos> or python
[04:53:38] <petev> the stroustrap (sp) is a good one
[04:53:53] <SWPadnos> yeah - I finally replaced the one my mother absconded with
[04:53:57] <SWPadnos> (Stroustrup)
[04:54:14] <petev> cradek, you can write the same code in C, but C++ lets the compiler do more work
[04:54:33] <petev> you could pass the this pointer, and use typecasts, and function tables, etc.
[04:54:35] <petev> no difference
[04:54:41] <SWPadnos> I didn't realize that you could throw an int - I had only seen code that threw some semi-custom exception class
[04:54:54] <petev> just a matter of more compiler checks and compiler generated code
[04:55:21] <SWPadnos> yeah - one instructor basically said "it makes run-time errors into compile-time errors"
[04:55:31] <SWPadnos> and that's a definite win
[04:56:14] <jmkasunich> <troll> does that mean that interpreted languages like Python that turn compile time errors into run time errors are bad </troll>
[04:56:18] <cradek> heh, I've seen those errors, it's not always a win
[04:56:52] <cradek> jmkasunich: man between SWPadnos and you, just be glad jepler isn't here now
[04:57:04] <SWPadnos> heh
[04:57:10] <jmkasunich> (I've been annoyed by that in my miniscule python experience.... run something, it works, then run it with differnt input, it takes a differnet path, and some simple type mismatch or other "obvious to a compiler" error happens
[04:57:32] <cradek> jmkasunich: pick your poison
[04:57:38] <jmkasunich> I forgot he was gone - a good troll wasted
[04:57:46] <cradek> haha
[04:57:53] <cradek> hope he reads back, I'll hear about it tomorrow if so
[04:57:56] <SWPadnos> c++ can actually be used for hardware drivers, but you have to be at least as careful as when writing C driver code
[04:58:13] <petev> I use it on embedded stuff all the time
[04:58:13] <SWPadnos> you can't use python (or bash) for drivers
[04:58:24] <petev> code re-use is much better than with C
[04:58:39] <SWPadnos> right, and compile-time checking is much better
[04:59:25] <jmkasunich> dammit.... tomorrow I gotta turn off IRC or something
[04:59:28] <SWPadnos> heh
[04:59:34] <SWPadnos> today, you mean
[04:59:37] <SWPadnos> :)
[04:59:46] <jmkasunich> 20 more seconds by my clock
[05:00:04] <SWPadnos> 3 seconds ago, by my atomic clock
[05:00:10] <SWPadnos> er - now 15
[05:00:14] <jmkasunich> I really thought I had a chance to do some real work tonight
[05:00:20] <cradek> #emc-concrete-feet-on-the-ground-incremental-devel
[05:00:20] <SWPadnos> last night
[05:00:22] <SWPadnos> ;)
[05:00:30] <jmkasunich> we didn't even settle some of the simple directory stuff
[05:00:32] <SWPadnos> ewwww - what a gross channel
[05:00:40] <SWPadnos> subdirs under m5i20/, I think
[05:00:51] <SWPadnos> they're already there
[05:01:01] <SWPadnos> (though you need a new one for the stepgen version)
[05:01:18] <jmkasunich> see, here's the thing
[05:01:32] <SWPadnos> hmmm - you want to support PWM and/or stepgen with the same driver
[05:01:36] <jmkasunich> the fpga configs don't want to be in multiple dirs
[05:02:07] <jmkasunich> there will be stepgen.vhd, pwmgen.vhd, encoder.vhd (or similar, the encoder is qcounter I think)
[05:02:09] <SWPadnos> so you need a parent dir that has the driver, and separate subdirs for each config, which may use VHDL blocks from the main "morphing: driver
[05:02:16] <jmkasunich> then for each config, there is a top level .vhd
[05:02:42] <jmkasunich> driver and vhdl have nothing in common
[05:03:03] <SWPadnos> there will be VHDL blocks that the driver can deal with, and possibly others that it can't
[05:03:10] <jmkasunich> driver consists of m5i20.c stepgen.c, pwmgen.c, etc
[05:03:16] <SWPadnos> the ones it can deal with should be in the same tree as the driver
[05:03:27] <jmkasunich> lost me
[05:03:35] <jmkasunich> C code sits in one directory
[05:03:40] <jmkasunich> vhdl in another
[05:03:46] <jmkasunich> and never the two shall meet
[05:03:55] <SWPadnos> ok
[05:04:10] <jmkasunich> m5i20/stepgen.c contains code that can deal with stepgen.vhd
[05:04:28] <jmkasunich> bm5i20/pwmgen.c contains code that deals with pwmgen.vhd
[05:04:48] <jmkasunich> there is also misc_bus_interface_crap.vhd
[05:04:52] <jmkasunich> no C code needed for that
[05:05:25] <jmkasunich> and then config1.vhd and config2.vhd that combine different numbers of the various blocks into two configs
[05:05:34] <jmkasunich> config1.bit and config2.bit
[05:06:11] <jmkasunich> the reason I don't want C and vhdl in one dir is that C gets compiled by the EMC make system
[05:06:12] <SWPadnos> try this: http://pastebin.ca/383204
[05:06:28] <SWPadnos> with whatever name changes you like for the dirnames
[05:06:32] <jmkasunich> I have a separate makefile that turns vhdl into bitfiles (if you have the xilinx tools)
[05:06:41] <SWPadnos> ok
[05:07:34] <SWPadnos> unless you want to completely replace the "old" driver, in which case just stick vhdl/ and configs/ under m5i20/
[05:07:45] <jmkasunich> I think I do
[05:08:09] <SWPadnos> I think I'd like to keep this morphing driver separate though - there's no reason to prevent something else (like a DSP config)
[05:08:34] <SWPadnos> and having all the needed variants under the same tree but in separate dirs makes sense
[05:09:07] <jmkasunich> some dsp config that would have its own dedicated hal driver?
[05:09:18] <SWPadnos> yep
[05:09:28] <jmkasunich> OI
[05:09:32] <SWPadnos> (or whatever)
[05:09:46] <jmkasunich> I'm reluctant to add another level of directories for that
[05:10:11] <SWPadnos> that extra level is needed until the old driver is removed, I think
[05:10:41] <jmkasunich> the make system is gonna have to dive down into m5i20 to build the new driver, I don't want it to have to skip thru a pretty much empty m5i20 dir and go even lower to build the driver
[05:11:20] <SWPadnos> ok. that constrains you to putting the driver code in the m5i20 dir, and doing whatever you like with the VHDL code
[05:11:21] <jmkasunich> before the discussion started I was actually thinking of leaving m5i20 untouched, and starting a hal_5i20 dir tree (or something)
[05:11:29] <cradek> with nonrecursive make, you can arrange directories however it makes the most sense, without worrying about depths
[05:11:32] <SWPadnos> hmmm. that could work
[05:11:44] <jmkasunich> cradek: I understand that make doesn't care
[05:11:45] <jmkasunich> I care
[05:11:51] <cradek> ok
[05:12:08] <jmkasunich> right now the code is in drivers/5i20/
[05:12:29] <jmkasunich> and I was gonna put the fpga stuff in drivers/5i20/vhdl or fpga or something
[05:13:05] <jmkasunich> I lied
[05:13:14] <jmkasunich> the code is still one big file, and its in drivers
[05:13:23] <jmkasunich> drivers/hal_5i20.c to be precise
[05:13:26] <petev> the driver code is in driver dir, not m5i20
[05:13:34] <petev> the VHDL is in m5i20
[05:13:37] <jmkasunich> right - and I was doing the same thing
[05:13:43] <petev> and can be deleted with a small change to make
[05:13:59] <petev> why not put the new driver code in m5i20?
[05:14:00] <jmkasunich> but I want to split my driver into multiple files, and don't want to clutter up drivers/
[05:14:11] <petev> we already have subdirs for the VHDL now?
[05:14:31] <petev> I would put all the new driver stuff in m5i20
[05:14:40] <petev> then delete the old driver when it's done
[05:14:55] <petev> you can delete the old VHDL in m5i20 if you change the make file
[05:19:04] <jmkasunich> the makefile reads HOSTM54E.BIT and builds a .h, right?
[05:19:08] <jmkasunich> it doesn't touch the VHDL at all?
[05:19:16] <petev> that's right
[05:20:01] <jmkasunich> all those named subdirs in m5i20/ only have one file in them - a bitfile
[05:20:19] <petev> hang on, I saw VHDL too
[05:20:46] <petev> the VHDL is in the one with src on the end
[05:20:58] <jmkasunich> ok
[05:21:01] <petev> the others are built from that source, supposedly
[05:21:14] <jmkasunich> I looked at the first couple and jumped to a conclusion
[05:21:44] <jmkasunich> I want all my vhdl in one dir
[05:22:04] <steve_stallings> steve_stallings is now known as steves_logging
[05:22:05] <jmkasunich> there will be one top level vhd per config, but all the configs will use the same lower level vhdl
[05:22:19] <petev> I think that's what we have now
[05:22:21] <jmkasunich> and a makefile in that one dir can make them all
[05:22:42] <petev> the dir per bitfile is probably overkill
[05:23:03] <mshaver> * mshaver has been reading the #emc buffer for 45 min to catch up...
[05:23:22] <SWPadnos> I hope you switched to here at the appropriate point :)
[05:23:30] <petev> it got ugly, but nobody got killed ;-)
[05:23:33] <mshaver> yep, just got there
[05:24:04] <mshaver> good thing you guys are separated by geography... & don't have ICBMs
[05:24:21] <jmkasunich> heh
[05:24:22] <SWPadnos> who sez we don't
[05:24:43] <jmkasunich> if we were in the same room, the discussion would have been faster, but the result would be the same
[05:24:43] <SWPadnos> haven't you ever heard of "Neighborhood Nuclear Superiority"? :)
[05:24:53] <SWPadnos> with the possible exception of loss of life
[05:25:20] <mshaver> go on with your m5i20 (sounds like some sort of BMW model) discussion while I read back a bit
[05:26:35] <jmkasunich> ok, lets see
[05:26:52] <jmkasunich> we got the old driver, and its compatible bitfile(s) and VHDL
[05:27:09] <jmkasunich> we got the new driver and its compatible bitfiles and VHDL
[05:27:19] <petev> almost, I think we are missing the ucf file for the build
[05:27:32] <petev> for the old bit file that is
[05:27:40] <jmkasunich> and someday we may have some other "thing" that runs on a 5i20 but doesn't follow the conventions of the new driver - needs a dedicated driver
[05:27:56] <jmkasunich> yeah, I doubt we can build the old bitfiles
[05:27:56] <petev> true
[05:28:01] <jmkasunich> another reason to phase them out
[05:28:18] <jmkasunich> I have a makefile that does build the new stuff
[05:28:28] <jmkasunich> even handles vhdl dependencies ;-)
[05:28:42] <petev> are u planing on making the developers need xilinx tools?
[05:28:52] <jmkasunich> no, the built bit files will be in CVS
[05:29:10] <petev> ok, they change stuff, so we may want to archive the tools
[05:29:16] <jmkasunich> the makefile in the VHDL directory will NOT be invoked by the EMC build system
[05:29:31] <jmkasunich> the tools? they are about a gigabyte
[05:29:43] <petev> I know, but thats for all OS
[05:29:50] <petev> just pick linux I guess
[05:29:52] <jmkasunich> although the subset used by the makefile might be smaller
[05:29:56] <jmkasunich> the linux download was a gig
[05:30:03] <petev> I don't think so
[05:30:10] <jmkasunich> I downloaded
[05:30:10] <jmkasunich> it
[05:30:11] <petev> I think that's the all OS version
[05:30:14] <SWPadnos> it is for 8.x, probably not for 6.x or earlier
[05:30:45] <petev> I definitely have a version for doze only and it's only a few hundred KB
[05:30:45] <jmkasunich> besides, I'm almost certain the licensing would not allow us to "distribute" the tools
[05:30:54] <jmkasunich> they are free of charge, not free software
[05:31:05] <petev> hmm, we may not be able to build later if they change something
[05:31:08] <jmkasunich> 8.x?
[05:31:27] <petev> the VHDL support is notoriously non standard
[05:31:35] <petev> it has been getting better, but you never know
[05:31:47] <petev> I used to have to use synplicity all the time
[05:31:58] <petev> because the xilinx tools wouldn't compile my code
[05:32:01] <jmkasunich> http://www.xilinx.com/ise/logic_design_prod/webpack.htm
[05:32:05] <jmkasunich> this is what I have
[05:32:12] <jmkasunich> to go beyond that page you register
[05:32:20] <jmkasunich> then you pick between doze or linux
[05:32:24] <jmkasunich> each file is about a gig
[05:32:38] <jmkasunich> its bloated a bit since you got your copy I think
[05:32:59] <petev> hmm, I don't have an old linux copy either
[05:33:35] <jmkasunich> I wonder how much is actually needed for our design flow...
[05:33:48] <jmkasunich> I don't use their IDE GUI thing
[05:33:59] <jmkasunich> don't use about 2/3 of the command line tools
[05:34:06] <jmkasunich> and don't use most of the part databases
[05:34:07] <petev> what version do you have?
[05:34:22] <jmkasunich> 8.2i I think
[05:34:36] <jmkasunich> recent - I downloaded it right before christmas
[05:34:51] <petev> hmm, my 9.1.02 linux zip is smaller, but it's corrupt
[05:34:53] <jmkasunich> 8.3i?
[05:34:59] <petev> the download must have failed
[05:35:09] <jmkasunich> 9?
[05:35:28] <petev> that's what is says
[05:35:43] <petev> I have 9.1.02 for both win and linux
[05:35:47] <jmkasunich> they have updated
[05:35:58] <jmkasunich> http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp?iLanguageID=1&sGlobalNavPick=SUPPORT&sSecondaryNavPick=DOWNLOAD
[05:36:03] <petev> win appears to be good and is 445KB exe file
[05:36:22] <jmkasunich> 9.1i Jan 2007
[05:36:33] <SWPadnos> that's got to be a downloader app
[05:36:38] <petev> my file date is 2-28-07
[05:36:44] <petev> hmm, could be
[05:36:52] <SWPadnos> you'll select the parts you want to install and it'll download only those
[05:37:20] <jmkasunich> oops, the dog is whining...
[05:37:21] <jmkasunich> back in a bit
[05:39:47] <jmkasunich> that was the "take me outside please" whine
[05:40:13] <SWPadnos> ... before I make puddles on your equipment ...
[05:40:57] <jmkasunich> dang, I can't find my password to get into the xilinx site
[05:42:00] <jmkasunich> duh, I forgot I used fake yahoo addy
[05:42:02] <jmkasunich> got it now
[05:43:29] <jmkasunich> what a pain in the ass
[05:45:05] <SWPadnos> hmmm. I wonder if my registered version will work in perpetuity or if I'll get screwed because it was part of a design "starter kit"
[05:45:28] <jmkasunich> the "single file download" is 1.4GB for doze or linux
[05:46:01] <jmkasunich> peter wallace told me he's still using version 6.something
[05:46:09] <SWPadnos> is that only windows and Linux, or does it include unix as well?
[05:48:01] <jmkasunich> http://www.pastebin.ca/383235
[05:48:13] <jmkasunich> crudely copied html
[05:48:36] <SWPadnos> interesting
[05:48:40] <jmkasunich> they've changed it since I got the 8.x
[05:48:57] <jmkasunich> because then doze and linux were two differnt files
[05:49:00] <jmkasunich> linux was actually a .sh
[05:49:09] <SWPadnos> I'm downloading EDK 8.1i, which is 784M, for a combined distro, I think
[05:49:15] <jmkasunich> it had a decompressor, followed by the data
[05:49:32] <SWPadnos> anyway, with that downloading, I think I'll call it a night
[05:49:43] <jmkasunich> you can't go yet
[05:49:48] <SWPadnos> oh
[05:50:17] <jmkasunich> ok, m5i20 will contain the C source for the self-adapting driver
[05:50:28] <jmkasunich> m5i20/vhdl will contain vhdl for that
[05:50:38] <jmkasunich> where do we stick the "someday" dsp config and matching driver?
[05:50:58] <jmkasunich> this is why I was thinking of another dir at the /drivers/foo level
[05:50:59] <SWPadnos> either under m5i20/ or in its own dir, I guess
[05:51:03] <jmkasunich> leave m5i20 alone
[05:51:07] <SWPadnos> sure - that works
[05:51:11] <jmkasunich> add new5i20/
[05:51:15] <jmkasunich> and later dsp5i20/
[05:51:20] <SWPadnos> yep
[05:51:35] <jmkasunich> so, I need a name thats better than new5i20
[05:51:46] <jmkasunich> and not as lame as adaptive-driver-5i20
[05:51:53] <alex_joni> hi guys
[05:51:59] <SWPadnos> multi_5i20
[05:52:02] <jmkasunich> up early?
[05:52:05] <SWPadnos> hi Alex
[05:52:09] <alex_joni> unfortunately ;)
[05:52:12] <jmkasunich> hal_5i20?
[05:52:20] <jmkasunich> the exsiting driver is hal_m5i20
[05:52:26] <SWPadnos> argh
[05:52:27] <alex_joni> that will cause confusion
[05:52:42] <SWPadnos> that will be worse than "you can't get that many steps/sec with your config, bonehead"
[05:52:48] <jmkasunich> yeah
[05:53:03] <jmkasunich> right now almost all the drivers are hal_something
[05:53:05] <SWPadnos> 5i20_morph
[05:53:27] <SWPadnos> 5i20_blocks
[05:53:43] <jmkasunich> I dunno why we prefixed them all with hal_
[05:53:48] <SWPadnos> heh
[05:53:54] <SWPadnos> that's your fault :)
[05:54:08] <jmkasunich> I think because we started with parport, and that name was taken by the Linux driver
[05:54:13] <SWPadnos> probably because parport was the first one, and you didn't want to be confused with the kernel module of that name
[05:54:14] <SWPadnos> heh
[05:55:25] <jmkasunich> I guess there is no reason to stick with that convention now
[05:55:37] <jmkasunich> except emc users expectations
[05:55:41] <SWPadnos> except for parport
[05:55:53] <jmkasunich> right - I'm not gonna change any of the existing ones
[05:55:56] <jmkasunich> but the new one...
[05:55:58] <SWPadnos> I think it's good to have lsmod differentiate between ours and theirs ...
[05:56:00] <SWPadnos> sure
[05:56:35] <SWPadnos> hal_m5i20_var
[05:56:43] <SWPadnos> +/- hal_
[05:56:48] <jmkasunich> -m
[05:56:53] <SWPadnos> ok
[05:57:04] <jmkasunich> the board is actually called 5i20, I'm not sure where the m came from
[05:57:11] <SWPadnos> mesa
[05:57:12] <alex_joni> mesa?
[05:57:16] <SWPadnos> mesa!
[05:57:19] <jmkasunich> right, but not sure why it was added to the filenames
[05:57:37] <SWPadnos> because it's a mesa 5i20, not a foobarblatbazmeister 5i20
[05:58:40] <SWPadnos> (that would be the f5i20, I guess ;) )
[05:58:56] <jmkasunich> I so much want to just call it hal_5i20
[05:59:15] <SWPadnos> ok, but you're tech support for that :)
[05:59:32] <jmkasunich> its gonna be the default 5i20 driver, unless somebody does some new config that is just so bizarre that it can't be fitted into the driver scheme
[05:59:40] <SWPadnos> that's true
[06:00:05] <SWPadnos> and hal_m5i20 won't be there at some point - as long as there's no release that has both, it should be relatively OK
[06:00:45] <jmkasunich> so my directory is drivers/5i20
[06:00:55] <jmkasunich> right at the top of the list ;-)
[06:01:10] <SWPadnos> I'd do "mesa_5i20"
[06:01:19] <jmkasunich> ok
[06:01:30] <SWPadnos> because when there's a 5i22, and maybe a 4isomething, it'll be more understandable
[06:01:45] <jmkasunich> eww, forgot about that
[06:01:47] <SWPadnos> (and a 7320 or whatever from someone else ...)
[06:01:53] <jmkasunich> mesa_5i2x ;-)
[06:02:19] <jmkasunich> because I hope this driver (and the associated ROM data format) can adapt to the 5i22 with little change
[06:02:44] <SWPadnos> I'll be that the driver can, but the bitfiles will be totally wrong of course
[06:02:58] <jmkasunich> yeah, there will be 5i22 specific configs
[06:02:57] <SWPadnos> and the VHDL may beed tweaking (though that should be relatively minor)
[06:03:04] <SWPadnos> need
[06:03:10] <jmkasunich> probably have a pwmgen, stepgen, and encoder counter on every pin
[06:03:33] <SWPadnos> heh - with 1.5M gates, you could almost have a CPU on every pin
[06:03:42] <jmkasunich> I'm gonna stick with mesa_5i20
[06:03:56] <jmkasunich> there will be some difference between the 20 and 22 that will force two dirs
[06:04:11] <jmkasunich> if not, the makefile can fetch the common code from wherever
[06:04:28] <SWPadnos> right
[06:04:55] <SWPadnos> you know, it may make sense to have a VHDL (and possibly a verilog) directory under drivers for stepgens and the like
[06:05:21] <jmkasunich> ?
[06:05:24] <SWPadnos> I'm not sure there's any reason to have separate implementations of the VHDL code for the basic functions
[06:05:44] <jmkasunich> I want it under mesa_5i20
[06:05:54] <SWPadnos> hmmm - nevermind. not everyone uses the same internal bus scheme as mesa, so you couldn't use the stepgen from a mesa card with e.g. a pluto or something
[06:05:57] <jmkasunich> someday I may regret that, if the same code can be used for the 5i22
[06:06:09] <SWPadnos> or FPGA_widget_x
[06:06:14] <jmkasunich> but drivers/vhdl is too generic
[06:06:31] <SWPadnos> yep, and would be difficult to make work well, so nevermind
[06:08:28] <petev> you could go for mesa_5i2X or something
[06:08:39] <petev> or we could install svn ;-)
[06:08:42] <SWPadnos> :P
[06:08:56] <jmkasunich> read back, we discused 2x already
[06:10:13] <jmkasunich> http://pastebin.ca/383257
[06:10:15] <petev> no reason not to have specific dirs below for the bit files
[06:10:22] <jmkasunich> here's what I've got
[06:10:28] <petev> if you think the driver can be shared
[06:10:50] <jmkasunich> true
[06:11:01] <jmkasunich> I guess the vhdl dir can be 5i20_vhdl
[06:11:12] <jmkasunich> and the mesa_5i20 dir can be mesa_5i2x
[06:11:29] <jmkasunich> and the driver can be hal_5i2x
[06:11:33] <petev> yes
[06:12:10] <SWPadnos> ok
[06:12:19] <jmkasunich> http://pastebin.ca/383258
[06:13:05] <petev> looks ok, but I wonder if some of the VHDL might not be shared as well
[06:13:23] <jmkasunich> cross that bridge when we come to it
[06:13:26] <petev> surely the compiled result won't be, but maybe some of the blocks
[06:13:50] <jmkasunich> maybe 5i2x_vhdl for the shared stuff, leave the board specific top level stuff in 5i20_vhdl
[06:14:35] <petev> sure, not I don't know what you have in mind for the blocks, but VHDL is usually very portable
[06:14:45] <SWPadnos> go for vhdl/ and configs/ like I had it, both under mesa_5i2x
[06:14:50] <petev> you can parameterize things and really re-use stuff
[06:15:06] <jmkasunich> I sure hope they are - I want to use the same driver, so the behavior, register maps, etc, need to be the same
[06:15:42] <petev> as long as you stick to RTL type stuff, you should be good
[06:16:15] <jmkasunich> I've created the 5i2x_vhdl dir, but for tonight, I'm only gonna commit the driver source and the makefile in 5i20_vhdl
[06:16:23] <jmkasunich> so we're not committed to the other
[06:16:35] <petev> ok
[06:16:47] <jmkasunich> oh, and I need a submakefile to deal with the C in mesa_5i2x
[06:17:15] <petev> do you, or can you just add the path prefix to the one above?
[06:17:37] <jmkasunich> not sure
[06:17:51] <jmkasunich> I'll take a look and figger it out
[06:18:44] <jmkasunich> I think I need to take the current directory out of my prompt
[06:19:01] <jmkasunich> its almost 80 chars long before I start typing the command
[06:19:04] <petev> yeah, getting a bit deep
[06:19:13] <jmkasunich> jmkasunich@ke-main-1006:~/emcdev/emc2head/src/hal/drivers/mesa_5i2x/5i20_vhdl$
[06:19:35] <SWPadnos> you need a 3840x2400 monitor
[06:19:44] <SWPadnos> and a microscope
[06:20:14] <jmkasunich> I need to spend less time in that directory
[06:21:50] <SWPadnos> I need to spend more time in bed
[06:21:52] <SWPadnos> good night :)
[06:21:57] <petev> gn
[06:21:57] <jmkasunich> goodnight
[06:31:24] <petev> what's up with the IniFile::Write()?
[06:31:32] <petev> and how are the values supposed to be updated?
[06:31:41] <petev> there isn't any mechanism for it
[06:31:47] <jmkasunich> at one time parts of emc would mess with the inifile
[06:32:07] <jmkasunich> for instance, if you tuned the PID loop, it would write the new gains to the ini
[06:32:23] <petev> but what's the write() method for?
[06:32:26] <jmkasunich> an abomination IMO, ini files should be edited by humans and read by programs
[06:32:28] <petev> it's totally empty now
[06:32:33] <petev> agreed
[06:32:56] <jmkasunich> its probably a vestige from the days when emc would modify its own ini file
[06:33:01] <petev> without a data struct to represent the file, writing seems like a kludge
[06:33:43] <jmkasunich> the old approach was to read the entire file, echoing everything to a new file, when you hit the var you are trying to write, substiture the new value and keep going
[06:34:11] <petev> man the code is a mess, I think I'll focus on the interface
[06:34:49] <petev> what do you think of the printfs in there?
[06:35:13] <jmkasunich> its 1:35 and I'm trying to prepare something for a commit
[06:35:18] <petev> shouldn't the library code just report error codes and let the app decide how to display?
[06:35:19] <jmkasunich> I can't get sucked off topic again
[06:35:19] <petev> ok
[06:35:26] <jmkasunich> probably
[06:54:27] <jmkasunich> and on that note... time for sleep
[06:54:35] <petev> gn
[09:21:06] <petev> alex, u there?
[15:03:16] <SWPadnos> hmmm. I wonder if we can do some rudimentary "infinite loop detection" in the interp
[15:03:48] <SWPadnos> the user list post about the "current running line" made me think of it
[15:05:41] <cradek> AXIS does highlight the running line - I don't understand what he's asking
[15:06:02] <SWPadnos> ok - I thought there was still a problem with running vs. interpreted line
[15:06:15] <SWPadnos> I guess it's just +/- 1 now, right?
[15:06:18] <cradek> I think both are in status, and AXIS shows the running line
[15:06:27] <cradek> no, it works right
[15:06:33] <cradek> oh you think he's talking about error messages?
[15:06:36] <SWPadnos> could be
[15:06:54] <SWPadnos> his last post was about aborts (segfaults actually)
[15:06:55] <cradek> I don't think so (reading again)
[15:07:05] <SWPadnos> right
[15:07:11] <cradek> yes, the one with the missing bug report
[15:07:16] <SWPadnos> heh
[15:07:17] <cradek> I hate having to fish for a real bug report
[15:07:28] <SWPadnos> "there's a bug" - isnt' that a report?
[15:07:32] <SWPadnos> :)
[15:10:23] <SWPadnos> so - rudimentary (and of course not perfect) loop detection: at each Onnn (or OName), start a list of variables that are assigned
[15:10:36] <SWPadnos> in the list, store the variable name and value
[15:11:08] <SWPadnos> when a goto is done, check all assigned vars - if none have changed, the loop is infinite
[15:11:43] <SWPadnos> of course, since this only finds a small subset of infinite loops, it's probably not worth the complexity
[15:12:43] <cradek> are you sure infinite loops are always a bug? (they pretty much are when using AXIS)
[15:13:07] <SWPadnos> I'd say that an infinite loop using O words is a bug, but I'm not sure that's always truew
[15:13:37] <cradek> except for AXIS, it seems like you could want a machine to repeatedly do something until stopped
[15:13:41] <SWPadnos> sure
[15:13:57] <SWPadnos> there are no infinite loops since the user can always "break" out of it
[15:15:26] <cradek> (it would sure be a nontraditional use of gcode)
[15:15:37] <SWPadnos> heh
[15:15:49] <SWPadnos> we seem to get all the nontraditional users though, so ...
[15:18:05] <cradek> after several rewrites I politely fished for a bug report
[15:18:26] <SWPadnos> heh
[15:18:50] <SWPadnos> you bastadr^W^Ware you stupid^W^W^WCould you please ... :)
[15:21:11] <skunkworks> I tried to loop the peguin a while back.. but it ran so slow I gave up. (using the escape to break out while loading it) but maybe I waited too long before I hit escape. This was just to test for latency on a computer.
[15:24:40] <SWPadnos> re: duerz, you can't configure the machine in sim, since you have no pin lists etc.
[15:26:24] <cradek> ok maybe I still didn't understand the question, thanks
[15:27:00] <SWPadnos> sure
[15:32:32] <SWPadnos> hmmm - are there GPL notices in the configs?
[15:32:41] <SWPadnos> HAL / ini files ...
[15:34:21] <SWPadnos> hmmm - doesn't look like it. is that intentional?
[15:36:38] <cradek> I don't know
[15:36:58] <cradek> some days I think we should have one license statement for the entire distribution
[15:38:34] <SWPadnos> yeah
[15:38:42] <SWPadnos> though lgpl is probably needed in some places
[15:39:45] <cradek> mshaver: there is not a license notice in those new sai files (I know they have a PD history but current practice is to put an explicit GPL notice in all previously-PD files)
[15:56:24] <mshaver> cradek:sorry, my bad... i'll fix it, got carried away with graphs!
[15:56:31] <cradek> mshaver: thanks!
[15:57:18] <skunkworks> mshaver: coming to the workshop this summer?
[15:57:29] <cradek> mshaver: we've had some questions from the FSF after they got a complaint (?!) so we're all really careful about it now
[15:57:52] <mshaver> what about?
[15:58:06] <cradek> mshaver: a typo in a few license statements
[15:58:16] <SWPadnos> GPL 2.1
[15:58:26] <SWPadnos> the nonexistent GPL version
[15:58:33] <mshaver> ahh 2.1 hah!
[16:03:23] <mshaver> re: workshop - yes, probably - june sure is hot though!
[16:04:19] <cradek> maybe we'll have to keep night hours
[16:04:46] <mshaver> suits me!
[16:05:04] <cradek> yeah, me too
[16:05:12] <cradek> that's my plan if it's hot
[16:05:32] <skunkworks> whatever works ;)
[16:06:01] <cradek> mshaver: I wonder if simple electric fans would help any - we could all bring those
[16:06:36] <jepler> I'd find a night schedule difficult
[16:07:28] <skunkworks> jepler: they will just leave sticky notes on thing you need to work on...
[16:07:31] <SWPadnos> it's a lesser of evils thing with no AC in the shop
[16:07:48] <SWPadnos> all over the monitor :)
[16:10:07] <jepler> maybe the bakery has wi-fi
[16:10:28] <jepler> we can work on code there all day, then go play with the mazak at dusk
[16:10:51] <mshaver> * mshaver loves a/c
[16:10:53] <jepler> though you guys all brought desktops, not laptops
[16:10:53] <cradek> I'd be all for that
[16:11:03] <cradek> I'll probably bring both again
[16:11:19] <SWPadnos> desktops are still portable - look at the KayPro
[16:11:33] <jepler> SWPadnos: is that what you'll be bringing?
[16:11:37] <mshaver> i bought a lunchbox chassis from roland last year, maybe i'll bring that :)
[16:11:39] <SWPadnos> err - no
[16:11:55] <SWPadnos> cool - I like those, especially the ones with plasma screens (amber)
[16:12:04] <mshaver> that's what this is!
[16:12:09] <SWPadnos> heh
[16:12:34] <mshaver> now I _have_ to bring it!
[16:12:47] <SWPadnos> I fiddles with an old 286 in one of those cases - it ran Lotus very quickly (and the 386 was even faster!!!)
[16:13:06] <cradek> I've got one of those too - it has a full size ISA slot iirc
[16:13:26] <mshaver> 123 is probably my favorite program of all time
[16:13:29] <cradek> that's where the IBM token-ring card goes of course
[16:14:13] <SWPadnos> two or 4 slots in the ones I worked with, and it took an AT motherboard
[16:14:30] <cradek> ah I'm thinking of the compaq with the plasma screen
[16:55:05] <SWPadnos> hiya Ray
[16:55:18] <rayh> Hi Steven.
[16:55:33] <rayh> Back from the hot country?
[16:55:39] <SWPadnos> yep
[16:55:46] <SWPadnos> -3 degrees, -24 windchill right now
[16:55:58] <SWPadnos> even colder outside ;)
[16:56:32] <rayh> -18 this morning here.
[16:56:40] <jepler> over about 1 hour and 45 minutes of running a program with a 2" radius circle, AXIS memory usage climbed from 28M to 33M "RES" according to top
[16:57:11] <SWPadnos> looping the circle?
[16:57:18] <jepler> the memory used by the backplot is constantly increasing, so it's possible that after running for a long time on a machine without much RAM it would be unable to allocate memory
[16:57:23] <SWPadnos> (ie, O-word looping)
[16:57:27] <jepler> SWPadnos: yes indeed
[16:57:32] <SWPadnos> ok
[16:57:40] <rayh> Mini or tkemc with backplot would be a lot worse!
[16:57:42] <jepler> O1 while [1]
[16:57:45] <SWPadnos> it still does time-based sampling for backplot, right?
[16:57:47] <jepler> SWPadnos: yes
[16:57:58] <SWPadnos> ok, so the complexity of the part(s) doesn't matter
[16:58:37] <rayh> Yep and just keeps adding elements to the canvas.
[16:58:43] <jepler> to some extent it does -- there is a "nearly colinear" test which reduces the number of samples for a straight line considerably
[16:58:51] <SWPadnos> ah - ok
[16:58:58] <jepler> that's why I chose a circle instead of straight lines for my program
[16:59:07] <SWPadnos> right - more or less worst case
[17:00:12] <rayh> logger_dev bookmark
[17:00:28] <rayh> that didn't work.
[17:00:30] <jepler> logger_dev: bookmark
[17:00:30] <jepler> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-06.txt
[17:00:39] <jepler> the ":" must matter
[17:00:42] <jepler> silly program
[17:01:45] <SWPadnos> I think it needs a colon or comma to actually do anything
[17:01:55] <SWPadnos> otherwise you could just be talking about logger_dev
[17:02:10] <rayh> thanks jeff
[17:02:43] <mshaver> cradek: can you get rid of rs274ngc.tool_default and rs274ngc.var in src/emc/sai? They're not used for anything anymore...
[17:02:57] <jepler> mshaver: you can do that youreself: "cvs rm -f filename" then "cvs commit"
[17:03:39] <mshaver> cool! I can never remember these commands after a few months absence
[17:04:13] <rayh> so don't stay away so long. ;)
[17:04:46] <jepler> indeed
[17:06:03] <mshaver> done!
[17:07:05] <mshaver> yea, i guess. it's the relentless (and mostly unsuccessful) search for money that keeps me off here...
[17:09:16] <alex_joni> hi guys
[17:09:27] <alex_joni> glad to see 'new' faces around :D
[17:09:46] <mshaver> hmpf
[17:09:50] <SWPadnos> heh
[17:09:54] <SWPadnos> does matt have a new face?
[17:10:00] <alex_joni> SWPadnos: haha
[17:10:03] <alex_joni> hi Matt
[17:10:11] <mshaver> hey alex!
[17:10:22] <alex_joni> glad to see you
[17:10:28] <alex_joni> gotta run for dinner though
[17:10:32] <alex_joni> I'll be back online in 1-2 hours
[17:10:34] <mshaver> I was just getting up to take a shower & earn some money
[17:10:39] <mshaver> me2
[17:10:49] <mshaver> cu then
[17:10:50] <SWPadnos> yes, please take a shower
[17:10:55] <alex_joni> that's always nice ;) (earn some money)
[17:11:00] <alex_joni> SWPadnos: you may too
[17:11:03] <alex_joni> :P
[17:11:13] <SWPadnos> hmmm - maybe if I took a shower, I'd be able to earn some money :)
[17:11:13] <alex_joni> bbl..
[17:11:18] <SWPadnos> see you Alex
[17:11:19] <mshaver> geez I sound like my daughter on aol or something...
[17:11:30] <SWPadnos> lol, that's so kewl!!!
[17:11:48] <SWPadnos> I hate that
[17:11:50] <mshaver> l8tr
[17:12:12] <SWPadnos> l8r 2 u to!!lol!!!r0x0rzz!!!
[17:12:49] <mshaver> ok, that's it - I'm really gone now.
[17:13:00] <SWPadnos> heh
[17:13:05] <SWPadnos> scared you away, huh?
[18:05:22] <petev> jmkasunich, u there?
[18:05:54] <cradek> he doesn't have irc during the day
[18:06:11] <petev> oh, I just replied to him about the C++ stuff
[18:06:15] <petev> you're ccd
[18:06:21] <petev> what is your opinion?
[18:07:57] <jepler> axis is 37 megs now
[18:08:06] <cradek> my opinion is that you're unlikely to agree with one another about this
[18:08:24] <petev> that may be, but I'm talking about for the code base
[18:08:28] <SWPadnos> heh - Mr Understatement
[18:08:40] <petev> are we going to re-write EMC in C or use C++?
[18:08:53] <cradek> that's a false dichotomy
[18:08:53] <petev> SWPadnos, I'll forward to u
[18:08:59] <SWPadnos> oh, thanks
[18:09:02] <petev> how so?
[18:09:13] <petev> existing C++ code to C
[18:09:16] <petev> why?
[18:09:29] <petev> to avoid a .cc
[18:09:35] <petev> it's already done in other places
[18:10:23] <cradek> bbl
[18:10:48] <petev> what does that mean?
[18:10:49] <SWPadnos> heh - lunch break I guess
[18:10:53] <SWPadnos> "be back later"
[18:10:58] <petev> oh
[18:11:13] <SWPadnos> he's got a regular job, so I assume it's lunchtime
[18:12:05] <rayh> define "regular job"
[18:12:22] <SWPadnos> err - one where you get paychecks at specific intervals
[18:13:28] <rayh> paycheck?
[18:13:44] <SWPadnos> right - those
[18:19:38] <mshaver> petev: cc me too!
[18:19:46] <petev> ok, hang on
[18:20:08] <petev> matt, I don't have an email for you
[18:20:38] <mshaver> mshaver AT erols.com
[18:20:47] <skunkworks> jepler: do you see how it is happening?
[18:20:58] <mshaver> Are you RC electronics?
[18:21:09] <petev> yes, that too
[18:21:33] <mshaver> is that phone # good for calling you?
[18:21:44] <petev> yes
[18:22:09] <mshaver> ok - will do that in about an hour or so, if that's ok
[18:23:20] <jepler> skunkworks: why AXIS is growing in memory use? Yes, I know exactly what it is -- the memory used for the backplot
[18:23:43] <jepler> skunkworks: probably I should change the code so that "extremely old" backplot information is discarded
[18:23:48] <petev> mshaver, sure
[18:24:04] <mshaver> ok, going to eat now back shortly
[18:24:44] <skunkworks> jepler: cool - sounds like a solution.
[18:25:35] <jepler> skunkworks: it requires that I decide what "extremely old" means, and find a definition that satisfies everyone
[18:26:01] <SWPadnos> hahahaha
[18:26:04] <SWPadnos> sorry
[18:27:17] <skunkworks> I can see that as being an issue - as the extremely old might get confusing as you might think that it hasn't been cut yet.
[18:27:45] <skunkworks> but hopefully you know what your program does. ;)
[18:28:02] <skunkworks> sorry - changed gears in mid thought
[18:42:20] <rayh> Reading back is fascinating. Yes some of the gui's work properly remote. Or did the last time I checked.
[18:42:32] <rayh> Some of them can work in parallel with others.
[18:43:04] <rayh> petev has asked the why nml question before and even proposed alternatives.
[18:43:32] <rayh> None of which give any of the flexibility of the existing communication structure.
[18:43:37] <rayh> IMO of course.
[19:56:46] <alex_joni> hi guys
[19:57:11] <alex_joni> rayh: I don't think petev suggested we should drop NML
[19:57:22] <alex_joni> at least not in all places
[19:57:56] <SWPadnos> the idea is more to use it like an encapsulated interface, like it's supposed to be used
[19:58:05] <SWPadnos> and maybe change it a bit along the way :)
[19:59:27] <rayh> hi alex
[20:00:08] <alex_joni> I think petev (didn't manage to read back fully) suggested to drop the use of NML for passing content around
[20:00:15] <alex_joni> not the mechanism itself
[20:00:59] <alex_joni> GUIs will still use NML to talk to task
[20:01:28] <SWPadnos> there are some changed requirements since EMC was first designed (aside from the obvious orders of magnitude of performance and memory increase)
[20:01:30] <mshaver> Is it OK to create a branch in the CVS repository?
[20:01:30] <alex_joni> but one of the major 'ugly' designs is hardcoding pre/portconditions in emctaskmain based on NML message
[20:01:40] <alex_joni> mshaver: sure
[20:01:44] <SWPadnos> depends on what for :)
[20:02:07] <rayh> NML was intended to distribute commands between processors as well.
[20:02:16] <rayh> a processor for IO and another for motion.
[20:02:32] <alex_joni> right.. but I wonder how many machines like that you ever saw
[20:02:46] <rayh> I've tried a couple times here.
[20:02:47] <mshaver> OK, what happens if I move stuff around, rename files, make new unique directories, etc?
[20:03:04] <alex_joni> rayh: actual need for that?
[20:03:07] <mshaver> in the new branch ;)
[20:03:11] <alex_joni> or just trying to see if it works?
[20:03:22] <rayh> Yes. There are large machines that need that ability.
[20:03:24] <alex_joni> mshaver: some of it will be visible in the TRUNK
[20:03:30] <jepler> mshaver: creating directories on branches doesn't really work as you might desire
[20:03:48] <jepler> creating files either
[20:03:50] <alex_joni> a folder is repository-wide
[20:03:58] <rayh> And I know of at least one work cell that distributes stuff to a number of working machines at a distance from each other.
[20:04:01] <mshaver> I'm hoping that all of that would be completely invisible
[20:04:11] <jepler> it is not entirely invisible
[20:04:14] <alex_joni> rayh: I can see the need for that
[20:04:16] <mshaver> to everybody else
[20:04:22] <mshaver> darn
[20:04:27] <jepler> if you create a directory on a branch, it exists for everyone in all branches
[20:04:39] <alex_joni> rayh: although I can't see the need for IO to be separate
[20:04:51] <alex_joni> I see the theoretical niceness .. but that's about it
[20:05:06] <mshaver> so, the new sai dir now exists in old brances that didn't have it?
[20:05:06] <rayh> My thinking is several microprocessor based IO systems.
[20:05:11] <rayh> one for tool change,
[20:05:13] <SWPadnos> mshaver, yes
[20:05:19] <rayh> one for pallet shuttle
[20:05:23] <rayh> and such.
[20:05:29] <alex_joni> mshaver: if you check out the branch with cvs up -d then you'll get an empty sai dir
[20:05:30] <SWPadnos> but they're "not there" when you check out
[20:05:47] <SWPadnos> with -dP, the empty dir won't be there, right?
[20:05:50] <jepler> SWPadnos: right
[20:05:50] <alex_joni> SWPadnos: they are there, but usually get removed by P
[20:05:55] <SWPadnos> ok
[20:06:09] <jepler> but it produces extra messages and extra time in "cvs up" because that directory has to be visited
[20:06:13] <jepler> by every "cvs up" or "cvs co"
[20:06:16] <SWPadnos> right
[20:06:22] <jepler> even if no files exist
[20:06:46] <SWPadnos> alex_joni, I wouldn't eliminate the possibility of remote I/O just because we don't have examples of it being an absolute necessity
[20:06:58] <alex_joni> SWPadnos: me neither.. just talking here ;)
[20:07:06] <alex_joni> * alex_joni is not removing anything :P
[20:07:09] <SWPadnos> I would, however, be happy with some remote HAL (ideally RT, but non-RT is OK as well) replacement for NML-based I/O
[20:07:15] <SWPadnos> sure
[20:07:36] <alex_joni> remote HAL is so limited
[20:08:07] <rayh> We talked a bit long ago about running several HAL's at the same time.\
[20:08:48] <SWPadnos> we have two different needs for remote I/O
[20:08:53] <mshaver> so, if big changes are likely in a source tree, then make a new module?
[20:09:13] <SWPadnos> one is getting info to and fro, and the other is executing commands somewhere other than where the commands are generated
[20:10:38] <rayh> SWPadnos: How do both of these things get accomplished with NML or do they?
[20:10:40] <alex_joni> mshaver: yeah
[20:10:55] <SWPadnos> rayh, damfino? :)
[20:11:15] <SWPadnos> since NML isn't RT, I think it only deals with the second option, for the most part
[20:11:42] <mshaver> Is it OK to create a new module in the CVS repository?
[20:11:46] <SWPadnos> I tihnk there can only be one I/O endpoint though, with the current system
[20:12:00] <alex_joni> mshaver: I'm not sure if you can do that
[20:12:01] <SWPadnos> I should look at an NML file before saying that though
[20:12:12] <alex_joni> but you can ask cchris to do it, I see no reason against it
[20:12:53] <rayh> I'm with Alex on matt creating a new module.
[20:13:03] <jepler> what is the purpose of the new module:
[20:13:04] <jepler> ?
[20:13:19] <mshaver> alex_joni: I'm sure I don't _know how_ to do that!
[20:13:58] <jepler> the proposed new modules, I should say
[20:14:33] <cradek> a branch, not a new module, is surely what you want
[20:14:49] <SWPadnos> depends on the number of created/deleted dirs and files, no?
[20:14:57] <mshaver> jepler: Last night you, petev, jmk, et al were talking about moving & renaming files & dirs. It screws up the current CVS operations.
[20:15:21] <cradek> no, it just causes the moved files to lose their history
[20:15:25] <mshaver> * mshaver doesn't want to screw up the regular development
[20:15:28] <jepler> mshaver: last night petev was proposing to rename files and directories, and everyone else was against it because it has limited value and lots of downsides
[20:16:47] <rayh> There are some megafiles that are simply collection boxes for stuff that should have been separated out into logically related smaller files.
[20:16:51] <cradek> we already have empty directories; cvs up -dP just removes them for you (it prunes empty directories after the update)
[20:17:21] <mshaver> jepler: Yes, but if those changes were part of playing around with a refactoring effort, the refactorers wouldn't want to mess up the day to day productivity of the regular devels
[20:18:46] <mshaver> jepler: But, if such a thing were done by making another repositry, or using some foreign VCS (like git or svn), that would be kind of "unsocialbe".
[20:18:59] <SWPadnos> are there objections to branching an "EMC3" effort now, for very experimental changes? (this would be under the assumption that EMc2 is still "the" release, until people are happy with emc3)
[20:19:13] <mshaver> err, unsociable
[20:19:15] <jepler> SWPadnos: yes, there are
[20:19:21] <jepler> I would object
[20:19:28] <jepler> what is the goal?
[20:19:31] <mshaver> you know, unfrienly!
[20:19:32] <SWPadnos> ok - what's your objection(s)?
[20:19:37] <rayh> I don't like emc3
[20:19:51] <SWPadnos> hey - you haven't even seen it :)
[20:19:52] <cradek> right now I object too
[20:20:08] <SWPadnos> ok - political, technical, other problems?
[20:20:19] <alex_joni> * alex_joni still reads back yesterday and todays logs before objecting
[20:20:31] <rayh> But I agree with matt that any major emc refactor is going to be disruptive.
[20:20:37] <jepler> if the goal is "let's split up megafile.c into file1.c file2.c and file3.c; it'll take about 3 weeks and I'll be collaborating with two other developers", do it on a branch and merge it back in in three weeks
[20:20:52] <cradek> making a new module causes you to lose the history on all files, and also all other benefits of CVS, like merging that you can do to roll a change into the trunk
[20:21:11] <jepler> if the goal is "I object to the location of inifile.cc in the source tree", I just don't see fixing it as important given that we are using CVS
[20:21:56] <rayh> A refactor of the EMC stuff really isn't a major feature add, hence my thinking that we don't want to call it emc3.
[20:22:08] <SWPadnos> there have been many discussions about a HAL refactor, changing the upper messaging layer(s), making changes to the upper layers to fix problems (ilke the fact that a remote UI needs to have G-code files in the exact same location as the machine controller), etc.
[20:22:10] <cradek> and if they diverge enough that they can't be reconciled (which they will), our users will all lose while you try to make emc3 a suitable product for release
[20:22:20] <SWPadnos> sure, I can see that
[20:22:25] <mshaver> * mshaver should troll professionally...
[20:22:30] <jepler> from a marketing standpoint, we shouldn't get rid of the "emc2" name so soon after using it in stable releases
[20:22:35] <SWPadnos> sure
[20:23:00] <SWPadnos> think like Ubuntu - there will be 6-10 releases before LTS support is retired
[20:23:57] <SWPadnos> there's still lots of development on the bleeding-edge versions, and I don't think it detracts from the LTS release (for most people)
[20:23:56] <cradek> if you want to split up files, eliminate some dependencies, whatever - there's every reason to do that on a branch
[20:24:21] <mshaver> I just don't want to inadvertantly do something that upsets everybody.
[20:24:38] <SWPadnos> so the objections to moving / renaming / whatever-ing files go away if it's done on a branch?
[20:24:40] <cradek> try to keep the moving of files to a minimum, but if you're pretty much rewriting a file from scratch, put the new one where you want it
[20:24:47] <jepler> SWPadnos: not mine
[20:25:10] <SWPadnos> do they get somewhat abated?
[20:25:22] <jepler> SWPadnos: technically, it makes merging harder (e.g., bugfix from src/libfoo/foo.c on the branch to src/liboldfoo/foo.c on the trunk)
[20:25:33] <SWPadnos> sure
[20:25:42] <jepler> SWPadnos: vicerally, renaming files produces so little concrete benefit
[20:25:59] <mshaver> jepler has a really good point also; I don't want to draw useful talent away from MAIN.
[20:26:09] <SWPadnos> I'd expect this branch to be used for some specific developments, then either be merged/accepted into the TRUNK, or dropped
[20:26:28] <cradek> mshaver: can you say in more concrete terms what you would like to do? Bonus points for avoiding the fuzzy term "refactor"
[20:26:48] <mshaver> If a branch, I was going to call it UNSTABLE.
[20:26:51] <cradek> SWPadnos: yes! and that's exactly why to not make a new module
[20:26:53] <SWPadnos> maximize the synergistic energies between peer sub-modules
[20:26:58] <SWPadnos> :)
[20:27:15] <mshaver> wait, first I have to laugh at SWP
[20:27:24] <cradek> mshaver: so that means your plan is to ... destabilize it?
[20:27:34] <cradek> mshaver: :-P
[20:27:39] <SWPadnos> cradek, no problem - it sjust seemed that there were exceedingly deep-rooted objections to doing anything in the "main" CVS module
[20:27:47] <cradek> mshaver: maybe a more positive goal would be nice
[20:27:48] <SWPadnos> err - main EMC2 mocule
[20:28:08] <mshaver> cradek: OK, that's a fair shot...
[20:28:33] <SWPadnos> just having a branch where radically different approaches can be tried without backlash from other developers would be good, IMO
[20:28:35] <jepler> SWPadnos: no, my deep-rooted objections are to doing murky things ("make the C++ code not suck") or useless things ("'rename' the files and directories")
[20:28:45] <SWPadnos> ok - that's fair
[20:29:32] <mshaver> cradek:, but no. I was thinking of: 1. consolidating the interface to .ini data & parameter (var) data.
[20:29:34] <rayh> You know we had a very similar sort of fuss when JMK went off and started his own module at SF.
[20:30:00] <jepler> I'm sure
[20:30:03] <cradek> rayh: how long did that take to stabilize into something usable and releasable?
[20:30:10] <rayh> It did get messy when other developers began copying stuff over.
[20:30:11] <SWPadnos> rayh, that was noted yesterday, with jmk taking the role of Paul :)
[20:30:31] <rayh> Yep. There were some tough times.
[20:30:38] <cradek> rayh: I also would have argued that it was the wrong approach then
[20:31:08] <SWPadnos> do you have another approach to radical changes? (other than "don't do that")
[20:31:16] <rayh> Yea. It's just that so much was being created from whole cloth.
[20:31:27] <cradek> make them incrementally
[20:31:42] <rayh> Let's take an example. INI read
[20:31:43] <jepler> SWPadnos: that question has no answer
[20:31:58] <SWPadnos> ok, but at some point, an increment will appear to have no value (such as adding a file with half the contents from a different file, so that things are split up better)
[20:32:08] <rayh> Can/do we want to create a single ini reading system.
[20:32:26] <SWPadnos> I think we do, but I don't think it can be done "soon"
[20:32:43] <SWPadnos> wait - do you mean ini files, or whole configs?
[20:32:48] <mshaver> cradek: 2. Reducing the connection from ... this is hard for me to put in words... instead of all the emc code including a bunch of libnml stuff, make it so it includes one small header file and calls a small set of functions to use the NML.
[20:33:15] <SWPadnos> "separate module interfaces and usage sensibly"
[20:34:10] <cradek> mshaver: I think #1 and #2 can be done in (their own) branches
[20:34:23] <cradek> mshaver: neither seems like it will involve a major restructuring of, say, directories
[20:34:43] <cradek> mshaver: then, we can see how they go, and roll them into the trunk if they're good
[20:34:45] <mshaver> I guess I tend to say "refactor" when I mean that I want to convert from our current spiderweb style archetecture to a hierarchial one.
[20:36:22] <SWPadnos> there should be some opportunity to do things like move all headers into a single include/* hierarchy (for example)
[20:37:07] <SWPadnos> (not saying that we need to do that, just using it as an example of a code "cleanup" / reorganization that has no immediate end-user benefit)
[20:37:07] <mshaver> cradek: That's fair. When I was in charge of this mess a few years ago, my biggest problem was not upsetting people. Pretty much to the extent that I just gave up. So now I intend to tread lightly ;) .
[20:37:09] <jepler> it would be great to decide which header(s) constitute our public interface and only include those in the -dev package / "make install"
[20:37:28] <cradek> pardon my language, but when someone comes along and says "I want to redo everything!" half of us say "hell yeah" and the other half say "oh shit". A more measured approach lets us move past that and talk about the necessary changes themselves and how best to do them.
[20:37:31] <jepler> right now, "virtually all" header files are copied into <top>/include
[20:38:49] <jepler> that should include (A) stuff to build realtime and non-realtime HAL Modules, (B) stuff to build user interface programs, and (C) maybe stuff to build gcode interface programs
[20:38:54] <mshaver> Like what jepler just said!
[20:41:05] <mshaver> If it's OK, maybe we should create UNSTABLE (that is I think what the Debian folks call thier bleeding edge branch) & see what can be done without changing directory names or renaming files.
[20:41:36] <mshaver> I think most of the changes would be ab.c is split to a.c & b.c
[20:41:39] <SWPadnos> that's kind of what TRUNK is, but some changes may need an "even further out" branch
[20:41:57] <petev> jepler, you there?
[20:42:11] <mshaver> so, what is the mission statement of TRUNK (that's for you SWP)
[20:42:19] <jepler> petev: yes
[20:42:30] <petev> I just looked at your commit on inifile.cc
[20:42:33] <petev> it will not work
[20:42:43] <petev> the destructor closes the file when out of scope
[20:42:47] <SWPadnos> mshaver, no comment ;)
[20:42:52] <petev> also, the open in inifile locks the file
[20:42:57] <mshaver> oops, pausing for real business...
[20:42:57] <petev> the open in halcmd does not
[20:43:19] <petev> seems like that could be an issue if some app mods the file while EMC is trying to read it
[20:43:36] <SWPadnos> that last problem would be with the existing halcmd code, not the change
[20:43:44] <petev> true
[20:44:06] <jepler> petev: please read the code more closely. Look at what the new constructor for Inifile does.
[20:44:12] <jepler> petev: I belive your remarks are mistaken
[20:44:29] <SWPadnos> it doesn't actually open the file, it just does an fcntl on it
[20:44:52] <petev> I see the flag, but the destructor and close ignore it
[20:45:45] <petev> SWPadnos, which line?
[20:45:58] <jepler> bool Inifile::close()
[20:46:01] <jepler> if(close_fp)
[20:45:59] <jepler> tmp = fclose(fp);
[20:46:31] <SWPadnos> Inifile::Inifile(FILE *fp_, bool owner) doesn't open the file
[20:46:43] <SWPadnos> Inifile::Inifile(const char *file) does
[20:47:02] <petev> jepler, ok, I see that now was looking higher up
[20:48:13] <jepler> I would be less surprised to learn I did the locking wrong, but I am confident the file doesn't get closed prematurely
[20:49:08] <petev> I'll incorporate your changes with the exception stuff and put the locking in a method so it's not duplicated
[20:50:35] <jepler> I was mostly interested in showing that the "C" API could be preserved without duplicating code
[20:50:52] <petev> no question about that
[20:51:04] <petev> the bigger question is why do it that way?
[20:51:18] <SWPadnos> how difficult is it to sync a branch to TRUNK? (ie, keep a branch name like EXPERIMENTAL, but only use it when there are experimental features/changes to test)
[20:51:49] <cradek> SWPadnos: the branch is from a certain point, so you'd want to make a new branch (with a name that describes the new feature you want to work on)
[20:52:20] <SWPadnos> ok, I was thinking of trying to not pollute that namespace much, and also to make it a bit easier to test the "current set of radical changes" by updating
[20:52:21] <cradek> SWPadnos: like the rigid_tap branch I made a few days ago. Alex and I are working together on that, and it records the history of our work forever, and if it works out we'll roll those changes into trunk
[20:52:32] <SWPadnos> sure
[20:52:59] <cradek> SWPadnos: don't worry about the namespace. It records the work, which is the point of rev control.
[20:53:45] <SWPadnos> ok
[20:53:57] <cradek> if you want to have a tag (called EXPERIMENT or whatever) that you move around to a branch you want people to play with, that's no problem
[20:54:11] <SWPadnos> ok - that would do, similar to -rv2_1
[20:54:16] <cradek> but people are probably more interested in testing a certain new feature than "experimenting"
[20:54:16] <SWPadnos> _branch
[20:54:30] <cradek> a tag would be similar to what we did with TESTING
[20:54:43] <SWPadnos> or stable, for that matter (it seems to me)
[20:54:52] <cradek> err yeah
[20:54:59] <cradek> we did both I think
[20:55:12] <SWPadnos> right - -rv2_1_branch moves with the current release
[20:55:36] <cradek> yes that is a branch tag, not a tag of certain particular versions
[20:56:00] <SWPadnos> ok, so something like an EXPERIMENTAL tag would do what I'm thinking of
[20:56:00] <cradek> actually it doesn't move with the current release, it moves as the HEAD of that branch moves
[20:56:17] <SWPadnos> ok
[20:56:35] <cradek> yes, you could have a tag like that, it would point to whatever branch contains the feature you're experimenting with right then
[20:56:56] <SWPadnos> OT: should there be a LATEST tag that moves around with the latest release? (or is that RELEASE or somthing)?
[20:57:05] <mshaver> You know, cradek has made a point that resonates with me - I'm only a uniprocessor machine & I have a few calls still pushed on the stack: 1. last few changes to sai to make it read the latest tool file. 2. a few more things I want to do with the include graphs. 3. I want to do some function call graphing before i even start to think about what to change. SO, I'll do these things one at a time & see where they should be put.
[20:57:17] <cradek> there is a tag RELEASE_x_y_z for each release
[20:58:27] <cradek> mshaver: that sounds great to me - no need to lump separate tasks together and then maybe have to break them apart to reconcile with trunk later
[20:59:13] <mshaver> OK, that's what I'll do!
[21:00:33] <cradek> mshaver: I'm always happy to help with the cvs part if you need me
[21:02:56] <mshaver> OK! Once I get to a stopping point with graphing, maybe we could make a "graphs" target that you can make.
[21:03:33] <cradek> sure, that might be something like how the docs are built now, but these are docs for programmers
[21:06:26] <mshaver> OK, going away now for a while to squirt insecticide in a cat's ears - back in a while (depending upon the cat)
[21:06:38] <cradek> eek, good luck to both of you
[21:06:46] <SWPadnos> heh - have fun :)
[21:06:53] <cradek> did you see xkcd.com?
[21:07:04] <jepler> haha yeah
[21:09:38] <alex_joni> logger_dev: bookmark
[21:09:38] <alex_joni> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-06.txt
[21:10:08] <mshaver> http://xkcd.com/c26.html
[21:10:19] <mshaver> now really, the cat is wating...
[21:44:29] <alex_joni> jmkasunich: you around?
[21:51:21] <alex_joni> anyone knows what "number of rotor segments" referrs to?
[21:52:29] <alex_joni> is that the same as 'poles' ?
[21:52:53] <SWPadnos> depends on the number of brushes, I bet
[21:54:17] <alex_joni> why can't you just say yes
[21:54:23] <alex_joni> need to make it more complicated
[21:57:12] <SWPadnos> I think it's proportional to the number of poles, but the number of brushes also affects that (I think)
[21:57:25] <alex_joni> * alex_joni wonders why jmkasunich is not around
[21:57:48] <skunkworks> he is probably still working
[21:57:51] <skunkworks> <4:30
[21:57:58] <alex_joni> right
[21:58:07] <skunkworks> oh - he is in a different time zone than me I think
[21:58:23] <SWPadnos> he's on EST, I believe
[21:58:30] <SWPadnos> and it's about 5:00 here
[21:58:33] <alex_joni> I'm only a letter away
[21:58:36] <alex_joni> EEST
[21:58:38] <alex_joni> :D
[21:58:41] <SWPadnos> heh
[22:00:49] <skunkworks> my servos have 8 brushes - neener neener neener
[22:01:22] <alex_joni> I just need the number of poles to set the servo
[22:01:30] <alex_joni> it's not working as it should :(
[22:02:02] <SWPadnos> I'd try multiplying segments by brushes/2 as a first approximation
[22:02:18] <SWPadnos> then divide, then take out the factor of 2, then put it in the numerator instead of denominator
[22:02:25] <SWPadnos> by that time jmk should be here, and he can tell you :)
[22:02:48] <skunkworks> that was mean ;)
[22:18:09] <alex_joni> skunkworks: not really, I know how to do that :P
[22:18:40] <skunkworks> * skunkworks thought SWPadnos was making shit up... what do I know
[22:18:56] <SWPadnos> I was, but it's firmly grounded in my lack of knowledge about motors
[22:19:23] <alex_joni> skunkworks: we're just messing around
[22:20:43] <alex_joni> I wasn't seriously waiting for an answer from SWPadnos
[22:21:19] <SWPadnos> smart man
[22:21:33] <alex_joni> at least not for motor-related stuff
[22:21:53] <SWPadnos> heh
[22:21:55] <alex_joni> there are fileds where he knows his sh*t
[22:21:56] <alex_joni> :D
[22:22:06] <alex_joni> fields even
[22:22:08] <SWPadnos> and fields where I know shit :)
[22:22:08] <skunkworks> :)
[22:22:15] <alex_joni> yeah that
[22:22:38] <SWPadnos> hmm - that's one of those "opposites mean the same thing" phrases
[22:23:25] <SWPadnos> like "duh" and "no duh"
[22:23:35] <SWPadnos> or "flammable" and :inflammable"
[22:30:03] <skunkworks> you should listen to 'a way with words' on npr
[23:47:06] <jmkasunich> petev: you around?
[23:47:12] <petev> yes
[23:47:29] <jmkasunich> I started looking at the commit mail for your changes
[23:47:32] <jmkasunich> and I'm confiused
[23:47:40] <petev> with what?
[23:47:44] <jmkasunich> Emc-commit] emc2/src/emc/usr_intf/axis/extensions emcmodule.cc
[23:47:51] <jmkasunich> while(1) {
[23:47:51] <jmkasunich> - out = self->i.find(s2, s1, num);
[23:47:51] <jmkasunich> + out = self->i.Find(s2, s1, num);
[23:47:51] <jmkasunich> if(out == NULL) {
[23:47:56] <jmkasunich> what changed?
[23:48:12] <petev> yes, I changed Inifile to IniFile so I could find all places used and fix all leaks
[23:48:20] <petev> that was just a name change there
[23:48:33] <jmkasunich> oh, I missed the case change
[23:48:41] <jmkasunich> I've always hated mixed case
[23:48:50] <petev> about 30% of the other files had memory leaks
[23:49:01] <petev> I got rid of the global vars and leaks
[23:49:14] <jmkasunich> the name change was just to find all the vars?
[23:49:21] <petev> next step is to use try/catch and clean up the error handling
[23:49:25] <jmkasunich> it makes a very confusing diff
[23:49:34] <petev> yes, not the best, but I didn't want to miss anything
[23:49:37] <jmkasunich> did anything actually _change_ in that file?
[23:49:47] <petev> no, not in the axis stuff
[23:49:50] <jmkasunich> thats what grep is for?
[23:50:01] <jmkasunich> grep -R identifier *
[23:50:13] <petev> I wanted to make sure I didn't miss anything
[23:50:27] <petev> this way all uses of the variables would come up
[23:50:54] <jmkasunich> but you have diffs in the cvs history that mean nothing
[23:51:24] <petev> is that a big deal? the new name is more readable anyhow
[23:51:44] <jmkasunich> I should shut up now
[23:52:04] <jmkasunich> can't...
[23:52:18] <petev> are we to be concerned about not changing white space and names for readability when cleaning up?
[23:52:25] <jmkasunich> we've had debates in the past, because people would run indent, resulting in confusing diffs
[23:52:59] <jmkasunich> the general concensus is don't mess with the formatting, and follow the format of the file you are in, not your own personal style
[23:53:07] <petev> hmm, seems hard to clean the code up if you can't make edits for stuff like that
[23:53:14] <petev> there was no consistency
[23:53:19] <jmkasunich> like I said, we've had debates about it
[23:53:24] <jmkasunich> and I was on the change it side
[23:53:44] <petev> then we should make some coding guidlines to be followed
[23:53:46] <jmkasunich> you weren't here for those debates, I'm just letting you know the way the community decicded to go
[23:53:52] <petev> as the code is not consistent at all
[23:54:04] <jmkasunich> there is (was?) a coding style doc
[23:54:20] <petev> some places funcs are lower case, some upper, some lower with _, etc.
[23:54:33] <petev> but all the code is different right now
[23:54:45] <petev> and even mixed withing the same file
[23:54:56] <jmkasunich> I know - thats life when the codebase is 10 years old
[23:55:00] <jmkasunich> thats why the arguments
[23:55:01] <petev> so when doing clean up are we to just leave it just for the diffs?
[23:55:16] <jmkasunich> I'm not going to have the arguement again
[23:55:24] <petev> I don't want to argue
[23:55:24] <jmkasunich> I lost the last time
[23:55:30] <petev> just asking
[23:55:36] <jmkasunich> (and the last time, I was following your position)
[23:56:11] <petev> well, I don't see how the code will ever get cleaned up if we worry about this kind of thing
[23:56:12] <jmkasunich> the real issue is when somebody makes a functional change that touches 5 lines, and at the same time a formatting change that touches 300
[23:56:26] <jmkasunich> someone reviewing the diff (perhaps to find a bug) can't see the real change
[23:56:37] <jmkasunich> I voted for cleanup only commits
[23:56:49] <jmkasunich> but it still wasn't popular
[23:56:56] <petev> trust me, there's a lot of formating that I would clean up, but I left it
[23:57:06] <petev> I only fixed the files with major edits
[23:57:10] <petev> and what it effected
[23:57:17] <jmkasunich> when a bug is known to have appeared between X and two weeks before X, people don't like dealing with big diffs to find it
[23:57:51] <petev> on the other hand, bugs would be less likely and easier to find with a clean code base
[23:58:04] <jmkasunich> I know
[23:58:10] <petev> but if the position is to just leave stuff as is, then so be it