Re: Style updated on d-programming-language.org

[Nick Sabalausky]

"Andrei Alexandrescu"  wrote in message 
news:i5unqf$2b4...@digitalmars.com...
> David Gileadi sent an update taking the recent feedback into account.
>
> http://d-programming-language.org
>

The code boxes on this page scroll horizontally and are difficult to read:

http://d-programming-language.org/template-comparison.html

Re: Style updated on d-programming-language.org

[Walter Bright]

Andrei Alexandrescu wrote:

David Gileadi sent an update taking the recent feedback into account.

http://d-programming-language.org


Thanks, David!

Looks nice! But it doesn't reflow well when shrinking the window. The header 
gets goofed up, and the google ad on the bottom is a fixed size.


Site looks good on an iPod. (Can someone with an Android check it?)

Probably can ditch the reddit button.

Behaviour of goto into catch blocks.

[Iain Buclaw]

When it comes to using goto in D, the behaviour seems to be that you cannot 
enter a try block, and neither can you enter or exit from a
finally block.

What about catch blocks? It seems that there is no restrictions imposed on 
them, meaning that the following is legal.


void main()
{
goto in_catch;
try
{
throw new Exception("msg");
}
catch (Exception e)
{
  in_catch:
 throw e;
}
}


As strongly as I feel that goto into catch blocks shouldn't be allowed, is this 
the intended behaviour of the language? If so, why?

Re: Style updated on d-programming-language.org

[Andrej Mitrovic]

Oh and, the current site on digitalmars.com doesn't have these
problems. It always reloads the text, but not the graphics. It's a
very smooth experience and I'd like that in the new site as well. :)

On Sun, Sep 5, 2010 at 3:21 AM, Andrej Mitrovic
 wrote:
> Nice. My only gripe is the loading of different sections of the site.
> E.g. if I'm in language reference and then switch to the articles
> section, I get a white flash before the site loads. But switching from
> page to page inside a section doesn't do this, as it only reloads the
> text on the right.
>
> On Sun, Sep 5, 2010 at 2:21 AM, Andrei Alexandrescu
>  wrote:
>> David Gileadi sent an update taking the recent feedback into account.
>>
>> http://d-programming-language.org
>>
>> Andrei
>>
>

Re: Style updated on d-programming-language.org

[Andrej Mitrovic]

Nice. My only gripe is the loading of different sections of the site.
E.g. if I'm in language reference and then switch to the articles
section, I get a white flash before the site loads. But switching from
page to page inside a section doesn't do this, as it only reloads the
text on the right.

On Sun, Sep 5, 2010 at 2:21 AM, Andrei Alexandrescu
 wrote:
> David Gileadi sent an update taking the recent feedback into account.
>
> http://d-programming-language.org
>
> Andrei
>

Style updated on d-programming-language.org

[Andrei Alexandrescu]

David Gileadi sent an update taking the recent feedback into account.

http://d-programming-language.org

Andrei

Re: accepts-invalid?

[Stewart Gordon]

On 24/08/2010 07:55, Don wrote:

Nick Sabalausky wrote:

"Steven Schveighoffer"  wrote in message
news:op.vhwolemleav...@localhost.localdomain...



Wait, how can you pass a runtime string as a template parameter? I'm
pretty sure the whole thing is a bug.


Oh, yea, now I see it :)


It may be a duplicate of bug 2962.


Bug 2962 relies on an alias template parameter.  It took me a moment or 
3 to make out why you'd decided it isn't accepts-invalid.  On the other 
hand, this clearly is.


Stewart.

Re: [challenge] Hamming numbers

[bearophile]

Philippe Sigaud:

>It's crystal clear & short (but we should aim for J! :-), but being lazy I 
>don't see how it can use less memory than a strict version of the same algo. 
>Got to store all those thunks somewhere.<

I have appreciated how the Haskell version allows me to generate a sequence 
lazily in a recursive way, with a compact syntax and efficiently. But I don't 
know Haskell, so it's easy for what I say about Haskell programs to be false :-)


> What did you use to compare them? (out of curiosity, not attack).<
> I used GHCi, and got 8.8s for the millionth Hamming number, using ~450 Mo of
> RAM, according to GHCi itself (:set +s, :set +t). But I'm no pro in
> optimizing Haskell compilation.

For the Python and D programs I have used woerking memory & commit on Windows, 
for the Haskell version I have used Ideone:
http://ideone.com/wH1YU

It computes the result (ghc-6.8.2) in 0.93s using only 8.7 MB of memory.


> For my own D version, that is quite near the Rosetta Code version, I get
> 3.7s, 100 Mo of RAM. (-O -release -inline)
> Using the RC code (your own, translated from Java, right?), I get the same.
> Same result, same time, same memory consumption. Yeah, my code is not wrong 
> :-)

On my very slow PC using DMD the D version requires about 2.7s and about max 92 
MB of memory.

The second Python version (the one by Hettinger) takes about 4.95s and less 
than 4.5 MB of memory.
(The third Python version, that uses the eager array and Psyco is faster.)

Are you able to write a short D version similar to the second Python version? 
(I have created one, but it's not as short as the second Python version, and it 
takes something like 4 seconds or more).

Bye,
bearophile

Re: [Slight OT] TDPL in Russia

[Walter Bright]

Michel Fortin wrote:
On 2010-09-02 22:04:39 -0400, Walter Bright  
said:



Michel Fortin wrote:
Basically, you wanted to do what I did with my website. What was the 
problem exactly? Creating a style sheet that displays the contents 
well when read linearly? Or was it about how to trigger this 
particular style sheet for iPhone and iPods? The later's quite 
simple, just use this media attribute:


media="handheld, only screen and (max-device-width: 480px)"

The "handheld, " part isn't really relevant for iOS devices, but 
it'll trigger the stylesheet with Opera-based handheld browsers.


The problem was that I googled it and every hit used a radically 
different method and they'd refer to it as "seems" to work. I'm not 
comfortable using such hacks. I'd like one that officially works and 
is standards compliant.


Call it a hack if you want, but this is the most standard-compliant 
solution as it is based on the CSS3 Media Queries specification:



It'll be officially standard-compliant once the specification becomes a 
W3C recommendation (it's currently a candidate recommendation). 
Currently, WebKit (Safari, Chrome), Gecko (Firefox) and Opera all 
support media queries.




IE 9 will support media queries too when it ships (I believe it's in 
beta currently) so it'll probably work with Windows Phone 7 too (when it 
becomes available). Here's a showcase they've made:



So good luck finding something more standard-compliant.



This is good information. Thanks!

Re: [challenge] Hamming numbers

[Philippe Sigaud]

On Fri, Sep 3, 2010 at 21:43, bearophile  wrote:

> Don:
> > That's not a very useful problem, because the timing depends entirely on
> > BigInt, which is completely unoptimised for small values.
>
> You are usually right, but this time what you say is useless. There are
> other means to judge how good a program is, beside running time:
> - Total line count of the program;
> - Max amount of memory used.
>
> The Haskell version of the program is quite fast, very short, and it's lazy
> so it uses very low memory.


It's crystal clear & short (but we should aim for J! :-), but being lazy I
don't see how it can use less memory than a strict version of the same algo.
Got to store all those thunks somewhere.


> The "Alternate version using "Cyclic Iterators"" Python version invented by
> the great Raymond Hettinger too is lazy and uses very low memory. On the
> other hand, that D version, that I have translated from the Java code, is
> eager so it uses a lot of memory, is slow (mostly because of the bigint
> implementation, I agree), and its source is many lines long. So D must do
> better along one or more than one of those axis.
>

What did you use to compare them? (out of curiosity, not attack).
I used GHCi, and got 8.8s for the millionth Hamming number, using ~450 Mo of
RAM, according to GHCi itself (:set +s, :set +t). But I'm no pro in
optimizing Haskell compilation.
For my own D version, that is quite near the Rosetta Code version, I get
3.7s, 100 Mo of RAM. (-O -release -inline)
Using the RC code (your own, translated from Java, right?), I get the same.
Same result, same time, same memory consumption. Yeah, my code is not wrong
:-)
So, at least naively like this for me, D is more than twice as fast as
Haskell and uses about 80% less memory.

Of course, GHC caches results, so the second time I ask for the millionth
Hamming number, I get it almost instantaneously. Nifty, that!


Philippe

Re: The new Mono GC

[Walter Bright]

bearophile wrote:

Walter Bright:
That's true if the language (like Java) uses a *lot* of gc allocation. D 
programs tend to do much less because it has support for value types.


This is true, unless: - Someone that knows well enough Java (and badly D)
writes a D program. Today it's hard to find people that know D; - Someone
ports a Java program to D;


The language should focus on supporting D programs best, not Java programs.
Putting write barriers on every write through a pointer will destroy 
performance. In Java, every write through a reference refers to the heap. This 
is not remotely true of D programs.


And, as was mentioned previous, you can't do write barriers halfway. You've got 
to do it everywhere, meaning that simple interfacing to C code is destroyed.




- Someone writes some D code where OOP (or
automatic heap activity management) is more necessary (commercial software?).


I don't think it makes sense to characterize commercial software as eschewing 
value types.

Re: The new Mono GC

[Jacob Carlborg]

On 2010-09-04 21:22, Walter Bright wrote:

Jacob Carlborg wrote:

Such write barriers are a performance problem, too.


What I've read about garbage collection techniques I got the
impression that you could implement a better and more efficient
collector with write barriers that would outweigh the performance loss
that comes with the barriers.



That's true if the language (like Java) uses a *lot* of gc allocation. D
programs tend to do much less because it has support for value types.


Ok, thanks for the answer.

--
/Jacob Carlborg

Re: Semantics of casting **to** shared?

[dsimcha]

== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> I loved the recent clone() idea. I think it might be better to disable
> casting to (and from) shared (and immutable) and make a (deep?) copy of an
> object instead. This will make sure that the isn't any dangling reference
> left. I strongly believe dangling references could become a major source
> of bugs which might be hard to find and fix.

Holy %)(*$%, casting **to** immutable works in SafeD, too?  Of course casting
from/to shared/immutable should be allowed in n...@safe code, but I don't think
either should be allowed in @safe code.  The only way to get aliasing between
mutable and immutable data in @safe code should be by using broken @trusted 
code.
 Otherwise the @safe-ty of SafeD is really questionable.

Also, as far as cloning, The fact that it's really a special case of 
serialization
was brought up by a few people, so I'm taking a wait-and-see attitude and seeing
what people who wrote serialization libraries come up w/ for cloning, rather 
than
working on cloning now.

Re: Semantics of casting **to** shared?

[dsimcha]

== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> safeD doesn't mean your code is safe... only "memory safe". Similarly, 
> "shared"
sort of partitions data and there is no provably safe way to create or use it. I
have no idea if your example is truly legit safeD or not...

1.  Using __gshared and casting **away** shared are illegal in SafeD.

2.  Low level data races can cause memory corruption if pointers get overwritten
with invalid data.

Re: Semantics of casting **to** shared?

[Denis Koroskin]

On Sat, 04 Sep 2010 22:05:05 +0400, dsimcha  wrote:

I noticed that the following code compiles even in SafeD.  Is this a  
bug?  If
not, what are the semantics of casting unshared to shared?  TDPL doesn't  
seem
to mention this.  Isn't it dangerous to have shared and unshared  
references to

the same memory?

@safe:
class Foo {
uint num;
}

void main() {
auto foo = new Foo;
auto bar = cast(shared) foo;
}


I loved the recent clone() idea. I think it might be better to disable  
casting to (and from) shared (and immutable) and make a (deep?) copy of an  
object instead. This will make sure that the isn't any dangling reference  
left. I strongly believe dangling references could become a major source  
of bugs which might be hard to find and fix.

Re: [Slight OT] TDPL in Russia

[Michel Fortin]

On 2010-09-02 22:04:39 -0400, Walter Bright  said:


Michel Fortin wrote:
Basically, you wanted to do what I did with my website. What was the 
problem exactly? Creating a style sheet that displays the contents well 
when read linearly? Or was it about how to trigger this particular 
style sheet for iPhone and iPods? The later's quite simple, just use 
this media attribute:


media="handheld, only screen and (max-device-width: 480px)"

The "handheld, " part isn't really relevant for iOS devices, but it'll 
trigger the stylesheet with Opera-based handheld browsers.


The problem was that I googled it and every hit used a radically 
different method and they'd refer to it as "seems" to work. I'm not 
comfortable using such hacks. I'd like one that officially works and is 
standards compliant.


Call it a hack if you want, but this is the most standard-compliant 
solution as it is based on the CSS3 Media Queries specification:



It'll be officially standard-compliant once the specification becomes a 
W3C recommendation (it's currently a candidate recommendation). 
Currently, WebKit (Safari, Chrome), Gecko (Firefox) and Opera all 
support media queries.




IE 9 will support media queries too when it ships (I believe it's in 
beta currently) so it'll probably work with Windows Phone 7 too (when 
it becomes available). Here's a showcase they've made:



So good luck finding something more standard-compliant.

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

Re: The new Mono GC

[bearophile]

Walter Bright:
> That's true if the language (like Java) uses a *lot* of gc allocation. D 
> programs tend to do much less because it has support for value types.

This is true, unless:
- Someone that knows well enough Java (and badly D) writes a D program. Today 
it's hard to find people that know D;
- Someone ports a Java program to D;
- Someone writes some D code where OOP (or automatic heap activity management) 
is more necessary (commercial software?).

Bye,
bearophile

Re: [Slight OT] TDPL in Russia

[Yao G.]

On Sat, 04 Sep 2010 12:55:58 -0500, Walter Bright  
 wrote:


Isn't it interesting that people keep inventing new audio formats and  
fail to solve obvious fundamental problems with them, like providing  
fields for things like artwork, lyrics, etc.?


http://www.id3.org/

--
Yao G.

Re: The new Mono GC

[Walter Bright]

Jacob Carlborg wrote:

Such write barriers are a performance problem, too.


What I've read about garbage collection techniques I got the impression 
that you could implement a better and more efficient collector with 
write barriers that would outweigh the performance loss that comes with 
the barriers.



That's true if the language (like Java) uses a *lot* of gc allocation. D 
programs tend to do much less because it has support for value types.

Re: Semantics of casting **to** shared?

[Jason House]

safeD doesn't mean your code is safe... only "memory safe". Similarly, "shared" 
sort of partitions data and there is no provably safe way to create or use it. 
I have no idea if your example is truly legit safeD or not...

dsimcha Wrote:

> I noticed that the following code compiles even in SafeD.  Is this a bug?  If
> not, what are the semantics of casting unshared to shared?  TDPL doesn't seem
> to mention this.  Isn't it dangerous to have shared and unshared references to
> the same memory?
> 
> @safe:
> class Foo {
> uint num;
> }
> 
> void main() {
> auto foo = new Foo;
> auto bar = cast(shared) foo;
> }

Semantics of casting **to** shared?

[dsimcha]

I noticed that the following code compiles even in SafeD.  Is this a bug?  If
not, what are the semantics of casting unshared to shared?  TDPL doesn't seem
to mention this.  Isn't it dangerous to have shared and unshared references to
the same memory?

@safe:
class Foo {
uint num;
}

void main() {
auto foo = new Foo;
auto bar = cast(shared) foo;
}

Re: [Slight OT] TDPL in Russia

[Walter Bright]

Max Samukha wrote:

On 04.09.2010 5:50, Walter Bright wrote:

It still makes no sense to have it as a separate file.



Yeah. Just like it makes no sense to have headers separate from object 
files.


If I invented an object file format, you can bet it'd be quite a bit different 
from existing ones!

Re: [Slight OT] TDPL in Russia

[Walter Bright]

Andrej Mitrovic wrote:

But, you can't embed multiple track info in mp3's either..?


Isn't it interesting that people keep inventing new audio formats and fail to 
solve obvious fundamental problems with them, like providing fields for things 
like artwork, lyrics, etc.?

Re: this as lvalue?

[Andrei Alexandrescu]

On 09/04/2010 10:41 AM, Steven Schveighoffer wrote:

Andrei Alexandrescu Wrote:


On 9/3/10 16:03 CDT, bearophile wrote:

JMRyan:

Is this a bug in the compiler (v.2.047)?  Am I missing something in
thinking it shouldn't be?


I think it's not a bug. It's not a common need, but a method may way want to 
swap this with another. In Phobos this is done on a struct, see:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324

Bye,
bearophile


For classes this must be an rvalue.

Andrei


Should this work?

class C
{
   int x;
   void opAssign(int n) {x = n;}
   void foo(int n) {this = n;}
}

I agree this should not be rebindable.  But it has to be an lvalue.

-Steve


The example should work, but doesn't need this to be an lvalue.

Andrei

Re: this as lvalue?

[Steven Schveighoffer]

Andrei Alexandrescu Wrote:

> On 9/3/10 16:03 CDT, bearophile wrote:
> > JMRyan:
> >> Is this a bug in the compiler (v.2.047)?  Am I missing something in
> >> thinking it shouldn't be?
> >
> > I think it's not a bug. It's not a common need, but a method may way want 
> > to swap this with another. In Phobos this is done on a struct, see:
> > http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324
> >
> > Bye,
> > bearophile
> 
> For classes this must be an rvalue.
> 
> Andrei

Should this work?

class C
{
  int x;
  void opAssign(int n) {x = n;}
  void foo(int n) {this = n;}
}

I agree this should not be rebindable.  But it has to be an lvalue.

-Steve

Re: this as lvalue?

[Andrei Alexandrescu]

On 9/4/10 3:32 CDT, KennyTM~ wrote:

On Sep 4, 10 05:22, Andrei Alexandrescu wrote:

On 9/3/10 16:03 CDT, bearophile wrote:

JMRyan:

Is this a bug in the compiler (v.2.047)? Am I missing something in
thinking it shouldn't be?


I think it's not a bug. It's not a common need, but a method may way
want to swap this with another. In Phobos this is done on a struct, see:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324



Bye,
bearophile


For classes this must be an rvalue.

Andrei


If 'this' is an rvalue then it is not possible to take the address
('&this').


And I think you shouldn't do that either!

Andrei

Re: [Slight OT] TDPL in Russia

[Andrej Mitrovic]

But, you can't embed multiple track info in mp3's either..?

On Sat, Sep 4, 2010 at 4:50 AM, Walter Bright
 wrote:
> It still makes no sense to have it as a separate file.
>
> Andrej Mitrovic wrote:
>>
>> I'm pretty sure that's only for albums which are stored as a single
>> flac file. They usually come with a .cue file which stores track
>> lengths so you can split up the huge flac file into each track as a
>> flac. Then you can have per-track info stored in the flac files
>> themselves. As for splitting a .flac file that has a .cue file,
>> Medieval cue splitter is probably the best free tool for the job.
>>
>> On Sat, Sep 4, 2010 at 3:36 AM, Walter Bright
>>  wrote:
>>>
>>> Like how FLAC format does not allow for track info - you have to
>>> have a separate "cue" file for that.
>

Re: [OT] Dark Star (1974) - the platinum age of movies

[bearophile]

Jeff Nowakowski:
> I liked it, but it was a modern-day take on "Microcosmic God" from 1941. 
> I would be a little bit wary about attributing a bunch of new ideas from 
> him.

One story is a too much small sample. He has invented tons of ideas, but of 
course you are right that it's very hard to invent totally new things.

Bye,
bearophile

Re: [OT] Dark Star (1974) - the platinum age of movies

[Jeff Nowakowski]

On 09/03/2010 10:12 PM, bearophile wrote:


Greg Egan is exceptionally good and he invents some of the most incredible 
ideas, but he's not for everyone.


I was curious and checked out his website. I ended up reading the short 
story “Crystal Nights”: http://ttapress.com/553/crystal-nights-by-greg-egan/


I liked it, but it was a modern-day take on "Microcosmic God" from 1941. 
I would be a little bit wary about attributing a bunch of new ideas from 
him. Lots of ideas are "in the air" and in many cases there's not much 
new under the sun. Just a different variation on a theme. The stories 
may still be good, but they are not necessarily revolutionary.

Re: The new Mono GC

[Jacob Carlborg]

On 2010-09-04 07:01, Walter Bright wrote:

Sean Kelly wrote:

I think write barriers in this context are calls out to the GC to
notify it
of reference changes, and these are generated by the compiler. A language
like D that can call inline ASM, external C routines, etc, simply can't
provide that guarantee. SafeD maybe.


Such write barriers are a performance problem, too.


What I've read about garbage collection techniques I got the impression 
that you could implement a better and more efficient collector with 
write barriers that would outweigh the performance loss that comes with 
the barriers.


--
/Jacob Carlborg

any update on large file support for linux?

[Lars Holowko]

Hi everybody,

Are there any status updates on the large file support for dmd on Linux?
I found this bug: http://d.puremagic.com/issues/show_bug.cgi?id=3409
which has not been commented on for quite a while.
I was trying to dig around in druntime and phobos - a lot seems
already in place so I was hoping that I could get it to work with
minor hacking:
-  enable __USE_LARGEFILE64 for 32 bit dmd in
druntime/src/core/sys/posix/config.d (no idea why this is determined
by the processor's native pointer size)
- change std.stdio.File.seek to call fseeko instead of fseek

    void seek(long offset, int origin = SEEK_SET)
    {
        enforce(p && p.handle,
                "Attempting to seek() in an unopened file");
        // @@@ Dubious: why is fseek in std.c.stdio taking an int???
        errnoEnforce(core.sys.posix.stdio.fseeko(
//        errnoEnforce(core.stdc.stdio.fseek(
//                    p.handle, to!int(offset), origin) == 0,
                    p.handle, offset, origin) == 0,
                "Could not seek in file `"~p.name~"'");
    }


But when I run the slightly modified std.stdio sample:

import std.stdio;
import core.sys.posix.sys.types;
void main(string args[])
{
    writefln("Typeof(off_t) = %s", typeid(off_t));
    auto f = File("test.txt", "w"); // open for writing
    f.write("Hello");
    f.seek(1024 * 1024 * 1024 * 6, SEEK_SET);
    if (args.length > 1)
    {
        auto g = f; // now g and f write to the same file
                    // internal reference count is 2
        g.write(", ", args[1]);
        // g exits scope, reference count decreases to 1
    }
    f.writeln("!");
}

I get something like this:

Typeof(off_t) = long
std.exception.errnoexcept...@std/stdio.d(526): Could not seek in file
`test.txt' (Invalid argument)

./io_test() [0x8055833]
./io_test() [0x8054d40]
./io_test() [0x8049859]
./io_test() [0x804f6b6]
./io_test() [0x804f610]
./io_test() [0x804f6fa]
./io_test() [0x804f610]
./io_test() [0x804f5b6]
/lib32/libc.so.6(__libc_start_main+0xe6) [0xf763bbd6]
./io_test() [0x8049741]



nm io_test | grep -e fopen -e fseek
080552f0 T _D3std5stdio5fopenFxAaxAaZPOS4core4stdc5stdio6_iobuf
         U fopen64@@GLIBC_2.1
         U fseeko64@@GLIBC_2.1

The 64 bit fopen and fseek calls seem to be linked, off_t is correctly
aliased to long. Does anyone have an idea what else I might be
missing?
Thanks a lot,

Lars

Re: this as lvalue?

[Jonathan M Davis]

On Saturday 04 September 2010 01:32:03 KennyTM~ wrote:
> On Sep 4, 10 05:22, Andrei Alexandrescu wrote:
> > On 9/3/10 16:03 CDT, bearophile wrote:
> >> JMRyan:
> >>> Is this a bug in the compiler (v.2.047)? Am I missing something in
> >>> thinking it shouldn't be?
> >> 
> >> I think it's not a bug. It's not a common need, but a method may way
> >> want to swap this with another. In Phobos this is done on a struct, see:
> >> http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#
> >> L324
> >> 
> >> 
> >> Bye,
> >> bearophile
> > 
> > For classes this must be an rvalue.
> > 
> > Andrei
> 
> If 'this' is an rvalue then it is not possible to take the address
> ('&this').

And of what possible use would taking the address of an object reference be?

- Jonathan M Davis

Re: [Slight OT] TDPL in Russia

[Max Samukha]

On 04.09.2010 5:50, Walter Bright wrote:

It still makes no sense to have it as a separate file.



Yeah. Just like it makes no sense to have headers separate from object 
files.

Re: this as lvalue?

[KennyTM~]

On Sep 4, 10 05:22, Andrei Alexandrescu wrote:

On 9/3/10 16:03 CDT, bearophile wrote:

JMRyan:

Is this a bug in the compiler (v.2.047)? Am I missing something in
thinking it shouldn't be?


I think it's not a bug. It's not a common need, but a method may way
want to swap this with another. In Phobos this is done on a struct, see:
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324


Bye,
bearophile


For classes this must be an rvalue.

Andrei


If 'this' is an rvalue then it is not possible to take the address 
('&this').

Re: Please comment on http://d-programming-language.org/

[HST]

Am 02.09.2010 15:34, schrieb Alexander Malakhov:


7. "Documentation"->"Library Reference" link is broken


It would be nice to include the print.css stylesheet into the phobos 
docs (for D1 and D2 on digitalmars.com as well) to get rid of the menu 
margins.

Re: [Slight OT] TDPL in Russia

[Nick Sabalausky]

"Steven Schveighoffer"  wrote in message 
news:op.vig8crpreav...@localhost.localdomain...
>
> And OMG, you've never bought a cell phone?  Why are you punishing yourself 
> ;)  I suppose with the attitude you have towards them it would just raise 
> your blood pressure carrying it around...
>

It would :) But I have other reasons for not having one. One of them is that 
I just don't do anywhere near enough yapping (outside of NG text, of course 
;) ) for it to be worthwhile. Cell companies don't even have a plan that 
would be small enough to be appropriate for me. But the landlines do, and 
with the tiny amount of talking I do, waiting until I get home to use the 
phone is a complete non-issue (especially since I'd be the only cell owner 
in the world to that would refuse to use it while driving). And I don't even 
*want* to be reachable 24/7. Unlimited minutes? Forget it. Back when pay 
phones still existed, my away-from-home phone usage never totaled more than 
$5/yr. Try finding a cell plan that competes with that.

> Your lack of experience with cell phones does not give any boost to your 
> position...
>

I never said I lacked experience with them, I said I never owned one. I've 
used them plenty, and I've even done WAP/WML sites (I'm glad that's gone!) 
and C/J2ME on Symbian.

>
> Huh?  Why should verizon go out of its way to allow you to use its phones 
> with other services?  Maybe you don't understand capitalism...
>

1. Anti-competitive practices are illegal under capitalism (...but then 
again, so is having the government in your company's pocket). In any case, 
the destruction of consumer choice is a hallmark of communism, not 
capitalism. Contrary to popular belief, capitalism doesn't bean bending over 
a table and taking it so big business can make a couple extra bucks.

2. Companies like Verizon doesn't make phones. They pay companies like Nokia 
and Samsung to slap on branded stickers, or just commission them to build 
proprietary phones.

People used to rent phones from the land-line companies. Then cross-provider 
for-purchase phones came around. That was a good thing. Now people want to 
go backwards.

>
> But cell phones and  computers change so fast that the hardware is 
> obsolete before it's broken.
>

That just absurd. Just because a newer fizzbarwidget comes out doesn't mean 
you can't keep using your old one...unless you happen to be an Apple 
customer.

Do I need to link to my phone again? I've had that probably close to ten 
years and all the cell phones and smart phone features in the world aren't 
doing a damn thing to make my phone suddenly cease functioning. How would 
they? Seek-and-destroy mini-missiles?

Obsolescence comes from three things:

1. Forced by big business strong-arming people into buying products via 
subscription model.

2. Physical breaking down.

3. The consumer *themself* deciding to get the new one *despite* the old one 
still working fine (If it didn't still work fine, it would fall under #1 or 
#2) .

Notice that "a newer one came out and proceeded to break all the old ones" 
isn't in there.

>> However, outside the cell phone world, such situations are likely to 
>> result
>> in dual-use devices
>
> There were some phones like that.  Nobody cared ;)
>

Yea, widespread contract lock-in, along with cable-card-style 
sweeping-it-under-the-rug will do that. (You don't expect me to believe the 
carriers didn't try to steer people away from those phones, do you?)

>
> I've had two old-style touch screen phones before this.  They suck.  They 
> break, require calibration, and require a stylus.  My samsung phone got to 
> be so inaccurate that I pretty much avoided using the touch screen as much 
> as possible.  I'll pay the price of lost accuracy when positioning a 
> cursor in order to avoid having to pop out a stylus to press on-screen 
> buttons.
>

*Shrug* Both of my PalmOS devices still work fine, the accuracy always 
worked fine, calibration takes about two seconds and is a one-time deal, I 
never had a problem with a fingernail, and I like syluses (stylii?).

>>
>> Which is exactly why it's idiotic for Apple to make the entire interface
>> touchscreen.  You do that and you lose tactile feedback and you can't 
>> just
>> hack it back in. If you took my Palm Pilot, replaced the 
>> up/down/left/right
>> and app buttons with touchscreen input, that would be a step *backwards*.
>> You'd gain nothing but a questionable "cool factor", and the UI would 
>> just
>> simply be worse.
>
> But PalmOS is not iOS.  I've had about 5 palms, starting with the palm 
> III, and I like the apple interface significantly more.
>

Just to be clear, I wasn't suggesting iOS used the exact same buttonset as 
PalmOS.

>>> The screen is made of pretty durable glass.  Like all touch-screen 
>>> phones,
>>> it's highly advisable to get a screen protector for it.  I don't get 
>>> what
>>> your problem is here, do you want a screen or not?  If you do, then what
>>> possible way cou