Re: Thoughts on std.system.OS

[Jacob Carlborg]

On 2011-08-14 21:20, Jonathan M Davis wrote:

On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:

On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis

wrote:

Personally, I'm
inclined to drop the Os enum along with the os and os_major and os_minor
variables, because I just don't think that we can get them to be correct
enough of generally useful enough to be worth having. It's too
OS-specific to
be trying to handle it in an OS-generic manner like that.


Looking at the code again, I noticed there's a Family enum, which seems to
me closer to what the OS enum should really be. I think Family should just
replace OS.

I don't agree that we should just drop version numbers. As I said before,
they can be useful for users. They can also be useful for programs that
care only about a certain OS family.

What do you think about this?

https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d


I'm not at all convinced that it makes any sense to try and handle OS version
numbers in a system-independent manner. You have to know what OS you're on for
them to mean anything, in which case, why try and handle them in an OS-
independent manner?

On Linux, the version number is probably pointless. It's the version number
for the kernel. Most programs won't care one whit about that. If they care
about a version number, odds are that it's the version number of some program
or library on the system that they're using, not the kernel. And in general,
if you care, you care when you compile, not when you run the program. I would
expect FreeBSD to be the same. I don't know about Mac OS X.


I think it makes sense to be able to get version information about Mac 
OS X. I would consider Windows XP, Vista and so on be similar to Mac OS 
X 10.5, 10.6.



--
/Jacob Carlborg

Re: Prototype DIP11

[Jacob Carlborg]

On 2011-08-15 01:39, Jonathan M Davis wrote

That's just not going to work. If you use .di files, you lose CTFE and inlining
for anything which isn't in the .di files. As such, there's a definite advantage
for a library to _not_ use .di files. There have been some suggestions about
how to fix that, but it's pretty much been decided to put off fixing how .di 
files
to D3.


How about putting the complete source code in the .di files and then the 
compiler will still be able to do CTFE and inline? But that might be no 
difference compared with a .d file.



So, libraries _must_ be able to use .d files exclusively. With D2, we _cannot_
assume that libraries will use .di files. There's a good chance that they
won't. Maybe they will for D3 but not for D2.

- Jonathan M Davis



--
/Jacob Carlborg

Re: ref parameters: there is no escape

[Mehrdad]

On 8/14/2011 7:20 AM, Andrei Alexandrescu wrote:
Walter and I have had a long discussion and we thought we'd bring an 
idea for community review.


We believe it would be useful for safety purposes to disallow escaping 
addresses of ref parameters. 


... I hope you're joking.

(1) I thought the whole point of D was that you didn't need pointers to 
program effectively?


(2) Isn't this what compiler **warnings** are for?

Re: Native Client in Chrome Beta

[Nick Sabalausky]

"Brad Roberts"  wrote in message 
news:mailman.2324.1313368907.14074.digitalmar...@puremagic.com...
>
> Quite frankly, it's too late to pretend that the web and the browser is

Judging by the rest of your post I assume you meant "isn't" not "is"...

> all there is for a large segment of the computer and 'net using
> population.  They never leave the browser.  That's only going to grow.
> Pretending otherwise, is, well, fairly pointless.  The people on this
> are in a very small minority and do NOT represent the typical user.
> Haven't for a long time.
>

That's a completely absurd cart-before-the-horse question-begging argument. 
The *reason* a growing number of people never leave the browser is obviously 
*because* so many idiot trend-whore developers and managers keep pretending 
the web is all there is.

Users are morons (almost by definition), and that means they defer judgement 
to others and thus follow the *trends*. On the desktop, web is the trend, 
therefore 1. Moron users assume that means it's better, and 2. That's where 
all the functionality gets put, and thus, where the users go. Start making 
*real* applications again and the sheeple will follow. Need evidence of 
that? iOS and Android. Are shitphone users flocking to webapps or to the 
app-store apps? The latter, obviously. (At least that's *one* thing they've 
managed to get sort-of right...)

And you can't argue it's a usability matter, because the web sure as shit 
doesn't win on that: Web app usability is crap, and Average Retard Joe is no 
worse at real apps than with the web. My mom's one of the dumbest 
completer-illiterate fucks I've ever met (no exaggeration) and yet even her 
ability with Word - a *REAL* application - is absolutely *NO* worse than her 
ability with a web browser. In fact, she's even a little *better* with the 
real apps like Word: You should see the crap I have to put up with when she 
*attempts* to use any of those god-awful webmail servces. Same goes for my 
dad.

Your argument here is completely rediculous.

Re: Any D developer at GDC europe next week ?

[Jouko Koski]

"Peter Alexander"  wrote:

Almost everyone in the games industry knows that C++ is a rubbish 
language.


When I talk about D programming language to somebody, I prefer avoiding this 
sort of argumentation entirely.


--
Jouko

Re: Why callers should explicitly document storage classes

[kennytm]

Timon Gehr  wrote:
> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:
>> 
>>> requiring lazy before lazy arguments basically destroys the reason for
>>> lazy being in the language:
>>> 
>>> int foo(lazy 2*3);
>>> 
>>> is not better than
>>> 
>>> int foo({return 2*3});
>> 
>> What about requiring "lazy" only for non-pure delegates?
>> 
> 
> Actually I would rather require lazy arguments to be pure, so that they
> can be guaranteed to be executed at most once.

One problem: It is expected that the lazy argument can be re-evaluated. D's
`lazy` is actually call-by-name, which allowed stuff like 


void dotimes(int count, lazy void exp)
{
for (int i = 0; i < count; i++)
   exp();
}
void foo()
{
int x = 0;
dotimes(10, writef(x++));
}


as documented in http://www.d-programming-language.org/lazy-evaluation.html

Re: Thoughts on std.system.OS

[amanda]

hi,D:)When you have Herpes, HIV/AIDS, hpv,or any other STD, it can feel like 
you are all alone in the world  DatingHerpesSingles.com is a place where you 
didn't have to worry about being rejected   Just feel free to chat, share 
stories, make friends in your local area.

Re: Why callers should explicitly document storage classes

[Jonathan M Davis]

On Sunday, August 14, 2011 17:39:29 Brad Roberts wrote:
> On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
> > On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
> >> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
> >>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
>  On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> > On Sun, 14 Aug 2011 22:48:18 +0300, Timon
> > Gehr
> > 
> > wrote:
> >> requiring lazy before lazy arguments basically destroys the
> >> reason
> >> for
> >> lazy being in the language:
> >> 
> >> int foo(lazy 2*3);
> >> 
> >> is not better than
> >> 
> >> int foo({return 2*3});
> > 
> > What about requiring "lazy" only for non-pure delegates?
>  
>  Actually I would rather require lazy arguments to be pure, so that
>  they
>  can be guaranteed to be executed at most once.
> >>> 
> >>> That still wouldn't be guaranteed, since pure function calls are
> >>> only
> >>> optimized out if they're strongly pure and in the same expression.
> >>> You
> >>> can't rely on calls to pure function
> 
> s being optimized.
> 
> >>> - Jonathan M Davis
> >> 
> >> My point was, that if lazy arguments were required to be pure, such a
> >> thing _could_ then be guaranteed independently from optimizations that
> >> may or may not take place on general pure functions.
> > 
> > Yes. In theory. It would depend on what Walter was willing to do with
> > the
> > language and the compiler though. At present, pure is purely an
> > optimization and not use to affect semantics at all.
> 
> The pure keyword doesn't _change_ semantics, but it very much affects
> semantics, through restriction and the guarantees it provides.  The
> restrictions help enforce some very specific and broadly useful
> behaviors.  But you know this.
> 
> > However, I'd actually argue that lazy delegates should be effectively
> > treated as pure anyway. Conceptually, what you're doing is delaying the
> > execution of the expression in case it isn't needed. I don't see any
> > reason why the end result should be any different from passing a
> > non-lazy a
> 
> rgument. As such, the
> 
> > lazy argument should only be called once regardless. It wouldn't
> > surprise me at all if the implementation doesn't work that way, but I'd
> > argue that it should regardless of purity. From the standpoint of the
> > function, the lazy argument is just like any other argument in terms of
> > its value, and IMHO it should be treated that way.
> 
> That's not the way it behaves, or is defined to behave.  Lazy
> parameters are executed 0-N times, entirely based on the implementation
> of the method itself.  It _could_ be re-done to mean 0 or 1, but that's
> still not always 1.  If it was, might as well kill the lazy concept.

Oh, I know that it's not always 1, and I'm not suggesting that it always be 1. 
I'm suggesting that it always be 0 or 1, and that it not actually be called 
multiple times even if it's referenced multiple times. I don't see why there 
is any value in having it called multiple times. In concept at least, a non-
lazy parameter is the same as a non-lazy except that it isn't evaluated unless 
it's used. And so I don't see why you'd want to be evaluating it multiple 
times except that it's probably easier to implement that way.

- Jonathan M Davis

Re: Native Client in Chrome Beta

[Brad Roberts]

On Sunday, August 14, 2011 3:29:28 PM, Marco Leise wrote:
> Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley :
> 
>> On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise  wrote:
>>
>>> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :
>>>
>>>  On Sat, Aug 13, 2011 at 5:10 AM, bearophile **
 wrote:

  Found though Reddit. It seems Chrome is starting to warm up to the Native
> Client (NaCl) idea, the Chrome Beta now has a working NaCl:
>
> http://chrome.blogspot.com/**2011/08/building-better-web-**
> apps-with-new.html
>
>
> http://channel9.msdn.com/**Shows/C9-GoingNative/**
> GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti
>
>

> It's one (the only?) chance to use D in the browser.
>
> Bye,
> bearophile
>
>
 Just thought I'd point out that the previous discussions on NaCl seem to
 have missed this part of the overview:
 "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is
 included in the Native Client SDK. This library is written in C, and the
 SDK
 also provides a set of C++ bindings for it. Native Client modules use the
 Pepper API to communicate with the browser's JavaScript, the DOM, and
 other
 resources managed by the browser. The Pepper Library also provides a
 platform-independent multimedia API that Native Client modules can use for
 audio, video, and 2D graphics."

 So yes, this is somewhat geared toward multimedia, but it looks like it
 can
 also replace javascript in web apps.

>>>
>>> Is this basically the same as the Java applet interface to the browser
>>> without the "compile once
, run everywhere", but with better API?
>>>
>>
>> I haven't ever dealt with the applet interface, but that quote came from
>> http://code.google.com/chrome/nativeclient/docs/technical_overview.html if
>> you want to take a closer look. The Pepper API docs are there as well.
> 
> It doesn't convince me. The driving force seems to be moving desktop 
> applications into the browser. That's
> understandable since a lot of people at Google use their web services where 
> possible. I personally don't like that
> centralization on the browser. It adds up on complexity and bugs, trying to 
> be an operating system that manages running
> applications. How do they make sure the code is safer than what we know from 
> ActiveX? Even the WebGL standard was in the
> critics, because it was obviously accessing the gfx card and a malicious 
> texture upload in a buggy driver could become a
> security risk.
> Maybe it finds a way through good advertising or real-time games which run 
> faster with native code 
instead of
> JavaScript, but there will always be some bad memories from 
> http://www.adoko.com/activex.html
> At least they take the issue serious :)
> http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702

Quite frankly, it's too late to pretend that the web and the browser is 
all there is for a large segment of the computer and 'net using 
population.  They never leave the browser.  That's only going to grow.  
Pretending otherwise, is, well, fairly pointless.  The people on this 
are in a very small minority and do NOT represent the typical user.  
Haven't for a long time.

Sorry Nick.

Later,
Brad

Re: Why callers should explicitly document storage classes

[Brad Roberts]

On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
> On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
>> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
>>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
 On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  
> wrote:
>> requiring lazy before lazy arguments basically destroys the reason
>> for
>> lazy being in the language:
>>
>> int foo(lazy 2*3);
>>
>> is not better than
>>
>> int foo({return 2*3});
>
> What about requiring "lazy" only for non-pure delegates?

 Actually I would rather require lazy arguments to be pure, so that
 they
 can be guaranteed to be executed at most once.
>>>
>>> That still wouldn't be guaranteed, since pure function calls are only
>>> optimized out if they're strongly pure and in the same expression. You
>>> can't rely on calls to pure function
s being optimized.
>>>
>>> - Jonathan M Davis
>>
>> My point was, that if lazy arguments were required to be pure, such a
>> thing _could_ then be guaranteed independently from optimizations that
>> may or may not take place on general pure functions.
> 
> Yes. In theory. It would depend on what Walter was willing to do with the 
> language and the compiler though. At present, pure is purely an optimization 
> and not use to affect semantics at all.

The pure keyword doesn't _change_ semantics, but it very much affects 
semantics, through restriction and the guarantees it provides.  The 
restrictions help enforce some very specific and broadly useful 
behaviors.  But you know this.
 
> However, I'd actually argue that lazy delegates should be effectively treated 
> as pure anyway. Conceptually, what you're doing is delaying the execution of 
> the expression in case it isn't needed. I don't see any reason why the end 
> result should be any different from passing a non-lazy a
rgument. As such, the 
> lazy argument should only be called once regardless. It wouldn't surprise me 
> at all if the implementation doesn't work that way, but I'd argue that it 
> should regardless of purity. From the standpoint of the function, the lazy 
> argument is just like any other argument in terms of its value, and IMHO it 
> should be treated that way.

That's not the way it behaves, or is defined to behave.  Lazy 
parameters are executed 0-N times, entirely based on the implementation 
of the method itself.  It _could_ be re-done to mean 0 or 1, but that's 
still not always 1.  If it was, might as well kill the lazy concept.
 
> - Jonathan M Davis

Re: Prototype DIP11

[Martin Nowak]

  - Using 'pragma(lib, "someLib")' in an imported source has no effect,  
as long as the imported module is not compiled.


I've added a workaround for that so that linking as depicted in the draft  
will work.


martin

Re: Prototype DIP11

[Martin Nowak]

I see.

For binary distributions it would be simple to make pragma(lib,) work from  
imported sources.
This would allow for something similar to what boost uses with Visual  
Studio.

I will add that in the DIP11 tree.

IMHO binary distributions don't allow a simple package distribution,  
because it's difficult to provide binaries for all platforms

and dmd changes rather rapidly making binaries incompatible.
So my conclusion is, to allow source distributions one needs a directive  
that instructs the compiler to actually build imported modules.


martin

Re: Prototype DIP11

[Jonathan M Davis]

On Monday, August 15, 2011 01:32:02 Martin Nowak wrote:
> On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis 
> 
> wrote:
> > On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
> >> I've implemented a prototype of the DIP11 draft.
> >> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> >> https://github.com/dawgfoto/dmd/tree/DIP11
> >> 
> >> -- Restrictions --
> >> 
> >>   - It doesn't check for conflicting qualified imports
> >>   (-Iacme=/path1
> >> 
> >> -Iacme.a=/path2)
> >> 
> >>   - pragma(importpath, "") must come lexically before
> >>   the
> >> 
> >> import
> >> 
> >>   - Untested on Windows
> >> 
> >> -- Some outcome --
> >> 
> >>   - Using '=' in [module.or.package=] could be slightly
> >> 
> >> ambiguous for '-Ihttp://acme.org?format=raw'.
> >> 
> >>   - Url syntax collides with import path lists. Currently it is
> >>   allowed
> >> 
> >> to
> >> specify -I/path1/import:/path2/import for POSIX. I've deactivated that
> >> for
> >> now.
> >> 
> >> Both can be disambiguated so they are not very severe.
> >>   
> >>   - Using 'pragma(lib, "someLib")' in an imported source has no
> >>   effect,
> >> 
> >> as
> >> long as the imported module is not compiled.
> >> 
> >>   - Overall this is very limited as even the example below will only
> >> 
> >> compile up to a linker error.
> >> 
> >> -- Testing --
> >> 
> >>   - build dmd from DIP11 branch
> >>   - get download.py: http://codepad.org/XAvSN505
> >>   - get test.d: http://codepad.org/BILAwzHj
> >>   - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
> >>   - compile: dmd test.d
> >> 
> >> -- Brainstorming --
> >> We need to define a compilation model for the imported files.
> >> 
> >> One solution could be to generally change the semantics of importing
> >> to
> >> mean if the
> >> imported file is a source (*.d) build an object for that module if it
> >> is a
> >> header (*.di) don't
> >> build an object and leave it to the user to supply binary data.
> > 
> > That's not going to work. That assumes that libraries use .di files,
> > which
> > isn't necessarily true. If a library just uses .d files, then that means
> > that
> > you're recompiling modules from the library when you don't need to (and
> > probably shouldn't be since, I would expect that you'd end up with
> > complaints
> > about symbols being defined twice when you link in the library).
> > 
> > - Jonathan M Davis
> 
> Yes I'm aware of this. Prominent example being phobos vs. druntime.
> But the idea was exactly to change this (in the long-term/opt-in).
> Requiring libraries to be bundled with .di files.

That's just not going to work. If you use .di files, you lose CTFE and inlining 
for anything which isn't in the .di files. As such, there's a definite 
advantage 
for a library to _not_ use .di files. There have been some suggestions about 
how to fix that, but it's pretty much been decided to put off fixing how .di 
files 
to D3.

So, libraries _must_ be able to use .d files exclusively. With D2, we _cannot_ 
assume that libraries will use .di files. There's a good chance that they 
won't. Maybe they will for D3 but not for D2.

- Jonathan M Davis

Re: Prototype DIP11

[Martin Nowak]

On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis   
wrote:



On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:

I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11

-- Restrictions --
  - It doesn't check for conflicting qualified imports (-Iacme=/path1
-Iacme.a=/path2)
  - pragma(importpath, "") must come lexically before the
import
  - Untested on Windows

-- Some outcome --
  - Using '=' in [module.or.package=] could be slightly
ambiguous for '-Ihttp://acme.org?format=raw'.
  - Url syntax collides with import path lists. Currently it is allowed  
to
specify -I/path1/import:/path2/import for POSIX. I've deactivated that  
for

now.

Both can be disambiguated so they are not very severe.

  - Using 'pragma(lib, "someLib")' in an imported source has no effect,  
as

long as the imported module is not compiled.
  - Overall this is very limited as even the example below will only
compile up to a linker error.

-- Testing --
  - build dmd from DIP11 branch
  - get download.py: http://codepad.org/XAvSN505
  - get test.d: http://codepad.org/BILAwzHj
  - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
  - compile: dmd test.d

-- Brainstorming --
We need to define a compilation model for the imported files.

One solution could be to generally change the semantics of importing to
mean if the
imported file is a source (*.d) build an object for that module if it  
is a

header (*.di) don't
build an object and leave it to the user to supply binary data.


That's not going to work. That assumes that libraries use .di files,  
which
isn't necessarily true. If a library just uses .d files, then that means  
that

you're recompiling modules from the library when you don't need to (and
probably shouldn't be since, I would expect that you'd end up with  
complaints

about symbols being defined twice when you link in the library).

- Jonathan M Davis


Yes I'm aware of this. Prominent example being phobos vs. druntime.
But the idea was exactly to change this (in the long-term/opt-in).
Requiring libraries to be bundled with .di files.

What is needed for DIP11 to work is some sort of pragma(build, pkg.module)  
but
 - it should not require redundant declarations (already have  
pragma(importpath, "pkg"))

 - one should be able to define the build model in the remote sources

martin

Re: Prototype DIP11

[Jonathan M Davis]

On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
> I've implemented a prototype of the DIP11 draft.
> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> https://github.com/dawgfoto/dmd/tree/DIP11
> 
> -- Restrictions --
>   - It doesn't check for conflicting qualified imports (-Iacme=/path1
> -Iacme.a=/path2)
>   - pragma(importpath, "") must come lexically before the
> import
>   - Untested on Windows
> 
> -- Some outcome --
>   - Using '=' in [module.or.package=] could be slightly
> ambiguous for '-Ihttp://acme.org?format=raw'.
>   - Url syntax collides with import path lists. Currently it is allowed to
> specify -I/path1/import:/path2/import for POSIX. I've deactivated that for
> now.
> 
> Both can be disambiguated so they are not very severe.
> 
>   - Using 'pragma(lib, "someLib")' in an imported source has no effect, as
> long as the imported module is not compiled.
>   - Overall this is very limited as even the example below will only
> compile up to a linker error.
> 
> -- Testing --
>   - build dmd from DIP11 branch
>   - get download.py: http://codepad.org/XAvSN505
>   - get test.d: http://codepad.org/BILAwzHj
>   - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
>   - compile: dmd test.d
> 
> -- Brainstorming --
> We need to define a compilation model for the imported files.
> 
> One solution could be to generally change the semantics of importing to
> mean if the
> imported file is a source (*.d) build an object for that module if it is a
> header (*.di) don't
> build an object and leave it to the user to supply binary data.

That's not going to work. That assumes that libraries use .di files, which 
isn't necessarily true. If a library just uses .d files, then that means that 
you're recompiling modules from the library when you don't need to (and 
probably shouldn't be since, I would expect that you'd end up with complaints 
about symbols being defined twice when you link in the library).

- Jonathan M Davis

Prototype DIP11

[Martin Nowak]

I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11

-- Restrictions --
 - It doesn't check for conflicting qualified imports (-Iacme=/path1  
-Iacme.a=/path2)
 - pragma(importpath, "") must come lexically before the  
import

 - Untested on Windows

-- Some outcome --
 - Using '=' in [module.or.package=] could be slightly  
ambiguous for '-Ihttp://acme.org?format=raw'.
 - Url syntax collides with import path lists. Currently it is allowed to  
specify -I/path1/import:/path2/import for POSIX. I've deactivated that for  
now.


   Both can be disambiguated so they are not very severe.

 - Using 'pragma(lib, "someLib")' in an imported source has no effect, as  
long as the imported module is not compiled.
 - Overall this is very limited as even the example below will only  
compile up to a linker error.


-- Testing --
 - build dmd from DIP11 branch
 - get download.py: http://codepad.org/XAvSN505
 - get test.d: http://codepad.org/BILAwzHj
 - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
 - compile: dmd test.d

-- Brainstorming --
We need to define a compilation model for the imported files.

One solution could be to generally change the semantics of importing to  
mean if the
imported file is a source (*.d) build an object for that module if it is a  
header (*.di) don't

build an object and leave it to the user to supply binary data.

If I somehow compile the remote sources I might want to do that including  
debug information.
This would immediately require an offline copy of the sources to work  
properly.


martin

Re: ref parameters: there is no escape

[Marco Leise]

Am 14.08.2011, 21:08 Uhr, schrieb bearophile :

Like in Go, a small tool similar to the one that converts Python2 code  
to Python3 code is getting useful in D too, to reduce the amount of work  
of people (including Phobos dev) that have to update D code to follow  
changed in D language.


Bye,
bearophile


+1 (although with __gshared it would have created some horrible code when  
the change was made :p)

Re: Native Client in Chrome Beta

[Marco Leise]

Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley :


On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise  wrote:

Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley  
:


 On Sat, Aug 13, 2011 at 5:10 AM, bearophile  
**

wrote:

 Found though Reddit. It seems Chrome is starting to warm up to the  
Native

Client (NaCl) idea, the Chrome Beta now has a working NaCl:

http://chrome.blogspot.com/**2011/08/building-better-web-**
apps-with-new.html


http://channel9.msdn.com/**Shows/C9-GoingNative/**
GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti

It's one (the only?) chance to use D in the browser.

Bye,
bearophile


Just thought I'd point out that the previous discussions on NaCl seem  
to

have missed this part of the overview:
"The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is
included in the Native Client SDK. This library is written in C, and  
the

SDK
also provides a set of C++ bindings for it. Native Client modules use  
the

Pepper API to communicate with the browser's JavaScript, the DOM, and
other
resources managed by the browser. The Pepper Library also provides a
platform-independent multimedia API that Native Client modules can use  
for

audio, video, and 2D graphics."

So yes, this is somewhat geared toward multimedia, but it looks like it
can
also replace javascript in web apps.



Is this basically the same as the Java applet interface to the browser
without the "compile once, run everywhere", but with better API?



I haven't ever dealt with the applet interface, but that quote came from
http://code.google.com/chrome/nativeclient/docs/technical_overview.html  
if

you want to take a closer look. The Pepper API docs are there as well.


It doesn't convince me. The driving force seems to be moving desktop  
applications into the browser. That's understandable since a lot of people  
at Google use their web services where possible. I personally don't like  
that centralization on the browser. It adds up on complexity and bugs,  
trying to be an operating system that manages running applications. How do  
they make sure the code is safer than what we know from ActiveX? Even the  
WebGL standard was in the critics, because it was obviously accessing the  
gfx card and a malicious texture upload in a buggy driver could become a  
security risk.
Maybe it finds a way through good advertising or real-time games which run  
faster with native code instead of JavaScript, but there will always be  
some bad memories from http://www.adoko.com/activex.html
At least they take the issue serious :)  
http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702

Re: Why callers should explicitly document storage classes

[Jonathan M Davis]

On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
> > On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
> >> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> >>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  
wrote:
>  requiring lazy before lazy arguments basically destroys the reason
>  for
>  lazy being in the language:
>  
>  int foo(lazy 2*3);
>  
>  is not better than
>  
>  int foo({return 2*3});
> >>> 
> >>> What about requiring "lazy" only for non-pure delegates?
> >> 
> >> Actually I would rather require lazy arguments to be pure, so that
> >> they
> >> can be guaranteed to be executed at most once.
> > 
> > That still wouldn't be guaranteed, since pure function calls are only
> > optimized out if they're strongly pure and in the same expression. You
> > can't rely on calls to pure functions being optimized.
> > 
> > - Jonathan M Davis
> 
> My point was, that if lazy arguments were required to be pure, such a
> thing _could_ then be guaranteed independently from optimizations that
> may or may not take place on general pure functions.

Yes. In theory. It would depend on what Walter was willing to do with the 
language and the compiler though. At present, pure is purely an optimization 
and not use to affect semantics at all.

However, I'd actually argue that lazy delegates should be effectively treated 
as pure anyway. Conceptually, what you're doing is delaying the execution of 
the expression in case it isn't needed. I don't see any reason why the end 
result should be any different from passing a non-lazy argument. As such, the 
lazy argument should only be called once regardless. It wouldn't surprise me 
at all if the implementation doesn't work that way, but I'd argue that it 
should regardless of purity. From the standpoint of the function, the lazy 
argument is just like any other argument in terms of its value, and IMHO it 
should be treated that way.

- Jonathan M Davis

Re: Why callers should explicitly document storage classes

[Timon Gehr]

On 08/14/2011 10:36 PM, Jonathan M Davis wrote:

On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:

On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:

On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:

requiring lazy before lazy arguments basically destroys the reason for
lazy being in the language:

int foo(lazy 2*3);

is not better than

int foo({return 2*3});


What about requiring "lazy" only for non-pure delegates?


Actually I would rather require lazy arguments to be pure, so that they
can be guaranteed to be executed at most once.


That still wouldn't be guaranteed, since pure function calls are only
optimized out if they're strongly pure and in the same expression. You can't
rely on calls to pure functions being optimized.

- Jonathan M Davis


My point was, that if lazy arguments were required to be pure, such a 
thing _could_ then be guaranteed independently from optimizations that 
may or may not take place on general pure functions.

Re: Why callers should explicitly document storage classes

[Simen Kjaeraas]

On Sun, 14 Aug 2011 22:00:34 +0200, Vladimir Panteleev  
 wrote:



On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:

requiring lazy before lazy arguments basically destroys the reason for  
lazy being in the language:


int foo(lazy 2*3);

is not better than

int foo({return 2*3});


What about requiring "lazy" only for non-pure delegates?



I also thought of this idea. Now that pure inference is (being) added to
the language, this seems doable and good.

--
  Simen

Re: Why callers should explicitly document storage classes

[Jonathan M Davis]

On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> > On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:
> >> requiring lazy before lazy arguments basically destroys the reason for
> >> lazy being in the language:
> >> 
> >> int foo(lazy 2*3);
> >> 
> >> is not better than
> >> 
> >> int foo({return 2*3});
> > 
> > What about requiring "lazy" only for non-pure delegates?
> 
> Actually I would rather require lazy arguments to be pure, so that they
> can be guaranteed to be executed at most once.

That still wouldn't be guaranteed, since pure function calls are only 
optimized out if they're strongly pure and in the same expression. You can't 
rely on calls to pure functions being optimized.

- Jonathan M Davis

Re: git gurus: Any way to set it up to auto-warn contributors abouttab indents?

[Jonathan M Davis]

On Sunday, August 14, 2011 16:05:03 Nick Sabalausky wrote:
> "Brad Roberts"  wrote in message
> news:mailman.2309.1313347727.14074.digitalmar...@puremagic.com...
> 
> > google --> git pre-commit hook
> > 
> > Setup whatever sort of checks you want on your local repository and
> > it'll be correct before pushing to github to even get into a pull
> > request.
> 
> That's not really what I was hoping for.
> 
> Here's the problem with that: It's a per-user solution. We can crusade all
> we want with "SET UP A PRE-COMMIT HOOK IN YOUR REPO TO CHECK FOR TABS!!" but
> it'll *never* solve the problem because there will always be people who,
> for whatever reason, don't do that.
> 
> Maybe I didn't word it clearly in the OP, but what I'm suggesting is needed
> is something that *automatically propagates* from the official
> "D-Programming-Language" repos to the local cloned repos. That's the only
> way that the issue is *really* going to be taken care of.

I don't think that you can do that with git. You can setup commit hooks in the 
repository to reject commits which don't fit a particular criteria (like having 
tabs or trailing whitespace), but none of that kind of stuff is actually part 
of the repository. It's in the .git directory. So, commits could be blocked 
from benig merged into the main repository, but pull requests could still have 
the issue, and I don't know if github is able to catch that and tell you that 
the pull request can't be automatically merged. I would _guess_ that it can, 
but it would probably also just tell you that it can't be automatically merged 
and not _why_, so that could be a bit annoying. We could experiment with it, I 
suppose.

But the hooks aren't cloned with the repository, so we can't prevent pull 
requests with tabs.

- Jonathan M Davis

Re: Why callers should explicitly document storage classes

[Timon Gehr]

On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:

On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:


requiring lazy before lazy arguments basically destroys the reason for
lazy being in the language:

int foo(lazy 2*3);

is not better than

int foo({return 2*3});


What about requiring "lazy" only for non-pure delegates?



Actually I would rather require lazy arguments to be pure, so that they 
can be guaranteed to be executed at most once.

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Jonathan M Davis]

On Sunday, August 14, 2011 22:58:37 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 22:50:22 +0300, Jonathan M Davis 
> 
> wrote:
> > Brad's suggestion is the correct way to
> > do it, I believe.
> 
> The advantage of a .gitattributes file is that you can add it to the
> repository (like .gitignore). I don't think you can set up a pre-commit
> hook so that it's copied when the repository is cloned.

You can setup hooks on the server to reject any commits with tabs or trailing 
whitespace or whatnot, but I don't believe that they get copied when you clone 
the repository. However, whether .gitattributes really helps is debatable. It 
does color the diffs, but it won't stop commits, and if you use git-diff -w, 
then it doesn't help at all (which I always do, since I want to see what's 
actually changed, not what's indented differently).

So, we could add .gitattributes, and it would help, but it wouldn't solve the 
problem.

- Jonathan M Davis

Re: Thoughts on std.system.OS

[Vladimir Panteleev]

On Sun, 14 Aug 2011 22:20:01 +0300, Jonathan M Davis   
wrote:


But I do not think that putting that in std.system in an OS-independent  
way makes sense.


OK, I agree with your points. No objections.

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

Re: git gurus: Any way to set it up to auto-warn contributors abouttab indents?

[Nick Sabalausky]

"Brad Roberts"  wrote in message 
news:mailman.2309.1313347727.14074.digitalmar...@puremagic.com...
>
> google --> git pre-commit hook
>
> Setup whatever sort of checks you want on your local repository and
> it'll be correct before pushing to github to even get into a pull
> request.

That's not really what I was hoping for.

Here's the problem with that: It's a per-user solution. We can crusade all 
we want with "SET UP A PRE-COMMIT HOOK IN YOUR REPO TO CHECK FOR TABS!!" but 
it'll *never* solve the problem because there will always be people who, for 
whatever reason, don't do that.

Maybe I didn't word it clearly in the OP, but what I'm suggesting is needed 
is something that *automatically propagates* from the official 
"D-Programming-Language" repos to the local cloned repos. That's the only 
way that the issue is *really* going to be taken care of.

Re: Why callers should explicitly document storage classes

[Vladimir Panteleev]

On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr  wrote:

requiring lazy before lazy arguments basically destroys the reason for  
lazy being in the language:


int foo(lazy 2*3);

is not better than

int foo({return 2*3});


What about requiring "lazy" only for non-pure delegates?

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

Re: Native Client in Chrome Beta

[Andrew Wiley]

On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise  wrote:

> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :
>
>  On Sat, Aug 13, 2011 at 5:10 AM, bearophile **
>> wrote:
>>
>>  Found though Reddit. It seems Chrome is starting to warm up to the Native
>>> Client (NaCl) idea, the Chrome Beta now has a working NaCl:
>>>
>>> http://chrome.blogspot.com/**2011/08/building-better-web-**
>>> apps-with-new.html
>>>
>>>
>>> http://channel9.msdn.com/**Shows/C9-GoingNative/**
>>> GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti
>>>
>>> It's one (the only?) chance to use D in the browser.
>>>
>>> Bye,
>>> bearophile
>>>
>>>
>> Just thought I'd point out that the previous discussions on NaCl seem to
>> have missed this part of the overview:
>> "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is
>> included in the Native Client SDK. This library is written in C, and the
>> SDK
>> also provides a set of C++ bindings for it. Native Client modules use the
>> Pepper API to communicate with the browser's JavaScript, the DOM, and
>> other
>> resources managed by the browser. The Pepper Library also provides a
>> platform-independent multimedia API that Native Client modules can use for
>> audio, video, and 2D graphics."
>>
>> So yes, this is somewhat geared toward multimedia, but it looks like it
>> can
>> also replace javascript in web apps.
>>
>
> Is this basically the same as the Java applet interface to the browser
> without the "compile once, run everywhere", but with better API?
>

I haven't ever dealt with the applet interface, but that quote came from
http://code.google.com/chrome/nativeclient/docs/technical_overview.html if
you want to take a closer look. The Pepper API docs are there as well.

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Vladimir Panteleev]

On Sun, 14 Aug 2011 22:50:22 +0300, Jonathan M Davis   
wrote:



Brad's suggestion is the correct way to
do it, I believe.


The advantage of a .gitattributes file is that you can add it to the  
repository (like .gitignore). I don't think you can set up a pre-commit  
hook so that it's copied when the repository is cloned.


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

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Nick Sabalausky]

"dsimcha"  wrote in message 
news:j295at$1rki$1...@digitalmars.com...
> What's wrong with configuring your editor to convert tabs to spaces?

Because this is a per-project matter, not a universal one. On all of my 
projects, I *want* tabs for indentation (why? because I said so ;) ) and so 
that's how I have my editor set up. But DMD/phobos/etc use spaces. I'm not 
going to switch my normal style just because one project I contribute to 
does it differently, and neither are other people.

> I know CodeBlocks, Vim and Notepad++ do this for you if you configure them 
> right (though I don't remember exactly how to configure Vim to do this). 
> Any other editor worth its salt should, too.  I use this for all my code, 
> not just Phobos.  I prefer to type a tab because it's much easier to type 
> than some specific number of spaces, but I prefer to have spaces in my 
> code because they take up a consistent amount of columns on all viewers, 
> whereas different tab stops can really make your code look messy.
>

I really don't want this to turn into another tabs vs spaces debate. Bottom 
line is, some people prefer tabs, some prefer spaces, and that's just how it 
is. But *both* camps contribute to DMD/phobos/etc which currently leads to 
some oversights in consistency because there's no project-wide automatic 
checking.

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Jonathan M Davis]

On Sunday, August 14, 2011 21:50:29 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 21:48:26 +0300, dsimcha  wrote:
> > What's wrong with configuring your editor to convert tabs to spaces?  I
> > know CodeBlocks, Vim and Notepad++ do this for you if you configure them
> > right (though I don't remember exactly how to configure Vim to do this).
> > 
> >   Any other editor worth its salt should, too.  I use this for all my
> > 
> > code, not just Phobos.  I prefer to type a tab because it's much easier
> > to type than some specific number of spaces, but I prefer to have spaces
> > in my code because they take up a consistent amount of columns on all
> > viewers, whereas different tab stops can really make your code look
> > messy.
> 
> Oh boy, here we go again.
> 
> No, some people prefer to use tabs for their code. If you use them
> correctly (tabs for INDENTATION, spaces for ALIGNMENT), your code will
> look great on all tab widths.

http://www.emacswiki.org/emacs/TabsSpacesBoth :)

In any case, why I'm completly and totally in the camp that thinks that tabs 
should be abolished from the face of the earth, I do understand that some 
people choose to use tabs. So, it's perfectly reasonable to look for a 
solution where git catches it for you. Brad's suggestion is the correct way to 
do it, I believe.

- Jonathan M Davis

Re: Why callers should explicitly document storage classes

[Timon Gehr]

On 08/14/2011 05:36 PM, Vladimir Panteleev wrote:

On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad  wrote:


Consider this example:

// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}

// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
while (!vals.empty)
baz(someCondition(), items.moveFront());
}

There is **absolutely NO WAY** to figure out what's wrong at the
calling site. You need to check /every/ method call and make sure
nothing weird is happening (e.g. lazy), and it's pretty much
impossible to figure it out unless you're intimately familiar with the
entire library you're calling -- something which (obviously) doesn't
scale.

I don't know of a similar example off the top of my head for out/ref,
but the same idea applies.

Is this convincing enough that we need to document storage classes at
the CALLING site, rather than just the CALLEE site?


I've raised this issue during voting for std.parallelism. I think the
consensus was that "lazy" before lazy arguments would be appropriate,
but "ref" would be mostly pointless, due to complex and reference types.



requiring lazy before lazy arguments basically destroys the reason for 
lazy being in the language:


int foo(lazy 2*3);

is not better than

int foo({return 2*3});

Re: Thoughts on std.system.OS

[Jonathan M Davis]

On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis 
> 
> wrote:
> > Personally, I'm
> > inclined to drop the Os enum along with the os and os_major and os_minor
> > variables, because I just don't think that we can get them to be correct
> > enough of generally useful enough to be worth having. It's too
> > OS-specific to
> > be trying to handle it in an OS-generic manner like that.
> 
> Looking at the code again, I noticed there's a Family enum, which seems to
> me closer to what the OS enum should really be. I think Family should just
> replace OS.
> 
> I don't agree that we should just drop version numbers. As I said before,
> they can be useful for users. They can also be useful for programs that
> care only about a certain OS family.
> 
> What do you think about this?
> 
> https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d

I'm not at all convinced that it makes any sense to try and handle OS version 
numbers in a system-independent manner. You have to know what OS you're on for 
them to mean anything, in which case, why try and handle them in an OS-
independent manner?

On Linux, the version number is probably pointless. It's the version number 
for the kernel. Most programs won't care one whit about that. If they care 
about a version number, odds are that it's the version number of some program 
or library on the system that they're using, not the kernel. And in general, 
if you care, you care when you compile, not when you run the program. I would 
expect FreeBSD to be the same. I don't know about Mac OS X.

However, the case of Windows is _completely_ different from the others. Windows 
version numbers mean _nothing_ to most people. They want stuff like Windows XP 
and Windows 7. They'd probably expect an enum with the primary versions of 
Windows in it. But since there _are_ other stray versions of Windows, and the 
actual version number could matter for some stuff, finding a clean way to deal 
with Windows' GetVersion call and dealing with the full version number and at 
the same time dealing with the more commonly useful enum needs to happen (as 
part of that, the enum would probably use the version numbers for the values 
of its enum members similar to what you did with you constants). It's all 
_very_ different from Linux, FreeBSD, and Mac OS X. And I don't see _any_ 
reason to try and treat them the same.

If we're going to deal with operating system versions, it should be in a 
system-specific manner and _not_ in std.system.

Endian is effectively a runtime enum for the versions which deal with 
endianness. Family is effectively the runtime enum for the OS versions. As 
such, I think that both have some value. I do think that you have a valid 
point that OS would be a better name for Family, so I'll make that change in 
my pull request. However, I do _not_ think that it makes sense to try and do 
getOSVersion like you're doing.

We need to find a clean, simple and yet flexible way to deal with version 
numbers for Windows and put that in std.windows or core.windows somewhere - 
preferably in core IMHO (and actually I'd be kind of inclined to put 
std.system  in core rather than std given what it's doing). If something 
similar for the Mac makes sense, then we can add that somewhere. For Linux and 
FreeBSD, I expect that there's no point - particularly since I'm not sure that 
it's quite safe to trust uname to be consistent anyway. But I do not think 
that putting that in std.system in an OS-independent way makes sense.

- Jonathan M Davis

Re: ref parameters: there is no escape

[bearophile]

Andrei Alexandrescu:

> We found pernicious bugs in 
> our code caused by escaping reference parameters, and we're looking into 
> adding a rule in our lint program to statically disallow it. If that's 
> worthwhile (and I have evidence it is), then it's all the better to put 
> the check straight in the language.

Another possibility is to add it to an experimental branch of DMD, study its 
use and effects for some time, and then decide what to do of this idea.


> We talked about this, too. I even aired ~scope. Such a change would be
> doable but is liable to break a lot of code.

It's interesting to know how much code and how much hard the changes are to do.

Like in Go, a small tool similar to the one that converts Python2 code to 
Python3 code is getting useful in D too, to reduce the amount of work of people 
(including Phobos dev) that have to update D code to follow changed in D 
language.

Bye,
bearophile

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Vladimir Panteleev]

On Sun, 14 Aug 2011 21:48:26 +0300, dsimcha  wrote:

What's wrong with configuring your editor to convert tabs to spaces?  I  
know CodeBlocks, Vim and Notepad++ do this for you if you configure them  
right (though I don't remember exactly how to configure Vim to do this).  
  Any other editor worth its salt should, too.  I use this for all my  
code, not just Phobos.  I prefer to type a tab because it's much easier  
to type than some specific number of spaces, but I prefer to have spaces  
in my code because they take up a consistent amount of columns on all  
viewers, whereas different tab stops can really make your code look  
messy.


Oh boy, here we go again.

No, some people prefer to use tabs for their code. If you use them  
correctly (tabs for INDENTATION, spaces for ALIGNMENT), your code will  
look great on all tab widths.


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

Re: ref parameters: there is no escape

[Michel Fortin]

On 2011-08-14 16:55:08 +, dsimcha  said:

Right, but they can be proven safe if they pass locals by ref **to 
@safe functions**.  I don't think there's any disagreement that @safe 
functions shouldn't be allowed to take the address of locals or 
parameters.


Actually, no, that's not safe by itself. Consider this:

ref int foo(ref int a) @safe
{
return a;
}

ref int bar() @safe
{
int a;
return foo(a);
}

And now 'bar' returns its local variable 'a' by ref, thanks to the 
complicity of 'foo'. All this unsafety is perfectly @safe.


I think a @safe function shouldn't be allowed to return by ref one of 
its parameter.



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

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Vladimir Panteleev]

On Sun, 14 Aug 2011 21:36:28 +0300, Nick Sabalausky  wrote:


I don't know if this has already been looked into, but to any git/github
gurus here: Is there some way to set up the "D-Programming-Language"
projects (either in git or in github) so that users get warned when they
have tab indents and try to commit, push, or pull-request (any one of  
those

three, wouldn't need to be all three of them)?


Yes. You can create a .gitattributes file with the following line:

*.d whitespace=blank-at-eol,space-before-tab,tab-in-indent

This will color tabs used for indentation and trailing whitespace as red  
in diffs (and git gui).


More information:

http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_whitespace_errors

http://www.kernel.org/pub/software/scm/git/docs/git-config.html - scroll  
down to core.whitespace


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

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[dsimcha]

What's wrong with configuring your editor to convert tabs to spaces?  I 
know CodeBlocks, Vim and Notepad++ do this for you if you configure them 
right (though I don't remember exactly how to configure Vim to do this). 
 Any other editor worth its salt should, too.  I use this for all my 
code, not just Phobos.  I prefer to type a tab because it's much easier 
to type than some specific number of spaces, but I prefer to have spaces 
in my code because they take up a consistent amount of columns on all 
viewers, whereas different tab stops can really make your code look messy.


On 8/14/2011 2:36 PM, Nick Sabalausky wrote:

Ok, I'm one of the "tab-indent" fans, and obviously there are others out
there. So in contributing some pull requests to phobos/rdmd I've noticed how
easy it is to forget to convert tabs->spaces before pushing. And others make
the same mistake too. Aside from being an inconsistent syle issue, this
seems to increase the chances of merge conflicts.

Obviously I could set up some script on my end to auto-check before
committing, but that's a per-user solution and so wouldn't really help the
overall problem. Plus it probably wouldn't work with the GUI git tools like
tortoise.

I don't know if this has already been looked into, but to any git/github
gurus here: Is there some way to set up the "D-Programming-Language"
projects (either in git or in github) so that users get warned when they
have tab indents and try to commit, push, or pull-request (any one of those
three, wouldn't need to be all three of them)?

---
Not sent from an iPhone.

Re: git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Brad Roberts]

On Sunday, August 14, 2011 11:36:28 AM, Nick Sabalausky wrote:
> Ok, I'm one of the "tab-indent" fans, and obviously there are others out 
> there. So in contributing some pull requests to phobos/rdmd I've noticed how 
> easy it is to forget to convert tabs->spaces before pushing. And others make 
> the same mistake too. Aside from being an inconsistent syle issue, this 
> seems to increase the chances of merge conflicts.
> 
> Obviously I could set up some script on my end to auto-check before 
> committing, but that's a per-user solution and so wouldn't really help the 
> overall problem. Plus it probably wouldn't work with the GUI git tools like 
> tortoise.
> 
> I don't know if this has already been looked into, but to any git/github 
> gurus here: Is there some way to set up the "D-Programming-Language" 
> projects (either in git or in github) so that users get warned when they 
> have tab indents and try to commit, push, or pull-request (any one of those 
> three, wouldn
't need to be all three of them)?
> 
> ---
> Not sent from an iPhone.

google --> git pre-commit hook

Setup whatever sort of checks you want on your local repository and 
it'll be correct before pushing to github to even get into a pull 
request.

git gurus: Any way to set it up to auto-warn contributors about tab indents?

[Nick Sabalausky]

Ok, I'm one of the "tab-indent" fans, and obviously there are others out 
there. So in contributing some pull requests to phobos/rdmd I've noticed how 
easy it is to forget to convert tabs->spaces before pushing. And others make 
the same mistake too. Aside from being an inconsistent syle issue, this 
seems to increase the chances of merge conflicts.

Obviously I could set up some script on my end to auto-check before 
committing, but that's a per-user solution and so wouldn't really help the 
overall problem. Plus it probably wouldn't work with the GUI git tools like 
tortoise.

I don't know if this has already been looked into, but to any git/github 
gurus here: Is there some way to set up the "D-Programming-Language" 
projects (either in git or in github) so that users get warned when they 
have tab indents and try to commit, push, or pull-request (any one of those 
three, wouldn't need to be all three of them)?

---
Not sent from an iPhone.

Re: ref parameters: there is no escape

[dsimcha]

On 8/14/2011 1:05 PM, Andrei Alexandrescu wrote:

Pass-by-pointer is really, really ugly when used in high-level D-style
code, and exposes the implementation detail that the D wrapper is using
C code. By explicit cast, do you mean one in dWrapper() that's
encapsulated and invisible to the caller?


Yah, dWrapper would become:

void dWrapper(ref int a, ref int b) {
cFun(cast(int*) &a, cast(int*) &b);
}

If the casts are missing, the compiler's error message could clarify
under what assumptions they might be inserted.


Ok, IIUC we might have found some common ground here.  Is the idea that, 
if you insert the cast, then it's an unsafe cast and you're free to take 
the address of a ref parameter, period?  I think this is a reasonable 
compromise:


1.  There's enormous precedent for the idea that casts are for things 
you **probably** shouldn't be doing but may occasionally have a good 
reason to do.


2.  It's greppable, unlike the status quo, where there's no easy way to 
search for possible escaping of addresses of ref parameters.


3.  It solves the encapsulation problem mentioned in my previous post.

4.  It can be disallowed in SafeD as an unsafe cast.

5.  If you allow taking the address of ref parameters without a cast as 
long as the compiler can prove that they don't escape, then performing 
this type of cast is a very explicit statement that you **know** the 
compiler can't prove that those addresses don't escape and that you take 
full responsibility for ensuring they don't.


6.  It may eventually lead to a more comprehensive ownership type system 
similar to one that's been discussed here before, where there's 
ScopedPointers and regular pointers.  A ScopedPointer is a super type of 
a regular pointer, isn't allowed to escape from where it was created, etc.


Bottom line:  I completely agree that escaping addresses of ref 
parameters is a terrible design.  I'm fine with making constructs that 
have the potential to do so more verbose and explicit by requiring 
casts.  However, I am against disallowing it completely for the 
following reasons:


1.  The rules against it would have to be conservative, meaning at least 
some valid designs are tossed out as well.  This is completely 
unacceptable in a systems language.


2.  I'm not convinced that escaping addresses of ref parameters is at 
all easy to do by accident.


3.  In a systems language the compiler should **never** go out of its 
way to completely disallow a design, no matter how bad that design is. 
A language is a tool that should do what the user tells it to, not a 
nanny that should prevent the user from being naughty.  (Though this 
does not preclude the compiler making it hard to do bad things **by 
accident**.)  I don't care if said design is wholeheartedly endorsed by 
The Devil himself.

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 12:39 PM, dsimcha wrote:

On 8/14/2011 1:05 PM, Andrei Alexandrescu wrote:

Pass-by-pointer is really, really ugly when used in high-level D-style
code, and exposes the implementation detail that the D wrapper is using
C code. By explicit cast, do you mean one in dWrapper() that's
encapsulated and invisible to the caller?


Yah, dWrapper would become:

void dWrapper(ref int a, ref int b) {
cFun(cast(int*) &a, cast(int*) &b);
}

If the casts are missing, the compiler's error message could clarify
under what assumptions they might be inserted.


Ok, IIUC we might have found some common ground here. Is the idea that,
if you insert the cast, then it's an unsafe cast and you're free to take
the address of a ref parameter, period?

[snip]

Everything sounds great, thanks.

Andrei

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 12:12 PM, dsimcha wrote:

On 8/14/2011 1:06 PM, Andrei Alexandrescu wrote:

You are exploring an increasingly narrow niche. Is it worth keeping a
hole in the language for the sake of that?

Andrei


Yes!!! Such conservative and inflexible rules have no place in a systems
language, period.


I see. Do you have a response to any of the arguments I brought? Among 
other things, does the fact that you still can do what you want to do 
assuage your perceived inconvenience?


Andrei

Re: Native Client in Chrome Beta

[Marco Leise]

Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :

On Sat, Aug 13, 2011 at 5:10 AM, bearophile  
wrote:


Found though Reddit. It seems Chrome is starting to warm up to the  
Native

Client (NaCl) idea, the Chrome Beta now has a working NaCl:

http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html


http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti

It's one (the only?) chance to use D in the browser.

Bye,
bearophile



Just thought I'd point out that the previous discussions on NaCl seem to
have missed this part of the overview:
"The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is
included in the Native Client SDK. This library is written in C, and the  
SDK

also provides a set of C++ bindings for it. Native Client modules use the
Pepper API to communicate with the browser's JavaScript, the DOM, and  
other

resources managed by the browser. The Pepper Library also provides a
platform-independent multimedia API that Native Client modules can use  
for

audio, video, and 2D graphics."

So yes, this is somewhat geared toward multimedia, but it looks like it  
can

also replace javascript in web apps.


Is this basically the same as the Java applet interface to the browser  
without the "compile once, run everywhere", but with better API?

Re: Should we add drop to Phobos?

[Marco Leise]

Am 14.08.2011, 14:45 Uhr, schrieb Timon Gehr :

I'd argue that find should actually have been called dropUntil. It is  
not evident at all what find does, given the name alone. If it is called  
dropUntil, nobody ever needs to read the documentation, be it the guy  
who writes the code or the guy who has to read it. But as it is probably  
heavily used, it is not sensible renaming it now. (and all I have to do  
is define an alias :))


When I first came across find I expected it to find a single item.  
dropUntil makes more sense to me, too.

Re: ref parameters: there is no escape

[dsimcha]

On 8/14/2011 1:06 PM, Andrei Alexandrescu wrote:

You are exploring an increasingly narrow niche. Is it worth keeping a
hole in the language for the sake of that?

Andrei


Yes!!!  Such conservative and inflexible rules have no place in a 
systems language, period.

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 12:02 PM, dsimcha wrote:

On 8/14/2011 12:54 PM, Andrei Alexandrescu wrote:

I have only little sympathy for this argument; it actually leaves me
more convinced we're on the right path. We're not talking about making
it impossible to do something that you want to do. We're discussing
about a change that will make a lot of functions efficient _and_ safe,
leaving a minority of cases to a slight syntactic change.


Andrei


But this breaks encapsulation horribly in the presence of conservative
rules. Let's say you start off with a function:

SomeType fun(ref T arg) {  }

Then you change fun()'s implementation such that it takes the address of
arg. It does **not** escape this address, so the fact that the address
is taken is an implementation detail. However, since the compiler's
rules are conservative, this code would might be illegal if the compiler
can't prove via its static analysis that the addresses don't escape.
Bam! Implementation details leaking into function signatures.


You are exploring an increasingly narrow niche. Is it worth keeping a 
hole in the language for the sake of that?


Andrei

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 11:55 AM, dsimcha wrote:

Argh, accidentally hit send before I meant to on my last post. Please
ignore.

On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:

Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);

// D:
void dWrapper(ref int a, ref int b) {
cFun(&a, &b);
}


I understand. Probably it's fine to require an explicit cast for taking
the address. Offhand, I don't see this as a frequent situation, or one
that would make pass-by-pointer unpalatable.


Pass-by-pointer is really, really ugly when used in high-level D-style
code, and exposes the implementation detail that the D wrapper is using
C code. By explicit cast, do you mean one in dWrapper() that's
encapsulated and invisible to the caller?


Yah, dWrapper would become:

void dWrapper(ref int a, ref int b) {
  cFun(cast(int*) &a, cast(int*) &b);
}

If the casts are missing, the compiler's error message could clarify 
under what assumptions they might be inserted.



If you want the compiler to put extra restrictions on you in the name of
safety, that's what SafeD is for. If you're writing an @system function,
then the compiler should stay out of your way and let you do what you
want, unless it can **prove** that it's wrong.


The problem is, currently all functions that pass locals by ref cannot
be proven safe modularly.



Right, but they can be proven safe if they pass locals by ref **to @safe
functions**. I don't think there's any disagreement that @safe functions
shouldn't be allowed to take the address of locals or parameters.


We don't have that rule yet, but we can enact it. I strongly believe it 
would help if we enacted the "unescapable ref" rule for all D code. It 
disallows a patently dangerous pattern that many C++ coding standards 
(including Facebook's) explicitly disallow. We found pernicious bugs in 
our code caused by escaping reference parameters, and we're looking into 
adding a rule in our lint program to statically disallow it. If that's 
worthwhile (and I have evidence it is), then it's all the better to put 
the check straight in the language.



Andrei

Re: ref parameters: there is no escape

[dsimcha]

On 8/14/2011 12:54 PM, Andrei Alexandrescu wrote:

I have only little sympathy for this argument; it actually leaves me
more convinced we're on the right path. We're not talking about making
it impossible to do something that you want to do. We're discussing
about a change that will make a lot of functions efficient _and_ safe,
leaving a minority of cases to a slight syntactic change.


Andrei


But this breaks encapsulation horribly in the presence of conservative 
rules.  Let's say you start off with a function:


SomeType fun(ref T arg) {   }

Then you change fun()'s implementation such that it takes the address of 
arg.  It does **not** escape this address, so the fact that the address 
is taken is an implementation detail.  However, since the compiler's 
rules are conservative, this code would might be illegal if the compiler 
can't prove via its static analysis that the addresses don't escape. 
Bam!  Implementation details leaking into function signatures.

Re: ref parameters: there is no escape

[dsimcha]

Argh, accidentally hit send before I meant to on my last post.  Please 
ignore.


On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:

Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);

// D:
void dWrapper(ref int a, ref int b) {
cFun(&a, &b);
}


I understand. Probably it's fine to require an explicit cast for taking
the address. Offhand, I don't see this as a frequent situation, or one
that would make pass-by-pointer unpalatable.


Pass-by-pointer is really, really ugly when used in high-level D-style 
code, and exposes the implementation detail that the D wrapper is using 
C code.  By explicit cast, do you mean one in dWrapper() that's 
encapsulated and invisible to the caller?





If you want the compiler to put extra restrictions on you in the name of
safety, that's what SafeD is for. If you're writing an @system function,
then the compiler should stay out of your way and let you do what you
want, unless it can **prove** that it's wrong.


The problem is, currently all functions that pass locals by ref cannot
be proven safe modularly.



Right, but they can be proven safe if they pass locals by ref **to @safe 
functions**.  I don't think there's any disagreement that @safe 
functions shouldn't be allowed to take the address of locals or parameters.

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 11:51 AM, dsimcha wrote:

On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:

On 8/14/11 10:28 AM, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.


I'm weary of absolute qualifications, particularly after arguments have
been made in favor of the idea that are not refuted.


What do you mean "absolute qualifications"?


"absolutely terrible"

Andrei

Re: ref parameters: there is no escape

[dsimcha]

On 8/14/2011 12:45 PM, Andrei Alexandrescu wrote:

Exactly. Using scope has been part of the discussion, and our agreement
was that it would be a lot of burden to require manual scope annotations
for non-escaping parameters.

Andrei


Let's assume for the sake of argument that scope is part of the game. 
(How) would it be checked?

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 11:50 AM, Jacob Carlborg wrote:

On 2011-08-14 18:45, Andrei Alexandrescu wrote:

On 8/14/11 10:33 AM, Jakob Ovrum wrote:

On 2011/08/15 0:28, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the
case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler
doesn't.
void cFun(int* a, int* b);


What if it was allowed if the parameters were explicitly marked scope?

void cFun(scope int* a, scope int* b);

I can imagine it being a proper inconvenience most of the time though,
with many libraries not escaping a lot at all, you'd have to mark pretty
much everything scope manually.


Exactly. Using scope has been part of the discussion, and our agreement
was that it would be a lot of burden to require manual scope annotations
for non-escaping parameters.

Andrei


Can we do the opposite, somehow indicating that the parameters might
escape?


We talked about this, too. I even aired ~scope. Such a change would be 
doable but is liable to break a lot of code.


Andrei

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 10:41 AM, dsimcha wrote:

Another example of why this is a bad idea:

In std.parallelism, I have a function called TaskPool.put, which takes a
Task object by reference, takes its address and puts it on the task
queue. This is used for scoped tasks. However, it's safe because Task
has a destructor that waits for the task to be finished and out of the
task queue before destroying the stack frame it's on and returning.


I understand. Would it be agreeable to require a cast to take the 
address of the parameter since you're relying on an extralinguistic 
invariant? Basically you'd be more motivated to do so if you recognized 
how problematic escaping ref parameters is for most cases.



Why can't we just establish a strong convention that, if a function
truly escapes the address of a ref parameter (meaning it actually lives
longer than the lifetime of the function), you take a pointer instead of
a ref? It's not like escaping ref parameters unintentionally is a common
source of bugs.


Convention has its usefulness, but also major downsides. The problem 
here is that we can't verify (or infer) @safe for a lot of functions. 
Basically all functions taking ref become very difficult to use from 
safe code, including the common idiom of passing a stack variable into a 
function by reference. I don't think we can afford to lose so much when 
turning safety on.



My point is that any rule we come up with will always be conservative. D
is a **systems language** and needs to give the benefit of the doubt to
assuming the programmer knows what he/she is doing. If you want extra
checks, that's what SafeD is for.


I have only little sympathy for this argument; it actually leaves me 
more convinced we're on the right path. We're not talking about making 
it impossible to do something that you want to do. We're discussing 
about a change that will make a lot of functions efficient _and_ safe, 
leaving a minority of cases to a slight syntactic change.



Andrei

Re: ref parameters: there is no escape

[Jacob Carlborg]

On 2011-08-14 18:45, Andrei Alexandrescu wrote:

On 8/14/11 10:33 AM, Jakob Ovrum wrote:

On 2011/08/15 0:28, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);


What if it was allowed if the parameters were explicitly marked scope?

void cFun(scope int* a, scope int* b);

I can imagine it being a proper inconvenience most of the time though,
with many libraries not escaping a lot at all, you'd have to mark pretty
much everything scope manually.


Exactly. Using scope has been part of the discussion, and our agreement
was that it would be a lot of burden to require manual scope annotations
for non-escaping parameters.

Andrei


Can we do the opposite, somehow indicating that the parameters might escape?

--
/Jacob Carlborg

Re: ref parameters: there is no escape

[dsimcha]

On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:

On 8/14/11 10:28 AM, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.


I'm weary of absolute qualifications, particularly after arguments have
been made in favor of the idea that are not refuted.


What do you mean "absolute qualifications"?




Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);

// D:
void dWrapper(ref int a, ref int b) {
cFun(&a, &b);
}


I understand. Probably it's fine to require an explicit cast for taking
the address. Offhand, I don't see this as a frequent situation, or one
that would make pass-by-pointer unpalatable.


Pass-by-



If you want the compiler to put extra restrictions on you in the name of
safety, that's what SafeD is for. If you're writing an @system function,
then the compiler should stay out of your way and let you do what you
want, unless it can **prove** that it's wrong.


The problem is, currently all functions that pass locals by ref cannot
be proven safe modularly.


Right, but they can be proven safe if they pass locals by ref **to @safe 
functions**.  I don't think there's any disagreement that @safe 
functions shouldn't be allowed to take the address of locals or parameters.

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 10:33 AM, Jakob Ovrum wrote:

On 2011/08/15 0:28, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);


What if it was allowed if the parameters were explicitly marked scope?

void cFun(scope int* a, scope int* b);

I can imagine it being a proper inconvenience most of the time though,
with many libraries not escaping a lot at all, you'd have to mark pretty
much everything scope manually.


Exactly. Using scope has been part of the discussion, and our agreement 
was that it would be a lot of burden to require manual scope annotations 
for non-escaping parameters.


Andrei

Re: ref parameters: there is no escape

[Andrei Alexandrescu]

On 8/14/11 10:28 AM, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.


I'm weary of absolute qualifications, particularly after arguments have 
been made in favor of the idea that are not refuted.



Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);

// D:
void dWrapper(ref int a, ref int b) {
cFun(&a, &b);
}


I understand. Probably it's fine to require an explicit cast for taking 
the address. Offhand, I don't see this as a frequent situation, or one 
that would make pass-by-pointer unpalatable.



If you want the compiler to put extra restrictions on you in the name of
safety, that's what SafeD is for. If you're writing an @system function,
then the compiler should stay out of your way and let you do what you
want, unless it can **prove** that it's wrong.


The problem is, currently all functions that pass locals by ref cannot 
be proven safe modularly.



Andrei

Re: Do multilanguage application

[Sean Kelly]

For serious i18n work I'd use ICU. I believe Mango even has a wrapper for some 
of it. 

Sent from my iPhone

On Aug 14, 2011, at 8:50 AM, Johannes Pfau  wrote:

> Jacob Carlborg wrote:
>> On 2011-08-12 23:02, bioinfornatics wrote:
>>> Dear,
>>> I would like to know how do a multilanguage application. It seem it
>>> is possible by using flag -J but they are no document for this
>>> feature. link givent in this page
>>> http://www.digitalmars.com/d/2.0/dmd-linux.html seem to be wrong
>>> 
>>> if you can do a little example, will be nice
>>> 
>>> thanks
>>> 
>>> kind regards
>> 
>> It's fairly simple. You just need a file containing keys and values. 
>> This file can be read either at compile time or runtime. Read the file 
>> into an associative array and when you need a piece of text translated 
>> just pass the key to a function which retries the corresponding value 
>> from the associative array.
> 
> I think the std.string functions tr, translate, maketrans are meant to
> do that.
> But there's a lot more to proper i18n and even for translation a simple
> key/value table isn't perfect.
> gettext for example also handles plural forms and context information.
> (A translation might be different depending on it's context.)
> 
> Implementing all this stuff can get quite difficult, just have a look
> at the plural formulas for different languages:
> http://translate.sourceforge.net/wiki/l10n/pluralforms
> 
>> 
>> You could take a look at how internalization is don in Ruby on Rails, 
>> this can be applied to D as well:
>> http://guides.rubyonrails.org/i18n.html
>> 
> 
> 
> -- 
> Johannes Pfau
> 

Re: Thoughts on std.system.OS

[Vladimir Panteleev]

On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis   
wrote:



Personally, I'm
inclined to drop the Os enum along with the os and os_major and os_minor
variables, because I just don't think that we can get them to be correct
enough of generally useful enough to be worth having. It's too  
OS-specific to

be trying to handle it in an OS-generic manner like that.


Looking at the code again, I noticed there's a Family enum, which seems to  
me closer to what the OS enum should really be. I think Family should just  
replace OS.


I don't agree that we should just drop version numbers. As I said before,  
they can be useful for users. They can also be useful for programs that  
care only about a certain OS family.


What do you think about this?

https://github.com/CyberShadow/phobos/blob/new-std-system/std/system.d

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

Re: Do multilanguage application

[Johannes Pfau]

Jacob Carlborg wrote:
>On 2011-08-12 23:02, bioinfornatics wrote:
>> Dear,
>> I would like to know how do a multilanguage application. It seem it
>> is possible by using flag -J but they are no document for this
>> feature. link givent in this page
>> http://www.digitalmars.com/d/2.0/dmd-linux.html seem to be wrong
>>
>> if you can do a little example, will be nice
>>
>> thanks
>>
>> kind regards
>
>It's fairly simple. You just need a file containing keys and values. 
>This file can be read either at compile time or runtime. Read the file 
>into an associative array and when you need a piece of text translated 
>just pass the key to a function which retries the corresponding value 
>from the associative array.

I think the std.string functions tr, translate, maketrans are meant to
do that.
But there's a lot more to proper i18n and even for translation a simple
key/value table isn't perfect.
gettext for example also handles plural forms and context information.
(A translation might be different depending on it's context.)

Implementing all this stuff can get quite difficult, just have a look
at the plural formulas for different languages:
http://translate.sourceforge.net/wiki/l10n/pluralforms

>
>You could take a look at how internalization is don in Ruby on Rails, 
>this can be applied to D as well:
>http://guides.rubyonrails.org/i18n.html
>


-- 
Johannes Pfau

Re: Do multilanguage application

[Jacob Carlborg]

On 2011-08-12 23:02, bioinfornatics wrote:

Dear,
I would like to know how do a multilanguage application. It seem it is possible 
by using flag -J but they are no document for this feature.
link givent in this page http://www.digitalmars.com/d/2.0/dmd-linux.html seem 
to be wrong

if you can do a little example, will be nice

thanks

kind regards


It's fairly simple. You just need a file containing keys and values. 
This file can be read either at compile time or runtime. Read the file 
into an associative array and when you need a piece of text translated 
just pass the key to a function which retries the corresponding value 
from the associative array.


You could take a look at how internalization is don in Ruby on Rails, 
this can be applied to D as well: http://guides.rubyonrails.org/i18n.html


--
/Jacob Carlborg

Re: ref parameters: there is no escape

[dsimcha]

Another example of why this is a bad idea:

In std.parallelism, I have a function called TaskPool.put, which takes a 
Task object by reference, takes its address and puts it on the task 
queue.  This is used for scoped tasks.  However, it's safe because Task 
has a destructor that waits for the task to be finished and out of the 
task queue before destroying the stack frame it's on and returning.


Why can't we just establish a strong convention that, if a function 
truly escapes the address of a ref parameter (meaning it actually lives 
longer than the lifetime of the function), you take a pointer instead of 
a ref?  It's not like escaping ref parameters unintentionally is a 
common source of bugs.


My point is that any rule we come up with will always be conservative. 
D is a **systems language** and needs to give the benefit of the doubt 
to assuming the programmer knows what he/she is doing.  If you want 
extra checks, that's what SafeD is for.


On 8/14/2011 10:20 AM, Andrei Alexandrescu wrote:

Walter and I have had a long discussion and we thought we'd bring an
idea for community review.

We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:

class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref parameter
}
}

Such code is accepted today. We believe it is error-prone and dangerous,
particularly because the caller has no syntactic cue that the address of
the parameter is passed into the function (in this case constructor).
Worse, such a function cannot be characterized as @safe.

So we want to make the above an error. The workaround is obvious - just
take int* as a parameter instead of ref int. What a function can do with
a ref parameter in general is:

* use it directly just like a local;

* pass it down to other functions (which may take it by value or
reference);

* pass its address down to pure functions because a pure function cannot
escape the address anyway (cool insight by Walter);

* take its address as long as the address doesn't outlive the frame of
the function.

The third bullet is not easy to implement as it requires flow analysis,
but we may start with a conservative version first. Probably there won't
be a lot of broken code anyway.

Please chime in with any comments you might have!


Thanks,

Andrei

Re: Why callers should explicitly document storage classes

[Vladimir Panteleev]

On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad  wrote:


Consider this example:

 // In module foo.d:
 void baz(bool condition, lazy int value)
 {
 if (condition)
 writeln(value);
 }

 // In module bar.d:
 import foo;
 bool someCondition() { return false; }
 void main()
 {
 auto vals = [1, 2, 3, 4];
 while (!vals.empty)
 baz(someCondition(), items.moveFront());
 }

There is **absolutely NO WAY** to figure out what's wrong at the calling  
site. You need to check /every/ method call and make sure nothing weird  
is happening (e.g. lazy), and it's pretty much impossible to figure it  
out unless you're intimately familiar with the entire library you're  
calling -- something which (obviously) doesn't scale.


I don't know of a similar example off the top of my head for out/ref,  
but the same idea applies.


Is this convincing enough that we need to document storage classes at  
the CALLING site, rather than just the CALLEE site?


I've raised this issue during voting for std.parallelism. I think the  
consensus was that "lazy" before lazy arguments would be appropriate, but  
"ref" would be mostly pointless, due to complex and reference types.


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

Re: ref parameters: there is no escape

[Jacob Carlborg]

On 2011-08-14 16:20, Andrei Alexandrescu wrote:

Walter and I have had a long discussion and we thought we'd bring an
idea for community review.

We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:

class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref parameter
}
}

Such code is accepted today. We believe it is error-prone and dangerous,
particularly because the caller has no syntactic cue that the address of
the parameter is passed into the function (in this case constructor).
Worse, such a function cannot be characterized as @safe.

So we want to make the above an error. The workaround is obvious - just
take int* as a parameter instead of ref int. What a function can do with
a ref parameter in general is:

* use it directly just like a local;

* pass it down to other functions (which may take it by value or
reference);

* pass its address down to pure functions because a pure function cannot
escape the address anyway (cool insight by Walter);

* take its address as long as the address doesn't outlive the frame of
the function.

The third bullet is not easy to implement as it requires flow analysis,
but we may start with a conservative version first. Probably there won't
be a lot of broken code anyway.

Please chime in with any comments you might have!


Thanks,

Andrei


I have code relying on this, probably not could practice but it works. 
This is a usage example:


void main ()
{
int i = 3;

restore(i) in {
i = 4;
};

assert(i == 3);
}

Restore returns a struct which overloads the "in" operator and stores a 
pointer to the value pass to "restore". I'm overloading the "in" 
operator have a nicer looking delegate syntax. But I guess this could be 
seen as operator overload abuse. If D just could have a good looking 
syntax for delegate literals, like this:


restore(i) {
i = 4;
}

Then this wouldn't be needed.

--
/Jacob Carlborg

Re: ref parameters: there is no escape

[Jakob Ovrum]

On 2011/08/15 0:28, dsimcha wrote:

I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for C functionality.

// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);


What if it was allowed if the parameters were explicitly marked scope?

void cFun(scope int* a, scope int* b);

I can imagine it being a proper inconvenience most of the time though, 
with many libraries not escaping a lot at all, you'd have to mark pretty 
much everything scope manually.

Re: ref parameters: there is no escape

[dsimcha]

I think this is an absolutely terrible idea, unless it has an "I know 
what I'm doing, let me cast away the safety" loophole.  Consider the 
case of designing a D wrapper for C functionality.


// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);

// D:
void dWrapper(ref int a, ref int b) {
cFun(&a, &b);
}

If you want the compiler to put extra restrictions on you in the name of 
safety, that's what SafeD is for.  If you're writing an @system 
function, then the compiler should stay out of your way and let you do 
what you want, unless it can **prove** that it's wrong.


On 8/14/2011 10:20 AM, Andrei Alexandrescu wrote:

Walter and I have had a long discussion and we thought we'd bring an
idea for community review.

We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:

class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref parameter
}
}

Such code is accepted today. We believe it is error-prone and dangerous,
particularly because the caller has no syntactic cue that the address of
the parameter is passed into the function (in this case constructor).
Worse, such a function cannot be characterized as @safe.

So we want to make the above an error. The workaround is obvious - just
take int* as a parameter instead of ref int. What a function can do with
a ref parameter in general is:

* use it directly just like a local;

* pass it down to other functions (which may take it by value or
reference);

* pass its address down to pure functions because a pure function cannot
escape the address anyway (cool insight by Walter);

* take its address as long as the address doesn't outlive the frame of
the function.

The third bullet is not easy to implement as it requires flow analysis,
but we may start with a conservative version first. Probably there won't
be a lot of broken code anyway.

Please chime in with any comments you might have!


Thanks,

Andrei

Re: ref parameters: there is no escape

[kennytm]

Andrei Alexandrescu  wrote:
> Walter and I have had a long discussion and we thought we'd bring an idea
> for community review.
> 
> We believe it would be useful for safety purposes to disallow escaping
> addresses of ref parameters. Consider:
> 
> class C {
>   int * p;
>   this(ref int x) {
> p = &x; // escapes the address of a ref parameter
>   }
> }
> 
> Such code is accepted today. We believe it is error-prone and dangerous,
> particularly because the caller has no syntactic cue that the address of
> the parameter is passed into the function (in this case constructor). 

Well, you could adopt bug 6442 and call the constructor as

auto c = new C(ref x);

 

> Worse, such a function cannot be characterized as @safe.
>
> So we want to make the above an error. The workaround is obvious - just
> take int* as a parameter instead of ref int. What a function can do with
> a ref parameter in general is:
> 
> * use it directly just like a local;
> 
> * pass it down to other functions (which may take it by value or reference);
> 
> * pass its address down to pure functions because a pure function cannot
> escape the address anyway (cool insight by Walter);
>

Does this mean strongly pure? Because for now we can write a weakly pure
function 

pure int* escape(int* q) { return q; }

and change that constructor to 

this(ref int x) { p = escape(&x); } 
 
> * take its address as long as the address doesn't outlive the frame of the 
> function.
> 
> The third bullet is not easy to implement as it requires flow analysis,
> but we may start with a conservative version first. Probably there won't
> be a lot of broken code anyway.
> 
> Please chime in with any comments you might have!
> 
> 
> Thanks,
> 
> Andrei

Re: Thoughts on std.system.OS

[Jacob Carlborg]

On 2011-08-13 18:58, Jonathan M Davis wrote:

On Saturday, August 13, 2011 14:37:46 Jacob Carlborg wrote:

On 2011-08-13 12:51, Jonathan M Davis wrote:

#2 and #3 don't really make sense between OSes, and I'd argue that they
don't make much sense period. I don't know what they'd mean on Windows
in any meaningful way. On Linux, I suppose that they could be the major
and minor numbers of the kernel (e.g. 2 and 6 or 3 and 0), but that's
pretty useless on Linux, given that they don't change very often. At
this point, there would only really be two options: 2.6 and 3.0. And I
don't know how major and minor could be applied to OS X or FreeBSD.


In Mac OS X you have three version numbers, for example: 10.6.8. Or at
least two, don't know if I would call the first one a version number. I
mean, Mac OS 9 and Mac OS 10 is two completely different operating systems.


Well, since the OS is Mac OS X, not Mac OS (at least so far as versioning in D
goes), then presumably 10.6.8 would have the major number 6 and the minor
number 8.

- Jonathan M Davis


Exactly.

--
/Jacob Carlborg

Re: ref parameters: there is no escape

[Timon Gehr]

On 08/14/2011 04:20 PM, Andrei Alexandrescu wrote:

Walter and I have had a long discussion and we thought we'd bring an
idea for community review.

We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:

class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref parameter
}
}

Such code is accepted today. We believe it is error-prone and dangerous,
particularly because the caller has no syntactic cue that the address of
the parameter is passed into the function (in this case constructor).
Worse, such a function cannot be characterized as @safe.

So we want to make the above an error. The workaround is obvious - just
take int* as a parameter instead of ref int. What a function can do with
a ref parameter in general is:

* use it directly just like a local;

* pass it down to other functions (which may take it by value or
reference);

* pass its address down to pure functions because a pure function cannot
escape the address anyway (cool insight by Walter);


Well, then it is possible to 'wash clean' a pointer to ref argument 
using a pure function:


int* identity(int* p)pure{return p;}
int* global;
void escapeRef(ref int x)@safe{
global=identity(&x);
}




* take its address as long as the address doesn't outlive the frame of
the function.

The third bullet is not easy to implement as it requires flow analysis,
but we may start with a conservative version first. Probably there won't
be a lot of broken code anyway.

Please chime in with any comments you might have!


Thanks,

Andrei


I agree, disallow. But more important is that scope parameters start 
working. Probably some of the code could be reused.

Re: ref parameters: there is no escape

[Jakob Ovrum]

On 2011/08/14 23:20, Andrei Alexandrescu wrote:

Walter and I have had a long discussion and we thought we'd bring an
idea for community review.

We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:

class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref parameter
}
}

Such code is accepted today. We believe it is error-prone and dangerous,
particularly because the caller has no syntactic cue that the address of
the parameter is passed into the function (in this case constructor).
Worse, such a function cannot be characterized as @safe.

So we want to make the above an error. The workaround is obvious - just
take int* as a parameter instead of ref int. What a function can do with
a ref parameter in general is:

* use it directly just like a local;

* pass it down to other functions (which may take it by value or
reference);

* pass its address down to pure functions because a pure function cannot
escape the address anyway (cool insight by Walter);

* take its address as long as the address doesn't outlive the frame of
the function.

The third bullet is not easy to implement as it requires flow analysis,
but we may start with a conservative version first. Probably there won't
be a lot of broken code anyway.

Please chime in with any comments you might have!


Thanks,

Andrei


I like the idea, but don't we already have (currently non-enforced) 
scope parameters for this? Of course it would be nice to have "ref" also 
mean scope, like "in" meaning "scope const", but it would be nice to 
have scope working properly.


Currently, this code compiles fine:
-
const(char)[] test;

void foo(in char[] s)
{
test = s;
}

void main()
{
foo("bar");
}
--
This is a big problem when writing a library (accepting delegate 
callbacks and such) and you're not sure whether the user wants to just 
"read" a variable or hold onto it. Whether or not to make a copy should 
be the user's choice, not the library's.

ref parameters: there is no escape

[Andrei Alexandrescu]

Walter and I have had a long discussion and we thought we'd bring an 
idea for community review.


We believe it would be useful for safety purposes to disallow escaping 
addresses of ref parameters. Consider:


class C {
  int * p;
  this(ref int x) {
p = &x; // escapes the address of a ref parameter
  }
}

Such code is accepted today. We believe it is error-prone and dangerous, 
particularly because the caller has no syntactic cue that the address of 
the parameter is passed into the function (in this case constructor). 
Worse, such a function cannot be characterized as @safe.


So we want to make the above an error. The workaround is obvious - just 
take int* as a parameter instead of ref int. What a function can do with 
a ref parameter in general is:


* use it directly just like a local;

* pass it down to other functions (which may take it by value or reference);

* pass its address down to pure functions because a pure function cannot 
escape the address anyway (cool insight by Walter);


* take its address as long as the address doesn't outlive the frame of 
the function.


The third bullet is not easy to implement as it requires flow analysis, 
but we may start with a conservative version first. Probably there won't 
be a lot of broken code anyway.


Please chime in with any comments you might have!


Thanks,

Andrei

Re: Why callers should explicitly document storage classes

[Timon Gehr]

On 08/14/2011 01:34 PM, Mehrdad wrote:

Consider this example:

// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}

// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
while (!vals.empty)
baz(someCondition(), items.moveFront());
}

There is **absolutely NO WAY** to figure out what's wrong at the calling
site. You need to check /every/ method call and make sure nothing weird
is happening (e.g. lazy), and it's pretty much impossible to figure it
out unless you're intimately familiar with the entire library you're
calling -- something which (obviously) doesn't scale.

I don't know of a similar example off the top of my head for out/ref,
but the same idea applies.

Is this convincing enough that we need to document storage classes at
the CALLING site, rather than just the CALLEE site?


Basically, as I see it what is wrong is that the function is called 
"baz" (and maybe that lazy arguments are allowed to be side-effecting).


out/ref:
int x=100;
foo(x);
assert(x==100);

Re: Should we add drop to Phobos?

[Timon Gehr]

On 08/14/2011 01:29 PM, Jonathan M Davis wrote:

On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:

+1. Having take but not drop does not add to the beauty of the module.
I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
plus renaming std.algorithm.until to takeUntil. "until" is an
undescriptive name and it has a different meaning in functional
programming language libraries.


Renaming until takeUntil might be a good idea, though you'd have to talk
Andrei into it.

However, dropWhile isn't going to make it in because it's the same as find
except that predicate is reversed. All you have to do is use std.function.not
on your predicate to find, and you have dropWhile. The same goes for takeWhile,
except that it's std.algorithm.until which does the same thing aside from the
reversed predicate. And dropUntil _is_ find, no reversing of predicates
required.


I'd argue that find should actually have been called dropUntil. It is 
not evident at all what find does, given the name alone. If it is called 
dropUntil, nobody ever needs to read the documentation, be it the guy 
who writes the code or the guy who has to read it. But as it is probably 
heavily used, it is not sensible renaming it now. (and all I have to do 
is define an alias :))




There was a fair bit of discussion about this in

https://github.com/D-Programming-Language/phobos/pull/147


Ok, thanks. However I don't agree that the functions would clutter the 
standard library: In functional code, it is *crucial* for the 
understandability and ease of writing of code that it is not necessary 
to mess with predicates and it is possible to use a natural 
nomenclature. As things are now, if somebody wants to write 
functional-style D code, they have to implement a lot of the basic stuff 
themselves.


The discussion is basically between keeping it small and orthogonal 
(with imho questionable defaults) or making it large, flexible and 
convenient, without requiring the user to implement many small helper 
functions. I'm fine with defining my own utility functions, but I think 
if many people end up writing that functionality themselves, the std 
library has missed opportunities.




While I rather like the idea of having takeWhile and dropWhile, Andrei's
stance is that because they do the same thing as existing functions except for
the reversed predicate, they shouldn't be added. And while I'm not entirely
happy with that, I think that he has a very good point. We don't want to
clutter Phobos with functions which do the same things as other functions.

So, I could see an argument for renaming until to takeUntil. I don't know if
Andrei would go for that or not, but that could be reasonble. I certainly
agree that the name would be better. However, dropWhile, dropUntil, and
takeWhile aren't going to make it in because we already have functions which
already do the same thing with at most requiring that you reverse the
predicate.

drop, on the other hand, I'd argue adds much more value. You can't do drop
with any other function in Phobos. The closest that you get is Andrei's
suggestion of (popFrontN(range, n), range) which while clever, is fairly
hideous IMHO given that it uses the comma operator.

closer:
((int n){auto s=range.save(); popFrontN(s,n); return s}(n))


So, drop adds signicant
benefit towards a more functional style of programming, whereas the others just
make it so that you don't have to mess with your predicates as much to do what
you want - which would be nice but not nice enough to clutter the standard
library with.

- Jonathan M Davis


Yes, drop should be added. But I think that using the comma operator is 
no more hideous than using something like:


until!(not!p1)(find!p2(range));

instead of

takeWhile!p1(dropUntil!p2)(range));

Re: Why callers should explicitly document storage classes

[Lutger Blijdestijn]

Mehrdad wrote:

> Consider this example:
> 
>  // In module foo.d:
>  void baz(bool condition, lazy int value)
>  {
>  if (condition)
>  writeln(value);
>  }
> 
>  // In module bar.d:
>  import foo;
>  bool someCondition() { return false; }
>  void main()
>  {
>  auto vals = [1, 2, 3, 4];
>  while (!vals.empty)
>  baz(someCondition(), items.moveFront());
>  }
> 
> There is **absolutely NO WAY** to figure out what's wrong at the calling
> site. You need to check /every/ method call and make sure nothing weird
> is happening (e.g. lazy), and it's pretty much impossible to figure it
> out unless you're intimately familiar with the entire library you're
> calling -- something which (obviously) doesn't scale.

I'm not convinced that intimately is the right word here. Lazy evaluation is 
a pretty big deal in the interface of a function, just like ref is. If you 
have no idea at all what a function does, there is no hope to figure out 
what the code at the call site does to begin with. Even without lazy/out/ref 
you could be passing an object with reference semantics to a function which  
mutates the object, same deal. Not everything is 'const correct', so this 
may also be surprising if you do not know the function.

> I don't know of a similar example off the top of my head for out/ref,
> but the same idea applies.
> 
> Is this convincing enough that we need to document storage classes at
> the CALLING site, rather than just the CALLEE site?

Do you mean literally documenting it or having the compiler require you to 
state the storage class? If the first, I'd say it depends on the context. 
The enforce function in phobos for example is clear and well known enough to 
leave it out. I would not want the latter. But yes, if it's not clear enough 
then it's a good idea. Preferably it would be clear from the function name 
and purpose how it operates on the parameters though.

Why callers should explicitly document storage classes

[Mehrdad]

Consider this example:

// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}

// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
while (!vals.empty)
baz(someCondition(), items.moveFront());
}

There is **absolutely NO WAY** to figure out what's wrong at the calling 
site. You need to check /every/ method call and make sure nothing weird 
is happening (e.g. lazy), and it's pretty much impossible to figure it 
out unless you're intimately familiar with the entire library you're 
calling -- something which (obviously) doesn't scale.


I don't know of a similar example off the top of my head for out/ref, 
but the same idea applies.


Is this convincing enough that we need to document storage classes at 
the CALLING site, rather than just the CALLEE site?

Re: Should we add drop to Phobos?

[Jonathan M Davis]

On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:
> +1. Having take but not drop does not add to the beauty of the module.
> I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
> plus renaming std.algorithm.until to takeUntil. "until" is an
> undescriptive name and it has a different meaning in functional
> programming language libraries.

Renaming until takeUntil might be a good idea, though you'd have to talk 
Andrei into it.

However, dropWhile isn't going to make it in because it's the same as find 
except that predicate is reversed. All you have to do is use std.function.not 
on your predicate to find, and you have dropWhile. The same goes for takeWhile, 
except that it's std.algorithm.until which does the same thing aside from the 
reversed predicate. And dropUntil _is_ find, no reversing of predicates 
required.

There was a fair bit of discussion about this in

https://github.com/D-Programming-Language/phobos/pull/147

While I rather like the idea of having takeWhile and dropWhile, Andrei's 
stance is that because they do the same thing as existing functions except for 
the reversed predicate, they shouldn't be added. And while I'm not entirely 
happy with that, I think that he has a very good point. We don't want to 
clutter Phobos with functions which do the same things as other functions.

So, I could see an argument for renaming until to takeUntil. I don't know if 
Andrei would go for that or not, but that could be reasonble. I certainly 
agree that the name would be better. However, dropWhile, dropUntil, and 
takeWhile aren't going to make it in because we already have functions which 
already do the same thing with at most requiring that you reverse the 
predicate.

drop, on the other hand, I'd argue adds much more value. You can't do drop 
with any other function in Phobos. The closest that you get is Andrei's 
suggestion of (popFrontN(range, n), range) which while clever, is fairly 
hideous IMHO given that it uses the comma operator. So, drop adds signicant 
benefit towards a more functional style of programming, whereas the others just 
make it so that you don't have to mess with your predicates as much to do what 
you want - which would be nice but not nice enough to clutter the standard 
library with.

- Jonathan M Davis

Re: Should we add drop to Phobos?

[Timon Gehr]

On 08/14/2011 08:02 AM, Jonathan M Davis wrote:

Okay. Right now, if you want to remove n elements from the front of a range,
you use popFrontN.

popFrontN(range, n);

This is obviously a highly useful function. However, it does not work very
well when chaining range-based functions. For instance, what if you need to
call find on a range, but you know that what you're looking for is not in the
first n elements of that range? You'd do

popFrontN(range, n);
auto found = find(range, needle);

And what if you don't want to alter the range when you did that? You'd do
something like

auto toFind = range.save;
toFind.popFrontN(range, n);
auto found = find(toFind, needle);

That's not very functional at all and requires multiple lines of code. Also,
if you want to chain more than one function and need to call popFrontN
multiple times in there, you can't chain them very well. popFrontN returns the
actual number of elements popped, not the range, so you can't just pass its
result into another range-based function.

However, if you had a drop function, you could do this

auto found = find(drop(range, n), needle);

You now only have one line of code instead of three. And if you have more
complicated chaining, it's that much more useful. However, it does have one
downside.

Both popFrontN and drop pop _up to_ n elements, so if there are fewer than n
elements in the range, then as many elements as are in the range are popped.
However, in the case of popFrontN, it returns the actual number of elements
popped, so you know how many elements were popped. drop, on the other hand,
returns the range with the elements popped, so you don't know how many
elements were popped unless you do something like

auto newRange = drop(range, n);
auto elementsDropped = newRange.empty ? walkLength(range) : n;

Also, drop doesn't alter the original range, so if you call it multiple times
on the same range instead of using popFrontN, then it's inefficient. However,
it's not like we're getting rid of popFrontN, so if that's an issue, you can
just call popFrontN instead. It's just up to the progammer to decide which is
best for what they're doing. In cases where you want to chain range-based
functions and don't want to alter the original range, drop is best. In cases
where you want to alter the original range and don't necessarily care about
chaining functions, popFrontN is best.

Now, as Andrei has pointed out, you can get a similar effect by doing
(popFrontN(range, n), range). So, instead of

auto found = find(drop(range, n), needle);

you can do something like

auto found = find((popFrontN(range, n), range), needle);

However, that involves the comma operator, which most people avoid. It also
alters the original range instead of returning a new one with n elements
popped off, though whether that's good or bad depends on what you're doing.

So, the question is: Is drop worth having in Phobos? It's common in functional
languages, and if you want to program in a more functional style, it's of
enormous benefit. We'll still have popFrontN regardless, so the question is
whether drop adds enough value to be worth having or whether it's just too
similar to popFrontN to be worth adding to the standard library.

Personally, I think that drop would be a _very_ useful function to have. What
do you think?

- Jonathan M Davis


+1. Having take but not drop does not add to the beauty of the module. 
I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile, 
plus renaming std.algorithm.until to takeUntil. "until" is an 
undescriptive name and it has a different meaning in functional 
programming language libraries.

Re: Thoughts on std.system.OS

[amanda]

  when it comes to herpes,I hate how many people are using the word 
"end".It's not the end,start your new life DatingHerpesSingles.com