clops-users — mailing lists for the users of CLOPS

Re: [Clops-users] Release

[Viliam H. <vil...@uc...>]

Hi,

I'm sorry I can't be there, the whole Mon and Tue I have to be in the FAME
meeting in Maynooth.

(All my assignments are done. :) )

Regards,
Viliam

On 21. Apr (Tuesday) v 09:23:44 +0100 2009, Julien Charles wrote:
> Hey guys,
> Let's do it this afternoon - after the sensetile meeting let's gather up
> talk about what's missing and release!
> 
> Julien

> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p

> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users


-- 
Viliam

[Clops-users] Release

[Julien C. <jul...@gm...>]

Hey guys,
Let's do it this afternoon - after the sensetile meeting let's gather up
talk about what's missing and release!

Julien

Re: [Clops-users] Revision number in the version numbering part

[Julien C. <jul...@gm...>]

On Thu, Apr 16, 2009 at 11:58 AM, Julien Charles
<jul...@gm...>wrote:

> What I was stating is that when you do a commit the .svn/entries file is
> not updated with the revision number that you commited; at least in eclipse.
>

I forget to precise the one for the root directory, while it is updated on
the remote server.

>
>
> On Thu, Apr 16, 2009 at 11:55 AM, Viliam Holub <vil...@uc...>wrote:
>
>>
>> I mean... when there is a bug, you probably want to have the revision
>> number
>> of your local copy, not the up-to-date one... ;)
>>
>> V.
>>
>> On 16. Apr (Thursday) v 11:46:58 +0100 2009, Julien Charles wrote:
>> > svn info
>> > gives a revision number which is not up to date if you haven't done
>> > previously an update (at least in eclipse).
>> >
>> > On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...>
>> wrote:
>> >
>> > >
>> > > Hi all,
>> > >
>> > > so I'll be probably the first one who will omit this ;)
>> > >
>> > > Isn't there an easier way? I.e. what if the revision number would be
>> > > automatically the svn revision number? I'm not an expert in svn hooks
>> > > though.
>> > >
>> > > Viliam
>> > >
>> > > On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
>> > > > Hi all,
>> > > > I have added the revision numbering to the version number because it
>> is
>> > > > quite useful when you are testing the program.
>> > > > Actually there is some kind of bug (maybe a feature...?) that arises
>> when
>> > > > doing that is that a commit doesn't change your local version
>> > > > of the repository, while changes the remote version, at least this
>> > > happens
>> > > > with subclipse.
>> > > > So be sure to _update_ after any commit otherwise you will get bad
>> > > version
>> > > > number.
>> > > >
>> > > > Julien
>> > >
>> > > >
>> > >
>> ------------------------------------------------------------------------------
>> > > > Stay on top of everything new and different, both inside and
>> > > > around Java (TM) technology - register by April 22, and save
>> > > > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> > > > 300 plus technical and hands-on sessions. Register today.
>> > > > Use priority code J9JMT32. http://p.sf.net/sfu/p
>> > >
>> > > > _______________________________________________
>> > > > Clops-users mailing list
>> > > > Clo...@li...
>> > > > https://lists.sourceforge.net/lists/listinfo/clops-users
>> > >
>> > >
>> > > --
>> > > Viliam
>> > >
>>
>> --
>> Viliam
>>
>
>

Re: [Clops-users] Revision number in the version numbering part

[Julien C. <jul...@gm...>]

I mean what you are saying is right... but has nothing to do with my point.

On Thu, Apr 16, 2009 at 11:58 AM, Julien Charles
<jul...@gm...>wrote:

> What I was stating is that when you do a commit the .svn/entries file is
> not updated with the revision number that you commited; at least in eclipse.
>
>
> On Thu, Apr 16, 2009 at 11:55 AM, Viliam Holub <vil...@uc...>wrote:
>
>>
>> I mean... when there is a bug, you probably want to have the revision
>> number
>> of your local copy, not the up-to-date one... ;)
>>
>> V.
>>
>> On 16. Apr (Thursday) v 11:46:58 +0100 2009, Julien Charles wrote:
>> > svn info
>> > gives a revision number which is not up to date if you haven't done
>> > previously an update (at least in eclipse).
>> >
>> > On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...>
>> wrote:
>> >
>> > >
>> > > Hi all,
>> > >
>> > > so I'll be probably the first one who will omit this ;)
>> > >
>> > > Isn't there an easier way? I.e. what if the revision number would be
>> > > automatically the svn revision number? I'm not an expert in svn hooks
>> > > though.
>> > >
>> > > Viliam
>> > >
>> > > On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
>> > > > Hi all,
>> > > > I have added the revision numbering to the version number because it
>> is
>> > > > quite useful when you are testing the program.
>> > > > Actually there is some kind of bug (maybe a feature...?) that arises
>> when
>> > > > doing that is that a commit doesn't change your local version
>> > > > of the repository, while changes the remote version, at least this
>> > > happens
>> > > > with subclipse.
>> > > > So be sure to _update_ after any commit otherwise you will get bad
>> > > version
>> > > > number.
>> > > >
>> > > > Julien
>> > >
>> > > >
>> > >
>> ------------------------------------------------------------------------------
>> > > > Stay on top of everything new and different, both inside and
>> > > > around Java (TM) technology - register by April 22, and save
>> > > > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> > > > 300 plus technical and hands-on sessions. Register today.
>> > > > Use priority code J9JMT32. http://p.sf.net/sfu/p
>> > >
>> > > > _______________________________________________
>> > > > Clops-users mailing list
>> > > > Clo...@li...
>> > > > https://lists.sourceforge.net/lists/listinfo/clops-users
>> > >
>> > >
>> > > --
>> > > Viliam
>> > >
>>
>> --
>> Viliam
>>
>
>

Re: [Clops-users] Revision number in the version numbering part

[Julien C. <jul...@gm...>]

What I was stating is that when you do a commit the .svn/entries file is not
updated with the revision number that you commited; at least in eclipse.

On Thu, Apr 16, 2009 at 11:55 AM, Viliam Holub <vil...@uc...> wrote:

>
> I mean... when there is a bug, you probably want to have the revision
> number
> of your local copy, not the up-to-date one... ;)
>
> V.
>
> On 16. Apr (Thursday) v 11:46:58 +0100 2009, Julien Charles wrote:
> > svn info
> > gives a revision number which is not up to date if you haven't done
> > previously an update (at least in eclipse).
> >
> > On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...>
> wrote:
> >
> > >
> > > Hi all,
> > >
> > > so I'll be probably the first one who will omit this ;)
> > >
> > > Isn't there an easier way? I.e. what if the revision number would be
> > > automatically the svn revision number? I'm not an expert in svn hooks
> > > though.
> > >
> > > Viliam
> > >
> > > On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
> > > > Hi all,
> > > > I have added the revision numbering to the version number because it
> is
> > > > quite useful when you are testing the program.
> > > > Actually there is some kind of bug (maybe a feature...?) that arises
> when
> > > > doing that is that a commit doesn't change your local version
> > > > of the repository, while changes the remote version, at least this
> > > happens
> > > > with subclipse.
> > > > So be sure to _update_ after any commit otherwise you will get bad
> > > version
> > > > number.
> > > >
> > > > Julien
> > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > Stay on top of everything new and different, both inside and
> > > > around Java (TM) technology - register by April 22, and save
> > > > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> > > > 300 plus technical and hands-on sessions. Register today.
> > > > Use priority code J9JMT32. http://p.sf.net/sfu/p
> > >
> > > > _______________________________________________
> > > > Clops-users mailing list
> > > > Clo...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/clops-users
> > >
> > >
> > > --
> > > Viliam
> > >
>
> --
> Viliam
>

Re: [Clops-users] Revision number in the version numbering part

[Viliam H. <vil...@uc...>]

I mean... when there is a bug, you probably want to have the revision number
of your local copy, not the up-to-date one... ;)

V.

On 16. Apr (Thursday) v 11:46:58 +0100 2009, Julien Charles wrote:
> svn info
> gives a revision number which is not up to date if you haven't done
> previously an update (at least in eclipse).
> 
> On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...> wrote:
> 
> >
> > Hi all,
> >
> > so I'll be probably the first one who will omit this ;)
> >
> > Isn't there an easier way? I.e. what if the revision number would be
> > automatically the svn revision number? I'm not an expert in svn hooks
> > though.
> >
> > Viliam
> >
> > On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
> > > Hi all,
> > > I have added the revision numbering to the version number because it is
> > > quite useful when you are testing the program.
> > > Actually there is some kind of bug (maybe a feature...?) that arises when
> > > doing that is that a commit doesn't change your local version
> > > of the repository, while changes the remote version, at least this
> > happens
> > > with subclipse.
> > > So be sure to _update_ after any commit otherwise you will get bad
> > version
> > > number.
> > >
> > > Julien
> >
> > >
> > ------------------------------------------------------------------------------
> > > Stay on top of everything new and different, both inside and
> > > around Java (TM) technology - register by April 22, and save
> > > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> > > 300 plus technical and hands-on sessions. Register today.
> > > Use priority code J9JMT32. http://p.sf.net/sfu/p
> >
> > > _______________________________________________
> > > Clops-users mailing list
> > > Clo...@li...
> > > https://lists.sourceforge.net/lists/listinfo/clops-users
> >
> >
> > --
> > Viliam
> >

-- 
Viliam

Re: [Clops-users] Revision number in the version numbering part

[Viliam H. <vil...@uc...>]

I mean using something like $Revision$. I found interesting discussion on
this: http://www.perlmonks.org/?node_id=668477

Might be of interest...

V.


On 16. Apr (Thursday) v 11:46:58 +0100 2009, Julien Charles wrote:
> svn info
> gives a revision number which is not up to date if you haven't done
> previously an update (at least in eclipse).
> 
> On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...> wrote:
> 
> >
> > Hi all,
> >
> > so I'll be probably the first one who will omit this ;)
> >
> > Isn't there an easier way? I.e. what if the revision number would be
> > automatically the svn revision number? I'm not an expert in svn hooks
> > though.
> >
> > Viliam
> >
> > On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
> > > Hi all,
> > > I have added the revision numbering to the version number because it is
> > > quite useful when you are testing the program.
> > > Actually there is some kind of bug (maybe a feature...?) that arises when
> > > doing that is that a commit doesn't change your local version
> > > of the repository, while changes the remote version, at least this
> > happens
> > > with subclipse.
> > > So be sure to _update_ after any commit otherwise you will get bad
> > version
> > > number.
> > >
> > > Julien
> >
> > >
> > ------------------------------------------------------------------------------
> > > Stay on top of everything new and different, both inside and
> > > around Java (TM) technology - register by April 22, and save
> > > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> > > 300 plus technical and hands-on sessions. Register today.
> > > Use priority code J9JMT32. http://p.sf.net/sfu/p
> >
> > > _______________________________________________
> > > Clops-users mailing list
> > > Clo...@li...
> > > https://lists.sourceforge.net/lists/listinfo/clops-users
> >
> >
> > --
> > Viliam
> >

-- 
Viliam

Re: [Clops-users] Revision number in the version numbering part

[Julien C. <jul...@gm...>]

svn info
gives a revision number which is not up to date if you haven't done
previously an update (at least in eclipse).

On Thu, Apr 16, 2009 at 11:45 AM, Viliam Holub <vil...@uc...> wrote:

>
> Hi all,
>
> so I'll be probably the first one who will omit this ;)
>
> Isn't there an easier way? I.e. what if the revision number would be
> automatically the svn revision number? I'm not an expert in svn hooks
> though.
>
> Viliam
>
> On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
> > Hi all,
> > I have added the revision numbering to the version number because it is
> > quite useful when you are testing the program.
> > Actually there is some kind of bug (maybe a feature...?) that arises when
> > doing that is that a commit doesn't change your local version
> > of the repository, while changes the remote version, at least this
> happens
> > with subclipse.
> > So be sure to _update_ after any commit otherwise you will get bad
> version
> > number.
> >
> > Julien
>
> >
> ------------------------------------------------------------------------------
> > Stay on top of everything new and different, both inside and
> > around Java (TM) technology - register by April 22, and save
> > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> > 300 plus technical and hands-on sessions. Register today.
> > Use priority code J9JMT32. http://p.sf.net/sfu/p
>
> > _______________________________________________
> > Clops-users mailing list
> > Clo...@li...
> > https://lists.sourceforge.net/lists/listinfo/clops-users
>
>
> --
> Viliam
>

Re: [Clops-users] Revision number in the version numbering part

[Viliam H. <vil...@uc...>]

Hi all,

so I'll be probably the first one who will omit this ;)

Isn't there an easier way? I.e. what if the revision number would be
automatically the svn revision number? I'm not an expert in svn hooks though.

Viliam

On 16. Apr (Thursday) v 11:23:15 +0100 2009, Julien Charles wrote:
> Hi all,
> I have added the revision numbering to the version number because it is
> quite useful when you are testing the program.
> Actually there is some kind of bug (maybe a feature...?) that arises when
> doing that is that a commit doesn't change your local version
> of the repository, while changes the remote version, at least this happens
> with subclipse.
> So be sure to _update_ after any commit otherwise you will get bad version
> number.
> 
> Julien

> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p

> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users


-- 
Viliam

[Clops-users] Revision number in the version numbering part

[Julien C. <jul...@gm...>]

Hi all,
I have added the revision numbering to the version number because it is
quite useful when you are testing the program.
Actually there is some kind of bug (maybe a feature...?) that arises when
doing that is that a commit doesn't change your local version
of the repository, while changes the remote version, at least this happens
with subclipse.
So be sure to _update_ after any commit otherwise you will get bad version
number.

Julien

Re: [Clops-users] infinite lookahead

[Fintan F. <fi...@gm...>]

It seems it isn't.

Who added the option?

I guess that means it's easier to remove it as a command line option then
anyway!

On Tue, Apr 14, 2009 at 8:01 PM, Mikoláš Janota <mik...@gm...>wrote:

> Hi, I probably missed something but I can't find where
> InfiniteLookahead: {"-oo", "--infinite-lookahead"}:[default="false"]
> is handled in code.
>
> --
> Mikoláš
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>

[Clops-users] infinite lookahead

[Mikoláš J. <mik...@gm...>]

Hi, I probably missed something but I can't find where
InfiniteLookahead: {"-oo", "--infinite-lookahead"}:[default="false"]
is handled in code.

-- 
Mikoláš

[Clops-users] Add what you have done to the CHANGELOG file

[Julien C. <jul...@gm...>]

Hi,
I just want to make sure everybody write their stuff to the changelog.

Cheers,
Julien

Re: [Clops-users] AllOptions and other ways of defining option groups

[Fintan F. <fi...@gm...>]

We're not diverging, AllOptions is still a named regexp. It's just defined
by default. It just saves you having to write it out manually.

I agree it's not entirely like regexp syntax, but it wasn't intended to be.
I really don't want to write [^SomeOptionOrGroup] in the format string. It's
horrible.

Also, treating option groups as sets is powerful for generating a group with
exactly the options we want inside it in a short succinct manner.

On Tue, Apr 14, 2009 at 3:33 PM, Julien Charles <jul...@gm...>wrote:

> I wholeheartedly agree with you on this point. I've added a feature request
> going in that direction for v0.3.
> Cheers,
> Julien
>
>
> On Tue, Apr 14, 2009 at 3:29 PM, Mikoláš Janota <mik...@gm...>wrote:
>
>> I don't like the special keyword AllOptions and that we are diverging
>> from the idea that option groups are named rexpses.
>>
>> In regexp notation instead of
>> > OptionalOptions:   AllOptions -CompulsoryOptions;
>> I'd write [^CompulsoryOptions], and AllOptions correspond to ".".
>>
>> m.
>>
>>
>> On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>
>> wrote:
>> > I modified the option store generation template so we now have an
>> > OptionGroup named "AllOptions". This was easy to do, but when I went to
>> see
>> > in which .clo files I could use it I realised that it wasn't sufficient.
>> For
>> > most interfaces there is often the need to have a group that includes
>> most,
>> > but not all, of the options.
>> >
>> > I'd like to propose that we create a way of easily defining such groups.
>> My
>> > initial design would be allow subtracting options (or option groups)
>> from
>> > the set, something like:
>> >
>> > OptionalOptions:   AllOptions -CompulsoryOptions;
>> >
>> > Or for svn,
>> >
>> > Options:   AllOptions -Commands;
>> >
>> > Where option or option group names prefixed with a '-' means that they
>> > should be removed from the set.
>> >
>> > This obviously creates some complication in terms of how we expand an
>> option
>> > group to determine exactly what options are in it, but I think the
>> effort
>> > would be worth it. I think allowing definitions like the above will help
>> to
>> > keep the groupings succinct.
>> >
>> > Comments/suggestions?
>> >
>> > -F
>> >
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by:
>> > High Quality Requirements in a Collaborative Environment.
>> > Download a free trial of Rational Requirements Composer Now!
>> > http://p.sf.net/sfu/www-ibm-com
>> > _______________________________________________
>> > Clops-users mailing list
>> > Clo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/clops-users
>> >
>> >
>>
>>
>>
>> --
>> Mikoláš Janota M. Sc.
>> School of Computer Science and Informatics,
>> University College Dublin,
>> Belfield,
>> Dublin 4,
>> Ireland
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> _______________________________________________
>> Clops-users mailing list
>> Clo...@li...
>> https://lists.sourceforge.net/lists/listinfo/clops-users
>>
>
>

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

I wholeheartedly agree with you on this point. I've added a feature request
going in that direction for v0.3.
Cheers,
Julien

On Tue, Apr 14, 2009 at 3:29 PM, Mikoláš Janota <mik...@gm...>wrote:

> I don't like the special keyword AllOptions and that we are diverging
> from the idea that option groups are named rexpses.
>
> In regexp notation instead of
> > OptionalOptions:   AllOptions -CompulsoryOptions;
> I'd write [^CompulsoryOptions], and AllOptions correspond to ".".
>
> m.
>
>
> On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>
> wrote:
> > I modified the option store generation template so we now have an
> > OptionGroup named "AllOptions". This was easy to do, but when I went to
> see
> > in which .clo files I could use it I realised that it wasn't sufficient.
> For
> > most interfaces there is often the need to have a group that includes
> most,
> > but not all, of the options.
> >
> > I'd like to propose that we create a way of easily defining such groups.
> My
> > initial design would be allow subtracting options (or option groups) from
> > the set, something like:
> >
> > OptionalOptions:   AllOptions -CompulsoryOptions;
> >
> > Or for svn,
> >
> > Options:   AllOptions -Commands;
> >
> > Where option or option group names prefixed with a '-' means that they
> > should be removed from the set.
> >
> > This obviously creates some complication in terms of how we expand an
> option
> > group to determine exactly what options are in it, but I think the effort
> > would be worth it. I think allowing definitions like the above will help
> to
> > keep the groupings succinct.
> >
> > Comments/suggestions?
> >
> > -F
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > High Quality Requirements in a Collaborative Environment.
> > Download a free trial of Rational Requirements Composer Now!
> > http://p.sf.net/sfu/www-ibm-com
> > _______________________________________________
> > Clops-users mailing list
> > Clo...@li...
> > https://lists.sourceforge.net/lists/listinfo/clops-users
> >
> >
>
>
>
> --
> Mikoláš Janota M. Sc.
> School of Computer Science and Informatics,
> University College Dublin,
> Belfield,
> Dublin 4,
> Ireland
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>

[Clops-users] Features

[Julien C. <jul...@gm...>]

Hi all,
Everybody has 2 opened task, which have to be done for version 0.2.
Cheers,
Julien

Re: [Clops-users] AllOptions and other ways of defining option groups

[Mikoláš J. <mik...@gm...>]

I don't like the special keyword AllOptions and that we are diverging
from the idea that option groups are named rexpses.

In regexp notation instead of
> OptionalOptions:   AllOptions -CompulsoryOptions;
I'd write [^CompulsoryOptions], and AllOptions correspond to ".".

m.


On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...> wrote:
> I modified the option store generation template so we now have an
> OptionGroup named "AllOptions". This was easy to do, but when I went to see
> in which .clo files I could use it I realised that it wasn't sufficient. For
> most interfaces there is often the need to have a group that includes most,
> but not all, of the options.
>
> I'd like to propose that we create a way of easily defining such groups. My
> initial design would be allow subtracting options (or option groups) from
> the set, something like:
>
> OptionalOptions:   AllOptions -CompulsoryOptions;
>
> Or for svn,
>
> Options:   AllOptions -Commands;
>
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.
>
> This obviously creates some complication in terms of how we expand an option
> group to determine exactly what options are in it, but I think the effort
> would be worth it. I think allowing definitions like the above will help to
> keep the groupings succinct.
>
> Comments/suggestions?
>
> -F
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>



-- 
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland

Re: [Clops-users] AllOptions and other ways of defining option groups

[Radu G. <rad...@gm...>]

On Thu, Apr 9, 2009 at 2:34 AM, Viliam Holub <vil...@uc...> wrote:
> Sounds good for me. One question - do we want to distinguish between
> arithmetic and set operators? In set we usually type \ or something
> similar...

I prefer minus, as in Python. (I used to prefer it even before Python.)

Re: [Clops-users] AllOptions and other ways of defining option groups

[Viliam H. <vil...@uc...>]

On 08. Apr (Wednesday) v 11:27:47 +0100 2009, Fintan Fairmichael wrote:
> OptionalOptions:   AllOptions -CompulsoryOptions;
> 
> Or for svn,
> 
> Options:   AllOptions -Commands;
> 
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.

Sounds good for me. One question - do we want to distinguish between
arithmetic and set operators? In set we usually type \ or something
similar...

V.

[Clops-users] Schedule a version 0.2

[Julien C. <jul...@gm...>]

Hey,
I'd like to have a version 0.2 of CLOPS.
Let's schedule a release date!
Let say for instance monday.
What do you think?

Julien

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

oops not in the mailing list. fixing it

On Wed, Apr 8, 2009 at 2:02 PM, Julien Charles <jul...@gm...>wrote:

> Ok so I will be more precise.
> The main problem is name collision, coupled with template translation, and
> custom user template things.
> Here what we do is to reserve a word for group naming. If we choose
> AllOptions, it will be typically translated by a section called 'AllOptions
> options' which I don't want. It will change most likely to a section with a
> name like 'All options'. Then in the average case the user will have an
> option which will be named All, and it will eventually collide with my
> translation and the user will be unhappy because we didn't tell him that All
> was already a reserved word somehow because the template use this
> convention. So I agree to do a special case, but tell me which user friendly
> header I could put up in the html.
>
> On Wed, Apr 8, 2009 at 1:53 PM, Fintan Fairmichael <fi...@gm...>wrote:
>
>>
>> Could it be a more documentation friendly name instead? Like just 'All', I
>>> mean I don't want to have to make a special case in the doc generation to
>>> make up a more user friendly name.
>>>
>>
>> While I do no agree that AllOptions is somehow not user-friendly it can be
>> easily changed. Just edit the template.
>>
>
>

Re: [Clops-users] AllOptions and other ways of defining option groups

[Julien C. <jul...@gm...>]

On Wed, Apr 8, 2009 at 11:27 AM, Fintan Fairmichael <fi...@gm...>wrote:

> I modified the option store generation template so we now have an
> OptionGroup named "AllOptions". This was easy to do, but when I went to see
> in which .clo files I could use it I realised that it wasn't sufficient. For
> most interfaces there is often the need to have a group that includes most,
> but not all, of the options.
>
> I'd like to propose that we create a way of easily defining such groups. My
> initial design would be allow subtracting options (or option groups) from
> the set, something like:
>
> OptionalOptions:   AllOptions -CompulsoryOptions;

Could it be a more documentation friendly name instead? Like just 'All', I
mean I don't want to have to make a special case in the doc generation to
make up a more user friendly name.


>
>
> Or for svn,
>
> Options:   AllOptions -Commands;
>
> Where option or option group names prefixed with a '-' means that they
> should be removed from the set.
>
> This obviously creates some complication in terms of how we expand an
> option group to determine exactly what options are in it, but I think the
> effort would be worth it. I think allowing definitions like the above will
> help to keep the groupings succinct.
>
> Comments/suggestions?
>
> -F
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>

[Clops-users] AllOptions and other ways of defining option groups

[Fintan F. <fi...@gm...>]

I modified the option store generation template so we now have an
OptionGroup named "AllOptions". This was easy to do, but when I went to see
in which .clo files I could use it I realised that it wasn't sufficient. For
most interfaces there is often the need to have a group that includes most,
but not all, of the options.

I'd like to propose that we create a way of easily defining such groups. My
initial design would be allow subtracting options (or option groups) from
the set, something like:

OptionalOptions:   AllOptions -CompulsoryOptions;

Or for svn,

Options:   AllOptions -Commands;

Where option or option group names prefixed with a '-' means that they
should be removed from the set.

This obviously creates some complication in terms of how we expand an option
group to determine exactly what options are in it, but I think the effort
would be worth it. I think allowing definitions like the above will help to
keep the groupings succinct.

Comments/suggestions?

-F

[Clops-users] A DSL for creating unit tests

[Fintan F. <fi...@gm...>]

I created a small dsl for creating unit tests for clops.

The idea being that we can write sample inputs for a given clops spec file,
indicating whether they should be deemed valid or not. These are turned into
unit tests against the generated parser.

I have created an ant target unit-tests that currently does the following:
-Reads the dsl file (test/tests)
-Generates the code for all the mentioned clops spec files
-Generates a unit test for every provided valid/invalid input
-Runs the unit tests

Here's an example of the format of the dsl:

file: dsl/svn.clo
name: SVN
valid: { update }
invalid: { sadfadsd }
valid: { diff -r 3456 }
...
file: dsl/gzip.clo
name: Gzip
...

Each valid/invalid line results in a unit test. You can see the few actual
tests I've written so far in "test/tests" in the repository.

One special feature of the input string is the ability to provide
existing/non-existing files or directories. For this the tokens
${existing-file}, ${existing-dir} and ${non-existant-file} will be
substituted with appropriate paths to ensure file existence checks etc run
correctly.

The process can be streamlined and improved to facilitate the testing of
individual clops specifications more efficiently. I could see this method of
unit testing as being very useful when trying to specify tools with existing
complex command line interfaces.

Feedback and suggestions welcome. I'd encourage those who are responsible
for any of our existing .clo(ps) files to start to write some tests in the
file "test/tests", as this will be useful for regression testing and testing
future changes like the infinite lookahead parser that Radu has been working
on.

-F

Re: [Clops-users] the svn has been updated.

[Mikoláš J. <mik...@gm...>]

Thanks Julien

  BTW the repo is on https://clops.svn.sourceforge.net/svnroot/clops/

m.

On Mon, Apr 6, 2009 at 2:07 PM, Julien Charles <jul...@gm...> wrote:
> Hi all,
> the development tree of CLOPS has been moved to sourceforge.
> I suggest you to check out the directory now.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Clops-users mailing list
> Clo...@li...
> https://lists.sourceforge.net/lists/listinfo/clops-users
>
>



-- 
Mikoláš Janota M. Sc.
School of Computer Science and Informatics,
University College Dublin,
Belfield,
Dublin 4,
Ireland