"Walter Bright" <newshound@digitalmars.com> wrote in message news:drm62v$13rf$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:drkk9b$290u$1@digitaldaemon.com...
>> Regular Expressions are a very powerful syntax for expressing search
>> strings, and reg ex libraries define mechanisms for applying that syntax
>> and
>> retrieving results. Here are some sample expressions from some of my
>> scripts:
>>
>>
>>    if line =~ /^# include <#{projectName}/#{projectName}.h>/
>
> In D:
>
>    import std.regexp;
>
>    if (find(line, r"^# include <#{projectName}/#{projectName}.h>") != -1)
>        ...

I think you've erred here. D doesn't support intra-literal code evaluation, does it?

> Evidently you find std.regexp from Phobos to be unsatisfactory. Can you explain what's wrong with it (and exactly how the Ruby one is better)?

Not really. It's been an age since I tried to use it. As it was, it was not substantially better or worse than a C++ one, which is to say: not very appealing.

If it's changed, great. I've heard good things here and there, and I have no reason to doubt them.

But my point was that people were discussing whether D might be an alternative to Python/Perl/Ruby and that without built-in support it wasn't going to qualify. I stand by that.

> And what's wrong with boost.regex, for that matter.

I'm not touching that one.

> Eric and I are developing a compile-time regexp parser, and it would help to know what the ideal would be. We can certainly get syntax that is quite close to the examples you've shown above... but the subtle details can be crucial.
>
> eg, would this be acceptable?
>
> char [] projectname;
> ...
> if ( matches!("^#include<#{1}/#{1}.h>")(projectname, line) ) {
>
> }
>
> (not sure about the syntax for #{1} ).
> which is eminently possible right now, or do we need to go further?
>
> if (line.matches!("^#include<#{1}/#{1}.h>")(projectname) ){
> }
>
> or even something like:
>
> if (matches!("^#include<#{projectname}/#{projectname}.h>")(line) ){
> }
>
> (this last one isn't currently possible, but I _think_ it could be done with a small language change -- would be easier to argue for it, if it was believed to be necessary).

All of those look reasonably nice. Until I get chance and a reason to use them, I can't attempt to give any kind of comparative opinion. (But who says my opinion's worth having on this point, anyway? I ain't no regex expert. <g>)

"Matthew" <matthew@stlsoft.com> wrote in message news:drmhon$1m79$2@digitaldaemon.com...
>
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:drm62v$13rf$1@digitaldaemon.com...
>>
>> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:drkk9b$290u$1@digitaldaemon.com...
>>> Regular Expressions are a very powerful syntax for expressing search
>>> strings, and reg ex libraries define mechanisms for applying that syntax
>>> and
>>> retrieving results. Here are some sample expressions from some of my
>>> scripts:
>>>
>>>
>>>    if line =~ /^# include <#{projectName}/#{projectName}.h>/
>>
>> In D:
>>
>>    import std.regexp;
>>
>>    if (find(line, r"^# include <#{projectName}/#{projectName}.h>") != -1)
>>        ...
>
> I think you've erred here. D doesn't support intra-literal code evaluation, does it?

I see what you mean. It should be:

    if (find(line, "^# include <" ~ projectName ~ "/" ~ projectName ~ ".h>")
!= -1)

using string concatenation. Or:

    if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)

Walter Bright wrote:
> using string concatenation. Or:
> 
>     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)

I think you meant:
	if (find(line, format("^# include <%s/%s.h>", projectName, projectName)) != -1)




-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:drmma0$1p9i$1@digitaldaemon.com...
> Walter Bright wrote:
>> using string concatenation. Or:
>>
>>     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)
>
> I think you meant:
> if (find(line, format("^# include <%s/%s.h>", projectName, projectName))
> != -1)

Oops!

On Mon, 30 Jan 2006 20:36:09 -0800, Walter Bright wrote:

> "Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:drmma0$1p9i$1@digitaldaemon.com...
>> Walter Bright wrote:
>>> using string concatenation. Or:
>>>
>>>     if (find(line, format("^# include <%s/%s.h>", projectName)) != -1)
>>
>> I think you meant:
>> if (find(line, format("^# include <%s/%s.h>", projectName, projectName))
>> != -1)
> 
> Oops!

This is why I have a function that does this ...

   Expand("# include <{pn}/{pn}.h>", "pn=" ~ projectName)

its found (and poorly documented) in Build's util/str.d

Regular expression comparisons are very useful when processing string inputs. The Build utility needed a lot of them I found, so I wrote 'IsLike', 'begins', 'ends', 'Tokenize' and 'Expand' as general purpose functions that meet my needs so far.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
31/01/2006 4:47:03 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:62turl0f9xkr.1g1pit4wbvmqs.dlg@40tude.net...
> This is why I have a function that does this ...
>
>   Expand("# include <{pn}/{pn}.h>", "pn=" ~ projectName)
>
> its found (and poorly documented) in Build's util/str.d

The whole std.regexp in Phobos is poorly documented as well.

$_ ?!  Oh the horror.



"Matthew" <matthew@stlsoft.com> wrote in message news:drlua3$r7j$1@digitaldaemon.com...
>
> "Charles" <noone@nowhere.com> wrote in message news:drlds5$7a1$1@digitaldaemon.com...
> > Yea I feel your pain.  I've kind of given up actively plugging D, its
just
> > taking so long.  Hopefully before 2009 ( C++0x ) we will have a 1.0.
>
> ;-/
>
> > Id like to see the compile time regex lib before I say yes or no to
built
> > in
> > regex's , but I guess builtin couldnt really hurt the language.
>
> Sure. My position is not that D has to have built-in regex, just that if
it
> doesn't then it can't hope to be a serious alternative to Perl and Ruby.
>
> > On a side note I read that article in one of the other posts comparing
> > ruby/c++/python/java -- and after looking at the source code for the
> > examples, ruby looks uber!  I definetly want to give it a try now --
> > having
> > retired perl long ago.
>
> It is indeed great. The thing that "worries" me is that I learned
everything
> I know about it in the first two days, and that I've not learned anything since. This either means I'm missing out on a huge amount of stuff, or
it's
> just as simple and easy as it seems.
>
> Most of my scripts use recls/Ruby, which is as simple as:
>
>
> require 'recls'
>
> fs = Recls::FileSearch::new("h:/stlsoft", "*.hpp|*.h", Recls::FILES |
> Recls::RECURSIVE)
>
> fs.each \
> { |fe|
>
>     lines = IO::readlines(fe.path)
>
>     lines.each_with_index \
>     { |line, index|
>             line.chomp!
>             if line =~ / blah blah blah /
>                 lines[index] = blah2 blah2 blah2
>             end
>     }
>
>     if bChanged
>         f = File::new(fe.path, "w")
>         lines.each { |line| f << line << "\n" }
>         f.close
>         puts "Processed #{fe.path}"
>     end
> }
>
> This is the basic form of my scripts, with which I can effect changes to hundreds/thousands of source files in one go. It's really really useful.
>
> (I'd love to be doing the same in D, but ...)
>
>
>
>
>

Matthew wrote:
> 
> This is the basic form of my scripts, with which I can effect changes to hundreds/thousands of source files in one go. It's really really useful.

I tend to use UltraEdit for this sort of thing, though scripting it seems a nice alternative.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:drolf7$1tae$1@digitaldaemon.com...
> Matthew wrote:
> >
> > This is the basic form of my scripts, with which I can effect changes to hundreds/thousands of source files in one go. It's really really useful.
>
> I tend to use UltraEdit for this sort of thing, though scripting it seems a nice alternative.

I've never tried UltraEdit. Although I'm sure it would work for most things I do, inevitably it would fall down on some, e.g. moving all the unit-test blocks out of any library headers and into newly created ./unittest/blahblah_unittest_.h files.