aptos-devel Mailing List for Aptos

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.

On Wednesday 18 December 2013, you wrote:
> Hey Brent,
>
> Please see attached screen shot.
>
> VC allows user to control structure member alignment. The 'defaul't is
> dependent on the target platform, so for Intel 32-bit believe it's 4 but
> I'll confirm that.
>
> Can you tell me what the equivalent setting is you are using???
>
> Given all the equivalence / structs, no doubt this could be creating an
> issue w/ my builds.
>
> Set it to 1 byte alignment and rebuilt, also attached the resulting build
> log.
>
> Don't think it helped. For the 'LX=LINE/XAXIS' stmt, I'm still going into
> 'a_line_' with argument '*n=0' (invoked from 'adfpre' with 'nr=0').
>
> Phil
>
> On 12/17/2013 11:17 PM, Brent Muller wrote:
> > On Monday 16 December 2013, you wrote:
>
> <snip>
The only real compiler setting that I found to be absolutely necessary is to 
turn optimization completely off. By default, gcc compiles at a "-O2" setting, 
(An Autotools added setting, I think)  and I had to change it to "-O0"(no 
optimizations).  Following code in a debugger like DDD requires optimizations 
off, but it seems that I remember it being necessary to keep weird things from 
happening, since the Fortran code was doing stuff that would probably be 
unexpected to a optimizer.

Here is a link to the manual page of gcc on optimizations:

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Below is the last lines of the build output off my machine- "gcc" is the c 
compiler, "g++" is the c++ compiler for the c++ files I have(export_surf.cpp). 
The "-M" flags are for makefile dependency tracking, so probably are irrelevant 
for you. The "-g" is debugging output in the code, which never seemed to 
bother anything, so I left it in the production code I use. It looks like it 
links with the "g++" compiler. The "g++" lines have the "-O2" setting.  I hope 
that helps. I might fire up a Windows machine with the code you sent, and see 
what happens if I get the time, but I don't know too much about Windows stuff.
Later! Brent.

gcc -DHAVE_CONFIG_H -I. -I..    -DTOP_BLD_DIR="/home/brent/apt360" -
DBINDIR="/usr/local/bin" -I../libf2c/ --static -g -O0 -MT main.o -MD -MP -MF 
.deps/main.Tpo -c -o main.o main.c                                                                         
main.c: In function 'parse_args':                                                                                             
main.c:50: warning: incompatible implicit declaration of built-in function 
'abort'                                            
mv -f .deps/main.Tpo .deps/main.Po                                                                                            
gcc -DHAVE_CONFIG_H -I. -I..    -DTOP_BLD_DIR="/home/brent/apt360" -
DBINDIR="/usr/local/bin" -I../libf2c/ --static -g -O0 -MT ASM.o -MD -MP -MF 
.deps/ASM.Tpo -c -o ASM.o ASM.c                                                                             
mv -f .deps/ASM.Tpo .deps/ASM.Po                                                                                              
gcc -DHAVE_CONFIG_H -I. -I..    -DTOP_BLD_DIR="/home/brent/apt360" -
DBINDIR="/usr/local/bin" -I../libf2c/ --static -g -O0 -MT aptpos.o -MD -MP -MF 
.deps/aptpos.Tpo -c -o aptpos.o aptpos.c                                                                 
mv -f .deps/aptpos.Tpo .deps/aptpos.Po                                                                                        
g++ -DHAVE_CONFIG_H -I. -I..    -DTOP_BLD_DIR="/home/brent/apt360" -
DBINDIR="/usr/local/bin" --static -g -O2 -MT export_surf.o -MD -MP -MF 
.deps/export_surf.Tpo -c -o export_surf.o export_surf.cpp                                                        
mv -f .deps/export_surf.Tpo .deps/export_surf.Po                                                                              
g++ -DTOP_BLD_DIR="/home/brent/apt360" -DBINDIR="/usr/local/bin" --static -g -
O2   -o apt360 A2CTRL.o ABKKPR.o ACALSP.o ACANCK.o ACANGT.o ACANPT.o ACCALL.o 
ACCINT.o ACENTR.o ACLAS7.o ACLS12.o ACNTR2.o ACNTRL.o ACONE1.o ACPLAN.o 
ACPYTP.o ACROSS.o ACSCF.o ACYLND.o ADCLAR.o ADDST.o ADDSTR.o ADDTB.o ADECIS.o

 <snip a bunch of linked files> 

 NNTAIN.ASM.o PARNOM.ASM.o PRATTWPP.ASM.o PROBOGPP.ASM.o PTW4EPP.ASM.o 
PUNCHA.ASM.o PUNIDN.ASM.o SAM.ASM.o SC4020PP.ASM.o SECZROPP.ASM.o SETMIN.ASM.o 
SHIFT.ASM.o SUNTRNPP.ASM.o TRUTRAPP.ASM.o TRWPP.ASM.o USERTN.ASM.o main.o 
ASM.o aptpos.o export_surf.o ../libf2c/libf2c.a -lgsl -lgslcblas -lm
/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-
linux/bin/ld: Warning: size of symbol `a1stab_' changed from 184 in ACLAS5.o 
to 192 in BLOCK5.o
/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-
linux/bin/ld: Warning: alignment 4 of symbol `adfprl_' in ADFPRL.ASM.o is 
smaller than 32 in ADFPRE.o