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