From clinton at unknownlamer.org  Thu Jul  3 16:58:09 2008
From: clinton at unknownlamer.org (Clinton Ebadi)
Date: Thu, 03 Jul 2008 12:58:09 -0400
Subject: [mcclim-devel] Gadget based accepting-values
In-Reply-To: <877ie192ec.fsf@unknownlamer.org> (Clinton Ebadi's message of
	"Sat\, 10 May 2008 19\:15\:39 -0400")
References: <87skwtep6y.fsf@unknownlamer.org>
	<87y76jjgxx.fsf@lambda.athas.dyndns.dk>
	<87lk2i80uk.fsf@unknownlamer.org>
	<87lk2hkfyt.fsf@lambda.athas.dyndns.dk>
	<877ie192ec.fsf@unknownlamer.org>
Message-ID: <87lk0i7vmm.fsf@unknownlamer.org>


Greetings,

I ironed out a few bugs in my implementation some weeks ago and almost
have my gadget based dialog code working now, but my laptop decided to
mysteriously die (someone spilled a very sugary drink into my laptop
case and I put my laptop into the case...) so I've been unable to code
for a bit as my only other machine lacks a monitor at present. I
managed to fix my laptop yesterday (the Internet is a wonderful place
where one can find technician service manuals).

I intend to have the patch working with equivalent functionality to
the current accepting-values by the end of July. Right now I'm focused
on getting clisp and ffcall working on EABI ARM and packaged for
openembedded (mcclim on the neo freerunner!) and the intial work for
a startup I recently joined so it will be a week or two before I have
time to finish ironing out the last few issues.

My big question now is: is it ok if the gadget based accepting-values
is not user extensible? I fetched the CLIM mailing list archives and
it seems that the spec is indeed woefully underspecified in this area,
and so making accepting-values user extensible will require shaping up
the current implementation and exposing bits of the protocol as a
mcclim extension. I am willing to work on this later, but right now am
lacking the time to undertake such a large projet (the economy is
cruel and demands that I do things for it lest I starve). Perhaps in
September I'd be able to make things extensible, but I figure that a
nonextensible gadget based accepting-values is nicer than a
nonextensible text field based accepting-values.

-- 
         To set your mind free you must first just listen
     Don't waste your life on worthless hate and contradiction


From athas at sigkill.dk  Fri Jul  4 18:15:19 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 04 Jul 2008 20:15:19 +0200
Subject: [mcclim-devel] Gadget based accepting-values
In-Reply-To: <87lk0i7vmm.fsf@unknownlamer.org> (Clinton Ebadi's message of
	"Thu, 03 Jul 2008 12:58:09 -0400")
References: <87skwtep6y.fsf@unknownlamer.org>
	<87y76jjgxx.fsf@lambda.athas.dyndns.dk>
	<87lk2i80uk.fsf@unknownlamer.org>
	<87lk2hkfyt.fsf@lambda.athas.dyndns.dk>
	<877ie192ec.fsf@unknownlamer.org> <87lk0i7vmm.fsf@unknownlamer.org>
Message-ID: <878wwha53c.fsf@lambda.athas.dyndns.dk>

Clinton Ebadi <clinton at unknownlamer.org> writes:

> My big question now is: is it ok if the gadget based
> accepting-values is not user extensible?

Fine by me. My previous statements were based on the fallacious
assumption that the spec already specified most of what was needed,
and if that is not the case a non-extensible implementation is better
than none at all.
-- 
\  Troels
/\ Henriksen


From tcr at freebits.de  Tue Jul 15 21:45:27 2008
From: tcr at freebits.de (Tobias C. Rittweiler)
Date: Tue, 15 Jul 2008 23:45:27 +0200
Subject: [mcclim-devel] [PATCH] Drei: adding some PRINT-OBJECTs for
	lambda-list related objects.
Message-ID: <87zloiu8i0.fsf@freebits.de>


Hi all,

You'll find a small patch attached which adds some PRINT-OBJECTs for
more descriptive results at the REPL; for example objects representing
lambda-lists will be printed like

#<ORDINARY-LAMBDA-LIST (R1 R2 R3 &OPTIONAL O1 O2 &KEY K1 ...) {ACC8261}>

instead of

#<ORDINARY-LAMBDA-LIST {ACC8261}>

I'm thinking of splitting out, and extending the lambda-list stuff into
a standalone library. Now I wonder why all the lambda-list relevant
classes only define reader methods for their slots. Is there some
intentional purpose behind this functional design, or is it just this
way because of KISS and YAGNI?

  -T.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: drei-lambda-list-print-objects.diff
Type: text/x-diff
Size: 1790 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20080715/0839fd7a/attachment.diff>

From athas at sigkill.dk  Thu Jul 17 08:49:21 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jul 2008 10:49:21 +0200
Subject: [mcclim-devel] [PATCH] Drei: adding some PRINT-OBJECTs for
	lambda-list related objects.
In-Reply-To: <87zloiu8i0.fsf@freebits.de> (Tobias C. Rittweiler's message of
	"Tue, 15 Jul 2008 23:45:27 +0200")
References: <87zloiu8i0.fsf@freebits.de>
Message-ID: <87y740nbe6.fsf@lambda.athas.dyndns.dk>

"Tobias C. Rittweiler" <tcr at freebits.de> writes:

> Hi all,
>
> You'll find a small patch attached which adds some PRINT-OBJECTs for
> more descriptive results at the REPL; for example objects representing
> lambda-lists will be printed like

Thank you, committed.

> I'm thinking of splitting out, and extending the lambda-list stuff into
> a standalone library. Now I wonder why all the lambda-list relevant
> classes only define reader methods for their slots. Is there some
> intentional purpose behind this functional design, or is it just this
> way because of KISS and YAGNI?

I like immutable data structures for this kind of stuff. The lambda
list frobbing interface is loosely based on CL pathnames.

-- 
\  Troels
/\ Henriksen


From tcr at freebits.de  Thu Jul 17 09:00:00 2008
From: tcr at freebits.de (Tobias C. Rittweiler)
Date: Thu, 17 Jul 2008 11:00:00 +0200
Subject: [mcclim-devel] Re: [PATCH] Drei: adding some PRINT-OBJECTs for
	lambda-list related objects.
References: <87zloiu8i0.fsf@freebits.de>
	<87y740nbe6.fsf@lambda.athas.dyndns.dk>
Message-ID: <8763r4j373.fsf@freebits.de>

Troels Henriksen <athas at sigkill.dk> writes:

> "Tobias C. Rittweiler" <tcr at freebits.de> writes:
>
> > I'm thinking of splitting out, and extending the lambda-list stuff into
> > a standalone library. Now I wonder why all the lambda-list relevant
> > classes only define reader methods for their slots. Is there some
> > intentional purpose behind this functional design, or is it just this
> > way because of KISS and YAGNI?
>
> I like immutable data structures for this kind of stuff. The lambda
> list frobbing interface is loosely based on CL pathnames.

How can you currently rename a parameter in a lambda-list?

  -T.



From athas at sigkill.dk  Thu Jul 17 10:25:52 2008
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 17 Jul 2008 12:25:52 +0200
Subject: [mcclim-devel] Re: [PATCH] Drei: adding some PRINT-OBJECTs for
	lambda-list related objects.
In-Reply-To: <8763r4j373.fsf@freebits.de> (Tobias C. Rittweiler's message of
	"Thu, 17 Jul 2008 11:00:00 +0200")
References: <87zloiu8i0.fsf@freebits.de>
	<87y740nbe6.fsf@lambda.athas.dyndns.dk> <8763r4j373.fsf@freebits.de>
Message-ID: <87sku8n6xb.fsf@lambda.athas.dyndns.dk>

"Tobias C. Rittweiler" <tcr at freebits.de> writes:

> How can you currently rename a parameter in a lambda-list?

You probably can't, because I haven't had the need to do that yet.

-- 
\  Troels
/\ Henriksen