Re: Common Lisp port

[Patrick Collison <pa...@collison.ie>]

On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> wrote:
> I'm not sure the attachment made it through. (Was it a file or a link?
> Maybe the Apache list doesn't like that...)

Hmm, seems like it didn't. It's now at http://collison.ie/code/thrift-cl.patch.

Cheers,

Patrick

> Sounds like a cool implementation, and I don't think it violates the
> spirit of Thrift since this sounds like a somewhat natural thing to do
> in the Lisp world for compatibility.
>
> -----Original Message-----
> From: Patrick Collison [mailto:patrick@collison.ie]
> Sent: Monday, June 09, 2008 1:26 AM
> To: thrift-user@incubator.apache.org
> Subject: Common Lisp port
>
> Hey,
>
> Attached is a port to Common Lisp.
>
> It's fairly rough, but since it's now good enough for my uses, I'm
> releasing it in case I never get around to cleaning it up fully.
>
> Some implementation notes:
> - It supports both client and server use.
> - It depends on Allegro Common Lisp for reading and writing floats (CL
> has no portable way of doing this), but adding support here for other
> implementations will be trivial.
> - It requires ASDF (a Common Lisp packaging system), and depends on the
> usocket and trivial-utf-8 libraries.
> - The generator works by translating the Thrift IDL to s-expressions
> (you can see tutorial.thrift's form at
> http://collison.ie/code/thrift-tutorial.lisp), and then doing the actual
> compilation in Lisp. Though this compilation will happen every time the
> source file is loaded, it's very fast: using Allegro, it takes me around
> 10 msec total to compile shared.thrift and tutorial.thrift. Doing the
> compilation at load-time is arguably against the spirit of Thrift, but
> in practice this approach works quite nicely with CL. Since source-files
> are only loaded once per session (which, in deployed systems, tend to
> run for days/months), the overhead is negligible, and greatly outweighed
> by the advantages (simpler code, more compile-time optimisation). It's
> worth pointing out that the load-time compilation is also completely
> transparent to the user, and the code generated by the C++ compiler can
> be loaded as if it were ordinary Lisp code (indeed, thanks to macros, it
> is).
> - There's actually another big reason for the intermediate s-exp
> approach -- it means ports to Scheme/Arc/Your Favourite Lisp Dialect can
> be done without any new C++ generator code.
> - It's the smallest port by a fairly large margin -- 892 non-blank lines
> total (325 lines of C++, 567 lines of CL). By contrast, Haskell
> (say) is 1730 (1285 C++, 445 Haskell), and Ruby is 1845 (848 C++, 997
> Ruby).
>
> Feedback and improvements are of course welcome.
>
> Cheers,
>
> Patrick
>

Re: Common Lisp port

[Patrick Collison <pa...@collison.ie>]

On Mon, Jul 14, 2008 at 5:41 PM, David Reiss <dr...@facebook.com> wrote:
> You need to create a JIRA issue and attach the patch so that you can
> click the box that says you agree to have it distributed under the
> ASL.  After that, we can definitely merge it.

Done: https://issues.apache.org/jira/browse/THRIFT-82

Patrick

> --David
>
> Patrick Collison wrote:
>> Hey folks -- any chance of getting this merged?
>>
>> On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie>
>> wrote:
>>> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> wrote:
>>>> I'm not sure the attachment made it through. (Was it a file or a link?
>>>> Maybe the Apache list doesn't like that...)
>>>
>>> Hmm, seems like it didn't. It's now at
>> http://collison.ie/code/thrift-cl.patch.
>>>
>>> Cheers,
>>>
>>> Patrick
>>>
>>>> Sounds like a cool implementation, and I don't think it violates the
>>>> spirit of Thrift since this sounds like a somewhat natural thing to do
>>>> in the Lisp world for compatibility.
>>>>
>>>> -----Original Message-----
>>>> From: Patrick Collison [mailto:patrick@collison.ie]
>>>> Sent: Monday, June 09, 2008 1:26 AM
>>>> To: thrift-user@incubator.apache.org
>>>> Subject: Common Lisp port
>>>>
>>>> Hey,
>>>>
>>>> Attached is a port to Common Lisp.
>>>>
>>>> It's fairly rough, but since it's now good enough for my uses, I'm
>>>> releasing it in case I never get around to cleaning it up fully.
>>>>
>>>> Some implementation notes:
>>>> - It supports both client and server use.
>>>> - It depends on Allegro Common Lisp for reading and writing floats (CL
>>>> has no portable way of doing this), but adding support here for other
>>>> implementations will be trivial.
>>>> - It requires ASDF (a Common Lisp packaging system), and depends on the
>>>> usocket and trivial-utf-8 libraries.
>>>> - The generator works by translating the Thrift IDL to s-expressions
>>>> (you can see tutorial.thrift's form at
>>>> http://collison.ie/code/thrift-tutorial.lisp), and then doing the actual
>>>> compilation in Lisp. Though this compilation will happen every time the
>>>> source file is loaded, it's very fast: using Allegro, it takes me around
>>>> 10 msec total to compile shared.thrift and tutorial.thrift. Doing the
>>>> compilation at load-time is arguably against the spirit of Thrift, but
>>>> in practice this approach works quite nicely with CL. Since source-files
>>>> are only loaded once per session (which, in deployed systems, tend to
>>>> run for days/months), the overhead is negligible, and greatly outweighed
>>>> by the advantages (simpler code, more compile-time optimisation). It's
>>>> worth pointing out that the load-time compilation is also completely
>>>> transparent to the user, and the code generated by the C++ compiler can
>>>> be loaded as if it were ordinary Lisp code (indeed, thanks to macros, it
>>>> is).
>>>> - There's actually another big reason for the intermediate s-exp
>>>> approach -- it means ports to Scheme/Arc/Your Favourite Lisp Dialect can
>>>> be done without any new C++ generator code.
>>>> - It's the smallest port by a fairly large margin -- 892 non-blank lines
>>>> total (325 lines of C++, 567 lines of CL). By contrast, Haskell
>>>> (say) is 1730 (1285 C++, 445 Haskell), and Ruby is 1845 (848 C++, 997
>>>> Ruby).
>>>>
>>>> Feedback and improvements are of course welcome.
>>>>
>>>> Cheers,
>>>>
>>>> Patrick
>>>>
>>>
>>
>

Re: Common Lisp port

[David Reiss <dr...@facebook.com>]

You need to create a JIRA issue and attach the patch so that you can
click the box that says you agree to have it distributed under the
ASL.  After that, we can definitely merge it.

--David

Patrick Collison wrote:
> Hey folks -- any chance of getting this merged?
> 
> On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie>
> wrote:
>> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> wrote:
>>> I'm not sure the attachment made it through. (Was it a file or a link?
>>> Maybe the Apache list doesn't like that...)
>>
>> Hmm, seems like it didn't. It's now at
> http://collison.ie/code/thrift-cl.patch.
>>
>> Cheers,
>>
>> Patrick
>>
>>> Sounds like a cool implementation, and I don't think it violates the
>>> spirit of Thrift since this sounds like a somewhat natural thing to do
>>> in the Lisp world for compatibility.
>>>
>>> -----Original Message-----
>>> From: Patrick Collison [mailto:patrick@collison.ie]
>>> Sent: Monday, June 09, 2008 1:26 AM
>>> To: thrift-user@incubator.apache.org
>>> Subject: Common Lisp port
>>>
>>> Hey,
>>>
>>> Attached is a port to Common Lisp.
>>>
>>> It's fairly rough, but since it's now good enough for my uses, I'm
>>> releasing it in case I never get around to cleaning it up fully.
>>>
>>> Some implementation notes:
>>> - It supports both client and server use.
>>> - It depends on Allegro Common Lisp for reading and writing floats (CL
>>> has no portable way of doing this), but adding support here for other
>>> implementations will be trivial.
>>> - It requires ASDF (a Common Lisp packaging system), and depends on the
>>> usocket and trivial-utf-8 libraries.
>>> - The generator works by translating the Thrift IDL to s-expressions
>>> (you can see tutorial.thrift's form at
>>> http://collison.ie/code/thrift-tutorial.lisp), and then doing the actual
>>> compilation in Lisp. Though this compilation will happen every time the
>>> source file is loaded, it's very fast: using Allegro, it takes me around
>>> 10 msec total to compile shared.thrift and tutorial.thrift. Doing the
>>> compilation at load-time is arguably against the spirit of Thrift, but
>>> in practice this approach works quite nicely with CL. Since source-files
>>> are only loaded once per session (which, in deployed systems, tend to
>>> run for days/months), the overhead is negligible, and greatly outweighed
>>> by the advantages (simpler code, more compile-time optimisation). It's
>>> worth pointing out that the load-time compilation is also completely
>>> transparent to the user, and the code generated by the C++ compiler can
>>> be loaded as if it were ordinary Lisp code (indeed, thanks to macros, it
>>> is).
>>> - There's actually another big reason for the intermediate s-exp
>>> approach -- it means ports to Scheme/Arc/Your Favourite Lisp Dialect can
>>> be done without any new C++ generator code.
>>> - It's the smallest port by a fairly large margin -- 892 non-blank lines
>>> total (325 lines of C++, 567 lines of CL). By contrast, Haskell
>>> (say) is 1730 (1285 C++, 445 Haskell), and Ruby is 1845 (848 C++, 997
>>> Ruby).
>>>
>>> Feedback and improvements are of course welcome.
>>>
>>> Cheers,
>>>
>>> Patrick
>>>
>>
> 

Re: Common Lisp port

[Patrick Collison <pa...@collison.ie>]

Hey folks -- any chance of getting this merged?

On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie> wrote:
> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> wrote:
>> I'm not sure the attachment made it through. (Was it a file or a link?
>> Maybe the Apache list doesn't like that...)
>
> Hmm, seems like it didn't. It's now at http://collison.ie/code/thrift-cl.patch.
>
> Cheers,
>
> Patrick
>
>> Sounds like a cool implementation, and I don't think it violates the
>> spirit of Thrift since this sounds like a somewhat natural thing to do
>> in the Lisp world for compatibility.
>>
>> -----Original Message-----
>> From: Patrick Collison [mailto:patrick@collison.ie]
>> Sent: Monday, June 09, 2008 1:26 AM
>> To: thrift-user@incubator.apache.org
>> Subject: Common Lisp port
>>
>> Hey,
>>
>> Attached is a port to Common Lisp.
>>
>> It's fairly rough, but since it's now good enough for my uses, I'm
>> releasing it in case I never get around to cleaning it up fully.
>>
>> Some implementation notes:
>> - It supports both client and server use.
>> - It depends on Allegro Common Lisp for reading and writing floats (CL
>> has no portable way of doing this), but adding support here for other
>> implementations will be trivial.
>> - It requires ASDF (a Common Lisp packaging system), and depends on the
>> usocket and trivial-utf-8 libraries.
>> - The generator works by translating the Thrift IDL to s-expressions
>> (you can see tutorial.thrift's form at
>> http://collison.ie/code/thrift-tutorial.lisp), and then doing the actual
>> compilation in Lisp. Though this compilation will happen every time the
>> source file is loaded, it's very fast: using Allegro, it takes me around
>> 10 msec total to compile shared.thrift and tutorial.thrift. Doing the
>> compilation at load-time is arguably against the spirit of Thrift, but
>> in practice this approach works quite nicely with CL. Since source-files
>> are only loaded once per session (which, in deployed systems, tend to
>> run for days/months), the overhead is negligible, and greatly outweighed
>> by the advantages (simpler code, more compile-time optimisation). It's
>> worth pointing out that the load-time compilation is also completely
>> transparent to the user, and the code generated by the C++ compiler can
>> be loaded as if it were ordinary Lisp code (indeed, thanks to macros, it
>> is).
>> - There's actually another big reason for the intermediate s-exp
>> approach -- it means ports to Scheme/Arc/Your Favourite Lisp Dialect can
>> be done without any new C++ generator code.
>> - It's the smallest port by a fairly large margin -- 892 non-blank lines
>> total (325 lines of C++, 567 lines of CL). By contrast, Haskell
>> (say) is 1730 (1285 C++, 445 Haskell), and Ruby is 1845 (848 C++, 997
>> Ruby).
>>
>> Feedback and improvements are of course welcome.
>>
>> Cheers,
>>
>> Patrick
>>
>