Re: [Aptos-devel] apt360 on M$FT

On Wednesday 18 December 2013, you wrote:
> Thanks for the reply! Nice work on those reels ;-)
>
> 1) AFAIC, I figure you own the project so you tell me what you want me to
> do with the Windows version.  I'm happy to send you WIN32 executables to
> try as well as any and all source and project files. If you want to add
> them to the sourceforge project, that would be great. The more eyeballs /
> developers on the project the better AFAIC.
>
If you give me your Sourceforge user name, I can add you to the developers 
list for cvs access.

> I have been out of pro software since 8/2011, the latest VC I've got is
> VC9, part of VS2008. I generally try to stick to the ANSI / ISO standards,
> no real familiarity w/ the GCC tool chain at this point but I've used some
> of the open source code w/ windows projects in the past (ex. regex++,
> cygwin).
>
> Any time you want to move this exchange to the sourceforge aptos email list
> is fine, too.
>
I haven't done much with the Sourceforge stuff for a while, so I am trying to 
figure out a little bit of it now. I will keep you posted.  I am going to try 
CC'ing this to the list.

> 2) I pulled down the 1.0.2 gz, made a new VS2008 project and got that
> building but some of the example files fail in an odd way (search for
> 'ERROR' in the following lst files). I've attached:
>
> - 'mods.txt' details about what I changed to get it to build w/ VS2008
> - '1st.apt' and '1st.lst' isolates the issue I'm seeing.
> - 'spool.lst' the output from the 'spool.apt' test case
>
> The stack error is in the 'export_surf.cpp' module ;-)
>
> 3) Studied what you were doing w/ invoking the postprocessor so - for now -
> I've got together ~70% of a dedicated postprocessor for my Haas GT-20
> lathe. It's soooo much easier w/ C++ compared to circa 1982 with Fortran!
> Figure to try that first and if I can get the control flow to work then
> I'll revisit the scripting mechanism.
>
> 4) Tried converting one of my VCS-APT programs (attached as 'dozer-pin.apt'
> and 'dozer-pin.lst'). The obvious show stoppers:
>
> - REDEF/ON and REDEF/OFF not supported
> - SHAPE/... not supported
> - LATHE/... not supported
> - Fortran logical expressions (ex. .EQ., etc) not supported
>
I think that apt360 has some limited capabilities for redefinition with the 
"CANON" statement (see 3.22.2 of the manual). That wouldn't be as capable, of 
course, but it might be a work-around.

The logical expressions are pretty meager. Some control flow could probably 
converted using the "IF" statement.  8.1.5 of the manual has an example using 
CANON and the LOOP that might be helpful.
> In the dozer-pin example I eliminated the not supported constructs for now.
>
> * With the 1.0.0 code base I get erroneous FEDRAT records in the CLFILE,
> easy to see listing.
> * With the 1.0.2 code base I get errors on LX=LINE/XAXIS like 'spool.apt'
>
> 5) My problem is I use VCS-APT on a Win XP box for virtually all my CNC
> lathe programming. But it's a 16-bit app that does not run 'native' on my
> newer Windows 7 laptop and I cannot get it to run correctly with the
> virtual XP subsystem on Windows 7. My best guess is Bob's expecting local
> file paths (ex: "C:\ProgramF~\...") but under virtual XP it's seeing UNC
> paths which it's not prepared to handle.
I wonder if Bob would allow you to look at his source and do some work on it.

>
> While I'd love to have a graphical front end, my first preference is to get
> the core processor working reliably. After that then, yah, I'm all for
> something graphical! BTW, in the attached 'dozer-pin.apt' you'll see some
> INSERT cmds at the beginning that contain pass thru content for the
> Predator CNC Editor. VCS-APT has some primitive graphics capability but
> http://www.predator-software.com came w/ my BobCADCAM and works well for
> verification for now.
>
> 6) The reason I jumped on trying to get a "C++ version" running to begin
> with was:
>
> - tighter error compile time error checking
> - be able to have an 'AptProcessor' class one could make multiple instances
> of within one process
>
> Given the processing power we have today, being able to have multiple
> instances of an AptProcessor in one process could make it easier to then
> have a graphical front end without having to add a bunch of special code
> into the core for undo / rollback processing. Just have two (or more)
> instances, add the new step to one instance, if there's an error then dump
> that instance and clone the previous good instance.
>
> 7) I tried chasing down that NASA COSMIC APT off and on for a number of
> years, too. Finally got a copy of the source ~1985 on a QIC but (a) who's
> got a device that can read that format (b) it's probably degraded by now.
>
> I've got some thoughts on why it's hassle to get it but better to discuss
> with a different mechanism ;-)
>
> Phil
I'm not sure how to add the Windows changes to the code base, but if you want 
to work on something, and add some downloads for Windows people, I'm all for 
it.  I will probably be one of the first downloads, actually :)
Brent.