Portability with USocket

Discussion:

Terje Norderhaug

2011-05-16 23:44:22 UTC

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-M3Gj+hvk7k9dz2imjWt+***@public.gmane.org

Chun Tian (binghe)

2011-05-17 02:44:52 UTC

Permalink

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 写道：

Post by 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?
-- Terje Norderhaug
_______________________________________________
info-mcl mailing list
http://clozure.com/mailman/listinfo/info-mcl

Terje Norderhaug

2011-05-17 21:26:20 UTC

Permalink

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

-- Terje Norderhaug
terje-M3Gj+hvk7k9dz2imjWt+***@public.gmane.org

Chun Tian (binghe)

2011-05-18 02:06:51 UTC

Permalink

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:

* (translate-logical-pathname "usocket:backend;sbcl.lisp")

#P"/Users/binghe/Lisp/usocket/branches/0.5.x/backend/sbcl.lisp"
* (pathname-version *)

:NEWEST

See, SBCL treat every logical pathname without a explicit version as "newest" version, and automatically fill the version component of translated pathname instance. If I didn't add the ".NEWEST" translation rule, a normal logical pathname cannot be translated correctly in SBCL.

Clozure CL also fill the version component as :NEWEST, but the translation can work without the ".NEWEST" rule.

I don't know how MCL handle this before, and not sure if MCL's previous behavior obey CL standard ...

Regards,

Chun Tian (binghe)

在 2011-5-18，05:26， Terje Norderhaug 写道：

Post by Terje Norderhaug
http://code.google.com/p/mcl/issues/detail?id=46&can=1
http://code.google.com/p/mcl/source/detail?r=045681d521e5

-- Terje Norderhaug
_______________________________________________
info-mcl mailing list
http://clozure.com/mailman/listinfo/info-mcl

Terje Norderhaug

2011-05-18 02:39:48 UTC

Permalink

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.

Post by Terje Norderhaug
http://code.google.com/p/mcl/issues/detail?id=46&can=1
http://code.google.com/p/mcl/source/detail?r=045681d521e5

-- Terje Norderhaug
terje-M3Gj+hvk7k9dz2imjWt+***@public.gmane.org

Chun Tian (binghe)

2011-05-19 05:58:42 UTC

Permalink

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

Post by Terje Norderhaug

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/

Chun Tian (binghe)

2011-05-19 06:33:36 UTC

Permalink

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

Post by Chun Tian (binghe)
"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/

Sandro Pedrazzini

2011-05-19 08:57:15 UTC

Permalink

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

Post by Chun Tian (binghe)
Wait, will Rosetta still be in next major version of Mac OS X?

Post by Chun Tian (binghe)
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
"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
http://clozure.com/mailman/listinfo/info-mcl

Pascal Costanza

2011-05-19 18:30:22 UTC

Permalink

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.