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 <address@hidden> 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<std::string, std::allocator<std::string> > 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 <address@hidden> 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<std::string, std::allocator<std::string> > 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 <address@hidden> 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 <address@hidden>
>> 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
>>> <address@hidden> 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 *)&utf[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
>>>>
>>>>
>>>
>>>
>>