On 2011-09-04 16:08:47 +0000, Steven Schveighoffer <schveiguy@yahoo.com> said:

> Michel Fortin Wrote:
> 
>> On 2011-09-04 12:57:06 +0000, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> said:
>> 
>>> On 9/4/11 7:10 AM, Michel Fortin wrote:
>>>> And also, I doubt using D IO by default will break printf that much: I
>>>> mean if C IO is used to print lines, those lines will be flushed as
>>>> they're emitted, with no possible weird interleaving unless the line is
>>>> really too long.
>>> 
>>> No, things are more complex; the interference will be major unless
>>> explicitly addressed.
>> 
>> That doesn't really help understand the issue, you're just making it
>> more obscure.
> 
> You are assuming each write flushes the buffer. That's not always the case.

Not exactly. I am assuming each write flushes the buffer __up to the last newline__, and that most writes ends with \n in a use case where you'd be intermixing the IO systems. That's what I read somewhere else in this discussion, but maybe I read it wrong.

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

On 9/4/11 2:58 PM, Jacob Carlborg wrote:
> On 2011-09-04 14:59, Andrei Alexandrescu wrote:
>> On 9/4/11 7:11 AM, Jacob Carlborg wrote:
>>> Tango has added a new method to Object, "dispose". The method is called
>>> by the runtime when a scoped class exits a scope:
>>>
>>> void foo ()
>>> {
>>> scope f = new File;
>>> }
>>>
>>> When "foo" exits File.dispose will be called and it can close any file
>>> handles. I think it's quite clever.
>>
>> What happens if f is aliased beyond the existence of foo()?
>>
>> Andrei
>
> I'm not sure if this is what you mean but:
>
> File file;
>
> void foo ()
> {
> scope f = new File;
> file = f;
> }
>
> void main ()
> {
> foo;
> // file is disposed here
> }
>
> In the above example "dispose" will be called when "foo" exits. After
> the call to "foo" in the main function "file" will refer to an object
> that is disposed, i.e. an object where the "dispose" method has been
> called.
>
> I don't know how bad this is or if it is bad at all.

Well it's not bad but a bit underwhelming. Clearly it's better than the unsafe behavior of scope, but it's nothing to write home about. The grand save it makes is replacing "scope(exit) f.dispose();" with "scope" in front of the declaration. That does systematically save some typing, but it's a feature with only local, non-modular effect, and limited abstraction power.


Andrei

On 9/4/11 3:23 PM, Michel Fortin wrote:
> On 2011-09-04 16:08:47 +0000, Steven Schveighoffer <schveiguy@yahoo.com>
> said:
>
>> Michel Fortin Wrote:
>>
>>> On 2011-09-04 12:57:06 +0000, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> said:
>>>
>>>> On 9/4/11 7:10 AM, Michel Fortin wrote:
>>>>> And also, I doubt using D IO by default will break printf that much: I
>>>>> mean if C IO is used to print lines, those lines will be flushed as
>>>>> they're emitted, with no possible weird interleaving unless the
>>>>> line is
>>>>> really too long.
>>>>
>>>> No, things are more complex; the interference will be major unless
>>>> explicitly addressed.
>>>
>>> That doesn't really help understand the issue, you're just making it
>>> more obscure.
>>
>> You are assuming each write flushes the buffer. That's not always the
>> case.
>
> Not exactly. I am assuming each write flushes the buffer __up to the
> last newline__, and that most writes ends with \n in a use case where
> you'd be intermixing the IO systems. That's what I read somewhere else
> in this discussion, but maybe I read it wrong.

It depends on the buffering mode of the stream, and also of the buffering mode of whatever alternative abstraction is being used.

Sorry for being curt - I trusted Walter's earlier explanation would suffice.


Andrei

On 2011-09-04 19:36:23 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> It depends on the buffering mode of the stream, and also of the buffering mode of whatever alternative abstraction is being used.
> 
> Sorry for being curt - I trusted Walter's earlier explanation would suffice.

Actually my assumption wasn't too bad within its own boundaries. I was only thinking about stdout and it being line-buffered by default. Looking into it a little more, I'm not sure what would happen to stdin and stdout isn't always line-buffered by default anyway (if the output isn't a terminal for instance).

So I have to agree with you that mixing the two won't work well in most cases. Sorry for the distraction.

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

On 2011-09-04 21:34, Andrei Alexandrescu wrote:
> On 9/4/11 2:58 PM, Jacob Carlborg wrote:
>> I'm not sure if this is what you mean but:
>>
>> File file;
>>
>> void foo ()
>> {
>> scope f = new File;
>> file = f;
>> }
>>
>> void main ()
>> {
>> foo;
>> // file is disposed here
>> }
>>
>> In the above example "dispose" will be called when "foo" exits. After
>> the call to "foo" in the main function "file" will refer to an object
>> that is disposed, i.e. an object where the "dispose" method has been
>> called.
>>
>> I don't know how bad this is or if it is bad at all.
>
> Well it's not bad but a bit underwhelming. Clearly it's better than the
> unsafe behavior of scope, but it's nothing to write home about. The
> grand save it makes is replacing "scope(exit) f.dispose();" with "scope"
> in front of the declaration. That does systematically save some typing,
> but it's a feature with only local, non-modular effect, and limited
> abstraction power.
>
>
> Andrei

Yeah, a variable declared as "scope" shouldn't, preferably, exit it's scope. The compiler will at least complain if you try to return a scoped variable.

-- 
/Jacob Carlborg

Andrei Alexandrescu Wrote:

> http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html

Ddoc screwed the types, right?

On 9/4/2011 2:17 AM, Lars T. Kyllingstad wrote:
> On Sat, 03 Sep 2011 18:23:26 -0700, Walter Bright wrote:
>
>> [I also don't like it that all my code that uses std.path is now
>> broken.]
>
> What do you mean by "broken"?  That it does not compile or work as
> expected, or that it spits out a bunch of annoying deprecation messages?
>
> If it is any of the former, that was not supposed to happen.  The new
> std.path still contains all the functions of the old std.path and should
> therefore be backwards compatible.
>
> If the new std.path breaks existing code, I need to fix it before it is
> released.  Please let me know what problems you are experiencing.

It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names.

I know that the majority wants the name changes. I know the deprecation system gives people plenty of time to edit their code.

But I think the cost of breaking existing code is much higher than many realize, and a lot of that cost will be hidden. It'll come in the form of people deciding not to use D because it is "not stable". It'll come in the form of invalidating existing libraries and modules unless someone is regularly maintaining them. It'll come in the form of invalidating the mass of books, articles, blog postings, and presentations about D, and those will never get updated. People will type in the code examples, they will fail to compile, and they'll get turned off about D.

I'll again note that I know of know successful operating system or programming language that goes around breaking existing code unless it is really, really urgent.

Camel-casing a name doesn't meet that standard. So, yes, I don't like it.

On 9/5/11, Walter Bright <newshound2@digitalmars.com> wrote:
> It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names.

It would really help out if we had some sort of semi-automated script that can do at least partial translation of code that uses old phobos functions to new ones. Maybe this wouldn't work 100% but at least it would help out. I'm thinking of something similar to what Python 2to3 does.

I know for sure I could use this, so far I've had to fix the DWinSamples for every DMD/Phobos release.

== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> On 9/4/2011 2:17 AM, Lars T. Kyllingstad wrote:
> I'll again note that I know of know successful operating system or programming
> language that goes around breaking existing code unless it is really, really urgent.
> Camel-casing a name doesn't meet that standard. So, yes, I don't like it.

I agree that we've been overzealous lately in breaking code to fix small inconsistencies in style, etc.  I think in a lot of cases the answer is permanent (or very long term, i.e. several years) soft deprecation, plus a real soft-deprecated language feature.  This will lead to cruft accumulation but in some cases this cruft is less bad than the cruft caused by inconsistent naming conventions/style, etc.  To make the docs seem less crufty to people browsing, we could even eventually remove the soft-deprecated functionality from the DDoc documentation so that people reading it can't even see the cruft, and move the code to the bottom of the source files so that people don't see it unless they go looking for it.  We could also adopt a policy of zero maintenance for features that have been soft-deprecated for long periods of time, i.e. not even if they produce egregiously wrong results, security holes, etc.

Am 06.09.2011, 00:05 Uhr, schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:

> On 9/5/11, Walter Bright <newshound2@digitalmars.com> wrote:
>> It prints out all the deprecation message. It means I'll have to go edit
>> existing, working code to change the names.
>
> It would really help out if we had some sort of semi-automated script
> that can do at least partial translation of code that uses old phobos
> functions to new ones. Maybe this wouldn't work 100% but at least it
> would help out. I'm thinking of something similar to what Python 2to3
> does.
>
> I know for sure I could use this, so far I've had to fix the
> DWinSamples for every DMD/Phobos release.

It would help to have a lexical analyzer of the kind that allows for the refactorings in for example Eclipse for Java. Without clear identification of symbols it is impossible to write such a script for every new D release. And there were other changes in the past where this would have been handy although I have not writing any D code lately to feel the breakage. I think of globals (__gshared).
I'm on the extreme with my urge to rewrite things if they give me the slightest feeling that they could be more elegant or effective and I've thought of such a script as well that could be distributed with every new D version while there are still breaking changes to the language. Well, you cannot write a script without a solid foundation that can reliably identify and refactor symbols.
But this doesn't work well for code you copy from blogs. You would have to know what D version it was written with and run the matching chain of conversion scripts. Anyway this feels like some crazy idea that can't make it into existence.
Still I have that picture of downloading a new D release and running the obligatory dmdup script to replace deprecated functionality or names with the new versions. Sure at some point 'this is it' and features of D and Phobos become set in stone. "Hello world!" console output is one of those examples that many will try first. I would understand if it breaks between major versions of a language, but not from one revision to the next. YMMV :)