Hello everyone,

I have taken the role of review manager of the std.regex replacement by Dmitry Olshansky. The review period begins now 2011-10-8 and will end on 2011-10-23 at midnight UTC. A voting thread to include into Phobos will be held after review assuming such is appropriate. The Voting period is one week.

Please note that you can try FRed as part of Phobos (Code) or by itself (Package of FReD) which includes docs.

Doc:

http://nascent.freeshell.org/fred/doc/

Code:

https://github.com/blackwhale/phobos MASTER

Package of FReD:

https://github.com/downloads/blackwhale/FReD/FReD.zip

Remember this will be replacing the current std.regex and is intended to be a drop in replacement. This project is also part of GSoC.

Dmitry, I ask that you apply this patch to posix.mak (adding to internal modules).

--- a/posix.mak
+++ b/posix.mak
@@ -184,7 +184,8 @@ std/c/, fenv locale math process stdarg stddef stdio
stdlib
 time wcharh)
 EXTRA_MODULES += $(EXTRA_DOCUMENTABLES) $(addprefix                    \
        std/internal/math/, biguintcore biguintnoasm biguintx86 \
-       gammafunction errorfunction) std/internal/processinit
+       gammafunction errorfunction) std/internal/processinit \
+       std/internal/uni std/internal/uni_tab

 # Aggregate all D modules relevant to this build
 D_MODULES = crc32 $(STD_MODULES) $(EXTRA_MODULES) $(STD_NET_MODULES)

On 10/8/2011 12:56 PM, Jesse Phillips wrote:
> Doc:
>
> http://nascent.freeshell.org/fred/doc/

1. There are many different regular expressions for strings. Should include a link to whichever one fred uses. Feel free to crib from http://www.digitalmars.com/ctg/regular.html

2. Many of the examples can be wrapped in a void main(){ ... } so that they are compilable using cut & paste.

3. "Advanced Syntax" and other headings need to be bold faced.

On 08.10.2011 23:56, Jesse Phillips wrote:
> Hello everyone,
>
> I have taken the role of review manager of the std.regex replacement by
> Dmitry Olshansky. The review period begins now 2011-10-8 and will end on
> 2011-10-23 at midnight UTC. A voting thread to include into Phobos will
> be held after review assuming such is appropriate. The Voting period is
> one week.
>
> Please note that you can try FRed as part of Phobos (Code) or by itself
> (Package of FReD) which includes docs.
>
> Doc:
>
> http://nascent.freeshell.org/fred/doc/
>
> Code:
>
> https://github.com/blackwhale/phobos MASTER
>
> Package of FReD:
>
> https://github.com/downloads/blackwhale/FReD/FReD.zip
>
> Remember this will be replacing the current std.regex and is intended to
> be a drop in replacement. This project is also part of GSoC.
>
> Dmitry, I ask that you apply this patch to posix.mak (adding to internal
> modules).
>
> --- a/posix.mak
> +++ b/posix.mak
> @@ -184,7 +184,8 @@ std/c/, fenv locale math process stdarg stddef stdio
> stdlib
>   time wcharh)
>   EXTRA_MODULES += $(EXTRA_DOCUMENTABLES) $(addprefix                    \
>          std/internal/math/, biguintcore biguintnoasm biguintx86 \
> -       gammafunction errorfunction) std/internal/processinit
> +       gammafunction errorfunction) std/internal/processinit \
> +       std/internal/uni std/internal/uni_tab
>
>   # Aggregate all D modules relevant to this build
>   D_MODULES = crc32 $(STD_MODULES) $(EXTRA_MODULES) $(STD_NET_MODULES)

Thanks, updated and now it works on linux for me. Though it wasn't that simple.

I've found out what caused my builds to break. The thing is that both std.file & std.stdio use fully qualified std.c.stdio.func calls but never actually import std.c.stdio in any way. I wasn't even aware that's possible.

So I changed it to core.stdc in std.file and added static import to std.stdio (some functions from std.c are not present in core.stdc apparently).  If there is any problem with that I can revert it, and investigate why it affects only me ;)


-- 
Dmitry Olshansky

On 09.10.2011 0:30, Walter Bright wrote:
> On 10/8/2011 12:56 PM, Jesse Phillips wrote:
>> Doc:
>>
>> http://nascent.freeshell.org/fred/doc/
>
> 1. There are many different regular expressions for strings. Should
> include a link to whichever one fred uses. Feel free to crib from
> http://www.digitalmars.com/ctg/regular.html
>

While I do mention ECMA-262 falvor, I agree a table right there is far more preferable. Will do.

> 2. Many of the examples can be wrapped in a void main(){ ... } so that
> they are compilable using cut & paste.
>

Indeed, I just though it wasn't phobos style. Now looking through again I see there are a lot of examples with void main().

> 3. "Advanced Syntax" and other headings need to be bold faced.

Right, thanks.

-- 
Dmitry Olshansky

On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
> I've found out what caused my builds to break. The thing is that both
> std.file & std.stdio use fully qualified std.c.stdio.func calls but
> never actually import std.c.stdio in any way. I wasn't even aware that's
> possible.

That may be a bug in the compiler. A symbol shouldn't be visible unless e.g. publicly imported from an imported module (could that be the case)?

Andrei

On 10/8/2011 1:43 PM, Dmitry Olshansky wrote:
> Right, thanks.

Welcs. And I might add that I do greatly appreciate the work you've done on this, I think it could be a showcase for D's capabilities.

Andrei Alexandrescu wrote:

> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>> I've found out what caused my builds to break. The thing is that both std.file & std.stdio use fully qualified std.c.stdio.func calls but never actually import std.c.stdio in any way. I wasn't even aware that's possible.
> 
> That may be a bug in the compiler. A symbol shouldn't be visible unless e.g. publicly imported from an imported module (could that be the case)?

It's definitely a bug. Once an import is processed, the package is visible globally as long as the parent package is accessible. This compiles:

touch dmd2/src/phobos/std/empty.d

a.d:
import std.stdio;

b.d:
import std.empty;
void main() { std.stdio.writeln("hi!"); }

On 10/9/11 2:26 AM, Christian Kamm wrote:
> Andrei Alexandrescu wrote:
>
>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>>> I've found out what caused my builds to break. The thing is that both
>>> std.file&  std.stdio use fully qualified std.c.stdio.func calls but
>>> never actually import std.c.stdio in any way. I wasn't even aware that's
>>> possible.
>>
>> That may be a bug in the compiler. A symbol shouldn't be visible unless
>> e.g. publicly imported from an imported module (could that be the case)?
>
> It's definitely a bug. Once an import is processed, the package is visible
> globally as long as the parent package is accessible. This compiles:
>
> touch dmd2/src/phobos/std/empty.d
>
> a.d:
> import std.stdio;
>
> b.d:
> import std.empty;
> void main() { std.stdio.writeln("hi!"); }

Hm, this is important. But what is the contribution of a.d to the example? Do you compile it together with b.d?

Andrei

Andrei Alexandrescu wrote:

> On 10/9/11 2:26 AM, Christian Kamm wrote:
>> Andrei Alexandrescu wrote:
>>
>>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>>>> I've found out what caused my builds to break. The thing is that both std.file&  std.stdio use fully qualified std.c.stdio.func calls but never actually import std.c.stdio in any way. I wasn't even aware that's possible.
>>>
>>> That may be a bug in the compiler. A symbol shouldn't be visible unless e.g. publicly imported from an imported module (could that be the case)?
>>
>> It's definitely a bug. Once an import is processed, the package is visible globally as long as the parent package is accessible. This compiles:
>>
>> touch dmd2/src/phobos/std/empty.d
>>
>> a.d:
>> import std.stdio;
>>
>> b.d:
>> import std.empty;
>> void main() { std.stdio.writeln("hi!"); }
> 
> Hm, this is important. But what is the contribution of a.d to the example? Do you compile it together with b.d?

Yes, 'dmd b.d' fails, 'dmd a.d b.d' succeeds.

On 10/9/2011 12:30 AM, Andrei Alexandrescu wrote:
> On 10/9/11 2:26 AM, Christian Kamm wrote:
>> Andrei Alexandrescu wrote:
>>
>>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>>>> I've found out what caused my builds to break. The thing is that both std.file&  std.stdio use fully qualified std.c.stdio.func calls but never actually import std.c.stdio in any way. I wasn't even aware that's possible.
>>>
>>> That may be a bug in the compiler. A symbol shouldn't be visible unless e.g. publicly imported from an imported module (could that be the case)?
>>
>> It's definitely a bug. Once an import is processed, the package is visible globally as long as the parent package is accessible. This compiles:
>>
>> touch dmd2/src/phobos/std/empty.d
>>
>> a.d:
>> import std.stdio;
>>
>> b.d:
>> import std.empty;
>> void main() { std.stdio.writeln("hi!"); }
> 
> Hm, this is important. But what is the contribution of a.d to the example? Do you compile it together with b.d?
> 
> Andrei

Isn't this bug #314?  Very well known, super old, highly voted for, etc, etc.