From csr21 at cantab.net  Sat Nov 10 15:27:02 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Sat, 10 Nov 2007 15:27:02 +0000
Subject: [mcclim-devel] More power to Drei
Message-ID: <87zlxmxgs9.fsf@cantab.net>

Hi,

(I can't remember if this has been suggested or shot down before; I
might have a need for something like this soon, so I'd appreciate
guidance on it.)

How hard would it be, do people think, to provide from Drei something
like a regexp-token-syntax class, such that it becomes straightforward
for people to define simple tokenizing syntaxes?

An example might help; I'd like to be able to do

  (define-token-syntax chord-ontology ()
    ("(([A-G])(s|ss|b|bb)?):\(([0-9](,[0-9])*)\)"
     ((root pitch accidental) pitches))
    (t error-token))

and have that be essentially all that's necessary to be able to use
the syntax in interesting ways, such as:

* being able to do (accept 'chord-ontology-token) and have the user
  input coloured in red unless it's valid, and be given the parse tree
  on return;

* being able to use Chord Ontology syntax in a buffer, where there is
  no parse per se, but the buffer is lexed according to the token
  syntax.

Is this sensible, worthwhile, possible, easy?  I would have thought
that we would have essentially all the components already, and it was
a matter of gluing them together, but maybe I'm forgetting a snag?

Cheers,

Christophe

[ In my example, the nesting in the symbolic names is intended to
  correspond to register groups; in that example, "As:(1,3)" is
  intended to generate the equivalent of

    (make-instance 'chord-ontology-token
      'root (make-instance 'root 'pitch "A" 'accidental "s")
      'pitches "1,3")

  I hope that my intent is reasonably clear. ]


From athas at sigkill.dk  Sun Nov 11 08:39:44 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 11 Nov 2007 09:39:44 +0100
Subject: [mcclim-devel] More power to Drei
In-Reply-To: <87zlxmxgs9.fsf@cantab.net> (Christophe Rhodes's message of "Sat, 
	10 Nov 2007 15:27:02 +0000")
References: <87zlxmxgs9.fsf@cantab.net>
Message-ID: <87ir49qipb.fsf@lambda.athas.dyndns.dk>

Christophe Rhodes <csr21 at cantab.net> writes:

> * being able to do (accept 'chord-ontology-token) and have the user
>   input coloured in red unless it's valid, and be given the parse tree
>   on return;

This sounds very useful for all the various kinds of special-purpose
textual input formats applications are likely to use.

> * being able to use Chord Ontology syntax in a buffer, where there is
>   no parse per se, but the buffer is lexed according to the token
>   syntax.

I don't understand this. How would you have a buffer syntax with "no
parse per se"?

> Is this sensible, worthwhile, possible, easy?  I would have thought
> that we would have essentially all the components already, and it was
> a matter of gluing them together, but maybe I'm forgetting a snag?

I would think this is possible, we already have a state machine,
cl-automaton, I think it can be adapted for this purpose.

-- 
\  Troels
/\ Henriksen


From csr21 at cantab.net  Sun Nov 11 08:58:18 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Sun, 11 Nov 2007 08:58:18 +0000
Subject: [mcclim-devel] More power to Drei
In-Reply-To: <87ir49qipb.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's
	message of "Sun, 11 Nov 2007 09:39:44 +0100")
References: <87zlxmxgs9.fsf@cantab.net> <87ir49qipb.fsf@lambda.athas.dyndns.dk>
Message-ID: <87sl3dxiol.fsf@cantab.net>

Troels Henriksen <athas at sigkill.dk> writes:

> Christophe Rhodes <csr21 at cantab.net> writes:
>
>> * being able to use Chord Ontology syntax in a buffer, where there is
>>   no parse per se, but the buffer is lexed according to the token
>>   syntax.
>
> I don't understand this. How would you have a buffer syntax with "no
> parse per se"?

Sorry, I meant that there would be no parse for the buffer beyond a
sequence of tokens.

>> Is this sensible, worthwhile, possible, easy?  I would have thought
>> that we would have essentially all the components already, and it was
>> a matter of gluing them together, but maybe I'm forgetting a snag?
>
> I would think this is possible, we already have a state machine,
> cl-automaton, I think it can be adapted for this purpose.

OK, good.

(Annoyingly, I realised after I posted that some of the mini languages
that I have a need to support include elements that are not regular:
the common case is properly-nesting balanced comments.  I don't know
the capabilities of cl-automaton; can it represent such things?)

Cheers,

Christophe


From athas at sigkill.dk  Sun Nov 11 09:56:44 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Sun, 11 Nov 2007 10:56:44 +0100
Subject: [mcclim-devel] More power to Drei
In-Reply-To: <87sl3dxiol.fsf@cantab.net> (Christophe Rhodes's message of "Sun, 
	11 Nov 2007 08:58:18 +0000")
References: <87zlxmxgs9.fsf@cantab.net>
	<87ir49qipb.fsf@lambda.athas.dyndns.dk> <87sl3dxiol.fsf@cantab.net>
Message-ID: <87ejexqf4z.fsf@lambda.athas.dyndns.dk>

Christophe Rhodes <csr21 at cantab.net> writes:

> Sorry, I meant that there would be no parse for the buffer beyond a
> sequence of tokens.

Oh yeah, this should be trivial. A parse tree of some sort is always
necessary for redisplay and other things, hence my question.

> (Annoyingly, I realised after I posted that some of the mini languages
> that I have a need to support include elements that are not regular:
> the common case is properly-nesting balanced comments.  I don't know
> the capabilities of cl-automaton; can it represent such things?)

I'm pretty sure cl-automaton as it stands only implements regular
expressions. I do not know whether it can reasonably be extended or
not, but for simplish things like balancing, I'd wager it can.

-- 
\  Troels
/\ Henriksen


From petdog at gmail.com  Tue Nov 27 10:49:40 2007
From: petdog at gmail.com (petdog)
Date: Tue, 27 Nov 2007 10:49:40 +0000 (UTC)
Subject: [mcclim-devel] can't load latest mcclim (with latest sbcl)
Message-ID: <figso4$u57$1@ger.gmane.org>

I think line 66 of mcclim/Lisp-Dep/mp-sbcl.lisp should be changed from
(sb-thread:get-mutex *permanent-queue* :locked nil))
to (sb-thread:get-mutex *permanent-queue* nil)).
Or, at least, that's how I got it to load.

Thanks to all for the great work.



From eric.marsden at free.fr  Tue Nov 27 22:56:23 2007
From: eric.marsden at free.fr (Eric Marsden)
Date: Tue, 27 Nov 2007 23:56:23 +0100
Subject: [mcclim-devel] Re: can't load latest mcclim (with latest sbcl)
References: <figso4$u57$1@ger.gmane.org>
Message-ID: <873aurguw8.fsf@free.fr>

>>>>> "pd" == petdog  <petdog at gmail.com> writes:

  pd> I think line 66 of mcclim/Lisp-Dep/mp-sbcl.lisp should be changed from
  pd> (sb-thread:get-mutex *permanent-queue* :locked nil))
  pd> to (sb-thread:get-mutex *permanent-queue* nil)).
  pd> Or, at least, that's how I got it to load.

  I second this; this bug seem old, but appears now because recent
  versions of SBCL have stronger type checking in (SETF MUTEX-%OWNER),
  sez Krystof.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcclim.diff
Type: text/x-diff
Size: 708 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20071127/d2048b67/attachment.diff>
-------------- next part --------------
  
-- 
Eric Marsden

From athas at sigkill.dk  Thu Nov 29 07:42:22 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 29 Nov 2007 08:42:22 +0100
Subject: [mcclim-devel] Re: can't load latest mcclim (with latest sbcl)
In-Reply-To: <873aurguw8.fsf@free.fr> (Eric Marsden's message of "Tue, 27 Nov
	2007 23:56:23 +0100")
References: <figso4$u57$1@ger.gmane.org> <873aurguw8.fsf@free.fr>
Message-ID: <87tzn5ts4h.fsf@lambda.athas.dyndns.dk>

Eric Marsden <eric.marsden at free.fr> writes:

>   I second this; this bug seem old, but appears now because recent
>   versions of SBCL have stronger type checking in (SETF MUTEX-%OWNER),
>   sez Krystof.

Right, I committed your patch, that should fix it. As an aside,
fix-abcl.lisp?


-- 
\  Troels
/\ Henriksen