[Bug-apl] I just can't help myself

2018-10-08 Thread Bill Daly 

Hello Jürgen

I've been working on two projects utl, my utility workspace with better 
documentation and better function names and lpr, a workspace to print 
directly from apl.


Now I've melted down the interpretor so I've sent three logs. I'm not 
sending all the workspace I loaded to create these files. I have updated 
the repository and one may clone it:


    git clone https://git.code.sf.net/p/apl-library/code apl-library-code

When you look at all this can you consider a few issues?

I've defined a function lpr∆USLetter which returns a lexicon that i need 
to for the unix pr and lpr commands.  Could you write one for the usual 
a sized paper sheets?  I started down that road and tripped on my 
uncontrollable urge to do arithmetic.  I couldn't figure how the 
priinters work as none of the a sizes seem to easily divided into 
points.  Here in Pennsylvania where we cling to all sorts of ancient 
biases one inch = 72 points and thus 12 point type is equal to one sixth 
of an inch and one letter size page has 66 lines per inch.


Could you also look at date.apl? I've defined a lexicon date-delta-US 
which in addition to the American month, weekday names defines day_pos, 
month_pos, and year_pos for those who feel that days come before months.


Thanks for all your help

Bill

  )load 1 lpr
DUMPED 2018-10-08  09:54:47 (GMT-4)
DUMPED 2018-10-07  08:46:49 (GMT-4)
DUMPED 2018-09-18  11:05:59 (GMT-4)
DUMPED 2018-08-18  16:48:59 (GMT-4)
  )copy 1 wp
DUMPED 2018-09-18  10:07:43 (GMT-4)
DUMPED 2018-09-18  10:07:43 (GMT-4)
DUMPED 2018-09-18  10:07:43 (GMT-4)
DUMPED 2018-09-18  11:05:59 (GMT-4)
DUMPED 2018-10-02  12:58:04 (GMT-4)
 html∆a html∆b html∆blockquote html∆body html∆caption html∆cite html∆div html∆em
   html∆footer html∆h1 html∆h2 html∆h3 html∆h4 html∆h5 html∆head html∆header
   html∆hr html∆html html∆i html∆li html∆link html∆nav html∆p html∆pre html∆
  span html∆strong html∆style html∆td html∆th html∆thead html∆tr html∆title
  html∆table html∆thead 
 html∆br html∆hr html∆meta 
DUMPED 2018-09-18  10:07:43 (GMT-4)
DUMPED 2018-08-18  16:48:59 (GMT-4)
  ∊utl∆helpFns ¨ (fns[;1 2]∧.='wp')⌿fns←⎕nl 2
INDEX ERROR
utl∆helpFns[3]  msg←(utl∆trim¨⊂[2]((1,∧\'⍝'=1↓src[;1])⌿src),⎕TC[3]),⎕TC[3]
  ^ ^
  src
  )sic
  ∊utl∆helpFns ¨ (fns[;1 2]∧.='wp')⌿fns←⎕nl 3
INDEX ERROR
utl∆helpFns[3]  msg←(utl∆trim¨⊂[2]((1,∧\'⍝'=1↓src[;1])⌿src),⎕TC[3]),⎕TC[3]
  ^ ^
  src
  fns
cl∆∆max
fns
html5∆closedTagList
html5∆tagList  
wp∆defaultcss  
xml∆whitespace 
  )fns
FIO FIO∆SockHelper
FIO∆accept  FIO∆access
FIO∆bindFIO∆chdir
FIO∆clear_statisticsFIO∆connect
FIO∆errno   FIO∆execve
FIO∆fclose  FIO∆feof
FIO∆ferror  FIO∆fflush
FIO∆fgetc   FIO∆fgets
FIO∆file_errno  FIO∆files_in_directory
FIO∆fopen   FIO∆fopen_ro
FIO∆fprintf FIO∆fprintf_stderr
FIO∆fread   FIO∆fscanf
FIO∆fseek_cur   FIO∆fseek_end
FIO∆fseek_set   FIO∆fstat
FIO∆fsync   FIO∆ftell
FIO∆fwrite  FIO∆fwrite_utf8
FIO∆get_dyadic_thresholdFIO∆get_monadic_threshold
FIO∆get_statistics  FIO∆getcwd
FIO∆getpeername FIO∆getsockname
FIO∆getsockopt  FIO∆gettimeofday
FIO∆gmtime  FIO∆listen
FIO∆localtime   FIO∆mkdir
FIO∆mkdir_777   FIO∆mktime
FIO∆pclose  FIO∆popen
FIO∆popen_roFIO∆printf
FIO∆readFIO∆read_directory
FIO∆read_file   FIO∆read_lines
FIO∆recvFIO∆rename
FIO∆rmdir   FIO∆select
FIO∆sendFIO∆send_utf8
FIO∆set_dyadic_thresholdFIO∆set_monadic_threshold
FIO∆setsockopt  FIO∆socket
FIO∆sscanf  FIO∆strerror
FIO∆unlink  FIO∆write
FIO∆write_lines FIO∆write_utf8
FIO⍙metadatahtml∆a
html∆b  html∆blockquote
html∆body   html∆br
html∆captionhtml∆cite
html∆divhtml∆em
html∆footer html∆h1
html∆h2 html∆h3
html∆h4 html∆h5
html∆head   html∆header
html∆hr html∆html
html∆i  html∆li
html∆link   html∆meta
html∆navhtml∆p
html∆pre

Re: [Bug-apl] bad character in execute+

2018-10-08 Thread Hans-Peter Sorge 
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
>>
>>
>

Re: [Bug-apl] bad character in execute+

2018-10-08 Thread 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






  
  




  




signature.asc
Description: OpenPGP digital signature