[Admin] hosting the UBF-in-CL project
Hi all, I was hoping to get ftp space for an arch archive & download area for my UBF-in-CL package. UBF is the Universal Binary Format by Joe Armstrong (it is documented in http://www.sics.se/~joe/ubf/site/home.html). You could call it a tasteful alternative to XML; it doesn't use SEXPs but a stack-based format and has special provisions for binary data as well as strings, integers, symbols and type-tagged objects. Currently, only the UBF(A) format is implemented (a reader and a writer exist, both perform reasonably well) Despite there being another implementation in Common Lisp (which is only mentioned in a mailing list post with no source code to be found /-:), let's call it "ubf" (-: The only contributor at the moment is me; the code is in the public domain. Thanks, -- Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
Andreas Fuchs <asf@boinkor.net> writes:
Hi all,
I was hoping to get ftp space for an arch archive & download area for my UBF-in-CL package.
You do not want our version control facilities? Awww... :)
UBF is the Universal Binary Format by Joe Armstrong (it is documented in http://www.sics.se/~joe/ubf/site/home.html). You could call it a tasteful alternative to XML; it doesn't use SEXPs but a stack-based format and has special provisions for binary data as well as strings, integers, symbols and type-tagged objects. Currently, only the UBF(A) format is implemented (a reader and a writer exist, both perform reasonably well)
Despite there being another implementation in Common Lisp (which is only mentioned in a mailing list post with no source code to be found /-:), let's call it "ubf" (-:
Well, I wouldn't call a linear algebra package "linear algebra", or an XML parser "xml", because they aren't what their name sugests. I would prefer something along the lines of "ubf.lisp", or "cl-ubf", "UBF-in-CL" etc.
The only contributor at the moment is me; the code is in the public domain.
Is my guess corect that you are an austrian citizen living in austria? I ask because at least in germany it is not possible to put things in the public domain... Regards, Mario.
Today, Mario Mommer <mommer@igpm.rwth-aachen.de> wrote:
I was hoping to get ftp space for an arch archive & download area for my UBF-in-CL package. You do not want our version control facilities? Awww... :)
heh, it's in arch already - there is no way to export it into CVS *lalala* (-;
Despite there being another implementation in Common Lisp (which is only mentioned in a mailing list post with no source code to be found /-:), let's call it "ubf" (-:
Well, I wouldn't call a linear algebra package "linear algebra", or an XML parser "xml", because they aren't what their name sugests. I would prefer something along the lines of "ubf.lisp", or "cl-ubf", "UBF-in-CL" etc.
ah, good one. I was thinking that it would fit in well together with rfc<nnnn> (cl implementations of the respective RFCs) and linedit (a line editing package) (-: cl-ubf will do, of course.
The only contributor at the moment is me; the code is in the public domain.
Is my guess corect that you are an austrian citizen living in austria? I ask because at least in germany it is not possible to put things in the public domain...
I am an Austrian, living in Austria, and now that you mention it, I'm not so sure about the PD situation here, either. I'll change the licence to a BSD one (sans advertising clause), which should be OK. -- Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
"Andreas Fuchs <asf@boinkor.net>" <asf@boinkor.net> writes:
Today, Mario Mommer <mommer@igpm.rwth-aachen.de> wrote:
I was hoping to get ftp space for an arch archive & download area for my UBF-in-CL package. You do not want our version control facilities? Awww... :)
heh, it's in arch already - there is no way to export it into CVS *lalala* (-;
:-) I read over "arch archive" and only saw "archive". Well, ok. Erik, do we support arch? I remember we talked about it as a possibility, but I do not remember what was decided.
Well, I wouldn't call a linear algebra package "linear algebra", or an XML parser "xml", because they aren't what their name sugests. I would prefer something along the lines of "ubf.lisp", or "cl-ubf", "UBF-in-CL" etc.
ah, good one. I was thinking that it would fit in well together with rfc<nnnn> (cl implementations of the respective RFCs) and linedit (a line editing package) (-:
Which is a good argument against the rfc<nnnn> names. I think I just changed my mind on those rfc<nnnn> names; I don't think anymore that they are good names, because the projects aren't the rfc. Linedit is an invented word, afaict, so I'd think it is 100% ok.
cl-ubf will do, of course.
Ok.
I am an Austrian, living in Austria, and now that you mention it, I'm not so sure about the PD situation here, either. I'll change the licence to a BSD one (sans advertising clause), which should be OK.
Ok. Then, as far as I am concerned, I think your project should get hosting here. The only thing that remains to be cleared is whether we support arch or not. Regards, Mario.
On Fri, Sep 12, 2003 at 01:34:40PM +0200, Mario Mommer wrote:
Erik, do we support arch? I remember we talked about it as a possibility, but I do not remember what was decided.
I don't think anythink got decided, but then again arch requires very little in the way of support: if the $project/ftp and $pubftp/project are in sync (or preferably the same directory), then the arch users are set up. ;)
Well, I wouldn't call a linear algebra package "linear algebra", or an XML parser "xml", because they aren't what their name sugests. I would prefer something along the lines of "ubf.lisp", or "cl-ubf", "UBF-in-CL" etc.
I'm get more and more agnostic on the naming issues as time passes by. ;) The only thing I'd comment against would be gratuitious .lisp postfixes and cl- prefixes, unless the project provides cl bindings to a foreign linbrary -- in which case cl-foo makes perfect sense. But I'm saying this "just for the record", not against cl-ubf as a name. I think a good guideline is: "Would you dedicate a CLiki page by that name to you project?". Cheers, -- Nikodemus
Nikodemus Siivola <nikodemus@random-state.net> writes:
On Fri, Sep 12, 2003 at 01:34:40PM +0200, Mario Mommer wrote:
Erik, do we support arch? I remember we talked about it as a possibility, but I do not remember what was decided.
I don't think anythink got decided, but then again arch requires very little in the way of support: if the $project/ftp and $pubftp/project are in sync (or preferably the same directory), then the arch users are set up. ;)
Ok, then it looks like we support arch :)
I'm get more and more agnostic on the naming issues as time passes by. ;)
The only thing I'd comment against would be gratuitious .lisp postfixes and cl- prefixes, unless the project provides cl bindings to a foreign linbrary -- in which case cl-foo makes perfect sense.
Hm.
But I'm saying this "just for the record", not against cl-ubf as a name.
Ok.
I think a good guideline is: "Would you dedicate a CLiki page by that name to you project?".
Since Andreas looks every bit like he would, I consider his request approved, up to objections by others... Regards, Mario.
Which is a good argument against the rfc<nnnn> names. I think I just changed my mind on those rfc<nnnn> names; I don't think anymore that they are good names, because the projects aren't the rfc. Linedit is an invented word, afaict, so I'd think it is 100% ok.
I don't fully understand your motivation. We're already in the context of CL, so cl-rfc822 sounds superfluous to me. It annoys me every time I say: (cl-ppcre:scan ...) Having to say (cl-rfc822:parse-date ...) is so silly. IMHO, of course. Nicknames could be a solution to that. If I'm in comp.lang.python and make a reference to the Common Lisp implementation of rfc822 I would probably say "a CL implementation of rfc822". If it's a package in Debian, I have no problems with the Debian package being named cl-rfc822. djb's RFC 822 implementation is called "mess822"; the Python module is called "rfc822" so is the Ruby version. I guess I'm being a bit stubborn. I think I see what you mean; you're not suggesting that we have cl-araneida and cl-sb-sockets, but rather that proper names such as RFC 822 should be cl-rfc822 to indicate that this is not the proper thing itself but rather an implementation of it. Whatever the popular vote is, I'll go with it. One good thing about having packages prefixed with cl- like that is that a Google search for "cl-rfc822" should be fairly indicative of whether there is such a package out there or not.
Then, as far as I am concerned, I think your project should get hosting here.
I agree.
The only thing that remains to be cleared is whether we support arch or not.
Andreas summarized the things I had to do to make that a reality in an email some time back. I'll have a look at it again and see if I can get the time to set this up rather rapidly. Erik.
erik-nittin@imeme.net wrote:
I guess I'm being a bit stubborn. I think I see what you mean; you'renot suggesting that we have cl-araneida and cl-sb-sockets, but ratherthat proper names such as RFC 822 should be cl-rfc822 to indicate thatthis is not the proper thing itself but rather an implementation of it. Whatever the popular vote is, I'll go with it.
I definitely prefer ubf over cl-ubf. I think we should use the cl- prefix when it's a cl wrapper of an existing library. I also strongly dislike the rfcXXX convention. Why not use something like "mime" or "mime-headers". The python module used to be called rfc822 but now it's "email". miles
Miles Egan <miles@caddr.com> writes:
I also strongly dislike the rfcXXX convention. Why not use something like "mime" or "mime-headers". The python module used to be called rfc822 but now it's "email".
I personally don't like "email" because it's too general and specific a name for that package at the same time, but anyway; what should I call my RFC 2822 implementation? I guess I could go with the title: "Internet Message Format". Too long for my carpal tunnel but some good nicknames might solve that. I like rfc2822 because it is very specific and, to me at least, unambiguous. If I saw "Internet Message Format" I might think "is that an implementation of rfc2822 or is there some other format out there that I don't know about". This discussion creeps up every now and then and I suggest this time we finish it and document our decision and see if we can't convince the rest of the CL world to adopt our policy too (yeah, right). I'm easy: I'll go with the popular vote. Erik.
Erik Enge wrote:
Miles Egan <miles@caddr.com> writes:
I also strongly dislike the rfcXXX convention. Why not use something like "mime" or "mime-headers". The python module used to be called rfc822 but now it's "email".
I personally don't like "email" because it's too general and specific a name for that package at the same time, but anyway; what should I call my RFC 2822 implementation? I guess I could go with the title: "Internet Message Format". Too long for my carpal tunnel but some good nicknames might solve that.
I like rfc2822 because it is very specific and, to me at least, unambiguous. If I saw "Internet Message Format" I might think "is that an implementation of rfc2822 or is there some other format out there that I don't know about".
To me rfcXXX is extremely ambiguous because I can't remember what all the rfc numbers are. Obvious seems better than precise in this case. miles
Miles Egan <miles@caddr.com> writes:
Obvious seems better than precise in this case.
Heh, yeah, exactly, and to my ear "rfc2822" is obvious whereas "internet message format" isn't. Ah, a classic problem this. :-) But let me make something clear: I don't /really/ care what the convention is. I do care that there is a convention and if we all can agree on one I'll happily follow it (I'll even rename my rfc2822 package). So, is our plan so far: cl- for wrappers around libraries; proper nouns are preferable; RFCs use a shortned version of their title? Erik.
Erik Enge <erik@nittin.net> writes:
Miles Egan <miles@caddr.com> writes:
Obvious seems better than precise in this case.
Heh, yeah, exactly, and to my ear "rfc2822" is obvious whereas "internet message format" isn't. Ah, a classic problem this. :-) [...] So, is our plan so far: cl- for wrappers around libraries; proper nouns are preferable; RFCs use a shortned version of their title?
Sounds good so far, except that I don't know if that is too inflexible for rfcs. I tried to find some guidelines at sourceforge, but found none. Any ideas how they deal with this? And savvannah? Regards, Mario.
On Fri, Sep 12, 2003 at 03:01:23PM -0400, Erik Enge wrote:
This discussion creeps up every now and then and I suggest this time we finish it and document our decision and see if we can't convince the rest of the CL world to adopt our policy too (yeah, right).
This issue is potentially tad larger than just us, though. And even if it is a pain, things *can* be restructured later. [ Think of the Great Renaming if you don't belive. ] I'm personally assuming that a shared (or at least "mostly shared") namespace between Common-lisp.net, CCLAN and CLiki would be a Good Thing, and this seems to have at least some support on the other side of the fence as well. First things first: "Do we want to try for a namespace shared with CCLAN and CLiki?" I say yes. Cheers, -- Nikodemus
Andreas Fuchs <asf@boinkor.net> writes:
Despite there being another implementation in Common Lisp (which is only mentioned in a mailing list post with no source code to be found /-:), let's call it "ubf" (-:
I fear our namingconvention-discussing might take a while. Why don't we go ahead and create "ubf" as a project for Andreas so he can at least start using our services? Erik.
participants (7)
-
Andreas Fuchs -
Andreas Fuchs <asf＠boinkor.net>
-
Erik Enge -
erik-nittin＠imeme.net -
Mario Mommer -
Miles Egan -
Nikodemus Siivola