On 2013-02-25 17:20, Don wrote:

> I don't think this is true at all.
> With respect -- I think Walter has absolutely no clue about backwards
> compatibility and deprecation.
>
> Here's how it should work:
> 1. You make promises  (about future compatibility).
> 2. You keep those promises.
>
> Walter tries to do (2). without doing (1). The result is the insanity
> we've had for years. It means an unpredictable, unplanned set of often
> undesirable behaviour is preserved, that doesn't help stability anyway.
>
> We need to do (1).
>
> Can we please stop pretending this is acceptable?
> It's not "growing pains" or anything like that. It's a basic
> misunderstanding of stability.

I completely agree.

-- 
/Jacob Carlborg

On 2013-02-25 20:57, Walter Bright wrote:

> Consider the common complaint from numerous people that "my code breaks
> with every new release".
>
> Even if the fix is "simple".
>
> Just today, rdmd doesn't compile anymore.
>

Read Don's post: http://forum.dlang.org/thread/stxxtfwfrwllkcpunhue@forum.dlang.org?page=10#post-rmisaclgytudqcdecvzb:40forum.dlang.org

-- 
/Jacob Carlborg

On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad wrote:
> On Monday, 25 February 2013 at 21:06:54 UTC, Vladimir Panteleev wrote:
>> On Monday, 25 February 2013 at 20:06:19 UTC, Lars T. Kyllingstad wrote:
>>> That is also incredibly obscure.  I'd venture a guess that only ~10% of D's user base have even heard of Lynx.  Everyone knows firefox, and will understand what the example is supposed to illustrate.  (I admit that the ls/grep examples will also be rather incomprehensible to someone not familiar with the *NIX command line, and I will replace them with something else.  The D toolchain, as you suggest below, is a very good idea.)
>>
>> I still think using Firefox is a bad idea, but I've already presented my arguments.
>>
>>> BTW, browse() should never have been added to std.process, in my opinion.  Maybe to some other utility module, but then it should at least be done right, and be properly documented.
>>
>> What would you improve about it?
>
> 1. I would document it properly.
> 2. As long as it runs in the background, I would return some kind of process ID from it.  (Yes, most browsers today may just signal another instance to open a new tab and then return, but would be surprised if they *all* do.)
> (3. Maybe put it in a different module, I'm not sure.)

4. I would design it so that if I do browse("foo.txt") it opens foo.txt in the web browser.  Correct me if I'm wrong, but it currently seems that it will open it in the user's text editor on Windows.  (On POSIX systems, too, if $BROWSER isn't set.)

1a. I would document that it uses $BROWSER on POSIX, as that is not even remotely standard.  (It is not set on my Ubuntu 11.10 machine, for instance.)  I would document that it uses xdg-open on Linux if $BROWSER is not set, as xdg-open will only exist on systems that conform to FreeDesktop standards.

Even if it turns out that browse() is the "best" way to implement this feature, it is not perfect by a long shot, and as such its shortcomings should be well documented.

Lars

On Mon, 25 Feb 2013 11:57:40 -0800, Walter Bright wrote:

> On 2/23/2013 6:58 PM, H. S. Teoh wrote:
>> On Sat, Feb 23, 2013 at 06:46:13PM -0800, Jonathan M Davis wrote:
>>> Possibly, but Walter takes a very dim view on most any code breakage, even if it means simply changing a makefile to make your code work again,
>>
>> I find this rather frustrating...
> 
> Consider the common complaint from numerous people that "my code breaks with every new release".

Yes, and as a compiled systems language, I think D needs to aim for compiling code from a decade ago, like GCC can (at least using -ansi etc.).

It seems like a some people modify D core libraries like they would for Python, so that 3.0 code works, but 2.2 code doesn't etc.  I don't think that's appropriate for D.  Not if it wants to be taken as seriously as C/C ++, at least.

> 
> Even if the fix is "simple".
> 
> Just today, rdmd doesn't compile anymore.

It really would be nice to have rdmd included as part of DMD, and gdc etc.  To me, it's a fundamental feature of the language, to be able to use it for scripts as well as pre-compiled code.

If it was, and there were unit tests as part of releases (or even commits to master, say), then this problem of RDMD breakage wouldn't happen.


-- 
Lee

On Tuesday, 26 February 2013 at 08:31:05 UTC, Lee Braiden wrote:
> On Mon, 25 Feb 2013 11:57:40 -0800, Walter Bright wrote:
>
>> On 2/23/2013 6:58 PM, H. S. Teoh wrote:
>>> On Sat, Feb 23, 2013 at 06:46:13PM -0800, Jonathan M Davis wrote:
>>>> Possibly, but Walter takes a very dim view on most any code breakage,
>>>> even if it means simply changing a makefile to make your code work
>>>> again,
>>>
>>> I find this rather frustrating...
>> 
>> Consider the common complaint from numerous people that "my code breaks
>> with every new release".
>
> Yes, and as a compiled systems language, I think D needs to aim for
> compiling code from a decade ago, like GCC can (at least using -ansi
> etc.).
>
> It seems like a some people modify D core libraries like they would for
> Python, so that 3.0 code works, but 2.2 code doesn't etc.  I don't think
> that's appropriate for D.  Not if it wants to be taken as seriously as C/C
> ++, at least.
>

To be honest, for those of us old enough C and C++ compilers went through the same process.

One of the things that initially atracted me to Java was that my supposedly portable C and C++ code was riddled with #ifdefs to workaround compiler issues.

--
Paulo

On 2013-02-26 09:31, Lee Braiden wrote:

> It really would be nice to have rdmd included as part of DMD, and gdc
> etc.  To me, it's a fundamental feature of the language, to be able to
> use it for scripts as well as pre-compiled code.
>
> If it was, and there were unit tests as part of releases (or even commits
> to master, say), then this problem of RDMD breakage wouldn't happen.

RDMD is part of the DMD release.

-- 
/Jacob Carlborg

On Tuesday, 26 February 2013 at 10:57:19 UTC, Jacob Carlborg wrote:
> On 2013-02-26 09:31, Lee Braiden wrote:
>
>> It really would be nice to have rdmd included as part of DMD, and gdc
>> etc.  To me, it's a fundamental feature of the language, to be able to
>> use it for scripts as well as pre-compiled code.
>>
>> If it was, and there were unit tests as part of releases (or even commits
>> to master, say), then this problem of RDMD breakage wouldn't happen.
>
> RDMD is part of the DMD release.


Some linux packagers may not include it, for unknown misunderstanding. When dmd2 made its way into main Arch Linux repositories I had a small e-mail conversation with new maintainer as I had to prove using code from DPL/tools is fine license-wise - he was reluctant to put rdmd in by default.

On 2/26/13 2:16 AM, Jonathan M Davis wrote:
> On Tuesday, February 26, 2013 08:08:33 Lars T. Kyllingstad wrote:
>> What if the variable is set, but empty?  Is that very different
>> from the situation where it doesn't exist at all?  In my opinion,
>> when it comes to environment variables, no.
>
> And yet, there _is_ a difference. I've dealt with code before that simply cared
> about whether an environment variable was set and not at all what it was set
> to. Regardless of whether that's desirable behavior, any program that needs to
> be compatible with a program that follows that behavior will need to be able
> to follow that behavior as well. So, if std.process is set up so that you
> can't tell the difference betwen an environment variable which hasn't been set
> and one that's been set to nothing, then that's a problem, even if it's not
> the most common case.
>
> - Jonathan M Davis

Guess we could go with returning a null string if nonexistent and "" if it does. This makes the implementation space about as subtle as the problem space.

Andrei

On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad wrote:
>> What would you improve about it?
>
> 1. I would document it properly.
> 2. As long as it runs in the background, I would return some kind of process ID from it.  (Yes, most browsers today may just signal another instance to open a new tab and then return, but would be surprised if they *all* do.)

Pretty sure all major Windows browsers do.

The result is useless anyway. The user can browse away to another website, and if the browser is tabbed, open a completely different website and close the tab containing your website. What the user does from that moment is not the program's business. If it's important to detect when your website/webapp's tab is closed, I'd suggest implementing a long-polling request (COMET) and acting on when the connection is interrupted and there is no reconnection in 5 seconds.

> (3. Maybe put it in a different module, I'm not sure.)
>
> Also, and this is of course extremely subjective, it just looks out of place and very much "alone".  Where is writeEmailInDefaultClient(address)?  Where is openInAssociatedApp(file)?

I guess no one simply wrote them yet?

writeEmailInDefaultClient(address) is accomplished by opening the "mailto:"~address URL.

The matter of protocols other than http needs some attention, though...

> 4. I would design it so that if I do browse("foo.txt") it opens foo.txt in the web browser.  Correct me if I'm wrong, but it currently seems that it will open it in the user's text editor on Windows.  (On POSIX systems, too, if $BROWSER isn't set.)

I don't know how you would accomplish that on Windows, without accessing the association in the OS registry for e.g. the http protocol. Might be better to change the documentation instead.

>>> Exposing the specifics of whatever programming language you are using to the end user?
>>
>> I don't understand what you mean here. It's not exposing any specifics if you don't implement anything in a way specific to D.
>
> You pass a string directly from a config file into a rather low-level function in the programming language's standard library without any kind of validation.

Running a program from another program should be that simple. I don't think anyone expects to validate a command-line.

On Tuesday, 26 February 2013 at 07:08:37 UTC, Lars T. Kyllingstad wrote:
> What if the variable is set, but empty?  Is that very different
> from the situation where it doesn't exist at all?  In my opinion,
> when it comes to environment variables, no.

Until today, I didn't know that empty variables could exist. They don't exist on Windows: setting a variable to an empty string is how you delete it.

Regardless, I think my point still stands on the argument that it's much more likely for a variable to be unexpectedly unset rather than unexpectedly empty. To extend to a general case, we could say that an empty variable is as likely as any invalid or unexpected value. For the 'rm -rf $FOO/$BAR' case, one can come up with any combinations of FOO and BAR, such as "/bin" and "../", where the command would have the same effect.