Re: [Bug-apl] Assertion failed

2017-08-30 Thread 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
> 

Re: [Bug-apl] Assertion failed

2017-08-30 Thread 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
> 

Re: [Bug-apl] Assertion failed

2017-08-28 Thread Ala'a Mohammad
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 
>> 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 *)[0], utf.size());
 }

 I am not sure what happens if string ucs is empty (in that case ucs[0]
 does not
 exist and may be makes [0] also 0. The std::string constructor then
 looks
 for the terminating 0 character in a 0-pointer. Using
 UTF8:string::c_str() might
 be better.

 Also converting a UCS or UTF8 string to std::string just for outputting
 it 

Re: [Bug-apl] Assertion failed

2017-08-28 Thread Ala'a Mohammad
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 
> 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 *)[0], utf.size());
>>> }
>>>
>>> I am not sure what happens if string ucs is empty (in that case ucs[0]
>>> does not
>>> exist and may be makes [0] also 0. The std::string constructor then
>>> looks
>>> for the terminating 0 character in a 0-pointer. Using
>>> UTF8:string::c_str() might
>>> be better.
>>>
>>> Also converting a UCS or UTF8 string to std::string just for outputting
>>> it with << may be
>>> an overkill, since ostream << often (read: after #include
>>> "PrintOperator.hh") understands
>>> UCF and UCS strings directly.
>>>
>>> /// Jürgen
>>>
>>>
>>> On 07/31/2017 02:31 AM, Elias Mårtenson wrote:
>>>
>>> Can you tell me exactly what you are doing in order to reproduce the
>>> problem?
>>>
>>> Regards,
>>> Elias
>>>
>>>
>>
>>
>



Re: [Bug-apl] Assertion failed

2017-08-08 Thread Elias Mårtenson
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 
wrote:

> Hi Elias,
>
> correct, except that an *UCS8_string* is not a string, despite of its
> name.
> *UCS8_string*s 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 <
> juergen.sauerm...@t-online.de> 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 *)[0], utf.size());*
>> *}*
>>
>> I am not sure what happens if string *ucs* is empty (in that case *ucs[0]
>> *does not
>> exist and may be makes *&**ucs[0]* also 0. The std::string constructor
>> then looks
>> for the terminating 0 character in a 0-pointer. Using
>> *UTF8:string::c_str**()* might
>> be better.
>>
>> Also converting a UCS or UTF8 string to *std::string* just for
>> outputting it with << may be
>> an overkill, since *ostream << *often (read: after *#include
>> "PrintOperator.hh*") understands
>> UCF and UCS strings directly.
>>
>> /// Jürgen
>>
>>
>> On 07/31/2017 02:31 AM, Elias Mårtenson wrote:
>>
>> Can you tell me exactly what you are doing in order to reproduce the
>> problem?
>>
>> Regards,
>> Elias
>>
>>
>>
>
>


Re: [Bug-apl] Assertion failed

2017-08-08 Thread Juergen Sauermann

  
  
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 *)[0],
utf.size());
  }

I am not sure what happens if string ucs is
empty (in that case ucs[0] does not 
exist and may be makes &ucs[0] also
  0. The std::string constructor then looks
  for the terminating 0 character in a 0-pointer. Using
  UTF8:string::c_str() might
be better.

Also converting a UCS or UTF8 string to std::string
just for outputting it with << may be
an overkill, since ostream << often
(read: after #include "PrintOperator.hh")
understands
UCF and UCS strings directly.

/// Jürgen

  
On
  07/31/2017 02:31 AM, Elias Mårtenson wrote:


  Can you tell me exactly what you are
doing in order to reproduce the problem? 


Regards, 
Elias 
  
  
  


  
  


  


  




Re: [Bug-apl] Assertion failed

2017-08-08 Thread Elias Mårtenson
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 *)[0], utf.size());*
> *}*
>
> I am not sure what happens if string *ucs* is empty (in that case *ucs[0]
> *does not
> exist and may be makes *&**ucs[0]* also 0. The std::string constructor
> then looks
> for the terminating 0 character in a 0-pointer. Using *UTF8:string::c_str*
> *()* might
> be better.
>
> Also converting a UCS or UTF8 string to *std::string* just for outputting
> it with << may be
> an overkill, since *ostream << *often (read: after *#include
> "PrintOperator.hh*") understands
> UCF and UCS strings directly.
>
> /// Jürgen
>
>
> On 07/31/2017 02:31 AM, Elias Mårtenson wrote:
>
> Can you tell me exactly what you are doing in order to reproduce the
> problem?
>
> Regards,
> Elias
>
>
>


Re: [Bug-apl] Assertion failed

2017-08-01 Thread Juergen Sauermann

  
  
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 *)[0], utf.size());
}
  
  I am not sure what happens if string ucs is empty (in that
  case ucs[0] does not 
  exist and may be makes &ucs[0]
also 0. The std::string constructor then looks
for the terminating 0 character in a 0-pointer. Using UTF8:string::c_str()
  might
  be better.
  
  Also converting a UCS or UTF8 string to std::string just
  for outputting it with << may be
  an overkill, since ostream << often (read: after #include
"PrintOperator.hh") understands
  UCF and UCS strings directly.
  
  /// Jürgen
  

On 07/31/2017 02:31 AM, Elias Mårtenson
  wrote:


  Can you tell me exactly what you are doing in
order to reproduce the problem? 


Regards, 
Elias 
  
  
  


  




Re: [Bug-apl] Assertion failed

2017-07-31 Thread Ala'a Mohammad
Hi,

I couldn't reproduce this reliably. This happened a couple of times
during the last week.

Is there any flag (runtime or compile time, emacs or gnu-apl) which
will provide more trace details?

Regards,

Ala'a

On Mon, Jul 31, 2017 at 4:31 AM, Elias Mårtenson  wrote:
> Can you tell me exactly what you are doing in order to reproduce the
> problem?
>
> Regards,
> Elias
>
> On 31 Jul 2017 04:51, "Juergen Sauermann" 
> wrote:
>>
>> Hi Ala'a,
>>
>> maybe this is something for Elias to look into. Seems like some
>> Simple_string is corrupted.
>>
>> /// Jürgen
>>
>>
>> On 07/30/2017 09:40 PM, Ala'a Mohammad wrote:
>>
>> Hi,
>>
>> I'm trying to edit a function but got the following trace
>>
>>
>>
>> ==
>> Assertion failed: items
>> in Function:  at
>> in file:  ../Simple_string.hh:276
>>
>> Call stack:
>>
>> 
>> -- Stack trace at ../Simple_string.hh:276
>> 
>> 0x7facab6e1184
>> 0x7faca6464bde  connection_loop(void*)
>> 0x7faca64680fe   NetworkConnection::run()
>> 0x7faca64670cbNetworkConnection::process_command(std::string const&)
>> 0x7faca6460ca7 FnCommand::run_command(NetworkConnection&,
>> std::vector const&)
>> 0x45e63f  do_Assert(char const*, char const*, char const*, int)
>> 
>>
>> SI stack:
>>
>>
>>
>> ==
>> terminate called after throwing an instance of 'ErrorCode'
>>
>> Process apl aborted
>>
>> my setup is GNU-APL through emacs
>>
>> : apl --version
>> BUILDTAG:
>> -
>> Project:GNU APL
>> Version / SVN:  1.7 / 983M
>> Build Date: 2017-07-23 17:01:17 UTC
>> Build OS:   Linux 3.13.0-37-generic x86_64
>> config.status:  unknown configure options
>>Archive SVN: 983
>>
>> Is this enough to be reported, and if not, then Is there any other way
>> to get a more informative debugging/tracing and helpful information?
>>
>> Best wishes,
>>
>> Ala'a
>>
>>
>>
>



Re: [Bug-apl] Assertion failed

2017-07-30 Thread Elias Mårtenson
Can you tell me exactly what you are doing in order to reproduce the
problem?

Regards,
Elias

On 31 Jul 2017 04:51, "Juergen Sauermann" 
wrote:

> Hi Ala'a,
>
> maybe this is something for Elias to look into. Seems like some
> Simple_string is corrupted.
>
> /// Jürgen
>
>
> On 07/30/2017 09:40 PM, Ala'a Mohammad wrote:
>
> Hi,
>
> I'm trying to edit a function but got the following trace
>
>
> ==
> Assertion failed: items
> in Function:  at
> in file:  ../Simple_string.hh:276
>
> Call stack:
>
> 
> -- Stack trace at ../Simple_string.hh:276
> 
> 0x7facab6e1184
> 0x7faca6464bde  connection_loop(void*)
> 0x7faca64680fe   NetworkConnection::run()
> 0x7faca64670cbNetworkConnection::process_command(std::string const&)
> 0x7faca6460ca7 FnCommand::run_command(NetworkConnection&,
> std::vector const&)
> 0x45e63f  do_Assert(char const*, char const*, char const*, int)
> 
>
> SI stack:
>
>
> ==
> terminate called after throwing an instance of 'ErrorCode'
>
> Process apl aborted
>
> my setup is GNU-APL through emacs
>
> : apl --version
> BUILDTAG:
> -
> Project:GNU APL
> Version / SVN:  1.7 / 983M
> Build Date: 2017-07-23 17:01:17 UTC
> Build OS:   Linux 3.13.0-37-generic x86_64
> config.status:  unknown configure options
>Archive SVN: 983
>
> Is this enough to be reported, and if not, then Is there any other way
> to get a more informative debugging/tracing and helpful information?
>
> Best wishes,
>
> Ala'a
>
>
>
>
>


Re: [Bug-apl] Assertion failed in 'equal'

2016-10-18 Thread Ala'a Mohammad
On Tue, Oct 18, 2016 at 3:42 PM, Jay Foad  wrote:
>   ⍋⍋'GNUAPL'

Great! Thanks.



Re: [Bug-apl] Assertion failed in 'equal'

2016-10-18 Thread Jay Foad
This is called "ranking" and is very simple in APL:

  ⍋⍋'GNUAPL'
2 4 6 1 5 3

The permutations 4 1 6 2 5 3 (i.e. ⍋'GNUAPL') and 2 4 6 1 5 3 are inverses
of each other, and ⍋ will invert a permutation.

Jay.

On 17 October 2016 at 15:41, Ala'a Mohammad  wrote:

> Hi Juergen,
>
> Thanks for the fix.
>
> Apology if I could not explain what I'm trying to do. It is: given a
> string, replace every char with its alphabetic index (starting from
> 1). The following simpler solution achieves it.
>
>   ⊢string ←'GNUAPL'
> GNUAPL
>   ⊢string[⍋string] ← ⍳⍴string
> 1 2 3 4 5 6
>   string
> 2 4 6 1 5 3
>
> but now 'string' is overwritten. Then i tried to generalize it, thus
>
>   {str⊣str[⍋str]←⍳⍴str←⍵} 'GNUAPL'
> 2 4 6 1 5 3
>
> but now I need '⊣', otherwise the returned result will be the ordered iota.
>
> I tried to understand why it returns 1 2 3 4 5 6 (without ⊣), but
> failed! Any hints/references?
>
> Thanks again for the fix.
>
> Ala'a
>
>
> On Mon, Oct 17, 2016 at 2:34 PM, Juergen Sauermann
>  wrote:
> > Hi Ala'a
> >
> > thanks, fixed in SVN 798.You will now get a DOMAIN ERROR instead of
> > a failed assertion.
> >
> > The DOMAIN ERROR is being reported because you try to compare objects
> that
> > would be called left values in C/C++, so your code is also wrong. I would
> > also
> > be careful with using A⍳B if A or B becomes large. For regular structures
> > like
> >
> >   abc←'abcdefghijklmnopqrstuvwxyz'
> >   abc⍳XXX
> >
> > you might consider using something like
> >
> >   0 ⌈ 26 ⌊ ¯97 + ⎕UCS XXX
> >
> > which will decrease your execution time from O((⍴A)×(⍴B)) down to O(⍴B).
> >
> > /// Jürgen
> >
> >
> >
> > On 10/16/2016 04:51 PM, Ala'a Mohammad wrote:
> >
> > I was trying to assign order to a word letters for example 'zach' is
> > 312, I got it finally, for example for 'maine'
> >   abc←'abcdefghijklmnopqrstuvwxyz'
> >  1+(⌽⍳5)[(⍋abc⍳'maine')]
> > 4 1 3 5 2
> >
> > But I got the following failing assertion and wanted to check if
> > something related to my code or the interpreter.
> > I'm using
> > GNU APL
> > : apl -v
> > BUILDTAG:
> > -
> > Project:GNU APL
> > Version / SVN:  1.6 / 796
> > Build Date: 2016-09-26 18:43:22 UTC
> > Build OS:   Linux 3.13.0-37-generic x86_64
> > config.status:  unknown configure options
> >Archive SVN: 787
> >
> > Operating system is Linuxmint 17.1 64bit (Linux rock 3.13.0-37-generic
> > #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64
> > GNU/Linux)
> >
> > Regards,
> >
> > Ala'a
> >
> > 
> ---
> >
> >   abc←'abcdefghijklmnopqrstuvwxyz'
> >   abc⍳'maine'
> > 12 0 8 13 4
> >   ⍋abc⍳'maine'
> > 1 4 2 0 3
> >   (⍋abc⍳'maine')←⍳5
> > equal() called on object of classLvalCell
> >
> > 
> ==
> > Assertion failed: 0
> > in Function:  equal
> > in file:  Cell.cc:117
> >
> > Call stack:
> >
> > 
> > -- Stack trace at Cell.cc:117
> > 
> > 0x7fb94a6e9f45 __libc_start_main
> > 0x446105  main
> > 0x56b84d   Workspace::immediate_execution(bool)
> > 0x487e89Command::process_line()
> > 0x487f2d Command::do_APL_expression(UCS_string&)
> > 0x4923c8  Executable::execute_body() const
> > 0x5201b0   StateIndicator::run()
> > 0x4c57e9Prefix::reduce_statements()
> > 0x4c4d59 Prefix::reduce_MISC_F_B_()
> > 0x460d8f  Bif_F12_SORT_ASC::eval_B(Value_P)
> > 0x45fdaf   Bif_F12_SORT::sort(Value_P, Sort_order)
> > 0x47746aCell::greater_vec(Cell const*, Cell const*, void
> const*)
> > 0x476b78
> > 0x4552df  do_Assert(char const*, char const*, char const*,
> int)
> > 
> >
> > SI stack:
> >
> > Depth:  79
> > Exec:   0x1796ad0
> > Safe exec:  0
> > Pmode:◊  (⍋abc⍳'maine')←⍳5
> > PC:   9 ENDL
> > Stat: (⍋abc⍳'maine')←⍳5
> > err_code: 0x0
> > thrown:   at StateIndicator.cc:39
> > e_msg_1:  'No Error'
> > e_msg_2:  ''
> > e_msg_3:  ''
> >
> > Depth:  78
> > Exec:   0x17b2af0
> > Safe exec:  0
> > Pmode:◊  abc[s]
> > PC:   4 ENDL
> > Stat: abc[s]
> > err_code: 0x50005
> > thrown:   at Value.cc:1050
> > e_msg_1:  'INDEX ERROR+'
> > e_msg_2:  '  abc[s]'
> > e_msg_3:  '  ^  ^'
> >
> > Depth:  77
> > Exec:   0x17b2820
> > Safe exec:  0
> > Pmode:◊  s⌷abc
> > PC:   3 ENDL
> > Stat: s⌷abc
> > err_code: 0x50002
> > thrown:   at PrimitiveFunction.cc:2308
> > e_msg_1:  'RANK ERROR'
> > e_msg_2:  '  s⌷abc'
> > e_msg_3:  '  ^ ^'
> >
> > Depth:  76
> > Exec:   0x17b2e30
> > Safe exec:  0
> > Pmode:◊  abs⍳s
> > PC:   2 'abs
> > Stat: abs⍳s
> > err_code: 0x30001
> > thrown:   at Symbol.cc:662
> > 

Re: [Bug-apl] Assertion failed in 'equal'

2016-10-17 Thread Ala'a Mohammad
Hi Juergen,

Thanks for the fix.

Apology if I could not explain what I'm trying to do. It is: given a
string, replace every char with its alphabetic index (starting from
1). The following simpler solution achieves it.

  ⊢string ←'GNUAPL'
GNUAPL
  ⊢string[⍋string] ← ⍳⍴string
1 2 3 4 5 6
  string
2 4 6 1 5 3

but now 'string' is overwritten. Then i tried to generalize it, thus

  {str⊣str[⍋str]←⍳⍴str←⍵} 'GNUAPL'
2 4 6 1 5 3

but now I need '⊣', otherwise the returned result will be the ordered iota.

I tried to understand why it returns 1 2 3 4 5 6 (without ⊣), but
failed! Any hints/references?

Thanks again for the fix.

Ala'a


On Mon, Oct 17, 2016 at 2:34 PM, Juergen Sauermann
 wrote:
> Hi Ala'a
>
> thanks, fixed in SVN 798.You will now get a DOMAIN ERROR instead of
> a failed assertion.
>
> The DOMAIN ERROR is being reported because you try to compare objects that
> would be called left values in C/C++, so your code is also wrong. I would
> also
> be careful with using A⍳B if A or B becomes large. For regular structures
> like
>
>   abc←'abcdefghijklmnopqrstuvwxyz'
>   abc⍳XXX
>
> you might consider using something like
>
>   0 ⌈ 26 ⌊ ¯97 + ⎕UCS XXX
>
> which will decrease your execution time from O((⍴A)×(⍴B)) down to O(⍴B).
>
> /// Jürgen
>
>
>
> On 10/16/2016 04:51 PM, Ala'a Mohammad wrote:
>
> I was trying to assign order to a word letters for example 'zach' is
> 312, I got it finally, for example for 'maine'
>   abc←'abcdefghijklmnopqrstuvwxyz'
>  1+(⌽⍳5)[(⍋abc⍳'maine')]
> 4 1 3 5 2
>
> But I got the following failing assertion and wanted to check if
> something related to my code or the interpreter.
> I'm using
> GNU APL
> : apl -v
> BUILDTAG:
> -
> Project:GNU APL
> Version / SVN:  1.6 / 796
> Build Date: 2016-09-26 18:43:22 UTC
> Build OS:   Linux 3.13.0-37-generic x86_64
> config.status:  unknown configure options
>Archive SVN: 787
>
> Operating system is Linuxmint 17.1 64bit (Linux rock 3.13.0-37-generic
> #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64
> GNU/Linux)
>
> Regards,
>
> Ala'a
>
> ---
>
>   abc←'abcdefghijklmnopqrstuvwxyz'
>   abc⍳'maine'
> 12 0 8 13 4
>   ⍋abc⍳'maine'
> 1 4 2 0 3
>   (⍋abc⍳'maine')←⍳5
> equal() called on object of classLvalCell
>
> ==
> Assertion failed: 0
> in Function:  equal
> in file:  Cell.cc:117
>
> Call stack:
>
> 
> -- Stack trace at Cell.cc:117
> 
> 0x7fb94a6e9f45 __libc_start_main
> 0x446105  main
> 0x56b84d   Workspace::immediate_execution(bool)
> 0x487e89Command::process_line()
> 0x487f2d Command::do_APL_expression(UCS_string&)
> 0x4923c8  Executable::execute_body() const
> 0x5201b0   StateIndicator::run()
> 0x4c57e9Prefix::reduce_statements()
> 0x4c4d59 Prefix::reduce_MISC_F_B_()
> 0x460d8f  Bif_F12_SORT_ASC::eval_B(Value_P)
> 0x45fdaf   Bif_F12_SORT::sort(Value_P, Sort_order)
> 0x47746aCell::greater_vec(Cell const*, Cell const*, void const*)
> 0x476b78
> 0x4552df  do_Assert(char const*, char const*, char const*, int)
> 
>
> SI stack:
>
> Depth:  79
> Exec:   0x1796ad0
> Safe exec:  0
> Pmode:◊  (⍋abc⍳'maine')←⍳5
> PC:   9 ENDL
> Stat: (⍋abc⍳'maine')←⍳5
> err_code: 0x0
> thrown:   at StateIndicator.cc:39
> e_msg_1:  'No Error'
> e_msg_2:  ''
> e_msg_3:  ''
>
> Depth:  78
> Exec:   0x17b2af0
> Safe exec:  0
> Pmode:◊  abc[s]
> PC:   4 ENDL
> Stat: abc[s]
> err_code: 0x50005
> thrown:   at Value.cc:1050
> e_msg_1:  'INDEX ERROR+'
> e_msg_2:  '  abc[s]'
> e_msg_3:  '  ^  ^'
>
> Depth:  77
> Exec:   0x17b2820
> Safe exec:  0
> Pmode:◊  s⌷abc
> PC:   3 ENDL
> Stat: s⌷abc
> err_code: 0x50002
> thrown:   at PrimitiveFunction.cc:2308
> e_msg_1:  'RANK ERROR'
> e_msg_2:  '  s⌷abc'
> e_msg_3:  '  ^ ^'
>
> Depth:  76
> Exec:   0x17b2e30
> Safe exec:  0
> Pmode:◊  abs⍳s
> PC:   2 'abs
> Stat: abs⍳s
> err_code: 0x30001
> thrown:   at Symbol.cc:662
> e_msg_1:  'VALUE ERROR'
> e_msg_2:  '  abs⍳s'
> e_msg_3:  '  ^'
>
> Depth:  75
> Exec:   0x17d0ae0
> Safe exec:  0
> Pmode:◊  abs[s]
> PC:   3 'abs
> Stat: abs[s]
> err_code: 0x30001
> thrown:   at Symbol.cc:662
> e_msg_1:  'VALUE ERROR'
> e_msg_2:  '  abs[s]'
> e_msg_3:  '  ^'
>
> Depth:  74
> Exec:   0x17a1e40
> Safe exec:  0
> Pmode:∇ λ1[1]
> PC:   13 ←
>
> ==
> Assertion failed: idx < items_valid
> in Function:  operator[]
> in file:  Simple_string.hh:140
>
> Call stack:
> *** 

Re: [Bug-apl] Assertion failed in 'equal'

2016-10-17 Thread Juergen Sauermann

  
  
Hi Ala'a
  
  thanks, fixed in SVN 798.You will now get a DOMAIN ERROR
  instead of
  a failed assertion.
  
  The DOMAIN ERROR is being reported because you try to compare
  objects that
  would be called left values in C/C++, so your code is also wrong.
  I would also
  be careful with using A⍳B if A or B
  becomes large. For regular structures like

 
abc←'abcdefghijklmnopqrstuvwxyz'
  
    abc⍳XXX
  
you might consider using something like

  0 ⌈ 26 ⌊ ¯97 +
⎕UCS XXX

which will decrease your execution time from O((⍴A)×(⍴B))
down to O(⍴B).

/// Jürgen


On 10/16/2016 04:51 PM, Ala'a Mohammad
  wrote:


  I was trying to assign order to a word letters for example 'zach' is
312, I got it finally, for example for 'maine'
  abc←'abcdefghijklmnopqrstuvwxyz'
 1+(⌽⍳5)[(⍋abc⍳'maine')]
4 1 3 5 2

But I got the following failing assertion and wanted to check if
something related to my code or the interpreter.
I'm using
GNU APL
: apl -v
BUILDTAG:
-
Project:GNU APL
Version / SVN:  1.6 / 796
Build Date: 2016-09-26 18:43:22 UTC
Build OS:   Linux 3.13.0-37-generic x86_64
config.status:  unknown configure options
   Archive SVN: 787

Operating system is Linuxmint 17.1 64bit (Linux rock 3.13.0-37-generic
#64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64
GNU/Linux)

Regards,

Ala'a

---

  abc←'abcdefghijklmnopqrstuvwxyz'
  abc⍳'maine'
12 0 8 13 4
  ⍋abc⍳'maine'
1 4 2 0 3
  (⍋abc⍳'maine')←⍳5
equal() called on object of classLvalCell

==
Assertion failed: 0
in Function:  equal
in file:  Cell.cc:117

Call stack:


-- Stack trace at Cell.cc:117

0x7fb94a6e9f45 __libc_start_main
0x446105  main
0x56b84d   Workspace::immediate_execution(bool)
0x487e89Command::process_line()
0x487f2d Command::do_APL_expression(UCS_string&)
0x4923c8  Executable::execute_body() const
0x5201b0   StateIndicator::run()
0x4c57e9Prefix::reduce_statements()
0x4c4d59 Prefix::reduce_MISC_F_B_()
0x460d8f  Bif_F12_SORT_ASC::eval_B(Value_P)
0x45fdaf   Bif_F12_SORT::sort(Value_P, Sort_order)
0x47746aCell::greater_vec(Cell const*, Cell const*, void const*)
0x476b78
0x4552df  do_Assert(char const*, char const*, char const*, int)


SI stack:

Depth:  79
Exec:   0x1796ad0
Safe exec:  0
Pmode:◊  (⍋abc⍳'maine')←⍳5
PC:   9 ENDL
Stat: (⍋abc⍳'maine')←⍳5
err_code: 0x0
thrown:   at StateIndicator.cc:39
e_msg_1:  'No Error'
e_msg_2:  ''
e_msg_3:  ''

Depth:  78
Exec:   0x17b2af0
Safe exec:  0
Pmode:◊  abc[s]
PC:   4 ENDL
Stat: abc[s]
err_code: 0x50005
thrown:   at Value.cc:1050
e_msg_1:  'INDEX ERROR+'
e_msg_2:  '  abc[s]'
e_msg_3:  '  ^  ^'

Depth:  77
Exec:   0x17b2820
Safe exec:  0
Pmode:◊  s⌷abc
PC:   3 ENDL
Stat: s⌷abc
err_code: 0x50002
thrown:   at PrimitiveFunction.cc:2308
e_msg_1:  'RANK ERROR'
e_msg_2:  '  s⌷abc'
e_msg_3:  '  ^ ^'

Depth:  76
Exec:   0x17b2e30
Safe exec:  0
Pmode:◊  abs⍳s
PC:   2 'abs
Stat: abs⍳s
err_code: 0x30001
thrown:   at Symbol.cc:662
e_msg_1:  'VALUE ERROR'
e_msg_2:  '  abs⍳s'
e_msg_3:  '  ^'

Depth:  75
Exec:   0x17d0ae0
Safe exec:  0
Pmode:◊  abs[s]
PC:   3 'abs
Stat: abs[s]
err_code: 0x30001
thrown:   at Symbol.cc:662
e_msg_1:  'VALUE ERROR'
e_msg_2:  '  abs[s]'
e_msg_3:  '  ^'

Depth:  74
Exec:   0x17a1e40
Safe exec:  0
Pmode:∇ λ1[1]
PC:   13 ←

==
Assertion failed: idx < items_valid
in Function:  operator[]
in file:  Simple_string.hh:140

Call stack:
*** do_Assert() called recursively ***
==