enough-namestring bugfix

Hello

Small bugfix in src/code/filesys.lisp to fix enough-namestring

Change

((and (> prefix-len 1)
in unparse-unix-enough to
((and (>= prefix-len 1)

fixes
(enough-namestring #P"/foo" #P"/")
->
#P"foo"
rather than
#P"/foo"

Thanks.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [cl-debian] Bug#331252: sbcl: tools-for-build/where-is-mcontext.c has no exit(0);

Hello,

This seems like a valid bug, not?

On Sunday 02 October 2005 17:42, Trent Buck wrote:
oo> Package: sbcl
> Version: 1:0.9.4.65-1
> Severity: minor
>
> In the SBCL source 0.9.5.9-1, the C program
> tools-for-build/where-is-mcontext.c does not have an explicit return value,
> resulting (I believe) in the resulting program sometimes succeding and
> sometimes failing.  Since make-config.sh has "set -e", where-is-mcontext
> should always exit successfully after printing. Therefore "exit(0);" should
> be added immediately before the last closing brace.

Groetjes, Peter

--

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

Re: [cl-debian] Bug#331252: sbcl: tools-for-build/where-is-mcontext.c has no exit(0);

Peter Van Eynde wrote:

> This seems like a valid bug, not?

IMO, yes, and since it's so easy to fix...

-- Rex

> On Sunday 02 October 2005 17:42, Trent Buck wrote:
> oo> Package: sbcl
> 
>>Version: 1:0.9.4.65-1
>>Severity: minor
>>
>>In the SBCL source 0.9.5.9-1, the C program
>>tools-for-build/where-is-mcontext.c does not have an explicit return value,
>>resulting (I believe) in the resulting program sometimes succeding and
>>sometimes failing.  Since make-config.sh has "set -e", where-is-mcontext
>>should always exit successfully after printing. Therefore "exit(0);" should
>>be added immediately before the last closing brace.

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [PATCH] optional explicit sb-alien struct alignment

On Sep 30, 2005, at 12:10 PM, Thiemo Seufer wrote:

> Cyrus Harmon wrote:
>
>> Dear sbcl-devel,
>>
>> The following patch allows for explicitly setting an :alignment
>> keyword option in sb-alien struct definitions such as the following:
>>
>> (sb-alien:define-alien-type align-test-struct
>>     (sb-alien:struct nil
>>                      (s1 sb-alien:unsigned-char)
>>                      (c1 sb-alien:unsigned-char :alignment 16)
>>                      (c2 sb-alien:unsigned-char :alignment 32)
>>                      (c3 sb-alien:unsigned-char :alignment 32)
>>                      (c4 sb-alien:unsigned-char :alignment 8)))
>>
>> This may seem like a rather silly thing to do, but certain compilers
>> support a #pragma pack that packs struct fields more tightly together
>> and this can be used to ensure that the sb-alien struct alignment
>> matches the compilers.
>>
>
> As a sidenote, a plain "#pragma pack" usually means byte-packed to the
> minimal size, which is different to what is wanted here.

Yes, it was not my intent to imply that the example I gave is an  
example for use with a #pragma pack'ed function. OTOH, I assume an  
alien struct in which all the members were set to :alignment 8 would  

Re: [PATCH] optional explicit sb-alien struct alignment

On Oct 3, 2005, at 12:25 PM, Cyrus Harmon wrote:

>> Since compiler writers don't use completely random alignment rules,
>> it might be better to have one :maximum-alignment key for the whole
>> struct/union.
>>
>
> Yes, this might be a better approach for this particular problem.  
> This route seemed more expedient, but I'm open to suggestions on  
> how to handle this as you describe.
>

In GCC, at least, you can specify the minimum alignment, both on the  
structure itself, and on each data member individually. Setting the  
alignment on the structure affects its placement in other structures  
(but doesn't affect the data members inside it), and setting the  
alignment of its data members affects that member (and by  
implication, the default alignment of the struct as a whole). The  
specified alignment doesn't override the normal rules for alignment,  
and thus you can only increase the alignment. If you want to decrease  
it, you must additionally use the "packed" attribute, which gets rid  
of the default minimum alignment.

Thus, it seems best to allow the ability to specify alignment on each  
member individually in the alien API, as well.

Also, while compiler writers may not use _completely_ random  
alignment rules, it almost seems that way on PPC. A double will have  
8-byte alignment iff it is the first element in the struct. In any  

OpenBSD Port?

Hi,

I was wondering who to contact about maintenance of the OpenBSD
port of SBCL. 

TIA

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: OpenBSD Port?

+------------------------------------------------------------------------------
| On (03/10/05 16:55), martin <at> asham.com wrote:
| 
| From: martin <at> asham.com
| To: sbcl-devel <at> lists.sourceforge.net
| Subject: [Sbcl-devel] OpenBSD Port?
| Date: Mon, 03 Oct 2005 16:55:11 -0500
| 
| Hi,
| 
| I was wondering who to contact about maintenance of the OpenBSD
| port of SBCL. 

The problem is the way SBCL deals with memory management. OpenBSD memory
management will not allow SBCL to do what it wants. To port to OpenBSD
would require changes in SBCL in it's memory management machinery.

OpenBSD 3.8 is now even more strict in that area. 

Good Luck :)

Bad design with OpenBSD? SBCL? Sure everyone has their two cents on that
matter, yet that is just the way it is and will probably never run on 
OpenBSD without much effort on SBCL's part.

| 
| TIA
| 
| 

Re: OpenBSD Port?

On Oct 4, 2005, at 8:52 AM, Chris Humphries wrote:

>
> The problem is the way SBCL deals with memory management. OpenBSD  
> memory
> management will not allow SBCL to do what it wants. To port to OpenBSD
> would require changes in SBCL in it's memory management machinery.
>
>

Curiousity compels me to ask: what is the actual problem? There is an  
OpenBSD binary for x86 listed as "available and supported" on the  
webpage...does it not actually work?

James

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

sbcl require problem

Dear sbcl-devel,

I have a strange sbcl problem I was hoping sbcl-devel might be able  
to shed some light on.

Using SBCL 0.9.5.19, if I do the following:

sbcl --eval "(save-lisp-and-die \"small.core\")"

Then this fails:

sbcl --core small.core --eval "(require :sb-bsd-sockets)"

with the message:

  Don't know how to REQUIRE SB-BSD-SOCKETS.
...

But this works:

SBCL_HOME=/usr/local/lib/sbcl sbcl --core small.core --eval  
"(require :sb-bsd-sockets)"

I thought that if I had in /usr/local, I didn't need to set  
SBCL_HOME. Am I mistaken or is this a problem with SBCL and core files?

Thanks,

Cyrus

[Cyrus Harmon] Fwd: Striped lines & funky colors ...

Anyone?

Cheers,

Christophe

Hi Xophe,

I was hoping you might be able to help with diagnosing a problem I'm  
having with SBCL and the MacOS toolbox. The symptom is that the stuff  
drawn on the screen looks rather funky. gbyers suggests that the  
stack might not be aligned on a 16-bit boundary. Obviously, it could  
be other porblems, but I see your initials in a FIXME comment in  
(define-vop (alloc-number-stack-space)) and thought that you might be  
able to shed some light on this. I'm a bit over my head here, but I  
would be very pleased if I could fix this and could then proceed with  
developing SBCL apps using the MacOS APIs.

Thanks,

Cyrus