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 <amal...@gmail.com> 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 <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
>>>>
>>>>
>>>
>>>
>>
