clisp-devel — closed list for developers and testers

Re: clisp: cvs --> hg

[Raymond T. <toy...@gm...>]

On 2/25/11 12:50 PM, Don Cohen wrote:
> Sam Steingold writes:
>  > > please read up https://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial
>  > 
>  > there are now two hg repos: clisp & www.
>  > https://sourceforge.net/projects/clisp/develop
>  > no one has write access yes, but everyone should be able to read.
>  > please test the repos.
>
> I'm trying to figure out what corresponds to 
>   cd ...
>   cvs up -d
I think you want to do hg clone first.  Then you can do hg pull to get
new stuff and hg update to update your local files.  (I am a new hg
user, but this is what I do.  There might be better ways.)

> http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial#Access
> contains this:
>   rsync -av PROJECTNAME.hg.sourceforge.net::hgroot/PROJECTNAME/* .
> but I get
> $ rsync -av clisp.hg.sourceforge.net::hgroot/clisp/ ~don/hg/clisp/
> rsync: failed to connect to clisp.hg.sourceforge.net: Connection refused (111)
rsync was disabled for git and hg on sourceforge a while ago.  I think
it still is.

Ray

Re: clisp: cvs --> hg

[<don...@is...>]

Sam Steingold writes:
 > > please read up https://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial
 > 
 > there are now two hg repos: clisp & www.
 > https://sourceforge.net/projects/clisp/develop
 > no one has write access yes, but everyone should be able to read.
 > please test the repos.

I'm trying to figure out what corresponds to 
  cd ...
  cvs up -d

http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial#Access
contains this:
  rsync -av PROJECTNAME.hg.sourceforge.net::hgroot/PROJECTNAME/* .
but I get
$ rsync -av clisp.hg.sourceforge.net::hgroot/clisp/ ~don/hg/clisp/
rsync: failed to connect to clisp.hg.sourceforge.net: Connection refused (111)

If I add -e ssh then it seems to connect but wants me to login.

Suggestions?

Re: clisp: cvs --> hg

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

Sam, I cloned the repository and it contains the same files as my last
cvs update.
I committed locally in the new hg repository the only change I have
pending (fix in GC when gen 0 is split fue to large holes at its end).
So far everything looks fine.

On 2/25/11, Sam Steingold <sd...@gn...> wrote:
>> * Sam Steingold <fq...@ta...> [2011-02-23 12:00:44 -0500]:
> there are now two hg repos: clisp & www.
> https://sourceforge.net/projects/clisp/develop
> no one has write access yes, but everyone should be able to read.
> please test the repos.
> Vladimir, please check that the repo is equivalent to the cvs head and
> prepare your pending patches against it.
> when you think you are ready to push (i.e., committed them to your local
> repo and are happy with them - no missing files &c), please tell me and
> I will enable your write access, and then you will push (so you will be
> the hg guinea pig ;-)

Re: clisp: cvs --> hg

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

> * Sam Steingold <fq...@ta...> [2011-02-23 12:00:44 -0500]:
>
> cvs write access has been disabled for everyone.
> hg coming up soon.
> please read up https://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial

there are now two hg repos: clisp & www.
https://sourceforge.net/projects/clisp/develop
no one has write access yes, but everyone should be able to read.
please test the repos.
Vladimir, please check that the repo is equivalent to the cvs head and
prepare your pending patches against it.
when you think you are ready to push (i.e., committed them to your local
repo and are happy with them - no missing files &c), please tell me and
I will enable your write access, and then you will push (so you will be
the hg guinea pig ;-)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://thereligionofpeace.com http://openvotingconsortium.org
http://truepeace.org http://www.memritv.org http://ffii.org http://camera.org
Heck is a place for people who don't believe in gosh.

Re: clisp: cvs --> hg

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

cvs write access has been disabled for everyone.
hg coming up soon.
please read up https://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial

-- 
Sam Steingold (http://sds.podval.org/) on gnu/linux terminal
http://dhimmi.com http://openvotingconsortium.org http://mideasttruth.com
http://honestreporting.com http://www.PetitionOnline.com/tap12009/
We're too busy mopping the floor to turn off the faucet.

Re: with-standard-io-syntax and integers

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

Vladimir Sedach <vs...@gm...> writes:

> I'm running the latest (as of Feb. 22) CVS version and getting this behavior:
>
>
> [1]> (prin1 1)
> 1
> 1
> [2]> (with-standard-io-syntax (prin1 1))
> 1.
> 1
>
> The "1." seems wrong. Is this a bug or allowed ANSI behavior?

This is specified behavior:

    *print-readably*             t                                   

to ensure that the integers are read back exactly as they are, the base
must be explicit.  This is archived with the decimal point which
specifies that the number is written in decimal (= base ten).

An implementation could also print it as: #x1 or #o1, but results would
be uglier for other integers, and this calls up a more sophisticated
mechanism: the dispatching reader macro character, instead of plain
reader token syntax.


Notice that *print-readably* true should also imply that symbols are
printed fully qualified and escaped:  |LIKE|:|THIS|.

Anything else, and the reading could fail!

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

with-standard-io-syntax and integers

[Vladimir S. <vs...@gm...>]

I'm running the latest (as of Feb. 22) CVS version and getting this behavior:


[1]> (prin1 1)
1
1
[2]> (with-standard-io-syntax (prin1 1))
1.
1

The "1." seems wrong. Is this a bug or allowed ANSI behavior?

Vladimir

Re: Small typo in clx.f

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

> * Peter Van Eynde <cin...@qr...> [2011-02-17 12:46:37 +0100]:
>
> -    error(error_condition,"~S: At least :DRAWABLE should be specifed.");
> +    error(error_condition,"~S: At least :DRAWABLE should be specified.");

thanks, but it is better to use error_required_keywords().
patch committed.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final)
http://truepeace.org http://jihadwatch.org http://ffii.org
http://mideasttruth.com http://memri.org http://openvotingconsortium.org
Life is like a diaper -- short and loaded.

Small typo in clx.f

[Peter V. E. <pva...@de...>]

Hello all,

There is a small typo in clx.f, patch:

--- clisp.orig/modules/clx/new-clx/clx.f
+++ clisp/modules/clx/new-clx/clx.f
@@ -3109,7 +3109,7 @@
     }
   } else {
     pushSTACK(TheSubr (subr_self)->name);
-    error(error_condition,"~S: At least :DRAWABLE should be specifed.");
+    error(error_condition,"~S: At least :DRAWABLE should be specified.");
   }
   skipSTACK(26);
 }

Best regards, Peter

-- 
signature -at- pvaneynd.mailworks.org
http://pvaneynd.dreamwidth.org/
"God, root, what is difference?" Pitr|"God is more forgiving." Dave Aronson|

[ clisp-Bugs-3182685 ] socket-connect with timeout non-zero ->ETIMEDOUT

[SourceForge.net <no...@so...>]

Bugs item #3182685, was opened at 2011-02-15 19:15
Message generated for change (Tracker Item Submitted) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182685&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Bruno Haible (haible)
Summary: socket-connect with timeout non-zero ->ETIMEDOUT

Initial Comment:
 > > [5]> (multiple-value-setq (socket err) (ignore-errors
 > > (SOCKET:SOCKET-CONNECT 80 
 > > "localhost" :timeout 1 :element-type '(unsigned-byte 8)))) 
 > >  
 > > [../src/stream.d:14257] NIL 
 > > [6]> (format nil "~a" err) 
 > > "UNIX error 110 (ETIMEDOUT): Connection timed out 
 > > " 
 ...
 > indeed this is a regression over 2.44.1.
 > could you please try to pin down which version caused this behavior and
 > file a bug report on SF?
 > thanks.

Earliest I can find so far already on my machines after 2.44 is
2.47+ as of 2008-10-24 and that has the bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182685&group_id=1355

Re: clisp proposal for google summer of code

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

On 2/15/11, Alin-Florin Rus-Rebreanu <net...@gm...> wrote:
> I see Sam forwarded my email to the development list, so there's not
> to much to be said. I've read Vladimir's mail and managed to find the
> relevant code, will try to dive in and come up with a mini-proposal
> (or questions) by the end of this week (still have one last exam at
> the university this semester).
>
> Hopefully this will be the beginning of a great experience, thanks for
> the support.

Hi Alin,

This was fast!
It's great to have another volunteer for mt - during last year I had
almost no time to work on the open issues.  Do not hesitate to ask
whatever questions you have here on clisp-devel list.

Vladimir

[ clisp-Bugs-3182597 ] WRITE-BYTE-SEQUENCE :no-hang t => error

[SourceForge.net <no...@so...>]

Bugs item #3182597, was opened at 2011-02-15 18:19
Message generated for change (Tracker Item Submitted) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182597&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Nobody/Anonymous (nobody)
Summary: WRITE-BYTE-SEQUENCE :no-hang t => error

Initial Comment:
[3]> (EXT:WRITE-BYTE-SEQUENCE #(1) f :no-hang t) 
   *** - WRITE-BYTE-SEQUENCE on  
         #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 8) #P"/tmp/out1"> is  illegal  
works when array is element-type (unsigned-byte 8)
(the bug is that it does not work for other types)
same problem for unbuffered streams

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182597&group_id=1355

Re: clisp proposal for google summer of code

[Alin-Florin Rus-R. <net...@gm...>]

On Tue, Feb 15, 2011 at 5:10 PM, Sam Steingold <sd...@gn...> wrote:
> Hi,
>
>> * Alin-Florin Rus-Rebreanu <arg...@tz...> [2011-02-15 15:34:18 +0200]:
>>
>> First of all sorry if this it bothers you that I've sent this as a
>> private email.
>
> good news are welcome on any medium, although it is best to use a
> mailing list.
> clisp-devel is the best venue, please subscribe and reply there.
>
>> I would be very interested in working on GNU CLISP on the
>> multithreading interface in or outside GSoC if someone is willing to
>> mentor this.
>
> we will be delighted to!
> Vladimir is our MT expert; he wrote most of it.
> He should be answering you questions about CLISP MT design.
> I will do my best helping you with various lesser issues.
> Bruno is our "elder statesman".
>
>> I was a student in GSoC 2010 [1] as part of RTEMS and I implemented
>> the support for posix asynchronous input output for their system
>> (aio_*() and lio_listio()) so I have a pretty good understanding of
>> the multithreading stuff required for such a project. I presented 2
>> implementation one based on the glibc desing and one redesinged by me
>> which is almost fully integrated in RTEMS, it only lacks the
>> lio_listio LIO_NOWAIT stuff on which I'm working right now.
>>
>> I'm a 2nd year student in software engineering.
>>
>> Would this make me at least eligible to undertake this project? If so
>> I can start this week to poke around CLISP.
>
> sure, please go ahead!
>

Hello clisp-devel,

I see Sam forwarded my email to the development list, so there's not
to much to be said. I've read Vladimir's mail and managed to find the
relevant code, will try to dive in and come up with a mini-proposal
(or questions) by the end of this week (still have one last exam at
the university this semester).

Hopefully this will be the beginning of a great experience, thanks for
the support.

Regards,
-- 
Alin Rus

Re: clisp proposal for google summer of code

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

Hi,

> * Alin-Florin Rus-Rebreanu <arg...@tz...> [2011-02-15 15:34:18 +0200]:
>
> First of all sorry if this it bothers you that I've sent this as a
> private email.

good news are welcome on any medium, although it is best to use a
mailing list.
clisp-devel is the best venue, please subscribe and reply there.

> I would be very interested in working on GNU CLISP on the
> multithreading interface in or outside GSoC if someone is willing to
> mentor this.

we will be delighted to!
Vladimir is our MT expert; he wrote most of it.
He should be answering you questions about CLISP MT design.
I will do my best helping you with various lesser issues.
Bruno is our "elder statesman".

> I was a student in GSoC 2010 [1] as part of RTEMS and I implemented
> the support for posix asynchronous input output for their system
> (aio_*() and lio_listio()) so I have a pretty good understanding of
> the multithreading stuff required for such a project. I presented 2
> implementation one based on the glibc desing and one redesinged by me
> which is almost fully integrated in RTEMS, it only lacks the
> lio_listio LIO_NOWAIT stuff on which I'm working right now.
>
> I'm a 2nd year student in software engineering.
>
> Would this make me at least eligible to undertake this project? If so
> I can start this week to poke around CLISP.

sure, please go ahead!

> Regards,
>
> [1] http://dl.dropbox.com/u/1287255/2010-10-01-110452.jpg

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final)
http://openvotingconsortium.org http://honestreporting.com http://memri.org
http://mideasttruth.com http://pmw.org.il http://iris.org.il
(let ((a "(let ((a %c%s%c)) (format a 34 a 34))")) (format a 34 a 34))

Re: clisp MT & summer of code

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

IMO, the only major thing left to be implemented are thread safe hash tables.
There are two approaches to accomplish this:
1. have lock on hash tables operations (e.g. add :synchronized param
to make-hash-table and ensure no segfault may happen with or without
it).
2. re-implement entirely hash tables.

(1) while easier is not good according to me. This will cause
performance issues in clos (internally it uses hash tables) - even
make-instance should (most probably) obtain lock internally.
(2) is the way to go, IMO. I think we should replace current hash
tables with lock-free open-addressing ones like described in:
http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf.
CCL hash tables implementation is based on this as well.
The hardest part in this reimplementation is integration with GC
because of weak relations.
I've started to implement (2) but in last year I had almost no free
time to spend on it :(.

There will be more issues with mt of course - but not so major ones as
hash tables.

Vladimir

PS:  currently there is problem with generational gc and heap holes
filling - hope this week to fix it. the problem can be easily observed
when some threads perform socket i/o from slow server and other worker
threads trigger GC frequently.


On 2/13/11, Sam Steingold <sd...@gn...> wrote:
> Vladimir,
> I think we should create a clisp/mt project for the google Summer of Lisp.
> IIUC, the only remaining hurdle is MT-safe hash tables, and this sounds
> like a good student project.
> Could you please write a brief description of what needs to be done?
> Thanks!
> --
> Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
> http://memri.org http://thereligionofpeace.com http://mideasttruth.com
> http://truepeace.org http://iris.org.il http://pmw.org.il http://camera.org
> XFM: Exit file manager? [Continue] [Cancel] [Abort]
>

clisp MT & summer of code

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

Vladimir,
I think we should create a clisp/mt project for the google Summer of Lisp.
IIUC, the only remaining hurdle is MT-safe hash tables, and this sounds
like a good student project.
Could you please write a brief description of what needs to be done?
Thanks!
-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
http://memri.org http://thereligionofpeace.com http://mideasttruth.com
http://truepeace.org http://iris.org.il http://pmw.org.il http://camera.org
XFM: Exit file manager? [Continue] [Cancel] [Abort]

Re: [clisp-list] CFFI on Mac OS X

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

On 2/7/11, Carlos Ungil <car...@gm...> wrote:
> $ cvs -z3 -d:pserver:ano...@cv...:/sources/libffcall co
> ffcall
> $ cd ffcall
> $ ./configure
> $ make
> cd avcall && make all
> gcc -E `if test true = true; then echo '-DASM_UNDERSCORE'; fi`
> ./avcall-i386-macro.S | grep -v '^ *#line' | grep -v '^#ident' | grep
> -v '^#' | sed -e 's,% ,%,g' -e 's,% ,%,g' -e 's,\. ,.,g' >
> avcall-i386.s
> /bin/sh ./libtool --mode=compile gcc -x none -c avcall-i386.s
>  gcc -x none -c avcall-i386.s -o avcall-i386.o
> avcall-i386.s:7:suffix or operands invalid for `push'
> avcall-i386.s:9:suffix or operands invalid for `push'
> avcall-i386.s:10:suffix or operands invalid for `push'
> avcall-i386.s:39:suffix or operands invalid for `call'
> avcall-i386.s:47:suffix or operands invalid for `call'
> avcall-i386.s:53:suffix or operands invalid for `call'
> avcall-i386.s:168:suffix or operands invalid for `pop'
> avcall-i386.s:169:suffix or operands invalid for `pop'
> avcall-i386.s:171:suffix or operands invalid for `pop'
> make[1]: *** [avcall-i386.lo] Error 1
> make: *** [all] Error 2

gcc on osx by default builds for x86_64. looks like configure does not
detect this and tries to build i386 target.

Vladimir

[ clisp-Bugs-3153786 ] Website error

[SourceForge.net <no...@so...>]

Bugs item #3153786, was opened at 2011-01-09 20:13
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3153786&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: web pages
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: guiler (guiler)
Assigned to: Sam Steingold (sds)
Summary: Website error

Initial Comment:
Access to certain parts of the implementation notes is not working. 
Example: http://www.gnu.org/software/clisp/impnotes/socket.html
Breaks with the following error: [an error occurred while processing this directive]

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-02-06 05:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2011-01-23 04:42

Message:
the problem was that we used to pass through comments from xml to html.
those comments contain "#if" et al which turn out to be SSI directives
which is enabled on gnu.org
see http://article.gmane.org/gmane.text.docbook.apps:13033
and clisp/doc/common.xsl:1.80

the problem will be fixed when we release clisp 2.50 and regenerate the
web pages.
please use clisp.cons.org for now.
thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3153786&group_id=1355

Re: new bug in MT

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

On 2/3/11, Don Cohen <don...@is...> wrote:
> .....
> #64 0x0000000000484b32 in handle_pending_interrupts () at ../src/spvw.d:4547
> #65 0x000000000046b9f9 in allocate_iarray (flags=55 '7', rank=1, type=30)
>     at ../src/spvw_typealloc.d:322
> #66 0x00000000005449eb in init_reader_low (thr=0x7fffe4001fd0)
>     at ../src/io.d:519
> #67 0x00000000006ad30e in thread_stub (arg=0x7fffe4001fd0)
>     at ../src/zthread.d:260
> #68 0x000000309e206d5b in start_thread () from /lib64/libpthread.so.0
> #69 0x000000309dae4a7d in clone () from /lib64/libc.so.6

Thanks.
While I still cannot reproduce it - the above call stack shows the
problem. Thread is being interrupted too early - before it's low-level
initialization. While fixing this - another problem with deferred
interrupts was revealed.

I fixed both issues but sf cvs is still down :(.

Vladimir

Re: new bug in MT

[<don...@is...>]

Vladimir Tzankov writes:
 > On 2/3/11, Don Cohen <don...@is...> wrote:
 > >
 > > (all bug reports related to MT go to -devel, right?)
 > yes
 > 
 > > This was an unpleasant surprise.  I've just made a small improvement
 > > to my debug server.  The new code is below.  The difference is that
 > > in addition to debugging an existing thread you can create a new one.
 > > I find that in the new thread, if I enter (mt::list-threads) I get
 > > a segfault!  The old threads don't do that.
 > 
 > I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx).
 > Can you run the whole thing under gdb and paste here the stack trace
 > of segfaulted thread?
 > 
 > Vladimir

I hope this is what you want.  I don't have a very strong idea of what
I'm doing here.  I notice that my first copy/paste added some spaces
to the ends of lines, which ended up causing a format error.
The original error was on old linux 32 bit, this is new linux 64 bit.
Anyway, if this isn't what you want, tell me how to fix it.

(gdb) run
Starting program: /tmp/ap5-2.49+MT 
[Thread debugging using libthread_db enabled]
STACK size: 98222 [0x7ffff2140e00 0x7ffff2081090]
[New Thread 0x7ffff2080700 (LWP 2364)]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (defvar *debug-server-port* 1234)
(defun show-socket-addrs(socket)
  (multiple-value-bind
      (local-host local-port)
      (socket:socket-stream-local socket)
    (multiple-value-bind
        (remote-host remote-port)
        (socket:socket-stream-peer socket)
      (format t "~&Connection: ~S:~D -- ~S:~D~%"
              remote-host remote-port local-host local-port))))
*DEBUG-SERVER-PORT*
[2]> SHOW-SOCKET-ADDRS
[3]> (defun debug-server()
  (let ((server (socket:socket-server *debug-server-port*
                                      :interface "localhost")))
       (unwind-protect
           (loop
            (let ((socket (socket:socket-accept server :buffered nil)))
              (show-socket-addrs socket)
              (let ((tlist (loop for x in (mt:list-threads) as i from 1
                             when (mt:thread-active-p x) collect (cons i x)))
                    ans)
                (print tlist socket)
                (format socket
                        "~&enter the number of a thread to interrupt debug ~
                         or something else that can be read in order to ~
                         create a new one: ")
                (setf ans (or (cdr (assoc (read socket) tlist))
                              (mt:make-thread #'read :name "listener")))
                (mt:thread-interrupt
                 ans
                 :function
                 (lambda nil
                   (let ((*standard-input* socket)
                         (*standard-output* socket)
                         (*debug-io* socket)
                         (*error-output* socket)
                         (*trace-output* socket)
                         (*query-io* socket))
                     (unwind-protect
                         (break "debug")
                       (close socket)))))))))
         (socket:socket-server-close server)))
DEBUG-SERVER
[4]> (mt:make-thread #'debug-server :name "debug-server")
[New Thread 0x7ffff0fb8700 (LWP 2371)]
#<THREAD "debug-server">
[5]> 
Connection: "127.0.0.1 (localhost.localdomain)":37791 -- "127.0.0.1 (number11.don-eve.dyndns.org)":1234
[New Thread 0x7ffff0bea700 (LWP 2373)]

Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7ffff0bea700 (LWP 2373)]
0x000000309e20e1ac in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) help
List of classes of commands:

aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands

Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) help running
Running the program.

List of commands:

advance -- Continue the program up to the given location (same form as args for break command)
attach -- Attach to a process or file outside of GDB
continue -- Continue program being debugged
detach -- Detach a process or file previously attached
detach checkpoint -- Detach from a checkpoint (experimental)
detach inferior -- Detach from inferior ID
disconnect -- Disconnect from a target
finish -- Execute until selected stack frame returns
handle -- Specify how to handle a signal
inferior -- Use this command to switch between inferiors
interrupt -- Interrupt the execution of the debugged program
jump -- Continue program being debugged at specified line or address
kill -- Kill execution of program being debugged
kill inferior -- Kill inferior ID
next -- Step program
nexti -- Step one instruction
reverse-continue -- Continue program being debugged but run it in reverse
reverse-finish -- Execute backward until just before selected stack frame is called
reverse-next -- Step program backward
reverse-nexti -- Step backward one instruction
reverse-step -- Step program backward until it reaches the beginning of another source line
reverse-stepi -- Step backward exactly one instruction
run -- Start debugged program
signal -- Continue program giving it signal specified by the argument
start -- Run the debugged program until the beginning of the main procedure
step -- Step program until it reaches a different source line
stepi -- Step one instruction exactly
target -- Connect to a target machine or process
target child -- Unix child process (started by the "run" command)
target core -- Use a core file as a target
target exec -- Use an executable file as a target
target extended-remote -- Use a remote computer via a serial line
target multi-thread -- Threads and pthreads support
target record -- Log program while executing and replay execution from log
target record-core -- Log program while executing and replay execution from log
target remote -- Use a remote computer via a serial line
target tfile -- Use a trace file as a target
task -- Use this command to switch between Ada tasks
thread -- Use this command to switch between threads
thread apply -- Apply a command to a list of threads
thread apply all -- Apply a command to all threads
until -- Execute until the program reaches a source line greater than the current

Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
30	    if (eq(Car(plistr),key)) /* found */
(gdb) help stack
Examining the stack.
The stack is made up of stack frames.  Gdb assigns numbers to stack frames
counting from zero for the innermost (currently executing) frame.

At any time gdb identifies one frame as the "selected" frame.
Variable lookups are done with respect to the selected frame.
When the program being debugged stops, gdb selects the innermost frame.
The commands below can be used to select other frames by number or address.

List of commands:

backtrace -- Print backtrace of all stack frames
bt -- Print backtrace of all stack frames
down -- Select and print stack frame called by this one
frame -- Select and print a stack frame
return -- Make selected stack frame return to its caller
select-frame -- Select a stack frame without printing anything
up -- Select and print stack frame that called this one

Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) bt
#0  0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
#1  0x000000000062f444 in get (symbol=..., key=...) at ../src/symbol.d:45
#2  0x000000000062a5c5 in expand_deftype (type_spec=..., once_p=false)
    at ../src/predtype.d:2166
#3  0x000000000062a953 in C_expand_deftype () at ../src/predtype.d:2195
#4  0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=1)
    at ../src/eval.d:5227
#5  0x00000000004a1112 in funcall (fun=..., args_on_stack=1)
    at ../src/eval.d:4867
#6  0x00000000004a8bff in interpret_bytecode_ (closure=..., 
    codeptr=0x333e9a2e0, 
    byteptr=0x333e9a2fa "\373\024\217\030\200\350\257\333\070\001\201\236")
    at ../src/eval.d:6793
#7  0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=3)
    at ../src/eval.d:5630
#8  0x00000000004a113f in funcall (fun=..., args_on_stack=3)
    at ../src/eval.d:4869
#9  0x00000000004a89d6 in interpret_bytecode_ (closure=..., 
    codeptr=0x333e9fc10, 
    byteptr=0x333e9fc37 "d@\002\021H\031\004\031\004@\034\275\064\003")
    at ../src/eval.d:6787
#10 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=2)
    at ../src/eval.d:5630
#11 0x00000000004a113f in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4869
#12 0x00000000006154ff in C_clcs_signal (argcount=0, 
    rest_args_pointer=0x7ffff0beb5f0) at ../src/error.d:805
#13 0x00000000004a242b in funcall_subr (fun=..., args_on_stack=0)
    at ../src/eval.d:5222
#14 0x00000000004a1084 in funcall (fun=..., args_on_stack=1)
    at ../src/eval.d:4860
#15 0x00000000006115dd in signal_and_debug (condition=...)
    at ../src/error.d:206
#16 0x000000000061296d in end_error (stackptr=0x7ffff0beb5b0, 
    start_driver_p=true) at ../src/error.d:346
#17 0x0000000000612a24 in prepare_error (errortype=package_error, 
    errorstring=0x7133a0 "~S from ~S: there is no package with name ~S", 
    start_driver_p=true) at ../src/error.d:365
#18 0x0000000000612a52 in error (errortype=package_error, 
    errorstring=0x7133a0 "~S from ~S: there is no package with name ~S")
    at ../src/error.d:378
#19 0x000000000054a2b0 in read_internal (stream_=0x7ffff0beb558)
    at ../src/io.d:2096
#20 0x000000000054a600 in read_recursive (stream_=0x7ffff0beb558)
    at ../src/io.d:2141
#21 0x000000000054ab84 in read_recursive_no_dot (stream_=0x7ffff0beb558)
    at ../src/io.d:2176
#22 0x000000000054caeb in read_delimited_list_recursive (
    stream_=0x7ffff0beb558, endch=..., ifdotted=...) at ../src/io.d:2367
#23 0x000000000054c535 in read_delimited_list (stream_=0x7ffff0beb558, 
    endch=..., ifdotted=...) at ../src/io.d:2332
#24 0x000000000054d605 in C_lpar_reader () at ../src/io.d:2497
#25 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#26 0x00000000004a1084 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4860
#27 0x0000000000548b97 in read_macro (ch=..., stream_=0x7ffff0beb470)
    at ../src/io.d:1793
#28 0x0000000000549580 in read_internal (stream_=0x7ffff0beb470)
    at ../src/io.d:1894
#29 0x000000000054b9d1 in read_top (stream_=0x7ffff0beb470, whitespace_p=...)
    at ../src/io.d:2263
#30 0x000000000054c027 in stream_read (stream_=0x7ffff0beb470, 
    recursive_p=..., whitespace_p=...) at ../src/io.d:2292
#31 0x000000000060875b in read_form () at ../src/debug.d:292
#32 0x00000000006092c9 in C_read_eval_print () at ../src/debug.d:400
#33 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#34 0x00000000004a1112 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4867
#35 0x00000000004a8e28 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007ee0, 
    byteptr=0x334007efe "\037\n\334\a\002\003\034\002\311R\310R\031\001")
    at ../src/eval.d:6799
#36 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5630
#37 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#38 0x000000000060cdf3 in C_same_env_as () at ../src/debug.d:1013
#39 0x00000000004a2552 in funcall_subr (fun=..., args_on_stack=2)
    at ../src/eval.d:5227
#40 0x00000000004a1112 in funcall (fun=..., args_on_stack=2)
    at ../src/eval.d:4867
#41 0x00000000004a8e28 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007c70, byteptr=0x334007cad "\021M\026\001Q&\020,\006\004")
    at ../src/eval.d:6799
#42 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5630
#43 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#44 0x00000000004c368f in C_driver () at ../src/control.d:1999
#45 0x00000000004a9090 in interpret_bytecode_ (closure=..., 
    codeptr=0x334007760, byteptr=0x3340079c7 "") at ../src/eval.d:6805
#46 0x00000000004a3e13 in funcall_closure (closure=..., args_on_stack=3)
    at ../src/eval.d:5630
#47 0x00000000004a10b1 in funcall (fun=..., args_on_stack=3)
    at ../src/eval.d:4862
#48 0x0000000000615298 in C_invoke_debugger () at ../src/error.d:743
#49 0x00000000004a9090 in interpret_bytecode_ (closure=..., 
    codeptr=0x333ff3070, byteptr=0x333ff30e6 "\006\004") at ../src/eval.d:6805
#50 0x000000000049b4fb in eval_closure (closure=...) at ../src/eval.d:3917
#51 0x0000000000494abd in eval1 (form=...) at ../src/eval.d:3091
#52 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#53 0x00000000004c2d83 in C_unwind_protect () at ../src/control.d:1943
#54 0x00000000004958c5 in eval_fsubr (fun=..., args=...) at ../src/eval.d:3263
#55 0x0000000000494b38 in eval1 (form=...) at ../src/eval.d:3101
#56 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#57 0x00000000004ba382 in C_let () at ../src/control.d:692
#58 0x00000000004958c5 in eval_fsubr (fun=..., args=...) at ../src/eval.d:3263
#59 0x0000000000494b38 in eval1 (form=...) at ../src/eval.d:3101
#60 0x000000000049420d in eval (form=...) at ../src/eval.d:2966
#61 0x00000000004930b8 in funcall_iclosure (closure=..., 
    args_pointer=0x7ffff0beb058, argcount=0) at ../src/eval.d:2744
#62 0x00000000004a3ffd in funcall_closure (closure=..., args_on_stack=0)
    at ../src/eval.d:5644
#63 0x00000000004a10b1 in funcall (fun=..., args_on_stack=0)
    at ../src/eval.d:4862
#64 0x0000000000484b32 in handle_pending_interrupts () at ../src/spvw.d:4547
#65 0x000000000046b9f9 in allocate_iarray (flags=55 '7', rank=1, type=30)
    at ../src/spvw_typealloc.d:322
#66 0x00000000005449eb in init_reader_low (thr=0x7fffe4001fd0)
    at ../src/io.d:519
#67 0x00000000006ad30e in thread_stub (arg=0x7fffe4001fd0)
    at ../src/zthread.d:260
#68 0x000000309e206d5b in start_thread () from /lib64/libpthread.so.0
#69 0x000000309dae4a7d in clone () from /lib64/libc.so.6
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000000000062f3ac in plist_find (plist_=0x9c1340, key=...)
    at ../src/symbol.d:30
30	    if (eq(Car(plistr),key)) /* found */
(gdb) continue
Continuing.
[Thread 0x7ffff0bea700 (LWP 2373) exited]
[Thread 0x7ffff0fb8700 (LWP 2371) exited]
[Thread 0x7ffff2080700 (LWP 2364) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 

Re: new bug in MT

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

On 2/3/11, Don Cohen <don...@is...> wrote:
>
> (all bug reports related to MT go to -devel, right?)
yes

> This was an unpleasant surprise.  I've just made a small improvement
> to my debug server.  The new code is below.  The difference is that
> in addition to debugging an existing thread you can create a new one.
> I find that in the new thread, if I enter (mt::list-threads) I get
> a segfault!  The old threads don't do that.

I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx).
Can you run the whole thing under gdb and paste here the stack trace
of segfaulted thread?

Vladimir

new bug in MT

[<don...@is...>]

(all bug reports related to MT go to -devel, right?)

This was an unpleasant surprise.  I've just made a small improvement
to my debug server.  The new code is below.  The difference is that
in addition to debugging an existing thread you can create a new one.
I find that in the new thread, if I enter (mt::list-threads) I get
a segfault!  The old threads don't do that.

I'm afraid I'm building up a backlog of bugs to be fixed when cvs
returns.  I think the current list includes, in addition to this one,
 performance change over last 10 years
 bug in loop? 

====
(defvar *debug-server-port* 1234)
(defun show-socket-addrs(socket) 
  (multiple-value-bind 
      (local-host local-port) 
      (socket:socket-stream-local socket) 
    (multiple-value-bind 
        (remote-host remote-port) 
        (socket:socket-stream-peer socket) 
      (format t "~&Connection: ~S:~D -- ~S:~D~%" 
              remote-host remote-port local-host local-port)))) 

(defun debug-server() 
  (let ((server (socket:socket-server *debug-server-port* 
                                      :interface "localhost"))) 
       (unwind-protect 
           (loop 
            (let ((socket (socket:socket-accept server :buffered nil))) 
              (show-socket-addrs socket) 
              (let ((tlist (loop for x in (mt:list-threads) as i from 1 
                             when (mt:thread-active-p x) collect (cons i x))) 
                    ans) 
                (print tlist socket) 
                (format socket 
                        "~&enter the number of a thread to interrupt debug ~ 
                         or something else that can be read in order to ~ 
                         create a new one: ") 
                (setf ans (or (cdr (assoc (read socket) tlist)) 
                              (mt:make-thread #'read :name "listener"))) 
                (mt:thread-interrupt 
                 ans 
                 :function 
                 (lambda nil 
                   (let ((*standard-input* socket) 
                         (*standard-output* socket) 
                         (*debug-io* socket) 
                         (*error-output* socket) 
                         (*trace-output* socket) 
                         (*query-io* socket)) 
                     (unwind-protect 
                         (break "debug") 
                       (close socket))))))))) 
         (socket:socket-server-close server))) 
 
(mt:make-thread #'debug-server :name "debug-server")
====
instructions:
run MT version of current cvs clisp
execute all above
telnet to localhost port 1234
This gives you a choice of breaking main thread or debug server or
creating a new listener, e.g., by typing 1, 2, or t

Re: clisp: cvs --> hg

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

> * Vladimir Tzankov <igm...@tz...> [2009-06-06 00:40:28 +0300]:
> On 6/6/09, Sam Steingold <sd...@gn...> wrote:
>> Sam Steingold wrote:
>>> I would like to convert the clisp cvs repository to hg (mercurial).
>>
>> All in all, the response it underwhelming.
>> Only Bruno (in a private e-mail) supports the transition.
>> Vladimir, what is your opinion?
>
> I support it too.

Good!

The time is now.
https://sourceforge.net/blog/sourceforge-attack-full-report/
"We are also considering the end-of-life of the CVS service..."
when their downtime is over, I will convert cvs to hg and push it to them.
cvs users should pull using hg.

I hope that in the 20 months, that elapsed since the discussion to which
I am replying now, those, who were opposed to the transition then, have
grown more friendly to DVCS.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
http://dhimmi.com http://www.PetitionOnline.com/tap12009/ http://pmw.org.il
http://honestreporting.com http://thereligionofpeace.com
Lisp suffers from being twenty or thirty years ahead of time.

Re: building syscalls on cygwin

[Angel P. <ang...@ya...>]

Thanks




________________________________
From: Sam Steingold <sd...@gn...>
To: cli...@li...; Angel Popov <ang...@ya...>
Sent: Wednesday, January 26, 2011 23:18:59
Subject: Re: building syscalls on cygwin

> * Angel Popov <nat...@ln...> [2011-01-22 03:42:19 -0800]:
>
> I have tried to compile the latest clisp on cygwin. with modules pcre and 
> new-clx
> make have passed, but there were some
>  multiple target patterns errors:
> .deps/close-hook.Po:1: *** multiple target patterns.  Stop.
> .deps/regex.Po:1: *** multiple target patterns.  Stop.
>
> It looks that the reason is that files have "C:/... " in them.
> Unfortunately, I cannot figure out who creates them to investigate further.
> Please, direct me to find out why it failed.

I added clisp/src/m4/clisp.m4:CLISP_DECOLONIZE specifically to address
this problem.  search makemake.in for it to see how it is used.
http://www.cygwin.com/acronyms/#PTC

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final)
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
http://palestinefacts.org http://honestreporting.com http://memri.org
You think Oedipus had a problem -- Adam was Eve's mother.

Re: building syscalls on cygwin

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

> * Angel Popov <nat...@ln...> [2011-01-22 03:42:19 -0800]:
>
> I have tried to compile the latest clisp on cygwin. with modules pcre and 
> new-clx
> make have passed, but there were some
>  multiple target patterns errors:
> .deps/close-hook.Po:1: *** multiple target patterns.  Stop.
> .deps/regex.Po:1: *** multiple target patterns.  Stop.
>
> It looks that the reason is that files have "C:/... " in them.
> Unfortunately, I cannot figure out who creates them to investigate further.
> Please, direct me to find out why it failed.

I added clisp/src/m4/clisp.m4:CLISP_DECOLONIZE specifically to address
this problem.  search makemake.in for it to see how it is used.
http://www.cygwin.com/acronyms/#PTC

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final)
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
http://palestinefacts.org http://honestreporting.com http://memri.org
You think Oedipus had a problem -- Adam was Eve's mother.