clisp-devel — closed list for developers and testers

Re: A few newbie questions

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

"Yves S. Garret" <you...@gm...> writes:

>  1. Are there any differences between CLISP and Clozure?  If so, how
>     substantial are they?  Which one would be a good place to start
>     for someone new?

Both are good implementation to start with.


>  2. Say I have a file hello_world.lisp.  In that file I have the
>     function print.  How do I execute that function from the command
>     line?  $ clisp hello_world:print ?

Depends on what's in this file exactly.

While the underline character seems to be more "portable" than the dash
for file names (eg. it's advised to use the following regexp for
maximally portable file names: /[A-Z0-9_]{1,8}\.[A-Z0-9_]{1,3}/), as a
lisper I prefer to use a dash in file names instead of an underline.
It's in the lisp style, and it's easier to type: just a key instead of
shift combination.

So, let's assume a file named hello-world.lisp, containing:

    ----(hello-world.lisp)--------------------------------------------------
    (defun hw ()
      (format t "~%Bonjour le monde !~%")
      (values))
    ------------------------------------------------------------------------

then you can run it from the unix command line with:

    $ clisp -norc -ansi -q -x '(progn (load "/tmp/hello-world.lisp" :verbose nil) (values))'  -x '(hw)'

    Bonjour le monde !
    $


But one wonders why you would want to do that?  I mean, call a lisp
function from the unix shell?



Either you are implementing a unix script in clisp, in which case you
should name your file hw, and edit it to contain:

    ----(hw)----------------------------------------------------------------
    #!/usr/bin/clisp -q -ansi -norc 

    (defun hw ()
      (format t "~%Bonjour le monde !~%")
      (values))

    (hw)
    ------------------------------------------------------------------------

    $ chmod 755 hw
    $ ./hw

    Bonjour le monde !
    $


or you are just writing lisp programs, and then you boot the lisp
environment and stay in it to work:

    $ clisp
      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.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.

    ;; Loading file /home/pjb/.clisprc.lisp ... 
    […]    
    ;; Loaded file /home/pjb/.clisprc.lisp
    C/USER[1]> (load "/tmp/hello-world.lisp")
    ;; Loading file /tmp/hello-world.lisp ...
    ;; Loaded file /tmp/hello-world.lisp
    #P"/tmp/hello-world.lisp"
    C/USER[2]> (hw)

    Bonjour le monde !

    C/USER[3]> 



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

Re: A few newbie questions

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

> * Yves S. Garret <lbhefheebtngrtbq@tznvy.pbz> [2012-04-25 17:04:33 -0400]:
>
>    1. Are there any differences between CLISP and Clozure?

yes.

> If so, how substantial are they?

wrt ANSI CL compliance - probably minor.
wrt extensions - probably pretty significant.

> Which one would be a good place to start for someone new?

either one is good enough.
try both, see which feels right.

>    2. Say I have a file hello_world.lisp.  In that file I have the function
>    print.  How do I execute that function from the command line?  $ clisp
>    hello_world:print ?

print is a standard ansi cl function.
do not redefine it.
$ clisp file
loads file.fas or file.lisp or file.
it means that it evaluates every form in it, one by one.
there are many more details, please see
http://clisp.org/impnotes/clisp.html

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://ffii.org http://memri.org
http://americancensorship.org http://truepeace.org
Two psychics reading each other's minds will die from stack overflow.

A few newbie questions

[Yves S. G. <you...@gm...>]

Hi all,

   Still learning about Lisp and I have a few questions.


   1. Are there any differences between CLISP and Clozure?  If so, how
   substantial are they?  Which one would be a good place to start for someone
   new?
   2. Say I have a file hello_world.lisp.  In that file I have the function
   print.  How do I execute that function from the command line?  $ clisp
   hello_world:print ?


I'd appreciate your help.

Re: Is there ever a good reason to create globals in Lisp?

[Christopher S. <cs...@dt...>]

Btw, a place where globals can potentially get you into trouble are in some multi-threaded situations.

Re: Is there ever a good reason to create globals in Lisp?

[Christopher S. <cs...@dt...>]

Global variables are used as the simplest implementation of the "singleton pattern".
People use them often for bootstrapping, as a database, fixed enumerations, etc.
There is no need to fetishly implement a superfluous container (such as a class instance,
whose pointer you need to pass around) for things like that, when you could just
as easily refer to the plist or hash table  *global-reasons-for-global-variables*.

A related concept you should look into are "special" variables, which have different scope.

You should read these:

http://www.flownet.com/ron/specials.pdf
http://www.gigamonkeys.com/book/variables.html

Re: Is there ever a good reason to create globals in Lisp?

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

"Yves S. Garret" <you...@gm...> writes:

> I wouldn't say I "worry" about it.  The concept of not having global
> vars at all (well, unless there's a damn good reason, avoid at all
> costs like the 'goto') has been drilled down into my skull ever since
> I finished my first C++ programming class in college.
>
> From a design perspective, this makes sense.  Fewer global vars are a
> good thing.  They can give you quirky behavior unless you're super
> careful.  I was more curious when you guys design Lisp apps, how you
> treat global variables (yes, classes, functions, etc. are global as
> well, but this is not exactly the same thing) in Lisp.  Even in
> imperative and OO languages globals have a time and place (but very
> seldom and there has to be a damn good reason why).  Do professional
> Lisp developers actively embrace them?  Stay away from them like you
> would in other programming languages?  Or is there some other
> middle-ground that I'm not aware of.
>
> The example that you provide is exactly where I could see how things
> could go very wrong in terms of undefined behavior :-) .  How are
> global variable regarded in Lisp?


I reiterate, there's no dogmatism.  They're a tool, and as any tool,
they can be put to good use, or to bad use.

But I repeat, one good use is that they allow easy access to data from
the REPL.  You can store some data from the inners of a function to a
global variable, so that when it's done you can inspect that data from
the REPL:

  (defvar *data*)

  (defun f (n p)
    (push p *data*)
    (if (zerop n) 
       p
       (f (1- n) (* n p))))

  (f 14 1)
  --> 87178291200

  *data*
  --> (87178291200 87178291200 43589145600 14529715200 3632428800
       726485760 121080960 17297280 2162160 240240 24024 2184 182 14 1)


This goes also for dynamic binding.  While it would be in general better
to use dynamic binding, ie.:

    (defun f () (let ((*global* local-value)) (g)))

for debugging purposes it may be good to use:

    (defun f () (setf *global* local-value) (g))

So that when f is ran, you can call and debug independently g (or h or
other inner functions), with *global* bound to local-value.  When
debugging is done, you revert to the dynamic binding LET so that F
doesn't change its global binding.


Notice how dynamic binding actually mitigates the globalness of the
variable.

   (defvar *global* '())

   (defun g () (print *global*))
   
   (defun f ()
      (let ((*global* (cons 42 *global*)))
         (g))
      (values))

   (f)
   *global* --> ()

with a dynamic binding LET, the global value of the *global* variable is
not changed, just masked temporarily.  This is important also with
threads, where one can give a set of dynamic bindings which will be
local to the thread.



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

Re: Is there ever a good reason to create globals in Lisp?

[Yves S. G. <you...@gm...>]

I wouldn't say I "worry" about it.  The concept of not having global vars
at all (well, unless there's a damn good reason, avoid at all costs like
the 'goto') has been drilled down into my skull ever since I finished my
first C++ programming class in college.

>From a design perspective, this makes sense.  Fewer global vars are a good
thing.  They can give you quirky behavior unless you're super careful.  I
was more curious when you guys design Lisp apps, how you treat global
variables (yes, classes, functions, etc. are global as well, but this is
not exactly the same thing) in Lisp.  Even in imperative and OO languages
globals have a time and place (but very seldom and there has to be a damn
good reason why).  Do professional Lisp developers actively embrace them?
 Stay away from them like you would in other programming languages?  Or is
there some other middle-ground that I'm not aware of.

The example that you provide is exactly where I could see how things could
go very wrong in terms of undefined behavior :-) .  How are global variable
regarded in Lisp?

On Wed, Apr 25, 2012 at 12:09 AM, Pascal J. Bourguignon <
pj...@in...> wrote:

> "Yves S. Garret" <you...@gm...> writes:
>
> > Hi, going through Land of Lisp and I get to a part of the book where
> > you define global variables.  I realize that the author is trying to
> > educate the students about this, but is there ever a good reason for
> > globals in Lisp?  In Java, C/C++, PHP, etc. it's frowned down upon at
> > best.
>
> Functions, classes, types, constants, packages, etc,  are global
> bindings.
>
> There are so many things that have global names, why do you worry about
> a few global variables?
>
>
> Yes, there are good reasons to have global variables.
>
> The main one is to keep references to "persistent" data.  The scope of
> persistence being that of the lisp image (and remember that
> implementations provide operators to save the lisp images and reload
> them).
>
> Given the REPL, global variables allow passing data between two
> functions called independently, and with the programmer intervention at
> the REPL in the middle.
>
>
>    cl-user> (defvar *data*)
>    *data*
>    cl-user> (defun compute-phase-a () (setf *data* (random 42)))
>    compute-phase-a
>    cl-user> (defun compute-phase-b () (* 2 *data*))
>    compute-phase-b
>    cl-user> (compute-phase-a)
>    40
>    cl-user> *data*
>    40
>    cl-user> (compute-phase-b)
>    80
>    cl-user> *data*
>    40
>
>
> Also, in Common Lisp global variables defined with defvar and
> defparameter are special variables.  All the bindings involving the
> symbol naming them are dynamic bindings.  This allow passing pervasive
> parameter unconspicuously.
>
>    cl-user> (defun do-something () (print *data*) (terpri))
>    do-something
>    cl-user> (setf *print-base* 16.)
>    10
>    cl-user> (do-something)
>
>    28
>    nil
>    cl-user> (setf *print-base* 10.)
>    10
>    cl-user> (do-something)
>
>    40
>    nil
>
>
>
> --
> __Pascal Bourguignon__                     http://www.informatimago.com/
> A bad day in () is better than a good day in {}.
>

[ clisp-Bugs-3521402 ] ffcall-1.10 (or CVS head) fails to build x86_64 on OS X

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

Bugs item #3521402, was opened at 2012-04-25 11:26
Message generated for change (Tracker Item Submitted) made by nieder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521402&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: ffcall
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hanspeter Niederstrasser (nieder)
Assigned to: Bruno Haible (haible)
Summary: ffcall-1.10 (or CVS head) fails to build x86_64 on OS X

Initial Comment:
On OS X 10.6 (and 10.7) which builds as 64bit by default, ffcall fails to build with the following error:

./configure --host=x86_64-apple-darwin10 (explicit --host is needed or it misidentifies as a 32 bit and that also fails in a 64bit environment [1] )
...
cd avcall; make all
/bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
avcall-x86_64.c:5:Unknown pseudo-op: .type
avcall-x86_64.c:5:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:331:Unknown pseudo-op: .size
avcall-x86_64.c:331:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:332:unknown section type: @progbits
avcall-x86_64.c:332:Rest of line ignored. 1st junk character valued 46 (.).
avcall-x86_64.c:337:Unknown pseudo-op: .string
avcall-x86_64.c:337:Rest of line ignored. 1st junk character valued 34 (").
make[1]: *** [avcall-x86_64.lo] Error 1
make: *** [all] Error 2
### execution of make failed, exit code 2

Building as 32bit in a 32bit environment builds correctly.

[1] http://www.mail-archive.com/fin...@li.../msg31434.html

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

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

Re: thread priorities?

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

 > As of now - no. There is no way to specify or change threads priorities.
 > There are several caveats:
 > 1. We have to unify what priority means across platforms. On Win32 we
 > have just SetThreadPriority...

So far I don't know what exactly all of these things do.
But I guess the best that can be done is use what the platform
provides and put a short description and a link in the clisp doc.

 > 2. On Linux in order process to be allowed to change scheduling
 > policy/priority of thread it needs CAP_SYS_NICE capability
 > (http://linux.die.net/man/7/capabilities). By default it is available
 > only to privileged (root) processes. So if you just download/build
 > clisp and run it as non-root you will not be able to change the
 > priority.

I'd have expected that you start a process with a given priority
(and perhaps can change that from outside the process), and then
within the process you can set thread priorities up to the process
priority.

 > 3. IMO, generally playing with threads priorities is bad idea. There
 > are very few cases where it makes sense (e.g. communication with
 > devices when protocol timing is important). Also note that garbage
 > collection is "stop-the-world" i.e. all threads are suspended during
 > GC.

Yes, I see that GC is a concern.  I'd expect this to run in the
process (highest available) priority.

What I really wanted to do was start a separate thread to do a long
computation and LOWER its priority.
What I was observing is that my machine would become unresponsive 
during occasional data dumps.

 > I am not against implementing it but i would set the task with low
 > priority :).

I was imagining that it would at least be easy to do.

clisp-cvs Digest, Vol 69, Issue 5

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: setq->defparameter
      (cli...@li...)


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

Message: 1
Date: Tue, 24 Apr 2012 15:07:37 +0000
From: cli...@li...
Subject: clisp: setq->defparameter
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9c27cf4b8349
changeset: 15585:9c27cf4b834934065e44af723a9e5efab91b77d9
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 17:19:33 -0400
description:
setq->defparameter

diffstat:

 tests/ffi.tst |  46 +++++++++++++++++++++-------------------------
 1 files changed, 21 insertions(+), 25 deletions(-)



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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 69, Issue 5
****************************************

Re: thread priorities?

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

On 4/25/12, Don Cohen <don...@is...> wrote:
> Does clisp currently have any way to manipulate thread priorities?
> Would it be easy to support?  What are the reasons it's either harder
> than it looks or not a good idea?

As of now - no. There is no way to specify or change threads priorities.
There are several caveats:
1. We have to unify what priority means across platforms. On Win32 we
have just SetThreadPriority. On Linux each thread is treated as a
process by kernel scheduler and can be assigned a scheduling policy
and priority. Not sure how it is on BSD variants.
2. On Linux in order process to be allowed to change scheduling
policy/priority of thread it needs CAP_SYS_NICE capability
(http://linux.die.net/man/7/capabilities). By default it is available
only to privileged (root) processes. So if you just download/build
clisp and run it as non-root you will not be able to change the
priority.
3. IMO, generally playing with threads priorities is bad idea. There
are very few cases where it makes sense (e.g. communication with
devices when protocol timing is important). Also note that garbage
collection is "stop-the-world" i.e. all threads are suspended during
GC.

Note that most CL implementation ignore (or does not support) thread
priorities (https://bugs.launchpad.net/sbcl/+bug/547030,
http://www.lispworks.com/documentation/lw60/LW/html/lw-234.htm#pgfId-896875,
http://ccl.clozure.com/manual/chapter7.7.html#f_make-process).

I am not against implementing it but i would set the task with low priority :).

Vladimir

[ clisp-Bugs-3521153 ] mt: module/linux error

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

Bugs item #3521153, was opened at 2012-04-24 12:59
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521153&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: multithreading
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Vladimir Tzankov (vtz)
Summary: mt: module/linux error

Initial Comment:
$ make full-mod-check MODULES=bindings/glibc
...


(DEFPARAMETER *SIGACT* (SHOW (LINUX:signal-action-retrieve LINUX:SIGINT)))
#S(LINUX:sigaction :SA_HANDLER NIL :SA_MASK #S(LINUX:sigset_t :VAL #()) :SA_FLAGS 0 :SA_RESTORER #<FOREIGN-ADDRESS #x00002AB7D29E4420>)
EQL-OK: *SIGACT*
(DEFPARAMETER *SAVEHANDLER* (LINUX:sa-handler *SIGACT*))
EQL-OK: *SAVEHANDLER*
(DEFPARAMETER *SIGNALS* NIL)
EQL-OK: *SIGNALS*
(DEFUN TEST-HANDLER (S) (DECLARE (COMPILE)) (PUSH S *SIGNALS*))
EQL-OK: TEST-HANDLER
(PROGN (SETF (LINUX:sa-handler *SIGACT*) #'TEST-HANDLER) (LINUX:signal-action-install LINUX:SIGINT *SIGACT*))
EQL-OK: NIL
*SIGNALS*
EQL-OK: NIL
(KILL (PROCESS-ID) :SIGINT)
EQL-OK: *** - Condition of type SYSTEM::INTERRUPT-CONDITION.
Bye.


I guess the signal is received by a different thread than the thread which has the signal handler installed.
I wonder if this test could be adapted to the MT clisp build.
Maybe the correct solution is to remove the signal ffi code altogether and implement that separately?
Vladimir, this is your call.


GNU CLISP 2.49+ (2010-07-17) (built 3544263222) (memory 3544285389)
Software: GNU C 4.6.1 
gcc -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -pthread -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl /usr/lib/libavcall.a /usr/lib/libcallback.a  -lsigsegv  
SAFETY=3 TYPECODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
libffcall 1.11
Features: 
(READLINE REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES MT
 SOCKETS GENERIC-STREAMS SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /home/sds/src/clisp/current/build-mt-g/
User language: ENGLISH
Machine: X86_64 (X86_64) t520sds [127.0.1.1]


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

>Comment By: Vladimir Tzankov (vtz)
Date: 2012-04-25 04:15

Message:
Signals and threads do not play nice in general.
Synchronous signals (SIGSEGFAULT, SIGPIPE, SIGFPE) are always delivered
and
signal handler is invoked in the thread that caused them.
Asynchronous ones (all the rest - SIGINT, SIGHUP, SIGCONT, SIGALRM, etc)
are
quite different and there are two approaches to handle them .
1. If signal handler is present - it can be invoked in any thread
that has not blocked the delivered signal. This means that only single
thread
can deterministically register signal handler (unblock the signal and block
it
in all the other threads).
2. Use a dedicated thread to wait & handle all signals (via sigwait()) and
block
all signals in other threads. Big advantage here is that after sigwait()
returns you are allowed to use any function not just the async-signal safe
ones
as in the case with signal handler (for a list see:
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
).

CLISP uses the sigwait() approach. So even though you register a signal
handler
the delivery of this signal is blocked in all threads and sigwait() comes
to
action.

CLISP handles internally following asynchronous signals:
SIGCLD: to prevent zombies when forking
SIGINT: to act on CTRL-C
SIGALRM & SIGUSR2: to implement CALL-WITH-TIMEOUT
SIGUSR1: to implement THREAD-INTERRUPT
SIGWINCH: to update terminal line length
And all terminating signals (SIGQUIT, SIGABRT, SIGTERM, SIGKILL)
I am not sure it is good idea to allow installation of signals handlers
for
the above.

As general solution we may maintain a central registry of signal handlers 
and threads in which they have been registered (NIL for "does not care"
thread) 
and invoke these handlers from dedicated sigwait-ing thread via 
THREAD-INTERRUPT (the same way as CALL-WITH-TIMEOUT works now). 
If we go in this way there are two questions:
1. should we allow multiple threads to register handler for the same
signal?
2. should we allow single thread to register several handlers for the same
signal?

And all the above is POSIX specific of course.

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

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

[ clisp-Bugs-3514029 ] clisp does not build on OSX (Macports)

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

Bugs item #3514029, was opened at 2012-04-01 21:40
Message generated for change (Comment added) made by cstacy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&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: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Stacy (cstacy)
Assigned to: Bruno Haible (haible)
Summary: clisp does not build on OSX (Macports)

Initial Comment:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions: No

Model Name:   Mac mini
Model Identifier:     Macmini3,1
Processor Name:       Intel Core 2 Duo
Processor Speed:      2.26 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache:     3 MB
Memory:       8 GB
Bus Speed:    1.07 GHz
SMC Version (system): 1.35f1

There does not seem to be a custom GCC in Macports, so I guess it's using this one:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

 sudo port install clisp
--->  Computing dependencies for clisp
--->  Building clisp
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for clisp is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/main.log
Error: Status 1 encountered during processing.



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

>Comment By: Christopher Stacy (cstacy)
Date: 2012-04-24 22:59

Message:
I have located the MacPorts ticket.

https://trac.macports.org/ticket/33344



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

Comment By: Christopher Stacy (cstacy)
Date: 2012-04-24 22:15

Message:
"port" is the command that invokes the BSD package management system; it
corresponds to "rpm" or "yum" or "apt-get" on Linux distributions.   This
"port" is MacPorts aka DarwinPorts, which is the version for the Mac.

It is downloading the source, running configure, doing the make, and
install.

Apparently I am complaining in the wrong place, as the maintainer for the
package in this distribution is not here.  I will see if I can figure out
who is responsible for it.

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

Comment By: Sam Steingold (sds)
Date: 2012-04-24 21:58

Message:
What I see is that
- configure is not run
- gcc is not run
- compiled (*.fas) files are loaded into the run-time for the initial
memory dump.
the is indicative of a "make" in a pre-existing build directory.

I don't know what the "port" command does.
as long as you are reporting the bug in terms of it, I cannot help you.
could you please take a look at clisp/unix/INSTALL and try to follow the
instructions there?

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

Comment By: Christopher Stacy (cstacy)
Date: 2012-04-24 18:10

Message:
Can you be more specific about what makes you think there is
contamination?

I did this sequence:
port clean clisp
port uninstall clisp

Then I verified that the /opt/local/var/macports/build subdirectory for
clisp was now gone.

Then I did:
port install clisp

I get the same answer as before (same logs as I originally reported).
(This is what I did for the original report; I just now did the whole thing
over again).

I have the latest (as of 24-April-2012) "selfupdate" of MacPorts
installed.


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

Comment By: Sam Steingold (sds)
Date: 2012-04-24 12:52

Message:
:info:build ;;  Loading file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/work/clisp-2.49/src/clos-methcomb2.fas
...
:info:build *** - (SETF METHOD-COMBINATION-CHECK-OPTIONS): variable
NEW-VALUE has no value

this is extremely weird.
other log messages indicate that this is not a clean build.
please try a clean build in a separate directory.

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

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

[ clisp-Bugs-3514029 ] clisp does not build on OSX (Macports)

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

Bugs item #3514029, was opened at 2012-04-01 21:40
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&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: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Stacy (cstacy)
Assigned to: Bruno Haible (haible)
Summary: clisp does not build on OSX (Macports)

Initial Comment:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions: No

Model Name:   Mac mini
Model Identifier:     Macmini3,1
Processor Name:       Intel Core 2 Duo
Processor Speed:      2.26 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache:     3 MB
Memory:       8 GB
Bus Speed:    1.07 GHz
SMC Version (system): 1.35f1

There does not seem to be a custom GCC in Macports, so I guess it's using this one:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

 sudo port install clisp
--->  Computing dependencies for clisp
--->  Building clisp
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for clisp is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/main.log
Error: Status 1 encountered during processing.



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

>Comment By: Sam Steingold (sds)
Date: 2012-04-24 21:58

Message:
What I see is that
- configure is not run
- gcc is not run
- compiled (*.fas) files are loaded into the run-time for the initial
memory dump.
the is indicative of a "make" in a pre-existing build directory.

I don't know what the "port" command does.
as long as you are reporting the bug in terms of it, I cannot help you.
could you please take a look at clisp/unix/INSTALL and try to follow the
instructions there?

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

Comment By: Christopher Stacy (cstacy)
Date: 2012-04-24 18:10

Message:
Can you be more specific about what makes you think there is
contamination?

I did this sequence:
port clean clisp
port uninstall clisp

Then I verified that the /opt/local/var/macports/build subdirectory for
clisp was now gone.

Then I did:
port install clisp

I get the same answer as before (same logs as I originally reported).
(This is what I did for the original report; I just now did the whole thing
over again).

I have the latest (as of 24-April-2012) "selfupdate" of MacPorts
installed.


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

Comment By: Sam Steingold (sds)
Date: 2012-04-24 12:52

Message:
:info:build ;;  Loading file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/work/clisp-2.49/src/clos-methcomb2.fas
...
:info:build *** - (SETF METHOD-COMBINATION-CHECK-OPTIONS): variable
NEW-VALUE has no value

this is extremely weird.
other log messages indicate that this is not a clean build.
please try a clean build in a separate directory.

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

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

Re: Is there ever a good reason to create globals in Lisp?

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

"Yves S. Garret" <you...@gm...> writes:

> Hi, going through Land of Lisp and I get to a part of the book where
> you define global variables.  I realize that the author is trying to
> educate the students about this, but is there ever a good reason for
> globals in Lisp?  In Java, C/C++, PHP, etc. it's frowned down upon at
> best.

Functions, classes, types, constants, packages, etc,  are global
bindings.

There are so many things that have global names, why do you worry about
a few global variables?


Yes, there are good reasons to have global variables.

The main one is to keep references to "persistent" data.  The scope of
persistence being that of the lisp image (and remember that
implementations provide operators to save the lisp images and reload
them).

Given the REPL, global variables allow passing data between two
functions called independently, and with the programmer intervention at
the REPL in the middle.


    cl-user> (defvar *data*)
    *data*
    cl-user> (defun compute-phase-a () (setf *data* (random 42)))
    compute-phase-a
    cl-user> (defun compute-phase-b () (* 2 *data*))
    compute-phase-b
    cl-user> (compute-phase-a)
    40
    cl-user> *data*
    40
    cl-user> (compute-phase-b)
    80
    cl-user> *data*
    40


Also, in Common Lisp global variables defined with defvar and
defparameter are special variables.  All the bindings involving the
symbol naming them are dynamic bindings.  This allow passing pervasive
parameter unconspicuously. 

    cl-user> (defun do-something () (print *data*) (terpri))
    do-something
    cl-user> (setf *print-base* 16.)
    10
    cl-user> (do-something)

    28 
    nil
    cl-user> (setf *print-base* 10.)
    10
    cl-user> (do-something)

    40 
    nil



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

thread priorities?

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

Does clisp currently have any way to manipulate thread priorities?
Would it be easy to support?  What are the reasons it's either harder
than it looks or not a good idea?

Is there ever a good reason to create globals in Lisp?

[Yves S. G. <you...@gm...>]

Hi, going through Land of Lisp and I get to a part of the book where you
define global variables.  I realize that the author is trying to educate
the students about this, but is there ever a good reason for globals in
Lisp?  In Java, C/C++, PHP, etc. it's frowned down upon at best.

[ clisp-Bugs-3514029 ] clisp does not build on OSX (Macports)

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

Bugs item #3514029, was opened at 2012-04-01 21:40
Message generated for change (Comment added) made by cstacy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&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: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Stacy (cstacy)
Assigned to: Bruno Haible (haible)
Summary: clisp does not build on OSX (Macports)

Initial Comment:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions: No

Model Name:   Mac mini
Model Identifier:     Macmini3,1
Processor Name:       Intel Core 2 Duo
Processor Speed:      2.26 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache:     3 MB
Memory:       8 GB
Bus Speed:    1.07 GHz
SMC Version (system): 1.35f1

There does not seem to be a custom GCC in Macports, so I guess it's using this one:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

 sudo port install clisp
--->  Computing dependencies for clisp
--->  Building clisp
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for clisp is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/main.log
Error: Status 1 encountered during processing.



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

>Comment By: Christopher Stacy (cstacy)
Date: 2012-04-24 18:10

Message:
Can you be more specific about what makes you think there is
contamination?

I did this sequence:
port clean clisp
port uninstall clisp

Then I verified that the /opt/local/var/macports/build subdirectory for
clisp was now gone.

Then I did:
port install clisp

I get the same answer as before (same logs as I originally reported).
(This is what I did for the original report; I just now did the whole thing
over again).

I have the latest (as of 24-April-2012) "selfupdate" of MacPorts
installed.


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

Comment By: Sam Steingold (sds)
Date: 2012-04-24 12:52

Message:
:info:build ;;  Loading file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/work/clisp-2.49/src/clos-methcomb2.fas
...
:info:build *** - (SETF METHOD-COMBINATION-CHECK-OPTIONS): variable
NEW-VALUE has no value

this is extremely weird.
other log messages indicate that this is not a clean build.
please try a clean build in a separate directory.

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

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

[ clisp-Bugs-3521153 ] mt: module/linux error

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

Bugs item #3521153, was opened at 2012-04-24 12:59
Message generated for change (Tracker Item Submitted) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521153&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: multithreading
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Vladimir Tzankov (vtz)
Summary: mt: module/linux error

Initial Comment:
$ make full-mod-check MODULES=bindings/glibc
...


(DEFPARAMETER *SIGACT* (SHOW (LINUX:signal-action-retrieve LINUX:SIGINT)))
#S(LINUX:sigaction :SA_HANDLER NIL :SA_MASK #S(LINUX:sigset_t :VAL #()) :SA_FLAGS 0 :SA_RESTORER #<FOREIGN-ADDRESS #x00002AB7D29E4420>)
EQL-OK: *SIGACT*
(DEFPARAMETER *SAVEHANDLER* (LINUX:sa-handler *SIGACT*))
EQL-OK: *SAVEHANDLER*
(DEFPARAMETER *SIGNALS* NIL)
EQL-OK: *SIGNALS*
(DEFUN TEST-HANDLER (S) (DECLARE (COMPILE)) (PUSH S *SIGNALS*))
EQL-OK: TEST-HANDLER
(PROGN (SETF (LINUX:sa-handler *SIGACT*) #'TEST-HANDLER) (LINUX:signal-action-install LINUX:SIGINT *SIGACT*))
EQL-OK: NIL
*SIGNALS*
EQL-OK: NIL
(KILL (PROCESS-ID) :SIGINT)
EQL-OK: *** - Condition of type SYSTEM::INTERRUPT-CONDITION.
Bye.


I guess the signal is received by a different thread than the thread which has the signal handler installed.
I wonder if this test could be adapted to the MT clisp build.
Maybe the correct solution is to remove the signal ffi code altogether and implement that separately?
Vladimir, this is your call.


GNU CLISP 2.49+ (2010-07-17) (built 3544263222) (memory 3544285389)
Software: GNU C 4.6.1 
gcc -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -pthread -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl /usr/lib/libavcall.a /usr/lib/libcallback.a  -lsigsegv  
SAFETY=3 TYPECODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
libffcall 1.11
Features: 
(READLINE REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER LOGICAL-PATHNAMES MT
 SOCKETS GENERIC-STREAMS SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /home/sds/src/clisp/current/build-mt-g/
User language: ENGLISH
Machine: X86_64 (X86_64) t520sds [127.0.1.1]


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

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

[ clisp-Bugs-3514029 ] clisp does not build on OSX (Macports)

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

Bugs item #3514029, was opened at 2012-04-01 21:40
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3514029&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: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christopher Stacy (cstacy)
Assigned to: Bruno Haible (haible)
Summary: clisp does not build on OSX (Macports)

Initial Comment:
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions: No

Model Name:   Mac mini
Model Identifier:     Macmini3,1
Processor Name:       Intel Core 2 Duo
Processor Speed:      2.26 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache:     3 MB
Memory:       8 GB
Bus Speed:    1.07 GHz
SMC Version (system): 1.35f1

There does not seem to be a custom GCC in Macports, so I guess it's using this one:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

 sudo port install clisp
--->  Computing dependencies for clisp
--->  Building clisp
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for clisp is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/main.log
Error: Status 1 encountered during processing.



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

>Comment By: Sam Steingold (sds)
Date: 2012-04-24 12:52

Message:
:info:build ;;  Loading file
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_clisp/clisp/work/clisp-2.49/src/clos-methcomb2.fas
...
:info:build *** - (SETF METHOD-COMBINATION-CHECK-OPTIONS): variable
NEW-VALUE has no value

this is extremely weird.
other log messages indicate that this is not a clean build.
please try a clean build in a separate directory.

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

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

clisp-cvs Digest, Vol 69, Issue 4

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: * src/defs1.lisp (logical-pathname-translations):
      signal ... (cli...@li...)
   2. clisp: (html): check that sf/www exists before linking to it
      (cli...@li...)
   3. clisp: * src/makemake.in (XCFLAGS): do not add -Wimplicit
      when c... (cli...@li...)
   4. clisp: * modules/gdbm/gdbm.c (error_bad_type): fix
      declaration (... (cli...@li...)
   5. clisp: * modules/rawsock/rawsock.c (RAWSOCK:CONVERT-ADDRESS):
      ad... (cli...@li...)
   6. clisp: (end_error) [MULTITHREAD]: add "\n" to abort error
      messages (cli...@li...)


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

Message: 1
Date: Mon, 23 Apr 2012 15:46:39 +0000
From: cli...@li...
Subject: clisp: * src/defs1.lisp (logical-pathname-translations):
	signal ...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/30bffabdf5c9
changeset: 15576:30bffabdf5c9333936060f68512ef049ee04a8d8
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 10:10:56 -0400
description:
* src/defs1.lisp (logical-pathname-translations): signal TYPE-ERROR on
non-existent logical host as per ANSI [bug#3520570]

diffstat:

 src/ChangeLog      |  5 +++++
 src/NEWS           |  2 ++
 src/defs1.lisp     |  6 ++++--
 tests/ChangeLog    |  5 +++++
 tests/excepsit.tst |  3 +++
 5 files changed, 19 insertions(+), 2 deletions(-)



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

Message: 2
Date: Mon, 23 Apr 2012 15:46:40 +0000
From: cli...@li...
Subject: clisp: (html): check that sf/www exists before linking to it
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/42822198dbcc
changeset: 15577:42822198dbcc7ef67174f0cf6972feed280bbc9b
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 10:11:22 -0400
description:
(html): check that sf/www exists before linking to it

diffstat:

 doc/Makefile |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)



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

Message: 3
Date: Mon, 23 Apr 2012 16:57:18 +0000
From: cli...@li...
Subject: clisp: * src/makemake.in (XCFLAGS): do not add -Wimplicit
	when c...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/08dd64b5a86b
changeset: 15579:08dd64b5a86bb89142e210af7b5cb5e7f849b1a5
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 12:24:16 -0400
description:
* src/makemake.in (XCFLAGS): do not add -Wimplicit when compiling with C++:
"warning: command line option `-Wimplicit' is valid for C/ObjC but not for C++"

diffstat:

 src/ChangeLog   |  5 +++++
 src/makemake.in |  5 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)



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

Message: 4
Date: Mon, 23 Apr 2012 16:57:19 +0000
From: cli...@li...
Subject: clisp: * modules/gdbm/gdbm.c (error_bad_type): fix
	declaration (...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b5d49c3df763
changeset: 15580:b5d49c3df76364a58a4df6ccf1563a4a8d3267e2
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 12:27:13 -0400
description:
* modules/gdbm/gdbm.c (error_bad_type): fix declaration (for g++)

diffstat:

 modules/gdbm/gdbm.c |  2 +-
 src/ChangeLog       |  4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)



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

Message: 5
Date: Mon, 23 Apr 2012 16:57:21 +0000
From: cli...@li...
Subject: clisp: * modules/rawsock/rawsock.c (RAWSOCK:CONVERT-ADDRESS):
	ad...
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/11dbf0f6588e
changeset: 15581:11dbf0f6588ecaa8a33ae62170141d691a0e411b
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 12:27:52 -0400
description:
* modules/rawsock/rawsock.c (RAWSOCK:CONVERT-ADDRESS): add a cast

diffstat:

 modules/rawsock/rawsock.c |  2 +-
 src/ChangeLog             |  1 +
 2 files changed, 2 insertions(+), 1 deletions(-)



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

Message: 6
Date: Mon, 23 Apr 2012 16:57:22 +0000
From: cli...@li...
Subject: clisp: (end_error) [MULTITHREAD]: add "\n" to abort error
	messages
To: cli...@li...
Message-ID:
	<hg....@vz...g>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/633b37f7a9df
changeset: 15582:633b37f7a9df65fba0395cbbc17943fa29d0493c
user:      Sam Steingold <sd...@po...>
date:      2012-04-23 12:37:40 -0400
description:
(end_error) [MULTITHREAD]: add "\n" to abort error messages

diffstat:

 src/error.d |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)



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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 69, Issue 4
****************************************

[ clisp-Bugs-3520978 ] file-length non conforming.

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

Bugs item #3520978, was opened at 2012-04-24 04:54
Message generated for change (Settings changed) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3520978&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: ANSI compliance issue
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: file-length non conforming.

Initial Comment:
FILE-LENGTH should return the number of CHARACTER in a text file.  It returns instead the number of bytes.

Either:
1- do the right thing, read the whole file when the encoding isnot a 1-1 encoding, and count the characters, or
2- document that FILE-LENGTH on CHARACTER text files with non 1-1 encodings deviates from the standard.



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

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

[ clisp-Bugs-3520978 ] file-length non conforming.

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

Bugs item #3520978, was opened at 2012-04-24 04:54
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3520978&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: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: file-length non conforming.

Initial Comment:
FILE-LENGTH should return the number of CHARACTER in a text file.  It returns instead the number of bytes.

Either:
1- do the right thing, read the whole file when the encoding isnot a 1-1 encoding, and count the characters, or
2- document that FILE-LENGTH on CHARACTER text files with non 1-1 encodings deviates from the standard.



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

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

Re: Test failure on ARM

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

> * Jerry James <ybtnawreel@tznvy.pbz> [2012-04-23 10:56:12 -0600]:
>
> Thanks for the reply, Sam.

You are welcome.

> On Mon, Apr 23, 2012 at 10:51 AM, Sam Steingold <sd...@gn...> wrote:
>> Jerry, I am afraid your best bet is to try to fix libffcall yourself.
>> An alternative is, of course, to build CLISP without FFI.
>> Sam.
>
> I was afraid that would be the answer. :-)  I'll see if I can get
> access to some ARM hardware so I can get more details on the problem.

Please file the bug report on
https://savannah.gnu.org/bugs/?func=additem&group=libffcall
and put the patches there too!

> In the meantime, I'll turn FFI off for the ARM platform to get the
> builds going again.  Wish me luck.

Good luck!

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://memri.org http://www.memritv.org
http://iris.org.il http://camera.org http://openvotingconsortium.org
If You Want Breakfast In Bed, Sleep In the Kitchen.

Re: MT crash

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

> * Don Cohen <qba...@vf...3-vap.pbz> [2012-04-22 13:19:39 -0700]:
>
> [1]> (POSIX:SET-FILE-STAT "/tmp/test-dir0" :MODE 511 :UID 1 :GID 1)
> *** thread is going into lisp land without calling
> end_blocking_call();Aborted (core dumped)

Fixed in hg.
Thanks for the report.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://honestreporting.com http://dhimmi.com
http://thereligionofpeace.com http://iris.org.il http://palestinefacts.org
Lisp is a language for doing what you've been told is impossible. - Kent Pitman