Re: [Bug-apl] Macintosh compile errors and warnings SVN 581

[Juergen Sauermann]

  
  
Hi Peter,
  
  thanks, should be fixed in SVN 582.
  
  /// Jürgen
  
  

On 03/30/2015 07:35 PM, Peter Teeson
  wrote:


  Hi Jürgen:
Congratulation on the 1.5 release….
So to keep you busy here are some issues on Mac OS X 10.8.5 

respect….

Peter

Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh::257257::2626:0: Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:278:26: ./../Workspace.hh:278error: non-ASCII characters are not allowed outside of literals and identifiers:26
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:0: 26error::  non-ASCII characters are not allowed outside of literals and identifierserror
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:257:26: Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:258:26: Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src:26: Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:278:26: Non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:26:rw_sv_def(Quad_Quad,  ⎕)non-ASCII characters are not allowed outside of literals and identifiers
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/Workspace.hh:279:26: Non-ASCII characters are not allowed outside of literals and identifiers

Shell Script Invocation Warning Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/file_io.cc:1273:25: Comparison of unsigned _expression_ < 0 is always false




  

Re: [Bug-apl] incompatible workspace 1.4 vs 1.5

[Juergen Sauermann]

  
  
Hi Fausto,
  
  the bug should be fixed in SVN 582. It was an old
  ⎕-function (⎕PT) that was removed in the meantime.
  
  /// Jürgen
  
  

On 03/31/2015 11:22 AM, Fausto Saporito
  wrote:


  Hello Jürgen,

thanks for the clarification. Yes I did as you wrote. I created the
saved workspace with APL 1.4, then I dumped with that version and
read-back in APL 1.5 without any problem.

Attached, by the way, there's the problematic workspace.

regards,
Fausto


2015-03-30 18:19 GMT+02:00 Juergen Sauermann :

  
Hi Fausto,

I would need the workspace in order to reproduce this.

In GNU APL there are two commands (and two file formats) for saving
workspaces: )SAVE and )DUMP.
The )LOAD command understands both formats.

The "classical" )SAVE command saves (serializes) the internal data
structures of the interpreter into an .xml file.
That normally works unless these data structures change. In other words,
)LOAD is only expected to work with the
same (SVN version of the) interpreter. Since the saved data structures do
not change that often, sometimes )LOADing
a workspace from a different interpreter version works. The text format of
the .xml file makes it possible to fix
minor incompatibilities.

The newer )DUMP command uses a completely different approach. Instead of
serializing the internal data structures
of the interpreter, it writes APL code that, when executed, bring the
interpreter into the same state that it had when the
)DUMP command was issued. The file produced is also a text file hat can be
edited with a normal text editor (read: vi)
if needed if the )LOAD should fail. The only disadvantage of the )DUMP
command is that the )SI stack is not saved
(which is kind of impossible to reconstruct with APL code). An advantage is
that it is fairly straightforward to read or
write this format even with APL interpreters of other vendors. Therefore it
is the preferred format of choice for archiving
and documentation purposes.

If you have )SAVEd an old workspace, then you can do this:

1. figure the SVN version used to )SAVE it. Unless  the SVN version is very
old, it is written in the  tag
of the .xml file like this:



2. If you don't have a working GNU APL with that SVN revision then check it
out and build it.
Look at file buildtag.hh which should have the following line:

#define ARCHIVE_SVN  9479

3. )LOAD the workspace file with that interpreter and )DUMP it. This creates
an .apl text file
that should be loadable by the latest GNU APL version. Note that up to
recently there were
bugs in the interpreter preventing this.

/// Jürgen


On 03/30/2015 10:37 AM, Fausto Saporito wrote:

Hello,

I found a strange bug loading a workspace previously saved with apl 1.4

==
Assertion failed: !Avec::is_quad(sym_name[0])
in Function:  lookup_symbol
in file:  SymbolTable.cc:83

Call stack:


-- Stack trace at SymbolTable.cc:83



SI stack:


==
*** immediate_execution() caught other exception ***

The workspace is ok, I tried again to load it with 1.4 and it works.

Is this an expected incompatibility ?

regards,
Fausto




  


  

Re: [Bug-apl] gnu apl svn version on Mac OS X

[Juergen Sauermann]

  
  
Hi Fausto,
  
  thanks, fixed in SVN 582.
  
  /// Jürgen
  
  

On 03/31/2015 11:36 AM, Fausto Saporito
  wrote:


  Hi Jürgen,

that file is in /usr/include/sys on my system... weird... :)

I checked-out the rev 581 but in src/native/file_io.cc there's still
PATH_MAX and not APL_PATH_MAX, and without that include I still not
able to compile it .

regards,
Fausto

2015-03-30 17:21 GMT+02:00 Juergen Sauermann :

  
Hi Fausto,

I have renamed PATH_MAX to APL_PATH_MAX in SVN 580.

For my taste there are too many PATH_MAXes below /usr/include,
and the file you mention below does not exist on my machine.

/// Jürgen


On 03/30/2015 08:20 AM, Fausto Saporito wrote:

Hello,

I tried to compile the svn version under Mac OS X 10.10, but I got a
problem about PATH_MAX undefined.
I'm currently using gcc from macports, because with  native compiler
(clang) there're some issues about APL symbols in the source code.

By the way, I fixed the building (with gcc) adding to
src/native/file_io.cc the #include  where it's
properly defined that symbol.

Maybe you could add this to the next release.

thanks,
Fausto




  
  



  

Re: [Bug-apl] Macintosh compile errors and warnings SVN 582

[Peter Teeson]

Hi Jürgen:
Almost fixed… but some new errors & warnings…:-}

Peter

On 2015-03-31, at 10:10 AM, Juergen Sauermann  
wrote:
> Hi Peter,
> 
> thanks, should be fixed in SVN 582.
> 
> /// Jürgen

SVN 582
GNUAPL Group
Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:128:9: 
Variable length array of non-POD element type 'PrintBuffer'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:131:14: 
Variable length array of non-POD element type 'PrintBuffer'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:149:14: 
Variable length array of non-POD element type 'PrintBuffer'

Shell Script Invocation Warning Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1974:43:
 If statement has empty body
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1975:43:
 If statement has empty body

[Bug-apl] SVN 582 and CLANG ... error in PrintBuffer.cc

[Fausto Saporito]

Hello,

I trying to compile again the latest version with CLANG. The previous
errors has been fixed, but now I have this new:

PrintBuffer.cc:128:9: error: variable length array of non-POD element
type 'PrintBuffer'

DynArray(PrintBuffer, pcols, cols);

^

./APL_types.hh:465:46: note: expanded from macro 'DynArray'

# define DynArray(Type, Name, Size) Type Name[Size];

 ^

PrintBuffer.cc:131:14: error: variable length array of non-POD element
type 'PrintBuffer'

 DynArray(PrintBuffer, item_matrix, ec);

 ^

./APL_types.hh:465:46: note: expanded from macro 'DynArray'

# define DynArray(Type, Name, Size) Type Name[Size];

 ^

PrintBuffer.cc:149:14: error: variable length array of non-POD element
type 'PrintBuffer'

 DynArray(PrintBuffer, item_matrix, ec);

 ^

./APL_types.hh:465:46: note: expanded from macro 'DynArray'

# define DynArray(Type, Name, Size) Type Name[Size];

Please could you check it ?

thanks,
Fausto

Re: [Bug-apl] incompatible workspace 1.4 vs 1.5

[Fausto Saporito]

Thanks Jürgen.


2015-03-31 16:18 GMT+02:00 Juergen Sauermann :
> Hi Fausto,
>
> the bug should be fixed in SVN 582. It was an old ⎕-function (⎕PT) that was
> removed in the meantime.
>
> /// Jürgen
>
>
> On 03/31/2015 11:22 AM, Fausto Saporito wrote:
>
> Hello Jürgen,
>
> thanks for the clarification. Yes I did as you wrote. I created the
> saved workspace with APL 1.4, then I dumped with that version and
> read-back in APL 1.5 without any problem.
>
> Attached, by the way, there's the problematic workspace.
>
> regards,
> Fausto
>
>
> 2015-03-30 18:19 GMT+02:00 Juergen Sauermann
> :
>
> Hi Fausto,
>
> I would need the workspace in order to reproduce this.
>
> In GNU APL there are two commands (and two file formats) for saving
> workspaces: )SAVE and )DUMP.
> The )LOAD command understands both formats.
>
> The "classical" )SAVE command saves (serializes) the internal data
> structures of the interpreter into an .xml file.
> That normally works unless these data structures change. In other words,
> )LOAD is only expected to work with the
> same (SVN version of the) interpreter. Since the saved data structures do
> not change that often, sometimes )LOADing
> a workspace from a different interpreter version works. The text format of
> the .xml file makes it possible to fix
> minor incompatibilities.
>
> The newer )DUMP command uses a completely different approach. Instead of
> serializing the internal data structures
> of the interpreter, it writes APL code that, when executed, bring the
> interpreter into the same state that it had when the
> )DUMP command was issued. The file produced is also a text file hat can be
> edited with a normal text editor (read: vi)
> if needed if the )LOAD should fail. The only disadvantage of the )DUMP
> command is that the )SI stack is not saved
> (which is kind of impossible to reconstruct with APL code). An advantage is
> that it is fairly straightforward to read or
> write this format even with APL interpreters of other vendors. Therefore it
> is the preferred format of choice for archiving
> and documentation purposes.
>
> If you have )SAVEd an old workspace, then you can do this:
>
> 1. figure the SVN version used to )SAVE it. Unless  the SVN version is very
> old, it is written in the  tag
> of the .xml file like this:
>
> hour="16" minute="8" second="8" timezone="7200"
>saving_SVN="9479">
>
> 2. If you don't have a working GNU APL with that SVN revision then check it
> out and build it.
> Look at file buildtag.hh which should have the following line:
>
> #define ARCHIVE_SVN  9479
>
> 3. )LOAD the workspace file with that interpreter and )DUMP it. This creates
> an .apl text file
> that should be loadable by the latest GNU APL version. Note that up to
> recently there were
> bugs in the interpreter preventing this.
>
> /// Jürgen
>
>
> On 03/30/2015 10:37 AM, Fausto Saporito wrote:
>
> Hello,
>
> I found a strange bug loading a workspace previously saved with apl 1.4
>
> ==
> Assertion failed: !Avec::is_quad(sym_name[0])
> in Function:  lookup_symbol
> in file:  SymbolTable.cc:83
>
> Call stack:
>
> 
> -- Stack trace at SymbolTable.cc:83
> 
> 
>
> SI stack:
>
>
> ==
> *** immediate_execution() caught other exception ***
>
> The workspace is ok, I tried again to load it with 1.4 and it works.
>
> Is this an expected incompatibility ?
>
> regards,
> Fausto
>
>
>
>

[Bug-apl] planning of future features

[Fausto Saporito]

Hello,

I'm trying to convert an old workspace (designed I suppose for Dyalog
APL) related to multi precision arithmetic operation.
It uses these non standard feature:

1) quad-D
2) quad-FMT
3) quad-SIGNAL

The first one is quite trivial, the other two are more complex.

Is there any way to replicate them (2 and 3) with GNU APL ?

thanks,
Fausto

Re: [Bug-apl] Macintosh compile errors and warnings SVN 582

[Juergen Sauermann]

  
  
Hi Peter and Fausto,
  
  thanks. I have tried to catch this in ./configure.
  SVN 583.
  
  /// Jürgen
  
  

On 03/31/2015 04:27 PM, Peter Teeson
  wrote:


  
  Hi Jürgen:
  Almost fixed… but some new errors & warnings…:-}
  
  
  Peter
  

  On 2015-03-31, at 10:10 AM, Juergen Sauermann 
wrote:
  

 Hi Peter,

thanks, should be fixed in SVN 582.

/// Jürgen
  
  
  
  SVN 582
  GNUAPL Group
  Shell Script Invocation Error Group
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:128:9:
Variable length array of non-POD element type 'PrintBuffer'
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:131:14:
Variable length array of non-POD element type 'PrintBuffer'
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/PrintBuffer.cc:149:14:
Variable length array of non-POD element type 'PrintBuffer'
  
  
  Shell Script Invocation Warning Group
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1974:43:
If statement has empty body
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/QuadFunction.cc:1975:43:
If statement has empty body

  


  

Re: [Bug-apl] Macintosh compile errors and warnings SVN 583

[Peter Teeson]

GNUAPL Group
Shell Script Invocation Error Group
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:45:5:
 No matching function for call to 'strcpy'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:47:10:
 No matching function for call to 'mkstemp'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:52:10:
 No viable overloaded '='

On 2015-03-31, at 11:22 AM, Juergen Sauermann  
wrote:
> Hi Peter and Fausto,
> 
> thanks. I have tried to catch this in ./configure. SVN 583.
> 
> /// Jürgen

Re: [Bug-apl] planning of future features

[Juergen Sauermann]

  
  
Hi Fausto,
  
  Dyalog ⎕SIGNAL seems to be ⎕ES in IBM APL2 and in
  GNU APL.
  
  Dyalog ⎕FMT is a little too FORTRANish for my taste.
  However
  dyadic ⍕ ("Format by example") in IBM APL2 and in GNU APL
  provide similar functionality (Dyalog also seems to have a dyadic
  ⍕, but
  it looks less powerful).
  
  Also, the FILE_IO native function in GNU APL gives you all
  the formatting
  capabilities of printf() and friends in C/C++. See 'info
  apl'.
  
  /// Jürgen
  
  

On 03/31/2015 04:34 PM, Fausto Saporito
  wrote:


  Hello,

I'm trying to convert an old workspace (designed I suppose for Dyalog
APL) related to multi precision arithmetic operation.
It uses these non standard feature:

1) quad-D
2) quad-FMT
3) quad-SIGNAL

The first one is quite trivial, the other two are more complex.

Is there any way to replicate them (2 and 3) with GNU APL ?

thanks,
Fausto





  

Re: [Bug-apl] Macintosh compile errors and warnings SVN 583

[Juergen Sauermann]

  
  
Hi Peter, Elias,
  
  I have created something that MAY compile. However:
  
  man mkstemp says:
      mkstemps(): unstandardized, but appears on several other
  systems.
  
  man tmpnam (the one I used instead) says:
     Never use this function.  Use mkstemp(3) or tmpfile(3)
  instead.
  
  Peter: Chances are that on your box mkstemp
is declared in /usr/include/unistd.h instead of
  /usr/include/stdlib.h.
If that is so then please let me know and I will revert the code
and #include it.

  Since this us Elias' code he should have the final word. tmpfile()
  seems to be more  portable, but
  it returns a FILE * instead of an fd and deletes the file
  on exit().
  
  /// Jürgen
  
  

On 03/31/2015 05:47 PM, Peter Teeson
  wrote:


  
  GNUAPL Group
  Shell Script Invocation Error Group
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:45:5:
No matching function for call to 'strcpy'
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:47:10:
No matching function for call to 'mkstemp'
  /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/TempFileWrapper.cc:52:10:
No viable overloaded '='
  
  
  
On 2015-03-31, at 11:22 AM, Juergen Sauermann 
  wrote:

  
   Hi Peter and Fausto,
  
  thanks. I have tried to catch this in ./configure.
  SVN 583.
  
  /// Jürgen


  


  

[Bug-apl] SVN 585 clean build

[David Lamkins]

I did a clean checkout of SVN 585 followed by configure and make.

The file src/buildtag.hh is neither present nor created, which causes the
build to fail.

-- 
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] Macintosh compile errors and warnings SVN 583

[Peter Teeson]

Hi Jürgen:

On 2015-03-31, at 12:53 PM, Juergen Sauermann  
wrote:

> Peter: Chances are that on your box mkstemp is declared in 
> /usr/include/unistd.h instead of
> /usr/include/stdlib.h. If that is so then please let me know and I will 
> revert the code and #include it.

You are correct…..
The following is in /usr/include/unistd.h starting at line701... on my box 
which is OS X 10.8.5
I also checked OS X 10.9.5 and it's also there in the same file at the same 
location (+- a few lines).
….
int  mkpath_np(const char *path, mode_t omode) 
__OSX_AVAILABLE_STARTING(__MAC_10_8, __IPHONE_5_0); /* returns errno */
int  mkstemp(char *);
int  mkstemps(char *, int);
char*mktemp(char *);

HTH

respect….

Peter

[Bug-apl] The ' 2 ⎕TF ' bug

[Christian Robert]

  var←'kelvin' (,'v') 'some text'
  D var
┌3───┐
│┌6─┐ ┌→┐ ┌9┐│
││kelvin│ │v│ │some text││
│└──┘ └─┘ └─┘│
└∊───┘
  2 ⎕tf 'var'
var←'kelvin' 'v' 'some text'
  ⍎2 ⎕tf 'var'
  D var
┌3─┐
│┌6─┐ v ┌9┐│
││kelvin│   │some text││
│└──┘   └─┘│
└∊─┘
  ⍝ Length 1 vectors ( here (,'v') ) have been converted to scalar 'v'

[Bug-apl] The ' 2 ⎕TF ' bug, more info

[Christian Robert]

  var←'kelvin' (,'v') 'some text'
  D var
┌3───┐
│┌6─┐ ┌→┐ ┌9┐│
││kelvin│ │v│ │some text││
│└──┘ └─┘ └─┘│
└∊───┘
  2 ⎕tf 'var'
var←'kelvin' 'v' 'some text'
  ⍎2 ⎕tf 'var'
  D var
┌3─┐
│┌6─┐ v ┌9┐│
││kelvin│   │some text││
│└──┘   └─┘│
└∊─┘
  ⍝ Length 1 vectors ( here (,'v') ) have been converted to scalar 'v'


  var←'kelvin' (,'v') (0⍴'') (⍳0) 'some text'
  D var
┌5───┐
│┌6─┐ ┌→┐ ┌⊖┐ ┌⊖┐ ┌9┐│
││kelvin│ │v│ │ │ │0│ │some text││
│└──┘ └─┘ └─┘ └─┘ └─┘│
└∊───┘
  ⍎2 ⎕tf 'var'
  D var
┌5─┐
│┌6─┐ v ┌⊖┐ ┌⊖┐ ┌9┐│
││kelvin│   │ │ │0│ │some text││
│└──┘   └─┘ └─┘ └─┘│
└∊─┘



  ⍝ in fact only Length 1 vectors are affected, length 0 are OK.

ps; copy&paste had problem here because of the horizontal pixel width of '⊖' in 
windows


Xtian.

Re: [Bug-apl] Macintosh compile errors and warnings SVN 583

[Elias Mårtenson]

I would much rather completely eliminate the use of the temporary file
here. The reason it's used is so that I can use
InputFile::files_todo.insert() on it.

Is there an alternative method by which I can queue a bunch of input lines
to be read by the interpreter?

Regards,
Elias

On 1 April 2015 at 05:39, Peter Teeson  wrote:

> Hi Jürgen:
>
> On 2015-03-31, at 12:53 PM, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
> Peter: Chances are that on your box *mkstemp* is declared in
> */usr/include/unistd.h* instead of
> */usr/include/stdlib.h*. If that is so then please let me know and I will
> revert the code and *#include* it.
>
>
> You are correct…..
> The following is in /usr/include/unistd.h starting at line701... on my box
> which is OS X 10.8.5
> I also checked OS X 10.9.5 and it's also there in the same file at the
> same location (+- a few lines).
> ….
> int mkpath_np(const char *path, mode_t omode)
> __OSX_AVAILABLE_STARTING(__MAC_10_8, __IPHONE_5_0); /* returns errno */
> int mkstemp(char *);
> int mkstemps(char *, int);
> char *mktemp(char *);
>
> HTH
>
> respect….
>
> Peter
>