Hello Jürgen,
correct - I missed:
*Skipped 'trunk/src/Executable.cc' -- Node remains in conflict*
Sorry for the false alarm.
Best Regards,
Hans-Peter
Am 08.10.18 um 22:47 schrieb Juergen Sauermann:
> Hi Hans-Peter,
>
> it looks like you compile an new *Executable.hh* with an old
> *Executable.cc*.
>
> The current executable looks - apart from other differences - like this:
>
> ...
> line 546:
>
> * Assert(end != -1);**
> ** b = setup_one_lambda(b, end, ++lambda_num) - 1; // -1 due
> to ++b in loop(b) above**
> **...**
> **
> *
> Best Regards,
> /// Jürgen
>
>
>
> On 10/08/2018 10:08 PM, Hans-Peter Sorge wrote:
>> Hello Jürgen,
>>
>> compile fails with
>>
>> Executable.cc: In member function 'void Executable::setup_lambdas()':
>> Executable.cc:529:46: error: no matching function for call to
>> 'Executable::setup_one_lambda(ShapeItem&, int&)'
>> b = setup_one_lambda(b, ++lambda_num) - 1; // -1 due to ++b
>> in loop(b) above
>> ^
>> In file included from Executable.cc:22:
>> Executable.hh:164:14: note: candidate: 'ShapeItem
>> Executable::setup_one_lambda(ShapeItem, ShapeItem, int)'
>> ShapeItem setup_one_lambda(ShapeItem b, ShapeItem end, int lambda_num);
>> ^~~~~~~~~~~~~~~~
>> Executable.hh:164:14: note: candidate expects 3 arguments, 2 provided
>> Executable.cc: At global scope:
>> Executable.cc:543:1: error: no declaration matches 'ShapeItem
>> Executable::setup_one_lambda(ShapeItem, int)'
>> Executable::setup_one_lambda(ShapeItem b, int lambda_num)
>> ^~~~~~~~~~
>> In file included from Executable.cc:22:
>> Executable.hh:164:14: note: candidate is: 'ShapeItem
>> Executable::setup_one_lambda(ShapeItem, ShapeItem, int)'
>> ShapeItem setup_one_lambda(ShapeItem b, ShapeItem end, int lambda_num);
>> ^~~~~~~~~~~~~~~~
>> Executable.hh:38:7: note: 'class Executable' defined here
>> class Executable
>> ^~~~~~~~~~
>>
>> Thanks,
>>
>> Hans-Peter
>>
>> Am 01.10.18 um 17:17 schrieb Juergen Sauermann:
>>> Hi Kacper,
>>>
>>> thanks, fixed in *SVN 1082*.
>>>
>>> /// Jürgen
>>>
>>>
>>>
>>> On 10/01/2018 01:11 AM, Kacper Gutowski wrote:
>>>> On Sun, Sep 30, 2018 at 03:42:53PM -0600, Nathan Rogers wrote:
>>>>> When using the diamond operator, the repl returns "bad character in
>>>>> execute+"
>>>>>
>>>>> simple example: \
>>>>> {1:2◊3}
>>>>> Bad char in execute+
>>>> Lambda syntax in GNU APL isn't compatible with Dyalog's, and you can't
>>>> use diamond within it. But the diamond here is a red herring.
>>>> It's the colon that causes the error before getting to the diamond:
>>>>
>>>> :
>>>> Bad char in execute+
>>>> {1⋄2}
>>>> Unbalanced curly bracket+
>>>>
>>>> It more-or-less works as expected. The former is because : is not a
>>>> valid token outside of defined functions where it is used for labels.
>>>> The later is because it's interpreted as two separate statements split
>>>> by diamond.
>>>>
>>>> I think the )MORE messages for parse errors could be improved, though.
>>>> Now it just repeats "Bad char in execute". It would be more informative
>>>> to say which character is the offending one.
>>>>
>>>> -k
>>>>
>>>>
>
