clisp-devel — closed list for developers and testers

New Cygwin maintainer

[Ken B. <kb...@co...>]

I have just taken over from Reini Urban as clisp maintainer for Cygwin. 
  I can build the tip of the Mercurial repository on both 32-bit and 
64-bit Cygwin [*], but several patches are required (not all of which 
are Cygwin-specific).  I would like to get these patches applied.  How 
should I proceed?  Should I just send patches to this list?  Or do you 
prefer bug reports with patches attached?

BTW, I just took a quick glance at the bug tracker and saw that some of 
my patches fix bugs that have been previously reported.  I didn't do a 
thorough search.

Ken Brown

[*] The 64-bit build is somewhat limited at the moment for several reasons:

1. ffcall has not been ported to 64-bit Cygwin.

2. libsigsegv has not been ported to 64-bit Cygwin.

3. I ran into a gcc problem when trying to build several of the modules 
(including regexp):

     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939


On the other hand, one Cygwin user reported that he had successfully 
built Macsyma using my 64-bit build, so apparently it's of some use in 
spite of the limitations.

Re: Clisp doesn't work on 64 bit machines?

[Blake M. <bl...@mc...>]

Surprisingly, that did fix the problem.    Thanks!

On Mon, Feb 16, 2015 at 3:32 PM, Vladimir Tzankov <vtz...@gm...>
wrote:

> Sorry, should have asked first whether you link with libffcall.
>
> Anyway I strongly suggest to do so on 64 bit linux builds since you are
> probably hitting an old issue: http://sourceforge.net/p/clisp/bugs/447/
>
> Vlad
>
> On Mon, Feb 16, 2015 at 11:07 PM, Blake McBride <bl...@mc...>
> wrote:
>
>> I appreciate your help, but I think it may not apply because I am no
>> linking ffi.  i.e.:
>>
>> Configure findings:
>>   FFI:        no (user requested: default)
>>   readline:   yes (user requested: default)
>>   libsigsegv: yes
>>
>> I can't even find any original libs for FFI on my machines.  Do you think
>> this is still the problem?
>>
>> Thanks!
>>
>> Blake
>>
>>
>> On Mon, Feb 16, 2015 at 1:38 PM, Vladimir Tzankov <vtz...@gm...>
>> wrote:
>>
>>> This is probably related to libffcall:
>>> https://bugs.launchpad.net/ubuntu/+source/ffcall/+bug/274951
>>>
>>> Try building against libffcall head instead to the one that comes with
>>> your linux distro.
>>> http://savannah.gnu.org/projects/libffcall/
>>>
>>> Vlad
>>>
>>>
>>>
>>> On Sun, Feb 15, 2015 at 4:57 AM, Blake McBride <bl...@mc...>
>>> wrote:
>>>
>>>> Greetings,
>>>>
>>>> I built the latest CLISP from the HG repository on two of my 64 bit
>>>> Linux machines.  Both built fine but when I do a 'make check' I get what is
>>>> shown below.
>>>>
>>>> This bug also makes it so slime doesn't work.  I checked the Internet.
>>>> Several people reported the same problem.  There is even a trouble ticket
>>>> from 2011, yet I haven't found a solution described anywhere.  Is there a
>>>> fix for this or should I drop CLISP?
>>>>
>>>> Thanks.
>>>>
>>>> Blake McBride
>>>>
>>>>
>>>> ---
>>>>
>>>> ...
>>>> #<SOCKET-SERVER 127.0.0.1:43466>
>>>> EQUAL-OK: ("0.0.0.0" "127.0.0.1" "0.0.0.0" "127.0.0.1")
>>>> (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER)))
>>>> (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL
>>>> "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL
>>>> :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO
>>>> (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO)
>>>> (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL
>>>> (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE
>>>> "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND)))
>>>> (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR)
>>>> (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
>>>> [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
>>>> [OS-ERROR]: OS-ERROR(32): Broken pipe
>>>> READ-CHAR
>>>> [SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED
>>>> SOCKET-STREAM CHARACTER 0.0.0.0:59263> has reached its end
>>>>
>>>> EQUAL-OK: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
>>>> (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))
>>>>
>>>> *** - handle_fault error2 ! address = 0x0 not in
>>>> [0x334031000,0x33439c560) !
>>>> SIGSEGV cannot be cured. Fault address = 0x0.
>>>> GC count: 649
>>>> Space collected by GC: 921236520
>>>> Run time: 33 873913
>>>> Real time: 38 950692
>>>> GC time: 5 875712
>>>> Permanently allocated: 152992 bytes.
>>>> Currently in use: 7823928 bytes.
>>>> Free space: 8 bytes.
>>>> make[1]: *** [tests] Segmentation fault
>>>> make[1]: Leaving directory `/home/blake/Backup/clisp/src/tests'
>>>> make: *** [check-tests] Error 2
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>>> your
>>>> hub for all things parallel software development, from weekly thought
>>>> leadership blogs to news, videos, case studies, tutorials and more.
>>>> Take a
>>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> clisp-devel mailing list
>>>> cli...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>>>>
>>>>
>>>
>>
>

Re: Clisp doesn't work on 64 bit machines?

[Vladimir T. <vtz...@gm...>]

Sorry, should have asked first whether you link with libffcall.

Anyway I strongly suggest to do so on 64 bit linux builds since you are
probably hitting an old issue: http://sourceforge.net/p/clisp/bugs/447/

Vlad

On Mon, Feb 16, 2015 at 11:07 PM, Blake McBride <bl...@mc...> wrote:

> I appreciate your help, but I think it may not apply because I am no
> linking ffi.  i.e.:
>
> Configure findings:
>   FFI:        no (user requested: default)
>   readline:   yes (user requested: default)
>   libsigsegv: yes
>
> I can't even find any original libs for FFI on my machines.  Do you think
> this is still the problem?
>
> Thanks!
>
> Blake
>
>
> On Mon, Feb 16, 2015 at 1:38 PM, Vladimir Tzankov <vtz...@gm...>
> wrote:
>
>> This is probably related to libffcall:
>> https://bugs.launchpad.net/ubuntu/+source/ffcall/+bug/274951
>>
>> Try building against libffcall head instead to the one that comes with
>> your linux distro.
>> http://savannah.gnu.org/projects/libffcall/
>>
>> Vlad
>>
>>
>>
>> On Sun, Feb 15, 2015 at 4:57 AM, Blake McBride <bl...@mc...>
>> wrote:
>>
>>> Greetings,
>>>
>>> I built the latest CLISP from the HG repository on two of my 64 bit
>>> Linux machines.  Both built fine but when I do a 'make check' I get what is
>>> shown below.
>>>
>>> This bug also makes it so slime doesn't work.  I checked the Internet.
>>> Several people reported the same problem.  There is even a trouble ticket
>>> from 2011, yet I haven't found a solution described anywhere.  Is there a
>>> fix for this or should I drop CLISP?
>>>
>>> Thanks.
>>>
>>> Blake McBride
>>>
>>>
>>> ---
>>>
>>> ...
>>> #<SOCKET-SERVER 127.0.0.1:43466>
>>> EQUAL-OK: ("0.0.0.0" "127.0.0.1" "0.0.0.0" "127.0.0.1")
>>> (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER)))
>>> (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL
>>> "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL
>>> :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO
>>> (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO)
>>> (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL
>>> (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE
>>> "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND)))
>>> (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR)
>>> (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
>>> [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
>>> [OS-ERROR]: OS-ERROR(32): Broken pipe
>>> READ-CHAR
>>> [SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED
>>> SOCKET-STREAM CHARACTER 0.0.0.0:59263> has reached its end
>>>
>>> EQUAL-OK: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
>>> (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))
>>>
>>> *** - handle_fault error2 ! address = 0x0 not in
>>> [0x334031000,0x33439c560) !
>>> SIGSEGV cannot be cured. Fault address = 0x0.
>>> GC count: 649
>>> Space collected by GC: 921236520
>>> Run time: 33 873913
>>> Real time: 38 950692
>>> GC time: 5 875712
>>> Permanently allocated: 152992 bytes.
>>> Currently in use: 7823928 bytes.
>>> Free space: 8 bytes.
>>> make[1]: *** [tests] Segmentation fault
>>> make[1]: Leaving directory `/home/blake/Backup/clisp/src/tests'
>>> make: *** [check-tests] Error 2
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> clisp-devel mailing list
>>> cli...@li...
>>> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>>>
>>>
>>
>

Re: Clisp doesn't work on 64 bit machines?

[Blake M. <bl...@mc...>]

I appreciate your help, but I think it may not apply because I am no
linking ffi.  i.e.:

Configure findings:
  FFI:        no (user requested: default)
  readline:   yes (user requested: default)
  libsigsegv: yes

I can't even find any original libs for FFI on my machines.  Do you think
this is still the problem?

Thanks!

Blake


On Mon, Feb 16, 2015 at 1:38 PM, Vladimir Tzankov <vtz...@gm...>
wrote:

> This is probably related to libffcall:
> https://bugs.launchpad.net/ubuntu/+source/ffcall/+bug/274951
>
> Try building against libffcall head instead to the one that comes with
> your linux distro.
> http://savannah.gnu.org/projects/libffcall/
>
> Vlad
>
>
>
> On Sun, Feb 15, 2015 at 4:57 AM, Blake McBride <bl...@mc...> wrote:
>
>> Greetings,
>>
>> I built the latest CLISP from the HG repository on two of my 64 bit Linux
>> machines.  Both built fine but when I do a 'make check' I get what is shown
>> below.
>>
>> This bug also makes it so slime doesn't work.  I checked the Internet.
>> Several people reported the same problem.  There is even a trouble ticket
>> from 2011, yet I haven't found a solution described anywhere.  Is there a
>> fix for this or should I drop CLISP?
>>
>> Thanks.
>>
>> Blake McBride
>>
>>
>> ---
>>
>> ...
>> #<SOCKET-SERVER 127.0.0.1:43466>
>> EQUAL-OK: ("0.0.0.0" "127.0.0.1" "0.0.0.0" "127.0.0.1")
>> (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER)))
>> (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL
>> "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL
>> :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO
>> (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO)
>> (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL
>> (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE
>> "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND)))
>> (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR)
>> (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
>> [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
>> [OS-ERROR]: OS-ERROR(32): Broken pipe
>> READ-CHAR
>> [SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED
>> SOCKET-STREAM CHARACTER 0.0.0.0:59263> has reached its end
>>
>> EQUAL-OK: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
>> (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))
>>
>> *** - handle_fault error2 ! address = 0x0 not in
>> [0x334031000,0x33439c560) !
>> SIGSEGV cannot be cured. Fault address = 0x0.
>> GC count: 649
>> Space collected by GC: 921236520
>> Run time: 33 873913
>> Real time: 38 950692
>> GC time: 5 875712
>> Permanently allocated: 152992 bytes.
>> Currently in use: 7823928 bytes.
>> Free space: 8 bytes.
>> make[1]: *** [tests] Segmentation fault
>> make[1]: Leaving directory `/home/blake/Backup/clisp/src/tests'
>> make: *** [check-tests] Error 2
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> clisp-devel mailing list
>> cli...@li...
>> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>>
>>
>

Re: Clisp doesn't work on 64 bit machines?

[Vladimir T. <vtz...@gm...>]

This is probably related to libffcall:
https://bugs.launchpad.net/ubuntu/+source/ffcall/+bug/274951

Try building against libffcall head instead to the one that comes with your
linux distro.
http://savannah.gnu.org/projects/libffcall/

Vlad



On Sun, Feb 15, 2015 at 4:57 AM, Blake McBride <bl...@mc...> wrote:

> Greetings,
>
> I built the latest CLISP from the HG repository on two of my 64 bit Linux
> machines.  Both built fine but when I do a 'make check' I get what is shown
> below.
>
> This bug also makes it so slime doesn't work.  I checked the Internet.
> Several people reported the same problem.  There is even a trouble ticket
> from 2011, yet I haven't found a solution described anywhere.  Is there a
> fix for this or should I drop CLISP?
>
> Thanks.
>
> Blake McBride
>
>
> ---
>
> ...
> #<SOCKET-SERVER 127.0.0.1:43466>
> EQUAL-OK: ("0.0.0.0" "127.0.0.1" "0.0.0.0" "127.0.0.1")
> (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER)))
> (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL
> "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL
> :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO
> (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO)
> (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL
> (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE
> "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND)))
> (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR)
> (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
> [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
> [OS-ERROR]: OS-ERROR(32): Broken pipe
> READ-CHAR
> [SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED
> SOCKET-STREAM CHARACTER 0.0.0.0:59263> has reached its end
>
> EQUAL-OK: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
> (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))
>
> *** - handle_fault error2 ! address = 0x0 not in [0x334031000,0x33439c560)
> !
> SIGSEGV cannot be cured. Fault address = 0x0.
> GC count: 649
> Space collected by GC: 921236520
> Run time: 33 873913
> Real time: 38 950692
> GC time: 5 875712
> Permanently allocated: 152992 bytes.
> Currently in use: 7823928 bytes.
> Free space: 8 bytes.
> make[1]: *** [tests] Segmentation fault
> make[1]: Leaving directory `/home/blake/Backup/clisp/src/tests'
> make: *** [check-tests] Error 2
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>
>

Clisp doesn't work on 64 bit machines?

[Blake M. <bl...@mc...>]

Greetings,

I built the latest CLISP from the HG repository on two of my 64 bit Linux
machines.  Both built fine but when I do a 'make check' I get what is shown
below.

This bug also makes it so slime doesn't work.  I checked the Internet.
Several people reported the same problem.  There is even a trouble ticket
from 2011, yet I haven't found a solution described anywhere.  Is there a
fix for this or should I drop CLISP?

Thanks.

Blake McBride


---

...
#<SOCKET-SERVER 127.0.0.1:43466>
EQUAL-OK: ("0.0.0.0" "127.0.0.1" "0.0.0.0" "127.0.0.1")
(MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER)))
(RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL
"(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL
:INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO
(SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO)
(SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL
(MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE
"bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND)))
(HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR)
(PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
[OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
[OS-ERROR]: OS-ERROR(32): Broken pipe
READ-CHAR
[SIMPLE-END-OF-FILE]: READ: input stream #1=#<IO INPUT-BUFFERED
SOCKET-STREAM CHARACTER 0.0.0.0:59263> has reached its end

EQUAL-OK: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE)
(CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111))

*** - handle_fault error2 ! address = 0x0 not in [0x334031000,0x33439c560)
!
SIGSEGV cannot be cured. Fault address = 0x0.
GC count: 649
Space collected by GC: 921236520
Run time: 33 873913
Real time: 38 950692
GC time: 5 875712
Permanently allocated: 152992 bytes.
Currently in use: 7823928 bytes.
Free space: 8 bytes.
make[1]: *** [tests] Segmentation fault
make[1]: Leaving directory `/home/blake/Backup/clisp/src/tests'
make: *** [check-tests] Error 2

TEST-FLOAT-IO-CONSISTENCY failure

[Jerry J. <log...@gm...>]

Greetings,

During the latest clisp build for Fedora Rawhide, a test failure was
encountered in number2 on an ARM platform, namely:

(TEST-FLOAT-IO-CONSISTENCY :FROM 1.0L-3000 :BY 1000 :TO 1.0L3000 :REPEAT 10)
ERROR!! ((-4.295097036180546188L-727 9621443592353920301 -2476 -1))
should be NIL !

If I'm reading the test correctly, that means

(read-from-string (prin1-to-string -4.295097036180546188L-727))

evaluated to something other than -4.295097036180546188L-727, right?
I will try to put together an ARM virtual machine next week and see if
I can gather more information, but I thought I would send a message
here in case there are any known reasons why this test might fail on
an ARM.

Regards,
-- 
Jerry James
http://www.jamezone.org/

clisp 2.49 on tru64/osf 5.1b

[Fausto S. <fau...@gm...>]

Hello all,

I have a problem compiling clisp 2.49 on tru64/osf 5.1b (1GB of RAM)
using native compiler CC (cc -g3 -O2)

Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-003 (sys) cc Driver

I was able to compile successfully clisp 2.33.2 (using gcc 4.1.1 and
--disable-mmap configure option) and now I was trying to compiler a
newer version using the native compiler instead (faster than gcc).

The building process (configured with --disable-mmap and the change to
lispbibl.d for the inclusion of <gllib/stdbool.h> instead of
<stdbool.h>) is fine, until I have this error:

./lisp.run -B . -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -M
interpreted.mem -q -c ../src/compiler.lisp -o ./
;; Compiling file /home/fausap/wrk/clisp-2.49/src/compiler.lisp ...
*** - PRINT: Despite *PRINT-READABLY*, #<ADDRESS #x00300000000A> cannot be
      printed readably.

My ulimit settings are :

core file size               (blocks, -c)      unlimited
data seg size              (kbytes, -d)     496504
file size                       (blocks, -f)       unlimited
max memory size        (kbytes, -m)    496504
open files                    (-n)                 4096
pipe size                     (512 bytes, -p) 8
stack size                   (kbytes, -s)     32768
cpu time                     (seconds, -t)    unlimited
max user processes    (-u)                 256
virtual memory             (kbytes, -v)     4194304

Do you have any hints how to correct this error ?

thanks in advance,
Fausto

Re: mt questions

[shashank <sha...@gm...>]

Okay! Great.

> If we have 'real' cas - testandset should be expressed via it - no need
to keep both.
> If you are using recent gcc - there is: __sync_val_compare_and_swap. This
can be your first attempt at cas - just use it.

Yes, I came across __sync_val_compare_and_swap method. My concern for
asking if we should keep both was since we had to support multiple
compilers.
But its clear now. I'll start right away.

Shashank
---
P.S. -
I hate to disappear. But I spent the past 2-3 days without internet
connection since it
broke due to some construction near my house.
But everything's back to normal. Good to be online now.


On Mon, May 5, 2014 at 6:19 PM, Vladimir Tzankov <vtz...@gm...> wrote:

> testandset is used for spinlock (busy lock) implementation.
> spinlock has two states: 0 - not owned, 1 - owned
>
> from xthread.d comments:
> >> testandset(spinlock) tries to acquire the spinlock. It returns
> >> 0 if it succeeded (i.e. the old value was 0, the new one is != 0).
> >> It returns != 0 if it failed (i.e. the old value was != 0).
>
> So basically testandset is special case of CAS (testandset(place) ==
> cas(place, 0, 1))
>
> If we have 'real' cas - testandset should be expressed via it - no need to
> keep both.
>
> If you are using recent gcc - there is: __sync_val_compare_and_swap. This
> can be your first attempt at cas - just use it.
> #define CAS(place, oldval,
> newval) __sync_val_compare_and_swap((place),(oldval),(newval))
>
> However clisp can (and should) be compiled with any c89 compiler. So we
> need some #ifdefs and asm stuff (like now) for cross platform/compiler
> support.
>
> In the beginning you can go with gcc specific implementation at the
> beginning and concentrate entirely on hash table stuff since this is the
> primary goal of the project.
>
> Vlad
>
>
> On Sun, May 4, 2014 at 7:18 PM, shashank <sha...@gm...> wrote:
>
>> I love your plan.
>> Finally the fun begins :D
>>
>> I'll quickly get on to reading the common lisp and clisp hashtable
>> implementation.Btw just to be clear you're saying, implement cas and use
>> it instead of testandset. Does that mean the existing testandset macros
>> have to go? (i.e. be replaced with cas) or for the new code we should
>> use cas instead of testandset?
>>
>> Shashank
>>
>>
>> On Sun, May 4, 2014 at 12:18 PM, Vladimir Tzankov <vtz...@gm...>wrote:
>>
>>> Let's have kind of plan. Here is what i have in mind.
>>>
>>> * Study common lisp hashtables (
>>> http://www.lispworks.com/documentation/HyperSpec/Body/18_.htm) and
>>> clisp implementation in hashtabl.d (there are few extensions to the above
>>> standard, e.g. weak relations).
>>> * Study and understand lock free hash table (
>>> http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf).
>>> Check clozure implementation. IIRC, you will need cas & mutex for this.
>>> * Implement cas and use it instead of testandset. Required mutex
>>> implementations are available.
>>> * Start coding and replacing hashtabl.d implementation
>>>
>>> Meanwhile you will get common with clisp (some) internals.
>>>
>>> As for you questions:
>>>
>>> 1. Always use mercurial checkout when consulting code. The link above is
>>> to old cvs repo that was not updated for quite some time.
>>> 2. win32 condition variables - it will be nice to use native ones but
>>> this is not the goal of the project. I would not put too much efforts on
>>> this at that stage.
>>> 3. There is no need to have 'full grasp' of mutex internals in order to
>>> use it. package.d is a place to consult for the usage.
>>>
>>> Vlad
>>>
>>
>>
>

Re: mt questions

[shashank <sha...@gm...>]

This is very interesting.

> This is what happens in the sources of clisp, written in .d files, which
> are pre-processed to produce the actual .c intermediary files.

It makes so much sense now, why all the code was written in pre-processed
files. Although I did know
there was supposed to be lot of compile time and template changes made due
to multiple platforms
and additional flags and options.

Thanks! Exchanging emails with all you amazing people provides so much
learning.

---
P.S. -
I hate to disappear. But I spent the past 2-3 days without internet
connection since it broke due to some construction near my house.
Anyway back to normal. Good to be online now.




On Sun, May 4, 2014 at 10:56 PM, Pascal J. Bourguignon <
pj...@in...> wrote:

>
>
> On 04 May 2014, at 19:05, shashank <sha...@gm...> wrote:
>
> > Hey
> >
> > Oh! so that's how its used.
> > Very nicely explained :)
> >
> > Actually I have never seen so many C macros at once and it gets quite
> overwhelming. In the past I have mostly used C for coding algorithms and
> small stuff, for everything else I used python.
> > But this is lovely.
>
> Notice that you can use the C processor on any kind of text, including any
> kind of programming language.
>
> Two examples:
>
> In standard Pascal (as defined in the 70s), a program was made of a single
> file, there were no units or libraries.
> However, you could use #include (and #define, #if, etc if needed), to
> build this single file program using cpp.
>
> Another example, that I have used recently, for a specification document
> where two different objects are specified
> to have similar fields, with only small variants.  The specification for
> the fieds are given in the file rule-actions.txt,
> which contains a few text section in #ifdef / #else / #endif, and a
> Makefile contains rules to generate the two variants:
>
>
> rule-actions-beacon.txt:rule-actions.txt  Makefile
>         @echo "Preprocessing $< for beacons"
>         @cpp -CC -P  -traditional-cpp \
>             -DBEACON \
>             -o rule-actions-beacon.txt rule-actions.txt
>
> rule-actions-geofence.txt:rule-actions.txt  Makefile
>         @echo "Preprocessing $< for geofences"
>         @cpp -CC -P  -traditional-cpp \
>             -UBEACON \
>             -o rule-actions-geofence.txt rule-actions.txt
>
>
> That said, while cpp is almost Turing Complete (if you use it it a loop,
> it becomes Turing Complete), it is still
> quite very rudimentary, and often you will want to write your own specific
> pre-processor.  This is what happens
> in the sources of clisp, written in .d files, which are pre-processed to
> produce the actual .c intermediary files.
>
> This is a very common technique.  A lot of languages began life as C
> pre-processors (Objective-C, C++ (cfront), Pro*C, etc).
>
> —
> __Pascal Bourguignon__
>
>

Fwd: Undeliverable: Re: mt questions

[Pascal J. B. <pj...@in...>]

Shiyaz, you should check your email address, your server stelco.com.mv doesn’t know it...

— 
__Pascal Bourguignon__



Begin forwarded message:

> From: <pos...@st...>
> Subject: Undeliverable: Re: mt questions
> Date: 4 May 2014 09:26:39 GMT+2
> To: <pj...@in...>
> 
> Delivery has failed to these recipients or groups:
> 
> shi...@st...
> The e-mail address you entered couldn't be found. Please check the recipient's e-mail address and try to resend the message. If the problem continues, please contact your helpdesk.
> 
> 
> 
> 
> 
> 
> Diagnostic information for administrators:
> 
> Generating server: stelco.com.mv
> 
> shi...@st...
> #550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##
> 
> Original message headers:
> 
> Received: from EX-EDGE.stelco.local (10.1.1.220) by EX-01.stelco.local
>  (10.1.1.219) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 4 May 2014
>  12:26:38 +0500
> Received: from exchange-pop3-connector.com (10.1.1.220) by
>  EX-EDGE.stelco.local (10.1.1.220) with Microsoft SMTP Server id 14.2.247.3;
>  Sun, 4 May 2014 12:26:26 +0500
> Received: (qmail 3317 invoked by uid 110); 4 May 2014 12:23:38 +0500
> Delivered-To: 82-...@st...
> Received: (qmail 3311 invoked from network); 4 May 2014 12:23:38 +0500
> Received: from mx-sweeper6.dhivehinet.net.mv (HELO sweeper6.dhivehinet.net.mv)
>  (27.114.139.6)  by host02.dhivehinet.net.mv with (DHE-RSA-AES256-SHA
>  encrypted) SMTP; 4 May 2014 12:23:38 +0500
> Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88])
>  by sweeper6.dhivehinet.net.mv with ESMTP id RC4dem56vAEmK3FA (version=TLSv1
>  cipher=AES256-SHA bits=256 verify=NO) for <shi...@st...>;
>  Sun, 04 May 2014 12:23:32 +0500 (MVT)
> Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com)
> 	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)	(envelope-from
>  <cli...@li...>)	id 1WgqlQ-0002Zd-F0; Sun, 04 May
>  2014 07:23:08 +0000
> Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
> 	helo=mx.sourceforge.net)	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim
>  4.76)	(envelope-from <lisp-clisp-devel@m.gmane.org>) id 1WgqlO-0002ZX-Ta	for
>  cli...@li...; Sun, 04 May 2014 07:23:06 +0000
> Received-SPF: None (EX-EDGE.stelco.local: pj...@in... does not
>  designate permitted sender hosts)
> Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
> 	designates 80.91.229.3 as permitted sender)
> 	client-ip=80.91.229.3;
> 	envelope-from=lisp-clisp-devel@m.gmane.org; helo=plane.gmane.org;
> Received: from plane.gmane.org ([80.91.229.3])	by
>  sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)	(Exim
>  4.76) id 1WgqlD-00032j-GO	for cli...@li...; Sun, 04 May
>  2014 07:23:06 +0000
> Received: from list by plane.gmane.org with local (Exim 4.69)	(envelope-from
>  <lisp-clisp-devel@m.gmane.org>) id 1Wgql5-0006nP-5m	for
>  cli...@li...; Sun, 04 May 2014 09:22:47 +0200
> Received: from amontsouris-654-1-97-27.w82-123.abo.wanadoo.fr ([82.123.0.27])
> 	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))	id 1AlnuQ-0007hv-00	for
>  <cli...@li...>; Sun, 04 May 2014 09:22:47 +0200
> Received: from pjb by amontsouris-654-1-97-27.w82-123.abo.wanadoo.fr with
> 	local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00	for
>  <cli...@li...>; Sun, 04 May 2014 09:22:47 +0200
> X-Injected-Via-Gmane: http://gmane.org/
> To: <cli...@li...>
> From: "Pascal J. Bourguignon" <pj...@in...>
> Subject: Re: mt questions
> Date: Sun, 4 May 2014 09:20:41 +0200
> Organization: Informatimago
> Lines: 65
> Message-ID: <87f...@ku...>
> References: <CAH...@ma...>
> 	<CAGGv9DhU+WH-Xu5M+Xrwtmu-+3=nhC...@ma...>
> MIME-Version: 1.0
> X-Complaints-To: us...@ge...
> X-Gmane-NNTP-Posting-Host: amontsouris-654-1-97-27.w82-123.abo.wanadoo.fr
> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA
> 	oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9
> 	033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac
> 	l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR
> 	mV+hO/VvFAAAAABJRU5ErkJggg==
> X-Accept-Language: fr, es, en
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
> Cancel-Lock: sha1:MzQ5NmU4NTc1OWRhZjFiM2M5MzAwNzEzYWYxNjBiY2RkYmQ0N2Q4Mg==
> X-Spam-Score: -2.2 (--)
> X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
> 	See http://spamassassin.org/tag/ for more details.
> 	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
> 	sender-domain
> 	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
> 	no trust [80.91.229.3 listed in list.dnswl.org]
> 	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
> 	-0.0 SPF_PASS               SPF: sender matches SPF record
> 	-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
> 	domain
> X-Headers-End: 1WgqlD-00032j-GO
> X-BeenThere: cli...@li...
> X-Mailman-Version: 2.1.9
> Precedence: list
> List-Id: CLISP developers <clisp-devel.lists.sourceforge.net>
> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/clisp-devel>, 
> 	<mailto:cli...@li...?subject=unsubscribe>
> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=clisp-devel>
> List-Post: <mailto:cli...@li...>
> List-Help: <mailto:cli...@li...?subject=help>
> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/clisp-devel>,
> 	<mailto:cli...@li...?subject=subscribe>
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Errors-To: cli...@li...
> X-Virus-Scanned: by bsmtpd at dhivehinet.net.mv
> Return-Path: pj...@in...
> 
> Reporting-MTA: dns;stelco.com.mv
> Received-From-MTA: dns;EX-EDGE.stelco.local
> Arrival-Date: Sun, 4 May 2014 07:26:38 +0000
> 
> Final-Recipient: rfc822;shi...@st...
> Action: failed
> Status: 5.1.1
> Diagnostic-Code: smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found
> 

Re: mt questions

[Pascal J. B. <pj...@in...>]

shashank <sha...@gm...> writes:

>>> 5.  In [xthread.d, line 99,152] what does #define
> THREADPROC_SIGNATURE do?
>> This is just a syntax sugar to hide win32/posix thread function
> return type.
> Can you elaborate more?


Use: M-x grep RET C-a C-k grep -nH THREADPROC_SIGNATURE *.d RET

It is defined in two #ifdef:

    #if defined(POSIX_THREADS)
    // ...
    #define THREADPROC_SIGNATURE void *
    // ...
    #endif  /* POSIX*_THREADS */

    #if defined(WIN32_THREADS)
    // ...
    #define THREADPROC_SIGNATURE unsigned WINAPI
    // ...
    #endif  /* WIN32_THREADS */



It is used in two functions:

    local THREADPROC_SIGNATURE thread_stub(void *arg)
    local THREADPROC_SIGNATURE mt_main_actions (void *param)


So when we use POSIX_THREADS, those two functions will have the
signature:

    local void * thread_stub(void *arg)
    local void * mt_main_actions (void *param)

returning a pointer, 

but when we use WIN32_THREADS, they will have the signature:

    local unsigned WINAPI thread_stub(void *arg)
    local unsigned WINAPI mt_main_actions (void *param)

returning a unsigned.

This is the basic substitution mechanism of C pre-processor macros.


What we've done here, is to conditionnalize the return type depending on
the kind of threads we use.


Similarly, the other xthread_* macros are defined differently depending
on the kind of thread we use, so that we can write a single source text,
that will be processed and produce a different source program depending
on the kind of thread we use.


-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"

Re: mt questions

[Vladimir T. <vtz...@gm...>]

Let's have kind of plan. Here is what i have in mind.

* Study common lisp hashtables (
http://www.lispworks.com/documentation/HyperSpec/Body/18_.htm) and clisp
implementation in hashtabl.d (there are few extensions to the above
standard, e.g. weak relations).
* Study and understand lock free hash table (
http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf).
Check clozure implementation. IIRC, you will need cas & mutex for this.
* Implement cas and use it instead of testandset. Required mutex
implementations are available.
* Start coding and replacing hashtabl.d implementation

Meanwhile you will get common with clisp (some) internals.

As for you questions:

1. Always use mercurial checkout when consulting code. The link above is to
old cvs repo that was not updated for quite some time.
2. win32 condition variables - it will be nice to use native ones but this
is not the goal of the project. I would not put too much efforts on this at
that stage.
3. There is no need to have 'full grasp' of mutex internals in order to use
it. package.d is a place to consult for the usage.

Vlad

Re: mt questions

[shashank <sha...@gm...>]

hello!

About the lisp mutex implementation. I am just cross checking, is this the
related
definition?
=============================

    typedef struct {
      XRECORD_HEADER
      gcv_object_t xmu_name _attribute_aligned_object_; /* name */
      gcv_object_t xmu_owner _attribute_aligned_object_; /* owner (thread)
*/
      uintL xmu_flags; /* mutex flags - recursive? (by default - no)*/
      uintL xmu_recurse_count; /* how many times we have obtained the mutex
*/
      /* following is pointer to malloc()-ed memory. it's location should
not
         change across GC since we may wait on it while GC is working.
         another option is to pin the mutex record but this leads to heap
         fragmentation and there should not be so many many mutex objects
         anyway */
      xmutex_t *xmu_system;                              /* OS object */
    } * Mutex;
    #define mutex_length  2
    #define mutex_xlength
(sizeof(*(Mutex)0)-offsetofa(record_,recdata)-mutex_length*sizeof(gcv_object_t))

    #define mutex_flag_recursive  0x0001
    #define mutex_recursivep(obj) (TheMutex(obj)->xmu_flags &
mutex_flag_recursive)

=============================

FYI I downloaded the lispbibl.d file from here
(http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/lispbibl.d<http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/lispbibl.d>
)
and I don't know why but the code there is not up to date with the
lispbibl.d
from mercurial repo.


>> 5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE
do?
> This is just a syntax sugar to hide win32/posix thread function return
type.
Can you elaborate more?


> Recent win32 versions (not sure from when exactly) have real
> condition variables
> (
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx
).
> The reason we do not use them is that we want to support windows
> xp as  well. Of course some ifdefs are possible but nobody bothered
> yet.

Thanks. Yes! I did find that condition variables are now part of win32
api since windows Vista. Wouldn't it be good to add the additional
usage of native condition variables now that they are supported?
It might increase the performance. Should I read the proper docs and
code another macro with new condition variables?


I tried to reproduce bugs tagged with 'multithreading' over at sourceforge.
But haven't been successful (obviously due to lack of knowledge)

Anyway I am going through the zthread.d file, understanding every part
of it. And alsofamiliarizing with the internals which should be completed
by this Monday.

Also, in a previous email you wrote
> xthread.d should be extended with CAS(I suggest to extend testandset
macros).
what more should I read to get started with it?

So what should I do next?
I still haven't had a grasp of lisp mutex. I would be clear with its usage
and
understanding after I have finished zthread.d, right?



On Thu, May 1, 2014 at 11:18 PM, Vladimir Tzankov <vtz...@gm...>wrote:

> > 1.  Is test-and-set faster than compare-and-swap?
> testandset in xthread.d is special case of cas with 0/1 values.
>
>
> > 2.  In [xthread.d, line 104 ]  its mentioned "raw mutex used for thread
> > suspension/resume". What does a raw mutex refer to here? Is it any
> > different from a normal mutex? Does by raw mutex you mean .. simply
> > a mutex (! mutex/condition variable pair) ?
>
> In all comments "raw" mutex means operating system mutex while "mutex"
> means lisp object mutex (see lispbibl.d:6831).
> "raw" mutex is used for lisp mutex implementation.
>
> > 3.  I came across futex. It's a kernel facility the enables fast
> > implementations
> > of mutex in userspace and is used to implement basic locking. Why don't
> we
> > incorporate it in achieving locking ? since Pthread Mutex in the latest
> > Linux
> > distributions are implemented through Futex logic.
>
> futex is linux only thing. clisp runs on bsd, win32, etc. Also futex
> cannot be used with condition variables.
>
> > 4.  In [xthread.d, line 52 ] I could not understand the 'Create a new
> > thread'
> > method's  void* (*startroutine)(void*) argument. Please, also provide me
> > with a definition of startroutine.
>
> See zthread.d:228
> This is start routine for all threads created from lisp code.
>
> > 5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE
> do?
> This is just a syntax sugar to hide win32/posix thread function return
> type.
>
> > 6.  In [xthread.d, line 156],  its mentioned 'an inefficient
> implementation
> > of
> > condition variable for win32.'. Why don't we use windows 'Events'
> instead of
> > a condition variable, since I read they are like a mutex/condition pair
> > wrapped
> > around a boolean.
> > plus there's also a to-do marked there-  "TODO : make it better."
>
> Condition variable emulation on win32 is not exactly inefficient but
> is not fair for sure. Win32 event is very different compared to posix
> condition variables - please go over related docs again.
> Recent win32 versions (not sure from when exactly) have real condition
> variables (
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx
> ).
> The reason we do not use them is that we want to support windows xp as
> well. Of course some ifdefs are possible but nobody bothered yet.
>

Re: mt questions

[Vladimir T. <vtz...@gm...>]

> 1.  Is test-and-set faster than compare-and-swap?
testandset in xthread.d is special case of cas with 0/1 values.


> 2.  In [xthread.d, line 104 ]  its mentioned "raw mutex used for thread
> suspension/resume". What does a raw mutex refer to here? Is it any
> different from a normal mutex? Does by raw mutex you mean .. simply
> a mutex (! mutex/condition variable pair) ?

In all comments "raw" mutex means operating system mutex while "mutex"
means lisp object mutex (see lispbibl.d:6831).
"raw" mutex is used for lisp mutex implementation.

> 3.  I came across futex. It's a kernel facility the enables fast
> implementations
> of mutex in userspace and is used to implement basic locking. Why don't we
> incorporate it in achieving locking ? since Pthread Mutex in the latest
> Linux
> distributions are implemented through Futex logic.

futex is linux only thing. clisp runs on bsd, win32, etc. Also futex
cannot be used with condition variables.

> 4.  In [xthread.d, line 52 ] I could not understand the 'Create a new
> thread'
> method's  void* (*startroutine)(void*) argument. Please, also provide me
> with a definition of startroutine.

See zthread.d:228
This is start routine for all threads created from lisp code.

> 5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE do?
This is just a syntax sugar to hide win32/posix thread function return type.

> 6.  In [xthread.d, line 156],  its mentioned 'an inefficient implementation
> of
> condition variable for win32.'. Why don't we use windows 'Events' instead of
> a condition variable, since I read they are like a mutex/condition pair
> wrapped
> around a boolean.
> plus there's also a to-do marked there-  "TODO : make it better."

Condition variable emulation on win32 is not exactly inefficient but
is not fair for sure. Win32 event is very different compared to posix
condition variables - please go over related docs again.
Recent win32 versions (not sure from when exactly) have real condition
variables (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx).
The reason we do not use them is that we want to support windows xp as
well. Of course some ifdefs are possible but nobody bothered yet.

Re: Hi [Gsoc-2014 Accepted]

[shashank <sha...@gm...>]

Progress Report:

hello Vlad,

It took me a lot of time to get familiar with the technical concepts and
terminologies about system system programming.

The amount of information was  overwhelming at first but now I do
have a sound knowledge about synchronization primitives - spinlocks,
 condition variables, compare-and-swap, test-and-set. And how to use
them. I also spent time going through each line of xthread.d file and
its now committed in my memory.

Questions .. yes! many.
(I found answers to a lot of the questions I faced mostly related to
OS concepts on the internet itself.)

1.  Is test-and-set faster than compare-and-swap?

2.  In [xthread.d, line 104 ]  its mentioned "raw mutex used for thread
suspension/resume". What does a raw mutex refer to here? Is it any
different from a normal mutex? Does by raw mutex you mean .. simply
a mutex (! mutex/condition variable pair) ?

3.  I came across futex. It's a kernel facility the enables fast
implementations
of mutex in userspace and is used to implement basic locking. Why don't we
incorporate it in achieving locking ? since Pthread Mutex in the latest
Linux
distributions are implemented through Futex logic.

4.  In [xthread.d, line 52 ] I could not understand the 'Create a new
thread'
method's  void* (*startroutine)(void*) argument. Please, also provide me
with a definition of startroutine.

5.  In [xthread.d, line 99,152] what does #define THREADPROC_SIGNATURE do?

6.  In [xthread.d, line 156],  its mentioned 'an
inefficient implementation of
condition variable for win32.'. Why don't we use windows 'Events' instead of
a condition variable, since I read they are like a mutex/condition pair
wrapped
around a boolean.
plus there's also a to-do marked there-  "TODO : make it better."


Shashank


On Sat, Apr 26, 2014 at 12:22 PM, shashank <sha...@gm...> wrote:

> I apologize for the delayed response. I got occupied with college work
> and also I was unsure what to write to you since you have given me a lot
> of information to study.
>
> Please allow me sometime to go through all this and become familiar with
> it.
> I'll ask question as I face them.
>
>
>
> On Thu, Apr 24, 2014 at 12:18 PM, Vladimir Tzankov <vtz...@gm...>wrote:
>
>> Yep, CAS is for Compare-And-Swap. Bear in mind we should support
>> multiple platforms and compilers. Recent gcc versions have builtin
>> support for atomic ops but we are not using them since other compilers
>> do not support them (e.g. msvc).
>>
>> In xthread.d is platform dependent portability layer - there are
>> mutex, condition variable and spinlock implementations for posix and
>> win32. Note that spinlock is special case of compare-and-swap (just
>> two values 0 or 1).
>>
>> zthread.d contains lisp land synchronization routines - lisp mutex and
>> lisp condition variable (called 'exemption').
>>
>> For hash table implementation you will need both.
>> 1. xthread.d should be extended with CAS (i suggest to extend
>> testandset macros).
>> 2. you will need this CAS + lisp sync object in order to implement the
>> hash table.
>>
>> As an example how to use lisp mutex - see package.d. There are helper
>> macros in lispbibl.d - WITH_LISP_MUTEX_LOCK which ensure proper
>> acquire/release handling in case of non-local exits.
>>
>> Vlad
>>
>> On Wed, Apr 23, 2014 at 6:16 PM, shashank <sha...@gm...>
>> wrote:
>> > Affirmative.
>> > I will CC all my question to clisp-devel list too.
>> > And I'll try to group together as many questions that I come up
>> > with into a single email, instead of spanning it over multiple emails.
>> >
>> >> Lock free hash table implementation itself is not very hard but
>> >> tricky in the details.
>> > Thanks for clearing this up. I got really worked up since the answer
>> > to a question here on stackoverflow said "Creating lock free structures
>> > is extremely hard and only experts in this field can do it.".
>> >
>> >> Also atomic primitives have to be added to xthread.d (cas in
>> particular).
>> > quick question .. what is cas?
>> >
>> > Also while doing a grep I found zthread.d file.While xthread.d contains
>> > macros
>> > for adding thread support, zthread.d contains the multithreading
>> > implementation (should I look into this too? ).
>> > So is there a top level file where xthread.c is called ?
>> >
>> >
>> >
>> > On Wed, Apr 23, 2014 at 12:02 AM, Vladimir Tzankov <vtz...@gm...>
>> > wrote:
>> >>
>> >> Hey Shashank,
>> >>
>> >> I am glad the proposal was accepted - now it's time for the real work
>> :).
>> >>
>> >> I'll be quite busy in recent weeks and the preferred way of
>> >> communication is via emails. I'll try to respond as quickly as I can
>> >> (but bare in mind there will be some gaps due to travelling). Also CC
>> >> your questions to clisp-devel.
>> >>
>> >> Now it's the time to go over the clisp internals at
>> >> http://clisp.org/impnotes/ (Chapter IV). Play around with clisp code
>> >> base - change some things, run tests, etc. Lock free hash table
>> >> implementation itself is not very hard but tricky in the details.
>> >> Making it compatible with CL standard is harder. Also atomic
>> >> primitives have to be added to xthread.d (cas in particular).
>> >>
>> >> So please spend first week or two in getting comfortable with the
>> >> toolchain, code base and internals. Ask questions.
>> >>
>> >> BR
>> >>   Vlad
>> >>
>> >> On Tue, Apr 22, 2014 at 12:14 AM, shashank <sha...@gm...>
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > Hey Vlad and Sam, thank you soo much :D
>> >> > And also thank you everyone who is a part of CLISP.
>> >> >
>> >> > I just found out that I got accepted into Google Summer of Code '14
>> to
>> >> > work
>> >> > with GNU and on CLISP. [0]
>> >> >
>> >> > I know I haven't been able to interact more with you guys about the
>> >> > project
>> >> > and in general. But thank for spotting the good in me and accepting
>> me
>> >> > as a
>> >> > part of clisp team.
>> >> > This is Exhilarating feeling for me. I am desperately waiting to
>> learn
>> >> > more
>> >> > & more from you all under your guidance and I commit that I will be a
>> >> > really
>> >> > good student and fun person to work with :)
>> >> >
>> >> > I am glad I'll be hanging out more here.
>> >> > Thanks again
>> >> >
>> >> > Best
>> >> > Shashank
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > Start Your Social Network Today - Download eXo Platform
>> >> > Build your Enterprise Intranet with eXo Platform Software
>> >> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> > http://p.sf.net/sfu/ExoPlatform
>> >> > _______________________________________________
>> >> > clisp-devel mailing list
>> >> > cli...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/clisp-devel
>> >> >
>> >
>> >
>>
>
>

Hi [Gsoc-2014 Accepted]

[shashank <sha...@gm...>]

Hi

Hey Vlad and Sam, thank you soo much :D
And also thank you everyone who is a part of CLISP.

I just found out that I got accepted into Google Summer of Code '14 to work
with GNU and on CLISP. [0]

I know I haven't been able to interact more with you guys about the project
and in general. But thank for spotting the good in me and accepting me as a
part of clisp team.
This is Exhilarating feeling for me. I am desperately waiting to learn more
& more from you all under your guidance and I commit that I will be a
really good student and fun person to work with :)

I am glad I'll be hanging out more here.
Thanks again

Best
Shashank

Re: Gsoc'14 proposal review

[shashank <sha...@gm...>]

Thank you for the review.
I have continued the thread conversation on google-melange's page itself.
Do suggest any more amendments :)


On Fri, Mar 28, 2014 at 9:46 PM, Sam Steingold <sd...@gn...> wrote:

> Hi,
>
> > * shashank <funfunaxtebil@tznvy.pbz> [2014-03-21 10:29:48 +0500]:
> >
> > Please review my proposal[1] to contribute in Clisp for Gsoc'14 and
> > also suggest any possible amendments that I need to make.
> > [1]:
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/fnaticshank/5629499534213120
>
> Thanks!
> I left a comment there.
>
> Vladimir, please review the proposal and volunteer to mentor!
>
> --
> Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
> http://www.childpsy.net/ http://islamexposedonline.com
> http://www.memritv.org
> https://www.facebook.com/TheIslamicThreat http://dhimmi.com
> We are born naked, wet, and hungry.  Then things get worse.
>

Re: Gsoc'14 proposal review

[shashank <sha...@gm...>]

Hey,
Can someone link me or suggest some resources that I can read on
multi-threading which work closely to how multi-thread interfaces are work
in Clisp, as I have started practicing multi-thread programming in C and I
believe it is a good time to closely match the standards and specifications
of clisp's workings.


On Fri, Mar 28, 2014 at 9:46 PM, Sam Steingold <sd...@gn...> wrote:

> Hi,
>
> > * shashank <funfunaxtebil@tznvy.pbz> [2014-03-21 10:29:48 +0500]:
> >
> > Please review my proposal[1] to contribute in Clisp for Gsoc'14 and
> > also suggest any possible amendments that I need to make.
> > [1]:
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/fnaticshank/5629499534213120
>
> Thanks!
> I left a comment there.
>
> Vladimir, please review the proposal and volunteer to mentor!
>
> --
> Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
> http://www.childpsy.net/ http://islamexposedonline.com
> http://www.memritv.org
> https://www.facebook.com/TheIslamicThreat http://dhimmi.com
> We are born naked, wet, and hungry.  Then things get worse.
>

Re: Gsoc'14 proposal review

[Sam S. <sd...@gn...>]

Hi,

> * shashank <funfunaxtebil@tznvy.pbz> [2014-03-21 10:29:48 +0500]:
>
> Please review my proposal[1] to contribute in Clisp for Gsoc'14 and
> also suggest any possible amendments that I need to make.
> [1]: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/fnaticshank/5629499534213120

Thanks!
I left a comment there.

Vladimir, please review the proposal and volunteer to mentor!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
http://www.childpsy.net/ http://islamexposedonline.com http://www.memritv.org
https://www.facebook.com/TheIslamicThreat http://dhimmi.com
We are born naked, wet, and hungry.  Then things get worse.

Re: Gsoc'14 proposal review

[Pascal J. B. <pj...@in...>]

shashank <sha...@gm...> writes:

> Hello,
>
> Please review my proposal[1] to contribute in Clisp for Gsoc'14 and
> also suggest any possible amendments that I need to make.
> [1]: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/fnaticshank/5629499534213120
>
> I hope to learn a lot.
> Thanks in advance,
>
> Shashank

Good luck, and good hacking! ;-)

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"

Gsoc'14 proposal review

[shashank <sha...@gm...>]

Hello,

Please review my proposal[1] to contribute in Clisp for Gsoc'14 and
also suggest any possible amendments that I need to make.
[1]: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/fnaticshank/5629499534213120

I hope to learn a lot.
Thanks in advance,

Shashank

ffcall bug issue in CLISP

[Deepak S. <dee...@gm...>]

Hello,

I am Deepak Kumar Sharma, I am participating in GSoC 2014 under GNU
Libffcall project "Debug the bugs". While looking into the list of
bugs I found one of the bug which is related to CLISP. This bug is
reported on savannah, it says  "when va_start_struct and va_return*
are used in clisp/src/foreign.d, GCC issues warnings: "

Here is the link for bug:
http://savannah.gnu.org/bugs/?22035

I want you to please tell/guide me how to reproduce that bug so that I
can fix it.


-- 
Deepak Kumar Sharma
Blog:
http://deekysharma.wordpress.com

Re: help on building clisp

[Pascal J. B. <pj...@in...>]

Sam Steingold <sd...@gn...> writes:

> Hi,
>
>> * shashank <funfunaxtebil@tznvy.pbz> [2014-03-13 01:47:50 +0500]:
>>
>>> What made you think that this command does anything useful?
>> well I was fumbling around and I thought make files should yield something.
>> Turns out it does something else but I wanted to know why it running "make
>> -f Makefile.devel" gave me an error?
>
> "devel" in this case means "maintainer".

Well, he wants to become a "maintainer", as a gsoc aspirant.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"

Re: help on building clisp

[Sam S. <sd...@gn...>]

Hi,

> * shashank <funfunaxtebil@tznvy.pbz> [2014-03-13 01:47:50 +0500]:
>
>> What made you think that this command does anything useful?
> well I was fumbling around and I thought make files should yield something.
> Turns out it does something else but I wanted to know why it running "make
> -f Makefile.devel" gave me an error?

"devel" in this case means "maintainer".

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
http://www.childpsy.net/ http://memri.org http://jihadwatch.org
http://openvotingconsortium.org http://islamexposedonline.com
The best propaganda of atheism is done by organized religion.