Re: [Audacity-devel] Batch Processing

[<Mar...@ao...>]

Hi Salvo
 
So how do we "disallow users to modify the string
in the batch  dialog"?
 
Martyn
 
In a message dated 03/05/2007 04:31:17 GMT Daylight Time,  
ven...@ya... writes:
Hi,
I believe that the advantage of  having the batch files
stored in a file is that you are able to share them  with
others. Editing them by hand - again - can still obey some
more or  less strict rules, which I don't see as a problem.

Said that, to me, user  can edit the files however they
won't, as long as they know what they are  doing. If we
want, we may publish a "batch files language syntax" for
the  manual coding.

This doesn't want to be a "whatever", but rather a "i  don't
really know" as I haven't used Audacity batch  files
before...

I agree though that one way to avoid common mistakes  is to
provide the editor, and disallow users to modify the string
in the  batch dialog: as much, we should still allow them to
copy it from there (for  example, as a reference/example).

Once we decide all the charset to  allow/forbid, we can use
the regexp or rollback to the 'old' parser, maybe  enhance
it. I will be happy to work on  it.

thanks,
.salvo




--- Mar...@ao... ha  scritto:

>  
> Salvo
>  
> The code we  have in CVS does work and allows for int,
> float, bool, string   
> and so on.  The most complicated example is, I think, in
>  the Equalizer code  
> where we have to use TransferString for the  curve name,
> as this can be set by  
> the user; the code  allows spaces but excludes < > ' \ (I
> don't know  why these  
> specific ones are illegal).  Something like
>   
>  FilterLength=8191 CurveName="Martyns rolloff"
>  InterpolateLin=no
>  
> being an int, a string and a  bool.
>  
> These chains are stored in a .txt file and I  imagined
> people may want to  
> edit them by hand so I wanted  to make the syntax slightly
> more flexible -  
> allowing  spaces around the '=' and use of single or
> double quotes.  I   expressed 
> this in a previous email as
>  
>  param1$=$value1 $param2$=$('or ")value$two(same as last '
> or   ")$etc
> where $ means zero-to-many white-space chars.
> 
>  There are, however, other problems if we expect users to
> edit the  .txt  files 
> by hand, and we do have the editor, so perhaps this  is
> not a sensible aim  
> right now.  Also there's the  increase in exe size that
> Markus notes  (although I 
> only  see 60k in Release and 164k in UD).
>  
> However, people can  currently edit the parameters in the
> main interface and  
>  so I do think that should be disabled, as I said before.
>  
>  What do you think?
> Martyn
>  
> In a message dated  02/05/2007 03:55:14 GMT Daylight Time,
>  
>  ven...@ya... writes:
> 
> > Or  am I expecting  too much of a regex?
> 
> Hehe :-)
> Maybe, maybe not...   See, if we want to avoid to scan all
> the matches that the regexp has had  at  any level, then
> this
> can get very complicated. If we  start relaxing on  this,
> then we will end up looping... again!  :-)
> 
> Question is: how  complex will the expression become?  I
> am
> always for the 'if things become  too complex, go for  an
> easier (and cleaner) solution'. Or add restrictions:  no
>  quotes in strings, not even escaped, no ' signs etc...
> Or there is   another way.
> 
> For example, if it is true that we can always  divide  our
> parameter string in blocks like  this:
>  
> [spaces]key=value[spaces]
> 
> then we might not even  need  anything more than:
> 
> 1. add a space at the end of the  param string
> 2.  search for '[spaces]key=*[spaces]
> 
>  and get the item out. This means  straight things: ""eric
> is a  single item of 6 chars. Then just trim any  spaces
> left.
>  
> We could leave up to the single 'value consumer' to 
>  decide
> if the value is good or bad.
> 
> What do you   think?
> 
> thx,
> .salvo
> 
> 
> ---  Mar...@ao... ha  scritto:
> 
> > salvo
>  >  
> > Thanks for the link, which  I've read (but perhaps  not
> > absorbed  fully).  I've 
> >  used  regex's a lot over the years but mostly only
> simple 
> > ones  (like  for 
> > finishing my crosswords using a big list of  words). 
> The  
> > more complex syntax just 
> >  isn't in my head.
> >   
> > I've also read the  first chapter of "Mastering Regular
> >  Expressions, 3rd   
> > Edition By Jeffrey E. F. Friedl" (O'Reilly),  and  will
> try
> > and read some more  
> >  tomorrow.
> >   
> > I've always thought of regex's  as a way of defining the
> >  syntax of  a 
> >  language, and that is really what we are trying to  do
> > here, I  think, which is  why I 
> > feel it's the way to  go.
>  >  
> > The rest of this is random  thoughts...
>  >  
> > ""eric" is being too greedy, I think.   It  should match
> an
> > empty string  (a 
> > quote  followed by a  quote is an empty string to me).
> >  
>  > Is stripping any  remaining quotes (and so on) 'by
>  hand'
> > really the way  to  go?
> >  
>  > I can see what you were thinking with the likes  of
> >  (?:\"); I had a  play with 
> > your code and came up with   some similar things myself
> to
> > what you  had tried  
> > (I  didn't do any better, even using \1).  I would be  
> > disappointed  with regex 
> > if we didn't manage to  come up with a better  
> solution.
> >  
> >  If it can't do
> > "a load of random  characters" | 
>  aLoadOfRandomCharacters
> > and give an unquoted  string then it  ain't much cop is 
> > it?
> >  
> > Isn't   using string.trim rather admitting defeat?
> >  
> > And  using '  instead of " should be easy, if we get the
> > other  bits   sorted!
> >  
> > Or am I expecting too  much of a regex?
> >  
> > TTFN
> >  Martyn
> >  
> > In a message dated  01/05/2007  02:51:06 GMT Daylight
> Time,
> ...
>