Re: [Ecls-list] Big patch

2010-10-29 Thread Juan Jose Garcia-Ripoll
Thanks for reporting it. Right now the speed at which I prepare fixes and
changes in ECL is faster than the speed of commits and of answering emails
:-)

Juanjo

On Fri, Oct 29, 2010 at 5:09 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:

 On Fri, 22 Oct 2010 00:06:28 -0400
 Matthew Mondor mm_li...@pulsar-zone.net wrote:

  Broken at SI:BYTECODES. [Evaluation of: (FOOBAR)] In:
  Debugger received error: Cannot print object #process TOP-LEVEL
 0810afc0 readably.
  Error flushed.
  Broken at SI:BYTECODES. [Evaluation of: (FOOBAR)] In:
  Debugger received error: Cannot print object #process TOP-LEVEL
 0810afc0 readably.
  Error flushed.
  [...]

 This now appears to have been fixed.  Thanks!
 --
 Matt


 --
 Nokia and ATT present the 2010 Calling All Innovators-North America
 contest
 Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
 $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
 marketing
 Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
 http://p.sf.net/sfu/nokia-dev2dev
 ___
 Ecls-list mailing list
 Ecls-list@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ecls-list




-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


[Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Paul Goins
Hi,

New to the list, so please forgive me if I've missed a thread that
covers this.

I'm trying to compile ECL 10.4.1 under Windows 7 64-bit.
Unfortunately, I'm having problems, and the Windows with
Mingw/Cygwin section of the reference guide is totally blank, so I
thought I should ask here.

(Note: already read some previous comments about 64-bit support.  I'm
just trying to build a 32-bit ECL via 32-bit MinGW, so don't worry,
I'm not barking up *that* tree.  However, the OS *is* 64-bit.)

1. I grabbed the CVS version of the Boehm GC.  Built it successfully
using ./configure  make  make install.  (7.1 failed to compile
via MSys in this way.)

2. I tried to ./configure and make ECL.  This did not pan out...

./configure --enable-threads=yes
# no problem, but did give some warnings:
#   configure: Configuring included GMP library:
#   configure: WARNING: you should use --build, --host, --target

make
# (This fails; output attached at the end)

 From here, I don't really know how to proceed.

I don't need to run 10.4.1, but I would really like to get some
version of ECL running on this system.  If anyone can advise me of
some way to get some version going, it'd really be appreciated.

Attached at the bottom is the error from running make, plus notes on
my MinGW configuration (in case it matters).

Thanks in advance.

Best Regards,
Paul Goins

--

Error in make on ECL 10.4.1:

gcc -DECLDIR=\/usr/local/lib/ecl-10.4.1\ -I. 
-Ic:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build 
-I/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c -I../ecl/gc -DECL_API 
-DECL_NO_LEGACY   -g -O2   -D_THREAD_SAFE -Dmingw32 -c -o file.o tmp.c
In file included from 
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/unistd.h:13:0,
  from 
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:29:
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:95:2: 
error: expected identifier or '(' before '{' token
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:95:16: 
error: expected identifier or '(' before 'void'
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:100:2: 
error: conflicting types for 'GC_beginthreadex'
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build/ecl/gc/gc.h:1049:21: 
note: previous declaration of 'GC_beginthreadex' was here
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
'ecl_off_t_to_integer':
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4813:4: warning: 
right shift count = width of type
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
'ecl_integer_to_off_t':
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4844:8: warning: 
left shift count = width of type
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
'not_a_file_stream':
c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4890:2: warning: 
function declared 'noreturn' has a 'return' statement
make[2]: *** [file.o] Error 1
make[2]: Leaving directory 
`/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build/c'
make[1]: *** [libeclmin.a] Error 2
make[1]: Leaving directory 
`/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build'
make: *** [all] Error 2

--

MinGW installation:

MinGW installed via mingw-get-inst-20100909.exe, using the latest
repository catalogues during installation.  All components except the
MSYS System Builder were installed.

(If there's a specific version of MinGW which is known to work, please
let me know what version and I will try it instead.)

Log:

 Pre-inst
 

 Installing:
   C Compiler
   C++ Compiler
   Fortran Compiler
   ObjC Compiler
   Ada Compiler
   MSYS Basic System
   MinGW Developer Toolkit

 Downloading latest repository catalogues

 Destination location:
   C:\MinGW

 Package download log
 

 downloading: mingwrt-3.18-mingw32-dll.tar.gz: 8122 b
 downloading: libgmp-5.0.1-1-mingw32-dll-10.tar.lzma: 159027 b
 downloading: libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma: 44 b
 downloading: libpthread-2.8.0-3-mingw32-dll-2.tar.lzma: 20862 b
 downloading: pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma: 13727 b
 downloading: libgomp-4.5.0-1-mingw32-dll-1.tar.lzma: 17170 b
 downloading: libmpc-0.8.1-1-mingw32-dll-2.tar.lzma: 24146 b
 downloading: libssp-4.5.0-1-mingw32-dll-0.tar.lzma: 15900 b
 downloading: libgcc-4.5.0-1-mingw32-dll-1.tar.lzma: 41185 b
 downloading: w32api-3.15-1-mingw32-dev.tar.lzma: 1128210 b
 downloading: mingwrt-3.18-mingw32-dev.tar.gz: 568649 b
 downloading: binutils-2.20.51-1-mingw32-bin.tar.lzma: 3097316 b
 downloading: libexpat-2.0.1-1-mingw32-dll-1.tar.gz: 62787 b
 

[Ecls-list] ECL HEAD now compiles Embedded Qt Lisp

2010-10-29 Thread Polos Ruetz
Just letting you know that the Embedded Qt Lisp EQL
(http://gitorious.org/eql/eql) now compiles fine with the current ECL
HEAD.

(For the interested: I needed to insert the macro definition from
SERVE-EVENT:WITH-FD-HANDLER in the file src/lisp/ini.lisp, otherwise
it didn't compile. Since I do some non standard things in the EQL
tool, this hack seems necessary to make the compiler aware of the
above mentioned macro.)

Paul

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Gabriel Dos Reis
On Fri, Oct 29, 2010 at 8:48 AM, Paul Goins gene...@vultaire.net wrote:
 Hi,

 New to the list, so please forgive me if I've missed a thread that
 covers this.

 I'm trying to compile ECL 10.4.1 under Windows 7 64-bit.
 Unfortunately, I'm having problems, and the Windows with
 Mingw/Cygwin section of the reference guide is totally blank, so I
 thought I should ask here.

 (Note: already read some previous comments about 64-bit support.  I'm
 just trying to build a 32-bit ECL via 32-bit MinGW, so don't worry,
 I'm not barking up *that* tree.  However, the OS *is* 64-bit.)

 1. I grabbed the CVS version of the Boehm GC.  Built it successfully
 using ./configure  make  make install.  (7.1 failed to compile
 via MSys in this way.)

 2. I tried to ./configure and make ECL.  This did not pan out...

    ./configure --enable-threads=yes
    # no problem, but did give some warnings:
    #   configure: Configuring included GMP library:
    #   configure: WARNING: you should use --build, --host, --target

Add --enable-boehm=system so that ECL picks up the GC library
you just installed.

PS: I have not been able to build ECL on windows 7, so let me know
how it went.

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Marko Kocić
Just wanted to ask the same question, but you beat me to it :)
I'm using mingw64, Win7 64, similar to you.

I can build gc-7.2-alpha-4 as both 32 and 64 bit, by setting CFLAGS=-mXX flag.
The problem is that gmp on windows could be compiled only as -m32. I
tried gmp-4.3.2 and gmp-5.0.1 and latest mipr and I was able to
compile them only with -m32.
(Does anyone knows gmp compatible lib that can be used instead of gmp on win64?)

If you don't providn -m flag, on our system gcc asumes -m64.

I compiled both gmp and gc with -m32, set CFLAGS for ECL to use -m32,
Compilation went fine until the moment ./ecl_min is invoked. I suppose
the problem is that ./ecl_min uses gcc to compile lisp stuff, but
doesn't set -m32 flag, and gcc asumes -m64 (or something like that, I
don't have access to that box right now)

I tried looking at the build farm trying to see correct flags for this
kind of builds, but the logs were empty.

I hope this helps to further locate the problem.
It would be best if new configure option would be added to allow
choice between 321 and 64 bit compilation mode, or just instructions
how to do it.

Regards,
Marko

On Fri, Oct 29, 2010 at 3:48 PM, Paul Goins gene...@vultaire.net wrote:
 Hi,

 New to the list, so please forgive me if I've missed a thread that
 covers this.

 I'm trying to compile ECL 10.4.1 under Windows 7 64-bit.
 Unfortunately, I'm having problems, and the Windows with
 Mingw/Cygwin section of the reference guide is totally blank, so I
 thought I should ask here.

 (Note: already read some previous comments about 64-bit support.  I'm
 just trying to build a 32-bit ECL via 32-bit MinGW, so don't worry,
 I'm not barking up *that* tree.  However, the OS *is* 64-bit.)

 1. I grabbed the CVS version of the Boehm GC.  Built it successfully
 using ./configure  make  make install.  (7.1 failed to compile
 via MSys in this way.)

 2. I tried to ./configure and make ECL.  This did not pan out...

    ./configure --enable-threads=yes
    # no problem, but did give some warnings:
    #   configure: Configuring included GMP library:
    #   configure: WARNING: you should use --build, --host, --target

    make
    # (This fails; output attached at the end)

  From here, I don't really know how to proceed.

 I don't need to run 10.4.1, but I would really like to get some
 version of ECL running on this system.  If anyone can advise me of
 some way to get some version going, it'd really be appreciated.

 Attached at the bottom is the error from running make, plus notes on
 my MinGW configuration (in case it matters).

 Thanks in advance.

 Best Regards,
 Paul Goins

 --

 Error in make on ECL 10.4.1:

 gcc -DECLDIR=\/usr/local/lib/ecl-10.4.1\ -I. 
 -Ic:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build 
 -I/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c -I../ecl/gc 
 -DECL_API -DECL_NO_LEGACY   -g -O2   -D_THREAD_SAFE -Dmingw32 -c -o file.o 
 tmp.c
 In file included from 
 c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/unistd.h:13:0,
                  from 
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:29:
 c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:95:2: 
 error: expected identifier or '(' before '{' token
 c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:95:16: 
 error: expected identifier or '(' before 'void'
 c:\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include/process.h:100:2: 
 error: conflicting types for 'GC_beginthreadex'
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build/ecl/gc/gc.h:1049:21: 
 note: previous declaration of 'GC_beginthreadex' was here
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
 'ecl_off_t_to_integer':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4813:4: 
 warning: right shift count = width of type
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
 'ecl_integer_to_off_t':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4844:8: 
 warning: left shift count = width of type
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d: In function 
 'not_a_file_stream':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/file.d:4890:2: 
 warning: function declared 'noreturn' has a 'return' statement
 make[2]: *** [file.o] Error 1
 make[2]: Leaving directory 
 `/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build/c'
 make[1]: *** [libeclmin.a] Error 2
 make[1]: Leaving directory 
 `/c/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/build'
 make: *** [all] Error 2

 --

 MinGW installation:

 MinGW installed via mingw-get-inst-20100909.exe, using the latest
 repository catalogues during installation.  All components except the
 MSYS System Builder were installed.

 (If there's a specific version of MinGW which is known to work, please
 let me know what 

Re: [Ecls-list] Big patch

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Fri, Oct 22, 2010 at 5:13 AM, Matthew Mondor mm_li...@pulsar-zone.netwrote:

 GCC 4.1.3 without glibc (but NetBSD-5 using its own libc) do not yet
 support C99 long double math functions.  An initial build failed with
 undefined reference errors to the following l-suffixed long double math
 functions:
 - atanl ceill coshl cosl expl floorl frexpl ldexpl logl sinhl sinl sqrtl
  tanhl tanl


This will be fixed in a set of patches to be uploaded tonight.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Fri, Oct 29, 2010 at 9:40 PM, Marko Kocić marko.ko...@gmail.com wrote:

 I compiled both gmp and gc with -m32, set CFLAGS for ECL to use -m32,
 Compilation went fine until the moment ./ecl_min is invoked. I suppose
 the problem is that ./ecl_min uses gcc to compile lisp stuff, but
 doesn't set -m32 flag, and gcc asumes -m64 (or something like that, I
 don't have access to that box right now)


ECL respects whatever value you supply to CFLAGS or at least they should. It
is not good to hardcode special flags in ECL. If something is needed for
your system, for instance in this case it seems that -m32 is needed, then
adding it at the end of the call to configure as in

./configure --enable-unicode CFLAGS=-m32

should do it. If this does not work and ECL forgets those flags, then it
is a bug that needs to be fixed.

Regarding more generally Win64 support, I have built ECL with Windos64
support using Microsoft's compilers. Indeed this is the regular build in
ECL's test farm whenever it is not off the grid (ecls.sf.net/logs.html). I
was never able to install mingw64 on that box (Windows Server 2008) so I
really do not know whether the compiler builds 64 bits executables or not.

In any case, it is been one month since I looked at the Windows port and as
I said our test

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Gabriel Dos Reis
On Fri, Oct 29, 2010 at 12:48 PM, Paul Goins gene...@vultaire.net wrote:
 Hello,

 On 10/29/2010 11:43 PM, Gabriel Dos Reis wrote:
 Add --enable-boehm=system so that ECL picks up the GC library
 you just installed.

 PS: I have not been able to build ECL on windows 7, so let me know
 how it went.

 Thanks Gabriel.  Okay, this was rather encouraging.  I can't quite
 compile completely, but I got much further.

 This time, the configure line was:

    LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include \
        ./configure --enable-threads=yes --enable-boehm=system

 The LDFLAGS and CPPFLAGS specs were necessary to pick up the GC lib;
 configure failed without them.

yeah.


 Info: resolving _GC_dont_gc by linking to __imp__GC_dont_gc (auto-import)
 Info: resolving _GC_oom_fn by linking to __imp__GC_oom_fn (auto-import)
 Info: resolving _GC_no_dls by linking to __imp__GC_no_dls (auto-import)
 Info: resolving _GC_all_interior_pointers by linking to
 __imp__GC_all_interior_pointers (auto-import)
 Info: resolving _GC_time_limit by linking to __imp__GC_time_limit
 (auto-import)
 Info: resolving _GC_push_other_roots by linking to
 __imp__GC_push_other_roots (auto-import)
 Info: resolving _GC_start_call_back by linking to __imp__GC_start_call_back
 (auto-import)
 Info: resolving _GC_java_finalization by linking to
 __imp__GC_java_finalization (auto-import)
 Info: resolving _GC_print_stats by linking to __imp__GC_print_stats
 (auto-importc:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe:
 warning: auto-importing has been activated without --enable-auto-import
 specified on the command line.
 This should work unless it involves constant data structures referencing
 symbols from auto-imported DLLs.
 libeclmin.a(threads.o): In function `ecl_import_current_thread':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:248:
 undefined reference to `GC_register_my_thread'
 libeclmin.a(threads.o): In function `mp_process_enable':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:408:
 undefined reference to `gc_createthr...@24'
 libeclmin.a(threads.o): In function `ecl_release_current_thread':
 c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:280:
 undefined reference to `GC_unregister_my_thread)

It sounds as if tECL is able to pick up the GC library but only a few
symbols are missing.  When you configured, did ECL really report
that it was building a 32-bit program?

-- Gaby

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] ECL HEAD now compiles Embedded Qt Lisp

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Fri, Oct 29, 2010 at 4:34 PM, Polos Ruetz polos.ru...@gmail.com wrote:

 Just letting you know that the Embedded Qt Lisp EQL
 (http://gitorious.org/eql/eql) now compiles fine with the current ECL
 HEAD.


Great! Thanks for reporting return to normality :-)


 (For the interested: I needed to insert the macro definition from
 SERVE-EVENT:WITH-FD-HANDLER in the file src/lisp/ini.lisp, otherwise
 it didn't compile. Since I do some non standard things in the EQL
 tool, this hack seems necessary to make the compiler aware of the
 above mentioned macro.)


Did you name it serve-event:with-fd-handler? Did you use (require
'serve-event) before building the library? One may list serve-event and
sockets among the modules that are linked together with ECL using
--with-sockets=builtin --with-serve-event=builtin etc etc

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Gabriel Dos Reis
On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić marko.ko...@gmail.com wrote:
 Just wanted to ask the same question, but you beat me to it :)
 I'm using mingw64, Win7 64, similar to you.

I have been using mingw64, windows 7 64-bit, and I have not been able
build full ECL.  However, I can build ecl_min.exe, but it crashes when
executed.


 I can build gc-7.2-alpha-4 as both 32 and 64 bit, by setting CFLAGS=-mXX 
 flag.
 The problem is that gmp on windows could be compiled only as -m32. I
 tried gmp-4.3.2 and gmp-5.0.1 and latest mipr and I was able to
 compile them only with -m32.
 (Does anyone knows gmp compatible lib that can be used instead of gmp on 
 win64?)

That is weird.  I am able to build both GC and GMP as 64-bit libraries.
Make sure that you're using the mingw64/GCC version that defaults to 64-bit.
(they distribute two sets of compilers with different default.)

-- Gaby

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Gabriel Dos Reis
On Fri, Oct 29, 2010 at 3:20 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:

 Regarding more generally Win64 support, I have built ECL with Windos64
 support using Microsoft's compilers. Indeed this is the regular build in
 ECL's test farm whenever it is not off the grid (ecls.sf.net/logs.html). I
 was never able to install mingw64 on that box (Windows Server 2008) so I
 really do not know whether the compiler builds 64 bits executables or not.
 In any case, it is been one month since I looked at the Windows port and as
 I said our test
 Juanjo

I'm reading this as suggesting that the build problem I am having would be
confined to mingw64 port only.

What was your issue with the mingw64 installation? (Did you use the
auto installer?)

-- Gaby

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Marko Kocić
On Fri, Oct 29, 2010 at 10:28 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
 On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić marko.ko...@gmail.com wrote:
 Just wanted to ask the same question, but you beat me to it :)
 I'm using mingw64, Win7 64, similar to you.

 I have been using mingw64, windows 7 64-bit, and I have not been able
 build full ECL.  However, I can build ecl_min.exe, but it crashes when
 executed.


 I can build gc-7.2-alpha-4 as both 32 and 64 bit, by setting CFLAGS=-mXX 
 flag.
 The problem is that gmp on windows could be compiled only as -m32. I
 tried gmp-4.3.2 and gmp-5.0.1 and latest mipr and I was able to
 compile them only with -m32.
 (Does anyone knows gmp compatible lib that can be used instead of gmp on 
 win64?)

 That is weird.  I am able to build both GC and GMP as 64-bit libraries.
 Make sure that you're using the mingw64/GCC version that defaults to 64-bit.
 (they distribute two sets of compilers with different default.)

Which version of GMP you compiled as 64bit, and which MingW
distribuition you use? Mine defaults to 64, but when building gmp it
builds only 32 bit version, and fail when I try to set ABI=64 or -m64.
I cnn't check which mingw64 distribution I was using right now, but
think it was the one fro tdragon (or something).

 -- Gaby


--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Fri, Oct 29, 2010 at 10:30 PM, Gabriel Dos Reis 
g...@integrable-solutions.net wrote:

 I'm reading this as suggesting that the build problem I am having would be
 confined to mingw64 port only.


I don't know. I may have broken something along the way, but last thing I
remember was 64-bit was building fine.


 What was your issue with the mingw64 installation? (Did you use the
 auto installer?)


I did not find such a thing. All I found were several mingw64 packages and
various naming conventions for them, no msys and thus no apparent support
for Unix-like builds and an overall lack of instructions. It was pretty
frustrating and I gave up at some point, installing mingw32+msys, which I
knew how to find.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] unknown symbol: mp::interrupt-process / We cannot use the mmap code without siginfo

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Thu, Oct 28, 2010 at 8:54 PM, Dr. David Kirkby
david.kir...@onetel.netwrote:

 I'm having a hard time on Solaris and OpenSolaris building the libecl.so
 library
 without text relocations against non-writable segments. This basically
 makes the
 ECL library unusable on 64-bit Solaris/OpenSolaris.


I know. I am slowly progressing through the list of bug reports.


 Hence I'm trying to build the latest git snapshot (downloaded around 1900
 GMT on
 28th October 2010) using the Sun compiler. But the Sun compiler will not
 compile
 this - it is failing with:

 Unknown symbol: mp::interrupt-process


You have hit some ugly point between commits. Bad luck :-)


 line 97: #error: We cannot use the mmap code without siginfo


mmap is used in ECL to help in delaying interrupts. The trick is simple: ECL
gets an interrupt while executing a C function that can not be interrupted,
it marks (using mmap) the Lisp environment as read-only, ECL tries to write
to the environment after the C function finished, this causes a signal and
now it can be processed together with the pending interrupts. But this only
works when mmap implements interrupts with information.

I am really surprised that the Sun platform does not support SA_SIGINFO :-/
Would one need additional compiler flags to allow the headers provide this
facility?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Gabriel Dos Reis
On Fri, Oct 29, 2010 at 3:34 PM, Juan Jose Garcia-Ripoll
juanjose.garciarip...@googlemail.com wrote:

 I did not find such a thing. All I found were several mingw64 packages and
 various naming conventions for them, no msys and thus no apparent support
 for Unix-like builds and an overall lack of instructions. It was pretty
 frustrating and I gave up at some point, installing mingw32+msys, which I
 knew how to find.

1. Install msys as usual (yes 32-bit, there is no 64-bit at the
moment, and that won't
   happen anytime soon.)  It works perfectly for both 32-bit and 64-bit.

2. Download and install mingw64 -- use the automated installation (anything else
is a nightmare, at least from my perspective.)

 http://tdm-gcc.tdragon.net/download

There are two versions: (a) one that defaults to 32-bit, but can
also generate code on demand;
 (b) one that defaults to 64-bit, but can generate 32-bit on demand.
I use the latter.

3. You should be good to go.


-- Gaby

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Revisiting locks and signals

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Tue, Oct 26, 2010 at 5:54 PM, Waldek Hebisch hebi...@math.uni.wroc.plwrote:

 I think it is reasonable to ignore POSIX restrictions.  POSIX is mostly
 a C API standard, so it is affected by limitations of C library.


... which is what ECL uses internally! This is not SBCL, and even they do
not have everything under control


 And the standard due to political pressure has to accomodate
 essentially obsolete systems.  However, AFAIK at the system call
 level on most Unix system there is no problem: one may call system
 calls from signal handler or longjmp outside.  There may be problem
 with locking in the C library, but C libraries are getting better.


I do not believe this. C libraries get better in terms of multithreading
support and locking between threads, but they do not support async-signal
safety. GNU libc explicitely speaks against it as do  other vendors that
follow POSIX. We do have to take this seriously

So, I think that ECL should look at capabilites provided by popular
 system and base on that (possibly declaring that some functionality
 is absent on less popular systems).


The problem with signals and interrupts is that the behaviour we would like
(arbitrary interruptions are ok, arbitrary code is, too) is not something
*provided*. Something provided is a behavior that one can rely on, not the
current status of things that may or may not work.

Look at it from a reasonable point of view: it is impossible to write code
that is async-signal-safe and allows arbitrary interruptions at
unpredictable times. This may happen in the middle of a slot write or read,
or while modifying a list, or while reading from a file (as in FILE) which
is left in a locked state (and thus the signal handler code can not use the
file), etc, etc.

The only way to avoid those problems within the optimistic way of coding is
to switch on and off interrupts all the time, but if one looks carefully at
the code, then the places where the ON status is feasible is a very small
fraction of the code.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] ECL HEAD now compiles Embedded Qt Lisp

2010-10-29 Thread Polos Ruetz
2010/10/29, Juan Jose Garcia-Ripoll juanjose.garciarip...@googlemail.com:
 Did you name it serve-event:with-fd-handler? Did you use (require
 'serve-event) before building the library? One may list serve-event and
 sockets among the modules that are linked together with ECL using
 --with-sockets=builtin --with-serve-event=builtin etc etc

Thanks for the hints! I named it serve-event:with-fd-handler, yes, but
I didn't do any require or similar...

In short: I saw this nice possibility to add an interactive top-level
using serve-event (at least for Unix based OSs, even without SLIME),
and simply did some brute-force to make it work.
Today I tried to find the reason of the compile failure with current
ECL, and it was in fact quite trivial...

I will do some revision and clean up some parts.

Paul

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Revisiting locks and signals

2010-10-29 Thread Juan Jose Garcia-Ripoll
Mathew, let me try to explain again what is the problem and a possible
operation model.

First of all a reminder of how I name things (which may not be compatible
with usual standards :-). Compiled programs may receive interrupts or
signals which may be originated by the operating system or by other
situations. I see only these scenarios for interrupts:

1* Inter-process communication.
2* Inter-thread communication
3* Serious computation errors: SIGSEGV, SIGBUS
4* Not so serious errors: SIGFPE
5* Interruption of code as with Ctrl-C. I see these reasons
  6- Interrupt rroneous code with infinite loops
  7- Interrupt deadlocked code
  8- I/O operations that take too long
  9- Interrupt as a way to debug / inspect a thread
(Feel free to add more to the list)

The problematic begins when deciding how the program reacts to these
interrupts. C libraries typically allow two ways of working:

i) the interrupt is delivered at any time, user code is stopped and an
appropriate handler is executed. Since the interrupt may happen almost at
any part of the code, the signal handler can only perform simple tasks that
do not conflict with whatever was being done. In particular many resources
(locks, files, etc) may be left in an inconsistent state during the signal.

ii) the program has a thread that waits for those interrupts. In this case
it is like reading from a file a list of events. Things are safe and ok for
handling, but not all interrupts can be waited for (see 3, 4 or the group 5)

Let us, as an exercise, assume that ECL runs with most interrupts disabled.
In other words, the signal handlers in an ECL thread can only perform
trivial tasks and we have an optional thread implementing what point (ii)
above says.

The first two situations (1,2, typically implemented via INTERRUPT-PROCESS)
can be eliminated or enforced out. There are better ways to do
inter-process communication than signals and most kind of such signals can
be automatically translated into other communication means (SIGPIPE -
errno, user signal - pipe message or socket...)

The situation 3 is serious and should be handled accordingly, for the
affected thread may not continue to execute normally. Possible responses are
a) suspending the thread and opening a new thread with a debugger
b) jumping to an outer point of code (unsafe)
c) killing the thread
Out of these b) and c) are deemed unsafe but we are already in a muddy land
when a SIGSEGV is delivered.

The case 4 can be handled similarly as 3 but we can complement with an
additional option, d) ignore floating point signals and continue, which is
safe and ok.

Case 8 is ok. Getting an interrupt delivered during I/O operations is safe.
We may enforce I/O operations to abort on receiving an interrupt even
without using signal handlers. Calls to READ or PRINT will recognize that
the I/O operation failed, look at the list of pending interrupts and invoke
the appropriate error handlers.

Case 9 is also simple. One may reserve a signal to indicate thread
suspension. In that case th signal handler is simple and just waits for a
resume signal, allowing another thread to inspect its environment and
gather information. This can be done in a POSIX-compatible way if the
debugger does not want to inject or execute additional code in the
suspended thread.

Cases 6 and 7 are more complicated. The problems with infinite loops and
deadlocks (infinitely waiting mutexes), is that we would like be able to
break the offending code (as with Ctrl-C) without quitting the lisp image.
This means we need a way to stop a thread, typically forcing it to jump to
an outer point. There are various ways to implement such a SIGINT handler
a* The SIGINT handler always jumps to an outer point in the lisp code.
b* Similar as a but only when the function is marked interruptible.
c* Similar as a but the thread is paused and in a separate thread a
debugger is started, from which we can decide whether to jump to an outer
point.
d* The SIGINT handler queues the interrupt until it is explicitly checked
for.
Only the last alternative is POSIX-compliant, but it is very costly, because
it forces us to add interrupt checks every now and then, as in GOTOs, and
does not solve the problem of deadlocks.

So it seems it would be possible to execute ECL threads that run with
interrupts mostly disabled. Signal handlers would do very little, and only
in the undesirable situations would they allow jumping to outer parts of the
code or canceling the thread (unwinding any possible operations), but that
would be done placing the burden of possible side-effects on the user.

This would have a couple of positive side effects. One would be that it
would make coding a lot simpler. Most of ECL right now is not
async-signal-safe and it will probably never be. Lisp code also can't be
async-safe. Instead of revisiting all the code, filling it with
ecl_disable_interrupt() calls, which are costly, we would be able to get a
cleaner Lispwhere everything is assumed to 

Re: [Ecls-list] unknown symbol: mp::interrupt-process / We cannot use the mmap code without siginfo

2010-10-29 Thread Juan Jose Garcia-Ripoll
On Thu, Oct 28, 2010 at 8:54 PM, Dr. David Kirkby
david.kir...@onetel.netwrote:

 I'm having a hard time on Solaris and OpenSolaris building the libecl.so
 library
 without text relocations against non-writable segments. This basically
 makes the
 ECL library unusable on 64-bit Solaris/OpenSolaris.

 I know the same issue arises with 3 library used by the stats package R if
 one
 uses gcc, but the problem disappears if one uses the Sun compiler.

 Hence I'm trying to build the latest git snapshot (downloaded around 1900
 GMT on
 28th October 2010) using the Sun compiler.


David, I have managed to build ECL in fulvia, which is running Solaris

-bash-3.00$ uname -a
SunOS fulvia 5.10 Generic_127128-11 i86pc i386 i86pc

using exclusively Sun's compiler and ECL's git sources

-bash-3.00$ CC=cc ./configure --prefix=$HOME --enable-slow-config
...
-bash-3.00$ cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
usage: cc [ options] files.  Use 'cc -flags' for details

Can you tell me via private email which was the machine running
Solaris/x86_64?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys

2010-10-29 Thread Paul Goins
Hello,

On 10/30/2010 5:24 AM, Gabriel Dos Reis wrote:
  On Fri, Oct 29, 2010 at 12:48 PM, Paul Goinsgene...@vultaire.net  wrote:
  Info: resolving _GC_dont_gc by linking to __imp__GC_dont_gc (auto-import)
  Info: resolving _GC_oom_fn by linking to __imp__GC_oom_fn (auto-import)
  Info: resolving _GC_no_dls by linking to __imp__GC_no_dls (auto-import)
  Info: resolving _GC_all_interior_pointers by linking to
  __imp__GC_all_interior_pointers (auto-import)
  Info: resolving _GC_time_limit by linking to __imp__GC_time_limit
  (auto-import)
  Info: resolving _GC_push_other_roots by linking to
  __imp__GC_push_other_roots (auto-import)
  Info: resolving _GC_start_call_back by linking to __imp__GC_start_call_back
  (auto-import)
  Info: resolving _GC_java_finalization by linking to
  __imp__GC_java_finalization (auto-import)
  Info: resolving _GC_print_stats by linking to __imp__GC_print_stats
  (auto-importc:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe:
  warning: auto-importing has been activated without --enable-auto-import
  specified on the command line.
  This should work unless it involves constant data structures referencing
  symbols from auto-imported DLLs.
  libeclmin.a(threads.o): In function `ecl_import_current_thread':
  c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:248:
  undefined reference to `GC_register_my_thread'
  libeclmin.a(threads.o): In function `mp_process_enable':
  c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:408:
  undefined reference to `gc_createthr...@24'
  libeclmin.a(threads.o): In function `ecl_release_current_thread':
  c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:280:
  undefined reference to `GC_unregister_my_thread)
 
  It sounds as if tECL is able to pick up the GC library but only a few
  symbols are missing.  When you configured, did ECL really report
  that it was building a 32-bit program?

I logged the configure... it looks like it.  Things do look slightly
different between the GC configure and the ECL configure though;
namely that ECL has the target as pentium3 and Boehm as i686.

ECL:

Switching to directory `build' to continue configuration.
checking build system type... pentium3-pc-mingw32
checking host system type... pentium3-pc-mingw32
[...]
checking for architecture... PENTIUM3
checking for software type... mingw32 /
[...]
[...]
using ABI=32
   CC=gcc 
   CFLAGS=-g -O2  
   CPPFLAGS=-I/usr/local/include
   MPN_PATH= x86/p6/p3mmx x86/p6/mmx x86/p6 x86 generic

Boehm GC:

checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32

I can send the full configure logs from both if desired; I have them
saved.

- Paul

--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps  games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list