date:20110403

On Sat, 2011-04-02 at 16:47 -0700, Walter Bright wrote:

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

So remove 0b... and 0x... as well such that the compiler only knows
about decimal.  The point here is not the removal of the C-style octal
notation, everyone agrees that it was and remains a bad idea, the
problem is the inconsistency of treatment of binary and hexadecimal
compared to octal.

-- 
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: Is the world coming to an end?

On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:

> 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.

What is the use for binary literals or hexadecimal literals, I can't
think of one.

Except perhaps specification of register save masks and control status
work literals -- which is of course where the octal stuff came from in
the first place in C and when the VAX replaced PDP, hexadecimal was
rapidly introduced. (*)

I would suggest that rather than discriminating against people who like
octal instead of decimal or hexadecimal, the solution of introducing
0o... in harmony with 0b... and 0x... -- and of course removing the
leading 0 octal literal convention -- is obviously the right solution.
It ticks all the boxes.

(*)  For anyone not immediately in the know here PDP had 8 registers and
VAX 16 so octal and hexadecimal were the natural bases for specifying
masks.  The 68000 also played a part.  The use of octal on the PDP
actually goes a lot deeper than this, cf. Unibus,  but it is all ancient
history now.

-- 
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: Is the world coming to an end?

On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
> 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.

The problem is not that it is a poor solution in isolation, it is the
conflict between 0b... and 0x.. versus octal!...  Why is octal being
discriminated against compared to binary and hexadecimal?

-- 
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: Is the world coming to an end?

On Sat, 2011-04-02 at 21:16 -0500, Andrei Alexandrescu wrote:
[ . . . ]
> 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.

The same goes for 0b... 0x... so why aren't they being removed in favour
of library based solution?

Despite Walters claim that inconsistency is not a bad thing, evidence
indicates that from the psychology community that consistency and
affordance is a very good thing for usability.  

-- 
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: Is the world coming to an end?

"Andrej Mitrovic"  wrote in message 
news:in8060$lt3$1...@digitalmars.com...
> 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

Yea! I stumbled onto that, too. IIRC, I let out a rather audible "Whoohoo!" 
:)

Re: Is the world coming to an end?

On Sat, 2011-04-02 at 21:16 -0500, Andrei Alexandrescu wrote:
[ . . . ]
>> 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.
>
>The same goes for 0b... 0x... so why aren't they being removed in favour
>of library based solution?

Because unlike the octal syntax, those are neither error-prone nor 
barely-useful. I agree that consistency is good, but I think it's far 
outweighed in this case by those other concerns.

Re: Is the world coming to an end?

"Michel Fortin"  wrote in message 
news:in8f9e$1h45$1...@digitalmars.com...
> 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?
>

Octal is never really needed or used for anything but unix file permissions, 
so I really don't think it matters at all if it happens to be inconsistent.

>>
>> 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.
>

C++'s user defined literals sound like a lexing nightmare to me.

Re: Is the world coming to an end?

"Russel Winder"  wrote in message 
news:mailman.3055.1301814881.4748.digitalmar...@puremagic.com...
>On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:
>> 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.
>
>The problem is not that it is a poor solution in isolation, it is the
>conflict between 0b... and 0x.. versus octal!...  Why is octal being
>discriminated against compared to binary and hexadecimal?
>

To be perfectly blunt, it's because octal...well, sucks. It's useless 
compared to binary and hex and just isn't really deserving of a special 
notation anyway. Even more so since the rare uses of it are possible in D 
without it being part of the language. Binary and hex, OTOH, are useful (I 
use hex very frequently. And I would get a lot of use out of binary if I 
actually had time to do low-level work like I used to).

That said, I woudn't have a problem with 0o... being used instead (Although 
I'd actually prefer 0c...). But I have a hard time understanding why people 
are making such a big deal out of something that practically no one ever 
uses anyway. Consistency is nice, sure, but when it's such a trival 
corner-case as octal: Why even care? This isn't the color of the bikeshed, 
this is the *shade* of color on the underside of the trim on a window that's 
one foot off the ground and completely blocked by a big tree.

Re: Is the world coming to an end?

"Daniel Gibson"  wrote in message 
news:in8jko$knb$7...@digitalmars.com...
> 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 ;)
>

Yea, but I bet people would also complain if it were disallowed. "There's no 
ambiguity here! Why's it whining about something that's obviously guaranteed 
to work?!"

Re: Is the world coming to an end?

On Sun, 2011-04-03 at 04:05 -0400, Nick Sabalausky wrote:
[ . . . ]
> >The same goes for 0b... 0x... so why aren't they being removed in favour
> >of library based solution?
> 
> Because unlike the octal syntax, those are neither error-prone nor 
> barely-useful. I agree that consistency is good, but I think it's far 
> outweighed in this case by those other concerns.

Your argument rests on the octal representation being like 0777, a
notation that everyone has already agreed needs removing.  The
introduction of 0o777 for octal increases consistency without
introducing error proneness.  This is just win--win.

There is no consistent language design argument that supports have 0b...
and 0x... but not 0o... -- requiring the use of octal! from the library
when hex! and binary! are not the standard forms.

In the end this is Walter's decision, I'd just prefer him not to get it
wrong.

-- 
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: Is the world coming to an end?


On 4/3/2011 12:12 AM, Russel Winder wrote:

On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:


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.


What is the use for binary literals or hexadecimal literals, I can't
think of one.

Except perhaps specification of register save masks and control status
work literals -- which is of course where the octal stuff came from in
the first place in C and when the VAX replaced PDP, hexadecimal was
rapidly introduced. (*)


I still prefer binary for that. It takes me a senior moment or two to remember 
what bit pattern 0xB is, for example.




I would suggest that rather than discriminating against people who like
octal


The phrase "discriminating against people" has a lot of emotional baggage 
associated with it that is irrelevant to this.




instead of decimal or hexadecimal, the solution of introducing
0o... in harmony with 0b... and 0x... -- and of course removing the
leading 0 octal literal convention -- is obviously the right solution.
It ticks all the boxes.


Except the box of a kitchen sink of features of marginal utility. A feature that 
can be handled adequately by the library should not be part of the core language.


And yes, you can make a reasonable case that 0b should be ditched for the same 
reason.

Re: Is the world coming to an end?


On 4/3/2011 12:00 AM, Russel Winder wrote:

On Sat, 2011-04-02 at 16:47 -0700, Walter Bright wrote:


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


So remove 0b... and 0x... as well such that the compiler only knows
about decimal.  The point here is not the removal of the C-style octal
notation, everyone agrees that it was and remains a bad idea, the
problem is the inconsistency of treatment of binary and hexadecimal
compared to octal.



The 0x notation is heavily used, and so justifies a custom syntax for it. Octal 
is pretty much never used outside of setting file permission masks.


Much as I like PDP-10's and PDP-11's, they are dead and gone.

Re: Is the world coming to an end?

"bearophile"  wrote in message 
news:in8dfe$1e32$1...@digitalmars.com...
> 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).
>

"(corner cases are bad)"

So is stealing, but no one ever bitches if you pick up a penny off the 
ground. Yea, it's a corner case, but it's trivial enough not to actually 
matter. Guaranteed, people would bitch the other way too, so it's "dammed if 
we do, dammed if we don't" anyway.

Re: Is the world coming to an end?

"Walter Bright"  wrote in message 
news:in9c9h$134t$1...@digitalmars.com...
> On 4/3/2011 12:12 AM, Russel Winder wrote:
>> On Sat, 2011-04-02 at 18:36 -0700, Walter Bright wrote:
>>
>>> 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.
>>
>> What is the use for binary literals or hexadecimal literals, I can't
>> think of one.
>>
>> Except perhaps specification of register save masks and control status
>> work literals -- which is of course where the octal stuff came from in
>> the first place in C and when the VAX replaced PDP, hexadecimal was
>> rapidly introduced. (*)
>
> I still prefer binary for that. It takes me a senior moment or two to 
> remember what bit pattern 0xB is, for example.
>

Somtimes I have to wonder if I'm much older than I think I am. I'm exactly 
the same way as you with "moment or two to remember what bit pattern 0xB is, 
for example", and if I'm getting senior moments in my late 20's then 
something is very very wrong ;)

Re: Is the world coming to an end?


On 4/3/2011 12:20 AM, Russel Winder wrote:

Despite Walters claim that inconsistency is not a bad thing, evidence
indicates that from the psychology community that consistency and
affordance is a very good thing for usability.



I meant that inconsistency is not *necessarily* a bad thing.

Successful programming languages are remarkably inconsistent, because people 
like them that way. Completely consistent languages tend to be failures.


Obviously, there's a judgment call about what's a bad inconsistency and what's a 
good inconsistency. A programming language is a mass of principles that pretty 
much all conflict with each other. The art is, for each conflict, deciding which 
principle should matter for that particular case.


Ok, I won't drag out my hoary airplane design analogy this time, but have you 
ever designed a house? It's nothing but conflicting requirements. There is no 
consistency. In fact, as any architect will tell you, a consistent design 
actually looks wrong! Look no further than the Parthenon, which doesn't have a 
straight line anywhere in it, even though it looks straight.

Re: Is the world coming to an end?


On 4/3/2011 1:54 AM, Nick Sabalausky wrote:

Somtimes I have to wonder if I'm much older than I think I am. I'm exactly
the same way as you with "moment or two to remember what bit pattern 0xB is,
for example", and if I'm getting senior moments in my late 20's then
something is very very wrong ;)


You should be fine as long as you're not tying an onion to your belt!

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

 wrote in message 
news:mailman.3049.1301786442.4748.digitalmar...@puremagic.com...
>> 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.
>

My main objection to Python's indentation was always: It *doesn't* enforce 
*anything*. It makes *assumptions*. (Plus, I like to leave temporary 
debugging code unindented so it's easy to spot. And easy to remove before 
comitting.)

...But now I've simplified my stance on Python's indentation to: I'm very 
allergic to it. (Easier to say, and I don't end up needed to defend it ;) )

>
> 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?
>

Yea, I've sometimes felt the same way. There's a program out there called 
JetBrains MPS that's sort of similar to that. It's interesting as a 
proof-of-concept, but it's so rediculously slow and bloated it makes a 
fully-loaded Eclipse seem as quick and lean as windows notepad (Just 
creating a new project took about half-an-hour, IIRC. 'Course, I'm on a 
32-bit single-core, but even still...) Been awhile since I tried it though, 
maybe it's gotten better since then.

Re: Is the world coming to an end?


On 4/3/2011 1:46 AM, Russel Winder wrote:

In the end this is Walter's decision, I'd just prefer him not to get it
wrong.


At some point, one has to take a leap of faith. Only time will tell if it was 
the right decision or not.


Or if (in this particular case) it's just a bikeshed color and simply does not 
matter.

Re: Is the world coming to an end?


On Apr 3, 11 09:44, Daniel Gibson wrote:

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


No need to be surprised, people are already complaining languages 
supporting the 0nnn notation that why 08, 09 does not compile. :)


e.g.

08 in Python 2: 
http://stackoverflow.com/questions/336181/python-invalid-token
09 in Java: 
http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized

Re: Is the world coming to an end?


On Apr 3, 11 07:50, 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.


Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ 
won't? Or is this considered just a DMD extension?

Re: Is the world coming to an end?

2011-04-03 Thread Ulrik Mikaelsson

2011/4/3 Walter Bright :
>
> The 0x notation is heavily used, and so justifies a custom syntax for it.
> Octal is pretty much never used outside of setting file permission masks.

The thing is, since you already have 0x and 0b, 0o would not be much
of a "custom syntax". It would simply be an "extrapolation of the
rule". It follows the already set pattern for non 10-base literals.

Regarding the "but it's so uncommon"-argument, there are 23 characters
left for the "0"-notation, there isn't exactly an
allocation-problem.

> A feature that can be handled adequately by the library should not be part of 
> the core language.
If you're looking for uncommonly used language-features that could
easily be otherwise solved, go ahead and remove asm instead. I'll
guess it's about as uncommon as octal literals (or maybe even more),
have simple other solution (just compile it separately and link), and
has much greater impact on the language and the compiler.

I simply don't buy the "uncommon" argument, when it's such a minuscule
thing in the language, following an already established
framework/pattern.

> The phrase "discriminating against people" has a lot of emotional baggage 
> associated with it that is irrelevant to this.
Walter, you can make the decisions you see fit, you are the BDFL, but
please don't dismiss peoples feelings like this. It will only hinder D
longevity and growth.

I realize the discussion is over, and the feature has been
implemented. Bitching and moaning now won't change anybodys mind, but
for the record, I think this is a bad design-move, breaking
established patterns. I agree it minuscule and seldom used, so I'm not
going to continue the discussion.

Re: Is the world coming to an end?


On 4/3/2011 2:31 AM, KennyTM~ wrote:

No need to be surprised, people are already complaining languages supporting the
0nnn notation that why 08, 09 does not compile. :)

e.g.

08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
09 in Java:
http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized



I love the answer given: "There is no 9 in octal"

Re: Is the world coming to an end?


On 4/3/2011 2:33 AM, KennyTM~ wrote:

On Apr 3, 11 07:50, 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.


Will it be part of the spec that 0+[0-7] will work, and the rest of 0\d+ won't?
Or is this considered just a DMD extension?


It should be part of the spec.

Re: Is the world coming to an end?


On 04/03/2011 10:37 AM, Nick Sabalausky wrote:

That said, I woudn't have a problem with 0o... being used instead (Although
I'd actually prefer 0c...). But I have a hard time understanding why people
are making such a big deal out of something that practically no one ever
uses anyway. Consistency is nice, sure, but when it's such a trival
corner-case as octal: Why even care? This isn't the color of the bikeshed,
this is the *shade* of color on the underside of the trim on a window that's
one foot off the ground and completely blocked by a big tree.


What I fail to see is the advantage of introducing an exception for octal. 
Either it is left out of the language (including stdlib, possibly having around 
a 3rd party hack for it), or the same pattern is used as for hex and bin.
A point is stating a threshold of usefulness. Seems nearly everyone agrees 
octal is not worth it: then just say bye. If it kept instead because of 
historical reasons (what I guess is the case), then just *fix* the syntax. 
Introducing a feature (an exception) for a nearly useless notion is weird.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Is the world coming to an end?


On 04/03/2011 11:39 AM, Walter Bright wrote:

On 4/3/2011 2:31 AM, KennyTM~ wrote:

No need to be surprised, people are already complaining languages supporting the
0nnn notation that why 08, 09 does not compile. :)

e.g.

08 in Python 2: http://stackoverflow.com/questions/336181/python-invalid-token
09 in Java:
http://stackoverflow.com/questions/970039/09-is-not-recognized-where-as-9-is-recognized




I love the answer given: "There is no 9 in octal"


I love that one: "10 is how many digits you have, whereas 010 is is what you 
get if you don't count your thumbs."


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Review of std.net.isemail part 2

2011-04-03 Thread Jacob Carlborg


On 2011-04-02 23:33, Jonathan M Davis wrote:

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've added a static assert with a custom error message. I think  static 
asserts can give better error messages than template constraints.



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.


Ok, I'll add a function, any idea for a good name?


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).


I think it's easier to work with tabs than spaces so I planned to work 
with tabs and than the last thing I would do before submitting a pull 
request would be to con

Re: Is the world coming to an end?


On 04/03/2011 02:52 AM, 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 :-)


I'm very surprised of this move -- aside the concrete details. What I point out 
here is how far sentiments about what is "obvious" or "correct" can be, for a 
given issue, that most of us considered wrong for the same reason.


When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure 
that (if a move was ever made) either octals would be thrown out of D all 
together for beeing nearly useless, or the syntax would be fixed -- the 
"obvious" "correct" solution if octals remain. While I new about octal!, this 
was so hackish and obviously wrong *for me*, that I did not even imagine one 
second it could become the "official" solution.

I'm certainly not the only one.
Questions of detail, sure, but we all know what the details hide ;-)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: [GSOC] Database API draft proposal


On 04/02/2011 10:03 PM, Christian Manning wrote:


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.
}


I would recommend to use slightly longer names for generic interfaces, eg 
"IConnection" or "DBConnection". Then, authors of libraries / implementations 
for specific DBMS like MySQL can use the shorter ones, eg "Connection", which 
will be all what library clients will see and use. This also avoids the need 
for "lexical hacks" like "Connection" versus "Connect".

What do you think?


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.


I have no idea of the actual size of such an interface design, but I doubt it 
can make you busy for 3 months full time, especially since there are (probably 
good) precedents for other languages. Maybe the example implementation should 
be specified as part of the project?



Denis
--
_
vita es estrany
spir.wikidot.com

Re: Some combinatorics?

2011-04-03 Thread bearophile

dsimcha:

> I need this often enough
> that I'd be interested in having them in Phobos.

Good.


> 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.

I will take a look at the code. In the meantime some comments:
- frequency, scan, flatMap, subranges, separate: good;
- tmap: this is the default semantics map should have, in my opinion;
- unfold: nice, but maybe a bit too much hard to understand for nonfunctional 
programmers;
- comp, setComp: I'd like a built in syntax instead of this. In my dlibs1 I 
have select() that has a different syntax;
- select: I am not sure, maybe this is this better in the array module;
- first, second: maybe good, but I suggest to add a leading "s" to their names;
- combinations: good, but the name has to change;
- permutations: I prefer my version;
- choose: good, but with name change;
- consumer: too much complex to use;

This stuff is good to have in Phobos. But I was thinking about some more 
combinatorics.


> 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).

The runtime version is needed. The compile time is surely a different version, 
and it's probably less needed. So I suggest to add the runtime version only, 
and then add the compile time version later if needed.


> 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.

Most of those things from dranges are fit in std.range (or std.algorithm?), or 
a little module that they publicly import, as you say. But if enough 
combinatorics stuff is added, then maybe a std.combinatorics module will be 
better.

If Andrei is OK with this then I will probably create a patch for std.range.

See you later,
bearophile

Re: image processing in D


On 2-apr-11, at 10:40, aman bansal wrote:

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.


As I told you via email

there are two main things, one is reading/writing several formats, I  
would say that you should support at least one standard (simple)  
format natively (the simplest would be netpbm format) but then you  
could rely on libraries to support more.
Use of external libraries should be discussed with others also,  
because one should rely only on libraries that are widely available,  
cross-platform and with acceptable licensing.


About the image processing itself you probably want to have a simple  
flat representation of the image (as 2d array), and then be able to  
apply several operations on it.
General convolution is probably something you want to have, masked  
operation might also be very useful.

Not sure about which other operations you want to support.
In D1 as part of blip I have implemented nearest neighbor convolution,  
it could be useful to you.


Not sure which bit depth you want to support, one can build a wrapper  
to access arbitrary bit depth/bitchannel contiguous block of memory as  
1d or 2d array (for example 4channel 12 bit images), this can be  
useful as base type for operations with images that might have an  
extended bit range.


is this for a GSoC project?

anyway about Python Image Library, I think that the high level  
functionality is mostly ok, and probably you can lift some of the C  
part, but lots seems to be a bit python connection specific, not sure  
that it is worth using.
PIL has a BSD style licensing, this might be an issue if you want to  
have it in phobos (Boost).


PIL uses the following libraries:

   JPEG support libjpeg (6a or 6b)
http://www.ijg.org
http://www.ijg.org/files/jpegsrc.v6b.tar.gz
ftp://ftp.uu.net/graphics/jpeg/

   PNG support  zlib (1.2.3 or later is recommended)
http://www.gzip.org/zlib/

   OpenType/TrueTypefreetype2 (2.3.9 or later is recommended)
   support
http://www.freetype.org
http://freetype.sourceforge.net

   CMS support  littleCMS (1.1.5 or later is recommended)
   support
http://www.littlecms.com/

They seem reasonable, so the first step would be to wrap their C  
interface (if not already available, like zlib).
I thought there were some image processing projects in D1, but I  
haven't found them just now.
Still also these libraries licensing, and support should be checked,  
and evaluated also by others.


Fawzi

Re: [GSOC] Database API draft proposal

2011-04-03 Thread Christian Manning


On 03/04/2011 13:10, spir wrote:

On 04/02/2011 10:03 PM, Christian Manning wrote:


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.
}


I would recommend to use slightly longer names for generic interfaces,
eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter ones,
eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?


When I was writing that it really didn't sit well and "DBConnection" in 
particular is a much better way of doing it to reduce some confusion there.



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.


I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?


I'm aware that it wouldn't take 3 months, but I don't know how long it 
will take to have the API agreed upon so that there's a general 
consensus. Another way I could do it is to decide on the API myself and 
begin implementing DBMSs with it and then adapt to the ideas brought 
forth by the community. Then, everyone's happy, just in a different time 
frame. Though, if there are a lot of changes wanted I'd have to change 
all of my implementations depending on how far I am at the time. What do 
you think about that path?


Thanks for the feedback, it's much appreciated :)

Chris

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

2011-04-03 Thread Jacob Carlborg


On 2011-04-03 08:55, Russel Winder wrote:

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?


This might not be fair, because I haven't used Waf, SCons or CMake very 
much, but I think they look too complicated. I would like a simple tool, 
I like dsss/rebuild it's a simple tool. You just put the file containing 
the main function in a configuration file and it just works.



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.


I don't want a tool to compete against SCons, Waf and others. I want a 
simple tool for building D software. I think this is one of the problems 
with the other build tools, that they should be able to handle almost 
every language out there.


--
/Jacob Carlborg

Re: [GSOC] Database API draft proposal

Well the comments in there are what is important, and will need to be  
specified better IMHO.


The most important part in my opinion is how one chooses to represent  
a record.
A big design choice is if the various fields are defined at compile  
time or at runtime.
Also how does one add special behavior to a record? Do you use a  
subclasses of the generic record type (as ruby does for example)?


D2 adds some more method to allow for generic accessors, so one can  
have a dynamic implementation, while still using static accessors.

Maybe one should allow for both dynamic records and static ones.
The efficient storage of results of a db query is an important point.

Are you aware of http://dsource.org/projects/ddbi for D1?

If one wants to have a nice efficient and well tested interface,  
supporting more than one DB then I think that there is enough work to  
do.


Fawzi
On 3-apr-11, at 14:33, Christian Manning wrote:


On 03/04/2011 13:10, spir wrote:

On 04/02/2011 10:03 PM, Christian Manning wrote:

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.
}


I would recommend to use slightly longer names for generic  
interfaces,

eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter  
ones,

eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?


When I was writing that it really didn't sit well and "DBConnection"  
in particular is a much better way of doing it to reduce some  
confusion there.



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.


I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?


I'm aware that it wouldn't take 3 months, but I don't know how long  
it will take to have the API agreed upon so that there's a general  
consensus. Another way I could do it is to decide on the API myself  
and begin implementing DBMSs with it and then adapt to the ideas  
brought forth by the community. Then, everyone's happy, just in a  
different time frame. Though, if there are a lot of changes wanted  
I'd have to change all of my implementations depending on how far I  
am at the time. What do you think about that path?


Thanks for the feedback, it's much appreciated :)

Chris

Re: [GSOC] Database API draft proposal


On 04/03/2011 02:33 PM, Christian Manning wrote:

On 03/04/2011 13:10, spir wrote:

On 04/02/2011 10:03 PM, Christian Manning wrote:


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.
}


I would recommend to use slightly longer names for generic interfaces,
eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter ones,
eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?


When I was writing that it really didn't sit well and "DBConnection" in
particular is a much better way of doing it to reduce some confusion there.


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.


I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?


I'm aware that it wouldn't take 3 months, but I don't know how long it will
take to have the API agreed upon so that there's a general consensus. Another
way I could do it is to decide on the API myself and begin implementing DBMSs
with it and then adapt to the ideas brought forth by the community. Then,
everyone's happy, just in a different time frame. Though, if there are a lot of
changes wanted I'd have to change all of my implementations depending on how
far I am at the time. What do you think about that path?


I would go for the second, especially because there is a Python example 
(probably one of the best languages out there for such design questions). Just 
think at usual qualities: clarity / simplicity / consistency (and currently 
discussed Phobos style guidelines).


Also:
* Implementation example(s) is source of feedback for the interface quality.
* Once you've done it, rewriting the exact same feature with a different design 
can be very fast (esp if the change is only about interface), because you 
master the application.


I personly would appreciate an example for a simpler and/or non-relational, 
DBMS (maybe it's only me) (I'm thinking at key:value like Berkeley DB, object 
DBMS, SQLite...).


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Some combinatorics?

2011-04-03 Thread Philippe Sigaud

David:

> 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.

Hi there,

I was even invited into Phobos by Andrei in August (so, before the Git 
migration). I
intended to cut the more 'Phobos-y' parts of dranges and present them for 
inclusion.
It's just, I was then propelled two levels upwards hierarchically and things 
have been a
bit hectic since then. I don't have any time right now to participate in 
Phobos. If I
ever get some rest, I'll formally knock on the door again.

I still read the D mailing lists with interest (even more so when I see the 
rate at
which bugs are corrected). dranges is Boost licensed specifically to be 
compatible with
Phobos. If anyone is interested in using it in any way (even proposing it for 
Phobos
inclusion), you have my permission.


Philippe

Re: Is the world coming to an end?

2011-04-03 Thread Lutger Blijdestijn

spir wrote:

> On 04/03/2011 02:52 AM, 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 :-)
> 
> I'm very surprised of this move -- aside the concrete details. What I
> point out here is how far sentiments about what is "obvious" or "correct"
> can be, for a given issue, that most of us considered wrong for the same
> reason.
> 
> When I introduced the topic of octal notation 0nnn beeing bad, I was 100%
> sure that (if a move was ever made) either octals would be thrown out of D
> all together for beeing nearly useless, or the syntax would be fixed --
> the "obvious" "correct" solution if octals remain. While I new about
> octal!, this was so hackish and obviously wrong *for me*, that I did not
> even imagine one second it could become the "official" solution.
> I'm certainly not the only one.
> Questions of detail, sure, but we all know what the details hide ;-)
> 
> Denis

I don't understand why it is hackish if it's a pure library approach. (it is 
right?) I find it actually rather nice that D can do this. This is not a 
syntax change, octals are out of the language and the library now has an 
octal template. Where's the problem?

Re: [GSOC] Database API draft proposal


Fawzi Mohamed wrote:

Well the comments in there are what is important, and will need to be
specified better IMHO.

The most important part in my opinion is how one chooses to represent a
record.
A big design choice is if the various fields are defined at compile time
or at runtime.
Also how does one add special behavior to a record? Do you use a
subclasses of the generic record type (as ruby does for example)?


I'm working on DB API for few months in my spare time. I'm delayed that 
much by my other projects. Please take a look at my ideas:


http://github.com/pszturmaj/ddb

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

In my code, row is represented using struct DBRow!(Specs...). Fields may 
be known at compile time or not. DBRow besides base types, may be 
instantiated using structs, tuples or arrays. Untyped row (no compile 
time information) is DBRow!(Variant[]).


Typed rows are very useful, for example you don't need to manually cast 
columns to your types, it's done automatically, e.g.:


auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery!(string, "typName", int, "len");

foreach (row; result)
{
// here, row DBRow subtypes
// a Tuple!(string, "typName", int, "len")
writeln(row.typName, ", ", row.len);
}

What do you think? :)

Re: Review of std.net.isemail part 2


On 4/3/11 6:38 AM, Jacob Carlborg wrote:

On 2011-04-02 23:33, Jonathan M Davis wrote:

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've added a static assert with a custom error message. I think static
asserts can give better error messages than template constraints.


Please use a template constraint. This is the right thing to do and we 
use it throughout Phobos.


Thanks,

Andrei

Re: [GSOC] Database API draft proposal

2011-04-03 Thread Christian Manning


On 03/04/2011 14:42, Piotr Szturmaj wrote:

Fawzi Mohamed wrote:

Well the comments in there are what is important, and will need to be
specified better IMHO.

The most important part in my opinion is how one chooses to represent a
record.
A big design choice is if the various fields are defined at compile time
or at runtime.
Also how does one add special behavior to a record? Do you use a
subclasses of the generic record type (as ruby does for example)?


I'm working on DB API for few months in my spare time. I'm delayed that
much by my other projects. Please take a look at my ideas:

http://github.com/pszturmaj/ddb

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

In my code, row is represented using struct DBRow!(Specs...). Fields may
be known at compile time or not. DBRow besides base types, may be
instantiated using structs, tuples or arrays. Untyped row (no compile
time information) is DBRow!(Variant[]).

Typed rows are very useful, for example you don't need to manually cast
columns to your types, it's done automatically, e.g.:

auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery!(string, "typName", int, "len");

foreach (row; result)
{
// here, row DBRow subtypes
// a Tuple!(string, "typName", int, "len")
writeln(row.typName, ", ", row.len);
}

What do you think? :)


I was going to reply with a link to your work but you beat me to it.
I think it's a great design and incorporating it or something similar 
into the API may be the way to go.

Re: Some combinatorics?


On 4/3/11 8:31 AM, Philippe Sigaud wrote:

David:


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.


Hi there,

I was even invited into Phobos by Andrei in August (so, before the Git 
migration). I
intended to cut the more 'Phobos-y' parts of dranges and present them for 
inclusion.
It's just, I was then propelled two levels upwards hierarchically and things 
have been a
bit hectic since then. I don't have any time right now to participate in 
Phobos. If I
ever get some rest, I'll formally knock on the door again.

I still read the D mailing lists with interest (even more so when I see the 
rate at
which bugs are corrected). dranges is Boost licensed specifically to be 
compatible with
Phobos. If anyone is interested in using it in any way (even proposing it for 
Phobos
inclusion), you have my permission.


Philippe


Congrats. Were you the one working on a simple JSON replacement?

Andrei

Re: [GSOC] Database API draft proposal

2011-04-03 Thread Christian Manning


On 03/04/2011 14:16, spir wrote:

On 04/03/2011 02:33 PM, Christian Manning wrote:

On 03/04/2011 13:10, spir wrote:

On 04/02/2011 10:03 PM, Christian Manning wrote:


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.
}


I would recommend to use slightly longer names for generic interfaces,
eg "IConnection" or "DBConnection". Then, authors of libraries /
implementations for specific DBMS like MySQL can use the shorter ones,
eg "Connection", which will be all what library clients will see and
use. This also avoids the need for "lexical hacks" like "Connection"
versus "Connect".
What do you think?


When I was writing that it really didn't sit well and "DBConnection" in
particular is a much better way of doing it to reduce some confusion
there.


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.


I have no idea of the actual size of such an interface design, but I
doubt it can make you busy for 3 months full time, especially since
there are (probably good) precedents for other languages. Maybe the
example implementation should be specified as part of the project?


I'm aware that it wouldn't take 3 months, but I don't know how long it
will
take to have the API agreed upon so that there's a general consensus.
Another
way I could do it is to decide on the API myself and begin
implementing DBMSs
with it and then adapt to the ideas brought forth by the community. Then,
everyone's happy, just in a different time frame. Though, if there are
a lot of
changes wanted I'd have to change all of my implementations depending
on how
far I am at the time. What do you think about that path?


I would go for the second, especially because there is a Python example
(probably one of the best languages out there for such design
questions). Just think at usual qualities: clarity / simplicity /
consistency (and currently discussed Phobos style guidelines).

Also:
* Implementation example(s) is source of feedback for the interface
quality.
* Once you've done it, rewriting the exact same feature with a different
design can be very fast (esp if the change is only about interface),
because you master the application.

I personly would appreciate an example for a simpler and/or
non-relational, DBMS (maybe it's only me) (I'm thinking at key:value
like Berkeley DB, object DBMS, SQLite...).

Denis


SQLite could definitely be on the table. However, I don't want to be 
over-ambitious at this stage and then not complete the project, and all 
advice I've read on applying for GSOC suggests this too. If I could be 
more certain on the time it would take for the API alone, then I would 
propose more.
Would it be suitable to have something like: "If the API is not in a 
good state by xx/xx/2011 then y implementation will not be undertaken" ?

Re: Some combinatorics?

2011-04-03 Thread Philippe Sigaud

On Sun, Apr 3, 2011 at 15:55, Andrei Alexandrescu
 wrote:
>
> Congrats. Were you the one working on a simple JSON replacement?

Hmm, no. My interests were in ranges, algorithms and template stuff.

Re: deprecation of "complex" floating point types

2011-04-03 Thread Francisco Almeida

== Quote from Moritz Warning (moritzwarn...@web.de)'s article
> 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.

I thought that the implementation of std.complex was already adequate?

Re: [GSOC] Database API draft proposal


On 3-apr-11, at 15:59, Christian Manning wrote:


On 03/04/2011 14:42, Piotr Szturmaj wrote:

Fawzi Mohamed wrote:
Well the comments in there are what is important, and will need to  
be

specified better IMHO.

The most important part in my opinion is how one chooses to  
represent a

record.
A big design choice is if the various fields are defined at  
compile time

or at runtime.
Also how does one add special behavior to a record? Do you use a
subclasses of the generic record type (as ruby does for example)?


I'm working on DB API for few months in my spare time. I'm delayed  
that

much by my other projects. Please take a look at my ideas:

http://github.com/pszturmaj/ddb

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

In my code, row is represented using struct DBRow!(Specs...).  
Fields may

be known at compile time or not. DBRow besides base types, may be
instantiated using structs, tuples or arrays. Untyped row (no compile
time information) is DBRow!(Variant[]).

Typed rows are very useful, for example you don't need to manually  
cast

columns to your types, it's done automatically, e.g.:

auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM  
pg_type");

auto result = cmd.executeQuery!(string, "typName", int, "len");

foreach (row; result)
{
// here, row DBRow subtypes
// a Tuple!(string, "typName", int, "len")
writeln(row.typName, ", ", row.len);
}

What do you think? :)


I was going to reply with a link to your work but you beat me to it.
I think it's a great design and incorporating it or something  
similar into the API may be the way to go.


Indeed ddb looks really nice (I hadn't looked at it yet), given it  
though, I have to agree that just adding mySQL support is too little  
and not really innovative for 3 months work...


Fawzi

Re: [GSOC] Database API draft proposal


Christian Manning wrote:

On 03/04/2011 14:42, Piotr Szturmaj wrote:

Fawzi Mohamed wrote:

Well the comments in there are what is important, and will need to be
specified better IMHO.

The most important part in my opinion is how one chooses to represent a
record.
A big design choice is if the various fields are defined at compile time
or at runtime.
Also how does one add special behavior to a record? Do you use a
subclasses of the generic record type (as ruby does for example)?


I'm working on DB API for few months in my spare time. I'm delayed that
much by my other projects. Please take a look at my ideas:

http://github.com/pszturmaj/ddb

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

In my code, row is represented using struct DBRow!(Specs...). Fields may
be known at compile time or not. DBRow besides base types, may be
instantiated using structs, tuples or arrays. Untyped row (no compile
time information) is DBRow!(Variant[]).

Typed rows are very useful, for example you don't need to manually cast
columns to your types, it's done automatically, e.g.:

auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery!(string, "typName", int, "len");

foreach (row; result)
{
// here, row DBRow subtypes
// a Tuple!(string, "typName", int, "len")
writeln(row.typName, ", ", row.len);
}

What do you think? :)


I was going to reply with a link to your work but you beat me to it.
I think it's a great design and incorporating it or something similar
into the API may be the way to go.


Thanks. At this time, you can write an interface for MySQL, SQLite or 
other relational databases, using the same DBRow struct. Naming of 
course may be changed to DataRow, Row or other, depending on the choice 
of community.


In regards of base interfaces like IConnection or (semi-)abstract class 
DBConnection, I think we should have common API for all clients, but 
only to some extent. There are many features available in some database 
servers, while not available in others, for example OIDs (object 
identifiers) are fundamental thing in PostgreSQL, but they simply don't 
exist in MySQL. So, PGCommand would give you information on 
lastInsertedOID, while MySQLCommand would not.
This is also proven in ADO.NET, where each client is rarely used with 
common base interface, because it blocks many of its useful features.


I think base interface should be defined only after some of the most 
popular RDBMS clients are finished. Also interface should be choosen to 
cover the most featured/advanced database client. This is why I started 
with PostgreSQL, as its the most powerful open-source RDBMS. If base 
interface will cover it, it will also cover some less powerful RDBMSes.

Re: [GSOC] Database API draft proposal



On 3-apr-11, at 16:44, Fawzi Mohamed wrote:


On 3-apr-11, at 15:59, Christian Manning wrote:


[...]
I was going to reply with a link to your work but you beat me to it.
I think it's a great design and incorporating it or something  
similar into the API may be the way to go.


Indeed ddb looks really nice (I hadn't looked at it yet), given it  
though, I have to agree that just adding mySQL support is too little  
and not really innovative for 3 months work...


Looking more maybe I was a bit too harsh, if you define clearly the  
goals of your API then yes it might be a good project.
The api doesn't have to be defined yet, but a more detailed definition  
of its goals should be there, maybe with code example of some usages.  
Questions that should be answered:


* support for static and dynamic types.
how access of dynamic and static types differs, should be as little as  
possible, and definitely the access one uses for dynamic types should  
work without changes on static types

* class or struct for row object
* support for table specific classes?
* reference to description of the table (to be able to get also  
dynamic types by column name, but avoid using too much memory for the  
structure)
* Nice to define table structure, and what happens if the db has  
another structure.

* you want to support only access or also db creation and modification?

I feel that these things should be addressed in a complete proposal,  
with possible answers that might be changed later on depending on how  
things actually go.


Fawzi

Re: [GSOC] Database API draft proposal



On 3-apr-11, at 16:52, Piotr Szturmaj wrote:


[...]
Thanks. At this time, you can write an interface for MySQL, SQLite  
or other relational databases, using the same DBRow struct. Naming  
of course may be changed to DataRow, Row or other, depending on the  
choice of community.


In regards of base interfaces like IConnection or (semi-)abstract  
class DBConnection, I think we should have common API for all  
clients, but only to some extent. There are many features available  
in some database servers, while not available in others, for example  
OIDs (object identifiers) are fundamental thing in PostgreSQL, but  
they simply don't exist in MySQL. So, PGCommand would give you  
information on lastInsertedOID, while MySQLCommand would not.
This is also proven in ADO.NET, where each client is rarely used  
with common base interface, because it blocks many of its useful  
features.


I think base interface should be defined only after some of the most  
popular RDBMS clients are finished. Also interface should be choosen  
to cover the most featured/advanced database client. This is why I  
started with PostgreSQL, as its the most powerful open-source RDBMS.  
If base interface will cover it, it will also cover some less  
powerful RDBMSes.


I think that you project looks nice, but see some of the comments in  
my other message.
I would for example consider separating table definition from row  
object, and while your row object is really nice, often one has either  
a single DB model, described in a few model files or goes with a fully  
dynamic model.
In large project one does not/should not, define RowTypes on the fly  
everywhere in the code.
So I would try to improve the way one describes a table, or a full  
database.
Your DBRow type is definitely nice, and is a good starting point, but  
there is definitely more work to do (not that you had said otherwise :).


Fawzi

Re: Is the world coming to an end?


On 4/3/11 6:24 AM, spir wrote:

On 04/03/2011 10:37 AM, Nick Sabalausky wrote:

That said, I woudn't have a problem with 0o... being used instead
(Although
I'd actually prefer 0c...). But I have a hard time understanding why
people
are making such a big deal out of something that practically no one ever
uses anyway. Consistency is nice, sure, but when it's such a trival
corner-case as octal: Why even care? This isn't the color of the
bikeshed,
this is the *shade* of color on the underside of the trim on a window
that's
one foot off the ground and completely blocked by a big tree.


What I fail to see is the advantage of introducing an exception for
octal. Either it is left out of the language (including stdlib, possibly
having around a 3rd party hack for it), or the same pattern is used as
for hex and bin.


Right now octal constants are indeed out of the language.


A point is stating a threshold of usefulness. Seems nearly everyone
agrees octal is not worth it: then just say bye. If it kept instead
because of historical reasons (what I guess is the case), then just
*fix* the syntax. Introducing a feature (an exception) for a nearly
useless notion is weird.


This is not a feature. It is effectively "bye".


Thanks,

Andrei

Re: Is the world coming to an end?


On 4/3/11 4:39 AM, Ulrik Mikaelsson wrote:

2011/4/3 Walter Bright:


The 0x notation is heavily used, and so justifies a custom syntax for it.
Octal is pretty much never used outside of setting file permission masks.


The thing is, since you already have 0x and 0b, 0o would not be much
of a "custom syntax". It would simply be an "extrapolation of the
rule". It follows the already set pattern for non 10-base literals.


It is a custom syntax nevertheless. Worse, that custom syntax does 
nothing for other cases of literals (e.g. lat/long, degrees and minutes 
etc). The best thing about std.conv.octal is that is serves as a 
template (in the general sense of the word) for any custom literals. It 
offers the proverbial fishing rod as opposed to '0o' being the 
proverbial fish.



Regarding the "but it's so uncommon"-argument, there are 23 characters
left for the "0"-notation, there isn't exactly an
allocation-problem.


A feature that can be handled adequately by the library should not be part of 
the core language.

If you're looking for uncommonly used language-features that could
easily be otherwise solved, go ahead and remove asm instead. I'll
guess it's about as uncommon as octal literals (or maybe even more),
have simple other solution (just compile it separately and link), and
has much greater impact on the language and the compiler.

I simply don't buy the "uncommon" argument, when it's such a minuscule
thing in the language, following an already established
framework/pattern.


The phrase "discriminating against people" has a lot of emotional baggage 
associated with it that is irrelevant to this.

Walter, you can make the decisions you see fit, you are the BDFL, but
please don't dismiss peoples feelings like this. It will only hinder D
longevity and growth.

I realize the discussion is over, and the feature has been
implemented. Bitching and moaning now won't change anybodys mind, but
for the record, I think this is a bad design-move, breaking
established patterns. I agree it minuscule and seldom used, so I'm not
going to continue the discussion.


On the contrary, I think it's a very good and significant move in the 
right direction. If it breaks anything, it breaks an inferior approach 
to literals.



Andrei

Re: Review of std.net.isemail part 2

2011-04-03 Thread Robert Jacques

On Sun, 03 Apr 2011 09:49:44 -0400, Andrei Alexandrescu  
 wrote:



On 4/3/11 6:38 AM, Jacob Carlborg wrote:

On 2011-04-02 23:33, Jonathan M Davis wrote:

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've added a static assert with a custom error message. I think static
asserts can give better error messages than template constraints.


Please use a template constraint. This is the right thing to do and we  
use it throughout Phobos.


Thanks,

Andrei


Also, static assert doesn't compose with is(typeof(...)) and  
__traits(compiles,...). (It stops the compiler if it's every evaluated)  
I'd recommend simply putting a string on an empty line over static assert:


static assert(...,"My error message");

static if(...) "My error message";

Re: Some combinatorics?

2011-04-03 Thread Robert Jacques

On Sun, 03 Apr 2011 09:55:54 -0400, Andrei Alexandrescu  
 wrote:



On 4/3/11 8:31 AM, Philippe Sigaud wrote:

David:


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.


Hi there,

I was even invited into Phobos by Andrei in August (so, before the Git  
migration). I
intended to cut the more 'Phobos-y' parts of dranges and present them  
for inclusion.
It's just, I was then propelled two levels upwards hierarchically and  
things have been a
bit hectic since then. I don't have any time right now to participate  
in Phobos. If I

ever get some rest, I'll formally knock on the door again.

I still read the D mailing lists with interest (even more so when I see  
the rate at
which bugs are corrected). dranges is Boost licensed specifically to be  
compatible with
Phobos. If anyone is interested in using it in any way (even proposing  
it for Phobos

inclusion), you have my permission.


Philippe


Congrats. Were you the one working on a simple JSON replacement?

Andrei


I've been working on a JSON replacement.

Re: Is the world coming to an end?

spir wrote:
> What I fail to see is the advantage of introducing an exception for
> octal.

Octal isn't the exception. Of all the infinite number bases out there,
octal is the one done in the most generic way. (In fact, it'd
probably be a reasonably simple change to make it alias base!8 octal;
or something like that)

The exceptions are decimal, hex, and binary. Each one has reasoning:

decimal: that's the way we normally talk and think. We need a
 starting point somewhere, so this is the natural choice.

hex: commonly used and cannot be easily written as a decimal
 literal. Piles upon piles of existing code depend on it.

binary:  Incredibly useful, not easily written as a decimal. The
 case for giving it special treatment isn't as strong as
 hex, but it follows the same reasoning. (Actually, in
 code that I write freshly, I use binary literals more
 often than hex. Like Walter, my brain is slow at making
 masks out of hex.)

Anything can follow the same pattern as octal. Not anything can
be shoved into the language.

Re: Is the world coming to an end?

Walter Bright wrote:
> And yes, you can make a reasonable case that 0b should be ditched
> for the same reason.

I know people already think of the isIntegral versions of octal
as a hack, but I see that as one reason why binary wouldn't work
as well as a template:

binary!___

Overflow city! Such long numbers aren't terribly common in octal,
but they /are/ in binary.

Of course, you can just use the string version, so it isn't a
big deal, but nevertheless, it is a difference.

btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)

And if you actually need that, the string version works just fine.

So all in all I don't think it's worth it.

Re: Is the world coming to an end?


On 4/3/11 2:14 AM, Russel Winder wrote:

On Sat, 2011-04-02 at 18:20 -0500, Andrei Alexandrescu wrote:

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.


The problem is not that it is a poor solution in isolation, it is
the conflict between 0b... and 0x.. versus octal!...  Why is octal
being discriminated against compared to binary and hexadecimal?


It's very simple. You are making a number of fallacious assumptions
which logically lead to a wrong conclusion.

First fallacy is:


What is the use for binary literals or hexadecimal literals, I can't
think of one.


Just looking through std/ yields 1849 lines with 0x in them, of which 
many have several instances on the same line.


The second fallacy is assigning equal weight to every feature or 
potential feature. A language should not be a democracy.


The third fallacy is a unidimensional view of consistency. It's very 
easy to first limit the notion of consistency to only one possible 
dimension, to then show that a lot of stuff is inconsistent. In reality 
there are many dimensions of consistency, and choosing their right 
relative importance is much of the difficulty of language design.


Keeping 0x in the language is consistent with the general similarity of 
D with C, C++, Java, and many others.


Eliminating 0777 from the language is consistent with the notion that 
leading zeros are insignificant in regular decimal notation in math. It 
is also consistent with the desire of preventing subtle mistakes made by 
people who make the math-based assumption.


Adding octal!777 to std.conv is consistent with the notion that there 
still are a few uses for octal constants that are worth a presence in 
the standard library. It is also consistent with the desire to foster 
other user-defined literals defined from the same mold.



Andrei

Re: Is the world coming to an end?


On 4/3/11 3:46 AM, Russel Winder wrote:

On Sun, 2011-04-03 at 04:05 -0400, Nick Sabalausky wrote:
[ . . . ]

The same goes for 0b... 0x... so why aren't they being removed in favour
of library based solution?


Because unlike the octal syntax, those are neither error-prone nor
barely-useful. I agree that consistency is good, but I think it's far
outweighed in this case by those other concerns.


Your argument rests on the octal representation being like 0777, a
notation that everyone has already agreed needs removing.  The
introduction of 0o777 for octal increases consistency without
introducing error proneness.  This is just win--win.


It wins consistency with two other hardwired conventions for 
representing numbers. It is a total loss in helping anything but octal 
constants.



There is no consistent language design argument that supports have 0b...
and 0x... but not 0o... -- requiring the use of octal! from the library
when hex! and binary! are not the standard forms.


0x is too widespread and too often used in C and C++ to gratuitously 
eliminate it. It does not have significant disadvantages. Besides it is 
used fairly often. I agree that 0b could and should be deprecated.



In the end this is Walter's decision, I'd just prefer him not to get it
wrong.


That is appreciated.


Andrei

Re: Some combinatorics?


On 4/3/11 10:50 AM, Robert Jacques wrote:

On Sun, 03 Apr 2011 09:55:54 -0400, Andrei Alexandrescu
 wrote:


On 4/3/11 8:31 AM, Philippe Sigaud wrote:

David:


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.


Hi there,

I was even invited into Phobos by Andrei in August (so, before the
Git migration). I
intended to cut the more 'Phobos-y' parts of dranges and present them
for inclusion.
It's just, I was then propelled two levels upwards hierarchically and
things have been a
bit hectic since then. I don't have any time right now to participate
in Phobos. If I
ever get some rest, I'll formally knock on the door again.

I still read the D mailing lists with interest (even more so when I
see the rate at
which bugs are corrected). dranges is Boost licensed specifically to
be compatible with
Phobos. If anyone is interested in using it in any way (even
proposing it for Phobos
inclusion), you have my permission.


Philippe


Congrats. Were you the one working on a simple JSON replacement?

Andrei


I've been working on a JSON replacement.


Apologies, I had the names mangled.

What is the status of that? Do you think you could use a student's help 
for completing and expanding that work?



Thanks,

Andrei

Re: Is the world coming to an end?

2011-04-03 Thread Michel Fortin


On 2011-04-03 12:04:42 -0400, Adam D. Ruppe  said:


btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)


I've been thinking about the same thing, except instead of having a 
special data type the template would simply take a string:


template binary(string digits) {
...
}

binary!___;
// no error, number "___" passed as a string to the 
template.

But the bigger problem is that it doesn't scale beyond base 10:

template hex(string digits) {
...
}

hex!ABCDEF00;
// isn't ABCDEF00 an identifier?

So it wouldn't bring us much when it comes to parsing different bases, 
even though it could be used for other things.


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

Re: [GSOC] Database API draft proposal


Fawzi Mohamed wrote:

I think that you project looks nice, but see some of the comments in my
other message.
I would for example consider separating table definition from row
object, and while your row object is really nice, often one has either a
single DB model, described in a few model files or goes with a fully
dynamic model.
In large project one does not/should not, define RowTypes on the fly
everywhere in the code.


There's no need to declare all row types. DBRow support both static and 
dynamic models. For dynamic rows, DBRow uses Variant[] as its underlying 
type. This is previous sample code, but changed to use dynamic row:


auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery;

foreach (row; result)
{
// here, row subtypes a Variant[]
writeln(row[0], ", ", row[1]);
}

Btw. I've just updated documentation, so you can take another look :)

Re: Is the world coming to an end?

Ulrik Mikaelsson wrote:
> If you're looking for uncommonly used language-features that could
> easily be otherwise solved, go ahead and remove asm instead. I'll
> guess it's about as uncommon as octal literals (or maybe even more),
> have simple other solution (just compile it separately and link),
> and has much greater impact on the language and the compiler.

Actually, inline asm can't be replaced. If you link it separately,
it won't be inlined...

There's also a huge difficulty change. 010 -> octal!10 is a simple
change. It'd be enormous effort to de-inline assembly, even if
it were actually possible in the first place! Consider asm
in version statements

Also, unlike octal literals, it couldn't be replaced by templates
either; inline asm enables things that are otherwise impossible.
There's simply no way for the language to express many of the
instructions available to you in asm. It's a foundational building
block.

This leads into the commonness too. I don't think I've *ever*
wanted an octal literal. But, assembly is useful in 3/5 of
my programs. Heck, even more, if you count library functions
that use it. (though lib functions could in theory be linked
separately)

Re: Is the world coming to an end?


On Apr 4, 11 00:49, Adam D. Ruppe wrote:

Ulrik Mikaelsson wrote:

If you're looking for uncommonly used language-features that could
easily be otherwise solved, go ahead and remove asm instead. I'll
guess it's about as uncommon as octal literals (or maybe even more),
have simple other solution (just compile it separately and link),
and has much greater impact on the language and the compiler.


Actually, inline asm can't be replaced. If you link it separately,
it won't be inlined...


Talking of asm, would the following be expected to work?

---
import std.conv;
void main() {
asm {
di octal!777;
mov EAX, octal!777;
}
}
---

Re: [GSOC] Database API draft proposal



On 3-apr-11, at 18:37, Piotr Szturmaj wrote:


Fawzi Mohamed wrote:
I think that you project looks nice, but see some of the comments  
in my

other message.
I would for example consider separating table definition from row
object, and while your row object is really nice, often one has  
either a

single DB model, described in a few model files or goes with a fully
dynamic model.
In large project one does not/should not, define RowTypes on the fly
everywhere in the code.


There's no need to declare all row types. DBRow support both static  
and dynamic models. For dynamic rows, DBRow uses Variant[] as its  
underlying type. This is previous sample code, but changed to use  
dynamic row:


auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery;

foreach (row; result)
{
   // here, row subtypes a Variant[]
   writeln(row[0], ", ", row[1]);
}

Btw. I've just updated documentation, so you can take another look :)


Yes I saw that, that is exactly the reason I was telling about  
splitting the table definition in another object, so that also in the  
dynamic case one can use the column names (that normally are known, or  
can be retrieved from the db schema).
That would only add a pointer to each row (to its description), and  
would make it much nicer to use.
Your DBRow is very nice to use, and I like how it can accommodate both  
types, but it degrades too much for dynamic types imho.


Fawzi

Re: Is the world coming to an end?

KennyTM~ wrote:
> Talking of asm, would the following be expected to work?

Maybe. Part of me says "yes, it should be the same as a literal*"
but part of me says no because it's weird to drop a template in
an asm block.

* For example:

enum a = octal!777;
asm {
   mov EAX, a;
}

does indeed work.


But, all in all, I don't think octal! itself in asm should work.
It's not literally a literal.

Re: [GSOC] Database API draft proposal


Fawzi Mohamed wrote:

Looking more maybe I was a bit too harsh, if you define clearly the
goals of your API then yes it might be a good project.
The api doesn't have to be defined yet, but a more detailed definition
of its goals should be there, maybe with code example of some usages.
Questions that should be answered:


I know your response is'nt to me, but please let me answer these 
questions from my point of view, based on my recent work on ddb.



* support for static and dynamic types.
how access of dynamic and static types differs, should be as little as
possible, and definitely the access one uses for dynamic types should
work without changes on static types


If you mean statically or dynamically typed data row then I can say my 
DBRow support both.



* class or struct for row object


I'm using struct, because I think row received from database is a value 
type rather than reference. If one selects rows from one table then yes, 
it is possible to do some referencing based on primary key, but anyway I 
think updates should be done explicitly, because row could be deleted in 
the meantime. In more complex queries, not all of selected rows are 
materialized, i.e. they may be from computed columns, view columns, 
aggregate functions and so on. Allocation overhead is also lower for 
structs.



* support for table specific classes?


Table specific classes may be written by user and somehow wrap 
underlying row type.



* reference to description of the table (to be able to get also dynamic
types by column name, but avoid using too much memory for the structure)


My PostgreSQL client already supports that. Class PGCommand has member 
"fields", which contain information about returned columns. You can even 
check what columns will be returned from a query, before actually 
executing it.



* Nice to define table structure, and what happens if the db has another
structure.


This is a problem for ORM, but at first, we need standard query API.


* you want to support only access or also db creation and modification?


First, I'm preparing base "traditional" API. Then I want to write simple 
object-relational mapping. I've already written some code that generated 
CREATE TABLE for structs at compile time. Static typing of row fields is 
very helpful here.

Re: deprecation of "complex" floating point types

2011-04-03 Thread Lars T. Kyllingstad

On Sun, 03 Apr 2011 14:33:02 +, Francisco Almeida wrote:

> == Quote from Moritz Warning (moritzwarn...@web.de)'s article
>> 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.
> 
> I thought that the implementation of std.complex was already adequate?

It is supposed to be, at least. :)  If it's not, I'd very much like to 
know what's wrong or missing.

-Lars

std.string.indexOf with an optional start-at parameter?

2011-04-03 Thread Aleksandar Ružičić

I needed std.string.indexOf to accept start position in the string to
start the search at. I was really surprised when I realized that this
(to me) standard parameter is "missing" (I'm used to indexOf in
javascript, strpos in php and equivalent methods in other languages,
which support start offset parameter).

There might be some other function (in some other module) that does
what I want but I wasn't able to find it (I find D's documentation not
easy to search and read), so I've copied indexOf to my module and
added wanted functionality:

https://gist.github.com/900589

now, I'm able to write, for example:

auto pos = indexOf(haystack, '$', 10); // will starts search at 11th
char in haystack

and

auto pos = indexOf(haystack, '$', -5); // will starts search at 5th
char from the end

My question is: is there a reason why there is no this functionality
in phobos (maybe there's some language feature I'm not aware of?) and
if no such reason exists, would it be possible to add it in future
version of phobos/dmd?

Re: Is the world coming to an end?

2011-04-03 Thread Lars T. Kyllingstad

On Sun, 03 Apr 2011 11:14:16 -0500, Andrei Alexandrescu wrote:

> I agree that 0b could and should be deprecated.

Ditto.

-Lars

Mixing C/D-style array declarations

2011-04-03 Thread bearophile

After a suggestion from simendsjo in D.learn, I have added an enhancement 
request:
http://d.puremagic.com/issues/show_bug.cgi?id=5807

If you see something wrong in this post I will modify or close the enhancement 
request.

The documentation about Postfix Array Declarations says:

> Rationale: The postfix form matches the way arrays are declared
> in C and C++, and supporting this form provides an easy migration
> path for programmers used to it.<

C style array declarations are handy (despite they add a little of extra 
complexity and confusion to the D language).

But currently (DMD 2.052) D also supports a syntax like:

// array of 5 dynamic arrays of ints.
int[][5] c;
int[] c[5];
int c[5][];

What's the purpose of such mixed syntax?
1) It's not present in C programs;
2) It's not used in normal native D programs;
3) And in my opinion it's not good to use even during the migration from C to D 
style, because it looks confusing (the order of ranges is inverted between C 
and D syntax).

So I suggest to statically disallow such mixed syntax.


Currently the mixed syntax is not just useless and potentially confusing for 
the programmer, it also causes problems with some vector operations:

void main() {
int[] a1 = [1, 2, 3];
int[] a2 = new int[3];
a2[] = a1[];   // OK
int[3] a3[] = a2[];// line 5, Error
}

test.d(5): Error: cannot implicitly convert expression (a2[]) of type int[] to 
int[3u][]

In theory if mixed C/D array declarations become disallowed, then there is only 
one meaning for the operation at line 5. (This is not very nice, but I don't 
see better solutions for this syntax problem with array operations).

Bye,
bearophile

Re: Is the world coming to an end?


On 4/3/2011 9:28 AM, Michel Fortin wrote:

So it wouldn't bring us much when it comes to parsing different bases, even
though it could be used for other things.


That would also get us into the C++0x territory of having "raw" and "cooked" 
tokens, something I really wish to avoid.

Re: [GSOC] Database API draft proposal


Fawzi Mohamed wrote:


On 3-apr-11, at 18:37, Piotr Szturmaj wrote:


Fawzi Mohamed wrote:

I think that you project looks nice, but see some of the comments in my
other message.
I would for example consider separating table definition from row
object, and while your row object is really nice, often one has either a
single DB model, described in a few model files or goes with a fully
dynamic model.
In large project one does not/should not, define RowTypes on the fly
everywhere in the code.


There's no need to declare all row types. DBRow support both static
and dynamic models. For dynamic rows, DBRow uses Variant[] as its
underlying type. This is previous sample code, but changed to use
dynamic row:

auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
auto result = cmd.executeQuery;

foreach (row; result)
{
// here, row subtypes a Variant[]
writeln(row[0], ", ", row[1]);
}

Btw. I've just updated documentation, so you can take another look :)


Yes I saw that, that is exactly the reason I was telling about splitting
the table definition in another object, so that also in the dynamic case
one can use the column names (that normally are known, or can be
retrieved from the db schema).
That would only add a pointer to each row (to its description), and
would make it much nicer to use.
Your DBRow is very nice to use, and I like how it can accommodate both
types, but it degrades too much for dynamic types imho.


Ah, I see what you mean :) This is yet to be done feature :)

I assume you mean something like row["typname"]. Soon, I will add 
support for this.

Re: Is the world coming to an end?


On 4/3/2011 4:24 AM, spir wrote:

Introducing a
feature (an exception) for a nearly useless notion is weird.


The whole point of this is it is not introducing a feature. It's using existing 
features to emulate a feature that is being removed.

Re: Is the world coming to an end?

"Michel Fortin"  wrote in message 
news:ina7e9$2kdh$1...@digitalmars.com...
> On 2011-04-03 12:04:42 -0400, Adam D. Ruppe  
> said:
>
>> btw, it might be worth considering a change to overflow. Suppose
>> there was a way to get arbitrary size ints passed to a template.
>> Then, the library could do its own overflow checks, or not, enabling
>> things like bigint literals in this same fashion.
>>
>> Though, I don't think it's a big benefit. It'd be really weird
>> to use (a new compile time only datatype?)
>
> I've been thinking about the same thing, except instead of having a 
> special data type the template would simply take a string:
>
> template binary(string digits) {
> ...
> }
>
> binary!___;
> // no error, number "___" passed as a string to the 
> template.
>

I've always thought that we should be able to do something like this:

template foo(int val)
{
enum foo = val.meta.argString;
}
static assert(foo!(2+3) == "2+3");

Re: std.string.indexOf with an optional start-at parameter?

2011-04-03 Thread Robert Jacques

On Sun, 03 Apr 2011 13:39:40 -0400, Aleksandar Ružičić  
 wrote:



I needed std.string.indexOf to accept start position in the string to
start the search at. I was really surprised when I realized that this
(to me) standard parameter is "missing" (I'm used to indexOf in
javascript, strpos in php and equivalent methods in other languages,
which support start offset parameter).

There might be some other function (in some other module) that does
what I want but I wasn't able to find it (I find D's documentation not
easy to search and read), so I've copied indexOf to my module and
added wanted functionality:

https://gist.github.com/900589

now, I'm able to write, for example:

auto pos = indexOf(haystack, '$', 10); // will starts search at 11th
char in haystack


auto pos = indexOf(haystack[10..$], '$') + 10;


and

auto pos = indexOf(haystack, '$', -5); // will starts search at 5th
char from the end


auto pos = indexOf(haystack[$-5..$], '$') + haystack.length-5;


My question is: is there a reason why there is no this functionality
in phobos (maybe there's some language feature I'm not aware of?) and
if no such reason exists, would it be possible to add it in future
version of phobos/dmd?


Yes, the language feature is called slicing. See above. Also, you may want  
to look at the various find methods in std.algorithm. Generally, it's  
better to work with ranges/slices than indexes due to UTF's encoding  
scheme.

Re: Is the world coming to an end?

2011-04-03 Thread bearophile

Lars T. Kyllingstad:

> > I agree that 0b could and should be deprecated.
> 
> Ditto.

No please :-)

Bye,
bearophile

Re: Is the world coming to an end?


On 4/3/2011 2:39 AM, Ulrik Mikaelsson wrote:

If you're looking for uncommonly used language-features that could
easily be otherwise solved, go ahead and remove asm instead. I'll
guess it's about as uncommon as octal literals (or maybe even more),
have simple other solution (just compile it separately and link), and
has much greater impact on the language and the compiler.


I've done assembler the old fashioned way - a separate .asm file assembled with 
masm and linked in - for years. Having the inline assembler is an ENORMOUS 
productivity improvement. Just a few off the top of my head:


1. MASM's syntax changes unpredictably from version to version. I'd get a lot of 
grief from customers with "this doesn't assemble with *my* version of MASM", or 
"I don't have MASM".


2. Different assemblers have utterly different syntax - see MASM and GAS.

3. MASM can't read struct declarations, meaning you now have parallel 
declarations that manually must be synced.


4. MASM doesn't understand C++ or D name mangling.

5. Can't mix MASM files and D code in the same function.

6. Can't access D manifest constants from MASM.

7. D takes care of local variable stack addressing modes for you.

8. I can't fix MASM bugs.

9. And Adam's comments.

Re: Review of std.net.isemail part 2


On 3/29/11 4:06 PM, 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


Overall I think the module is in good shape for admission, with the nits 
below. Here is my review:


* First doc sentence: "To validate..." is grammatically mistaken 
(doesn't have a predicate). Normally I'd just note that and fix later, 
but this is the first sentence so I guess it gets a higher priority.


* Copyright: please look up and use the comment convention used 
elsewhere in Phobos.


* Instead of using a bool for checkDns I suggest enum CheckDns { no, yes 
} which is used in other parts of Phobos.


* Line 67: Please use template constraints instead of static assert.

* Line 79 and others: I wish there were no empty line before the "else" 
clause...


* Line 86: There is a constant Threshold that doesn't follow common 
conventions.


* Line 189: enforce?

* Line 235: At best 33, 126, and 10 were symbolic constants or otherwise 
explained.


* Line 920: EmailStatus should be either private or documented.

* Line 1316: Why is Token a struct with an enum in it instead of an 
enum? (Also the static: label is unnecessary.)


* Line 1357: Why is there a need for conversion to int? Wouldn't dchar 
work well?



Andrei

Re: std.string.indexOf with an optional start-at parameter?

2011-04-03 Thread Aleksandar Ružičić

I thought first of slicing, but isn't that making a copy of string?
And also, if I'm not mistaken if you slice out of range bounds (i.e.
haystack[5..$] when haystack.length < 5) you'll get exception, right?

That's why I think this would be nice to have feature, so you don't
have to worry if start position is within the string bounds, and you
won't need to write this:

> auto pos = indexOf(haystack[$-5..$], '$') + haystack.length-5;

when you want to start search from the end (since it's somehow less
readable than indexOf(haystack, '$', -5)).

On Sun, Apr 3, 2011 at 7:55 PM, Robert Jacques  wrote:
> On Sun, 03 Apr 2011 13:39:40 -0400, Aleksandar Ružičić
>  wrote:
>
>> I needed std.string.indexOf to accept start position in the string to
>> start the search at. I was really surprised when I realized that this
>> (to me) standard parameter is "missing" (I'm used to indexOf in
>> javascript, strpos in php and equivalent methods in other languages,
>> which support start offset parameter).
>>
>> There might be some other function (in some other module) that does
>> what I want but I wasn't able to find it (I find D's documentation not
>> easy to search and read), so I've copied indexOf to my module and
>> added wanted functionality:
>>
>> https://gist.github.com/900589
>>
>> now, I'm able to write, for example:
>>
>> auto pos = indexOf(haystack, '$', 10); // will starts search at 11th
>> char in haystack
>
> auto pos = indexOf(haystack[10..$], '$') + 10;
>
>> and
>>
>> auto pos = indexOf(haystack, '$', -5); // will starts search at 5th
>> char from the end
>
> auto pos = indexOf(haystack[$-5..$], '$') + haystack.length-5;
>
>> My question is: is there a reason why there is no this functionality
>> in phobos (maybe there's some language feature I'm not aware of?) and
>> if no such reason exists, would it be possible to add it in future
>> version of phobos/dmd?
>
> Yes, the language feature is called slicing. See above. Also, you may want
> to look at the various find methods in std.algorithm. Generally, it's better
> to work with ranges/slices than indexes due to UTF's encoding scheme.
>

Re: [GSOC] Database API draft proposal


On 3-apr-11, at 19:28, Piotr Szturmaj wrote:


Fawzi Mohamed wrote:

Looking more maybe I was a bit too harsh, if you define clearly the
goals of your API then yes it might be a good project.
The api doesn't have to be defined yet, but a more detailed  
definition

of its goals should be there, maybe with code example of some usages.
Questions that should be answered:


I know your response is'nt to me, but please let me answer these  
questions from my point of view, based on my recent work on ddb.


I think that your responses are very relevant, as it seems to me that  
your work is nice, and I find that if a GSoC is done in that direction  
it should definitely work together with the good work that is already  
done, let's don't create multiple competing projects if people are  
willing to work together.



* support for static and dynamic types.
how access of dynamic and static types differs, should be as little  
as

possible, and definitely the access one uses for dynamic types should
work without changes on static types


If you mean statically or dynamically typed data row then I can say  
my DBRow support both.


yes but as I said I find the support for dynamic data rows weak.


* class or struct for row object


I'm using struct, because I think row received from database is a  
value type rather than reference. If one selects rows from one table  
then yes, it is possible to do some referencing based on primary  
key, but anyway I think updates should be done explicitly, because  
row could be deleted in the meantime. In more complex queries, not  
all of selected rows are materialized, i.e. they may be from  
computed columns, view columns, aggregate functions and so on.  
Allocation overhead is also lower for structs.



* support for table specific classes?


Table specific classes may be written by user and somehow wrap  
underlying row type.


well with the current approach it is ugly because your calls would be  
another type, thus either you remove all typing or you can't have  
generic functions, accepting rows, everything has to be a template,  
looping on a table or a row you always need a template.


* reference to description of the table (to be able to get also  
dynamic
types by column name, but avoid using too much memory for the  
structure)


My PostgreSQL client already supports that. Class PGCommand has  
member "fields", which contain information about returned columns.  
You can even check what columns will be returned from a query,  
before actually executing it.


ok that is nice, and my point is that the type that the user sees by  
default should automatically take advantage of that


* Nice to define table structure, and what happens if the db has  
another

structure.


This is a problem for ORM, but at first, we need standard query API.


I am not so sure about this, yes these (also classes for tables) are  
part of the ORM, but the normal users will more often be at the ORM  
level I think, and how exactly we want the things look like that the  
object level can influence the choice of the best low level interface.


* you want to support only access or also db creation and  
modification?


First, I'm preparing base "traditional" API. Then I want to write  
simple object-relational mapping. I've already written some code  
that generated CREATE TABLE for structs at compile time. Static  
typing of row fields is very helpful here.


Very good I think that working on getting the API right there and  
having it nice to use is important.
Maybe you are right and the current DBRow is indeed the best  
abstraction, but I am not yet 100% sure, to me it looks like it isn't  
the best end user abstraction (but it might be an excellent low level  
object)

Re: [GSOC] Database API draft proposal



On 3-apr-11, at 19:54, Piotr Szturmaj wrote:


Fawzi Mohamed wrote:


On 3-apr-11, at 18:37, Piotr Szturmaj wrote:


Fawzi Mohamed wrote:
I think that you project looks nice, but see some of the comments  
in my

other message.
I would for example consider separating table definition from row
object, and while your row object is really nice, often one has  
either a
single DB model, described in a few model files or goes with a  
fully

dynamic model.
In large project one does not/should not, define RowTypes on the  
fly

everywhere in the code.


There's no need to declare all row types. DBRow support both static
and dynamic models. For dynamic rows, DBRow uses Variant[] as its
underlying type. This is previous sample code, but changed to use
dynamic row:

auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM  
pg_type");

auto result = cmd.executeQuery;

foreach (row; result)
{
// here, row subtypes a Variant[]
writeln(row[0], ", ", row[1]);
}

Btw. I've just updated documentation, so you can take another  
look :)


Yes I saw that, that is exactly the reason I was telling about  
splitting
the table definition in another object, so that also in the dynamic  
case

one can use the column names (that normally are known, or can be
retrieved from the db schema).
That would only add a pointer to each row (to its description), and
would make it much nicer to use.
Your DBRow is very nice to use, and I like how it can accommodate  
both

types, but it degrades too much for dynamic types imho.


Ah, I see what you mean :) This is yet to be done feature :)

I assume you mean something like row["typname"]. Soon, I will add  
support for this.


yes exactly, great

Re: std.string.indexOf with an optional start-at parameter?


On 4/3/11 1:14 PM, Aleksandar Ružičić wrote:

I thought first of slicing, but isn't that making a copy of string?


It's not.


And also, if I'm not mistaken if you slice out of range bounds (i.e.
haystack[5..$] when haystack.length<  5) you'll get exception, right?


Correct.


That's why I think this would be nice to have feature, so you don't
have to worry if start position is within the string bounds, and you
won't need to write this:


I think that's a natural and simple improvement of indexOf. The one 
aspect that I'm unsure about is starting from the end for negative indices.


Could you please submit an enhancement request to bugzilla?


Andrei

Re: Is the world coming to an end?


On 4/3/2011 4:48 AM, spir wrote:

When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure
that (if a move was ever made) either octals would be thrown out of D all
together for beeing nearly useless, or the syntax would be fixed -- the
"obvious" "correct" solution if octals remain. While I new about octal!, this
was so hackish and obviously wrong *for me*, that I did not even imagine one
second it could become the "official" solution.
I'm certainly not the only one.
Questions of detail, sure, but we all know what the details hide ;-)


I can see that the syntax octal!677 can be a bit off-putting at first, simply 
because it is not what we're used to. But give it a chance.

Re: std.string.indexOf with an optional start-at parameter?


On 04/03/2011 07:39 PM, Aleksandar Ružičić wrote:

I needed std.string.indexOf to accept start position in the string to
start the search at. I was really surprised when I realized that this
(to me) standard parameter is "missing" (I'm used to indexOf in
javascript, strpos in php and equivalent methods in other languages,
which support start offset parameter).

There might be some other function (in some other module) that does
what I want but I wasn't able to find it (I find D's documentation not
easy to search and read), so I've copied indexOf to my module and
added wanted functionality:

https://gist.github.com/900589

now, I'm able to write, for example:

auto pos = indexOf(haystack, '$', 10); // will starts search at 11th
char in haystack

and

auto pos = indexOf(haystack, '$', -5); // will starts search at 5th
char from the end

My question is: is there a reason why there is no this functionality
in phobos (maybe there's some language feature I'm not aware of?) and
if no such reason exists, would it be possible to add it in future
version of phobos/dmd?


Agreed this is a fairly standard param in other languages, but D easily (and 
rather cheaply) allows

auto pos = indexOf(s[i..$], char);

I would be far more interested in generalised negative inices in D --à la 
Python. A great step for D's friendliness, and an final end to current '$' 
issues (1).


Denis

(1) Which works only for builtin type via compiler magic, because it neither 
maps to .length, nore is overloadable.

--
_
vita es estrany
spir.wikidot.com

Re: Is the world coming to an end?

"Lutger Blijdestijn"  wrote in message 
news:in9t6a$21jb$1...@digitalmars.com...
>
> I don't understand why it is hackish if it's a pure library approach. (it 
> is
> right?) I find it actually rather nice that D can do this. This is not a
> syntax change, octals are out of the language and the library now has an
> octal template. Where's the problem?
>

Apperently, people want to get a warm fuzzy feeling from the existence of 
features they'll never use.

Seriously, we don't have an 0t... for trinary. We don't have an 0q... for 
base-4 (quadrary?). We don't have any such syntax for any base other than 2, 
10, and 16 (and previously 8). And how many people are bitching about those 
omissions? Nobody. But those omissions are *EVERY BIT* as inconsistent with 
decimal/hex/binary syntax as omitting octal is.

But n, apperently we *need* 0o... for octal just simply for the sake of 
*it* existing, but not for any other base. So where the fuck is the 
consistency in the self-proclaimed "consistency" argument? And don't tell me 
"octal is more useful than trinary" because then you're implicitly admitting 
that the consistency argument is a load of crap, and you're jumping ship to 
the "usefulness" argument...which octal *still* looses.

Re: Review of std.net.isemail part 2


On 3/29/11 4:06 PM, Jacob Carlborg wrote:

I've made a few minor changes:

* Renamed EmailStatusCode.Off -> None and On -> Any


I suggest we follow the nascent convention that enum values start with a 
lowercase letter.


Andrei

Re: Is the world coming to an end?

"spir"  wrote in message 
news:mailman.3064.1301831318.4748.digitalmar...@puremagic.com...
> On 04/03/2011 02:52 AM, 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 :-)
>
> I'm very surprised of this move -- aside the concrete details. What I 
> point out here is how far sentiments about what is "obvious" or "correct" 
> can be, for a given issue, that most of us considered wrong for the same 
> reason.
>
> When I introduced the topic of octal notation 0nnn beeing bad, I was 100% 
> sure that (if a move was ever made) either octals would be thrown out of D 
> all together for beeing nearly useless, or the syntax would be fixed --  
> the "obvious" "correct" solution if octals remain. While I new about 
> octal!, this was so hackish and obviously wrong *for me*, that I did not 
> even imagine one second it could become the "official" solution.
> I'm certainly not the only one.
> Questions of detail, sure, but we all know what the details hide ;-)
>

Sounds to me like you wanted a faster horse instead of a car ;)

Re: Mixing C/D-style array declarations


On 04/03/2011 07:43 PM, bearophile wrote:

After a suggestion from simendsjo in D.learn, I have added an enhancement 
request:
http://d.puremagic.com/issues/show_bug.cgi?id=5807

If you see something wrong in this post I will modify or close the enhancement 
request.

The documentation about Postfix Array Declarations says:


Rationale: The postfix form matches the way arrays are declared
in C and C++, and supporting this form provides an easy migration
path for programmers used to it.<


C style array declarations are handy (despite they add a little of extra 
complexity and confusion to the D language).

But currently (DMD 2.052) D also supports a syntax like:

// array of 5 dynamic arrays of ints.
int[][5] c;
int[] c[5];
int c[5][];

What's the purpose of such mixed syntax?
1) It's not present in C programs;
2) It's not used in normal native D programs;
3) And in my opinion it's not good to use even during the migration from C to D 
style, because it looks confusing (the order of ranges is inverted between C 
and D syntax).

So I suggest to statically disallow such mixed syntax.


Currently the mixed syntax is not just useless and potentially confusing for 
the programmer, it also causes problems with some vector operations:

void main() {
 int[] a1 = [1, 2, 3];
 int[] a2 = new int[3];
 a2[] = a1[];   // OK
 int[3] a3[] = a2[];// line 5, Error
}

test.d(5): Error: cannot implicitly convert expression (a2[]) of type int[] to 
int[3u][]

In theory if mixed C/D array declarations become disallowed, then there is only 
one meaning for the operation at line 5. (This is not very nice, but I don't 
see better solutions for this syntax problem with array operations).


+++ D cleaning.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.string.indexOf with an optional start-at parameter?

2011-04-03 Thread Aleksandar Ružičić

On Sun, Apr 3, 2011 at 8:16 PM, Andrei Alexandrescu
 wrote:
> It's not.

Seems I've missed that in the docs, I tought it will always make a copy :)

> I think that's a natural and simple improvement of indexOf. The one aspect
> that I'm unsure about is starting from the end for negative indices.

Negative indices might seem a bit odd but it's standard in other
languages (like javascript and php which I've already mentioned).
I would even like to see this in D:

array[-2];  // get 'a' from "foobar"

same for slicing:

array[-4..2];  // get "ob" from "foobar"

> Could you please submit an enhancement request to bugzilla?

sure!

Re: Is the world coming to an end?

"bearophile"  wrote in message 
news:inacud$10b$1...@digitalmars.com...
> Lars T. Kyllingstad:
>
>> > I agree that 0b could and should be deprecated.
>>
>> Ditto.
>
> No please :-)
>

Yea, I'm perfectly fine with omitting built-in octal literals, but I'll jump 
deep into the "bitch and moan" ship if the deprication-axe gets aimed at 
binary.

Re: [GSOC] Database API draft proposal


On 4/2/11 3:03 PM, Christian Manning wrote:

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

[snip]

Thanks for your interest and for sharing your draft proposal.

Fawzi is doing an excellent job at making suggestions for improving the 
proposal. Let me add some.


Generally you need to create a compelling case that you know what your 
project entails, you have thoroughly studied the state of the art, and 
you are able to take the project to completion. Digital Mars' reputation 
is at stake here - we need to make sure that we're using Google's money 
and everybody's time to good end.


Here are some more additions to the proposal that would improve it:

* What is your level of understanding of D? How do you believe you could 
use D's templates for improving the API compared to JDBC? If you choose 
to copy JDBC's interface, how do you justify relying on dynamic typing 
alone?


* What coursework did you complete? As a second-year student this makes 
it easier for us to assess where you are in terms of expertise. Scores 
would help as well.


* Since you now know of existing work, have you contacted Piotr for 
collaboration? Would he give you his API to work on? Would he be 
available to help as a formal mentor or informally? What is the 
integration plan?


* If there project were totally successful, what features do you expect 
it has and what would be the impact?


* What is the absolute minimum level of functionality that would still 
qualify the project as successful?


* Also include Fawzi's suggestions focused on details of API definition.


Thanks,

Andrei

Re: image processing in D


On 4/3/11 7:25 AM, Fawzi Mohamed wrote:

On 2-apr-11, at 10:40, aman bansal wrote:


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.


As I told you via email

there are two main things, one is reading/writing several formats, I
would say that you should support at least one standard (simple) format
natively (the simplest would be netpbm format) but then you could rely
on libraries to support more.
Use of external libraries should be discussed with others also, because
one should rely only on libraries that are widely available,
cross-platform and with acceptable licensing.

About the image processing itself you probably want to have a simple
flat representation of the image (as 2d array), and then be able to
apply several operations on it.
General convolution is probably something you want to have, masked
operation might also be very useful.
Not sure about which other operations you want to support.
In D1 as part of blip I have implemented nearest neighbor convolution,
it could be useful to you.

Not sure which bit depth you want to support, one can build a wrapper to
access arbitrary bit depth/bitchannel contiguous block of memory as 1d
or 2d array (for example 4channel 12 bit images), this can be useful as
base type for operations with images that might have an extended bit range.

is this for a GSoC project?


Yes, that is a GSoC project.

Aman, you may want to read the posts I wrote with advice to other 
students before completing your proposal.


A strong proposal would convince us that you (a) understand your domain 
rather well, (b) you understand D's specifics enough to define a good 
API for it, (c) you have studied and absorbed similar endeavors in other 
languages and frameworks, and (e) you have what it takes to complete the 
project.



Good luck!

Andrei

Re: Is the world coming to an end?


On 04/03/2011 07:57 PM, Nick Sabalausky wrote:

"Michel Fortin"  wrote in message
news:ina7e9$2kdh$1...@digitalmars.com...

On 2011-04-03 12:04:42 -0400, Adam D. Ruppe
said:


btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)


I've been thinking about the same thing, except instead of having a
special data type the template would simply take a string:

template binary(string digits) {
...
}

binary!___;
// no error, number "___" passed as a string to the
template.



I've always thought that we should be able to do something like this:

template foo(int val)
{
 enum foo = val.meta.argString;
}
static assert(foo!(2+3) == "2+3");


That's Lisp (or Io): non-evaluated arguments (messages). Next century in 
compiled languages ;-)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Is the world coming to an end?


On 4/3/11 1:37 PM, spir wrote:

On 04/03/2011 07:57 PM, Nick Sabalausky wrote:

"Michel Fortin" wrote in message
news:ina7e9$2kdh$1...@digitalmars.com...

On 2011-04-03 12:04:42 -0400, Adam D. Ruppe
said:


btw, it might be worth considering a change to overflow. Suppose
there was a way to get arbitrary size ints passed to a template.
Then, the library could do its own overflow checks, or not, enabling
things like bigint literals in this same fashion.

Though, I don't think it's a big benefit. It'd be really weird
to use (a new compile time only datatype?)


I've been thinking about the same thing, except instead of having a
special data type the template would simply take a string:

template binary(string digits) {
...
}

binary!___;
// no error, number "___" passed as a string to the
template.



I've always thought that we should be able to do something like this:

template foo(int val)
{
enum foo = val.meta.argString;
}
static assert(foo!(2+3) == "2+3");


That's Lisp (or Io): non-evaluated arguments (messages). Next century in
compiled languages ;-)


No, that's C's last century's "#" prefix.


Andrei

Re: Is the world coming to an end?


On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:

Adding octal!777 to std.conv is consistent with the notion that there still are
a few uses for octal constants that are worth a presence in the standard
library. It is also consistent with the desire to foster other user-defined
literals defined from the same mold.


What about a general baseNumber template instead?
...which would also be trivially "alias-able":
alias baseNumber!3 base3;

Denis
--
_
vita es estrany
spir.wikidot.com

Re: Is the world coming to an end?


On 04/03/2011 07:19 PM, Adam D. Ruppe wrote:

KennyTM~ wrote:

Talking of asm, would the following be expected to work?


Maybe. Part of me says "yes, it should be the same as a literal*"
but part of me says no because it's weird to drop a template in
an asm block.

* For example:

enum a = octal!777;
asm {
mov EAX, a;
}

does indeed work.


But, all in all, I don't think octal! itself in asm should work.
It's not literally a literal.


The whole is that, precisely, it is not (no more) a literal. Octals have no 
more syntactic existence ;-)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Is the world coming to an end?


On 4/3/11 1:40 PM, spir wrote:

On 04/03/2011 06:14 PM, Andrei Alexandrescu wrote:

Adding octal!777 to std.conv is consistent with the notion that there
still are
a few uses for octal constants that are worth a presence in the standard
library. It is also consistent with the desire to foster other
user-defined
literals defined from the same mold.


What about a general baseNumber template instead?
which would also be trivially "alias-able":
alias baseNumber!3 base3;


When was last time you've been in a place in life when you could have 
used a base 3 literal?


Andrei

Re: Complete D grammar

2011-04-03 Thread Jason

On Mon, 28 Mar 2011 09:02:45 -0700, Luca Boasso wrote:

> A complete D grammar is one of the objectives of my GSOC 2011 ANTLR
> proposal, if I got accepted you will have one :)

Luca -

You might want to be aware that it appears that the dmd2 front end uses 
Pratt parsing rather than being based on EBNF.  That being the case, it 
might be much easier (not to say more useful) to specify the language 
semantics in a more compatible format than EBNF.  If you've had sophmore 
level CS theory, then Pratt's original paper is very readable, and highly 
recommended.

Best,
Jason

http://hall.org.ua/halls/wizzard/pdf/Vaughan.Pratt.TDOP.pdf

;;; Pratt, Vaughan R., ``Top Down Operator Precedence,''
;;; ACM Symposium on Principles of Programming Languages
;;; Boston, MA; October, 1973.

Re: Is the world coming to an end?


On 04/03/2011 08:17 PM, Walter Bright wrote:

On 4/3/2011 4:48 AM, spir wrote:

When I introduced the topic of octal notation 0nnn beeing bad, I was 100% sure
that (if a move was ever made) either octals would be thrown out of D all
together for beeing nearly useless, or the syntax would be fixed -- the
"obvious" "correct" solution if octals remain. While I new about octal!, this
was so hackish and obviously wrong *for me*, that I did not even imagine one
second it could become the "official" solution.
I'm certainly not the only one.
Questions of detail, sure, but we all know what the details hide ;-)


I can see that the syntax octal!677 can be a bit off-putting at first, simply
because it is not what we're used to. But give it a chance.


Sorry, I expressed my thought wrongly: I meant this was my first impression. 
Then, I would rather go (see other post) for a general baseNumber! template, 
that could trivially be aliased as in

alias baNumber!3 base3;
What do you think?

Denis
--
_
vita es estrany
spir.wikidot.com

Re: Mixing C/D-style array declarations

2011-04-03 Thread Vladimir Panteleev

On Sun, 03 Apr 2011 20:43:59 +0300, bearophile   
wrote:


C style array declarations are handy (despite they add a little of extra  
complexity and confusion to the D language).


Hmm, I thought C-style array declarations are pending deprecation. I know  
the C-style function pointer syntax has already been deprecated.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Is the world coming to an end?


On 04/03/2011 08:27 PM, Nick Sabalausky wrote:

"bearophile"  wrote in message
news:inacud$10b$1...@digitalmars.com...

Lars T. Kyllingstad:


I agree that 0b could and should be deprecated.


Ditto.


No please :-)



Yea, I'm perfectly fine with omitting built-in octal literals, but I'll jump
deep into the "bitch and moan" ship if the deprication-axe gets aimed at
binary.


;-) Same for me: sometimes I just want to write the exact bit sequence. I can't 
automagically figure it out in my head for eg D9 (aging... ).


denis
--
_
vita es estrany
spir.wikidot.com

[GSoC] Container proposals by Ishan and Christian

We are honored to receive a fair amount of interest from students at our
GSoC 2011.

One issue is that at least one student (who contacted me off-list)
couldn't find a project to work on that would best play into his
strengths. I think it's not too late to improve our GSoC ideas page
(http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

Another issue is that we have competing proposals on identical or
overlapping projects. I am trying to solve one of these matters
privately, and I think it would be best if we could solve the others in
the community.

I'm referring to Ishan's and Christian's proposals for containers. Both
proposals have pros and cons, and I predict it would be very difficult
to make a decision. Therefore, I'm trying to avoid that "by design",
i.e. by finding a solution that would keep both busy on useful work that
is in line with their capabilities.

First, I suggest that anyone interested gives a thorough read to the two
proposals:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1

Both students seem to be quite enthusiastic and capable. Two things that
I'm worrying about are:

1. Both seem to be quite fresh on D, so they'll need close coaching at
least in the beginning.

2. Both students seem unfamiliar with the STL, which is a difficult
skill to acquire in a short time frame and is quite recommended for
working on D's containers.

If the students could comment on that, that would be helpful.

Here's how I think we can solve the problem of overlapping projects:

1. One way is to convince one of the students to work on a different
topic that would also play into his strengths and is of interest to him.
Any suggestions are welcome, both from the students and the community.

2. Another approach would be to expand the scope of the project. There
are plenty of interesting containers out there (see e.g.
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-cool-data-structures)
that are darn useful. I suggest students to look over those and answer
if they'd fell comfortable about implementing e.g. a Bloom filter or a trie.

With an expanded containers project we could (assuming all goes smooth)
benefit of a host of solid containers by fall. The thing is that would
definitely require very intensive mentoring. I'd probably be a mentor,
and I'd need at least one to be comfortable about putting this option on
the table.

Any thoughts, please share.

Thanks,

Andrei

Re: std.string.indexOf with an optional start-at parameter?