Re: Dream package management system (Was: a cabal for D ?)

[Russel Winder]

On Sat, 2011-04-02 at 21:35 +0200, Jacob Carlborg wrote:
[ . . . ]
> I don't think it's the package manger's job to build the 
> application/library. The package manager operates on a level higher than 
> a build tool. The build tool is working with files, tracking 
> dependencies among files and building applications/libraries. The 
> package manager is working with packages, tracking dependencies among 
> packages.

Haskell's Cabal has blurred the lines between package management and
build in many people's minds, but it only succeeds when in isolation.
As soon as there is a platform packaging system it is clear that build
and packaging must be separate.  Though obviously you can get into
JVM/Maven, and indeed Go, situations where again the lines get blurred.

For something such as D which should have some ability to work with C
and C++ libraries, keeping the separation is likely a better route.

> I was planning to creating my own build tool that would be integrated 
> with the package manager. The package manager would use the build tool 
> to track the files making up the package. But other build tool would be 
> supported as well, not forcing anyone to use my build tool.

Is there a need for a brand new build tool.  Are CMake, SCons and Waf
not sufficient to the task?

Clearly there are no perfect tools, there is always room for evolution
and new things.  However the history in the JVM-related milieu and the
Go arena, indicate that the knee jerk reaction of "we have a new
language, therefore we must write a new build framework" leads to a lot
of isolationism, creation of ghettos, and a lot of wasted effort.  Go
has at least 6 brand new build frameworks, all of which were deemed
necessary, and none of which have gained any traction -- the core
development team are believers that Make is all that is needed.  Rake
has gained little traction outside the Ruby community. Leiningen has
little traction outside the Clojure community.  SBT has little traction
outside the Scala community.  Gradle is getting significant traction
across the Java and Groovy communities as it solves problems inherent in
the wildly successful Ant and Maven frameworks.

SCons and Waf arose as dynamic language realizations of ADG-based
systems to replace Make and Autotools respectively.  They have a clear
reason for existence and are successful, indeed have traction.  CMake
likewise.

Note here though there is a yawning gap between build frameworks in the
JVM-verse and the native-verse.  Tools from one are generally rubbish in
the other, to the detriment of build.

If there is to be a new build framework to compete against SCons, Waf,
CMake, Gradle and Maven I suggest it must be designed from the outset to
deal with the vastly different problems of C, C++, D, LaTeX, Python,
Ruby, Java, Groovy, Scala, Clojure, Erlang, Haskell, Chapel, Fortress,
X10, etc.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: deprecation of "complex" floating point types

[Moritz Warning]

On Sun, 03 Apr 2011 00:48:29 +, Francisco Almeida wrote:

> Are there plans to deprecate the built-in complex types soon?

I assume they will be deprecated when a library replacement is feasible 
and implemented.

Re: Is the world coming to an end?

[Andrei Alexandrescu]

On 4/2/11 9:38 PM, Adam D. Ruppe wrote:

Andrei Alexandrescu wrote:

Did that include the string parsing and all?


Yeah. You can see my original version here:
http://arsdnet.net/dcode/octal.d

The meat of the code is pretty well unchanged in Phobos.


Oh indeed, and you're credited in std.conv as an author, too. Thanks!

Andrei

Re: GSoC: Containers and Ranges

[Ishan Thilina]

Hi,

D's Ranges are somewhat like iterators in C++.But only interface is compared to
find out what kind of a range this is ( I think this is called duck typing, not
sure though).There are mainly 4 kinds of ranges.

One passs range

Forward range

Double ended range

Random access range

If I show you the inheritance hierarchy( again, this is not true inheritance :) 
),

One pass range<-- Forward range<-- Random access range


One pass range:
Can get a single element from the container. Has three methods.

bool empty() --> Checks to see whether the current element that it's pointing to
is empty( or has been already accessed).

void popFront()--> Points to the next element in the container

Ref(T) front()--> Returns a reference to the current element that the range 
points to.

Forward range:
Has the same methods as the one pass range but also has an additional method "
ForwardRange save()". This method returns an exact copy of the range.

Double ended range:

Similar to One pass range, but can access data from the back of the container
too.This has the same methods of One pass range and also has these additional 
methods.

Ref(T) back()
void popBack()

( you can guess what they do, can't you ? ;) )

Random access range:

As the name suggests provides random access to elements of the container( Should
be in constant time I guess). Has these additional methods with respect to 
Forward
ranges.

Ref(T) at(int i)--> Fetches an element at the given index i.
RandomAccessRange slice(int i, int j)--> Returns a random access range which
points to a sub range lying between indexes i and j.

Hope this helps :)

Re: Is the world coming to an end?

[Andrei Alexandrescu]

On 4/2/11 9:28 PM, Adam D. Ruppe wrote:

Andrei Alexandrescu wrote:

std.conv.octal _is_ the work of the community, written by myself and
others (could you please identify yourselves)?


I wrote the first version, interestingly, almost exactly a year
ago now. (The timestamp on my local file is 2010-03-26)

It looks like the current version is mostly the same as my
original one, although with significantly improved documentation
and some style cleanup.


Did that include the string parsing and all? I didn't write that code.

Andrei

Re: Is the world coming to an end?

[Adam D. Ruppe]

Andrei Alexandrescu wrote:
> std.conv.octal _is_ the work of the community, written by myself and
> others (could you please identify yourselves)?

I wrote the first version, interestingly, almost exactly a year
ago now. (The timestamp on my local file is 2010-03-26)

It looks like the current version is mostly the same as my
original one, although with significantly improved documentation
and some style cleanup.

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 6:44 PM, Daniel Gibson wrote:

Time will tell but I wouldn't be surprised if sooner or later somebody wonders
why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)


They might. We'll see.

Re: Is the world coming to an end?

[Andrei Alexandrescu]

On 4/2/11 7:52 PM, bearophile wrote:

Michel Fortin:


The new syntax is certainly usable, it's just inelegant and hackish.
Its your language, it's your choice, and I'll admit it won't affect me
much.


My suggestions for Walter are:
- To turn 01 .. 07 too into errors;
- to deprecate the octal! Phobos template.
- To introduce the 0o leading that works from 0o0 to the uint.max;
- To change the new error message, so it suggests to use 0o.
- To ask opinions to the community here next time before changing things in 
D2/D3 :-)

Bye,
bearophile


I think a point the size of China is being missed here.

"octal" is not only an alternative notation, it is an example, a model 
for defining other user-defined literals. Adding 0o or whatever would 
solve the issue of defining an obscure literal, whereas octal opens the 
door to a host of possibilities to define user-defined literals.


std.conv.octal _is_ the work of the community, written by myself and 
others (could you please identify yourselves)?



Andrei

Re: Python-indentation (Was: Re: Is the world coming to an end?)

[Andrei Alexandrescu]

On 4/2/11 8:01 PM, bearophile wrote:

PS I don't want to say every of Python's decisions is wrong. Many of them
are great (but defenitely not significant intendation).


There's a large difference between Python and D design process: Python devs discuss ideas 
about possible designs, even for days, and then the most preferred one is chosen. Only in 
uncommon cases, when there is no consensus, Guido chooses (like in the "X if P else 
Y" syntax). This, and the care they give to that process (they believe that good 
syntax matters), produce a language that's very well designed (despite some flaws).

Bye,
bearophile


That's how it works for D too.

Andrei

Re: Python-indentation (Was: Re: Is the world coming to an end?)

[Daniel Gibson]

Am 03.04.2011 03:01, schrieb bearophile:
>>> PS I don't want to say every of Python's decisions is wrong. Many of them  
>>> are great (but defenitely not significant intendation).
> 
> There's a large difference between Python and D design process: Python devs 
> discuss ideas about possible designs, even for days, and then the most 
> preferred one is chosen. Only in uncommon cases, when there is no consensus, 
> Guido chooses (like in the "X if P else Y" syntax). This, and the care they 
> give to that process (they believe that good syntax matters), produce a 
> language that's very well designed (despite some flaws).
> 
> Bye,
> bearophile

IMHO D is a language that is very well designed (despite some flaws) as well, so
it seems like D's design process isn't any worse ;)

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 04:00, schrieb Andrei Alexandrescu:
> On 4/2/11 6:36 PM, Daniel Gibson wrote:
>> Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
>>> On 4/2/11 5:27 PM, ulrik.mikaels...@gmail.com wrote:
 A D-newbie would probably be able to guess 0o for octal, but hardly
 octal!. octal! breaks the rule of least surprise.
>>>
>>> I fail to infer how using the word "octal" for an octal literal is 
>>> surprising at
>>> all.
>>>
>>> This thread is a good example that it's impossible to please everyone. 
>>> Although
>>> past discussions made it clear that most everyone found leading 0 a poor
>>> convention for octal numbers, now not only the consensus is weaker, but some
>>> actually claim a different solution is superior. If that were chosen, then 
>>> all
>>> of a sudden octal!777 would have become suddenly sexy and so on.
>>>
>>> The grass is always greener on the other side...
>>>
>>>
>>> Andrei
>>
>> I don't think the consensus that a leading 0 is a poor convention for octal
>> numbers is weaker now - so far nobody wants the old syntax back :)
> 
> Some discussions on IRC suggest otherwise.
> 
> Andrei

Ok. I don't hang out in the D IRC chan because the NG is time-consuming enough
already ;)

Re: Is the world coming to an end?

[Andrei Alexandrescu]

On 4/2/11 6:36 PM, Daniel Gibson wrote:

Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:

On 4/2/11 5:27 PM, ulrik.mikaels...@gmail.com wrote:

A D-newbie would probably be able to guess 0o for octal, but hardly
octal!. octal! breaks the rule of least surprise.


I fail to infer how using the word "octal" for an octal literal is surprising at
all.

This thread is a good example that it's impossible to please everyone. Although
past discussions made it clear that most everyone found leading 0 a poor
convention for octal numbers, now not only the consensus is weaker, but some
actually claim a different solution is superior. If that were chosen, then all
of a sudden octal!777 would have become suddenly sexy and so on.

The grass is always greener on the other side...


Andrei


I don't think the consensus that a leading 0 is a poor convention for octal
numbers is weaker now - so far nobody wants the old syntax back :)


Some discussions on IRC suggest otherwise.

Andrei

Re: Some combinatorics?

[dsimcha]

== Quote from bearophile (bearophileh...@lycos.com)'s article
> I'd like to write combinations, permutations, etc ranges (generators), for
std.algorithm or for a small std.combinatorics Phobos module. (I have written 
this
code time ago for dlibs1 in D1).
> I have found some small performance problems in converting the opApply
combinatorics code to the Range protocol.
> Are you interested in this module (or in just those few generators for
std.algorithm)? I find them often useful.
> Bye,
> bearophile

I've included these in my dstats lib, but my implementations admittedly aren't
very well thought out.  (I wrote these in 2008 before ranges and shoehorned them
into ranges.  I never fixed them because I kept thinking I or someone else was
going to rewrite them and that hasn't happened so far.)  I need this often 
enough
that I'd be interested in having them in Phobos.

Some code by Philippe Sigaud does it better than my implementations
(http://svn.dsource.org/projects/dranges/trunk/dranges/docs/algorithm.html) and 
is
Boost licensed.  He was thinking of getting parts of this lib into Phobos, but I
don't know what the status of that is.  If this project is abandoned and you 
like
it, you could take it over, or you could just write your own.

One important issue is whether the number of elements for a combination should 
be
specified at compile time (more efficient), runtime (more flexible) or both
(possibly bloated).

As far as where these should go, I'd say either std.range or a module publicly
imported by std.range.  They deal with range topology.

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 03:39, schrieb Walter Bright:
> On 4/2/2011 4:52 PM, Daniel Gibson wrote:
>> Am 03.04.2011 01:50, schrieb Walter Bright:
>>> On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:
 As I wrote, I think it's great that 010 != 8 anymore.
>>>
>>> 010, etc., will now be errors. They will not be 10 decimal.
>>>
>>> Also, the literals 00, 01, ..., 07 will still be accepted without 
>>> complaint. 08,
>>> 09, etc. will of course be errors.
>>
>> That feels pretty inconsistent.
> 
> It is inconsistent. One of the interesting things about "good" user interface
> design is it is awfully inconsistent.
> 
> The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't
> octal, and it seemed a pity to break it.

They were octal, it just didn't make a difference. I don't see a reason to use
them (if not as octals) anyway.

Time will tell but I wouldn't be surprised if sooner or later somebody wonders
why 00, 01..07 work, but 08 etc don't and complains about weird corner cases ;)

Cheers,
- Daniel

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 4:52 PM, Daniel Gibson wrote:

Am 03.04.2011 01:50, schrieb Walter Bright:

On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:

As I wrote, I think it's great that 010 != 8 anymore.


010, etc., will now be errors. They will not be 10 decimal.

Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 08,
09, etc. will of course be errors.


That feels pretty inconsistent.


It is inconsistent. One of the interesting things about "good" user interface 
design is it is awfully inconsistent.


The thing is, I ran into a bunch of D code that used 01, 03, etc. They weren't 
octal, and it seemed a pity to break it.

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 5:30 PM, Michel Fortin wrote:

On 2011-04-02 19:58:25 -0400, Walter Bright  said:

The problem with the octal literals is, as has been often complained about,
people getting surprised by it. I've never heard of anyone being surprised by
the binary or hex literals.

Indeed. Isn't that a good argument for implementing octal literals the same way
as binary and hex literals?


Yes, except for something else - the rarity of need for octal literals. The only 
modern usage I've seen of it is for file permissions.




I think it's a feature, not a "resort", that library templates can do this
well. I think it's far better than C++0x's user defined literals, for example.

I disagree that it's better. With C++ user defined literals the user doesn't
have to find by himself whether the number fits within the range of a regular
integer literal and if not fall back to using a string as the template argument
instead.


I believe that if you attempted to do octal literals using C++0x user defined 
literals, you'd run into exactly the same issue (overflow). See:


 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2765.pdf

C++0x user defined literals call a global function, which fails when you have 
more than one definition of the same literal. I.e. you cannot qualify the 
function to resolve ambiguity.


Other complaints about them:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3250.html



I don't think it's much worse, but I fail to see how it could be better.


Reasons:

1. It is not a language extension
2. Conflicting names are easily resolved
3. More than one argument is possible
4. The full power of CTFE is available to compute it, rather than the very 
limited C++0x constexpr
5. If you read N2765, it's pretty darned hackish. I.e. there's the "raw" and 
"cooked" mode.




Which makes me wonder, what does the compiler suggests in the error message when
it encounters 017 ? I suspect it doesn't add the necessary
quotes, does it?


No, it doesn't. The lexer knows nothing about higher level semantics.

Some combinatorics?

[bearophile]

I'd like to write combinations, permutations, etc ranges (generators), for 
std.algorithm or for a small std.combinatorics Phobos module. (I have written 
this code time ago for dlibs1 in D1).

I have found some small performance problems in converting the opApply 
combinatorics code to the Range protocol.

Are you interested in this module (or in just those few generators for 
std.algorithm)? I find them often useful.

Bye,
bearophile

Re: Is the world coming to an end?

[KennyTM~]

On Apr 3, 11 08:30, Michel Fortin wrote:

On 2011-04-02 19:58:25 -0400, Walter Bright 
said:


On 4/2/2011 4:11 PM, Michel Fortin wrote:

It's funny that D (the language) has binary notation built-in (which
C doesn't
have) but no octal notation anymore (which C has).


The problem with the octal literals is, as has been often complained
about, people getting surprised by it. I've never heard of anyone
being surprised by the binary or hex literals.


Indeed. Isn't that a good argument for implementing octal literals the
same way as binary and hex literals?



You now have to resort to a
library template for that,


I think it's a feature, not a "resort", that library templates can do
this well. I think it's far better than C++0x's user defined literals,
for example.


I disagree that it's better. With C++ user defined literals the user
doesn't have to find by himself whether the number fits within the range
of a regular integer literal and if not fall back to using a string as
the template argument instead.



This is a problem but as I'd test it's a non-issue. Running a Google 
code search on   [^.'"-]\b0[0-7]{7,}[ulUL]*\b -0{8,}   shows only two 
instances of real (i.e. not used for testing the format function) usage 
of long (> 7 digits) octal literals in the first few pages:


0360l  in Android's OpenSSL (this is 0x_L)
0777L  in Apache's ASF (this is 0x1__L)

Both of them fit inside 2^^63 as decimal digits for octal!(), and both 
of them could better be represented as hex if ported.



I don't think it's much worse, but I fail to see how it could be better.



Avoiding needing to create another kind of literal?




and it doesn't work for big numbers: try
assert(octal!17 == 0x___). Not
that I expect
anyone to want to write big 64-bit numbers in octal, but it makes the
new
"official" octal notation more like a hack.


If you use octal!"17" it will work correctly.
You're right in that the decimal literal being "converted" to octal is
a bit of a hack.

The octal!17 will fail at compile time with an
integer overflow, it never gets to the runtime assert.


Which makes me wonder, what does the compiler suggests in the error
message when it encounters 017 ? I suspect it
doesn't add the necessary quotes, does it?



There's no quotes, and there should be, but the extra cost for this 
branch may not worth it (the lower limit of quotes depends on whether it 
is a long/unsigned literal).



The new syntax is certainly usable, it's just inelegant and hackish. Its
your language, it's your choice, and I'll admit it won't affect me much.

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 5:34 PM, KennyTM~ wrote:

On Apr 3, 11 07:52, Walter Bright wrote:

On 4/2/2011 3:58 PM, KennyTM~ wrote:

1. this message is specific to the dmd front-end. Other lexers might
not show this message


Appropriate and informative error messages are properly
quality-of-implementation issues. As the dmd source shows, doing this
message is trivial.



DMD recognizes the octal literal then rejects it later. Ideally the lexer should
not accept 0\d{2,} at all.


That's for backwards compatibility.


Yes. I mean Tango for D2 (if it will be finished?)


I hope that Tango for D2 will not have gratuitous incompatibilities.

Re: Python-indentation (Was: Re: Is the world coming to an end?)

[bearophile]

> > PS I don't want to say every of Python's decisions is wrong. Many of them  
> > are great (but defenitely not significant intendation).

There's a large difference between Python and D design process: Python devs 
discuss ideas about possible designs, even for days, and then the most 
preferred one is chosen. Only in uncommon cases, when there is no consensus, 
Guido chooses (like in the "X if P else Y" syntax). This, and the care they 
give to that process (they believe that good syntax matters), produce a 
language that's very well designed (despite some flaws).

Bye,
bearophile

Re: Is the world coming to an end?

[bearophile]

Michel Fortin:

> The new syntax is certainly usable, it's just inelegant and hackish. 
> Its your language, it's your choice, and I'll admit it won't affect me 
> much.

My suggestions for Walter are:
- To turn 01 .. 07 too into errors;
- to deprecate the octal! Phobos template.
- To introduce the 0o leading that works from 0o0 to the uint.max;
- To change the new error message, so it suggests to use 0o.
- To ask opinions to the community here next time before changing things in 
D2/D3 :-)

Bye,
bearophile

deprecation of "complex" floating point types

[Francisco Almeida]

Are there plans to deprecate the built-in complex types soon?

Re: Is the world coming to an end?

[Francisco Almeida]

== Quote from Daniel Gibson (metalcae...@gmail.com)'s article

> > I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?
> No, it's a template, so it's evaluated at compile-time and doesn't impact
> (runtime) performance.

If there is no runtime performance penalty, then it's fine.

> > Granted, the 0123 syntax was error prone and we're all glad it's gone, but
aren't there better alternatives such as 0o123 or 0q123, for example?
> >
> How often do you use octal numbers?

Good point.

Re: Is the world coming to an end?

[Michel Fortin]

On 2011-04-02 19:58:25 -0400, Walter Bright  said:


On 4/2/2011 4:11 PM, Michel Fortin wrote:

It's funny that D (the language) has binary notation built-in (which C doesn't
have) but no octal notation anymore (which C has).


The problem with the octal literals is, as has been often complained 
about, people getting surprised by it. I've never heard of anyone being 
surprised by the binary or hex literals.


Indeed. Isn't that a good argument for implementing octal literals the 
same way as binary and hex literals?




You now have to resort to a
library template for that,


I think it's a feature, not a "resort", that library templates can do 
this well. I think it's far better than C++0x's user defined literals, 
for example.


I disagree that it's better. With C++ user defined literals the user 
doesn't have to find by himself whether the number fits within the 
range of a regular integer literal and if not fall back to using a 
string as the template argument instead.


I don't think it's much worse, but I fail to see how it could be better.



and it doesn't work for big numbers: try
assert(octal!17 == 0x___). Not that 
I expect

anyone to want to write big 64-bit numbers in octal, but it makes the new
"official" octal notation more like a hack.


If you use octal!"17" it will work correctly. 
You're right in that the decimal literal being "converted" to octal is 
a bit of a hack.


The octal!17 will fail at compile time with an 
integer overflow, it never gets to the runtime assert.


Which makes me wonder, what does the compiler suggests in the error 
message when it encounters 017 ? I suspect it 
doesn't add the necessary quotes, does it?


The new syntax is certainly usable, it's just inelegant and hackish. 
Its your language, it's your choice, and I'll admit it won't affect me 
much.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Is the world coming to an end?

[KennyTM~]

On Apr 3, 11 07:52, Walter Bright wrote:

On 4/2/2011 3:58 PM, KennyTM~ wrote:

1. this message is specific to the dmd front-end. Other lexers might
not show this message


Appropriate and informative error messages are properly
quality-of-implementation issues. As the dmd source shows, doing this
message is trivial.



DMD recognizes the octal literal then rejects it later. Ideally the 
lexer should not accept 0\d{2,} at all.



2. this assumes std.conv.octal exists, though it may not be the case
(e.g. using Tango without Phobos (well Tango devs could add just
std.conv.octal)).


This change will not migrate to D1.


Yes. I mean Tango for D2 (if it will be finished?)

Anyway the above aren't really big problems. I don't expect newbies know 
octal literals :).

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 02:23, schrieb Francisco Almeida:
> Walter Bright Wrote:
> 
>> On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:
>>> As I wrote, I think it's great that 010 != 8 anymore.
>>
>> 010, etc., will now be errors. They will not be 10 decimal.
>>
>> Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 
>> 08, 
>> 09, etc. will of course be errors.
> 
> This doesn't feel right, though. Either you permit leading numbers with 
> leading zeroes to be read as decimals, or you forbid them unless they are 
> 0x... or 0b... .

I agree.

> 
> I am concerned about the choice of relegating a kind of number literal to a 
> library template. Doesn't this needlessly impact performance?

No, it's a template, so it's evaluated at compile-time and doesn't impact
(runtime) performance.

> 
> Granted, the 0123 syntax was error prone and we're all glad it's gone, but 
> aren't there better alternatives such as 0o123 or 0q123, for example?
> 

How often do you use octal numbers?

Asynchronicity and more

[Fawzi Mohamed]

There are several difficult issues connected with asynchronicity, high  
performace networking and connected things.
I had to deal with them developing blip ( http://fawzi.github.com/ 
blip ).
My goal with it was to have a good basis for my program dchem, and as  
consequence is not so optimized in particular for non recursive tasks,  
and it is D1, but I think that the issues are generally relevant.


i/o and asynchronicity is a very important aspect and one that will  
tend to "pollute" many parts of the library, and introduce  
dependencies that are difficult to remove thus those choices have to  
be done carefully.


Overview:


Threads vs fibers:
---

* an issue not yet brought up is that thread wire some memory, and so  
have an extra cost that fibers don't.
* evaluation strategy of fibers can be chosen by the user, this is  
relevant for recursive tasks where each task
  spawns other tasks, different strategies (breadth first evaluation  
like threads uses a *lot* more resources
  than depth first, by having many more tasks concurrently in  
evaluation)


Otherwise the relevant points already  brought forth by others are:

- context switch of fibers (assuming that memory is active) is much  
faster
- context switch are chosen by the user in fibers (cooperative  
multitasking), this allows
  one to choose the optima point to switch, but a "bad" fibers can  
ruin the response time the others.
- d is not stackless (like Go for example), so each fiber needs to  
have enough space for the stack
  (something that often is not so easy to predict). This makes fiber  
still a bit costly if one really needs a lot of them.
  64 bit can help here, because hopefully the active part is small,  
and it can be kept in RAM, even using a rather
  large virtual space. Still as correctly said by Brad for heavily  
uniform handling of many tasks manual
  management (and using stateless functions as much as possible) can  
be much more efficient.


Closures

When possible and for the low level (often used) operations delegates  
and functions calls are a better solution than , structs and manual  
memory handling for "closures" are a good choice for low level  
operations, because one can avoid the heap allocation connected with  
the automatic closure.
This approach cannot be avoided in D1, whereas D2 has the very useful  
closures, but at low level their cost should be avoided when possible.
About using structs there are subtle issues that I think are connected  
with optimization of the compiler (I never really investigated them, I  
always changed the code, or resorted to heap allocation.
The main issue is that one would like to optimize as much as possible,  
and to do it it normally assumes that the current thread is the only  
user of the stack. If you pass stack stored structures to other  
threads these assumptions aren't true anymore, so the memory of a  
stack allocated struct might be reused even before the function  
returns (unless I am mistaken and the ABI forbids it, in this case  
tell me).


Async i/o
--

* almost always i/o is much slower than CPU, so an i/o operation is  
bound to make the cpu wait, so one wants to use the wait efficiently.
  - A very simple way is to just use blocking i/o, and just have  
other threads do other threads.

  - async i/o allows overlap of several operations in a single thread.
  - for files an even more efficient way to communicate sharing of  
the buffer with the kernel (aio_*)
  - an important issue is avoiding waste of cpu cycles while waiting,  
to achieve this one can collect several waiting operations and use a  
single thread to wait on several of them, select, poll and epoll allow  
this, and increase the efficiency of several kinds of programs
  - libev and libevent are cross platform libraries that can help  
having an event based approach, taking care to check a large number of  
events and call a user defined callback when they happen in a robust  
cross platform way


locks, semaphores

to synchronize between threads locks and semaphores are a standard way  
to synchronize.
One has to be careful to mix them with fiber scheduling with locks, as  
one can easily deadlock.


Hardware informationy
-
Efficient usage of computational resource depends also on being able  
to identify the available hardware.
Don did quite some hacking to get useful information out of cpuinfo,  
but if one is interested in more complex computers more info would be  
nice.

I use hwloc for this purpose, it is cross plattform, can be embedded.

Possible solutions
==

Having async i/o can be presented as normal synchronous (blocking) i/ 
o, but this makes sense only if one has several objects waiting, or  
uses fibers, and executes other fiber while waiting.
How acceptable it is to rely (and thus introduce a dependency on)  
things like libev or hwloc?
For my purposes using them was ok, 

Re: Is the world coming to an end?

[Francisco Almeida]

Walter Bright Wrote:

> On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:
> > As I wrote, I think it's great that 010 != 8 anymore.
> 
> 010, etc., will now be errors. They will not be 10 decimal.
> 
> Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 
> 08, 
> 09, etc. will of course be errors.

This doesn't feel right, though. Either you permit leading numbers with leading 
zeroes to be read as decimals, or you forbid them unless they are 0x... or 
0b... .

I am concerned about the choice of relegating a kind of number literal to a 
library template. Doesn't this needlessly impact performance?

Granted, the 0123 syntax was error prone and we're all glad it's gone, but 
aren't there better alternatives such as 0o123 or 0q123, for example?

Re: Is the world coming to an end?

[bearophile]

Walter:

> The point is that "octal!" is not a syntax. It's completely a library 
> construction.

It seems I use the word "syntax" in a different way, for me it means any way to 
express a semantics. I will be more careful with my wording.

Bye,
bearophile

Re: Is the world coming to an end?

[Adam D. Ruppe]

Walter Bright wrote:
> You're right in that the decimal literal being "converted"
> to octal is a bit of a hack.

Yeah, but it's a no-win scenario.

Without it, people would bitch and moan that they have to put
quotes around little numbers like permission masks.

With it, people bitch and moan that its a hack, probably without
ever actually using it.

Re: Is the world coming to an end?

[bearophile]

Walter:

> Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 
> 08, 
> 09, etc. will of course be errors.

Isn't this a corner case of the general rule? (corner cases are bad).

Bye,
bearophile

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 4:11 PM, Michel Fortin wrote:

It's funny that D (the language) has binary notation built-in (which C doesn't
have) but no octal notation anymore (which C has).


The problem with the octal literals is, as has been often complained about, 
people getting surprised by it. I've never heard of anyone being surprised by 
the binary or hex literals.



You now have to resort to a
library template for that,


I think it's a feature, not a "resort", that library templates can do this well. 
I think it's far better than C++0x's user defined literals, for example.



and it doesn't work for big numbers: try
assert(octal!17 == 0x___). Not that I expect
anyone to want to write big 64-bit numbers in octal, but it makes the new
"official" octal notation more like a hack.


If you use octal!"17" it will work correctly. You're right 
in that the decimal literal being "converted" to octal is a bit of a hack.


The octal!17 will fail at compile time with an integer 
overflow, it never gets to the runtime assert.

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:

As I wrote, I think it's great that 010 != 8 anymore.


010, etc., will now be errors. They will not be 10 decimal.

Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 08, 
09, etc. will of course be errors.

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 3:58 PM, KennyTM~ wrote:

1. this message is specific to the dmd front-end. Other lexers might
not show this message


Appropriate and informative error messages are properly 
quality-of-implementation issues. As the dmd source shows, doing this message is 
trivial.



2. this assumes std.conv.octal exists, though it may not be the case
(e.g. using Tango without Phobos (well Tango devs could add just
std.conv.octal)).


This change will not migrate to D1.

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 01:50, schrieb Walter Bright:
> On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:
>> As I wrote, I think it's great that 010 != 8 anymore.
> 
> 010, etc., will now be errors. They will not be 10 decimal.
> 
> Also, the literals 00, 01, ..., 07 will still be accepted without complaint. 
> 08,
> 09, etc. will of course be errors.

That feels pretty inconsistent.

Cheers,
- Daniel

Re: Is the world coming to an end?

[bearophile]

Andrei:

> Although past discussions made it clear that most everyone found leading 
> 0 a poor convention for octal numbers, now not only the consensus is 
> weaker,

The consensus was as much strong as now that the leading zero to denote octals 
is bad. But even in past some people (like me) have suggested more than one 
replacement syntax (see Bugzilla). So I am seeing nothing new in the 
discussions of today.


> If that were chosen, then all of a sudden octal!777 would have become 
> suddenly sexy and so on.

You have no proof of this.

By the way, I am happy of this (unannounced) change.

Bye,
bearophile

Re: Is the world coming to an end?

[Walter Bright]

On 4/2/2011 2:38 PM, bearophile wrote:

Andrej Mitrovic:


If I didn't know it better I would think it's still April 1st. :D


I don't like the "octal!" a lot, I prefer a syntax like the Python3 one



The point is that "octal!" is not a syntax. It's completely a library 
construction.

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 01:20, schrieb Andrei Alexandrescu:
> On 4/2/11 5:27 PM, ulrik.mikaels...@gmail.com wrote:
>> A D-newbie would probably be able to guess 0o for octal, but hardly
>> octal!. octal! breaks the rule of least surprise.
> 
> I fail to infer how using the word "octal" for an octal literal is surprising 
> at
> all.
> 
> This thread is a good example that it's impossible to please everyone. 
> Although
> past discussions made it clear that most everyone found leading 0 a poor
> convention for octal numbers, now not only the consensus is weaker, but some
> actually claim a different solution is superior. If that were chosen, then all
> of a sudden octal!777 would have become suddenly sexy and so on.
> 
> The grass is always greener on the other side...
> 
> 
> Andrei

I don't think the consensus that a leading 0 is a poor convention for octal
numbers is weaker now - so far nobody wants the old syntax back :)

Re: Is the world coming to an end?

[Andrei Alexandrescu]

On 4/2/11 5:27 PM, ulrik.mikaels...@gmail.com wrote:

A D-newbie would probably be able to guess 0o for octal, but hardly
octal!. octal! breaks the rule of least surprise.


I fail to infer how using the word "octal" for an octal literal is 
surprising at all.


This thread is a good example that it's impossible to please everyone. 
Although past discussions made it clear that most everyone found leading 
0 a poor convention for octal numbers, now not only the consensus is 
weaker, but some actually claim a different solution is superior. If 
that were chosen, then all of a sudden octal!777 would have become 
suddenly sexy and so on.


The grass is always greener on the other side...


Andrei

Re: Python-indentation (Was: Re: Is the world coming to an end?)

[ulrik . mikaelsson]

PS I don't want to say every of Python's decisions is wrong. Many of them  
are great (but defenitely not significant intendation).
On a side-note, I thought the same, until I realised I hate redundancies  
even more than I hated forced code-styles. And code-indentation AND  
brackets are clearly redundant, since they pretty much convey the same  
information "block", only one is structural and the other visual.


Nowadays, my complaint on Python-indentation are that they aren't fully  
enforcing a STRICT policy on indentation. Mixed-code indentation in 3d-part  
can cause a lot of unexpected bugs.



Personally, I'd like to see a world where "plain old text" (whatever that  
means, considering all the related encoding and line-ending-problems  
constantly biting us multi-platform non-ASCII-people in the behind) were  
replaced with something just slightly higher-level, such as semantic trees.  
For programming, the notion would be to, instead of storing "text", storing  
the AST of the parsed code, letting the editor render the tree to the  
user's preferences, to create true separation between information (the  
structural code) and visualization (the readable code).


If a standardized format for the serialized tree was used, VCS:es could use  
it to record changes not as "lines changed", but changes in the AST.  
Name-changes would not change entire lines, but just the references to that  
symbol. Wrapping a block of code into an "if-statement" could clearly be  
visualized, instead of appearing like a big chunk of code were COMPLETELY  
rewritten (when in reality it was just indented.)


For other tree structured formats, if nothing else, efficient standardized  
tree-representation could significantly boost performance of some  
protocols. (XML, I'm looking at you)


I know, it's not going to happen, but one can dream?

Re: Is the world coming to an end?

[Michel Fortin]

On 2011-04-02 18:27:12 -0400, ulrik.mikaels...@gmail.com said:


011 = 11
0b11 = 3
0x11 = 17
0o11 = 9

is much more consistent than

011 = 11
0b11 = 3
0x11 = 17
octal!11 = 9


I too would prefer 0o11 for consistency.

It's funny that D (the language) has binary notation built-in (which C 
doesn't have) but no octal notation anymore (which C has). You now have 
to resort to a library template for that, and it doesn't work for big 
numbers: try assert(octal!17 == 
0x___). Not that I expect anyone to want to write big 
64-bit numbers in octal, but it makes the new "official" octal notation 
more like a hack.


But it's a good thing that the old error-prone octal notation is 
deprecated. So overall I think the change is positive, I just find the 
replacement a little too hackish.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 00:58, schrieb KennyTM~:
> On Apr 3, 11 06:49, KennyTM~ wrote:
>> On Apr 3, 11 06:27, ulrik.mikaels...@gmail.com wrote:
>>> A D-newbie would probably be able to guess 0o for octal, but hardly
>>> octal!. octal! breaks the rule of least surprise.
>>
>> Except a big error
>>
>> octal literals 011 are deprecated, use std.conv.octal!11 instead
>>
>> will be emitted when the said newbie tries to compile with 011 :). See
>> commit
>> https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932
>>
>>
> 
> But of course
> 
>  1. this message is specific to the dmd front-end. Other lexers might
> not show this message
>  2. this assumes std.conv.octal exists, though it may not be the case
> (e.g. using Tango without Phobos (well Tango devs could add just
> std.conv.octal)).

If Tango is ever ported to D2 it should be possible to use Phobos and Tango at
the same time (thanks to druntime), so that shouldn't be an issue, right?

Re: Is the world coming to an end?

[KennyTM~]

On Apr 3, 11 06:49, KennyTM~ wrote:

On Apr 3, 11 06:27, ulrik.mikaels...@gmail.com wrote:

A D-newbie would probably be able to guess 0o for octal, but hardly
octal!. octal! breaks the rule of least surprise.


Except a big error

octal literals 011 are deprecated, use std.conv.octal!11 instead

will be emitted when the said newbie tries to compile with 011 :). See
commit
https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932



But of course

 1. this message is specific to the dmd front-end. Other lexers might
not show this message
 2. this assumes std.conv.octal exists, though it may not be the case
(e.g. using Tango without Phobos (well Tango devs could add just
std.conv.octal)).

Re: Is the world coming to an end?

[KennyTM~]

On Apr 3, 11 06:27, ulrik.mikaels...@gmail.com wrote:

A D-newbie would probably be able to guess 0o for octal, but hardly
octal!. octal! breaks the rule of least surprise.


Except a big error

octal literals 011 are deprecated, use std.conv.octal!11 instead

will be emitted when the said newbie tries to compile with 011 :). See 
commit 
https://github.com/D-Programming-Language/dmd/commit/87afe713711060ec73942d1a94d3e28024781932

Re: Re: Is the world coming to an end?

[Andrej Mitrovic]

Guessing is a bad game. A newbie should take a look in the manuals,
which is where octal should be described.

Re: Re: Is the world coming to an end?

[ulrik . mikaelsson]

0b and 0x are not "dangerous" so there's no need to remove/deprecate them  
and



thus cause breakage of code using them.


At least 0x is quite common (certainly more common than octal numbers) so  
it



makes sense to have this short syntax (IMHO).



As I wrote, I think it's great that 010 != 8 anymore.

I just think that 0o10 would be more consistent with 0x and 0b. Obviously  
the framework is there for parsing the literals, and AFAIK, 0o isn't  
accepted today so no code would be broken.


011 = 11
0b11 = 3
0x11 = 17
0o11 = 9

is much more consistent than

011 = 11
0b11 = 3
0x11 = 17
octal!11 = 9

A D-newbie would probably be able to guess 0o for octal, but hardly octal!.  
octal! breaks the rule of least surprise.


In any case, everything is better than 011 = 9

Re: Re: Is the world coming to an end?

[Adam D. Ruppe]

ulrik.mikaelsson
> I too was just about to ask why on earth "octal!" instead of 0o
> (and I didn't know about Python3).

octal! was written early last year IIRC, when changes to the language
weren't yet on the table.

Re: Is the world coming to an end?

[Daniel Gibson]

Am 03.04.2011 00:00, schrieb ulrik.mikaels...@gmail.com:
> About time someone dropped the 0777-nonsense. The least common digit-base 
> should
> not easily be invoked "by accident".
> 
> However:
> 
> 
>> I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but
>> Walter never stops moving himself forward :-)
> 
> I too was just about to ask why on earth "octal!" instead of 0o (and I didn't
> know about Python3).
> 
> Sure, I think it's nice and clean language-wise to implement it as a
> template-function, but if so the same should go for 0b and 0x? Are they too
> deprecated in D2?
> 

0b and 0x are not "dangerous" so there's no need to remove/deprecate them and
thus cause breakage of code using them.
At least 0x is quite common (certainly more common than octal numbers) so it
makes sense to have this short syntax (IMHO).

Cheers,
- Daniel

Re: Is the world coming to an end?

[bearophile]

Daniel Gibson:

> In general octal numbers are rarely needed (I guess), so the somehow clumsy
> octal!123 syntax doesn't matter. Also it's more readable (self-documenting) 
> for
> someone not used to octal numbers than Python3's 0o123.

I agree.

Bye,
bearophile

Re: Re: Is the world coming to an end?

[ulrik . mikaelsson]

About time someone dropped the 0777-nonsense. The least common digit-base  
should not easily be invoked "by accident".


However:


I don't like the "octal!" a lot, I prefer a syntax like the Python3 one,  
but Walter never stops moving himself forward :-)


I too was just about to ask why on earth "octal!" instead of 0o (and I  
didn't know about Python3).


Sure, I think it's nice and clean language-wise to implement it as a  
template-function, but if so the same should go for 0b and 0x? Are they too  
deprecated in D2?

Re: Is the world coming to an end?

[Daniel Gibson]

Am 02.04.2011 23:38, schrieb bearophile:
> Andrej Mitrovic:
> 
>> If I didn't know it better I would think it's still April 1st. :D
> 
> I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, 

Come on: the C-style octal syntax is bad (see [1]) and can lead to strange bugs,
so it's a huge win that it's finally killed, even if you don't like the new
syntax :-)
In general octal numbers are rarely needed (I guess), so the somehow clumsy
octal!123 syntax doesn't matter. Also it's more readable (self-documenting) for
someone not used to octal numbers than Python3's 0o123.

Also congratulations to spir, I guess his "0nnn octal notation considered
harmful" thread[1] was a good argument for this step :-)


Cheers,
- Daniel

[1]
http://www.digitalmars.com/d/archives/digitalmars/D/0nnn_octal_notation_considered_harmful_129416.html

Re: Is the world coming to an end?

[Mafi]

Am 02.04.2011 23:38, schrieb bearophile:

Andrej Mitrovic:


If I didn't know it better I would think it's still April 1st. :D


I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but 
Walter never stops moving himself forward :-)

Bye,
bearophile


No ofence, but I sometimes get the opinion that you think something is 
better just because there's "Python" written on it.
But sure, syntaxes are a matter of taste and people shouldn't dispute 
about tastes.


Mafi

PS I don't want to say every of Python's decisions is wrong. Many of 
them are great (but defenitely not significant intendation).

Re: Is the world coming to an end?

[bearophile]

Andrej Mitrovic:

> If I didn't know it better I would think it's still April 1st. :D

I don't like the "octal!" a lot, I prefer a syntax like the Python3 one, but 
Walter never stops moving himself forward :-)

Bye,
bearophile

Re: Review of std.net.isemail part 2

[Jonathan M Davis]

On 2011-04-02 09:26, Jacob Carlborg wrote:
> On 2011-04-01 11:01, Jonathan M Davis wrote:
> > On 2011-03-29 14:06, Jacob Carlborg wrote:
> >> I've made a few minor changes:
> >> 
> >> * Renamed EmailStatusCode.Off ->  None and On ->  Any
> >> * Added and clarified the documentation for EmailStatusCode.Any and None
> >> * Updated the documentation
> >> 
> >> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
> >> Docs: http://dl.dropbox.com/u/18386187/isemail.html
> > 
> > Shouldn't isEmail have a template constraint which verifies that the
> > e-mail variable is a valid string type? Also, it would probably be
> > better to use Char instead of T for the type. It's clearer that way. I
> > believe that that's what std.string does.
> 
> That's a good idea.

I'd say that pretty much every template should have a template constraint on 
it. I'm not sure that I've ever seen a template which was flexible enough that 
it would compile with anything you gave it, and if there's an argument that 
you can give it which won't compile with it, it should fail the template 
constraints, otherwise the error messags are much harder to understand and 
track down.

> > I'd strongly consider making EmailStatus' public member variables private
> > with getter properties (no setters obviously, since they're const),
> > since you can't even assign to a const struct, and that could be
> > annoying. For instance, you can't really put them in an array very well.
> > By making them only have getter properties, you get the same effect but
> > can still put the struct in arrays or reassign it if you need to. const
> > member variables in classes isn't such a big deal, but I'm disinclined
> > to use them in structs due to the issues that they cause.
> 
> Ok, didn't think about that.
> 
> > I'd be inclined to make EmailStatus' constructor private. I'm not sure
> > that it makes any sense for it to be public. Why would anyone create one
> > rather than using isEmail to create it?
> 
> I guess you're right.
> 
> > You should probably add a note to the documentation that the DNS check
> > hasn't been implemented yet.
> 
> Yes.
> 
> > It would probably be a good idea to create a free function which takes an
> > EmailStatusCode and returns the status string, move the logic in the
> > status function to there, and have it call the new function. That way,
> > if a program needed to know what the actual string was without having an
> > e-mail with that particular error, it could get at the string.
> 
> Is this really necessary? Would you ever have the status code without
> the EmailStatus?

In most cases, no. However, I can easily believe that a fancier program would 
care. For instance, anything which wanted to list the various e-mail status 
codes and their associated strings would need to have the list of 
EmailStatusCodes and their associated strings.

I don't doubt that few programs will care. But it would be so simple to make 
it possible to get a string and from its corresponding status code without 
having an EmailStatus, that I see no reason to not make it possible to do so. 
It makes the module more flexible, and I expect that if the module is used 
enough, then a program at some point will want that capability.

> > If you're going to mention a version number, you might want to make it
> > clearer what the code is based on, since from Phobos' perspective, the
> > version number makes no sense. It _does_ make sense to say that it's
> > based on version X of library Y but not that the module itself is
> > version X - especially when that version is 3+, and it's brand-new.
> 
> Yeah, I kind of most of that text as is.
> 
> > Nitpicks:
> > 
> > You have tabs and trailing space in the file. You shouldn't have either.
> > And even if we wanted tabs, they were used inconsistently.
> 
> Forgot about converting the tabs to spaces? How can I easily find
> trailing spaces?

We have only been using spaces in Phobos - no tabs - and I don't expect that 
to change, so code in Phobos shouldn't have tabs in it. Mixing tabs and spaces 
tends to ruin formatting and cause problems. And trailing spaces are just 
wasted characters.

Personally, I have vim set up to always highlight any tabs as well as trailing 
whitespace, so I notice it immediately - which is why I noticed in this case.

Typically, there's a way to get code editors to show extra whitespace and/or 
remove it when saving the file. They also typically have a way to convert tabs 
to spaces. How that works depends in your editor though depends on your 
editor.

If you're using vim, then :retab would turn the tabs into spaces and the 
command :s/\s\+$// will remove all trailing whitespace (and presumably that 
can be converted into an appropriate sed command, but I'm not well-versed in 
sed).

> > Why did you create aliases for front, back, and popFront? That's a really
> > odd thing to do and makes the code harder to understand. I would have
> > considered that to fall in the "useless

Re: GSoC - Question about "XML Processing" Project.

[Andrei Alexandrescu]

On 4/2/11 11:32 AM, Omar El-Mohandes wrote:

Hello there,

My name is Omar , I am a student and would like ask a question about XML
Processing Project to make sure that I understand it well:

* The library will be implemented in D , right ? and Is there any
  way so I can design and implement the algorithms in C or C++ , I
  believe they are the fastest languages ever!


I am now writing my proposal in this project and it will be great if I
can show my ideas with you. :)
Looking to hearing from you all , and work with you as well.

Regards,
Omar


Hi Omar,


Thanks for your interest. You could design and implement in C or C++ and 
then link the resulting functions with D. However, this is likely to 
impede ability to interface seamlessly with D and to create additional 
hoops for anyone who wants to use your library.


All of this is unnecessary. It is well understood that D offers you the 
same control that C and C++ do; for a given backend the code generated 
is equally efficient. I infer that you are just starting with D, so I 
suggest you familiarize with it a fair amount more before submitting an 
application.


Hurry - deadline is April 8.


Andrei

Re: Is the world coming to an end?

[Aleksandar Ružičić]

Nice to see awkward octal literal syntax being removed from Phobos! :)

On Sat, Apr 2, 2011 at 10:16 PM, Andrej Mitrovic  wrote:
> https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
> https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7
>
> If I didn't know it better I would think it's still April 1st. :D
>

Is the world coming to an end?

[Andrej Mitrovic]

https://github.com/D-Programming-Language/phobos/commit/83f99df573c089cc186ef370cb691c2f8a25c873
https://github.com/D-Programming-Language/phobos/commit/88904f7795a94b23e750e10a2addc90783089de7

If I didn't know it better I would think it's still April 1st. :D

[GSOC] Database API draft proposal

[Christian Manning]

Hello all,

This is my first draft proposal for a Database API for Google Summer Of 
Code. I have never written a document such as this so any and all 
feedback is welcome.


Thanks
-

Synopsis

An API for databases is a common component of many languages' standard 
library, though Phobos currently lacks this. This project will remedy 
this by providing such an API and also begin to utilise it with 
interfaces for some Database Management Systems (DBMS). I believe this 
will benefit the D community greatly and will help bring attention and 
developers to the language.


Details
---
This project takes influence from the Java Database Connectivity API 
(JDBC), the Python Database API v2 and other similar interfaces. The 
idea is that any database interface created for use with D will follow 
the API so that the only thing to change is the database back-end being 
used. This will make working with databases in D a much easier experience.


I plan to have several interfaces in a database module which are then 
implemented for specific DBMSs.

For example:

module database;

interface Connection {
//method definitions for connecting to databases go here.
}

Then in an implementation of MySQL for example:

module mysql;

import database;

class Connect : Connection {
//implement defined methods tailoring to MySQL.
}

What goes in to these interfaces will be decided in conjunction with the 
D community so that there is minimal conflict and it will benefit as 
many circumstances as possible. I believe this to be the best route to 
take as I cannot speak for everyone who will be using this.


Using the API created I plan to create an example implementation, 
initially wrapping around the MySQL C API. This will be a good starting 
point for this project and more can be created, time permitting.


About Me

My name is Christian Manning and I am a second year undergraduate 
studying Computer Science at De Montfort University.
I've become interested in D over time after reading about it several 
years ago. I got myself "The D Programming Language" and went from 
there. Although I've not done anything useful in D as I've learnt mainly 
C and Java and am unable to use D for my university projects, I think 
I'm capable of achieving the goals of this project.

Re: GSoC: Containers and Ranges

[Christian Hotz-Behofsits]

Thanks! This is a really good link!

--closed--
2011/4/2 Torarin :
> 2011/4/2 Christian Hotz-Behofsits :
>> Hi everyone!
>>
>> I applied to GSoC 2011 to enhance D's container landscape.  For that
>> reason I read a lot about D and it's given containers, because I used
>> it once, but not quite extensive and there is one "speciality" I don't
>> understand yet - ranges. All in all the documentation is really good,
>> but I wasn't able to find adequate descriptions or suitable examples -
>> Can you help me ?
>>
>> Are ranges only conjugate parts of the given container? Or like the
>> C++ iterators? Are there comparable structs in other languages?
>>
>> even if I don't get the chance - I take it serious :-)
>>
>
> If you haven't read it already, I recommend Andrei Alexandrescu's
> great article introducing ranges:
> http://www.informit.com/articles/article.aspx?p=1407357
>
> Torarin
>

Re: Dream package management system (Was: a cabal for D ?)

[Jacob Carlborg]

On 2011-04-01 20:44, Bruno Medeiros wrote:

On 19/03/2011 14:36, Jacob Carlborg wrote:

On 2011-03-18 18:04, Chris Manning wrote:

On 17/03/2011 22:49, Jason E. Aten wrote:

Somewhat tongue in cheek, we could call it dabal.

As in, "get on dabal!" :-)


If D gets accepted for Google Summer of Code, I think this would be a
great idea for a project and I would be interested in implementing it as
a student. Although, it does seem overly ambitious so maybe only some of
this could be for the gsoc (and if I do this It'd be great to carry on
working on it anyway).

What does everybody think about this? Should I draw up a proposal of
some kind?

Chris


I've been thinking for quite some time to build a package management
system for D, lets call it dpac as an example. This is the ideas that I
have:

Basically copy how RubyGems works.
Use Ruby as a DSL for dpacsepc files which is used to create to create
the dpac file. This is an example for how a file used to build a package
could look like:

name "Foo Bar"
summary "This is the Foo Bar package"
version "1.0.0"
type :lib
author "Jacob Carlborg"
files ["lib.d"] # list of the files in the package
build :make # other options could be :dsss :cmake and so on
dversion 2 # D1 or D2



Copying Rubygems would be a bad idea, or at least a very incomplete one.
And the example code above shows why, doesn't anyone else see it?
Just look at the line:
build :make # other options could be :dsss :cmake and so on
Basicly, this would be a D package manager that requires another package
manager to build D artifacts... kinda not very useful, right? If we skip
the issue of building D artifacts (executables, dynamic libraries,
static libraries, etc.) we skip one essential aspect of a D
package/build management system (if not the main aspect, but that is
debatable...). This is why I think just copying/cloning a PM from
interpreted languages is not helping us much.


I don't think it's the package manger's job to build the 
application/library. The package manager operates on a level higher than 
a build tool. The build tool is working with files, tracking 
dependencies among files and building applications/libraries. The 
package manager is working with packages, tracking dependencies among 
packages.


I was planning to creating my own build tool that would be integrated 
with the package manager. The package manager would use the build tool 
to track the files making up the package. But other build tool would be 
supported as well, not forcing anyone to use my build tool.


--
/Jacob Carlborg

Re: GSoC: Containers and Ranges

[Torarin]

2011/4/2 Christian Hotz-Behofsits :
> Hi everyone!
>
> I applied to GSoC 2011 to enhance D's container landscape.  For that
> reason I read a lot about D and it's given containers, because I used
> it once, but not quite extensive and there is one "speciality" I don't
> understand yet - ranges. All in all the documentation is really good,
> but I wasn't able to find adequate descriptions or suitable examples -
> Can you help me ?
>
> Are ranges only conjugate parts of the given container? Or like the
> C++ iterators? Are there comparable structs in other languages?
>
> even if I don't get the chance - I take it serious :-)
>

If you haven't read it already, I recommend Andrei Alexandrescu's
great article introducing ranges:
http://www.informit.com/articles/article.aspx?p=1407357

Torarin

GSoC: Containers and Ranges

[Christian Hotz-Behofsits]

Hi everyone!

I applied to GSoC 2011 to enhance D's container landscape.  For that
reason I read a lot about D and it's given containers, because I used
it once, but not quite extensive and there is one "speciality" I don't
understand yet - ranges. All in all the documentation is really good,
but I wasn't able to find adequate descriptions or suitable examples -
Can you help me ?

Are ranges only conjugate parts of the given container? Or like the
C++ iterators? Are there comparable structs in other languages?

even if I don't get the chance - I take it serious :-)

I know this page (but it wasn't helpful):
http://d-programming-language.org/phobos/std_container.html#Range

GSoC - Question about "XML Processing" Project.

[Omar El-Mohandes]

Hello there,

My name is Omar , I am a student and would like ask a question about XML
Processing Project to make sure that I understand it well:

   - The library will be implemented in D , right ? and Is there any way so
   I can design and implement the algorithms in C or C++ , I believe they are
   the fastest languages ever!


I am now writing my proposal in this project and it will be great if I can
show my ideas with you. :)
Looking to hearing from you all , and work with you as well.

Regards,
Omar

Re: Review of std.net.isemail part 2

[Jacob Carlborg]

On 2011-04-01 11:01, Jonathan M Davis wrote:

On 2011-03-29 14:06, Jacob Carlborg wrote:

I've made a few minor changes:

* Renamed EmailStatusCode.Off ->  None and On ->  Any
* Added and clarified the documentation for EmailStatusCode.Any and None
* Updated the documentation

Github: https://github.com/jacob-carlborg/phobos/tree/isemail
Docs: http://dl.dropbox.com/u/18386187/isemail.html


Shouldn't isEmail have a template constraint which verifies that the e-mail
variable is a valid string type? Also, it would probably be better to use Char
instead of T for the type. It's clearer that way. I believe that that's what
std.string does.


That's a good idea.


I'd strongly consider making EmailStatus' public member variables private with
getter properties (no setters obviously, since they're const), since you can't
even assign to a const struct, and that could be annoying. For instance, you
can't really put them in an array very well. By making them only have getter
properties, you get the same effect but can still put the struct in arrays or
reassign it if you need to. const member variables in classes isn't such a big
deal, but I'm disinclined to use them in structs due to the issues that they
cause.


Ok, didn't think about that.


I'd be inclined to make EmailStatus' constructor private. I'm not sure that it
makes any sense for it to be public. Why would anyone create one rather than
using isEmail to create it?


I guess you're right.


You should probably add a note to the documentation that the DNS check hasn't
been implemented yet.


Yes.


It would probably be a good idea to create a free function which takes an
EmailStatusCode and returns the status string, move the logic in the status
function to there, and have it call the new function. That way, if a program
needed to know what the actual string was without having an e-mail with that
particular error, it could get at the string.


Is this really necessary? Would you ever have the status code without 
the EmailStatus?



If you're going to mention a version number, you might want to make it clearer
what the code is based on, since from Phobos' perspective, the version number
makes no sense. It _does_ make sense to say that it's based on version X of
library Y but not that the module itself is version X - especially when that
version is 3+, and it's brand-new.


Yeah, I kind of most of that text as is.


Nitpicks:

You have tabs and trailing space in the file. You shouldn't have either. And
even if we wanted tabs, they were used inconsistently.


Forgot about converting the tabs to spaces? How can I easily find 
trailing spaces?



Why did you create aliases for front, back, and popFront? That's a really odd
thing to do and makes the code harder to understand. I would have considered
that to fall in the "useless alias" category and best to be avoided.


I like those names better and though it wouldn't matter all the much 
since they're private.



As stated before, all of your enums seem to start with a capital letter when
the typical thing to do in Phobos at this point is to start with a lowercase
letter.


Yes, didn't know what the naming convention were for enum members when I 
started.



It would be nice if isEmail were broken up given its size, but it does seem
like the sort of function which wouldn't break up very easily. The most
obvious way to do that would be to create separate functions for each case
statement, but given all of the variables involved, that wouldn't work very
well. About the only sane way that I could think of doing that would be to
create class or struct which held all of the logic and had all of those local
variables as member variables. Then each of the cases could be broken up into
separate functions. It would probably be declared internal to isEmail, and
isEmail would construct one and then get the result out of it. That would
allow you to break up the function. However, I'm not at all convinced that
that would really be a better solution. It does seem a bit convoluted to do
that just to break the function up. If it really helped the function's
readability and maintainability then it would be worth it, but it might make
it worse. So, I don't really like the size of the function, and that's a way
that you could break it up, but unless you really think that that's a good
idea, I'd just leave it as is. It's the sort of function that's generally
stuck being long.


I agree with you, it's far too big but I don't know how I could break it 
up. It would be a lot easier if I've written the function myself but 
it's just a port of a PHP function.



Overall, it looks pretty good. And as long as it works, it should be fine
other than the few API issues that I mentioned, and they're not exactly
enormous issues.


Thanks.


- Jonathan M Davis



--
/Jacob Carlborg

Re: A few thoughts on the existing GSoC student proposals

[Christian Manning]

On 01/04/2011 21:14, Piotr Szturmaj wrote:

So, here it is :)

Code:
http://github.com/pszturmaj/ddb

Documentation:
http://pszturmaj.github.com/ddb/db.html
http://pszturmaj.github.com/ddb/postgres.html

Some things are unfinished yet.


This is some great stuff and will definitely be a massive help!

Thanks

Re: [GSOC idea] enhance regular expressions?

[Peter Chadwick]

Dmitry Olshansky  writes:

> On 31.03.2011 22:16, petevi...@yahoo.com.au wrote:
>> Dmitry Olshansky  writes:
>>> --- somewhat informal draft ---
>>>
>> Hi Dmitry,
>>
>> It's good to know that there is interest in improving regular
>> expressions in the D standard library. I've run into a number of
>> problems using std.regex myself, so I'm keen so see either fixes for
>> std.regex or an improved replacement.
> Thanks for the interest.
> Indeed there are problems, though the engine itself is quite capable
> and optimized, I think it could be fixed.

Great.

>> I've been working on a regular expression library myself based around
>> Russ Cox article at http://swtch.com/~rsc/regexp/regexp2.html and the
>> std.regex range interface. It includes a backtracking and Thompson
>> engine. If you are interested it is on github:
>>
>> https://github.com/PeteChadwick/pcregexeng
>>
>> The ddoc documentation is here:
>> http://petechadwick.github.com/pcregexeng/
>>
> Wow, I'll definitely look into it.
> Overall it seems solid even though incomplete. From glance it seems
> that parsing a pattern is somewhat convulted, but I'll defer any
> critics or decisions until I looked in closer detail.

I'm open to any criticisms or suggestions you may have.

> I see you also using the test from std.regex, sadly it's somewhat
> broken (the one with test vectors).
> All it's checking proves that *there is a match*, not *what* was matched.

You're right. I'm now updating the the code to make use of the other
info in the test vectors for more reliable tests.

> Anyway, I'm gathering what I have in a way of fixes as my first pull
> request, wish me luck ;)

Good luck! I look forward to seeing your work.

Re: aman bansal has invited you to open a Google mail account

[Walter Bright]

On 4/2/2011 1:40 AM, aman bansal wrote:

Here's an invitation to create an account.


Please do not spam the n.g.

Re: aman bansal has invited you to open a Google mail account

[Jonathan M Davis]

On 2011-04-02 01:40, aman bansal wrote:
> I've been using Gmail and thought you might like to try it out. Here's an
> invitation to create an account.
> 
> 
>   You're Invited to Gmail!
> 
> aman bansal has invited you to open a Gmail account.
> 
> Gmail is Google's free email service, built on the idea that email can be
> intuitive, efficient, and fun. Gmail has:
> 
>  *Less spam*
> Keep unwanted messages out of your inbox with Google's innovative
> technology.
> 
> *Lots of space*
> Enough storage so that you'll never have to delete another message.
> 
> *Built-in chat*
> Text or video chat with aman bansal and other friends in real time.
> 
> *Mobile access*
> Get your email anywhere with Gmail on your mobile phone.
> 
> You can even import your contacts and email from Yahoo!, Hotmail, AOL, or
> any other web mail or POP accounts.
> 
> Once you create your account, aman bansal will be notified of your new
> Gmail address so you can stay in touch. Learn
> moreor get
> started PPk-SnRrjGCY> !
> Sign
> up SnRrjGCY>
> 
> Google Inc. | 1600 Ampitheatre Parkway | Mountain View, California 94043

And why are you sending this to the D newsgroup? That seems a bit odd.

Personally, I got sick of how poorly gmail handled mailing lists and switched 
to gmx.com, but gmail does have its advantages for other stuff. It's not 
really my cup of tea though.

- Jonathan M Davis

aman bansal has invited you to open a Google mail account

[aman bansal]

I've been using Gmail and thought you might like to try it out. Here's an
invitation to create an account.


  You're Invited to Gmail!

aman bansal has invited you to open a Gmail account.

Gmail is Google's free email service, built on the idea that email can be
intuitive, efficient, and fun. Gmail has:

 *Less spam*
Keep unwanted messages out of your inbox with Google's innovative
technology.

*Lots of space*
Enough storage so that you'll never have to delete another message.

*Built-in chat*
Text or video chat with aman bansal and other friends in real time.

*Mobile access*
Get your email anywhere with Gmail on your mobile phone.

You can even import your contacts and email from Yahoo!, Hotmail, AOL, or
any other web mail or POP accounts.

Once you create your account, aman bansal will be notified of your new Gmail
address so you can stay in touch. Learn
moreor get
started
!
Sign 
up

Google Inc. | 1600 Ampitheatre Parkway | Mountain View, California 94043

image processing in D

[aman bansal]

i was trying to chalk out a strategy to go for image processing in D.the
closest reference i found was in the implementation of python imaging
library.it has modules for imaging,and input output of jpeg and bmp file
formats.the data structures used also are quite accurate.i would like to ask
developers what can be the possible problems in implementing image i/o in D
on the lines of python imaging library.

-- 
aman bansal

namaban...@gmail.com
usit.a...@aol.in

Re: D grammar overhaul

[Rainer Schuetze]

Before going into details with the grammar, I'd like to clarify one 
thing regarding the lexer, that also has some influence on the grammar:

Do we want to allow spaces and comments between these tokens?

- ! in
- ! is
- extern ( C ++ )
- @ Property (safe, trusted, disable, etc)

here is some example code which also shows an ambiguity introduced by 
combining these from seperate tokens:


extern(C
//
++) void foo();

@ /* comment inside
property */ safe int bar() { return 0; }

void main()
{
int[int] a;
struct S { int x; }
S s;
int b;

if (1 ! /* still an infix operator? */ in a) {}
if (null ! /* still an infix operator? */ is null) {}

//	if (s.x !in a) {} /* does not compile: 
http://d.puremagic.com/issues/show_bug.cgi?id=5785 */

if (b !in a) {} // but this compiles!?
}



Trass3r wrote:

Original discussion forked in the D grammar thread, so I'm opening a new one 
for this specific issue.
The D grammar is in dire need of an overhaul.

I suggest we discuss changes here and then put everything into github to issue 
a pull request once everything's done.
I already forked the d-programming-language.org repo to get started by fixing 
some mistakes. Hereafter I list some issues that come to my mind.

Re: Fawzi Mohamed has been accepted as a GSoC 2011 mentor for Digital Mars

[Fawzi Mohamed]

On 1-apr-11, at 20:13, Walter Bright wrote:


On 4/1/2011 10:29 AM, Andrei Alexandrescu wrote:
Fawzi Mohamed from Humboldt University has been accepted as a  
mentor for the
Google Summer of Code 2011 program for Digital Mars. He is  
particularly
interested in topics related to concurrency, parallelism, and  
garbage collection.


Great! Congrats, Fawzi!


thanks, I am clearly happy about this, looking forward to mentor a  
project, and making D even better :)


Fawzi