Leslie P. Polzer | 1 Oct 09:24 2008
Picon

Re: Compile failure on CLISP 2.46


>> So the libc6 statement would work for 99% of UNIX users
>
> Unix or Linux? What statement would we need on Solaris/ *BSD?

I don't have boxes to check on, but I suppose libc6.so is pretty
safe for UNIX.

>> whereas the current situation works for 0% of CLISP users.
>
> Well, if it really didn't work, I wouldn't have included it in the
> distribution.

Sorry for the bold statement. :)

> It's definitely working for me: Debian/Etch on x86. Are
> any of you also using Debian yet experiencing problems?

I'm using ArchLinux. What does

  ls /lib/libc*

give you? Maybe I'm missing a symbolic link?

  Leslie

--

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/
(Continue reading)

Chun Tian (binghe | 1 Oct 09:35 2008
Picon

Re: Compile failure on CLISP 2.46

在 2008-10-1,15:24, Leslie P. Polzer 写道:

>
>>> So the libc6 statement would work for 99% of UNIX users
>>
>> Unix or Linux? What statement would we need on Solaris/ *BSD?
>
> I don't have boxes to check on, but I suppose libc6.so is pretty
> safe for UNIX.

No. libc.so.6 just for Linux, I think it means the 6th big revision  
(with incompatible API changes) of the GNU C Library.

On Solaris (I have some Solaris 10 (both SPARC and x86) boxes),  
there's no libc.so.6 but libc.so.1:

binghe <at> sparc-1:/usr/lib$ ls -l libc.so*
lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so -> ../../ 
lib/libc.so.1
lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so.1 - 
 > ../../lib/libc.so.1

binghe <at> sparc-1:/usr/lib$ ldd /bin/ls
         libsec.so.1 =>   /lib/libsec.so.1
         libc.so.1 =>     /lib/libc.so.1
         libavl.so.1 =>   /lib/libavl.so.1
         libm.so.2 =>     /lib/libm.so.2
         /platform/SUNW,Ultra-80/lib/libc_psr.so.1

And on FreeBSD (which I don't have a running one), since they also do  
(Continue reading)

Chun Tian (binghe | 1 Oct 09:40 2008
Picon

Re: Compile failure on CLISP 2.46

>>
>
> No. libc.so.6 just for Linux, I think it means the 6th big revision  
> (with incompatible API changes) of the GNU C Library.
>
> On Solaris (I have some Solaris 10 (both SPARC and x86) boxes),  
> there's no libc.so.6 but libc.so.1:
>
> binghe <at> sparc-1:/usr/lib$ ls -l libc.so*
> lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so - 
> > ../../lib/libc.so.1
> lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so.1 - 
> > ../../lib/libc.so.1
>
> binghe <at> sparc-1:/usr/lib$ ldd /bin/ls
>        libsec.so.1 =>   /lib/libsec.so.1
>        libc.so.1 =>     /lib/libc.so.1
>        libavl.so.1 =>   /lib/libavl.so.1
>        libm.so.2 =>     /lib/libm.so.2
>        /platform/SUNW,Ultra-80/lib/libc_psr.so.1
>
> And on FreeBSD (which I don't have a running one), since they also  
> do not use GNU C Library either, it's quite possible that the  
> libc.so revision isn't "6" too.
>
> But, on all UNIX, I think the file "/usr/lib/libc.so" will be the  
> right answer.

Except Darwin (Mac OS X), which is "/usr/lib/libc.dylib", which point  
to "libSystem.dylib", I don't know if it's also from FreeBSD.
(Continue reading)

Hans Hübner | 1 Oct 12:02 2008

Re: Compile failure on CLISP 2.46

"libc.so" is somewhat of the standard system default on all things
Unix, with Darwin being different.  The idea is to have libc.so be a
symbolic link to the real thing.  Loading with an explicit version
number is a bad idea, but then, Unix is full of bad ideas.

What I mean to say is:  There is no sensible way to load libc in a
system independent manner.  It is certainly supposed into every
program anyway.

-Hans

On Wed, Oct 1, 2008 at 03:40, Chun Tian (binghe)
<binghe.lisp@...> wrote:
>>>
>>
>> No. libc.so.6 just for Linux, I think it means the 6th big revision (with
>> incompatible API changes) of the GNU C Library.
>>
>> On Solaris (I have some Solaris 10 (both SPARC and x86) boxes), there's no
>> libc.so.6 but libc.so.1:
>>
>> binghe <at> sparc-1:/usr/lib$ ls -l libc.so*
>> lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so ->
>> ../../lib/libc.so.1
>> lrwxrwxrwx   1 root     root          19 Aug  4 17:16 libc.so.1 ->
>> ../../lib/libc.so.1
>>
>> binghe <at> sparc-1:/usr/lib$ ldd /bin/ls
>>       libsec.so.1 =>   /lib/libsec.so.1
>>       libc.so.1 =>     /lib/libc.so.1
(Continue reading)

Tobias C. Rittweiler | 1 Oct 12:02 2008
Picon

Re: What if a usocket instance be garbage collected?

"Chun Tian (binghe)" writes

> Hi, usocket devel
>
> If a usocket instance has been garbage collected (or just cannot refer
> to it, i. e. lost it by set the variable to new value), does anyone
> (either usocket or CL platform) will consider closing the correspond
> socket fd automatically?

I think the general consensus is not to misuse the Garbage Collector as
a general ressource manager. You never know when GC is run, if it's run
at all, etc. 

In Lisp, automatic ressource deallocation is most often done in the
cleanup clauses of an UNWIND-PROTECT that's nicely abstracted in some
WITH-FOO macro.

> I know at least one CL platform, LispWorks, has some related API
> (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP
> applications. Just don't know if this will be a common feature to be
> considered by usocket itself.

The usual terminology for this kind of stuff is "finalizers". What you
could do, is to add a finalizer that signals a warning if a socket
object is going to be garbage collected that wasn't closed previously.

  -T.
Erik Huelsmann | 1 Oct 14:11 2008
Picon

Re: Re: What if a usocket instance be garbage collected?

On Wed, Oct 1, 2008 at 12:02 PM, Tobias C. Rittweiler <tcr@...> wrote:
> "Chun Tian (binghe)" writes
>
>> Hi, usocket devel
>>
>> If a usocket instance has been garbage collected (or just cannot refer
>> to it, i. e. lost it by set the variable to new value), does anyone
>> (either usocket or CL platform) will consider closing the correspond
>> socket fd automatically?

Well, in case of using a socket as supported by the underlying
implementation, the implementation will take care of closing the
socket.

> I think the general consensus is not to misuse the Garbage Collector as
> a general ressource manager. You never know when GC is run, if it's run
> at all, etc.

Right. However, if the object refering to some external resource is
not explicitly closed, you might want to do so if the object is
garbage collected.

> In Lisp, automatic resource deallocation is most often done in the
> cleanup clauses of an UNWIND-PROTECT that's nicely abstracted in some
> WITH-FOO macro.

Yes, however, from the point of view of the library, this can't be
guaranteed. If the library can make sure the resources will be
de-allocated, I'm of the opinion it should.

(Continue reading)

Tobias C. Rittweiler | 1 Oct 14:47 2008
Picon

Re: What if a usocket instance be garbage collected?

"Erik Huelsmann" writes:

> > In Lisp, automatic resource deallocation is most often done in the
> > cleanup clauses of an UNWIND-PROTECT that's nicely abstracted in some
> > WITH-FOO macro.
>
> Yes, however, from the point of view of the library, this can't be
> guaranteed. If the library can make sure the resources will be
> de-allocated, I'm of the opinion it should.

I think it's reasonable for the library to hook into the garbage
collector, and warn about garbage-collected but not yet closed external
ressources (and close them, incidentally.)

It should, however, not try to make the user think that relying on the
GC for closing external ressources is a good design choice.

  -T. 
Chun Tian (binghe | 1 Oct 23:13 2008
Picon

Re: Re: What if a usocket instance be garbage collected?

>
>>> I know at least one CL platform, LispWorks, has some related API
>>> (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP
>>> applications. Just don't know if this will be a common feature to be
>>> considered by usocket itself.
>
> It doesn't need to be applied to other backends in general, however,
> it does need to be applied to all implementations which make direct
> use of the handles (non-lisp objects) supplied by the operating
> system.
>
>> The usual terminology for this kind of stuff is "finalizers". What  
>> you
>> could do, is to add a finalizer that signals a warning if a socket
>> object is going to be garbage collected that wasn't closed  
>> previously.
>
> Right. However, implementations which provide objects for this purpose
> should take care of this themselves because usocket uses the
> implementation supplied sockets. Only in those cases where such
> guarantees are missing, usocket needs to take additional measures.
> This includes LispWorks, but additional investigation will turn up if
> this is the only implementation affected.

I'm quite sure that only UDP stuff being affected (which haven't been  
merged into USOCKET). For TCP, the CL implementation itself will take  
good care of TCP streams and close the socket fd when streams being  
GCed.

After more investigation, I think there're two implementations of five  
(Continue reading)

Chun Tian (binghe | 2 Oct 18:15 2008
Picon

Re: [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT

Hi, usocket

Anyone review this patch? Should it be applied? (If sure, I'll commit  
it by myself)

--binghe

在 2008-9-7,23:46, Chun Tian (binghe) 写道:

>
> 在 2008-9-7,下午11:33, Hans Hübner 写道:
>
>> On Sun, Sep 7, 2008 at 17:09, Chun Tian (binghe)
<binghe.lisp@... 
>> > wrote:
>>
>>> So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT  
>>> keyword
>>> supply, (TRUNCATE NIL) will be called, and error happens. How to  
>>> fix this
>>> issue to make sure I can just wait "infinitely" on a usocket?
>>
>> Not having tried it, but (and timeout (truncate timeout)) should  
>> do, no?
>
> I don't think so.
>
> MP:PROCESS-WAIT-WITH-TIMEOUT must be called with a TIMEOUT parameter  
> as integer (in seconds). If TIMEOUT is NIL, WAIT-FOR-INPUT-INTERNAL  
> maybe should turn to call MP:PROCESS-WAIT instead of MP:PROCESS-WAIT- 
(Continue reading)

Chun Tian (binghe | 2 Oct 18:34 2008
Picon

Request for new experimental branch about UDP and others

Hi, usocket devel (Erik and Hans)

(sorry for my poor English first)

As you guys already know, I'm working on some UDP-relate packages'  
development, and already got a working UDP patch for usocket project.  
I also want to do more on this area (portable Common Lisp networking),  
following is my interesting part:

  * UDP (already have some code)
  * ICMP (ping)
  * UDP Multicasting
  * UNIX Domain Socket (AF_LOCAL)

I want to stay in the framework which USOCKET already have, and try to  
extensive it to support more features. Erik agreed to give me SVN  
commit access and now I wish to open a new branch for above  
experimental work. As the first mission, I'll merge all my UDP patch  
into this new branch.

I think a branch with name "udp" or "binghe" (like the "hans" branch  
before) will be OK, but as a new member I don't think I should make  
this branch by my self (that's not quite polite, I think). So I'm  
looking for opinions or a branch made by Erik for me to commit codes.

Regards,

Chun Tian (binghe)

Gmane