On Sep 25, 2012, at 09:42 , Kent A. Reed wrote: > I like Gene's second approach because it doesn't require the author of a > G-code routine to know anything about the directory structure the code > may end up in; e.g., the combination of a routine and its supporting > subroutines is portable. The only thing I didn't like about Sebastian's > modification is the addition of yet another variant syntax into our > variant of RS274/NGC. The notion of rolling over from the current > directory to the system-defined directory is fine with me.
I like Michael Haberler's suggestion of adding a magic cookie to the SUBROUTINE_PATH, like ".", which would mean "search the directory of the currently open file". Folks who like this behavior can turn it on, folks who dislike it can turn it off, and our gcode dialect doesn't get any more complicated. Let's say the SUBROUTINE_PATH is ".:/home/seb/linuxcnc/nc_subroutines", and let's say I've opened a gcode file in the directory "/home/seb/project-123". When the main program calls a subroutine, it would search for the subroutine first in "/home/seb/project-123" where the main program lives, let's say the sub is not found there. Then it would search in "/home/seb/linuxcnc/nc_subroutines", let's say we find it there. Now, we're in that subroutine, and it calls another subroutine. Where are we going to search for this second subroutine? I think we should search in the directory of the caller, not in the directory of the main program, in other words i think that "." now means "/home/seb/linuxcnc/nc_subroutines", since we're inside a subroutine that lives in that directory. Does that sound right? -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
