Re: [Bug-apl] Assertion failed

[Elias Mårtenson]

I thought Jürgen fixed that? The cuase was apparently my misunderstanding
of how the GNU APL Simple_string works.

Regards,
Elias

On 29 August 2017 at 03:45, Ala'a Mohammad  wrote:

> Hi,
>
> Trying to reduce the steps above to 'define, save, define' gives the
> same thing above. This only happens when the defined function is saved
> without a body (saved only with the header).
>
> Network listener started. Connection information: mode:tcp addr:35039
>   ∇x
>   ∇x
>
> 
> ==
> Assertion failed: items
> in Function:  at
> in file:  ../Simple_string.hh:277
>
> Call stack:
>
> 
> -- Stack trace at ../Simple_string.hh:277
> 
> 0x7F2D7FEEC184
> 0x7F2D7AC6BBDE  connection_loop(void*)
> 0x7F2D7AC6F0FE   NetworkConnection::run()
> 0x7F2D7AC6E0CBNetworkConnection::process_command(std::string const&)
> 0x7F2D7AC67CA7 FnCommand::run_command(NetworkConnection&,
> std::vector > const&)
> 0x45EA0F  do_Assert(char const*, char const*, char const*, int)
> 
>
> SI stack:
>
>
> 
> ==
> terminate called after throwing an instance of 'ErrorCode'
>
> Process apl aborted
>
>
> On Mon, Aug 28, 2017 at 10:10 PM, Ala'a Mohammad 
> wrote:
> > Hi,
> >
> > I do not know if this is the same cause, but the assertion seems to be
> the same
> >
> > in a new session do the following
> > - write an incorrect name like 'x.y'
> > - edit a function like 'z'
> > - save the function
> > - edit the z function again, and you get the failed assertion
> >
> > I'm running the latest APL version from svn:
> > : apl --version
> > BUILDTAG:
> > -
> > Project:GNU APL
> > Version / SVN:  1.7 / 1003M
> > Build Date: 2017-08-28 18:02:08 UTC
> > Build OS:   Linux 3.13.0-37-generic x86_64
> > config.status:  'RATIONAL_NUMBERS_WANTED=yes'
> > Archive SVN:989
> >
> > Here is a session sample:
> > --
> >
> >   x.y
> > VALUE ERROR
> >   x.y
> > ^
> >   ∇z
> >   ∇z
> >
> > 
> ==
> > Assertion failed: items
> > in Function:  at
> > in file:  ../Simple_string.hh:277
> >
> > Call stack:
> >
> > 
> > -- Stack trace at ../Simple_string.hh:277
> > 
> > 0x7F2ECE271184
> > 0x7F2EC8FF0BDE  connection_loop(void*)
> > 0x7F2EC8FF40FE   NetworkConnection::run()
> > 0x7F2EC8FF30CBNetworkConnection::process_command(std::string const&)
> > 0x7F2EC8FECCA7 FnCommand::run_command(NetworkConnection&,
> > std::vector > const&)
> > 0x45EA0F  do_Assert(char const*, char const*, char const*, int)
> > 
> >
> > SI stack:
> >
> > Depth:  0
> > Exec:   0xbaf770
> > Safe exec:  0
> > Pmode:  ◊  x.y
> > PC: 0 (5) 'y
> > Stat:   x.y
> > err_code:   0x30001
> > thrown at:  Symbol.cc:683
> > e_msg_1:'VALUE ERROR'
> > e_msg_2:'  x.y'
> > e_msg_3:'^'
> >
> >
> > 
> ==
> > terminate called after throwing an instance of 'ErrorCode'
> >
> > Process apl aborted
> >
> >
> > Hope It Helps
> >
> > Regards,
> >
> > Ala'a
> >
> >
> >
> >
> >
> > On Tue, Aug 8, 2017 at 2:18 PM, Elias Mårtenson 
> wrote:
> >> If that's the case, then you are indeed right. It's possible that the
> >> std::string constructor will work, but that would be more out of luck
> than
> >> anything else.
> >>
> >> Regards,
> >> Elias
> >>
> >> On 8 August 2017 at 18:11, Juergen Sauermann <
> juergen.sauerm...@t-online.de>
> >> wrote:
> >>>
> >>> Hi Elias,
> >>>
> >>> correct, except that an UCS8_string is not a string, despite of its
> name.
> >>> UCS8_strings have no terminating 0 byte; the 0-byte is only appended if
> >>> the UCS8_string is converted to a C string with function c_str().
> >>>
> >>> /// Jürgen
> >>>
> >>>
> >>> On 08/08/2017 09:28 AM, Elias Mårtenson wrote:
> >>>
> >>> Sorry for not replying earlier, I forgot about this message.
> >>>
> >>> ucs[0] should be OK for an empty string, as that will still refer to
> the
> >>> terminating NUL byte at the end of the string. Note that an empty
> string is
> >>> differetn from a NULL pointer (the former is a valid string, and the
> other
> >>> is not).
> >>>
> >>> Regards,
> >>> Elias
> >>>
> >>> On 1 August 2017 at 19:04, Juergen Sauermann
> >>>  wrote:
> 
>  Hi Elias,
> 
>  I don't know what Ala'a did. However, looking at:
> 
>  /// return a UTF8 encoded std:string
>  inline std::string to_string(const UCS_string & ucs)
>  {
>  const UTF8_string utf(ucs);
>  return string((const char *)

Re: [Bug-apl] Access to rational number numerator and denominator

[Juergen Sauermann]

  
  
Hi Fred,
  
  Rational. and non-rational numbers use the same Cell type
  (FloatCell).

Non-Rational numbers have a denominator = 0 and store their
value in value.fval.u1.flt (which is a double in
union u1)
Rational numbers have a denominator >= 1 and store their
value in value.fval.u1.num (which is an int64_t in
union u1)

So basically a rational number uses the same space that a complex
number would use for its imaginary part (to avoid an
increase of the Cell size by introducing rational numbers).

26 ⎕CR has nothing to do with all of this.
27 ⎕CR returns the primary value of a Cell (which is always
an integer that was possibly cast from a different type like
APL_Char or APL_Float to APL_Integer = int64_t).
28 ⎕CR is 0 or the secondary value of a Cell (imaginary part
for Complex Cells, Denominator for Rational FloatCells, ...),
and is also always an APL_Integer.

  28 ⎕CR ÷ 2
  2

So the denominator is NOT represented by a double but by an
int64_t.

The idea behind 27/28 ⎕CR is to get the underlying machine
representation of the value(s) store in a Cell (similar to dyadic ⎕CR
in good old APL68000) which by chance is the denominator of a
rational float value.

Hope that explains it,

/// Jürgen


On 08/30/2017 07:59 AM, Frederick Pitts
  wrote:


  
  Hello Jürgen,
  
  
   After reading your email and the apl.html documentation on
⎕CR and so, I've have two questions:
  
  
   1) How does one know B is a rational number? The apl.html
documentation for 26 ⎕CR B does not show
  that there is a cell type for rationals and I could not
locate one in the source code. Admittedly my examination was
cursory. 
   2) Why is a real number being used to represent the
numerator of a rational number? I thought ~63-bit
  integers would consistently be used to represent the parts of
a rational. 26 ⎕CR ÷ 2 yields 32 indicating that 1 is being
represented by a real rather than an integer. That is puzzling
to me. It almost seems irrational, no pun intended.
  
  
  Regards.
  
  
  
  
  On Tue, 2017-08-29 at 12:51 +0200, Juergen Sauermann wrote:
   Hi Fred,
  
  the existing mechanism is 27 ⎕CR B to get the
  numerator of B and 28 ⎕CR to get the denominator >
0
  of a quotient or 0 if the number is not a quotient (and then 27
  ⎕CR is the double B cast to uint64_t.
  
  Unfortunately there was a bug 28 ⎕CR returning always
  0. Fixed in SVN 1004.

Best Regards,
/// Jürgen


On 08/28/2017 11:24 PM, Frederick
  Pitts wrote:


  Hello,

	Is there an existing mechanism for accessing rational number
numerator and denominator parts analogous to that for accessing complex
number real and imaginary parts?  If yes, please let me know how.  If
no, can a mechanism be implemented?

Respectfully,

Fred





  


  

Re: [Bug-apl] Assertion failed

[Juergen Sauermann]

  
  
Hi Elias,
  
  not really. I am only fetching your emacs code from time to time.
  I can't test it because I am on vi.
  
  Best Regards,
  Jürgen
  

On 08/30/2017 10:25 AM, Elias Mårtenson
  wrote:


  I thought Jürgen fixed that? The cuase was
apparently my misunderstanding of how the GNU APL Simple_string
works.


Regards,
Elias
  
  
On 29 August 2017 at 03:45, Ala'a
  Mohammad 
  wrote:
  Hi,

Trying to reduce the steps above to 'define, save, define'
gives the
same thing above. This only happens when the defined
function is saved
without a body (saved only with the header).

Network listener started. Connection information: mode:tcp
addr:35039
      ∇x
      ∇x

  ==
  Assertion failed: items
  in Function:      at
  in file:          ../Simple_string.hh:277
  
  Call stack:
  
  
  -- Stack trace at ../Simple_string.hh:277
  
0x7F2D7FEEC184
0x7F2D7AC6BBDE  connection_loop(void*)
0x7F2D7AC6F0FE   NetworkConnection::run()
0x7F2D7AC6E0CB    NetworkConnection::process_command(std::string
const&)
0x7F2D7AC67CA7     FnCommand::run_command(NetworkConnection&,
std::vector > const&)
  0x45EA0F      do_Assert(char const*, char const*, char
  const*, int)
  
  
  SI stack:
  
  
==
  terminate called after throwing an instance of 'ErrorCode'
  
  Process apl aborted
  
  


  On Mon, Aug 28, 2017 at 10:10 PM, Ala'a
Mohammad 
wrote:
> Hi,
>
> I do not know if this is the same cause, but the
assertion seems to be the same
>
> in a new session do the following
> - write an incorrect name like 'x.y'
> - edit a function like 'z'
> - save the function
> - edit the z function again, and you get the failed
assertion
>
> I'm running the latest APL version from svn:
> : apl --version
> BUILDTAG:
> -
>     Project:        GNU APL
>     Version / SVN:  1.7 / 1003M
>     Build Date:     2017-08-28 18:02:08 UTC
>     Build OS:       Linux 3.13.0-37-generic x86_64
>     config.status:  'RATIONAL_NUMBERS_WANTED=yes'
>     Archive SVN:    989
>
> Here is a session sample:
> --
>
>       x.y
> VALUE ERROR
>       x.y
>         ^
>       ∇z
>       ∇z
>
> ==
> Assertion failed: items
> in Function:      at
> in file:          ../Simple_string.hh:277
>
> Call stack:
>
> 
> -- Stack trace at ../Simple_string.hh:277
> 
> 0x7F2ECE271184
> 0x7F2EC8FF0BDE  connection_loop(void*)
> 0x7F2EC8FF40FE   NetworkConnection::run()
> 0x7F2EC8FF30CB    NetworkConnection::process_command(std::string
const&)
> 0x7F2EC8FECCA7     FnCommand::run_command(NetworkConnection&,
> std::vector > const&)
> 0x45EA0F      do_Assert(char const*, char const*,
char const*, int)
> 
>
> SI stack:
>
> Depth:      0
> Exec:       0xbaf770
> Safe exec:  0
> Pmode:      ◊  x.y
> PC:         0 (5) 'y
> Stat:       x.y
> err_code:   0x3

[Bug-apl] ]DOXY command

[Juergen Sauermann]

  
  
Hi,
  
  I have finished the first version of a new command named ]DOXYin
SVN 1005.
  
  The ]DOXY command dumps the current workspace into
  several, hyper-linked
  .html files for the purpose of documenting the workspace.
  Similar to Doxygen,
  although less beautiful.
  
  The ]DOXY command works only if dot (aka Graphviz)
  is installed. GNU APL
  compiles without it, but the creation of call graphs and caller
  graphs fails when
  dot is missing (dot does the painting of the
  graphs).
  
  Initially I was trying to extend Doxygen itself to understand APL,
  but failed big
  style achieving that.
  
  The ]DOXY command should also be able to document the
  workspaces of other
  vendors as long as their APL can export workspaces as .ATF
  files (most can do that,
  and for the others creating .ATF files can also easily be
  done in APL itself).
  
  Enjoy,
  /// Jürgen