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 <loke...@gmail.com> 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
>> <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 *)&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
>>>
>>>
>>
>>
>
