Jared C. Davis | 26 Sep 20:30 2014
Picon

ext:unix-namestring issue

Hi,

I am using CMUCL 20e on a Linux/x86 system.  In tracking down an issue with
osilib:file-kind on CMUCL, I found the behavior of ext:unix-namestring to be
somewhat surprising when parts of the input path do not exist.

In particular, suppose that I have the following directory structure:

    foo/            (foo is otherwise empty except for bar)
     |
    bar/            (bar is otherwise empty except for hello.txt)
     |
  hello.txt

In this case, the following seem perfectly sensible and consistent:

  (ext:unix-namestring "hello.txt"         nil) ; "hello.txt"
  (ext:unix-namestring "foo/"              nil) ; "foo/"
  (ext:unix-namestring "foo/hello.txt"     nil) ; "foo/hello.txt"
  (ext:unix-namestring "foo/bar/hello.txt" nil) ; "foo/bar/hello.txt"
  (ext:unix-namestring "foo/bar/bye.txt"   nil) ; "foo/bar/bye.txt"
  (ext:unix-namestring "foo/bar/"          nil) ; "foo/bar/"
  (ext:unix-namestring "foo/bar/baz"       nil) ; "foo/bar/baz"
  (ext:unix-namestring "foo/bye.txt"       nil) ; "foo/bye.txt"
  (ext:unix-namestring "bye.txt"           nil) ; "bye.txt"

But it seems odd that examples such as these return NIL:

  (ext:unix-namestring "oops/"                  nil) ; NIL, why not
instead "oops/"?
(Continue reading)

Fausto Saporito | 14 Sep 00:13 2014
Picon

Re: 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]

2014-09-10 19:10 GMT+02:00 Carl Shapiro <carl.shapiro <at> gmail.com>:
> On Wed, Sep 10, 2014 at 1:18 AM, Fausto Saporito <fausto.saporito <at> gmail.com>
> wrote:
>>
>> how can I do that ? in dbx I cannot find anything about disassembling....
>> I have to check with ladebug.
>
>
> I think you can tell dbx something like 0x12345678/90i where 0x12345678 is
> your address, 90 is an optional repeat count, and i is the flag for
> instructions.  There is an example in section 1.8.6 of the ladebug manual.
> Its command syntax is similar to dbx.

Hello Carl,

I tried, but the PC when the dbx find the error, is

In initial-function, and running.
GLOBALDB-INIT
FDEFN-INIT
TYPEDEF-INIT
CLASS-INIT
TYPE-INIT
Calling top-level forms.
signal Trace/BPT trap at >*[., 0x3028f990]      call_pal mtpr_astsr

(dbx) px $pc
0x3028f990

and address of INITIAL-FUNCTION is 0x30295720 (according to lisp.map),
(Continue reading)

Raymond Toy | 8 Sep 21:41 2014
Picon

19c alpha [Was Re: CMUCL 18c building on tru64 5.1]

On Mon, Sep 8, 2014 at 10:41 AM, Fausto Saporito <fausto.saporito <at> gmail.com>
wrote:

> Hello... I fixed the Depends problem... in the GNUMakefile there's -MM
> flag for depend... it seems DEC cc wants just one M...
>
> so -M -E
>
>
​Starting a new thread....

If we're standardizing on 19c, I'll try to make a branch from 19c to keep
track of this development work, so we don't lose it.

It's probably worth while for me to get the github mirror of cmucl actually
working.

​

> regards,
> Fausto
>
>
> 2014-09-08 19:16 GMT+02:00 Fausto Saporito <fausto.saporito <at> gmail.com>:
> > ok, Ray.
> > I'll use 19c from now on.
> >
> > thanks,
> > Fausto
> >
(Continue reading)

Raymond Toy | 8 Sep 00:15 2014
Picon

Re: CMUCL 18c building on tru64 5.1

On Sun, Sep 7, 2014 at 9:25 AM, Fausto Saporito <fausto.saporito <at> gmail.com>
wrote:

> Hello Ray,
>
> i'm trying to do a cross-compile with 18e, I copied the scripts from
> 19a, cause in the 18x src tree they don't exist.
> It seems all ok, but I got this new error:
>
> ;; Loading
> #p"/home/fausap/CMU/18e/alpha-cross/compiler/generic/new-genesis.x86f".
> ;
>
> ; Warning: This function is undefined:
> ;   KERNEL::%CLASS-LAYOUT
>
> Error in %COERCE-TO-FUNCTION:  the function KERNEL::%CLASS-LAYOUT is
> undefined.
>

​Ah, there were some class layout changes done by Gerd somewhere around ​

​the 18e or 18f time frame.  It might work to just remove those things from
the bootstrap file or try to get the scripts from release 18e or 18f.​

Rather than randomly trying different versions, can we stick to the one
where you were able to create a kernel.core successfully? (Which version
was that?) Let's stick to that and see how far we can get with it. I think
if we can figure out why your debugger session is so different from the
assembly source, we can make it work. That's gotta be something simple and
(Continue reading)

Fausto Saporito | 7 Sep 21:58 2014
Picon

named-readtables

hello all,

I'm trying to install (with quicklisp) the named-readtables package.
I'm using 20e version (under Linux), but I have these errors:

[package editor-hints.named-readtables].......;

; Error: (during macroexpansion)
;
; Error in function LISP::ASSERT-ERROR:
;    The assertion (OR (NULL OPTS) (EQ # '&OPTIONAL)) failed.
....
..; ;

; Error: (during macroexpansion)
;
; Error in function LISP::ASSERT-ERROR:
;    The assertion (OR (NULL OPTS) (EQ # '&OPTIONAL)) failed.

Do you have experience with this package ?

I'm using it because it's needed by matlisp.

thanks,
Fausto
_______________________________________________
cmucl-help mailing list
cmucl-help <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help

(Continue reading)

Fausto Saporito | 4 Sep 12:46 2014
Picon

Re: CMUCL 18c building on tru64 5.1

Hello,

this is the debug session of alpha-assem.s, specifically call_to_lisp function:

(dbx) stop in funcall0
[2] stop in funcall0
(dbx) run -core kernel.core
WARNING: startup-code version (6) different from core version (0).
You may lose big.
[2] stopped at   [funcall0:315 ,0x1202df14]     lispobj *args =
current_control_stack_pointer;
(dbx) n
  [funcall0:317 ,0x1202df20]    return call_into_lisp(function, args, 0);
(dbx) stepi
>*[funcall0:317, 0x1202df24]    ldq     a1, 16(sp)
(dbx) stepi
>*[funcall0:317, 0x1202df28]    bis     zero, zero, a2
(dbx) stepi
>*[funcall0:317, 0x1202df2c]    ldq_u   zero, 0(sp)
(dbx) stepi
>*[funcall0:317, 0x1202df30]    bsr     ra, call_into_lisp+0x8(line 54)
(dbx) stepi
>*[call_into_lisp:54, 0x1202e138]       ldah    at, 511(gp)
(dbx) stepi
>*[call_into_lisp:25, 0x1202e13c]       lda     sp, -64(sp)
(dbx) stepi
>*[call_into_lisp:28, 0x1202e140]       stq     s1, 16(sp)
(dbx) stepi
>*[call_into_lisp:61, 0x1202e144]       bis     a1, a1, s1
(dbx) stepi
(Continue reading)

Fausto Saporito | 4 Sep 00:42 2014
Picon

Re: CMUCL 18c building on tru64 5.1

Hello Raymond,

I have a doubt... I tried to compile the lisp frontend with gcc (under
Tru64)... I suppose the Config file has been made with gcc in mind...
the -I- in the CPPFLAGS is gcc syntax...not DECC
Also gmake doesn't complain about the depends generated by gcc.

I have only gcc4.x at the moment, and maybe is too new...

I have an error compiling src/lisp/interrupt.c at line 644:

 ../../src/lisp/interrupt.c:644: error: lvalue required as left
operand of assignment

That line is :

SC_NPC(context) = SC_PC(context) + 4;

maybe it could be SC_PC(context) = SC_PC(context) + 4;

this line interpreted only if not x86.
SC_NPC is only used in that line... so it's quite strange.

regards
fausto

2014-09-03 22:13 GMT+02:00 Raymond Toy <toy.raymond <at> gmail.com>:
>
>
>
(Continue reading)

Raymond Toy | 3 Sep 00:51 2014
Picon

Re: CMUCL 18c building on tru64 5.1

In case you haven't already, you probably don't want these features set for
alpha:

:complex-fp-vops
:linkage-table
:stack-checking
:heap-overflow-check
:gencgc
:modular-arith
:executable

Check that extern-alien-name, fixup-code-object, and sanctify-for-execution
are correct for alpha. Not sure if these are needed or not. Not all of them
are defined for sparc in the cross-x86-sparc.lisp file.

On Sun, Aug 31, 2014 at 11:14 PM, Fausto Saporito <fausto.saporito <at> gmail.com
> wrote:

> Hello Ray,
>
> yes, I'm using 20d to cross-build 20d.
> I read at the top of the sparc cross.lisp file, it should be broken :-)
>
> Attached there're all the log files and the script.
>
> I read some errors about external symbols that are not external in
> ALPHA package, maybe this is related to some definitions in
> cross.lisp, but I'm not sure about it.
>
> thanks for you help
(Continue reading)

Raymond Toy | 2 Sep 05:55 2014
Picon

Re: CMUCL 18c building on tru64 5.1

On Sun, Aug 31, 2014 at 11:14 PM, Fausto Saporito <fausto.saporito <at> gmail.com
> wrote:

> Hello Ray,
>
> yes, I'm using 20d to cross-build 20d.
> I read at the top of the sparc cross.lisp file, it should be broken :-)
>

​FWIW, I just did a cross-compile from x86 (OSX) to sparc using the current
git sources. It works as long as you remember to remove :alien-callback
when compiling on sparc.​

>
> Attached there're all the log files and the script.
>
> I read some errors about external symbols that are not external in
> ALPHA package, maybe this is related to some definitions in
> cross.lisp, but I'm not sure about it.
>

​Possibly.​

>
> thanks for you help
> Fausto
>
>
> 2014-09-01 5:11 GMT+02:00 Raymond Toy <toy.raymond <at> gmail.com>:
> >
(Continue reading)

Fausto Saporito | 1 Sep 11:56 2014
Picon

Re: CMUCL 18c building on tru64 5.1

Hello,

please could you explain me the difference between alpha-target and
alpha-cross ?
I understand the alpha-target will contain the lisp.core (for alpha)
and the frontend files to be compiled under OSF1.
But alpha-cross ?

I tried to use, also, a cross compile file x86->ppc (with some obvious
modifications).

I have some serious errors, maybe due to some changes not ported to alpha tree:

alpha/vm

Error in function META-SC-OR-LOSE:
   DESCRIPTOR-REG is not a defined storage class.

alpha/insts

    ZERO is not a defined storage class.

alpha/move

    NULL is not a defined storage class.

alpha/float

    FP-SINGLE-ZERO is not a defined storage class.

(Continue reading)

Fausto Saporito | 30 Aug 13:42 2014
Picon

CMUCL 18c building on tru64 5.1

Hello all,

i'm trying to build CMUCL 18c under Tru64 5.1 using Digital C compiler
and assembler.
I have this error compiling alpha-assem.s

as -g -Dosf1 -Dalpha -I/usr/users/fausap/wrk/CMUCL/src/18c/lisp  -o
alpha-assem.o alpha-assem.s
alpha-assem.s(242) : error : syntax error : last token was 'undefined_tramp'
alpha-assem.s(256) : error : syntax error : last token was 'closure_tramp'
gmake: *** [alpha-assem.o] Error 1

I know this is quite old version and unsupported arch, but do you know
is there's a patch to fix this error ?

thanks a lot,
Fausto
_______________________________________________
cmucl-help mailing list
cmucl-help <at> cmucl.cons.org
http://lists.zs64.net/mailman/listinfo/cmucl-help


Gmane