#2 faslout has problems

When starting the csl reduce to compile crack I get:

------------------------------------------------
REDUCE, 15-Sep-08 ...

1: faslout crack$

FASLOUT crack: IN files; or type in expressions
When all done, execute FASLEND;
C file = "/tmp/a0bxouaj"
2: in "~/red/src6/crack.red"$
Compiling setprop ...
+++ setprop compiled, 38 + 12 bytes
Failed to find "/home/user/red/csl/./reduce.img(pipes)"

***** error in loading package pipes or package not
found

Cont? (Y or N)

?
------------------------------------------------

Thanks,
Thomas

[Arthur Norman]

There is a PSL-only loadable modules called "pipes" but there is not and never has been either a CSL one or one that is in the generic parts of Reduce.

You will already file that crutil.red contains some code that is sensitive to whether it runs on CSL or PSL, as in it says

% some PSL specific hacks

!#if (memq 'psl lispsystem!*)
symbolic procedure delete!-file(fi);
if memq('unix,lispsystem!*) then
system bldmsg("rm '%s'",fi) else
system bldmsg("del ""%s""",fi);
!#endif

so if you have a "load pipes" somewhere does it need guarding that way. Just what use of pipes do you need?

There is a function "pipe!-open" in CSL always, but it has probably not been heavily used or tested... Arthur

[Anonymous]

I wrapped load pipes:
!#if (memq 'psl lispsystem!*)
load pipes$ % to detect the operating system for parallel runs
% See calls of pipe!-open() in crpvm.red and crutil.red.
% There is a function "pipe!-open" in CSL.
!#endif

and load debug:
!#if (memq 'psl lispsystem!*)
algebraic (load debug)$
!#endif

but now when compiling procedure crackmain() in crmain.red it crashes:
-------------------
...
+++ sq!*crack compiled, 1786 + 364 bytes
Compiling crackmain ...

Cont? (Y or N)

?
----------------------
How can one find out what is the cause?

Thomas

File Added: crmain.red

[Anonymous]

the file which crashes

[Arthur Norman]

With the CSL version OI can either set !*backtrace or use a "-g" command-line option to make errors noisier and hence easier to debug. IN this case when I try that I see first a LOT of cases where you are using undeclared variables that really probably ought to have been declared fluid or global. Eg a FEW of them are
+++ full_proc_list_ declared fluid
+++ choose_70_65_8_47_origterms declared fluid
+++ tr_main declared fluid
+++ adjust_fnc declared fluid
+++ time_limit declared fluid
+++ limit_time declared fluid
+++ print_more declared fluid
+++ expert_mode declared fluid
+++ eqn_to_be_gen declared fluid
+++ gcfree!* declared fluid
+++ userrules_ declared fluid
+++ session_ declared fluid
+++ repeat_mode declared fluid
+++ auto_para_mode declared fluid
+++ print_all declared fluid
+++ lex_fc declared fluid

... But THEN I see
+++ call_crack_out declared fluid
+++ Error: ilogand (loadlit !*) 255
Inside: s!:expand_jump
Arg 1: jumpne
Arg 2: 127
Inside: s!:resolve_labels
Inside: s!:endprocedure
Arg1: crackmain
... which at first sight is the compiler getting significantly upset by something where at present I do not know what is making it choke. But at present I *SUSPECT* that it is to do with that one procedure being bigger that is comfortable or containing more references to distinct literals or global variables than is common and that is taking the compiler through a path that has not been exercised and debugged enough.

So in the short term you could try making all those variabes explicitly global or fluid which would tidy things up and protect agsinst some sorts of glitch and then see of crmain would easily split into a number of smaller chunks. It is at present around 1200 lines long.

I will (when I can!) investigate compiler limits in that area... but the result MIGHT end up that you get a clear disgnostic from the compiler saying "procedure too large" if I have trouble making it manage gracefully!!!!

Thanks for the report. Arthur

[Anonymous]

All variables are declared fluid in the file crack.red
before other files are read in for compilation.

About the length of a procedure: it would need many
procedures outsourced to reduce the length substantially.
Is there a way to increase the possible length of
procedures/files?

Thomas

[Arthur Norman]

There was a place in the compiler where it was allowing for procedures with > 255 distinct literals where the code accessed the incorrect variable - I have changed that in the subversion repository and although I have not tested behaviour at least the compiler does not crash any more on your example!
So to get the benefit of this you will need to fetch and download a current subversion copy of the code.