headers
Terje Norderhaug | 17 May 2011 01:44

Portability with USocket

I have updated the Portability wiki page for MCL with a link to the USocket TCP/IP socket interface, which
supports MCL.

  http://code.google.com/p/mcl/wiki/Portability

USocket provides a portable alternative to using OpenTransport directly in your MCL applications or modules.

Using the portable libraries in place of MCL-specific interfaces facilitates that your code can be used
with other Common Lisp implementations.

Thanks to Chun Tian (binghe) for bringing USocket to MCL. I have found good use for it in MCLIDE and elsewhere.

Any other portable libraries that should be added to the list?

-- Terje Norderhaug
   terje@...

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
Permalink | Reply |
headers
Chun Tian (binghe | 17 May 2011 04:44
Picon

Re: Portability with USocket

Hi, Terje

You're welcome, and actually you did most of the hard parts in the whole porting work.

I'm planning to bring UDP support to usocket's MCL backend, based on MCL's FFI facility; I think it's quite
possible to implement all usocket features in short future.

For "other portable libraries", I think currently the bottleneck is the support of Gray Streams, which
stops a lots of third-party CL packages (include Hunchentoot) running on MCL/RMCL.  I talked about this
before, but I realized that I'm not capable to implement it because of my knowledge limitation.  I hope
someone else (maybe you) could try to work on it instead. The goal is to make a series of loadable MCL patches
as part of trivial-gray-streams project.

--binghe

在 2011-5-17，07:44， Terje Norderhaug 写道：

> I have updated the Portability wiki page for MCL with a link to the USocket TCP/IP socket interface, which
supports MCL.
> 
>  http://code.google.com/p/mcl/wiki/Portability
> 
> USocket provides a portable alternative to using OpenTransport directly in your MCL applications or modules.
> 
> Using the portable libraries in place of MCL-specific interfaces facilitates that your code can be used
with other Common Lisp implementations.
> 
> Thanks to Chun Tian (binghe) for bringing USocket to MCL. I have found good use for it in MCLIDE and elsewhere.
> 
> Any other portable libraries that should be added to the list?
(Continue reading)

Permalink | Reply |
headers
Terje Norderhaug | 17 May 2011 23:26

Re: Portability with USocket

The usocket library provokes a latent flaw in MCL by creating a logical pathname translation with a
"newest" version component. Details:

    http://code.google.com/p/mcl/issues/detail?id=46&can=1

I have uploaded a patch that should be loaded before using usocket:

    http://code.google.com/p/mcl/source/detail?r=045681d521e5

On May 16, 2011, at 4:44 PM, Terje Norderhaug wrote:
> I have updated the Portability wiki page for MCL with a link to the USocket TCP/IP socket interface, which
supports MCL.
> 
>  http://code.google.com/p/mcl/wiki/Portability
> 
> USocket provides a portable alternative to using OpenTransport directly in your MCL applications or modules.
> 
> Using the portable libraries in place of MCL-specific interfaces facilitates that your code can be used
with other Common Lisp implementations.
> 
> Thanks to Chun Tian (binghe) for bringing USocket to MCL. I have found good use for it in MCLIDE and elsewhere.
> 
> Any other portable libraries that should be added to the list?
> 
> -- Terje Norderhaug
>   terje@...

-- Terje Norderhaug
   terje@...
(Continue reading)

Permalink | Reply |
headers
Chun Tian (binghe | 18 May 2011 04:06
Picon

Re: Portability with USocket

Hi, Terje

First, thank you for adjust MCL for this!

The logical pathname definitions in usocket wasn't used by other part of usocket source code, it's purely
used for developers like me to quickly switch the current working directory.  However, I have another
project (cl-net-snmp), which heavily depends on the logical pathname facility when locating some data
files in source code directory.

I think my usage of logical pathname should fall into CL standard (I'm not 100% sure about this, but
apparently it works on most CLs). However, the logical pathname implementation differ between CL
implementations, the ".NEWEST" translation was added for maximum portability, especially needed by
SBCL.  Below is how LispWorks and SBCL differently treat logical pathnames:

In LispWorks:

CL-USER 4 > (translate-logical-pathname "usocket:backend;sbcl.lisp")
#P"/Users/binghe/Lisp/usocket/branches/0.5.x/backend/sbcl.lisp"

CL-USER 5 > (pathname-version *)
NIL

CL-USER 6 > (translate-logical-pathname "usocket:backend;sbcl.lisp.newest")
#P"/Users/binghe/Lisp/usocket/branches/0.5.x/backend/sbcl.lisp"

CL-USER 7 > (pathname-version *)
:NEWEST

In SBCL:
(Continue reading)

Permalink | Reply |
headers
Terje Norderhaug | 18 May 2011 04:39

Re: Portability with USocket

On May 17, 2011, at 7:06 PM, Chun Tian (binghe) wrote:
> I think my usage of logical pathname should fall into CL standard (I'm not 100% sure about this, but
apparently it works on most CLs). However, the logical pathname implementation differ between CL
implementations, the ".NEWEST" translation was added for maximum portability, especially needed by
SBCL.  [...] I don't know how MCL handle this before, and not sure if MCL's previous behavior obey CL
standard ...

MCL may not have been up to spec when it comes to handling logical pathnames with a version component. I place
no blame on anybody for that oversight though. I don't think the pathname version has been used much with MCL.

>> The usocket library provokes a latent flaw in MCL by creating a logical pathname translation with a
"newest" version component. Details:
>> 
>>   http://code.google.com/p/mcl/issues/detail?id=46&can=1
>> 
>> I have uploaded a patch that should be loaded before using usocket:
>> 
>>   http://code.google.com/p/mcl/source/detail?r=045681d521e5
>> 
>> On May 16, 2011, at 4:44 PM, Terje Norderhaug wrote:
>>> I have updated the Portability wiki page for MCL with a link to the USocket TCP/IP socket interface,
which supports MCL.
>>> 
>>> http://code.google.com/p/mcl/wiki/Portability
>>> 
>>> USocket provides a portable alternative to using OpenTransport directly in your MCL applications or modules.
>>> 
>>> Using the portable libraries in place of MCL-specific interfaces facilitates that your code can be
used with other Common Lisp implementations.
>>>
(Continue reading)

Permalink | Reply |
headers
Chun Tian (binghe | 19 May 2011 07:58
Picon

Re: Portability with USocket


在 2011-5-18，10:39， Terje Norderhaug 写道：

> On May 17, 2011, at 7:06 PM, Chun Tian (binghe) wrote:
>> I think my usage of logical pathname should fall into CL standard (I'm not 100% sure about this, but
apparently it works on most CLs). However, the logical pathname implementation differ between CL
implementations, the ".NEWEST" translation was added for maximum portability, especially needed by
SBCL.  [...] I don't know how MCL handle this before, and not sure if MCL's previous behavior obey CL
standard ...
> 
> MCL may not have been up to spec when it comes to handling logical pathnames with a version component. I
place no blame on anybody for that oversight though. I don't think the pathname version has been used much
with MCL.

I want to say something about the pathname version:

Versioned File Systems has disappeared from own sight for over 20 years, but the new Mac OS X Lion [1] seems
bring them back: a new file system facility called "Versions":

"Versions records the evolution of a document as you create it. Mac OS X Lion automatically creates a
version of the document each time you open it and every hour while you’re working on it..."

I don't the tech details yet, but Apple should provide some API for accessing old version of a file in current
filesystem, and these old version are just stored in the same disk with latest version. (like a local form
of Apple's Time Machine technology)

Common Lisp is the only software platform which natively support versioned file system, I would like to
push and actually working on bring new features to the standard function PATHNAME-VERSION.

--binghe
(Continue reading)

Permalink | Reply |
headers
Chun Tian (binghe | 19 May 2011 08:33
Picon

Re: Portability with USocket

Wait, will Rosetta still be in next major version of Mac OS X?

> 
> I want to say something about the pathname version:
> 
> Versioned File Systems has disappeared from own sight for over 20 years, but the new Mac OS X Lion [1] seems
bring them back: a new file system facility called "Versions":
> 
> "Versions records the evolution of a document as you create it. Mac OS X Lion automatically creates a
version of the document each time you open it and every hour while you’re working on it..."
> 
> I don't the tech details yet, but Apple should provide some API for accessing old version of a file in
current filesystem, and these old version are just stored in the same disk with latest version. (like a
local form of Apple's Time Machine technology)
> 
> Common Lisp is the only software platform which natively support versioned file system, I would like to
push and actually working on bring new features to the standard function PATHNAME-VERSION.
> 
> --binghe
> 
> [1] http://www.apple.com/macosx/lion/

_______________________________________________
info-mcl mailing list
info-mcl <at> clozure.com
http://clozure.com/mailman/listinfo/info-mcl
Permalink | Reply |
headers
Sandro Pedrazzini | 19 May 2011 10:57
Favicon

Re: Portability with USocket

It seems not.
This is one of the major problems for RMCL users / developers,  
considering that many applications are still using the MCL graphical  
toolbox.
Am I right?  Are there solutions?

Best regards
Sandro

On 19 May 2011, at 08:33, Chun Tian (binghe) wrote:

> Wait, will Rosetta still be in next major version of Mac OS X?
>
>>
>> I want to say something about the pathname version:
>>
>> Versioned File Systems has disappeared from own sight for over 20  
>> years, but the new Mac OS X Lion [1] seems bring them back: a new  
>> file system facility called "Versions":
>>
>> "Versions records the evolution of a document as you create it. Mac  
>> OS X Lion automatically creates a version of the document each time  
>> you open it and every hour while you’re working on it..."
>>
>> I don't the tech details yet, but Apple should provide some API for  
>> accessing old version of a file in current filesystem, and these  
>> old version are just stored in the same disk with latest version.  
>> (like a local form of Apple's Time Machine technology)
>>
>> Common Lisp is the only software platform which natively support
(Continue reading)

Permalink | Reply |
headers
Pascal Costanza | 19 May 2011 20:30

Re: Portability with USocket


On 17 May 2011, at 01:44, Terje Norderhaug wrote:

> I have updated the Portability wiki page for MCL with a link to the USocket TCP/IP socket interface, which
supports MCL.
> 
>  http://code.google.com/p/mcl/wiki/Portability
> 
> USocket provides a portable alternative to using OpenTransport directly in your MCL applications or modules.
> 
> Using the portable libraries in place of MCL-specific interfaces facilitates that your code can be used
with other Common Lisp implementations.
> 
> Thanks to Chun Tian (binghe) for bringing USocket to MCL. I have found good use for it in MCLIDE and elsewhere.
> 
> Any other portable libraries that should be added to the list?

Although MCL is not my "home" Lisp system, I try to actively maintain MCL support in Closer to MOP and
ContextL as far as possible.

See http://common-lisp.net/project/closer/

Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.

_______________________________________________
info-mcl mailing list
(Continue reading)

Permalink | Reply |

Gmane