Re: GSoC status report

Jörg wrote:
> Did you mean the Lisp level FFI tests or the C tests part of the libffcall
> library?
> Did you build the ffcall library on your own or use the binary package
> from the distribution?

I mean the Lisp level tests (tests/ffi.tst). Currently I'm only using the
binary package from the distribution
(libffcall-2009-05-27 ... wow, that's kind of dated.)


Jörg wrote:
> +2 A CLISP release should not be built without libsigsegv. Libsigsegv is
> required for generational GC, and a CLISP without genGC is an order of
> magnitude slower than when it's available.
> OTOH, better without genGC than no CLISP at all. YMMV.
>
> IIRC, early binaries for MS-Windows ran without libsigsegv.
> Actually, has libsigsegv ever been ported to MS-Windows?

I mostly built without libsigsegv because of lazyness to download it.
Windows (cygwin, mingw, as it seems also "pure native" msvc) seems to be
supported, according to the PORTING file. And indeed, it builds and passes
its tests (it's reporting i686-pc-mingw32 as detected target, which is correct
but surprised me due to running on win 10 amd64 with MinGW64).

CLISP builds with libsigsegv, too. Though interestingly it adds even more
issues with regards to pathnames (without libsigsegv only the argument of
a Lisp level load call had to be adjusted, with libsigsegv also the -lp
parameter to lisp.exe)
The tests run exactly the same as without libsigsegv: 2 errors for
tests/socket.tst and 3 for tests/path.tst.

Regarding the socket tests: At first I thought it could be the firewall, but
even without it trying to communicate with a socket server just hangs.

Adding this link for pure reference, someone who built on mingw, too:
http://www.frank-buss.de/lisp/clisp.html

Jörg wrote (regarding "64 bit support"):
> I'm confused. If on amd64, you're building a 64bit version, aren't you?
> So what doesn't get configured and what builds and passes tests?

(on linux)
I'm on amd64, and am building a 64bit version. Both clisp and lisp.run are
64bit elf executables. There's :WORD-SIZE=64 in *features*.
Running

(use-package "FFI")
(WITH-C-VAR (X 'SINT64 1229782938247303441) T)

results in

[SIMPLE-ERROR]: FFI::EXEC-ON-STACK: 64 bit integers are not supported
on this platform and with this C compiler: SINT64

From a first glance at the relevant code, this message can only show up if
HAVE_LONG_LONG_INT is not defined (in src/foreign.d, because then error_64bit
is called from convert_to_foreign). Thus I'd assume it's some "configure" bug,
though I'm with Sam here:

Sam wrote:
> not too good, but I sure we can figure this out eventually.



Jörg wrote:
> "Downstream" means the NetBSD CLISP package maintainer?
> Mmap issues can get very hairy and very low-level fast. CLISP tries to put
> its typecodes within the 32 bit pointers and may soon get in conflict with the
> OS memory layout. I don't know how ASLR works with CLISP. I'd expect much less
> mmap trouble with a 64bit build.

I found this: http://gnats.netbsd.org/33189
They just add a flag --disable-mmap. From a few first tests it seems that
MAP_FIXED (which the offending function, mmap_zeromap, uses) is entirely
unuseable on NetBSD. I'll try to get more information on this from their
mailing list.

Btw, is there any technical reason for using a fixed address instead of
letting the underlying OS choose a suitable location?

Jörg wrote:
> (Note that I never put my hands on a NetBSD system.)

When I read "Pullup ticket 1670 - requested by joerg" (in above link) I hoped
that "joerg" would be you, but I guess I'm wrong then :)


Sam wrote:
>>  * linux, ./configure (tried a minimum config): builds, tests segfault
>>  when trying to run a socket server, possibly due to a corrupted error
>>  message.
>
> I am confused: how is this different from above?

Instead of using defaults, I passed --without-ffcall, --without-dynamic-modules
and --without-readline (mostly out of curiosity). On linux amd64, this fails
with:

(CHECK-OS-ERROR (SOCKET-SERVER 1240 :INTERFACE "[/]=") (:EINVAL 22))
[OS-ERROR]:
*** - handle_fault error2 ! address = 0x0 not in [0x33437f000,0x3346e2dc0) !
SIGSEGV cannot be cured. Fault address = 0x0.

This looks a lot as if the message it's about to print isn't a valid
(C) string.


Sam wrote:
> You did not even scratch the surface, sorry.

I figured it would be good to know how reliable CLISP itself is before
approaching the modules.
Summarizing the configuration related stuff:

 * libsigsegv, ffcall, dynamic-modules, unicode, readline: yes
 * threads, jitc: no
 * disabling mmap on NetBSD is ok
 * garbage collector / object representation: leave as is
 * check that fixnums have 48 bits available on 64bit architectures (?)
 * configuration system itself remains on TODO list for later


Sam wrote:
> The real problem is, as I said before, with gnulib files in modules.
>
> You need to build at least the following modules:
> base (i18n, regexp, syscalls, readline)
> full (rawsock, bindings, asdf, pcre, new-clx)
> all others for which you can _easily_ get the back end (berkeley-db,
> fastcgi, gdbm, libsvm, pari, postgresql, zlib)

Ok, I'll try to bring some news regarding this ASAP. asdf should be updated
to it's recent version, right? (there was a post from its maintainer on
clisp-list: https://sourceforge.net/p/clisp/mailman/message/35010071/ )


Sam wrote:
> Many modules come with their own test suites which can be run with "make
> mod-check", and I bet rawsock will fail on windows spectacularly.

I just tried with rawsock and indeed, it didn't come very far, though that's
not really related to rawsock: Running make mod-check recompiles
(and breaks!) clisp.exe leading to another pathname related issue.

Moreover, it didn't even build rawsock because (again, pathnames) it didn't
find the modules folder:

./configure --help-modules
module sets found in the directory 'modules':
find: `modules': No such file or directory
to specify the location of external software:


Sam wrote:
> You will have to update CLISP with 6 years worth of gnulib updates, and
> also figure out how to make it work on windows.
> This is the meat of the project.
> This is what the midterm eval will hinge on.

Is there any "list" (possibly from the time of the first gnulib import) of
what gnulib module is imported for what reason?
In order to get anything to work on windows I'll find and fix that pathname
issues now.


Jörg wrote:
> Not needed with SLIME or withint Emacs, but I don't know whether current SLIME
> still supports CLISP (I haven't heard about CLISP in the SLIME mailing list
> for a long time).

Pascal wrote:
> Clisp works ok with slime.

I am using this setup since about a year without major issues.


Finally: Do these mails get too long? Would it be better to split further
discussion by topic, i.e. windows-pathname related, HAVE_LONG_LONG_INT
related, ... ?

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel