From mikemac@mikemac.com Mon Feb 18 18:39:23 2002 Return-Path: Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IHdMi76072 for ; Mon, 18 Feb 2002 18:39:22 +0100 (CET) (envelope-from mikemac@mikemac.com) Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id JAA06834; Mon, 18 Feb 2002 09:34:01 -0800 Message-Id: <200202181734.JAA06834@saturn.mikemac.com> To: "Paul Werkowski" cc: cmucl-imp@cons.org Subject: Re: defsystem for 18d In-Reply-To: Your message of "Sat, 16 Feb 2002 20:28:06 EST." <000901c1b752$5c7d4780$0100a8c0@MOBY> Date: Mon, 18 Feb 2002 09:34:01 -0800 From: Mike McDonald e) keep the one we have until we can find a better one Mike McDonald mikemac@mikemac.com From toy@rtp.ericsson.se Mon Feb 18 19:19:13 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IIJCi76518 for ; Mon, 18 Feb 2002 19:19:12 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1IIJ8S03662 for ; Mon, 18 Feb 2002 12:19:11 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1IIJ7U20025 for ; Mon, 18 Feb 2002 12:19:08 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 18 12:19:06 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id NAA26529; Mon, 18 Feb 2002 13:21:20 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1IIJ5j01495; Mon, 18 Feb 2002 13:19:05 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: Lynn Quam Cc: cmucl-imp@cons.org, cracauer@cons.org Subject: Re: PATHNAME-VERSION bugs in MERGE-PATHNAMES and %ENUMERATE-FILES References: <200202180140.g1I1eQo04631@localhost.localdomain> From: Raymond Toy Date: 18 Feb 2002 13:19:05 -0500 In-Reply-To: <200202180140.g1I1eQo04631@localhost.localdomain> Message-ID: <4npu32ps9y.fsf@rtp.ericsson.se> Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Lynn" == Lynn Quam writes: Lynn> I believe that MERGE-PATHNAMES does not conform with the Lynn> Common Lisp HyperSpec which says: Lynn> If pathname does not specify a name, then the version, if Lynn> not provided, will come from default-pathname, just like Lynn> the other components. If pathname does specify a name, Lynn> then the version is not affected by default-pathname. If Lynn> this process leaves the version missing, the Lynn> default-version is used. This looks right and your solution implements this. Lynn> The function %ENUMERATE-FILES creates a pathname-string with the form: Lynn> (concatenate 'string file "." (quick-integer-to-string version)) Lynn> The resulting pathname-string does not contain tildes around Lynn> the version number. Changing to form to: Lynn> (concatenate 'string file ".~" (quick-integer-to-string version) "~") Lynn> appears to fix that problem I think this is also right, but I normally don't use version numbers on my files. Lynn> Modified version of both functions appear below. Thanks for the bug reports and fixes. Next time, can you supply context diffs or unified diffs? Makes it much easier to figure out what changed. Ray From toy@rtp.ericsson.se Mon Feb 18 19:22:28 2002 Return-Path: Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IIMSi76564 for ; Mon, 18 Feb 2002 19:22:28 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1IIMQh29570 for ; Mon, 18 Feb 2002 12:22:26 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1IIMPt16040 for ; Mon, 18 Feb 2002 12:22:26 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 18 12:22:24 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id NAA26581; Mon, 18 Feb 2002 13:24:38 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1IIMNn01502; Mon, 18 Feb 2002 13:22:23 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: "Paul Werkowski" Cc: Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> From: Raymond Toy Date: 18 Feb 2002 13:22:23 -0500 In-Reply-To: <000901c1b752$5c7d4780$0100a8c0@MOBY> Message-ID: <4nlmdqps4g.fsf@rtp.ericsson.se> Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Paul" == Paul Werkowski writes: Paul> So, what should we do about defsystem. The version in src/contrib Paul> has been out of date since the last release. Options are: Paul> a) Remove it from the repository and let people fetch it from Paul> sourceforge. Paul> b) Replace it with the current version at sourceforge. Paul> c) (b) + include a binary in the release. Paul> d) none of the above. Doe anyone actually use the version in src/contrib? I don't---I use the one from sourceforge in CLOCC. If no one really uses it, I choose a) (but leave a note saying where to get the sourceforge version). If people do use it, then b). Ray From emarsden@laas.fr Mon Feb 18 20:01:23 2002 Return-Path: Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IJ1Ni77028 for ; Mon, 18 Feb 2002 20:01:23 +0100 (CET) (envelope-from emarsden@laas.fr) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.12.1/8.12.1) with ESMTP id g1IJ1MAp022132 for ; Mon, 18 Feb 2002 20:01:22 +0100 (CET) Received: (from emarsden@localhost) by dukas.laas.fr (8.11.1/8.11.1) id g1IJ1MP20232; Mon, 18 Feb 2002 20:01:22 +0100 (MET) To: CMUCL implementors Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> From: Eric Marsden Organization: LAAS-CNRS http://www.laas.fr/ X-Message-Flags: f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ Date: Mon, 18 Feb 2002 20:01:22 +0100 In-Reply-To: <000901c1b752$5c7d4780$0100a8c0@MOBY> ("Paul Werkowski"'s message of "Sat, 16 Feb 2002 20:28:06 -0500") Message-ID: Lines: 15 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii There is another alternative, which is to remove the file from the repository, yet include a binary compiled from the CLOCC source in the release tarballs, for example as lib/cmucl/lib/subsystems/defsystem-library.FASL. This would be convenient for users (since DEFSYSTEM is quite widely used, despite the cruftiness of its code), yet avoid maintenance problems for us. For licensing reasons I think we would have to include in the release notes the URL from which the defsystem source code was downloaded, including the version number. -- Eric Marsden From Rob_MacLachlan@ram2.ius.cs.cmu.edu Mon Feb 18 20:19:40 2002 Return-Path: Received: from ram2.ius.cs.cmu.edu (RAM2.IUS.CS.CMU.EDU [128.2.211.170]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1IJJdi77275 for ; Mon, 18 Feb 2002 20:19:39 +0100 (CET) (envelope-from Rob_MacLachlan@ram2.ius.cs.cmu.edu) Message-Id: <200202181919.g1IJJdi77275@schlepper.zs64.net> Received: from ram2.ius.cs.cmu.edu ([127.0.0.1]) by ram2.ius.cs.cmu.edu id aa28790; 18 Feb 2002 14:19 EST To: jonathan@twopunks.org cc: cmucl-imp@cons.org Subject: Re: generic functions In-reply-to: Your message of Sat, 16 Feb 2002 18:43:05 -0500. <3C6EEE89.B8044FC4@twopunks.org> Reply-To: ram@ri.cmu.edu Date: Mon, 18 Feb 2002 14:18:58 -0500 From: Rob MacLachlan Are there any performance costs when using generic functions? Would I be better off using a defun with typecase? I'm guessing that the compiler can optimize more if I use generic functions, since it can be assured of the type. For sufficiently small numbers of cases, you will find non-generic functions to be faster. So if speed is the only consideration then explicit conditionals are promising. However, if speed were the only consideration you would probably be using C++. I suggest that you write the code in a natural way first, then if profiling proves it is necessary, you can selectively rip GFs out. Rob From toy@rtp.ericsson.se Mon Feb 18 21:06:45 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IK6ii77745 for ; Mon, 18 Feb 2002 21:06:44 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1IK6hS22903 for ; Mon, 18 Feb 2002 14:06:44 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1IK6ht19301 for ; Mon, 18 Feb 2002 14:06:43 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 18 14:06:42 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id PAA28468 for ; Mon, 18 Feb 2002 15:08:57 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1IK6dr01916; Mon, 18 Feb 2002 15:06:39 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: CMUCL Mailing List Subject: catch vop bug? From: Raymond Toy Date: 18 Feb 2002 15:06:38 -0500 Message-ID: <4ng03ypnap.fsf@rtp.ericsson.se> Lines: 77 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In the SBCL mailing list, the following (from Alexy Dejneka) was mentioned: 1. It is strange that %CATCH VOP accepts tag only in DESCRIPTOR-REG, while THROW accepts also in ANY-REG. 2. Even if these VOPs behave as they do now, it does not protect from setting non-portable tag: compiler accepts (CATCH (THE (UNSIGNED-BYTE 32) TAG) ...) /boxed value/ (but forbids (THE (UNSIGNED-BYTE 8))). I think we also have the same problem, but I'm not sure. He also supplied the attached patch. Something we should do? Ray Index: src/compiler/ctype.lisp =================================================================== RCS file: /mnt/hd2/lesha/cvsroot/sbcl/src/compiler/ctype.lisp,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 ctype.lisp --- src/compiler/ctype.lisp 2002/01/14 05:56:02 1.1.1.5 +++ src/compiler/ctype.lisp 2002/02/02 09:45:28 @@ -759,3 +759,13 @@ (dolist (ref (leaf-refs var)) (derive-node-type ref type))))) t)))))) + +;;; + +(defun check-catch-tag-type (tag) + (declare (type continuation tag)) + (when (csubtypep (continuation-type tag) + (specifier-type '(or number character))) + (compiler-style-warn "using ~S of type (OR NUMBER CHARACTER) ~ + as a catch tag is non-portable" + (continuation-source tag)))) Index: src/compiler/ir2tran.lisp =================================================================== RCS file: /mnt/hd2/lesha/cvsroot/sbcl/src/compiler/ir2tran.lisp,v retrieving revision 1.1.1.14 diff -u -r1.1.1.14 ir2tran.lisp --- src/compiler/ir2tran.lisp 2002/02/01 04:54:42 1.1.1.14 +++ src/compiler/ir2tran.lisp 2002/02/02 07:44:37 @@ -1368,6 +1368,7 @@ (defun ir2-convert-throw (node block) (declare (type mv-combination node) (type ir2-block block)) (let ((args (basic-combination-args node))) + (check-catch-tag-type (first args)) (vop* throw node block ((continuation-tn node block (first args)) (reference-tn-list @@ -1428,6 +1429,7 @@ ;;; Set up the unwind block for these guys. (defoptimizer (%catch ir2-convert) ((info-cont tag) node block) + (check-catch-tag-type tag) (emit-nlx-start node block (continuation-value info-cont) tag)) (defoptimizer (%unwind-protect ir2-convert) ((info-cont cleanup) node block) (emit-nlx-start node block (continuation-value info-cont) nil)) Index: src/compiler/x86/nlx.lisp =================================================================== RCS file: /mnt/hd2/lesha/cvsroot/sbcl/src/compiler/x86/nlx.lisp,v retrieving revision 1.1.1.4 diff -u -r1.1.1.4 nlx.lisp --- src/compiler/x86/nlx.lisp 2002/01/31 04:18:37 1.1.1.4 +++ src/compiler/x86/nlx.lisp 2002/02/02 06:32:25 @@ -92,7 +92,7 @@ ;;; tag, and link the block into the CURRENT-CATCH list (define-vop (make-catch-block) (:args (tn) - (tag :scs (descriptor-reg) :to (:result 1))) + (tag :scs (any-reg descriptor-reg) :to (:result 1))) (:info entry-label) (:results (block :scs (any-reg))) (:temporary (:sc descriptor-reg) temp) From jonathan@twopunks.org Mon Feb 18 21:11:25 2002 Return-Path: Received: from wh1.baymountain.net (wh1.baymountain.net [63.102.49.17]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IKBPi77787 for ; Mon, 18 Feb 2002 21:11:25 +0100 (CET) (envelope-from jonathan@twopunks.org) Received: from twopunks.org ([207.50.24.5]) (authenticated) by wh1.baymountain.net (8.10.0/8.10.0) with ESMTP id g1IKBOP30077 for ; Mon, 18 Feb 2002 15:11:24 -0500 X-Authentication-Warning: wh1.baymountain.net: cyrus owned process doing -bs Message-ID: <3C715FA2.5070407@twopunks.org> Date: Mon, 18 Feb 2002 15:10:10 -0500 From: Jonathan Simpson User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.2) Gecko/20011002 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: cmucl-imp@cons.org Subject: struct type-checking Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Using the following structure definition, cmucl does not give me a type error when I run (make-matrix :i 4.0). Clisp, on the other hand, does what I expect and complains that 4.0 is not a fixnum. The only time I can get cmucl to complain is if I try to set the value of a floating point slot with another type. This seems to contradict the user manual's statements(5.2.8) about strict type-checking in constructors. (defstruct matrix (i 4 :type fixnum) ;rows (j 4 :type fixnum) ;columns a) ;data Can someone here explain where i've gone wrong? Thanks, Jonathan From pmai@pmsf.de Mon Feb 18 23:09:25 2002 Return-Path: Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IM9Pi79151 for ; Mon, 18 Feb 2002 23:09:25 +0100 (CET) (envelope-from pmai@pmsf.de) Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16cvyK-0007wC-06; Mon, 18 Feb 2002 23:09:20 +0100 Received: from dent.bln.pmsf.de (320001904523-0001@[62.155.170.122]) by fmrl06.sul.t-online.com with esmtp id 16cvy8-2BaD68C; Mon, 18 Feb 2002 23:09:08 +0100 Received: from orion (nobody@orion.bln.pmsf.de [192.168.42.10]) by dent.bln.pmsf.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id XAA02456 for ; Mon, 18 Feb 2002 23:09:08 +0100 X-Authentication-Warning: dent.bln.pmsf.de: Host nobody@orion.bln.pmsf.de [192.168.42.10] claimed to be orion Received: (nullmailer pid 15247 invoked by uid 1000); Mon, 18 Feb 2002 22:09:08 -0000 Sender: dent@pmsf.net To: cmucl-imp@cons.org Subject: Re: catch vop bug? References: <4ng03ypnap.fsf@rtp.ericsson.se> From: "Pierre R\. Mai" Date: 18 Feb 2002 23:09:08 +0100 In-Reply-To: <4ng03ypnap.fsf@rtp.ericsson.se> Message-ID: <87it8u5tob.fsf@orion.bln.pmsf.de> Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 320001904523-0001@t-dialin.net Raymond Toy writes: > In the SBCL mailing list, the following (from Alexy Dejneka) was > mentioned: > > 1. It is strange that %CATCH VOP accepts tag only in DESCRIPTOR-REG, > while THROW accepts also in ANY-REG. We fixed this problem (reported by William Newman) in November, by doing the nlx.lisp fix that is contained in the patch below (which I suspect was based on the CMU CL fix). The details were discussed by Bill, Douglas and me on cmucl-imp/help. > 2. Even if these VOPs behave as they do now, it does not protect from > setting non-portable tag: compiler accepts > (CATCH (THE (UNSIGNED-BYTE 32) TAG) ...) /boxed value/ > (but forbids (THE (UNSIGNED-BYTE 8))). As far as I'm aware we are not allowed to prevent people from using any object they like as a catch tag. Producing a compile-time (style-)warning when people use numbers (which are only guaranteed to be "reliably" comparable by eql) seems a good idea, so I'll probably commit a similar warning fix... Regs, Pierre. -- Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein From toy@rtp.ericsson.se Tue Feb 19 00:07:46 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1IN7ji79680 for ; Tue, 19 Feb 2002 00:07:46 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1IN7iS04895 for ; Mon, 18 Feb 2002 17:07:45 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1IN7iU12415 for ; Mon, 18 Feb 2002 17:07:44 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 18 17:07:43 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id SAA01554; Mon, 18 Feb 2002 18:09:57 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1IN7g602081; Mon, 18 Feb 2002 18:07:42 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: "Pierre R\. Mai" Cc: cmucl-imp@cons.org Subject: Re: catch vop bug? References: <4ng03ypnap.fsf@rtp.ericsson.se> <87it8u5tob.fsf@orion.bln.pmsf.de> From: Raymond Toy Date: 18 Feb 2002 18:07:42 -0500 In-Reply-To: <87it8u5tob.fsf@orion.bln.pmsf.de> Message-ID: <4ny9hqo0ch.fsf@rtp.ericsson.se> Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Pierre" == Pierre R\ Mai writes: Pierre> Raymond Toy writes: >> In the SBCL mailing list, the following (from Alexy Dejneka) was >> mentioned: >> >> 1. It is strange that %CATCH VOP accepts tag only in DESCRIPTOR-REG, >> while THROW accepts also in ANY-REG. Pierre> We fixed this problem (reported by William Newman) in November, by Pierre> doing the nlx.lisp fix that is contained in the patch below (which I Pierre> suspect was based on the CMU CL fix). The details were discussed by Pierre> Bill, Douglas and me on cmucl-imp/help. I see that now. My memory is going, Dave. I can feel it. (I think that's what HAL said. :-) ) Pierre> As far as I'm aware we are not allowed to prevent people from using Pierre> any object they like as a catch tag. Producing a compile-time Pierre> (style-)warning when people use numbers (which are only guaranteed to Pierre> be "reliably" comparable by eql) seems a good idea, so I'll probably Pierre> commit a similar warning fix... Sounds good. Ray From toy@rtp.ericsson.se Tue Feb 19 00:22:38 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1INMbi79970 for ; Tue, 19 Feb 2002 00:22:37 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1INMaS09052 for ; Mon, 18 Feb 2002 17:22:36 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1INMaU17130 for ; Mon, 18 Feb 2002 17:22:36 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 18 17:22:35 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id SAA01754; Mon, 18 Feb 2002 18:24:48 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1INMXA02097; Mon, 18 Feb 2002 18:22:33 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: dtc@scieneer.com Cc: William Harold Newman , cmucl-imp@cons.org Subject: Re: can't compile CATCH 0 References: <20011129072254.A24244@rootless> <3C0651B4.A2FB5069@scieneer.com> From: Raymond Toy Date: 18 Feb 2002 18:22:33 -0500 In-Reply-To: <3C0651B4.A2FB5069@scieneer.com> Message-ID: <4nsn7ynznq.fsf@rtp.ericsson.se> Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "dtc" == dtc writes: dtc> William Harold Newman wrote: dtc> ... >> (defun foo () >> (catch 0 >> (print 1331))) dtc> ... >> Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: >> the function C::VOP-PARSE-OR-LOSE is undefined. dtc> o Add 'any-reg to the 'tag argument SCs of the 'make-catch-block VOP dtc> allowing the tag to be a fixnum. dtc> compiler/x86/nlx.lisp: dtc> (define-vop (make-catch-block) dtc> (:args (tn) dtc> (tag :scs (descriptor-reg any-reg) :to (:result 1))) dtc> (:info entry-label) dtc> ... Since a descriptor-reg is an any-reg, can this just be any-reg? Or is it important to specify both in that order? Ray From pw@snoopy.mv.com Tue Feb 19 01:07:42 2002 Return-Path: Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1J07fi80652 for ; Tue, 19 Feb 2002 01:07:41 +0100 (CET) (envelope-from pw@snoopy.mv.com) Received: from MOBY (snoopy.mv.com [207.22.43.15]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with SMTP id TAA19616; Mon, 18 Feb 2002 19:07:36 -0500 (EST) Message-ID: <003d01c1b8d9$5e6f21c0$0100a8c0@MOBY> From: "Paul Werkowski" To: "Jonathan Simpson" , References: <3C715FA2.5070407@twopunks.org> Subject: Re: struct type-checking Date: Mon, 18 Feb 2002 19:07:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 | | Using the following structure definition, cmucl does not give me a type | error when I run (make-matrix :i 4.0). Clisp, on the other hand, does | what I expect and complains that 4.0 is not a fixnum. The only time I | can get cmucl to complain is if I try to set the value of a floating | point slot with another type. This seems to contradict the user | manual's statements(5.2.8) about strict type-checking in constructors. | | | (defstruct matrix | (i 4 :type fixnum) ;rows | (j 4 :type fixnum) ;columns | a) ;data | | | Can someone here explain where i've gone wrong? You must not have compiled that form. The user manual is no doubt describing compiled code. Paul From amoroso@mclink.it Tue Feb 19 09:48:59 2002 Return-Path: Received: from mail.mclink.it (net128-053.mclink.it [195.110.128.53]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1J8mwi85625 for ; Tue, 19 Feb 2002 09:48:58 +0100 (CET) (envelope-from amoroso@mclink.it) Received: from net145-078.mclink.it (net145-078.mclink.it [195.110.145.78]) by mail.mclink.it (8.11.0/8.9.0) with SMTP id g1J8mti05200 for ; Tue, 19 Feb 2002 09:48:56 +0100 (CET) From: Paolo Amoroso To: CMUCL implementors Subject: Re: defsystem for 18d Date: Tue, 19 Feb 2002 09:44:43 +0100 Organization: Paolo Amoroso - Milan, ITALY Message-ID: References: <000901c1b752$5c7d4780$0100a8c0@MOBY> In-Reply-To: X-Mailer: Forte Agent 1.6/32.525 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Mon, 18 Feb 2002 20:01:22 +0100, Eric Marsden wrote: > This would be convenient for users (since DEFSYSTEM is quite widely > used, despite the cruftiness of its code), yet avoid maintenance > problems for us. Although MK:DEFSYSTEM is widely used, there are so many--possibly incompatible--versions around that users may be confused if a system does not compile with a particular one. Here are a few MK:DEFSYSTEM versions: - CMU CL - CMU Common Lisp Repository - CLOCC - CLC - ACL - CL-HTTP Wouldn't it be better to just tell users where to find the one which is most actively maintained? Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://www.paoloamoroso.it/ency/README [http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/] From dan@telent.net Tue Feb 19 11:15:23 2002 Return-Path: Received: from noetbook.telent.net (pc1-oxfo6-0-cust37.oxf.cable.ntl.com [80.3.240.37]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JAFNi86370 for ; Tue, 19 Feb 2002 11:15:23 +0100 (CET) (envelope-from dan@telent.net) Received: from dan by noetbook.telent.net with local (Exim 3.33 #1 (Debian)) id 16d7It-0006zU-00; Tue, 19 Feb 2002 10:15:19 +0000 To: Paolo Amoroso Cc: CMUCL implementors Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> From: Daniel Barlow Date: 19 Feb 2002 10:15:19 +0000 In-Reply-To: Message-ID: <87664tzsjs.fsf@noetbook.telent.net> Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Paolo Amoroso writes: > Although MK:DEFSYSTEM is widely used, there are so many--possibly > incompatible--versions around that users may be confused if a system does > not compile with a particular one. Here are a few MK:DEFSYSTEM versions: > > - CMU CL > - CMU Common Lisp Repository > - CLOCC > - CLC > - ACL > - CL-HTTP As far as I know, the only one of these that sees active maintenance is the CLOCC one, and possible the CLC version. As Peter is both a CLOCC maintainer and the CLC maintainer, I hope he can keep those two in sync, though ... > Wouldn't it be better to just tell users where to find the one which is > most actively maintained? Speaking as a user, this is the option I'd be happiest with. I don't think you need distribute a compiled version; its hardly rocket science (as compared to, ahem, CMUCL itself ;-) to build anyway. -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources From marcoxa@cs.nyu.edu Tue Feb 19 16:23:58 2002 Return-Path: Received: from octagon.mrl.nyu.edu (OCTAGON.MRL.NYU.EDU [128.122.47.83]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JFNvi88873 for ; Tue, 19 Feb 2002 16:23:58 +0100 (CET) (envelope-from marcoxa@cs.nyu.edu) Received: (from marcoxa@localhost) by octagon.mrl.nyu.edu (8.11.6/8.9.3) id g1JFNt819675; Tue, 19 Feb 2002 10:23:55 -0500 Date: Tue, 19 Feb 2002 10:23:55 -0500 Message-Id: <200202191523.g1JFNt819675@octagon.mrl.nyu.edu> X-Authentication-Warning: octagon.mrl.nyu.edu: marcoxa set sender to marcoxa@cs.nyu.edu using -f From: Marco Antoniotti To: cmucl-imp@cons.org In-reply-to: <000901c1b752$5c7d4780$0100a8c0@MOBY> (pw@snoopy.mv.com) Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> > From: "Paul Werkowski" > Date: Sat, 16 Feb 2002 20:28:06 -0500 > Content-type: text/plain; charset=iso-8859-1 > X-Priority: 3 > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > X-listar-version: Listar v1.0.0 > Sender: cmucl-imp-bounce@cons.org > X-original-sender: pw@snoopy.mv.com > Precedence: bulk > X-list: cmucl-imp > Content-Length: 332 > > > So, what should we do about defsystem. The version in src/contrib > has been out of date since the last release. Options are: > > a) Remove it from the repository and let people fetch it from > sourceforge. > > b) Replace it with the current version at sourceforge. > > c) (b) + include a binary in the release. This is the way to go. MK:DEFSYSTEM has been pretty stable w.r.t. CMUCL (and SBCL) for some time now. The version from the CLOCC CVS (BTW. there is a CVS module in the CLOCC called `defsystem-3.x') is the one we want in here. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. From marcoxa@cs.nyu.edu Tue Feb 19 16:31:46 2002 Return-Path: Received: from octagon.mrl.nyu.edu (OCTAGON.MRL.NYU.EDU [128.122.47.83]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JFVji88980 for ; Tue, 19 Feb 2002 16:31:45 +0100 (CET) (envelope-from marcoxa@cs.nyu.edu) Received: (from marcoxa@localhost) by octagon.mrl.nyu.edu (8.11.6/8.9.3) id g1JFVhq19695; Tue, 19 Feb 2002 10:31:43 -0500 Date: Tue, 19 Feb 2002 10:31:43 -0500 Message-Id: <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> X-Authentication-Warning: octagon.mrl.nyu.edu: marcoxa set sender to marcoxa@cs.nyu.edu using -f From: Marco Antoniotti To: amoroso@mclink.it CC: cmucl-imp@cons.org In-reply-to: (message from Paolo Amoroso on Tue, 19 Feb 2002 09:44:43 +0100) Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> > From: Paolo Amoroso > Date: Tue, 19 Feb 2002 09:44:43 +0100 > Organization: Paolo Amoroso - Milan, ITALY > Content-type: text/plain; charset=us-ascii > X-listar-version: Listar v1.0.0 > Sender: cmucl-imp-bounce@cons.org > X-original-sender: amoroso@mclink.it > Precedence: bulk > X-list: cmucl-imp > Content-Length: 775 > > > On Mon, 18 Feb 2002 20:01:22 +0100, Eric Marsden wrote: > > > This would be convenient for users (since DEFSYSTEM is quite widely > > used, despite the cruftiness of its code), yet avoid maintenance > > problems for us. > > Although MK:DEFSYSTEM is widely used, there are so many--possibly > incompatible--versions around that users may be confused if a system does > not compile with a particular one. Here are a few MK:DEFSYSTEM > versions: That is a problem. However. > - CMU CL > - CMU Common Lisp Repository > - CLOCC This is the main reference one. > - CLC > - ACL Myself are unaware of these. What is CLC? What about ACL? I don't recall finding one in the Franz ACL distribution. > - CL-HTTP > > Wouldn't it be better to just tell users where to find the one which is > most actively maintained? Maybe. The one that is better maintained is the one in the CLOCC. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. From rogers-cmucl-imp@rgrjr.dyndns.org Tue Feb 19 17:17:03 2002 Return-Path: Received: from rgrjr.dyndns.org (h0050da615e79.ne.mediaone.net [66.31.124.64]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1JGH3i89587 for ; Tue, 19 Feb 2002 17:17:03 +0100 (CET) (envelope-from rogers-cmucl-imp@rgrjr.dyndns.org) Received: (qmail 2162 invoked by uid 500); 19 Feb 2002 16:16:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.31342.276666.103235@rgrjr.dyndns.org> Date: Tue, 19 Feb 2002 11:16:46 -0500 From: Bob Rogers To: Marco Antoniotti , Paolo Amoroso CC: cmucl-imp@cons.org Subject: Re: defsystem for 18d In-Reply-To: <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> References: <000901c1b752$5c7d4780$0100a8c0@MOBY> <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> X-Mailer: VM 6.89 under Emacs 20.7.1 From: Marco Antoniotti Date: Tue, 19 Feb 2002 10:31:43 -0500 > From: Paolo Amoroso > Date: Tue, 19 Feb 2002 09:44:43 +0100 > > ... > - CLC > - ACL Myself are unaware of these. What is CLC? What about ACL? I don't recall finding one in the Franz ACL distribution. Neither did I, until I looked just now. It's in contrib/mkant-cmu/, along with the other MK utilities (logical pathnames, xref, etc.), but the files are all dated 1993. Furthermore, only source is provided, and defsystem.lisp won't compile without error due to package problems, so they appear to be completely unmaintained, as opposed to "merely" unsupported. You might want to drop this one from the list, except perhaps to mention it as a historical variant. -- Bob Rogers ESS Technology, Inc. http://rgrjr.dyndns.org/icancad/ From cracauer Tue Feb 19 17:17:33 2002 Return-Path: Received: (from cracauer@localhost) by schlepper.zs64.net (8.11.1/8.11.1) id g1JGHXa89606; Tue, 19 Feb 2002 17:17:33 +0100 (CET) (envelope-from cracauer) Date: Tue, 19 Feb 2002 11:17:33 -0500 From: Martin Cracauer To: Paul Werkowski Cc: Jonathan Simpson , cmucl-imp@cons.org Subject: Re: struct type-checking Message-ID: <20020219111733.A89514@cons.org> References: <3C715FA2.5070407@twopunks.org> <003d01c1b8d9$5e6f21c0$0100a8c0@MOBY> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c1b8d9$5e6f21c0$0100a8c0@MOBY>; from pw@snoopy.mv.com on Mon, Feb 18, 2002 at 07:07:06PM -0500 There is a hole in the structure type checking. The following Lisp file has identical code once in a defun-let and once in a toplevel let. The type check for compiled code and safety 3 (on x86) does not work for the in-defun case, but it works for the toplevel let. Sample output of this code: ;; defun-let Is (1 . 1) of type CONS a cons? => NIL ;; toplevel let. It also got a compiler warning before Type-error in C::BYTE-TYPE-CHECK-XOP: (1 . 1) is not of type (OR FIXNUM NULL) (defstruct foo (bla 0 :type fixnum)) (defun f () (let ((foo (make-foo))) (setf (foo-bla foo) '(1 . 1)) (format t "Is ~a of type ~a a cons? => ~a~%" (foo-bla foo) (type-of (foo-bla foo)) (consp (foo-bla foo))))) (f) (let ((foo (make-foo))) (setf (foo-bla foo) '(1 . 1)) (format t "Is ~a of type ~a a cons? => ~a~%" (foo-bla foo) (type-of (foo-bla foo)) (consp (foo-bla foo))))) From mikemac@mikemac.com Tue Feb 19 17:48:54 2002 Return-Path: Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JGmri90046 for ; Tue, 19 Feb 2002 17:48:53 +0100 (CET) (envelope-from mikemac@mikemac.com) Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id IAA11455; Tue, 19 Feb 2002 08:43:24 -0800 Message-Id: <200202191643.IAA11455@saturn.mikemac.com> To: Bob Rogers cc: Marco Antoniotti , Paolo Amoroso , cmucl-imp@cons.org Subject: Re: defsystem for 18d In-Reply-To: Your message of "Tue, 19 Feb 2002 11:16:46 EST." <15474.31342.276666.103235@rgrjr.dyndns.org> Date: Tue, 19 Feb 2002 08:43:24 -0800 From: Mike McDonald >Date: Tue, 19 Feb 2002 11:16:46 -0500 >From: Bob Rogers >To: Marco Antoniotti , Paolo Amoroso >Subject: Re: defsystem for 18d > > > From: Marco Antoniotti > Date: Tue, 19 Feb 2002 10:31:43 -0500 > > > From: Paolo Amoroso > > Date: Tue, 19 Feb 2002 09:44:43 +0100 > > > > ... > > - CLC > > - ACL > > Myself are unaware of these. What is CLC? What about ACL? I don't > recall finding one in the Franz ACL distribution. > >Neither did I, until I looked just now. It's in contrib/mkant-cmu/, >along with the other MK utilities (logical pathnames, xref, etc.), but >the files are all dated 1993. Furthermore, only source is provided, and >defsystem.lisp won't compile without error due to package problems, so >they appear to be completely unmaintained, as opposed to "merely" >unsupported. You might want to drop this one from the list, except >perhaps to mention it as a historical variant. ACL used to come with defsystem compiled in. It's the Symbolics compatible version, not the MK version. Personally, I prefer the Symbolics version. mars=>acl Loading /usr/ACL5.0/libacl503.so. Mapping /usr/ACL5.0/acl.dxl...done. Mapping /usr/ACL5.0/acl503.epll. Allegro CL Trial Edition 5.0 [Linux/X86] (8/29/98 10:57) Copyright (C) 1985-1998, Franz Inc., Berkeley, CA, USA. All Rights Reserved. ;; Optimization settings: safety 1, space 1, speed 1, debug 2. ;; For a complete description of all compiler switches given the ;; current optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS). USER(1): (apropos 'defsystem) DEFSYS::NON-DEFSYSTEM-OBJECT DEFSYS::UNDEFSYSTEM-1 [function] (SYSTEM-NAME) DEFSYS::DEFSYSTEM-BASE-CLASS DEFSYS:DEFSYSTEM-1 [function] (SYSTEM-NAME OPTIONS MODULES) UNDEFSYSTEM [macro] (SYSTEM-NAME) DEFSYSTEM [macro] (SYSTEM-NAME OPTIONS &BODY MODULES) :DEFSYSTEM value: :DEFSYSTEM USER(2): (exit) ; Exiting Lisp Mike McDonald mikemac@mikemac.com From marcoxa@cs.nyu.edu Tue Feb 19 18:36:25 2002 Return-Path: Received: from octagon.mrl.nyu.edu (OCTAGON.MRL.NYU.EDU [128.122.47.83]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JHaOi90545 for ; Tue, 19 Feb 2002 18:36:24 +0100 (CET) (envelope-from marcoxa@cs.nyu.edu) Received: (from marcoxa@localhost) by octagon.mrl.nyu.edu (8.11.6/8.9.3) id g1JHaNO20449; Tue, 19 Feb 2002 12:36:23 -0500 Date: Tue, 19 Feb 2002 12:36:23 -0500 Message-Id: <200202191736.g1JHaNO20449@octagon.mrl.nyu.edu> X-Authentication-Warning: octagon.mrl.nyu.edu: marcoxa set sender to marcoxa@cs.nyu.edu using -f From: Marco Antoniotti To: cmucl-imp@cons.org In-reply-to: <200202191643.IAA11455@saturn.mikemac.com> (message from Mike McDonald on Tue, 19 Feb 2002 08:43:24 -0800) Subject: Re: defsystem for 18d References: <200202191643.IAA11455@saturn.mikemac.com> > cc: Marco Antoniotti , Paolo Amoroso , > cmucl-imp@cons.org > Date: Tue, 19 Feb 2002 08:43:24 -0800 > From: Mike McDonald > Content-Length: 2059 > > > >Date: Tue, 19 Feb 2002 11:16:46 -0500 > >From: Bob Rogers > >To: Marco Antoniotti , Paolo Amoroso > >Subject: Re: defsystem for 18d > > > > > > From: Marco Antoniotti > > Date: Tue, 19 Feb 2002 10:31:43 -0500 > > > > > From: Paolo Amoroso > > > Date: Tue, 19 Feb 2002 09:44:43 +0100 > > > > > > ... > > > - CLC > > > - ACL > > > > Myself are unaware of these. What is CLC? What about ACL? I don't > > recall finding one in the Franz ACL distribution. > > > >Neither did I, until I looked just now. It's in contrib/mkant-cmu/, > >along with the other MK utilities (logical pathnames, xref, etc.), but > >the files are all dated 1993. Furthermore, only source is provided, and > >defsystem.lisp won't compile without error due to package problems, so > >they appear to be completely unmaintained, as opposed to "merely" > >unsupported. You might want to drop this one from the list, except > >perhaps to mention it as a historical variant. > > ACL used to come with defsystem compiled in. It's the Symbolics > compatible version, not the MK version. Personally, I prefer the > Symbolics version. Preferences apart, AFAIK, the current ACL DEFSYSTEM seems rather different from the Symbolics version. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. From pw@snoopy.mv.com Tue Feb 19 23:42:09 2002 Return-Path: Received: from snoopy.mv.com (snoopy.mv.com [207.22.43.15]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1JMg7i93736 for ; Tue, 19 Feb 2002 23:42:07 +0100 (CET) (envelope-from pw@snoopy.mv.com) Received: from snoopy.mv.com (localhost [127.0.0.1]) by snoopy.mv.com (8.11.6/8.11.6) with ESMTP id g1JMfa703916 for ; Tue, 19 Feb 2002 17:41:36 -0500 (EST) (envelope-from pw@snoopy.mv.com) Message-Id: <200202192241.g1JMfa703916@snoopy.mv.com> To: cmucl-imp@cons.org Subject: CLX shape extension Date: Tue, 19 Feb 2002 17:41:36 -0500 From: Paul Werkowski ------- Forwarded Message Return-Path: zhivago@iglou.com Delivery-Date: Thu Jan 28 10:02:46 1999 Received: from localhost (localhost [127.0.0.1]) by snoopy.mv.com (8.8.8/8.8.8) with ESMTP id KAA02027 for ; Thu, 28 Jan 1999 10:02:43 -0500 (EST) (envelope-from zhivago@iglou.com) Received: from mail.mv.net by fetchmail-4.6.0 IMAP for (single-drop); Thu, 28 Jan 1999 10:02:44 EST Received: from iglou.com (sendmail@shell1.iglou.com [192.107.41.17]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id IAA09722 for ; Thu, 28 Jan 1999 08:17:03 -0500 (EST) Received: from zhivago by iglou.com with local (8.9.1/8.9.1) id 105rL0-0005OM-00; Thu, 28 Jan 1999 08:18:26 -0500 Subject: Re: CLX Shape Extension To: pw@snoopy.mv.com (Paul Werkowski) Date: Thu, 28 Jan 1999 08:18:26 -0500 (EST) In-Reply-To: <199901271637.LAA04603@snoopy.mv.com> from "Paul Werkowski" at Jan 27, 99 11:37:43 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-Id: From: BRIAN SPILSBURY > Yes, please send it here and I will get it into the repository. This is small enough to mail plaintext, fairly simple, and incomplete, and based on reading undocumented code, but seems to work. I may add in the rectangle, and event code if I get incentive from another extension to figure them out (XInput might persuade me). - ---- test.lisp ---- ; test code (load "shape") (defun test (&optional (host "localhost")) (let* ((d (xlib:open-display host)) (s (first (xlib:display-roots d))) (r (xlib:screen-root s)) (w (xlib:create-window :x 0 :y 0 :parent r :width 100 :height 100)) (p (xlib:create-pixmap :width 100 :height 100 :depth 1 :drawable w)) (g (xlib:create-gcontext :drawable p :foreground 0))) (multiple-value-bind (b? bx by bw bh c? cx cy cw ch) (xlib:shape-query-extents w) (print (list b? bx by bw bh c? cx cy cw ch))) (setf (xlib:window-background w) 0) (xlib:draw-rectangle p g 0 0 100 100 t) (setf (xlib:gcontext-foreground g) 1) (xlib:draw-arc p g 0 0 100 100 0.0 6.29 t) (xlib:shape-combine-mask w xlib:shape-bounding 0 0 p xlib::shape-set) (xlib:map-window w) (xlib:display-finish-output d) (multiple-value-bind (b? bx by bw bh c? cx cy cw ch) (xlib:shape-query-extents w) (print (list b? bx by bw bh c? cx cy cw ch))))) - ---- shape.lisp ---- ;;; -*- Mode:Lisp; Package:XLIB; Syntax:COMMON-LISP; Base:10; Lowercase:T -*- ;;; CLX interface for Shape Extension (in-package "XLIB" :use '(lisp)) (define-extension "SHAPE") (export '( query-shape-version shape-mask shape-combine shape-offset shape-query-extents shape-set shape-union shape-invert shape-bounding shape-clip shape-notify-mask shape-notify shape-combine-mask shape-combine-shape shape-offset-shape shape-query-extents)) (defconstant query-shape-version 0) ; not sure about this one (defconstant shape-rectangles 1) ; unimplemented (defconstant shape-mask 2) (defconstant shape-combine 3) (defconstant shape-offset 4) (defconstant shape-query-extents 5) (defconstant shape-select-input 6) ; unimplemented - need to figure inputs (defconstant shape-input-selected 7) ; unimplemented - " " (defconstant shape-get-rectangles 8) ; unimplemented (defconstant shape-set 0) (defconstant shape-union 1) (defconstant shape-intersect 2) (defconstant shape-subtract 3) (defconstant shape-invert 4) (defconstant shape-bounding 0) (defconstant shape-clip 1) (defconstant shape-notify-mask 0) (defconstant shape-notify 1) ; kinds are shape-bounding, or shape-clipped (defun shape-combine-mask (drawable dst-kind x-off y-off bitmap op) (let* ((display (drawable-display drawable)) (opcode (extension-opcode display "SHAPE"))) (with-buffer-request (display opcode :length 5) ((data card8) shape-mask) (card8 op dst-kind 0 0) (drawable drawable) (int16 x-off y-off) (drawable bitmap)))) ; kinds are shape-bounding, or shape-clipped (defun shape-combine-shape (drawable dst-kind x-off y-off bitmap src-kind op) (let* ((display (drawable-display drawable)) (opcode (extension-opcode display "SHAPE"))) (with-buffer-request (display opcode :length 5) ((data card8) shape-combine) (card8 op dst-kind src-kind 0) (drawable drawable) (int16 x-off y-off) (drawable bitmap)))) ; kinds are shape-bounding or shape-clip (defun shape-offset-shape (drawable dst-kind x-off y-off) (let* ((display (drawable-display drawable)) (opcode (extension-opcode display "SHAPE"))) (with-buffer-request (display opcode :length 4) ((data card8) shape-combine) (card8 dst-kind 0) (card16 0) (drawable drawable) (int16 x-off y-off)))) (defun shape-query-extents (drawable) (let* ((display (drawable-display drawable)) (opcode (extension-opcode display "SHAPE"))) (with-buffer-request-and-reply (display opcode 2 :sizes (8 16 32)) (((data card8) shape-query-extents) (drawable drawable)) (values (card8-get 8) ; bounding shape? (int16-get 12) ; bounding x (int16-get 14) ; bounding y (card16-get 16) ; bounding width (card16-get 18) ; bounding height (card8-get 9) ; bounding shape? (int16-get 20) ; bounding x (int16-get 22) ; bounding y (card16-get 24) ; bounding width (card16-get 26) ; bounding height )))) ------- End of Forwarded Message From amoroso@mclink.it Wed Feb 20 13:33:58 2002 Return-Path: Received: from mail.mclink.it (net128-053.mclink.it [195.110.128.53]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1KCXvi00728 for ; Wed, 20 Feb 2002 13:33:57 +0100 (CET) (envelope-from amoroso@mclink.it) Received: from net145-014.mclink.it (net145-014.mclink.it [195.110.145.14]) by mail.mclink.it (8.11.0/8.9.0) with SMTP id g1KCXQi14856 for ; Wed, 20 Feb 2002 13:33:55 +0100 (CET) From: Paolo Amoroso To: cmucl-imp@cons.org Subject: Re: defsystem for 18d Date: Wed, 20 Feb 2002 13:29:13 +0100 Organization: Paolo Amoroso - Milan, ITALY Message-ID: References: <000901c1b752$5c7d4780$0100a8c0@MOBY> <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> In-Reply-To: <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> X-Mailer: Forte Agent 1.6/32.525 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, 19 Feb 2002 10:31:43 -0500, Marco Antoniotti wrote: > Myself are unaware of these. What is CLC? What about ACL? I don't CLC is the Common Lisp Controller maintained by Peter Van Eynde as part of CLOCC. Others have provided info on the ACL version. Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://www.paoloamoroso.it/ency/README [http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/] From marcoxa@cs.nyu.edu Wed Feb 20 17:00:49 2002 Return-Path: Received: from octagon.mrl.nyu.edu (OCTAGON.MRL.NYU.EDU [128.122.47.83]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1KG0mi02664 for ; Wed, 20 Feb 2002 17:00:48 +0100 (CET) (envelope-from marcoxa@cs.nyu.edu) Received: (from marcoxa@localhost) by octagon.mrl.nyu.edu (8.11.6/8.9.3) id g1KG0hS03311; Wed, 20 Feb 2002 11:00:43 -0500 Date: Wed, 20 Feb 2002 11:00:43 -0500 Message-Id: <200202201600.g1KG0hS03311@octagon.mrl.nyu.edu> X-Authentication-Warning: octagon.mrl.nyu.edu: marcoxa set sender to marcoxa@cs.nyu.edu using -f From: Marco Antoniotti To: amoroso@mclink.it CC: cmucl-imp@cons.org In-reply-to: (message from Paolo Amoroso on Wed, 20 Feb 2002 13:29:13 +0100) Subject: Re: defsystem for 18d References: <000901c1b752$5c7d4780$0100a8c0@MOBY> <200202191531.g1JFVhq19695@octagon.mrl.nyu.edu> > From: Paolo Amoroso > Date: Wed, 20 Feb 2002 13:29:13 +0100 > Organization: Paolo Amoroso - Milan, ITALY > Content-type: text/plain; charset=us-ascii > X-listar-version: Listar v1.0.0 > Sender: cmucl-imp-bounce@cons.org > X-original-sender: amoroso@mclink.it > Precedence: bulk > X-list: cmucl-imp > Content-Length: 441 > > > On Tue, 19 Feb 2002 10:31:43 -0500, Marco Antoniotti wrote: > > > Myself are unaware of these. What is CLC? What about ACL? I don't > > CLC is the Common Lisp Controller maintained by Peter Van Eynde as part of > CLOCC. Others have provided info on the ACL version. Ooops, my mistake. I always saw it written as c-l-c. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. From pmai@pmsf.de Thu Feb 21 01:35:03 2002 Return-Path: Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1L0Z3i07659 for ; Thu, 21 Feb 2002 01:35:03 +0100 (CET) (envelope-from pmai@pmsf.de) Received: from fwd05.sul.t-online.de by mailout09.sul.t-online.com with smtp id 16dh26-0002Xs-00; Thu, 21 Feb 2002 01:24:22 +0100 Received: from dent.bln.pmsf.de (320001904523-0001@[217.5.89.128]) by fmrl05.sul.t-online.com with esmtp id 16dh24-1dyOTgC; Thu, 21 Feb 2002 01:24:20 +0100 Received: from orion (nobody@orion.bln.pmsf.de [192.168.42.10]) by dent.bln.pmsf.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id BAA13905 for ; Thu, 21 Feb 2002 01:24:16 +0100 X-Authentication-Warning: dent.bln.pmsf.de: Host nobody@orion.bln.pmsf.de [192.168.42.10] claimed to be orion Received: (nullmailer pid 16534 invoked by uid 1000); Thu, 21 Feb 2002 00:24:15 -0000 Sender: dent@pmsf.net To: cmucl-imp@cons.org Subject: RFC for improved and subtypep handling fix From: "Pierre R\. Mai" Date: 21 Feb 2002 01:24:15 +0100 Message-ID: <874rkby95c.fsf@orion.bln.pmsf.de> Lines: 140 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 320001904523-0001@t-dialin.net Hi! The appended patch improves the handling of subtypep for hairy and types enough to allow at least (subtypep 'ratio 'rational) and (subtypep 'rational 'ratio) to produce valid results, as required by the standard (and by an application I'm working on ;). Since any kind of messing with the type-system is inherently dangerous, and we are so near to a release, I'd appreciate it if people could comment on the logic of the changes: To determine the result of (subtypep type1 type2): - If type2 is an and type (and type1 isn't), then if type1 is the subtype of every type t in type2, type1 is a subtype of type2. If type1 is _definitely_ not a subtype of _any_ type t in type2, then type1 is definitely not a subtype of type2. Else we don't know. - If type1 is an and type (and type2 isn't), then if any type t of type1 is a subtype of type2, type1 is definitely a subtype of type2. Else we don't know. This could obviously be extended to subtypep on two and types, but that's not necessary for the ratio stuff, and I wanted to be conservative. Below is the patch, once as a diff, and once as a lisp file that can be compiled and loaded into a running system to play with the changes without going through genesis. Regs, Pierre. ;;; Patch file (in-package "KERNEL") (define-type-method (hairy :complex-subtypep-arg2) (type1 type2) (let ((hairy-spec (hairy-type-specifier type2))) (cond ((and (consp hairy-spec) (eq (car hairy-spec) 'not)) (multiple-value-bind (val win) (type-intersection type1 (specifier-type (cadr hairy-spec))) (if win (values (eq val *empty-type*) t) (values nil nil)))) ((and (consp hairy-spec) (eq (car hairy-spec) 'and)) (block PUNT (values (every-type-op csubtypep type1 (mapcar #'specifier-type (cdr hairy-spec))) t))) (t (values nil nil))))) (define-type-method (hairy :complex-subtypep-arg1) (type1 type2) (let ((hairy-spec (hairy-type-specifier type1))) (cond ((and (consp hairy-spec) (eq (car hairy-spec) 'and)) (block PUNT (if (any-type-op csubtypep type2 (mapcar #'specifier-type (cdr hairy-spec)) :list-first t) (values t t) (values nil nil)))) (t (values nil nil))))) (define-type-method (hairy :complex-=) (type1 type2) (declare (ignore type1 type2)) (values nil nil)) (setf (kernel::type-class-complex-subtypep-arg2 (type-class-or-lose 'hairy)) #'kernel::hairy-complex-subtypep-arg2-type-method (kernel::type-class-complex-subtypep-arg1 (type-class-or-lose 'hairy)) #'kernel::hairy-complex-subtypep-arg1-type-method (kernel::type-class-complex-= (type-class-or-lose 'hairy)) #'kernel::hairy-complex-=-type-method) (clear-type-caches) Index: type.lisp =================================================================== RCS file: /home/CVS-cmucl/src/code/type.lisp,v retrieving revision 1.39 diff -u -r1.39 type.lisp --- type.lisp 2001/11/22 13:39:15 1.39 +++ type.lisp 2002/02/20 23:59:28 @@ -1013,16 +1013,35 @@ (define-type-method (hairy :complex-subtypep-arg2) (type1 type2) (let ((hairy-spec (hairy-type-specifier type2))) - (cond ((and (consp hairy-spec) (eq (car hairy-spec) 'not)) - (multiple-value-bind (val win) - (type-intersection type1 (specifier-type (cadr hairy-spec))) - (if win - (values (eq val *empty-type*) t) - (values nil nil)))) - (t - (values nil nil))))) + (cond + ((and (consp hairy-spec) (eq (car hairy-spec) 'not)) + (multiple-value-bind (val win) + (type-intersection type1 (specifier-type (cadr hairy-spec))) + (if win + (values (eq val *empty-type*) t) + (values nil nil)))) + ((and (consp hairy-spec) (eq (car hairy-spec) 'and)) + (block PUNT + (values (every-type-op csubtypep type1 + (mapcar #'specifier-type (cdr hairy-spec))) + t))) + (t + (values nil nil))))) -(define-type-method (hairy :complex-subtypep-arg1 :complex-=) (type1 type2) +(define-type-method (hairy :complex-subtypep-arg1) (type1 type2) + (let ((hairy-spec (hairy-type-specifier type1))) + (cond + ((and (consp hairy-spec) (eq (car hairy-spec) 'and)) + (block PUNT + (if (any-type-op csubtypep type2 + (mapcar #'specifier-type (cdr hairy-spec)) + :list-first t) + (values t t) + (values nil nil)))) + (t + (values nil nil))))) + +(define-type-method (hairy :complex-=) (type1 type2) (declare (ignore type1 type2)) (values nil nil)) -- Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein From pw@sonetechcorp.com Thu Feb 21 16:33:29 2002 Return-Path: Received: from mail.sonetechcorp.com (mail.sonetechcorp.com [216.153.209.81]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1LFXSi14433; Thu, 21 Feb 2002 16:33:29 +0100 (CET) (envelope-from pw@sonetechcorp.com) Received: from moby (moby.sc.com [192.168.1.251]) by mail.sonetechcorp.com (8.11.6/8.11.6) with SMTP id g1LFZth89263; Thu, 21 Feb 2002 10:36:03 -0500 (EST) (envelope-from pw@sonetechcorp.com) Message-ID: <000f01c1baed$21cc7ef0$fb01a8c0@moby> From: "Paul Werkowski" To: Cc: Subject: Re: Strings with fill-pointers Date: Thu, 21 Feb 2002 10:33:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 make-string returns a simple-string which is a simple-array and has no fill pointer. (make-array n :element-type 'base-char :fill-pointer 1) will do what you want. Paul From cracauer Thu Feb 21 16:53:57 2002 Return-Path: Received: (from cracauer@localhost) by schlepper.zs64.net (8.11.1/8.11.1) id g1LFrvG14619; Thu, 21 Feb 2002 16:53:57 +0100 (CET) (envelope-from cracauer) Date: Thu, 21 Feb 2002 10:53:56 -0500 From: Martin Cracauer To: Paul Werkowski Cc: cmucl-imp@cons.org, cracauer@cons.org Subject: Re: Strings with fill-pointers Message-ID: <20020221105356.A14565@cons.org> References: <000f01c1baed$21cc7ef0$fb01a8c0@moby> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000f01c1baed$21cc7ef0$fb01a8c0@moby>; from pw@sonetechcorp.com on Thu, Feb 21, 2002 at 10:33:30AM -0500 Paul Werkowski wrote on Thu, Feb 21, 2002 at 10:33:30AM -0500: > make-string returns a simple-string which is a simple-array and has no fill > pointer. > > (make-array n :element-type 'base-char :fill-pointer 1) will do what you > want. Ah. That does it (with ":fill-pointer 0"). Thanks! Martin From Rob_MacLachlan@ram2.ius.cs.cmu.edu Thu Feb 21 18:26:15 2002 Return-Path: Received: from ram2.ius.cs.cmu.edu (RAM2.IUS.CS.CMU.EDU [128.2.211.170]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1LHQEN00895 for ; Thu, 21 Feb 2002 18:26:15 +0100 (CET) (envelope-from Rob_MacLachlan@ram2.ius.cs.cmu.edu) Message-Id: <200202211726.g1LHQEN00895@schlepper.zs64.net> Received: from ram2.ius.cs.cmu.edu ([127.0.0.1]) by ram2.ius.cs.cmu.edu id aa00344; 21 Feb 2002 12:26 EST To: "Pierre R. Mai" cc: cmucl-imp@cons.org Subject: Re: RFC for improved and subtypep handling fix In-reply-to: Your message of 21 Feb 2002 01:24:15 +0100. <874rkby95c.fsf@orion.bln.pmsf.de> Reply-To: ram@ri.cmu.edu Date: Thu, 21 Feb 2002 12:26:03 -0500 From: Rob MacLachlan The prose description sounds correct. I didn't read the patch. Rob From wiseman@inetmi.com Thu Feb 21 20:23:48 2002 Return-Path: Received: from nameserve.inetmi.com (nameserve.inetmi.com [204.146.136.253]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1LJNkN11480 for ; Thu, 21 Feb 2002 20:23:47 +0100 (CET) (envelope-from wiseman@inetmi.com) Received: (qmail 3363 invoked from network); 21 Feb 2002 19:29:20 -0000 Received: from unknown (HELO LEMONODOR) (207.208.116.154) by 204.146.136.253 with SMTP; 21 Feb 2002 19:29:20 -0000 From: "John Wiseman" To: Subject: making cmucl more multiprocessing friendly II Date: Thu, 21 Feb 2002 13:23:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Hi. In my continuing quest to make cmucl multiprocessing friendly, I have a new enemy: ext:process-wait ext:process-wait is the function that waits for a forked unix process to exit (don't confuse it with mp:process-wait). The problem is that while it's waiting, no other lisp threads can run. Here's the new version I came up with to fix this: (defun process-wait (proc &optional check-for-stopped) "Wait for PROC to quit running for some reason. Returns PROC." (declare (type process proc)) (mp:process-wait "Waiting for child process to exit" #'(lambda () (case (process-status proc) (:running NIL) (:stopped (if check-for-stopped T NIL)) (T (if (zerop (car (process-cookie proc))) T NIL)))))) And here is the original: (defun process-wait (proc &optional check-for-stopped) "Wait for PROC to quit running for some reason. Returns PROC." (declare (type process proc)) (loop (case (process-status proc) (:running) (:stopped (when check-for-stopped (return))) (t (when (zerop (car (process-cookie proc))) (return)))) (system:serve-all-events 1)) proc) What I'm wondering is what the best solution is. Is there an accepted way to write cmucl system code so that it works well whether or not multiprocessing is enabled? I'm a little surprised that system:serve-all-events isn't causing other lisp threads to run, and I also worry that mp:process-wait isn't going to work on architectures without multiprocessing. Do you guys have any guidance? Thanks, John Wiseman From pw@snoopy.mv.com Thu Feb 21 21:55:18 2002 Return-Path: Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1LKtIN12498 for ; Thu, 21 Feb 2002 21:55:18 +0100 (CET) (envelope-from pw@snoopy.mv.com) Received: from MOBY (snoopy.mv.com [207.22.43.15]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with SMTP id PAA17871; Thu, 21 Feb 2002 15:55:14 -0500 (EST) Message-ID: <001101c1bb19$fdbe05b0$0100a8c0@MOBY> From: "Paul Werkowski" To: "John Wiseman" , References: Subject: Re: making cmucl more multiprocessing friendly II Date: Thu, 21 Feb 2002 15:54:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 | ext:process-wait | | ext:process-wait is the function that waits for a forked unix process | to exit (don't confuse it with mp:process-wait). The problem is that | while it's waiting, no other lisp threads can run. | This indeed a problem as you have to think about what thread is going to be active when the SIGCHLD signal is delivered and how to get that to work correctly. I don't think we have a clear scheme worked out for handling the cases where the MP package may or may not be present except to use a #+MULTIPROCESSING conditional. Right now, the MP package is very low level and hasn't been as fully integrated into the rest of cmucl as it probably could be. Paul From marcoxa@cs.nyu.edu Thu Feb 21 22:56:53 2002 Return-Path: Received: from octagon.mrl.nyu.edu (OCTAGON.MRL.NYU.EDU [128.122.47.83]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1LLuqN13063 for ; Thu, 21 Feb 2002 22:56:53 +0100 (CET) (envelope-from marcoxa@cs.nyu.edu) Received: (from marcoxa@localhost) by octagon.mrl.nyu.edu (8.11.6/8.9.3) id g1LLuql05512; Thu, 21 Feb 2002 16:56:52 -0500 Date: Thu, 21 Feb 2002 16:56:52 -0500 Message-Id: <200202212156.g1LLuql05512@octagon.mrl.nyu.edu> X-Authentication-Warning: octagon.mrl.nyu.edu: marcoxa set sender to marcoxa@cs.nyu.edu using -f From: Marco Antoniotti To: cmucl-imp@cons.org Subject: ext:create-unix-socket-listener Hi, I was fooling around with a simple interface to a program I wrote and realized that the following function is not in the distribution. I am not much of a programmer when it comes to networking stuff, but shouldn't EXT:CREATE-UNIX-SOCKET-LISTENER be present as well in the internet.lisp file? (Note that maybe my code should be cleaned up). Cheers ============================================================================== (in-package "EXT") (defun create-unix-socket-listener (pathname &optional (kind :stream) &key reuse-address (backlog 5) ) (let ((socket (create-unix-socket kind)) (path (typecase pathname (pathname (namestring pathname)) (string (namestring (parse-namestring pathname))))) ) (when reuse-address (multiple-value-bind (optval errno) (set-socket-option socket sol-socket so-reuseaddr 1) (or optval (error "Error ~s setting socket option on socket ~d." (unix:get-unix-error-msg errno) socket)))) (with-alien ((sockaddr unix-sockaddr)) (setf (slot sockaddr 'family) af-unix) (kernel:copy-to-system-area path (* vm:vector-data-offset vm:word-bits) (alien-sap (slot sockaddr 'path)) 0 (* (1+ (length path)) vm:byte-bits)) (when (minusp (unix:unix-bind socket (alien-sap sockaddr) (alien-size unix-sockaddr :bytes))) (unix:unix-close socket) (error "Error binding unix socket to path ~S: ~A" path (unix:get-unix-error-msg)))) (when (eq kind :stream) (when (minusp (unix:unix-listen socket backlog)) (unix:unix-close socket) (error "Error listening to unix socket: ~A" (unix:get-unix-error-msg)))) socket)) ============================================================================== -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. From toy@rtp.ericsson.se Thu Feb 21 23:48:03 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1LMm3N13721 for ; Thu, 21 Feb 2002 23:48:03 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1LMm2S19017 for ; Thu, 21 Feb 2002 16:48:02 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1LMm1507232 for ; Thu, 21 Feb 2002 16:48:01 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Thu Feb 21 16:47:44 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id RAA14536 for ; Thu, 21 Feb 2002 17:50:00 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1LMlhG11765; Thu, 21 Feb 2002 17:47:43 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: CMUCL Mailing List Subject: Non-consing ftruncate and 18d From: Raymond Toy Date: 21 Feb 2002 17:47:42 -0500 Message-ID: <4nadu2laep.fsf@rtp.ericsson.se> Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have some changes that I'd like to make to ftruncate so that it doesn't have any extra consing. (ftruncate calls truncate and if CMUCL can't prove that truncate will return a 32-bit integer, a call to the generic truncate is done. However, for a good float type, the truncation can be done directly on the bits so no consing is needed at all.) This is quite useful for f2cl Should this wait for 18d or should I check it in when ready? Are we ready for 18d yet? Ray From pw@snoopy.mv.com Fri Feb 22 01:00:20 2002 Return-Path: Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1M00KN14646 for ; Fri, 22 Feb 2002 01:00:20 +0100 (CET) (envelope-from pw@snoopy.mv.com) Received: from MOBY (snoopy.mv.com [207.22.43.15]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with SMTP id TAA11466; Thu, 21 Feb 2002 19:00:18 -0500 (EST) Message-ID: <000f01c1bb33$d831e7c0$0100a8c0@MOBY> From: "Paul Werkowski" To: "CMUCL Mailing List" , "Raymond Toy" References: <4nadu2laep.fsf@rtp.ericsson.se> Subject: Re: Non-consing ftruncate and 18d Date: Thu, 21 Feb 2002 18:59:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 | Should this wait for 18d or should I check it in when ready? I think it ok to check it in. | Are we ready for 18d yet? Are people about finished with what they want to put in? I can tag a branch whenever people think the time is right. Paul From toy@rtp.ericsson.se Fri Feb 22 16:41:28 2002 Return-Path: Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1MFfRN42431 for ; Fri, 22 Feb 2002 16:41:27 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1MFfQS02284 for ; Fri, 22 Feb 2002 09:41:26 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1MFfQh24788 for ; Fri, 22 Feb 2002 09:41:26 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Fri Feb 22 09:41:25 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id KAA28601; Fri, 22 Feb 2002 10:43:40 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1MFfNE12479; Fri, 22 Feb 2002 10:41:23 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: "Paul Werkowski" Cc: "CMUCL Mailing List" Subject: Re: Non-consing ftruncate and 18d References: <4nadu2laep.fsf@rtp.ericsson.se> <000f01c1bb33$d831e7c0$0100a8c0@MOBY> From: Raymond Toy Date: 22 Feb 2002 10:41:23 -0500 In-Reply-To: <000f01c1bb33$d831e7c0$0100a8c0@MOBY> Message-ID: <4nsn7tjzh8.fsf@rtp.ericsson.se> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Paul" == Paul Werkowski writes: Paul> | Should this wait for 18d or should I check it in when ready? Paul> I think it ok to check it in. Ok. I need a bit more testing and I want to modify ffloor and fceiling to take advantage of ftruncate. Paul> | Are we ready for 18d yet? Paul> Are people about finished with what they want to put in? I don't have anything planned, except new stuff. Ray From jk271828@yahoo.com Sun Feb 24 13:56:29 2002 Return-Path: Received: from web21306.mail.yahoo.com (web21306.mail.yahoo.com [216.136.129.60]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1OCuSN06112 for ; Sun, 24 Feb 2002 13:56:29 +0100 (CET) (envelope-from jk271828@yahoo.com) Message-ID: <20020224125615.82066.qmail@web21306.mail.yahoo.com> Received: from [131.111.69.166] by web21306.mail.yahoo.com via HTTP; Sun, 24 Feb 2002 04:56:15 PST Date: Sun, 24 Feb 2002 04:56:15 -0800 (PST) From: John Klein Subject: select and large file descriptors To: cmucl-imp@cons.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I recently posted to these lists concerning some problems with memory corruption with a threaded cmucl 18c app on FreeBSD. I think I may have found a problem with cmucl, though not yet necessarily the source of my memory corruption. The problem is that polling file descriptors in cmucl is done using unix:unix-fast-select, which is fine for file descriptors less than unix::fd-setzize = 1024. However, some systems can produce file descriptors larger than this, if the rlimit is set higher. The typical code of a select call is: (alien:with-alien ((read-fds (alien:struct unix:fd-set))) (unix:fd-zero read-fds) ;; next line is dangerous for (> fd 1024) (unix:fd-set fd read-fds) (multiple-value-bind (value err) (unix:unix-fast-select (1+ fd) (alien:addr read-fds) nil nil 0 0))) This will fail when the file descriptor fd is greater than unix:fd-setsize = 1024, and (unix:fd-set fd read-fds) will overwrite the stack, I think. I managed to get cmucl to segfault by giving code like the above a really large fd. This can be 'fixed' by placing (assert (< fd unix:fd-setsize)) before any call to unix:fd-set. This issue comes up in two places in mp:process-wait-until-fd-usable in multi-proc.lisp. Specifically, the internal functions fd-usable-for-input and fd-usable-for-output do not check for (< fd unix:fd-setsize). Also, (do-input) in fd-stream.lisp calls both fast-select and mp:process-wait-until-fd-usable. The following modification could be placed in unix.lisp and unix-glibc2.lisp to protect all fd-set calls: ;; ---- fix for unix.lisp and unix-glibc2.lisp (defmacro fd-set (offset fd-set) (let ((word (gensym)) (bit (gensym))) `(progn ;; NEXT LINE IS NEW (assert (and (>= ,offset 0) (< ,offset fd-setsize))) (multiple-value-bind (,word ,bit) (floor ,offset nfdbits) (setf (deref (slot ,fd-set 'fds-bits) ,word) (logior (truly-the (unsigned-byte 32) (ash 1 ,bit)) (deref (slot ,fd-set 'fds-bits) ,word))))))) An identical assert is necessary in fd-clr, fd-isset, and fd-zero. Additionally, the declared type of fd in mp:process-wait-until-fd-usable should perhaps be (type (mod #.unix::fd-setsize) fd) rather than (type kernel:index fd). The fd-hander functions in sys: do appear to disallow (> fd unix:fd-setsize), so most cmucl code using fd-handers appears safe. It seems to be just mp:process-wait-until-fd-usable that is the problem. The above 'assert' is a kludgy solution, because it causes errors on legitimate file descriptors. The correct solution would be to use poll rather than select, I think. This is what I will eventually try for my own code. unix.lisp defines unix-poll, but then comments it out. Is poll deleted for a reason? Another quick fix would be to get unix::getrlimit and setrlimit working in unix.lisp (currently, it is defined only in unix-glibc2.lisp) and set the open file limit to be equal to unix::fd-setsize. Quicker but kludgier would be to put a 'ulimit -n 1024' in the cmucl startup script. Apologies if any or all of this is completely wrong, as it probably is; I am rather new to working with cmucl source, and I am not a unix guru. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From jk271828@yahoo.com Mon Feb 25 12:01:33 2002 Return-Path: Received: from web21309.mail.yahoo.com (web21309.mail.yahoo.com [216.136.173.254]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1PB1WN17089 for ; Mon, 25 Feb 2002 12:01:33 +0100 (CET) (envelope-from jk271828@yahoo.com) Message-ID: <20020225110118.79724.qmail@web21309.mail.yahoo.com> Received: from [131.111.8.103] by web21309.mail.yahoo.com via HTTP; Mon, 25 Feb 2002 03:01:18 PST Date: Mon, 25 Feb 2002 03:01:18 -0800 (PST) From: John Klein Subject: more on FD-SETSIZE and select To: cmucl-imp@cons.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Some more notes on file descriptors: In FreeBSD, unix.lisp defines FD_SETSIZE to be 256. In fact, modern FreeBSD defines it to be 1024, but makes it user-extensible, so the OS should handle any FD_SETSIZE that the user throws at it: >From 'man select' on FreeBSD The default size of FD_SETSIZE is currently 1024. In order to accommodate programs which might potentially use a larger number of open files with select() , it is possible to increase this size by having the pro- gram define FD_SETSIZE before the inclusion of any header which includes . A similar argument applies to solaris: FD_SETSIZE defaults to 1024, but can be up to (expt 2 16). So I would suggest the following change to unix.lisp: (defconstant FD-SETSIZE #-(or hpux alpha linux freebsd4 solaris) 256 #+hpux 2048 #+alpha 4096 #+freebsd4 4096 ;; user-definable, so make it big #+solaris 4096 ;; user-definable, so make it big #+linux 1024) The only cost of a 4096 FD_SETSIZE is the temporary malloc'ing of 512 bytes whereever with-alien is used to wrap a unix-fast-select. (From the definition and expansion of with-alien I think it is malloc'ed, though the cmucl manual suggests that with-alien does stack allocation. I don't understand this bit.) Also, the definitions of the unix:unix-fast-select macro differ in unix.lisp and unix-glibc2.lisp. In unix.lisp, a (declare...) block is part of the doc-string, whereas in unix-glibc2.lisp the position of a double-quote was changed, making the declare block a part of the macro. Because the (declare ...) does not show up in the macroexpansion, and does not really make sense, I think that it is incorrect (though benign) in unix-glibc2.lisp. I think that the declare block was meant as sample code for users, not as part of the macro. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From cracauer Mon Feb 25 15:08:31 2002 Return-Path: Received: (from cracauer@localhost) by schlepper.zs64.net (8.11.1/8.11.1) id g1PE8V318314; Mon, 25 Feb 2002 15:08:31 +0100 (CET) (envelope-from cracauer) Date: Mon, 25 Feb 2002 09:08:31 -0500 From: Martin Cracauer To: John Klein Cc: cmucl-imp@cons.org Subject: Re: more on FD-SETSIZE and select Message-ID: <20020225090831.B18270@cons.org> References: <20020225110118.79724.qmail@web21309.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020225110118.79724.qmail@web21309.mail.yahoo.com>; from jk271828@yahoo.com on Mon, Feb 25, 2002 at 03:01:18AM -0800 John Klein wrote on Mon, Feb 25, 2002 at 03:01:18AM -0800: > > > (defconstant FD-SETSIZE #-(or hpux alpha linux freebsd4 solaris) 256 > #+hpux 2048 > #+alpha 4096 > #+freebsd4 4096 ;; user-definable, so make it big > #+solaris 4096 ;; user-definable, so make it big > #+linux 1024) Does this profit in any way from being a constant in first place? It doesn't seem so. Martin From jk271828@yahoo.com Mon Feb 25 15:16:53 2002 Return-Path: Received: from web21309.mail.yahoo.com (web21309.mail.yahoo.com [216.136.173.254]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1PEGqN18404 for ; Mon, 25 Feb 2002 15:16:52 +0100 (CET) (envelope-from jk271828@yahoo.com) Message-ID: <20020225141650.23402.qmail@web21309.mail.yahoo.com> Received: from [131.111.8.96] by web21309.mail.yahoo.com via HTTP; Mon, 25 Feb 2002 06:16:50 PST Date: Mon, 25 Feb 2002 06:16:50 -0800 (PST) From: John Klein Subject: Re: more on FD-SETSIZE and select To: cmucl-imp@cons.org In-Reply-To: <20020225090831.B18270@cons.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii --- Martin Cracauer wrote: > Does this [FD-SETSIZE] profit in any way from being a constant in first place? > It doesn't seem so. #.unix:fd-setsize is used in declarations like in serve-event.lisp and in unix:unix-select, though these could all be modified and asserts could be inserted at relevant parts of the code. Also, if FD-SETSIZE changes between the creation of one fd-set and the creation of another, then macros like unix:fd-zero could end up using the wrong size, with nasty consequences...I think. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From toy@rtp.ericsson.se Mon Feb 25 17:39:58 2002 Return-Path: Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1PGdwN19967 for ; Mon, 25 Feb 2002 17:39:58 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1PGduh24858 for ; Mon, 25 Feb 2002 10:39:56 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1PGdtc15873 for ; Mon, 25 Feb 2002 10:39:56 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Mon Feb 25 10:39:54 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id LAA21450 for ; Mon, 25 Feb 2002 11:42:11 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1PGdr415879; Mon, 25 Feb 2002 11:39:53 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: CMUCL Mailing List Subject: new-random? From: Raymond Toy Date: 25 Feb 2002 11:39:53 -0500 Message-ID: <4nofidikh2.fsf@rtp.ericsson.se> Lines: 7 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Is anyone using the new-random random number generator? I think it's basically been superseded by the mt19937 generator. Maybe we should just get rid of it, including the code? Ray From Rob_MacLachlan@ram2.ius.cs.cmu.edu Mon Feb 25 19:16:40 2002 Return-Path: Received: from ram2.ius.cs.cmu.edu (RAM2.IUS.CS.CMU.EDU [128.2.211.170]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1PIGeN20788; Mon, 25 Feb 2002 19:16:40 +0100 (CET) (envelope-from Rob_MacLachlan@ram2.ius.cs.cmu.edu) Message-Id: <200202251816.g1PIGeN20788@schlepper.zs64.net> Received: from ram2.ius.cs.cmu.edu ([127.0.0.1]) by ram2.ius.cs.cmu.edu id aa11478; 25 Feb 2002 13:15 EST To: Martin Cracauer cc: John Klein , cmucl-imp@cons.org Subject: Re: more on FD-SETSIZE and select In-reply-to: Your message of Mon, 25 Feb 2002 09:08:31 -0500. <20020225090831.B18270@cons.org> Reply-To: ram@ri.cmu.edu Date: Mon, 25 Feb 2002 13:15:59 -0500 From: Rob MacLachlan The use of with-alien should truly allocate the storage on the number (C) stack, and not cons any Alien at all. However, this may not work if fd-set is not a constant size type. So I'd go for making it larger constant, but feel free to come up with a more elegant solution as long as it doesn't pessimize select. We really don't want select to cons or leak memory. Rob From pw@snoopy.mv.com Mon Feb 25 22:03:37 2002 Return-Path: Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1PL3aN22521 for ; Mon, 25 Feb 2002 22:03:36 +0100 (CET) (envelope-from pw@snoopy.mv.com) Received: from MOBY (snoopy.mv.com [207.22.43.15]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with SMTP id QAA26198; Mon, 25 Feb 2002 16:03:31 -0500 (EST) Message-ID: <002301c1be3f$d0ff8bb0$0100a8c0@MOBY> From: "Paul Werkowski" To: "CMUCL Mailing List" , "Raymond Toy" References: <4nofidikh2.fsf@rtp.ericsson.se> Subject: Re: new-random? Date: Mon, 25 Feb 2002 16:02:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 | | | Is anyone using the new-random random number generator? I think it's | basically been superseded by the mt19937 generator. | | Maybe we should just get rid of it, including the code? | I can't think of any reason to keep it. If someone wants it later it can still be retrieved from CVS. Paul From pmai@pmsf.de Tue Feb 26 00:07:32 2002 Return-Path: Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1PN7WN24019 for ; Tue, 26 Feb 2002 00:07:32 +0100 (CET) (envelope-from pmai@pmsf.de) Received: from fwd03.sul.t-online.de by mailout06.sul.t-online.com with smtp id 16fUDB-00044J-0B; Tue, 26 Feb 2002 00:07:13 +0100 Received: from dent.bln.pmsf.de (320001904523-0001@[62.155.170.114]) by fmrl03.sul.t-online.com with esmtp id 16fUD4-1V2ZyiC; Tue, 26 Feb 2002 00:07:06 +0100 Received: from orion (nobody@orion.bln.pmsf.de [192.168.42.10]) by dent.bln.pmsf.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA15736 for ; Tue, 26 Feb 2002 00:07:00 +0100 X-Authentication-Warning: dent.bln.pmsf.de: Host nobody@orion.bln.pmsf.de [192.168.42.10] claimed to be orion Received: (nullmailer pid 9647 invoked by uid 1000); Mon, 25 Feb 2002 23:07:00 -0000 Sender: dent@pmsf.net To: cmucl-imp@cons.org Subject: Re: Non-consing ftruncate and 18d References: <4nadu2laep.fsf@rtp.ericsson.se> <000f01c1bb33$d831e7c0$0100a8c0@MOBY> <4nsn7tjzh8.fsf@rtp.ericsson.se> From: "Pierre R\. Mai" Date: 26 Feb 2002 00:07:00 +0100 Message-ID: <87y9hh5ffv.fsf@orion.bln.pmsf.de> Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 320001904523-0001@t-dialin.net Raymond Toy writes: > >>>>> "Paul" == Paul Werkowski writes: > > Paul> | Should this wait for 18d or should I check it in when ready? > > Paul> I think it ok to check it in. > > Ok. I need a bit more testing and I want to modify ffloor and > fceiling to take advantage of ftruncate. > > Paul> | Are we ready for 18d yet? > > Paul> Are people about finished with what they want to put in? > > I don't have anything planned, except new stuff. Likewise, with the subtype-handling fix committed, there's nothing left on my end that needs to go into 18d, so how about releasing in the second week of March? In order for the release to be tagged, I should still add the release-info/README file for 18d to the CVS repository, so that release tarballs can be built solely from the CVS sources. I consider myself responsible for building release tarballs for - Linux/x86 with glibc 2.1 - OpenBSD/x86 Not sure about NetBSD/x86, since I currently have no NetBSD machine. Regs, Pierre. -- Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein From emarsden@laas.fr Tue Feb 26 10:36:27 2002 Return-Path: Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1Q9aRN29180 for ; Tue, 26 Feb 2002 10:36:27 +0100 (CET) (envelope-from emarsden@laas.fr) Received: from moustacho.laas.fr (moustacho [140.93.21.71]) by laas.laas.fr (8.12.1/8.12.1) with ESMTP id g1Q9aQAp008921 for ; Tue, 26 Feb 2002 10:36:27 +0100 (CET) Received: (from emarsden@localhost) by moustacho.laas.fr (8.9.3/8.9.3) id KAA08968; Tue, 26 Feb 2002 10:36:26 +0100 (MET) To: CMUCL implementors Subject: Re: Non-consing ftruncate and 18d References: <4nadu2laep.fsf@rtp.ericsson.se> <000f01c1bb33$d831e7c0$0100a8c0@MOBY> <4nsn7tjzh8.fsf@rtp.ericsson.se> <87y9hh5ffv.fsf@orion.bln.pmsf.de> From: Eric Marsden Organization: LAAS-CNRS http://www.laas.fr/ X-Message-Flags: Don't Panic! X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ Date: Tue, 26 Feb 2002 10:36:25 +0100 In-Reply-To: <87y9hh5ffv.fsf@orion.bln.pmsf.de> ("Pierre R\. Mai"'s message of "26 Feb 2002 00:07:00 +0100") Message-ID: Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "prm" == Pierre R\ Mai writes: prm> I consider myself responsible for building release tarballs for prm> prm> - Linux/x86 with glibc 2.1 prm> - OpenBSD/x86 I could do sparcv9-solaris and sparc-solaris, and x86-linuxglibc22 if we want separate binaries (not sure whether this is worth it?), and x86-freebsd (would need help for testing). prm> Not sure about NetBSD/x86, since I currently have no NetBSD machine. I have an x86 machine with NetBSD 1.5.2, but I'm not sure that the release for that platform is very stable. I still haven't been able to rebuild from your experimental binaries (various manifestations of apparent memory corruption), and they infloop on something as simple as (/ 1 0.0s0). I haven't yet tried cross-compiling from linux. -- Eric Marsden From pmai@pmsf.de Tue Feb 26 12:35:41 2002 Return-Path: Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1QBZfN29990 for ; Tue, 26 Feb 2002 12:35:41 +0100 (CET) (envelope-from pmai@pmsf.de) Received: from fwd07.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16ffCp-0003qZ-0R; Tue, 26 Feb 2002 11:51:35 +0100 Received: from dent.bln.pmsf.de (320001904523-0001@[217.80.21.143]) by fmrl07.sul.t-online.com with esmtp id 16ffCm-1YbwLgC; Tue, 26 Feb 2002 11:51:32 +0100 Received: from orion (nobody@orion.bln.pmsf.de [192.168.42.10]) by dent.bln.pmsf.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA18968 for ; Tue, 26 Feb 2002 11:51:27 +0100 X-Authentication-Warning: dent.bln.pmsf.de: Host nobody@orion.bln.pmsf.de [192.168.42.10] claimed to be orion Received: (nullmailer pid 9951 invoked by uid 1000); Tue, 26 Feb 2002 10:51:26 -0000 Sender: dent@pmsf.net To: cmucl-imp@cons.org Subject: Re: Non-consing ftruncate and 18d References: <4nadu2laep.fsf@rtp.ericsson.se> <000f01c1bb33$d831e7c0$0100a8c0@MOBY> <4nsn7tjzh8.fsf@rtp.ericsson.se> <87y9hh5ffv.fsf@orion.bln.pmsf.de> From: "Pierre R\. Mai" Date: 26 Feb 2002 11:51:26 +0100 In-Reply-To: Message-ID: <87elj8sehd.fsf@orion.bln.pmsf.de> Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 320001904523-0001@t-dialin.net Eric Marsden writes: > >>>>> "prm" == Pierre R\ Mai writes: > > prm> I consider myself responsible for building release tarballs for > prm> > prm> - Linux/x86 with glibc 2.1 > prm> - OpenBSD/x86 > > I could do sparcv9-solaris and sparc-solaris, and x86-linuxglibc22 if > we want separate binaries (not sure whether this is worth it?), and > x86-freebsd (would need help for testing). We probably don't need an extra glibc22 binary, since the glibc21 ones seems to run just fine on glibc 2.2 machines. The only reason that 18c has both is historical (since the 2.2 one came first, and I didn't want to remove it after the fact). > prm> Not sure about NetBSD/x86, since I currently have no NetBSD machine. > > I have an x86 machine with NetBSD 1.5.2, but I'm not sure that the > release for that platform is very stable. I still haven't been able to > rebuild from your experimental binaries (various manifestations of > apparent memory corruption), and they infloop on something as simple > as (/ 1 0.0s0). I haven't yet tried cross-compiling from linux. Agreed. I think that we can release without NetBSD, and if someone gets the 18d release source working stably on NetBSD, it can be added later on, and if not, it can remain an experimental build. Since cmucl on NetBSD/x86 is seriously lacking when compared to other platforms, I'd prefer that not to taint CMU CL's reputation. Regs, Pierre. -- Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein From toy@rtp.ericsson.se Tue Feb 26 15:03:36 2002 Return-Path: Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1QE3ZN30950 for ; Tue, 26 Feb 2002 15:03:35 +0100 (CET) (envelope-from toy@rtp.ericsson.se) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QE3Vh17705 for ; Tue, 26 Feb 2002 08:03:34 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g1QE3Vw14132 for ; Tue, 26 Feb 2002 08:03:31 -0600 (CST) Received: FROM netmanager7.rtp.ericsson.se BY eamrcnt749 ; Tue Feb 26 08:03:31 2002 -0600 Received: from edgedsp4.rtp.ericsson.se (edgedsp4.rtp.ericsson.se [147.117.122.19]) by netmanager7.rtp.ericsson.se (8.8.8+Sun/8.6.4) with ESMTP id JAA11881; Tue, 26 Feb 2002 09:05:48 -0500 (EST) Received: (from toy@localhost) by edgedsp4.rtp.ericsson.se (8.10.2+Sun/8.9.3) id g1QE3TH18614; Tue, 26 Feb 2002 09:03:29 -0500 (EST) X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to toy@rtp.ericsson.se using -f To: "Paul Werkowski" Cc: "CMUCL Mailing List" Subject: Re: new-random? References: <4nofidikh2.fsf@rtp.ericsson.se> <002301c1be3f$d0ff8bb0$0100a8c0@MOBY> From: Raymond Toy Date: 26 Feb 2002 09:03:29 -0500 In-Reply-To: <002301c1be3f$d0ff8bb0$0100a8c0@MOBY> Message-ID: <4nk7t0ibm6.fsf@rtp.ericsson.se> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "Paul" == Paul Werkowski writes: Paul> | Paul> | Paul> | Is anyone using the new-random random number generator? I think it's Paul> | basically been superseded by the mt19937 generator. Paul> | Paul> | Maybe we should just get rid of it, including the code? Paul> | Paul> I can't think of any reason to keep it. If someone wants it later Paul> it can still be retrieved from CVS. Ok. I'll delete it after 18d goes out. Ray From wsch9884@eudoramail.com Wed Feb 27 01:56:20 2002 Return-Path: Received: from chmatoex01.mato.ch (mail.matofirstswiss.ch [195.144.38.27]) by schlepper.zs64.net (8.11.1/8.11.1) with SMTP id g1R0uJN37810 for ; Wed, 27 Feb 2002 01:56:19 +0100 (CET) (envelope-from wsch9884@eudoramail.com) Received: from mx1.eudoramail.com ([204.32.146.147]) by chmatoex01.mato.ch (NAVGW 2.5.1.13) with SMTP id M2002022603273216448 ; Tue, 26 Feb 2002 03:27:49 +0100 Message-ID: <00002f546b5c$0000330a$00004c65@mx1.eudoramail.com> To: From: wsch9884@eudoramail.com Subject: WSCH : A Revolutionary Acne Treatment and More P Date: Mon, 25 Feb 2002 20:29:47 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: wsch9884@eudoramail.com SPECIAL ALERT

Special Alert :  WASATCH  PHARMACEUTICAL= S  (OTCBB: WSCH)

<= td vAlign=3Dtop align=3Dleft width=3D277 rowspan=3D6 height=3D1>

<= font face=3D"Times New Roman" style=3D"font-size: 13pt">   =            PROJECTIONS, = OBJECTIVES AND STATISTICS

TOP 4 REASONS TO BUY WSCH=
1.The products and medical therapies developed by WSCH rep= resent possibly the most important breakthrough in the field of Der= matology in the last fifty years.
2.WSCH anticipat= es FDA approval on seven over-the-counter products within the next = year, which will provide significant revenue in the retail drug market.
3.<= /font>WSCH has experienced a success rate of 90% during clinical studies, completely eliminating skin disease from 90% of= all patients treated.
4.By year five, WSCH plan= s to have annualized revenue over $525 million and over $125 mil= lion in EBIT.  This does not take into account income from OTC pr= oducts which will be substantial.

 

 &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ; Over a five year period, AISC (WSCH's subsidiary) plans to establish = 350 clinics in over 100 major population areas. The company plans= to hire over 150 medical doctors for these clinics, train over 1,000 medi= cal assistants and treat over 2,000,000 patients. Also by year five= , WSCH plans to have annualized over $525 million in revenue and over $= 125 million in EBIT. This does not take into account income from OTC p= roducts which will be substantial.

As of 1991, there were ap= proximately 14 million chronic acne and eczema patients annually in= the United States, with the highest percentage between 18 to 44 year= s of age. The actual number of patients with any type of acne Is= significantly higher. Seven billion dollars is spent annuall= y on dermatological pharmaceutical products for these disorders.<= /span>

In 1994, the teen population reached 25 million. Duri= ng the next decade, it will grow at nearly twice the rate of = the overall population (according to U.S. Census Bureau projectio= ns). Acne patients are primarily teenagers, whereas eczema patie= nts range from infants to the elderly.

          SYMBOL:=    &= nbsp;    WSCH
  &nbs= p;    CURRENT PRICE:       $0.059
    = ;   52 WEEK HIGH:       $27.50
&= nbsp;      52 WEEK LOW:       $0.056<= /b>

COMPANY BACKGROUND<= /font>

Wasatch Pharmaceutical, Inc. = is a fourteen year old company with a record of outstanding achievements i= n the field of Dermatology. Dermatology. Under the name of its subsid= iary, American Institute of Skin Care (AISC), Wasatch has operated = two prototype clinics for the last five years where the products and medic= al therapies have been tested and proven on hundreds of patients. The Comp= any's activities have been centered on research in the area of serious = skin diseases. A concurrent discov= ery and benefit is WSCH's dramatic success in the area of skin rejuvenatio= n.

Seeing the high growth potential from ma= jor funding, WSCH elected to become a public company less than two = years ago.

Wasatch's major success= es in the area of skin diseases include:

Cystic Acne, Eczema, Seborrhea, Contact Dermatitis, Molluscum, Folliculit= is, Acne Rosacea and less prevalent skin diseases.
Interestingly, these skin disorders account for more than 7= 0% of all business in the field of dermatology for which there are ver= y few (if any) safe, effective therapies like those developed by Wasatc= h.
Because the therapies developed by W= asatch dominate this area of medicine, WSCH has elected to market i= ts products via company-owned clinics throughout the United States. T= his decision has resulted in the establishment of two research clinics<= /b> in Utah for the purpose of implementing procedures within the clinics = pursuant to testing and confirming the results that were achieved in past = clinical trials. Due to its success rate of 90% on hundreds of p= atients over a five year period, WSCH's clinics are now on line with i= nsurance providers independent of HMOs. Efforts to establish Preferred Pro= vidership status with HMOs are presently being pursued.
<= /div>
THIS J= UST IN : WSCH BREAKING NEWS
 = =

Wasatch Pharmaceu= tical Inc. Announces a New Physician Marketing Campaign and Listing On Ger= man Stock Exchanges

MURRAY, Utah--(BUSINESS WIRE)--Nov. 27,= 2001--Wasatch Pharmaceutical Inc. (OTCBB:WSCH - news) CEO Gary Heesch announced today a marketing campaign dir= ected to physicians. A direct link has been established on a physician rec= ruiting Web site making available therapies for the treatment of cystic ac= ne, acne, folliculitis and skin rejuvenation. Physicians will find the ben= efits of these treatment therapies by logging on to the "X Acne&qu= ot; link at the Physician Search website. This physician search Web si= te typically receives over 200,000 hits per month. Mr. Heesch remin= ded, "Our treatment therapy products are also available via the AISC = Online Store."

Th= ese skin treatment products come in kit form providing a 90-day supply to = patients for the full treatment program. Included in the kit is an instruc= tional video on the treatment therapy allowing the patient to use these pr= oducts in their home. The therapies, when used as instructed, achieve a success rate of eradication in excess of 90% with no side effects of any = consequence. Previously, these therapies and associated products were = only available through the two prototype clinics in Utah. The availability= of these products will open the way for family practitioners, pediatricia= ns, internists and other primary care physicians to retain their patients = under their care during the treatment of these common skin disorders. T= he benefit to insurance providers is the potential to save millions of dol= lars in reimbursement costs by freeing the physician and the patient from = ongoing treatment.

In the = coming year, six additional therapies will be made available for a = broad range of skin disorders that are badly in need of successful therapi= es.

Gary Heesch also announced= the listing of Wasatch Pharmaceutical stock on the Frankfurt and Berli= n Exchanges in Germany. Active trading on these exchanges will take pl= ace upon the completion of a research report in Germany. Said Mr. Heesch, = "We feel this is a significant event as Wasatch will gain wider ex= posure as a leader in dermatology and will put buying pressu= re on its stock to reflect the true value of a company that has= committed years of research and development of products that allow people= with serious skin disorders to live normal and more productive lives.&quo= t;

There may be forward-lookin= g statements in this release. Investors are cautioned that such forward-lo= oking statements involve risks and uncertainties, including, without limit= ation, continued acceptance of the Company's products, increased levels of= competition, new products introduced by competitors, changes in the rates= of subscriber acquisition and retention, and other risks detailed from ti= me to time in the Company's periodic reports filed with the Securities and= Exchange Commission.

A LOOK AT THE COMPETITION

Dermatologists are the primary competitors of WSCH's cli= nics. Dermatologists specialize in the treatment of skin disorders and pre= scribe medications to treat the disorder. However, competing products addr= ess the symptoms of acne and eczema, not the cause. 

The= competition's skin care treatments include prescription medications (oral= and external use drugs prescribed by dermatologists and other doctors) an= d over-the-counter products.

Several com= mon prescription medications include: 

1)= E-Mycin for oral and topical use, 2) Cleocin for oral and topical use, 3)= Tetracycline for oral and topical use, and 4) Accutane for oral use only.=

Over-the-counter acne medications include:&nbs= p;
1) Clearasil and Oxy creams, 2) generic brand creams, 3) medica= ted pads, and 4) medicated soaps.

Many of th= e competition's oral medications have serious side effects.

Costs for competing treatments range from $2.50 for medicated soap= s to $200 for Accutane oral medication prescription. Treatments are on-goi= ng. Over time a person can spend an unlimited amount of money = on such treatments. An example would be someone who spent $1,500 for = a 22 week program of Accutane which includes blood testing. Another e= xample would be someone who has had acne for many years and has spent in e= xcess of $34,000.

At this time there is = no known competitor who treats the causes of these skin disorders and = no competitor can claim a success rate equal to that of Wasatch's t= reatments.

A FINAL WORD ABOUT WSCH

W= ith a proven success rate of 90% in a field that affects so many of our li= ves, Wasatch has clearly positioned itself in a market hungry and despe= rate for successful products and treatment. WSCH has recently exp= anded its marketing presence (as seen in the above press release) and will= continue to aggressively broaden awareness over the near term. The listin= g of WSCH on the German stock exchange is another sign of the compa= ny's credibility and ambitious plans to establish itself as a major glo= bal player in the field of dermatology.

 WSCH = has taken on a completely different approach. By addressing the cause= s of skin disorders rather than the symptoms, WSCH will help to successful= ly eliminate skin disease altogether. Given the following:

1. Successful 14-year history and plans for expansion
2. Impressi= ve revenue projections ($525 million+ annualized by year 5 and $125 m= illion in EBIT)
3. Virtually unmatched success rate of 90%...

...and so much more, WSCH will certainly be watched by savvy inve= stors for some time to come.

To be removed from future mailings, please reply= to this email with "Remove" in the subject line


DISCLAIMER: 
Information within this ema= il contains "forward looking statements" within the meaning of S= ection 27A of the Securities Act of 1933 and Section 21B of the Securities= Exchange Act of 1934. Any statements that express or involve discussions = with respect to predictions, expectations, beliefs, plans, projections, ob= jectives, goals, assumptions or future events or performance are not state= ments of historical fact and may be "forward looking statements."= ;

Forward looking statements are based on expectations, estimates= and projections at the time the statements are made that involve a number= of risks and uncertainties which could cause actual results or event= s to differ materially from those presently anticipated. Forward looking s= tatements in this action may be identified through the use of words such a= s "projects", "foresee", "expects", "wi= ll,"  "anticipates," "estimates," "beli= eves," "understands" or that by statements indicating certa= in actions "may," "could," or "might" occur.=   All information provided within this email pertaining to investing,= stocks, securities must be understood as information provided and not inv= estment advice. Emerging Growth Stock Alert advises all readers and subscr= ibers to seek advice from a registered professional securities repres= entative before deciding to trade in stocks featured within this email.&nb= sp; None of the material within this report shall be construed as any kind= of investment advice.

In compliance with the Securities Act of 1= 933, Section17(b), Emerging Growth Stock Alert discloses the receipt of $5= 0,000 cash from a third party for the publication of this report and addit= ional services related to WSCH. Be aware of an inherent conflict of i= nterest resulting from such compensation.  In addition, Emerging Grow= th Stock Alert intends to receive three million five hundred thousand unre= stricted shares of WSCH from a third party for the publication of this rep= ort and additional services related to WSCH.  Be aware of an inherent= conflict of interest due to our intent to profit from the liquidation of = these shares. Part or all of this position may be sold at any time, even a= fter we have made positive statements regarding the above company.  A= ll factual information in this report was gathered from public source= s, including but not limited to SEC filings, Company Press Releases, and t= he company's website at wasatchpharm.com. Emerging Growth Stock Alert= believes this information to be reliable but can make no guarantee as to = its accuracy or completeness. Use of the material within this email consti= tutes your acceptance of these terms.=
 
=

To be r= emoved from future mailings, please reply to this email with "Remove&= quot; in the subject line

From gerd.moellmann@t-online.de Wed Feb 27 17:06:43 2002 Return-Path: Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1RG6hN44962 for ; Wed, 27 Feb 2002 17:06:43 +0100 (CET) (envelope-from gerd.moellmann@t-online.de) Received: from fwd07.sul.t-online.de by mailout01.sul.t-online.com with smtp id 16g6bH-000605-08; Wed, 27 Feb 2002 17:06:39 +0100 Received: from gerd.dnsq.org (520015515780-0001@[217.85.165.58]) by fwd07.sul.t-online.com with esmtp id 16g6ax-0XrDMGC; Wed, 27 Feb 2002 17:06:19 +0100 Received: (from gerd@localhost) by gerd.dnsq.org (8.11.6/8.11.4) id g1RG6Hb05068; Wed, 27 Feb 2002 17:06:17 +0100 (CET) (envelope-from gerd@gnu.org) X-Authentication-Warning: gerd.dnsq.org: gerd set sender to gerd@gnu.org using -f Sender: gerd@gerd.dnsq.org To: cmucl-imp@cons.org Subject: Patch: FreeBSD and shared libs From: gerd.moellmann@t-online.de (Gerd Moellmann) Date: 27 Feb 2002 17:06:17 +0100 Message-ID: <868z9e6hae.fsf@gerd.dnsq.org> Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender: 520015515780-0001@t-dialin.net The following patch is an, at least partial, fix for loading shared libs on FreeBSD. I guess it's obvious what oversight the patch fixes. (Tried with CMUCL built on 4.5 STABLE from cmucl-src-20020224.tar.gz using the procedure from cmucl-build.tar.gz (feature :FREEBSD added to its env-simple-raw.lisp, and using Config.FreeBSD_gencgc.)) *** foreign.lisp 2002/02/27 15:02:04 1.1 --- foreign.lisp 2002/02/27 15:36:52 *************** *** 239,246 **** (unless (elf-executable-p (alien:slot header 'elf-type)) (error (format nil "~A is not executable." name))) ! (alien:with-alien ((program-header pheader)) (unix:unix-read fd (alien:alien-sap program-header) (alien:alien-size pheader :bytes)) --- 239,250 ---- (unless (elf-executable-p (alien:slot header 'elf-type)) (error (format nil "~A is not executable." name))) ! (alien:with-alien ((program-header pheader)) + (unix:unix-lseek + fd + (alien:slot header 'elf-program-header-offset) + unix:l_set) (unix:unix-read fd (alien:alien-sap program-header) (alien:alien-size pheader :bytes)) The patched CMUCL issues lots of warnings when loading shared libs. I'd be interested to know how serious these warnings are, and how to avoid them. Example: * (load-foreign "/usr/lib/libz.so") ;;; Running library:load-foreign.csh... ;;; Loading object file... ;;; Parsing symbol table... Warning: "getipnodebyaddr" moved from #x0807645C to #x080762C0. Warning: "longjmp" moved from #x08058278 to #x08058284. Warning: "__fp_nquery" moved from #x0807C5AC to #x0807C2D8. Warning: "__bt_setcur" moved from #x0806BC78 to #x0806BBC8. ... And BTW, the binary from cmucl-20020219-x86-freebsd.tar.bz2 (from cons.org) has no :ELF in *FEATURES*, which I think should be a bug. From emarsden@laas.fr Wed Feb 27 20:27:53 2002 Return-Path: Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1RJRrN47365 for ; Wed, 27 Feb 2002 20:27:53 +0100 (CET) (envelope-from emarsden@laas.fr) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.12.1/8.12.1) with ESMTP id g1RJRqAp015559; Wed, 27 Feb 2002 20:27:52 +0100 (CET) Received: (from emarsden@localhost) by dukas.laas.fr (8.11.1/8.11.1) id g1RJRpm13297; Wed, 27 Feb 2002 20:27:51 +0100 (MET) To: Gerd Moellmann Cc: CMUCL implementors Subject: Re: Patch: FreeBSD and shared libs References: <868z9e6hae.fsf@gerd.dnsq.org> From: Eric Marsden Organization: LAAS-CNRS http://www.laas.fr/ X-Message-Flags: Please don't feed the Microserfs X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ Date: Wed, 27 Feb 2002 20:27:51 +0100 In-Reply-To: <868z9e6hae.fsf@gerd.dnsq.org> (gerd.moellmann@t-online.de's message of "27 Feb 2002 17:06:17 +0100") Message-ID: Lines: 10 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "gm" == Gerd Moellmann writes: gm> And BTW, the binary from cmucl-20020219-x86-freebsd.tar.bz2 (from gm> cons.org) has no :ELF in *FEATURES*, which I think should be a bug. thanks for pointing this out. I have uploaded some corrected binaries (though without your patch). -- Eric Marsden From gerd.moellmann@t-online.de Wed Feb 27 20:45:47 2002 Return-Path: Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by schlepper.zs64.net (8.11.1/8.11.1) with ESMTP id g1RJjlN47463 for ; Wed, 27 Feb 2002 20:45:47 +0100 (CET) (envelope-from gerd.moellmann@t-online.de) Received: from fwd09.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16gA1F-00007F-0E; Wed, 27 Feb 2002 20:45:41 +0100 Received: from gerd.dnsq.org (520015515780-0001@[217.230.98.65]) by fwd09.sul.t-online.com with esmtp id 16gA1B-1oZsPoC; Wed, 27 Feb 2002 20:45:37 +0100 Received: (from gerd@localhost) by gerd.dnsq.org (8.11.6/8.11.4) id g1RJjTu05733; Wed, 27 Feb 2002 20:45:29 +0100 (CET) (envelope-from gerd@gnu.org) X-Authentication-Warning: gerd.dnsq.org: gerd set sender to gerd@gnu.org using -f Sender: gerd@gerd.dnsq.org To: Eric Marsd