Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Sebastian Kuzminsky]

(Please CC the emc-developers list in any replies you send.)


On 10/28/2015 02:27 AM, Nick wrote:
> Hello Sebastian. 
> 
> You should consider Fern's
> repo http://fernv.github.io/linuxcnc-features/ as it is latest one.
> 
> We are interested in including Features into linuxcnc repo because it
> will male it's install much much easier. 

Hi Николай and Fernand, a LinuxCNC developer named Dewey Garrett has
copied the files from github.com/cnc-club/linuxcnc-features.git into a
branch in linuxcnc named "bringin_features":

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/bringin_features

We may redo it based on this information that Fern's repo is the one to
use, or we may just copy Fern's files over the files we imported.

Once this gets finalized and Features is in LinuxCNC, will you use our
repo as the central place for future bugfixes and development?  That
would bring new Features features and bugfixes to users in the fastest
and most direct way.

We could give you push access to our repo, or you could send us pull
requests on Github if you prefer.

A bunch of us played around with it and were very impressed.  I'm
excited to get this into the hands of all LinuxCNC users in the next
release.


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Fernand Veilleux]

Le 2015-10-26 13:09, Sebastian Kuzminsky a écrit :
> Hello Nick and Fernand, I'm a developer on the LinuxCNC project and 
> we've been talking about getting linuxcnc-features into the next 
> stable release of linuxcnc.
>
> Is this something you'd be interested in, willing to help with?
>
> We noticed that there are two linuxcnc-features repos on github, what 
> is the relationship between them?
>
>

Hello Sebastian,

I must admit you took me by surprise when you wrote you wanted to 
include features in next stable release.
I knew it would be interesting but I though that it needed some more 
refinements before.

I have a tight schedule currently and cannot spend much time to rush the 
project.

It seems that you deleted bringing_features and I do not blame you. I 
hope you still think that it is a very good add-on
to linuxcnc, nothing else comes close. Since I wrote more than 90% of 
the code I am the one that knows it best and I will help you.

But you should not work with version 2.0 it is outdated, having been 
released about 4 months ago.
Version 2.01 released last month is much better. They both have much 
code and files to delete.
Those releases were the first I made and it was some kind of market test 
to find the interest.

I believe version 2.02 will be ready to include in stable linuxcnc and I 
am proposing you what I know will work.
Please correct me on what does not fit your view.


Features depend on a good directory structure and links to those 
directories.

APP_PATH : /usr/features
files in this dir : features.py
 features.glade
 features.ui
 CHANGES
 README.md
sub-dirs :  catalogs
 lathe
 mill
 examples
 graphics
 images
 ini
 lathe
 mill
 lib
 support

Working dir : $HOME/linuxcnc/features
 link to APP_PATH/features.ui
 links to APP_PATH/...
 catalogs
 examples
 graphics
 ini
 lib
 support

USER_DATA : $HOME/linuxcnc/features/user (not $USER, full access)
 (preferences file will be saved there, no need to create)
sub-dirs :  catalogs
 lathe   (files that will be saved here : default 
template and history)
 mill(user will save his modified menu.xml)
 graphics
 ini
 lib
 scripts (or the name you think is best, this is where 
resulting file 'features.ngc' will be saved)
 xml
No files need to be created. This is where the user puts his 
modified files.
Features will first search files in USER_DATA and use it if 
found, else it uses APP_PATH


Links needed :
 /usr/local/bin/features to APP_PATH/features.py (stand alone from 
anywhere, no need for args, everything from defaults or preferences file)

 /usr/share/pyshared/gladevcp/features.glade -> APP_PATH/features.glade
 /usr/lib/pymodules/python2.7/gladevcp/features.glade -> 
APP_PATH/features.glade
 /usr/share/pyshared/gladevcp/features.py -> APP_PATH/features.py
 /usr/lib/pymodules/python2.7/gladevcp/features.py -> 
APP_PATH/features.py

 optional :
 /usr/share/pyshared/gladevcp/features_user -> USER_DATA


Files to edit :
 /usr/share/pyshared/gladevcp/hal_pythonplugin.py
 /usr/share/glade3/catalogs/hal_python.xml


Linuxcnc ini files
 axis-features.ini, axis_mm-features.ini and axis_lathe-features.ini 
could be added in sim.axis
 without any other files
 OR
 sim.axis.features dir could be created with the needed files

 Similar option for gmoccapy


This is what I am preparing for release 2.02
I hope to have it ready in less than one month. Some new features I am 
adding are very difficult to implement, gcode is terrible IMHO.


Regards
Fernand



























--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[andy pugh]

On 6 November 2015 at 04:29, Fernand Veilleux  wrote:
> gcode is terrible IMHO.

It's a terrible programming language, but then it was never intended to be one.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 2:53 AM, andy pugh wrote:
> On 6 November 2015 at 04:29, Fernand Veilleux 
>  wrote:
>> gcode is terrible IMHO.
>
> It's a terrible programming language, but then it was never intended 
> to be one.

fine, but what is better?  STEP-NC (ISO-10303/14649)?

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[andy pugh]

On 6 November 2015 at 12:57, EBo  wrote:
>> It's a terrible programming language, but then it was never intended
>> to be one.
>
> fine, but what is better?  STEP-NC (ISO-10303/14649)?

It is a machine control language, not a programming language.
If you want a programming language then it probably makes sense to use
one, and to output G-code (or direct motion commands)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 6:19 AM, andy pugh wrote:
> On 6 November 2015 at 12:57, EBo  wrote:
>>> It's a terrible programming language, but then it was never 
>>> intended
>>> to be one.
>>
>> fine, but what is better?  STEP-NC (ISO-10303/14649)?
>
> It is a machine control language, not a programming language.
> If you want a programming language then it probably makes sense to 
> use
> one, and to output G-code (or direct motion commands)

I'm not disagreeing, and in fact that is what I typically do.  I was 
curious what people thought was better for both machine control and 
something that straddles general programming and machine control?

Put another way, what is the state of the art with regards to machine 
control and motion primitive programming?

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Gene Heskett]

On Friday 06 November 2015 04:53:15 andy pugh wrote:

> On 6 November 2015 at 04:29, Fernand Veilleux  
wrote:
> > gcode is terrible IMHO.
>
> It's a terrible programming language, but then it was never intended
> to be one.

I wouldn't condem it quite that vociferously.  It has the basic trig 
functions, all the basic control loop stuff, and several ways to do a 
subroutine.  My biggest and loudest bitch is the inability to 
troubleshoot an errant arc move in a subroutine that may have 10 of them 
in it,  it gets blamed on the line that calls the sub.  I have had to 
convert my blanket-chest code from 3 subroutines, to multiple copies of 
the subroutine but inline.  In the process, I probably have 300 LOC out 
of 650 or so that are never executed.  Its a horrible mess, but it 
works.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> On Friday 06 November 2015 04:53:15 andy pugh wrote:
>
>> On 6 November 2015 at 04:29, Fernand Veilleux 
>> 
> wrote:
>> > gcode is terrible IMHO.
>>
>> It's a terrible programming language, but then it was never intended
>> to be one.
>
> I wouldn't condem it quite that vociferously.  It has the basic trig
> functions, all the basic control loop stuff, and several ways to do a
> subroutine.  My biggest and loudest bitch is the inability to
> troubleshoot an errant arc move in a subroutine that may have 10 of 
> them
> in it,  it gets blamed on the line that calls the sub.  I have had to
> convert my blanket-chest code from 3 subroutines, to multiple copies 
> of
> the subroutine but inline.  In the process, I probably have 300 LOC 
> out
> of 650 or so that are never executed.  Its a horrible mess, but it
> works.

So then the question is "how do we develop better debugging tools?"  or 
at least analytic tools of the results?  For example, I can see 
generating a little more output to go from the motion planner to the 
tool path display.  If those lines and arcs had the program line number 
somehow associated with it, then you would be able to possible zoom in 
and ask a question about a specific line segment displayed.  It would 
then tell you which line of code generated it.  There might also be 
other metadata you want to associate with it (like depth of recursion or 
stack depth, ... hmmm... I do not know off the top of my head).  If we 
did not provide analytics, then it would be good to be able to step into 
a subroutine to execute it as well as run a call.  Last version of LCNC 
I used had *something* like this, but I do remember that it did not play 
well with subroutines.  Not sure about the latest and greatest.  What I 
am envisioning here is the GDB equivalent of motion control -- full 
variable querying and setting capabilities, and the ability to set break 
points and other useful functionality.

Just a thought...  now back to my normal programming...

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Dewey Garrett]

> ...
> It seems that you deleted bringing_features
> ...

The 'bringin_features' branch rebased on git master was deleted to
avoid confustion with a newer branch 'features_preview' based
on git 2.7 (the current release)

> ...
> But you should not work with version 2.0 it is outdated, having been 
> released about 4 months ago.
> Version 2.01 released last month is much better. They both have much 
> code and files to delete.
> ...

The 'features_preview' branch brings in files from
   https://github.com/FernV/linuxcnc-features.git
starting at commit dfd2btb marked (v2.01)

> ... 
> Features depend on a good directory structure and links to those 
> directories.
> 

Please see posts with 'features_preview' in the Subject for 
additional information on the implemented directory structure.
-- 
Dewey Garrett


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Gene Heskett]

On Friday 06 November 2015 09:09:26 EBo wrote:

> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
> >> On 6 November 2015 at 04:29, Fernand Veilleux
> >> 
> >
> > wrote:
> >> > gcode is terrible IMHO.
> >>
> >> It's a terrible programming language, but then it was never
> >> intended to be one.
> >
> > I wouldn't condem it quite that vociferously.  It has the basic trig
> > functions, all the basic control loop stuff, and several ways to do
> > a subroutine.  My biggest and loudest bitch is the inability to
> > troubleshoot an errant arc move in a subroutine that may have 10 of
> > them
> > in it,  it gets blamed on the line that calls the sub.  I have had
> > to convert my blanket-chest code from 3 subroutines, to multiple
> > copies of
> > the subroutine but inline.  In the process, I probably have 300 LOC
> > out
> > of 650 or so that are never executed.  Its a horrible mess, but it
> > works.
>
> So then the question is "how do we develop better debugging tools?" 
> or at least analytic tools of the results?  For example, I can see
> generating a little more output to go from the motion planner to the
> tool path display.  If those lines and arcs had the program line
> number somehow associated with it, then you would be able to possible
> zoom in and ask a question about a specific line segment displayed. 
> It would then tell you which line of code generated it.  There might
> also be other metadata you want to associate with it (like depth of
> recursion or stack depth, ... hmmm... I do not know off the top of my
> head).  If we did not provide analytics, then it would be good to be
> able to step into a subroutine to execute it as well as run a call. 
> Last version of LCNC I used had *something* like this, but I do
> remember that it did not play well with subroutines.  Not sure about
> the latest and greatest.  What I am envisioning here is the GDB
> equivalent of motion control -- full variable querying and setting
> capabilities, and the ability to set break points and other useful
> functionality.
>
> Just a thought...  now back to my normal programming...
>
>EBo --
>
Well, such thoughts would find me encouraging the effort for sure.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 4:44 PM, Gene Heskett wrote:
> On Friday 06 November 2015 09:09:26 EBo wrote:
>
>> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
>> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
>> >> On 6 November 2015 at 04:29, Fernand Veilleux
>> >> 
>> >
>> > wrote:
>> >> > gcode is terrible IMHO.
>> >>
>> >> It's a terrible programming language, but then it was never
>> >> intended to be one.
>> >
>> > I wouldn't condem it quite that vociferously.  It has the basic 
>> trig
>> > functions, all the basic control loop stuff, and several ways to 
>> do
>> > a subroutine.  My biggest and loudest bitch is the inability to
>> > troubleshoot an errant arc move in a subroutine that may have 10 
>> of
>> > them
>> > in it,  it gets blamed on the line that calls the sub.  I have had
>> > to convert my blanket-chest code from 3 subroutines, to multiple
>> > copies of
>> > the subroutine but inline.  In the process, I probably have 300 
>> LOC
>> > out
>> > of 650 or so that are never executed.  Its a horrible mess, but it
>> > works.
>>
>> So then the question is "how do we develop better debugging tools?"
>> or at least analytic tools of the results?  For example, I can see
>> generating a little more output to go from the motion planner to the
>> tool path display.  If those lines and arcs had the program line
>> number somehow associated with it, then you would be able to 
>> possible
>> zoom in and ask a question about a specific line segment displayed.
>> It would then tell you which line of code generated it.  There might
>> also be other metadata you want to associate with it (like depth of
>> recursion or stack depth, ... hmmm... I do not know off the top of 
>> my
>> head).  If we did not provide analytics, then it would be good to be
>> able to step into a subroutine to execute it as well as run a call.
>> Last version of LCNC I used had *something* like this, but I do
>> remember that it did not play well with subroutines.  Not sure about
>> the latest and greatest.  What I am envisioning here is the GDB
>> equivalent of motion control -- full variable querying and setting
>> capabilities, and the ability to set break points and other useful
>> functionality.
>>
>> Just a thought...  now back to my normal programming...
>>
>>EBo --
>>
> Well, such thoughts would find me encouraging the effort for sure.

I will add this to the end of a 50 level project queue...  Seriously 
though, it might not be that bad to implement.  A bit noisy though (but 
that is what dubug switches are for).  Hmmm... maybe if Google Summer of 
Code sponsored it, this would be a useful idea and suitable for an 
intern project...

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Kenneth Lerman]

Right now, you get an error together with a line number.

A good fix would be to do a stack backtrace. If it is in a subroutine, show
the line that it was called from including the values of all of the
arguments. Then, if that line is in a subroutine, show where it was called
from with its arguments. Recursively.

A second aid that would be handy is to have tracing. As each line is
interpreted, output the raw line (and file:linenumber) to a file. Also
output the expanded values of any arguments. (So: X[#21+#44] would be
output with as X[4.] if that's the sum.) When an error is detected, the
trace file would be flushed so that the user could look at it.

A third aid would be like gdb. It would have the ability to set a
breakpoint on a line. It would also cause a "break" when there was an
error. Within this tool, one could look at the current subroutine stack,
look at local and global named parameters, etc.

The first two tools would be pretty easy. The third would be somewhat
harder.

Ken


On Fri, Nov 6, 2015 at 11:11 PM, EBo  wrote:

> On Nov 6 2015 4:44 PM, Gene Heskett wrote:
> > On Friday 06 November 2015 09:09:26 EBo wrote:
> >
> >> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> >> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
> >> >> On 6 November 2015 at 04:29, Fernand Veilleux
> >> >> 
> >> >
> >> > wrote:
> >> >> > gcode is terrible IMHO.
> >> >>
> >> >> It's a terrible programming language, but then it was never
> >> >> intended to be one.
> >> >
> >> > I wouldn't condem it quite that vociferously.  It has the basic
> >> trig
> >> > functions, all the basic control loop stuff, and several ways to
> >> do
> >> > a subroutine.  My biggest and loudest bitch is the inability to
> >> > troubleshoot an errant arc move in a subroutine that may have 10
> >> of
> >> > them
> >> > in it,  it gets blamed on the line that calls the sub.  I have had
> >> > to convert my blanket-chest code from 3 subroutines, to multiple
> >> > copies of
> >> > the subroutine but inline.  In the process, I probably have 300
> >> LOC
> >> > out
> >> > of 650 or so that are never executed.  Its a horrible mess, but it
> >> > works.
> >>
> >> So then the question is "how do we develop better debugging tools?"
> >> or at least analytic tools of the results?  For example, I can see
> >> generating a little more output to go from the motion planner to the
> >> tool path display.  If those lines and arcs had the program line
> >> number somehow associated with it, then you would be able to
> >> possible
> >> zoom in and ask a question about a specific line segment displayed.
> >> It would then tell you which line of code generated it.  There might
> >> also be other metadata you want to associate with it (like depth of
> >> recursion or stack depth, ... hmmm... I do not know off the top of
> >> my
> >> head).  If we did not provide analytics, then it would be good to be
> >> able to step into a subroutine to execute it as well as run a call.
> >> Last version of LCNC I used had *something* like this, but I do
> >> remember that it did not play well with subroutines.  Not sure about
> >> the latest and greatest.  What I am envisioning here is the GDB
> >> equivalent of motion control -- full variable querying and setting
> >> capabilities, and the ability to set break points and other useful
> >> functionality.
> >>
> >> Just a thought...  now back to my normal programming...
> >>
> >>EBo --
> >>
> > Well, such thoughts would find me encouraging the effort for sure.
>
> I will add this to the end of a 50 level project queue...  Seriously
> though, it might not be that bad to implement.  A bit noisy though (but
> that is what dubug switches are for).  Hmmm... maybe if Google Summer of
> Code sponsored it, this would be a useful idea and suitable for an
> intern project...
>
>EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>



-- 
Kenneth Lerman
55 Main Street
Newtown, CT 06470
--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

Agreed on all accounts.  It is also possible that options 1 and/or 2 
could be structure in such a way to support option 3 (simula gdb).

I was serious about the intern thing.  If one was interested I would be 
glad to try to help with mentioning, but I have roughly a petabyte of 
data to process at work (seriously), and it will be months before I have 
enough time to pick anything else up, and the couple of side projects I 
have not already swept under the rug are not getting much love.  I 
cannot take this one on.

   EBo --

On Nov 9 2015 11:15 AM, Kenneth Lerman wrote:
> Right now, you get an error together with a line number.
>
> A good fix would be to do a stack backtrace. If it is in a 
> subroutine, show
> the line that it was called from including the values of all of the
> arguments. Then, if that line is in a subroutine, show where it was 
> called
> from with its arguments. Recursively.
>
> A second aid that would be handy is to have tracing. As each line is
> interpreted, output the raw line (and file:linenumber) to a file. 
> Also
> output the expanded values of any arguments. (So: X[#21+#44] would be
> output with as X[4.] if that's the sum.) When an error is 
> detected, the
> trace file would be flushed so that the user could look at it.
>
> A third aid would be like gdb. It would have the ability to set a
> breakpoint on a line. It would also cause a "break" when there was an
> error. Within this tool, one could look at the current subroutine 
> stack,
> look at local and global named parameters, etc.
>
> The first two tools would be pretty easy. The third would be somewhat
> harder.
>
> Ken
>
>
> On Fri, Nov 6, 2015 at 11:11 PM, EBo  wrote:
>
>> On Nov 6 2015 4:44 PM, Gene Heskett wrote:
>> > On Friday 06 November 2015 09:09:26 EBo wrote:
>> >
>> >> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
>> >> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
>> >> >> On 6 November 2015 at 04:29, Fernand Veilleux
>> >> >> 
>> >> >
>> >> > wrote:
>> >> >> > gcode is terrible IMHO.
>> >> >>
>> >> >> It's a terrible programming language, but then it was never
>> >> >> intended to be one.
>> >> >
>> >> > I wouldn't condem it quite that vociferously.  It has the basic
>> >> trig
>> >> > functions, all the basic control loop stuff, and several ways 
>> to
>> >> do
>> >> > a subroutine.  My biggest and loudest bitch is the inability to
>> >> > troubleshoot an errant arc move in a subroutine that may have 
>> 10
>> >> of
>> >> > them
>> >> > in it,  it gets blamed on the line that calls the sub.  I have 
>> had
>> >> > to convert my blanket-chest code from 3 subroutines, to 
>> multiple
>> >> > copies of
>> >> > the subroutine but inline.  In the process, I probably have 300
>> >> LOC
>> >> > out
>> >> > of 650 or so that are never executed.  Its a horrible mess, but 
>> it
>> >> > works.
>> >>
>> >> So then the question is "how do we develop better debugging 
>> tools?"
>> >> or at least analytic tools of the results?  For example, I can 
>> see
>> >> generating a little more output to go from the motion planner to 
>> the
>> >> tool path display.  If those lines and arcs had the program line
>> >> number somehow associated with it, then you would be able to
>> >> possible
>> >> zoom in and ask a question about a specific line segment 
>> displayed.
>> >> It would then tell you which line of code generated it.  There 
>> might
>> >> also be other metadata you want to associate with it (like depth 
>> of
>> >> recursion or stack depth, ... hmmm... I do not know off the top 
>> of
>> >> my
>> >> head).  If we did not provide analytics, then it would be good to 
>> be
>> >> able to step into a subroutine to execute it as well as run a 
>> call.
>> >> Last version of LCNC I used had *something* like this, but I do
>> >> remember that it did not play well with subroutines.  Not sure 
>> about
>> >> the latest and greatest.  What I am envisioning here is the GDB
>> >> equivalent of motion control -- full variable querying and 
>> setting
>> >> capabilities, and the ability to set break points and other 
>> useful
>> >> functionality.
>> >>
>> >> Just a thought...  now back to my normal programming...
>> >>
>> >>EBo --
>> >>
>> > Well, such thoughts would find me encouraging the effort for sure.
>>
>> I will add this to the end of a 50 level project queue...  Seriously
>> though, it might not be that bad to implement.  A bit noisy though 
>> (but
>> that is what dubug switches are for).  Hmmm... maybe if Google 
>> Summer of
>> Code sponsored it, this would be a useful idea and suitable for an
>> intern project...
>>
>>EBo --
>>
>>
>> 
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>


--
Presto, an open s