April 08, 2009
On Wed, Apr 8, 2009 at 5:00 PM, bearophile <bearophileHUGS@lycos.com> wrote:
>
> Most times you don't want to change the separator. For the uncommon cases where you want a different separator, you can use a map plus a std.string.join. So I don't like it.

Wow, talk about inefficient.  Consider you have to write out a 100,000 element array.  What a waste of memory.
April 08, 2009
Piotrek wrote:
> Hi,
> 
> I looked at std.algorithm. Wow, what a piece of art.
> 
> BTW. What about your book on D? Any known dates? I know nothing about publishing business, so forgive my ignorance in advance.
> 
> Cheers

Thanks. It's a good question. The book has 121 pages written out of the projected 350. The bottleneck is how soon we'll have a reasonably complete threading model. I don't have an exact date at the moment.

In wake of the incredibly good experience with luring reviewers off this group for "The Case For D", I might try a similar trick for getting parts of the book reviewed. TCFD got probably 20% value added by reviewers alone. Many thanks to (list copied from the draft I submitted) Bill  Baxter,  Jason  House,  John ``Eljay''  Love-Jensen, Denis Koroskin, leonardo  maffi  (sic), Petru Marginean,  Bartosz Milewski, Derek Parnell,  Brad  Roberts, Joel  Salomon,  Benjamin Shropshire, David  Simcha, Florin  Trofin, Cristian Vlasceanu, and Walter Bright.

By the way, TCFD is coming to a website near you too. It's received publication approval from both the Overload magazine in England and the online magazine Doctor Dobb's Journal (which will make it available online for free). Publication dates to be announced soon.


Andrei
April 08, 2009
Jarrett Billingsley:
> Wow, talk about inefficient.  Consider you have to write out a 100,000 element array.  What a waste of memory.

There are three parameters to consider here: flexibility, speed, and complexity.

In most situations you don't need speed and flexibility (because you have to print few data and a comma is OK for most printing situations), so I think it's better to minimize complexity.

If you need flexibility but speed isn't necessary, use a generator or list comprehension or a map, plus a join. So the "complexity" is low still because you don't need to learn more syntax.

Then there is the large data case. Often you need to print it with commas, so the default printing is fine.

For the uncommon situation you talk about, where you have both large data and you need flexibility, then write a small for loop with many write() inside.

-----------------------

Andrei:
>How about parsing?<

How about using a module of the standard library designed for such simple parsing purposes?

Anyway, do as you like. I'm just thinking aloud here. I'll probably rewrite my dlibs for 2.0 anyway.

Later,
bearophile
April 08, 2009
bearophile:
>I'll probably rewrite my dlibs for 2.0 anyway.<

Ignore this part, please, it's not good.

Bye,
bearophile
April 08, 2009
Andrei Alexandrescu wrote:
>> Will the final release support "osx" [sic] and "freebsd" too,
>> or is the new Phobos going to be "Windows" and "linux" only ?

> I'll need to defer such testing and answers to Walter; I don't have access to OSX and FreeBSD.

Think I was just looking in the wrong place, the svn did have them.
So I'm assuming it's just a merge away and it'll be the same as now.

Strange with how "Unix" became "Posix" and "darwin" became "OSX" and
"freebsd" became "FreeBSD", but I guess that is evolution for ya...

--anders
April 08, 2009
bearophile wrote:
> bearophile:
>> I'll probably rewrite my dlibs for 2.0 anyway.<
> 
> Ignore this part, please, it's not good.

Huh, is this some kind of feel-good community?

> Bye,
> bearophile
April 08, 2009
grauzone:
> Huh, is this some kind of feel-good community?

Brutal environments kill playful mood and don't lead to creative thinking and good ideas, and also keep away gentle but potentially useful people (think about women too). A good place keeps your blood pressure lower, and makes you live longer.

Be well,
bearophile
April 08, 2009
bearophile wrote:
> Jarrett Billingsley:
>> Wow, talk about inefficient.  Consider you have to write out a
>> 100,000 element array.  What a waste of memory.
> 
> There are three parameters to consider here: flexibility, speed, and
> complexity.
> 
> In most situations you don't need speed and flexibility (because you
> have to print few data and a comma is OK for most printing
> situations), so I think it's better to minimize complexity.
> 
> If you need flexibility but speed isn't necessary, use a generator or
> list comprehension or a map, plus a join. So the "complexity" is low
> still because you don't need to learn more syntax.
> 
> Then there is the large data case. Often you need to print it with
> commas, so the default printing is fine.
> 
> For the uncommon situation you talk about, where you have both large
> data and you need flexibility, then write a small for loop with many
> write() inside.
> 
> -----------------------
> 
> Andrei:
>> How about parsing?<
> 
> How about using a module of the standard library designed for such
> simple parsing purposes?

std.format. There is formattedWrite that looks and works complementary to formattedRead. About the speed/complexity/flexibility tradeoff, I think it's a good point in spirit but kind of misapplied. I can't bring myself to advocate a solution that involves memory allocation and the such when the task is to dump out an array, and I also need to write and parse sequences all the time, so I extended the formatting strings to make that comfortable and consistent for both parsing and writing. That doesn't preclude using join et al, and also doesn't affect existing code (currently "%(" is invalid), so I don't quite understand the complaint.


Andrei
April 08, 2009
grauzone Wrote:

> bearophile wrote:
> > bearophile:
> >> I'll probably rewrite my dlibs for 2.0 anyway.<
> > 
> > Ignore this part, please, it's not good.
> 
> Huh, is this some kind of feel-good community?

ignore. crybaby wanna attention. new releases piss him off. with each phobos bearophile comes all 'i told ya' &'finally u do like my dlibs' & primedonne nitpicks & shit. feels not reco or sumth'n. relax dood. u didnt invent all tat shit.

anyway. found time 2 look over phobos & got some nits myself @ andre. std.algorithm is big. should be more orthogonal. why fill. i can do copy with repeat. some other fns can go. std.range is incomplete. theres tons of ranges tat r useful. std.numeric is a motley crew of vaguely related shit. theres no containers. u got all bananas w range but only test with arrays. no good solution for array append. fuck appender. no matrices & u promised tem. fptemporary dont make sense. anyway. this shit is dope. ranges r cool & simple in hindsight. tats a good sign. ill get hands dirty n maybe report more.
April 09, 2009
On Wed, 08 Apr 2009 19:24:10 -0400, superdan wrote:

> ill get hands dirty n maybe report more.

If you do, can you report back using English. I'm not very good at translating your, presumably excellent, insights otherwise.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell