admin

admin@common-lisp.net

1485 discussions

[admin] project request
by Nick Allen 07 Aug '06

07 Aug '06

Hello, I'd like to apply for a common-lisp.net hosting for some code I wrote Name: Nick Allen GPG key: I don't have one yet, but I'll get one shortly Project name: cl-component License: BSD Contributors: Nick Allen Description: an orthogonal, extendible library for defining and examining dependencies between CLOS objects provides a COMPONENT class that extends MAKE-INSTANCE, REINITIALIZE-INSTANCE, etc with a :DIRECT-SUBCOMPONENTS keyword. Instances of COMPONENT class can be examined with the following funtions direct-subclasses direct-superclasses and both instances of COMPONENT class and lists of instances of COMPONENT class can also be more thoroughly examined with the following functions: all-subclasses all-superclasses subcomponent-hierarchy supercomponent-hierarchy which also take an optional "test" and "recurse-failed-subcomponent?"/"recurse-failed-supercomponent?" args to allow the user to efficiently examine obfuscated nets while only generating as many cons cells as are needed for the returned list. There is also a simple metaprotocal to allow users to extend the behavior of the COMPONENT class and its subclasses and some condition stuff dealing with circular dependencies... ... SUBCOMPONENT-HIERARCHY and SUPERCOMPONENT-HIERARCHY will hopefully be useful for things like recompiling in order all supercomponents of an arbitrary group of files from a defined system or loading an arbitrary group of modules and their shared dependencies. Once I get an internet home for the project I'm going to drop a line on c.l.l. and cl-gardeners and see if there would be interest in starting a mailing list to discuss what a system-definition facility based on this library might look like... thanks for your time Nick

2 2

[admin] added cl-component; owned by nallen
by root＠common-lisp.net 07 Aug '06

07 Aug '06

Add successful at 2006.08.07.07.26.

1 0

[admin] project-creation request for common-lisp.net - tioga project
by Sean Champ 05 Aug '06

05 Aug '06

Hello, I would like to request that a project would be created at common-lisp.net. Here is summary on the immediate goals of the project: - ultimately, to make a Linux distribution -- deriving it on Debian (and possibly, on Ubuntu, and maybe, on Mepis, there's a little chain across how those two are derived, and it anchors, at a point, on Debian) -- for the purpose of developing and distributing an "out-of-the-box" Common Lisp environment, designed as to be so, and distributed on a Linux OS. other operating system kernels may be supported of the project. Directly of the Debian projects, there are already at least two Debian distributions, made for BSD-area kernels -- one of which uses one kFreeBSD (?) as a kernel, and the other, it uses NetBSD. As I recall, there was a distribution in regards to BeOS. Speaking by experience, Debian packaging may also be supported for QNX hosts. (I mean no offense to the QNX developers. For a developer familiar with Debian conventions, it could be easier for that developer to use Debian packaging, contrasted to to the QNX packaging system.) - To gather, to develop, and to draw focus to a number of 'baseline libraries' for the Common Lisp environment -- one of which would be the SSC project, I observe, recently added to common-lisp.net. I understand that the SSC project would serve as a premier, cross-implementation interface onto the implementation's threading mechanism. In demonstration of some intention, about the project: Once understanding how SSC is to be implemented, I hope I will have an opportunity to produce and to propose a patch onto McCLIM, for using SSC as the threading interface in the kit. It is my hope that in consequence iwth such a matter of effort, there may become less duplication of code across Common Lisp systems, and that there may become more familiarity, by develoeprs (myself included, to be sure) familiarity with some general-purpose libraries. I consider that some discussion about "shared functionality", in regards to software systems design, might be apropos. I will have to make that as a focus, for some explanation about the Tioga project. I consider that I should denote, in the production of this project request: I intend to add to the tioga project's codebase, a number of library systems that I have been working on -- but to ensure that those systems are all scrubbed-out, production-ready, "clean" before releasing the codebases out from within my own Arch repository. (There had been a time of some months, in which I was not able to obtain a direct connection to the internet, from my home computer. During that time, I had begun to develop a couple of library systems -- one 'commonlibrary', just some basic library routines, condition types, etc; another, 'commonobject', with some extensions onto CLOS and MOP; another, 'commonsystem', but that one is the most of a mess. The last of those has been made as to include some extensions onto ASDF, but I have been uneasy about how it has been approached. I can find some difficulty at approaching the ASDF codebase -- ASDF::TRAVERSE, I cannot seem to do any work with, and it not begin to behave in an unexpected manner, such that I cannot determine the cause of, in any time I've so much as endeavored upon it. I would like to consider MK:Defsystem as the driver system-definition library to the Tioga project, but I am not sure of how it is going to be developed. There is no public Defsystem 5, as yet. ) (I realize, some of those projects would be similar to existing projects -- such as CLOCC's cllib, and I recall that there is a sort of MOP-related project at common-lisp.net. Of all code that is an extension on the Common Lisp language, then of what libraries that I have written, I am the most familiar with those. ) - To make a Debian Linux/GNU installation to be easier for the desktop user, and for the hosts administrators, and for the networks administrators, each, to use; to endeavor to develop Common Lisp systems, in so doing. Most of those systems would probably be interfaed with CLIM. - To address the distribution of Common LIisp software systems, in such that may be made to include support about the hosts' primary packaging system, but should not be made in disregard of the question, "What would be the most convenient thing, for the developer?" That might be addressed to an effect of something like a BSD 'ports' kind of system on Debian -- the OS distributor taking the responsability to ensure tha the code works, and works correctly with other code, before distributing it. - I suppose that some unit-testing would be a requisite part to it. Not to add "just to add another to the stuck", but I may have to develop more of what was a testing system called Rubrics; it could be hosted in the Tioga project archives. - To address ECMA TR/69, <Reference Model for Project Support Environments>, onto a Common Lisp systems environment. TR/69 is a 'standard' kind of publication. TR/69 is freely available via http://www.ecma-international.org/publications/techreports/E-TR-069.htm In some regards, TR/69 depends on ECMA's TR/55. (The latter of those is linked from within the page at the previous URL). As a part to the Tioga project, there may be produced some discussion of how features of TR/55 are addressed -- addressed in implementation, whether or not the implemnetation was intended as an implementation upon TR/55, but in such that would be applicable onto TR/55 -- and are addressed, within the Debian Linux complement of the free/open source softare systems environment. --------- In regards to licensing: Any code produced of the Tioga project should be licensed upon terms of the Franz LLGPL. --------- In regards to sytems logisitcs: - I would like to request the group name, 'tioga', for the project As I have come to understand it: "Tioga" is a transliteration of a word from a Native American dialect. I am not sure, offhand, what the original word would mean; the transliterated form is applied in the name of a mountain pass, in the Sierra Nevada mountains, in California. (Tioga Pass opens from the east end of Yosemite Valley, opening onto the Great Basin -- or opening onto the valley, if you're heading from the basin. Considering how stark is the climate of the Great Basin, as well as how lush is the vegetative quality of Yosemite Valley, Tioga Pass is quite a transition area.) - I would like to request that a 'trac' instance would be initialized for the project. - If it would matter, the project should not need a mailing list for transmittal of logs about CVS checkins. TLA 'log' output may be enough; there may need not be any further resources allocated for it, and I would not ask to request any. - In addition to the other (standard) project mailing lists I would like to request if a 'tioga-admin' list may be initialized for the project. I consider that the tioga-admin list may serve as a forum for discussion about the development of the Tioga project web site. Certainly, the list would be as like a forum, available in regards to any more of material pertaining about the administration of the Tioga project. - I do not have a shell account with common-lisp.net. If I would have the opportunity to request a user name, I would request the user name 'schamp' - attached to this email is an ASCII-armored export of the public compliment to my public-projects GPG key. I have generated a revocation certificate for it, and stored it for safe keeping) - I consider that I should menton: That it is my intention that the Tioga project will use TLA -- Tom Lord's Arch, an implementation of the GNU arch SCCM architecture -- as the SCCM service for codebases of the Tioga project. I consider that it would be your pergative, if there would be no CVS archives that would be initialized for the Tioga project. I will state, simply, that there should not need to be a CVS archive, for the Tioga project. (I am aware that CVS and TLA systems may be made to interoperate. I have yet to have found that it would be absolutely necessary that they would be made to do as so. I am already familiar with CVS. I can use a CVS client, for simple operations onto a CVS archive.) ----- (NB: If your time would be short and if you would not want to read an introduction about TLA, I would recommend, cordially, that you may skip over the following section of this email.) (I intend to produce an introduction about TLA, such that I consider may be taken as to be in interst for the Common Lisp developer community. Given an apperance of a reasonable cause, here, as for to produce a draft for the intorudction, now -- and it would be in this email -- but I mean to address, to you, here: Considerations that may be of relevance to the hosts-administrator, in regards to GNU Arch) I am aware that an Arch 'archive' (viz. repository) may be accessed by way of the following means -- and that the burden for the access would reside, almost entirely, at the client end: * local filesystem * SSH * HTTP -- when without DAV support being available in the host (no problem) then operating for read-only access (no problem) In regards to a remote repository access, as onto a remote TLA archive, then in regards to access onto common-lisp.net : To a user who would be able to log in on the common-lisp.net SSH host (namely, to a user who would have an account at common-lisp.net), to that user, SSH access would be the most feasible. (In sidebar: As for the Tioga codebase: SSH would be the access method used by developers on the Tioga project.) To a user who would not have an account to the SSH service at common-lisp.net: The HTTP access method should serve to be enough. As such, each user would make a 'mirror' of a selected archive 'category' (viz a viz a CVS 'module') then mirroring any selected portions of the upstream 'category' (across each selected category, branch, version, and changeset), mirroring it into another archive, of the the user's own determination -- e.g. so that it would be locally accessible, on the user's primary desktop. When the user would not be able to access the repository by way of SSH, then the user would need only an HTTP URL for the remote archive -- and tla would have to be installed on the client that the user would use for this -- so as to do so. (Of course, when the user would access the upstream repository by way of HTTP, and when the repository would be read-only to the user, then any changes that the user would make onto the codebase of the repository, when submitted, those changes would need to be submitted by way of email. TLA could be used as to make this fairly easy, however -- the user could simply produce a 'changeset' batch, then tar-gzip it up, and send) The HTTP access method , it should not serve to occasion any burden on the common-lisp.net web server. TLA operates as to package each changeset, packaging the files of each one into an individual, gzipped tape archive (and then, the archive file is checksummed). So, rather than a group of individual files being accessed, it would be a single, compressed archive, accessed by the TLA client, and accessed on each selected changeset. (You know, I would like to recommend the following, to your consideration, and I will have to take care of such, on the Tioga project's TLA archives -- will have to look back over this email, after sending it: That some robots-exclusion rules should be made, such that would be mapped onto the HTTP-accessible compliments of the project's TLA archive directories -- as such, into a robots.txt file in the host's document root, and so as to prevent access that may be otherwise made to those directories, as by web-spidering systems. There's not much sense they could probably make of those gzipped archives, anyway.) I'm sure you may be aware of the previous. I'm sure that you may be aware, additionally, that TLA need not be installed onto the system that would be running the file hosting for an archive, as when that host would be remotely accessible. All of what a GNU Arch client does, in regards to archive files, it is all done remotely, in access onto the filesystem. Client authentication, then, would be left to the host's operating system, and to the service managing the mechanism for the archive access. ------ That text, in the section immediately previous, I will have to take it as it being a first draft to an introductory tutorial about GNU Arch. I am glad to have found this opportunity for to have begun upon the work. I mean this as in a joke, the following, but with some humor, meant as to be kind in tone: If this would appear as it being a long email for you to read, then will you guess at how it has been, for my to have written this? (I have thought that it has been worth the effort. Of course, I can only expect if you would volunteer to read this.) I think that the previous sections have been to the end of what I have considered that I should state, as in this request for the initialization of the Tioga project at common-lisp.net Should you consder that this request will be met with approval: I would like to thank you, then, for this opportunity to make the Tioga project available, within it being provided in a comfortable, central location. Formally, Sean Champ gimmal(a)gmail.com

2 1

[admin] added tioga; owned by schamp
by root＠common-lisp.net 05 Aug '06

05 Aug '06

Add successful at 2006.08.05.20.42.

1 0

[admin] Request for new project
by Pascal Costanza 04 Aug '06

04 Aug '06

Hi Erik, This is a request for a new project with the name "CDR". CDR stands for "Common Lisp Document Repository". The Common Lisp Document Repository is a repository of documents that are of interest to the Common Lisp community. The most important property of a CDR document is that it will never change: if you refer to it, you can be sure that your reference will always refer to exactly the same document. There have been a number of attempts to establish a standardization process for Common Lisp after it has been officially published as an ANSI standard. The ANSI standardization was very costly and very time consuming (according to http://groups.google.com/group/comp.lang.lisp/ msg/15248a1b11c5a603 it took nearly 10 years and at least $400K). The goal of the Common Lisp Document Repository is to be more light- weight and more efficient. We focus on one aspect of standardization: the ability to refer to a specification document in an unambiguous way. The Common Lisp Document Repository intentionally does not define a process for coming up with specifications or any other means to guarantee some level of quality of the submitted documents. Instead, we aim for a community-driven, decentralized approach to come up, discuss and finalize specifications. In this sense, we only provide the services of librarians. We hope that the Common Lisp Document Repository has the potential to prove useful in establishing new de-facto standards, and to serve as a stepping stone for more formal standardizations in the long run. For more details, see the draft website at http://p-cos.net/lisp/cdr/ This project is carried out by Marc Battyani, Pascal Costanza, Arthur Lemmens and Edi Weitz. Since the project doesn't produce any code of its own, there is no license attached to it. However, we state requirements for document licenses as part of the CDR submission process - see point 2 at http://p-cos.net/lisp/cdr/manual.html I already have a home directory at common-lisp.net, but find my public key attached anyway. On behalf of the CDR editors, Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium

2 2

[admin] New mailing list: FM-Lisp
by Edi Weitz 04 Aug '06

04 Aug '06

Hi! I've developed a toolkit for developing FileMaker plug-ins with Common Lisp. The toolkit will be released at http://weitz.de/fm-tools/ in the next days. However, there's already a plug-in available which was written using this toolkit: http://jensteich.de/regex-plugin/ http://weitz.de/regex-plugin/ Both the toolkit as well as the plug-in are released under a BSD-style license. I'd like to apply for an "independent" mailing list on c-l.net that would be used to support the software mentioned above and for general discussion about writing FileMaker plug-ins with Common Lisp. The name of the list should be "fm-lisp". Would that be OK? Thanks in advance, Edi.

2 1

[admin] added cdr; owned by pcostanza
by root＠common-lisp.net 04 Aug '06

04 Aug '06

Add successful at 2006.08.04.09.21.

1 0

[admin] account for repository access
by Kevin Casey 03 Aug '06

03 Aug '06

Hello, Marco Antoniotti and I are going to be working on the common-math project. I would like an account so that I can access the repository. Thanks much! Kevin Casey

3 3

[admin] please add user thenriksen to list of McCLIM committers.
by Andreas Fuchs 02 Aug '06

02 Aug '06

Hi there, Athas would like to commit stuff to McCLIM, so he'll need commit privileges. Please make him a project member. Thanks, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 1

[admin] Account for Editting in Trac
by AJ Armstrong 28 Jul '06

28 Jul '06

Hi, Ties Stuij suggested that I get an account so that I can edit in the ucw-intro trac pages. Is this email sufficient, or is there a formal process I should be observing? -- -------------- AJ Armstrong (aja) aja(a)clanarmstrong.com

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

admin