June 14, 2010
bearophile wrote:
> I am back.
> 
> From the v2.047 changelog:
>> std.conv: Added file and line information to conversion errors; added brackets '[' and ']' around arrays and associative arrays as defaults; added emplace() for non-class types.<
> 
> This program:
> 
> import std.stdio: writeln;
> import std.conv: to;
> void main() {
>     int[] a = [1, 2, 3];
>     writeln(to!string(a));
>     writeln(a);
> }
> 
> 
> Prints:
> [1 2 3]
> 1 2 3
> 
> 
> But I think if they produce the same default output.
> 
> Like:
> [1, 2, 3]
> [1, 2, 3]
> 
> --------------------------
> 
> I have reopened bug 4109 and in the meantime Shin Fujishiro has closed it again. He looks efficient :-)
> 
> Bye,
> bearophile

Thank you guys. Indeed that was my intent.

Andrei
June 14, 2010
Andrei Alexandrescu:
> Thank you guys. Indeed that was my intent.

What do you mean?

Bye,
bearophile
June 14, 2010
> What do you mean?

I have now understood :-)
June 14, 2010
torhu Wrote:

> I tried the example on page 406-407 of the book (copying stdin to stdout using message passing).  I don't mean to be a killjoy, but it doesn't compile. :(
> 
> I'm using the latest pdf version of the book, and dmd 2.047.
> 
> 
> I get this:
> 
> ---
> d:\prog\dmd\bin\..\src\phobos\std\stdio.d(1902): Error: cannot
> implicitly conver
> t expression (buffer) of type ubyte[] to immutable(ubyte)[]
> d:\prog\dmd\bin\..\src\phobos\std\stdio.d(7): Error: template instance
> std.stdio
> .chunks.opApply!(int delegate(ref immutable(ubyte)[] __applyArg0)) error
> instant
> iating
> ---

stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you can't ask for an immutable ubyte[] in the foreach line.  Here's the version of that sample I used to test (13.7):

import std.algorithm, std.concurrency, std.stdio;

void main()
{
    enum bufferSize = 10;
    auto tid = spawn( &fileWriter );
    // Read loop
    foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
        send( tid, buffer.idup );
}

void fileWriter()
{
    // Write loop
    for( ; ; )
    {
        auto buffer = receiveOnly!(immutable(ubyte)[])();
        writeln( "rx: ", buffer );
    }
}
June 14, 2010
On 15.06.2010 00:45, Sean Kelly wrote:
> stdin.byChunk uses a mutable buffer that's overwritten for each chunk so you can't ask for an immutable ubyte[] in the foreach line.  Here's the version of that sample I used to test (13.7):
>
> import std.algorithm, std.concurrency, std.stdio;
>
> void main()
> {
>      enum bufferSize = 10;
>      auto tid = spawn(&fileWriter );
>      // Read loop
>      foreach( ubyte[] buffer; stdin.byChunk( bufferSize ) )
>          send( tid, buffer.idup );
> }
>
> void fileWriter()
> {
>      // Write loop
>      for( ; ; )
>      {
>          auto buffer = receiveOnly!(immutable(ubyte)[])();
>          writeln( "rx: ", buffer );
>      }
> }

Right, now where's the bugzilla for TDPL? :)
June 15, 2010
On 2010-06-14 04:10, Eric Poggel wrote:
> On 6/13/2010 9:30 AM, Lutger wrote:
>> Great, thank you!
>>
>> I noticed both std.concurrency and std.json are not (yet?) included in
>> the documentation. Does that have any bearing on their status, are
>> they usable and / or stable?
>>
>> There are some other modules without documentation like std.openrj and
>> std.perf. Is there a page somewhere that documents their fate? I could
>> only find this one:
>>
>> http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel
>
> Speaking of std.json, has anyone looked at the Orange library on
> dsource? http://www.dsource.org/projects/orange/
>
> I haven't used it (yet), but it looks to support a back-end
> serialization engine that supports different front-ends, with xml
> currently being implemented. It's also Boost licensed.

I would but it the other way around, a serialization front end with support for different back ends (archive types). I hope to add support for Phobos soon.

-- 
/Jacob Carlborg
June 15, 2010
My project takes 4 times longer to compile with 1.062 (iso 1.061).
It now takes 1min 20sec on my p4 and memory doesn't seem to be the problem (<80MB).
I'd rather have it below 30sec :)

bud prj\main.d -w -inline -O -full -cleanup -IC:\D\Libs\

June 15, 2010
strtr wrote:
> My project takes 4 times longer to compile with 1.062 (iso 1.061).
> It now takes 1min 20sec on my p4 and memory doesn't seem to be the problem (<80MB).
> I'd rather have it below 30sec :)


I have no idea why that might be. Anyone else have this problem?
June 15, 2010
It's the optimization :)
Without -O compilation took only a few seconds!
June 15, 2010
strtr wrote:
> It's the optimization :)
> Without -O compilation took only a few seconds!

Well, that explains it! Little attempt is made in the optimizer to make it compile faster if that would interfere with generating faster code.