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
|