www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Poll: Primary D version

reply "Nick Sabalausky" <a a.a> writes:
I'm interested in trying to gauge the current state of D version usage, so 
I've set up a poll:

http://micropoll.com/t/KEFfsZBH5F

I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I 
personally hate MicroPoll but everything else I've seen is even worse and I 
don't have time to make a custom one.
May 19 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Nick,

 I'm interested in trying to gauge the current state of D version
 usage, so I've set up a poll:
 
 http://micropoll.com/t/KEFfsZBH5F
 
 I apologize for using MicroPoll (and all its
 manditory-JavaScript-ness). I personally hate MicroPoll but everything
 else I've seen is even worse and I don't have time to make a custom
 one.
 

your missing "Mosty Dx but some of the other." -- ... <IXOYE><
May 20 2010
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff13eaa8ccc5f8db8fcfd6 news.digitalmars.com...
 Hello Nick,

 I'm interested in trying to gauge the current state of D version
 usage, so I've set up a poll:

 http://micropoll.com/t/KEFfsZBH5F

 I apologize for using MicroPoll (and all its
 manditory-JavaScript-ness). I personally hate MicroPoll but everything
 else I've seen is even worse and I don't have time to make a custom
 one.

your missing "Mosty Dx but some of the other."

The idea was just to gauge which one a person leans more heavily towards.
May 20 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 20 de mayo a las 02:52 me escribiste:
 I'm interested in trying to gauge the current state of D version usage, so 
 I've set up a poll:
 
 http://micropoll.com/t/KEFfsZBH5F
 
 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I 
 personally hate MicroPoll but everything else I've seen is even worse and I 
 don't have time to make a custom one.

Oh, yeah! Only USA uses D... Nice =P -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- We're rotten fruit We're damaged goods What the hell, we've got nothing more to lose One gust and we will probably crumble We're backdrifters
May 20 2010
prev sibling next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
OBG! I'm minority! (still stuck on 1.030)

Nick Sabalausky Wrote:

 I'm interested in trying to gauge the current state of D version usage, so 
 I've set up a poll:
 
 http://micropoll.com/t/KEFfsZBH5F
 
 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I 
 personally hate MicroPoll but everything else I've seen is even worse and I 
 don't have time to make a custom one.
 
 

May 20 2010
next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
OMG! I can't even spell OMG right!

 OBG! I'm minority! (still stuck on 1.030)
 
 Nick Sabalausky Wrote:
 
 I'm interested in trying to gauge the current state of D version usage, so 
 I've set up a poll:
 
 http://micropoll.com/t/KEFfsZBH5F
 
 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I 
 personally hate MicroPoll but everything else I've seen is even worse and I 
 don't have time to make a custom one.
 
 


May 20 2010
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bane wrote:
 OMG! I can't even spell OMG right!
 
 OBG! I'm minority! (still stuck on 1.030)


rofl. you tool. (i mean that in a good way) I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL9XkwT9LetA9XoXwRAslqAKCGBjh2XR3WJ1Pc6wAn0kiMZgTYbACfSXy5 UujYfGkxvmEj/e8TBDZfCIQ= =+GPH -----END PGP SIGNATURE-----
May 20 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"div0" <div0 users.sourceforge.net> wrote in message 
news:ht3tfa$2smm$1 digitalmars.com...
 I'm surprised so many people who don't use D bother to read this news
 group and voted on the poll. Surely they must have better things to do.

I have a few guesses for that phonomenon: - There are a lot of people who are keeping a close eye on D, but aren't ready/able to commit to any use just yet. In fact, I've already been under the impression that that's the case. - Troll and/or trolls. I turned on "enable IP logging", but I didn't turn on "prevent multiple votes from same IP", since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. - Maybe people misunderstood what I meant by "Which version of D do you primarily use?". What I meant was "When you use D, which version do you use more heavily?". Maybe there are people thinking "Well, I use D, but my primary language is C/Python/Java/whatever, so I'll say 'None'". Question to all, including lurkers: Did anyone say "None" because that's what they thought it meant?
May 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ht3uj4$30fv$1 digitalmars.com...
 "div0" <div0 users.sourceforge.net> wrote in message 
 news:ht3tfa$2smm$1 digitalmars.com...
 I'm surprised so many people who don't use D bother to read this news
 group and voted on the poll. Surely they must have better things to do.

I have a few guesses for that phonomenon:

 - Troll and/or trolls. I turned on "enable IP logging", but I didn't turn 
 on "prevent multiple votes from same IP", since shared IPs are fairly 
 common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit 
 D-Downvoters found it. Maybe I made a mistake by not preventing multiple 
 votes from same IP. Maybe if it turn that on it'll apply 
 retro-actively...or maybe not? I dunno, I really should get around to 
 making my own poll software.


I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia.
May 20 2010
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Nick Sabalausky Wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:ht3uj4$30fv$1 digitalmars.com...
 "div0" <div0 users.sourceforge.net> wrote in message 
 news:ht3tfa$2smm$1 digitalmars.com...
 I'm surprised so many people who don't use D bother to read this news
 group and voted on the poll. Surely they must have better things to do.

I have a few guesses for that phonomenon:

 - Troll and/or trolls. I turned on "enable IP logging", but I didn't turn 
 on "prevent multiple votes from same IP", since shared IPs are fairly 
 common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit 
 D-Downvoters found it. Maybe I made a mistake by not preventing multiple 
 votes from same IP. Maybe if it turn that on it'll apply 
 retro-actively...or maybe not? I dunno, I really should get around to 
 making my own poll software.


I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia.

Thats great. It proves my point - even D trolls are loyal to the project. 72 votes? That is some dedication.
May 21 2010
next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
 What is more interesting is that the majority of D users already use D2, 
 which has a huge list of bugs. It just tells that most D users don't use 
 D in serious / mission critical / money bringing projects, but instead as 
 a hobby. 

I'm in serious business with it. I think D1 is up to it pretty well.
May 21 2010
parent Bane <branimir.milosavljevic gmail.com> writes:
Bane Wrote:
 What is more interesting is that the majority of D users already use D2, 
 which has a huge list of bugs. It just tells that most D users don't use 
 D in serious / mission critical / money bringing projects, but instead as 
 a hobby. 

I'm in serious business with it. I think D1 is up to it pretty well.

D1 I mean. Shit. I lack clarity.
May 21 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 What is more interesting is that the majority of D users already use D2, 
 which has a huge list of bugs. It just tells that most D users don't use 
 D in serious / mission critical / money bringing projects, but instead as 
 a hobby. 

What matters not is the number of bugs, it is whether they block reasonable use of the compiler. Just one bug can make it unusable, whereas a thousand insignificant ones may not.
May 21 2010
parent Alex Makhotin <alex bitprox.com> writes:
Walter Bright wrote:
 What matters not is the number of bugs, it is whether they block 
 reasonable use of the compiler. Just one bug can make it unusable, 
 whereas a thousand insignificant ones may not.

In Steven's dcollections excerpt starting from dcollections/model/List.d, line #80:
 // workaround for compiler deficiencies.  Note you MUST repeat this in
         // derived classes to achieve covariance (see bug 4182).
         alias concat opCat;
         alias concat_r opCat_r;
         alias add opCatAssign;

http://d.puremagic.com/issues/show_bug.cgi?id=4182 Could you please explain is this a bug or feature? -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
May 21 2010
prev sibling next sibling parent reply Eric Poggel <dnewsgroup yage3d.net> writes:
On 5/21/2010 1:57 PM, retard wrote:
 hat is more interesting is that the majority of D users already use D2,
 which has a huge list of bugs. It just tells that most D users don't use
 D in serious / mission critical / money bringing projects, but instead as
 a hobby.

Or possibly, D newsgroup followers are mostly early-adopters, which makes the poll skewed toward D2.
May 21 2010
parent "Nick Sabalausky" <a a.a> writes:
"Eric Poggel" <dnewsgroup yage3d.net> wrote in message 
news:ht7i0u$hv1$1 digitalmars.com...
 On 5/21/2010 1:57 PM, retard wrote:
 hat is more interesting is that the majority of D users already use D2,
 which has a huge list of bugs. It just tells that most D users don't use
 D in serious / mission critical / money bringing projects, but instead as
 a hobby.

Or possibly, D newsgroup followers are mostly early-adopters, which makes the poll skewed toward D2.

I also posted on the Tango message board, which is definitely skewed towards D1. But then again, that only has 25 views and I know at least five of them were me reloading the page.
May 21 2010
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
retard Wrote:
 
 What is more interesting is that the majority of D users already use D2, 
 which has a huge list of bugs. It just tells that most D users don't use 
 D in serious / mission critical / money bringing projects, but instead as 
 a hobby. 

I've yet to use a compiler that had zero bugs I needed to consider when writing code. What's more important to me is that the bugs that do exist shouldn't unduly inconvenience me, nor should they hurt my ability to easily move to a newer compiler later. VC6 was terrible in this respect--it crashed constantly, and so badly supported the language spec that I had to purposefully write screwed up code just so it would compile. Moving to VC7 took a lot of rewriting. Assuming there are no sufficiently annoying bugs in DMD2 I'd rather work with the latest language spec to make my app more maintainable over time. In a work environment, I think it's more important that a compiler be supported than that it be bug-free.
May 21 2010
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Kelly wrote:
 retard Wrote:
 What is more interesting is that the majority of D users already use D2, 
 which has a huge list of bugs. It just tells that most D users don't use 
 D in serious / mission critical / money bringing projects, but instead as 
 a hobby. 

I've yet to use a compiler that had zero bugs I needed to consider when writing code. What's more important to me is that the bugs that do exist shouldn't unduly inconvenience me, nor should they hurt my ability to easily move to a newer compiler later. VC6 was terrible in this respect--it crashed constantly, and so badly supported the language spec that I had to purposefully write screwed up code just so it would compile. Moving to VC7 took a lot of rewriting. Assuming there are no sufficiently annoying bugs in DMD2 I'd rather work with the latest language spec to make my app more maintainable over time. In a work environment, I think it's more important that a compiler be supported than that it be bug-free.

Well I'm still using 2.028. Every version I've tried since has had a compiler bug that's been a show stopper. However I'm in no major rush, there's enough momentum in progress for me to be confidant that it will work eventually. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL+BW1T9LetA9XoXwRAthRAJ9lrqaoqWj7QAZxc3Aye4Mldk/OiACfWvT0 sjc5M0Q5/zhzDoCQ7y1V4CQ= =P4EP -----END PGP SIGNATURE-----
May 22 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
div0 wrote:
 Well I'm still using 2.028. Every version I've tried since has had a
 compiler bug that's been a show stopper. However I'm in no major rush,
 there's enough momentum in progress for me to be confidant that it will
 work eventually.

Which one is your current showstopper?
May 22 2010
parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:
 div0 wrote:
 Well I'm still using 2.028. Every version I've tried since has had a
 compiler bug that's been a show stopper. However I'm in no major rush,
 there's enough momentum in progress for me to be confidant that it will
 work eventually.

Which one is your current showstopper?

http://d.puremagic.com/issues/show_bug.cgi?id=3712 Except for me, it's something to do with the change to struct initializers. Error: struct clr has constructors, cannot use { initializers }, use clr( initializers ) instead ty. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFL+Qa/T9LetA9XoXwRApAzAKCTy5B+j+jh/UPsUEuSU7INQIgadACfUlWU t/lY1I7V1FP+yWPx1APeUJg= =ckRX -----END PGP SIGNATURE-----
May 23 2010
prev sibling parent user domain.invalid writes:
div0 wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Bane wrote:
 OMG! I can't even spell OMG right!

 OBG! I'm minority! (still stuck on 1.030)


rofl. you tool. (i mean that in a good way) I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do.

I'm keeping an eye on D.
Jun 12 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
As a thought, when/if you decide to write your own polling system, I
think it should log the website referrer as well as the voter's ip and
choice.

It'd be interesting to see stats about skewing from a certain site,
like if everyone who followed a link on "d-sucks-ass.org" voted "none
and never will", you might be able to discount them as trolls.
May 20 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Nick Sabalausky <a a.a> wrote:

 I've looked into this a little. I was able to download a chart of the  
 IPs,
 and the number of votes per IP. Unfortunately, there doesn't seem to be  
 any
 way to tell anything about the actual votes from a particular IP, which I
 suppose is good for privacy, but it prevents me from looking at an IP  
 with
 multiple votes and determining if all of the votes were suspiciously
 strongly favoring the one option.

 There are 105 IPs. The vast majority of the IPs only had one vote. There
 were five IPs that had two votes each, and one IP that had three votes.  
 I'm
 willing to assume those are just multiple people from the same ISP, and  
 even
 if not they're not particularly significant compared to the rest. But  
 then
 there was one IP with 72 votes. So, yea, that does seem suspicious. In  
 case
 anyone thinks they might have more insight, the IP in question is
 115.131.192.250, and appears to be from Austrailia.

Looking at the statistics, if we assume all those 72 votes are for 'None - Not likely to use D anytime soon', we get these nice numbers: D2 43 % Both D1 and D2 fairly equally 3 % D1 - Not likely to use D2 anytime soon 28 % D1 - Likely to switch to D2 soon 6 % D1 - Likely to do both D1 and D2 soon 5 % None - Not likely to use D anytime soon 9 % None - Likely to use D2 soon 6 % None - Likely to use D1 soon 0 % None - Likely to use both D1 and D2 soon 0 % Honestly, I find this to seem more likely as a serious result. That said, I do not expect 43% of programmers to be using D at the moment. :P -- Simen
May 20 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 21 May 2010 11:00:32 -0400, Bane wrote:

 Nick Sabalausky Wrote:
 
 "Nick Sabalausky" <a a.a> wrote in message
 news:ht3uj4$30fv$1 digitalmars.com...
 "div0" <div0 users.sourceforge.net> wrote in message
 news:ht3tfa$2smm$1 digitalmars.com...
 I'm surprised so many people who don't use D bother to read this
 news group and voted on the poll. Surely they must have better
 things to do.


 - Troll and/or trolls. I turned on "enable IP logging", but I didn't
 turn on "prevent multiple votes from same IP", since shared IPs are
 fairly common. Maybe GirlProgrammer's been messing with it. Or maybe
 the Reddit D-Downvoters found it. Maybe I made a mistake by not
 preventing multiple votes from same IP. Maybe if it turn that on
 it'll apply retro-actively...or maybe not? I dunno, I really should
 get around to making my own poll software.


IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia.

project. 72 votes? That is some dedication.

What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby.
May 21 2010
prev sibling parent "Viktor H." <viktor.h laposte.net> writes:
On Thu, 2010-05-20 at 14:19 -0400, Nick Sabalausky wrote:=20
 "div0" <div0 users.sourceforge.net> wrote in message=20
 news:ht3tfa$2smm$1 digitalmars.com...
 I'm surprised so many people who don't use D bother to read this news
 group and voted on the poll. Surely they must have better things to do.

I have a few guesses for that phonomenon: =20 - There are a lot of people who are keeping a close eye on D, but aren't=20 ready/able to commit to any use just yet. In fact, I've already been unde=

 the impression that that's the case.

That's exactly my case. I'm waiting for D2 to stabilise, for D2 compilers to hit Debian unstable, and for me having both some time and a good itch to scratch. For the time being, I find this newsgroup very informative, versatile and yet not too busy to follow as an infrequent visitor. Thanks to everyone who makes this possible, Viktor.
May 21 2010
prev sibling next sibling parent reply Matthias Pleh <matthias.pleh gmx.at> writes:
Am 20.05.2010 08:52, schrieb Nick Sabalausky:
 I'm interested in trying to gauge the current state of D version usage, so
 I've set up a poll:

 http://micropoll.com/t/KEFfsZBH5F

 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I
 personally hate MicroPoll but everything else I've seen is even worse and I
 don't have time to make a custom one.

Oh god, we have to inform micropoll, there is more than the USA ...
May 21 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Matthias Pleh" <matthias.pleh gmx.at> wrote in message 
news:ht6p7t$27sk$1 digitalmars.com...
 Oh god, we have to inform micropoll, there is more than the USA ...

"Kagamin" <spam here.lot> wrote in message news:ht6jgv$1tbs$1 digitalmars.com...
 I'd appreciate js, but pissed off by flash.

Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )
May 21 2010
parent reply Matthias Pleh <matthias.pleh gmx.at> writes:
Am 21.05.2010 22:27, schrieb Nick Sabalausky:
 "Matthias Pleh"<matthias.pleh gmx.at>  wrote in message
 news:ht6p7t$27sk$1 digitalmars.com...
 Oh god, we have to inform micropoll, there is more than the USA ...

"Kagamin"<spam here.lot> wrote in message news:ht6jgv$1tbs$1 digitalmars.com...
 I'd appreciate js, but pissed off by flash.

Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )

Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows ....
May 21 2010
next sibling parent Not your grandma <some mail.com> writes:
Matthias Pleh Wrote:

 Am 21.05.2010 22:27, schrieb Nick Sabalausky:
 "Matthias Pleh"<matthias.pleh gmx.at>  wrote in message
 news:ht6p7t$27sk$1 digitalmars.com...
 Oh god, we have to inform micropoll, there is more than the USA ...

"Kagamin"<spam here.lot> wrote in message news:ht6jgv$1tbs$1 digitalmars.com...
 I'd appreciate js, but pissed off by flash.

Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )

Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows ....

Does it say "See how users are polling in Bohinj : Total Votes : 2" for you too?
May 21 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Matthias Pleh" <matthias.pleh gmx.at> wrote in message 
news:ht6t33$2fv3$1 digitalmars.com...
 Am 21.05.2010 22:27, schrieb Nick Sabalausky:
 "Matthias Pleh"<matthias.pleh gmx.at>  wrote in message
 news:ht6p7t$27sk$1 digitalmars.com...
 Oh god, we have to inform micropoll, there is more than the USA ...

"Kagamin"<spam here.lot> wrote in message news:ht6jgv$1tbs$1 digitalmars.com...
 I'd appreciate js, but pissed off by flash.

Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )

Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows ....

I was surprised to see that there's another D user in Ohio besides me. From what I've seen, all the good programmers usually leave Ohio, and we're just left with the cruft.
May 21 2010
prev sibling parent Matthias Pleh <matthias.pleh gmx.at> writes:
Am 21.05.2010 23:14, schrieb Matthias Pleh:
 Am 21.05.2010 22:27, schrieb Nick Sabalausky:
 "Matthias Pleh"<matthias.pleh gmx.at> wrote in message
 news:ht6p7t$27sk$1 digitalmars.com...
 Oh god, we have to inform micropoll, there is more than the USA ...

"Kagamin"<spam here.lot> wrote in message news:ht6jgv$1tbs$1 digitalmars.com...
 I'd appreciate js, but pissed off by flash.

Yea, micropoll unfortunately has a lot of deficiencies. Like, when I was typing in the possible choices, the text box was lagging by roughly a second. And I've had some discussion with their support staff, and they seem to be the type of support people who are very easily confused. (Either that, or I'm just a hell of a lot worse at explaining things than I think I am ;) )

Funny is, that it shows me in the result that there were 2 votes in my area of about a radius of 50km, so there must be another D-enthusiast near by me, maybe my grandmother, who knows ....

It says "See how users are polling in Vorarlberg : Total Votes : 2" So it seems that in every erea of us life 2 D-enthusiasts ...
May 22 2010
prev sibling next sibling parent Matthias Pleh <matthias.pleh gmx.at> writes:
Am 20.05.2010 08:52, schrieb Nick Sabalausky:
 I'm interested in trying to gauge the current state of D version usage, so
 I've set up a poll:

 http://micropoll.com/t/KEFfsZBH5F

 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I
 personally hate MicroPoll but everything else I've seen is even worse and I
 don't have time to make a custom one.

For all who want to see the current result, without voting twice: http://www.micropoll.com/akira/mpresult/928402-256449
May 22 2010
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 20/05/10 07:52, Nick Sabalausky wrote:
 I'm interested in trying to gauge the current state of D version usage, so
 I've set up a poll:

 http://micropoll.com/t/KEFfsZBH5F

 I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I
 personally hate MicroPoll but everything else I've seen is even worse and I
 don't have time to make a custom one.

I put my vote with D1 & 2, although truthfully I've moved back to D1 for the most part. I found D2 almost impossible to use, for a few reasons: - Safe D was impossible to use due to phobos not supporting this (although this seems to be close to a fix) - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions - to!() didn't work in most cases where I tried to use it, I ended up writing my own conversion functions - Various bugs I encountered which have already been reported (I forget which ones). - Lack of an x86_64 compiler. I spent far too long messing around setting up a multilib system, and ended up making a chroot for dmd. This is far too much effort/messing around, and should I ever feel there's a use for my apps outside of localhost people will wonder why they don't support x86_64 natively (I believe this will change after D2 from various comments from Walter). - Lack of containers in phobos, although dcollections may have solved this now, I haven't had chance to look There were some other reasons I've forgotten, but until at least some of these are fixed I'll stick to D1/Tango... I hope I can move back to D2 at some point in the future once it's stabilized a bit more.
May 22 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2010 08:29 AM, Robert Clipsham wrote:
 On 20/05/10 07:52, Nick Sabalausky wrote:
 I'm interested in trying to gauge the current state of D version
 usage, so
 I've set up a poll:

 http://micropoll.com/t/KEFfsZBH5F

 I apologize for using MicroPoll (and all its
 manditory-JavaScript-ness). I
 personally hate MicroPoll but everything else I've seen is even worse
 and I
 don't have time to make a custom one.

I put my vote with D1 & 2, although truthfully I've moved back to D1 for the most part. I found D2 almost impossible to use, for a few reasons: - Safe D was impossible to use due to phobos not supporting this (although this seems to be close to a fix) - Interfacing to C libraries is now overly complex thanks to const correctness. After updating all the function signatures I found phobos was completely lacking the functions to convert between C and D strings of varying constness or with different encodings (char/wchar/dchar).. I ended up writing my own functions

Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness.
 - to!() didn't work in most cases where I tried to use it, I ended up
 writing my own conversion functions

to is deliberately defined to be restrictive; parse is more forgiving. Anyway, I'd be glad to improve to if you gave me a few hints.
 - Various bugs I encountered which have already been reported (I forget
 which ones).
 - Lack of an x86_64 compiler. I spent far too long messing around
 setting up a multilib system, and ended up making a chroot for dmd. This
 is far too much effort/messing around, and should I ever feel there's a
 use for my apps outside of localhost people will wonder why they don't
 support x86_64 natively (I believe this will change after D2 from
 various comments from Walter).
 - Lack of containers in phobos, although dcollections may have solved
 this now, I haven't had chance to look

 There were some other reasons I've forgotten, but until at least some of
 these are fixed I'll stick to D1/Tango... I hope I can move back to D2
 at some point in the future once it's stabilized a bit more.

Yah, for most of these things are definitely looking up. Thanks, and I'd appreciate any more detail you might have. Andrei
May 22 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 22/05/10 17:42, Andrei Alexandrescu wrote:
 - Interfacing to C libraries is now overly complex thanks to const
 correctness. After updating all the function signatures I found phobos
 was completely lacking the functions to convert between C and D strings
 of varying constness or with different encodings (char/wchar/dchar).. I
 ended up writing my own functions

Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness.

extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it. extern(C)void someFunc(wchar*); This is impossible with phobos, there's no function to convert a D string to wchar*, not even one where I could cast away constness. This includes dchar* too.
 - to!() didn't work in most cases where I tried to use it, I ended up
 writing my own conversion functions

to is deliberately defined to be restrictive; parse is more forgiving. Anyway, I'd be glad to improve to if you gave me a few hints.

Any of the above conversions would be nice, although I appreciate that there's no way to tell if it's a C style string or a pointer to a single char. There were several other situations which I worked around but didn't note down, so I can't list them here.
May 22 2010
next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 05/22/2010 08:26 PM, Robert Clipsham wrote:
 extern(C)void someFunc(char*);

 There is no function in phobos which will allow me to call this function
 using a D string

You could use (array.dup ~ '\0').ptr, right?
 extern(C)void someFunc(wchar*);

 This is impossible with phobos, there's no function to convert a D
 string to wchar*, not even one where I could cast away constness. This
 includes dchar* too.

to!(wchar[])(chararray) works.
May 22 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:
 On 22/05/10 17:42, Andrei Alexandrescu wrote:
 - Interfacing to C libraries is now overly complex thanks to const
 correctness. After updating all the function signatures I found phobos
 was completely lacking the functions to convert between C and D strings
 of varying constness or with different encodings (char/wchar/dchar).. I
 ended up writing my own functions

Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness.

extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it.

What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it.
May 22 2010
parent reply Mike Parker <aldacron gmail.com> writes:
Walter Bright wrote:
 Robert Clipsham wrote:
 On 22/05/10 17:42, Andrei Alexandrescu wrote:
 - Interfacing to C libraries is now overly complex thanks to const
 correctness. After updating all the function signatures I found phobos
 was completely lacking the functions to convert between C and D strings
 of varying constness or with different encodings (char/wchar/dchar).. I
 ended up writing my own functions

Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness.

extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it.

What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it.

That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args.
May 22 2010
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 5/22/2010 23:16, Mike Parker wrote:
 That's not the problem. The problem is this:
 
 const(char)* toStringz(const(char)[] s);
 
 There's no equivalent for:
 
 char *toStringz(char[] s);
 
 Hence the need to cast away const or use a wrapper for non-const char*
 args.

There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'. -- Rainer Deyke - rainerd eldwood.com
May 22 2010
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
Rainer Deyke wrote:
 On 5/22/2010 23:16, Mike Parker wrote:
 That's not the problem. The problem is this:

 const(char)* toStringz(const(char)[] s);

 There's no equivalent for:

 char *toStringz(char[] s);

 Hence the need to cast away const or use a wrapper for non-const char*
 args.

There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'.

I understand that. But, ignoring the fact that toStringz in D1 seems to have functioned perfectly fine for several years without a const return, it doesn't change the fact that a C function call that accepts a char* expects it to be null-terminated, regardless of what happens to it on the other side. And I would argue that it's unreasonable to expect the declarations of C functions to be declared const-correct based on their usage. To my knowledge, all of the C bindings for D to date either don't use const at all (because they were created for D1) or use it according to the declarations in the C headers. Which means there are numerous C functions out there with non-const params that do not modify them. Then there's the issue of compatibility between D1/D2. I've bound several C libraries for D that need to support both D1/D2, Phobos/Tango. Supporting const was one of the first headaches I encountered when porting the original D1 bindings to D2. Finding that toStringz returned a const string was a big surprise.
May 23 2010
parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/23/2010 10:14 AM, Mike Parker wrote:
 And I would argue that it's unreasonable to expect the declarations of C
 functions to be declared const-correct based on their usage. To my
 knowledge, all of the C bindings for D to date either don't use const at
 all (because they were created for D1) or use it according to the
 declarations in the C headers. Which means there are numerous C
 functions out there with non-const params that do not modify them.

I do them according to the C headers, and the constness is almost always correct. Otherwise, it's a bug in the C headers!
 Then there's the issue of compatibility between D1/D2. I've bound
 several C libraries for D that need to support both D1/D2, Phobos/Tango.
 Supporting const was one of the first headaches I encountered when
 porting the original D1 bindings to D2. Finding that toStringz returned
 a const string was a big surprise.

It should probably be inout(char)* toStringz(inout(char)[]), or something like that.
May 23 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2010 04:47 AM, Pelle wrote:
 On 05/23/2010 10:14 AM, Mike Parker wrote:
 And I would argue that it's unreasonable to expect the declarations of C
 functions to be declared const-correct based on their usage. To my
 knowledge, all of the C bindings for D to date either don't use const at
 all (because they were created for D1) or use it according to the
 declarations in the C headers. Which means there are numerous C
 functions out there with non-const params that do not modify them.

I do them according to the C headers, and the constness is almost always correct. Otherwise, it's a bug in the C headers!

Yes. My experience with C headers is that they're always careful about inserting const for read-only pointer parameters.
 Then there's the issue of compatibility between D1/D2. I've bound
 several C libraries for D that need to support both D1/D2, Phobos/Tango.
 Supporting const was one of the first headaches I encountered when
 porting the original D1 bindings to D2. Finding that toStringz returned
 a const string was a big surprise.

It should probably be inout(char)* toStringz(inout(char)[]), or something like that.

It could, but what C functions output to a zero-terminated char*? I can only think of unsafe ones, such as strcat() and gets(). Both are inherently unsafe. Andrei
May 23 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2010 12:30 AM, Rainer Deyke wrote:
 On 5/22/2010 23:16, Mike Parker wrote:
 That's not the problem. The problem is this:

 const(char)* toStringz(const(char)[] s);

 There's no equivalent for:

 char *toStringz(char[] s);

 Hence the need to cast away const or use a wrapper for non-const char*
 args.

There is no way to define this function with the correct semantics in D. 'toStringz' must append a null character to the string, therefore it cannot return a pointer to the original string data in the general case. If you pass the resulting string to a function that mutates it, then the changes will not be reflected in the original string. If you pass the resulting string to a function that does /not/ mutate it, then that function should be defined to take a 'const char *'.

There is a way, you could simply allocate a copy plus the \0 on the GC heap. In fact that's what happens right now. Andrei
May 23 2010
parent Rainer Deyke <rainerd eldwood.com> writes:
On 5/23/2010 07:33, Andrei Alexandrescu wrote:
 On 05/23/2010 12:30 AM, Rainer Deyke wrote:
 There is no way to define this function with the correct semantics in D.
   'toStringz' must append a null character to the string, therefore it
 cannot return a pointer to the original string data in the general case.
   If you pass the resulting string to a function that mutates it, then
 the changes will not be reflected in the original string.

 If you pass the resulting string to a function that does /not/ mutate
 it, then that function should be defined to take a 'const char *'.

There is a way, you could simply allocate a copy plus the \0 on the GC heap. In fact that's what happens right now.

No, the problem is getting any changes to the copy back to the original. It can be done, but not with a simple conversion function. -- Rainer Deyke - rainerd eldwood.com
May 23 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/23/2010 12:16 AM, Mike Parker wrote:
 Walter Bright wrote:
 Robert Clipsham wrote:
 On 22/05/10 17:42, Andrei Alexandrescu wrote:
 - Interfacing to C libraries is now overly complex thanks to const
 correctness. After updating all the function signatures I found phobos
 was completely lacking the functions to convert between C and D
 strings
 of varying constness or with different encodings
 (char/wchar/dchar).. I
 ended up writing my own functions

Could you please give more detail on that? There should be essentially no problem with using C-style strings with D regardless of constness.

extern(C)void someFunc(char*); There is no function in phobos which will allow me to call this function using a D string, toStringz() gives: test.d(4): Error: function test.someFunc (char*) is not callable using argument types (const(char)*) Unless I cast away const, which isn't pretty if you've got a lot of these functions, unless you write a wrapper for each one (my current hack). to!() doesn't support it at all, and I can't find another method in phobos for it.

What's necessary is to decide if someFunc changes the string data or not. If it does not, then it should be prototyped as: extern (C) void someFunc(const char *); If it does, then the char* is the correct declaration, and an immutable string should not be passed to it.

That's not the problem. The problem is this: const(char)* toStringz(const(char)[] s); There's no equivalent for: char *toStringz(char[] s); Hence the need to cast away const or use a wrapper for non-const char* args.

Yah, and that's intentional. APIs that use zero-terminated strings for output are very rare and most often inherently unsafe. Andrei
May 23 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 to is deliberately defined to be restrictive; parse is more forgiving. 
 Anyway, I'd be glad to improve to if you gave me a few hints.

If you are interested, I have written: http://d.puremagic.com/issues/show_bug.cgi?id=3961 http://d.puremagic.com/issues/show_bug.cgi?id=4165 http://d.puremagic.com/issues/show_bug.cgi?id=4168 For the 4168 I can write some kind of patch too... Bye, bearophile
May 22 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:

 I don't think that's a bug. It should only worry about converting, not
 filtering out bad stuff. That's an orthogonal problem that the other
 function does well, and easily too.

It's not a bug, right. But saying that there are other functions orthogonal to it that solve this problem is not enough. There is a balance you have to adopt between having a so flexible language/stdlib that's sloppy and can lead to bugs, and to have as much orthogonal functions as possible that are fussy and can lead to opposite kinds of bugs. Very often if I have to convert strings to numbers I have leading or trailing spaces, often a leading newline. Converting such string to a number is not sloppiness because my experience shows me it can hardly cause bugs in general. The way to!() is currently designed forces me to remove the spaces often. This has caused a bug in one of my small script-like D programs. So if to!() will not strip spaces I'll have to define a stripping+conversion function in my dlibs2, and I'd like dlibs2 to be as small as possible. Bye, bearophile
May 22 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Robert Clipsham" <robert octarineparrot.com> wrote in message 
news:ht8m7t$2qua$1 digitalmars.com...
  - and should I ever feel there's a use for my apps outside of localhost 
 people will wonder why they don't support x86_64 natively (I believe this 
 will change after D2 from various comments from Walter).

Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem.
May 22 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2010 02:22 PM, retard wrote:
 Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:

 "Robert Clipsham"<robert octarineparrot.com>  wrote in message
 news:ht8m7t$2qua$1 digitalmars.com...
   - and should I ever feel there's a use for my apps outside of
   localhost
 people will wonder why they don't support x86_64 natively (I believe
 this will change after D2 from various comments from Walter).

Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem.

You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. In addition, x86 programs might be tuned for i586 or i386, forcing them to not utilize only 50% of the registers available. In the worst case they don't even use SSE at all! Some assembly experts here probably know how much slower x87 is when compared to SSE2+. Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at http://www.bestbuy.com/site/HP+-+Factory-Refurbished+Desktop+with+AMD +Athlon&%23153;+II+X2+Dual-Core+Processor/9880623.p? id=1218188306780&skuId=9880623 I already have 24 GB in my Core i7 system. I can't imagine how a 32-bit system would benefit modern users.

You both have a point. Clearly not a lot of individual applications really need more than 4GB (though unfortunately, many are pushing up for the wrong reasons), but then a whole category of them would greatly benefit of expanded RAM availability. Andrei
May 22 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 You both have a point. Clearly not a lot of individual applications 
 really need more than 4GB (though unfortunately, many are pushing up for 
 the wrong reasons), but then a whole category of them would greatly 
 benefit of expanded RAM availability.

I would phrase it as the greatly expanded address space. This offers a ton of benefits even if your app uses very little actual memory. For example, the stack size problem for threads pretty much goes away. Garbage collection can get much better. You can have much better hardware detection of wild pointers.
May 22 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Andrei Alexandrescu wrote:
 
 You both have a point. Clearly not a lot of individual applications
 really need more than 4GB (though unfortunately, many are pushing up for
 the wrong reasons), but then a whole category of them would greatly
 benefit of expanded RAM availability.
 
 Andrei

I've written at least one application (for my thesis) which ended up using all of my 4GB RAM and 6GB swap. Of course, that was at least partially because I was writing it in Haskell and hadn't taken its laziness into proper account. It was reading in the hundreds of files before it actually calculated anything since it didn't write anything to disk until it was done processing (which it naturally never did since it ran out of memory). Fixing it to write to disk after processing each file (thereby forcing it to actually process each file before reading in the next one) made it only take 3+ GB of RAM. But I was doing a lot of string processing, and it wasn't at all a typical app. Haskell was a poor match for the problem as it turns out, but given D's current lack of 64-bit support, it would have been too - though for very different reasons. Still, you work with what you've got. We'll get 64-bit support eventually. At least I can say that I wrote a program that used up all of my memory and swap doing something useful (or trying anyway). I don't think that many people can say that - especially when it was around 10GB total. That project definitely lead me to upgrade my RAM. But anywho, D is great. And for the most part, 64-bit isn't necessary. But it will be nice when we do get it. - Jonathan M Davis
May 24 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/22/2010 02:38 PM, retard wrote:
 Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote:

 On 5/22/10, retard<re tard.com.invalid>  wrote:
 On a 4 GB system you lose 600+ MB of memory when using a 32-bit
 operating system without PAE support.

You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries.

I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture.

It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version. Andrei
May 22 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 It all depends on what the largest payload is. One of my apps' largest 
 structures was a hash, which was almost twice as large in the 64-bit 
 version.

Some of that extra space is used by the pointers that are twice larger. The latest JavaVM are able to compress pointers in some situations, this can contain some info: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.8725 The main LLVM designer has studied that in C-like languages too, such ideas can be usable in D too: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html If you are interested in this, you can find more papers, with examples, benchmarks, etc. Bye, bearophile
May 22 2010
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:
 
 It all depends on what the largest payload is. One of my apps' largest 
 structures was a hash, which was almost twice as large in the 64-bit 
 version.

It's always possible to trim down the bits used for a pointer inside a data structure if the savings really matters. Doing so can create some really interesting bugs though.
May 22 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Andrei Alexandrescu Wrote:
 It all depends on what the largest payload is. One of my apps' largest 
 structures was a hash, which was almost twice as large in the 64-bit 
 version.

It's always possible to trim down the bits used for a pointer inside a data structure if the savings really matters. Doing so can create some really interesting bugs though.

The 'reduced' pointer memory model is a bad fit for D because: 1. D has to work with the corresponding C compiler, which does not support such a memory model. This kills it right there. 2. This will kill off a lot of the benefits of having a large address space that have nothing to do with allocating a lot of memory. I mentioned these in another post. 3. Having to support 2 memory models doubles the work. Two libraries, two test suite runs, more documentation, inevitable user confusion and mismatching, everyone shipping a library has to ship two, etc. If you must shrink the space required by pointers for a particular data structure, I suggest instead storing an offset instead of the pointer. Then, follow the indirection by adding said offset to a "base pointer".
May 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 1. D has to work with the corresponding C compiler, which does not support
such 
 a memory model. This kills it right there.

But the 'need' to do it can "resurrect" this feature from the dead. Sometimes you just need to do something, even such thing was not seen as "possible" in the past. The Oracle JavaVM is already using this optimization, but indeed it doesn't need to keep compatibility with the C compiler. This shows pointer compression in C and the like: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html Even if pointer compression can cause problems at the interface between C and D, there can be ways to decompress pointers when they are given to C libraries. So you can perform more efficient computations inside D code, and adapt (inflate) your pointers when they are needed for processing inside C code. There are things (like pointer compression, de-virtualization, dynamic decompilation, and so on) that future C-class languages can find useful to do that C compilers ten years ago didn't even think possible. Things are not set in stone, there's change too. Don't kill an idea just because it was kind of impossible (and probably kind of useless too) fifteen years ago. Bye, bearophile
May 23 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 1. D has to work with the corresponding C compiler, which does not support
 such a memory model. This kills it right there.

But the 'need' to do it can "resurrect" this feature from the dead. Sometimes you just need to do something, even such thing was not seen as "possible" in the past. The Oracle JavaVM is already using this optimization, but indeed it doesn't need to keep compatibility with the C compiler. This shows pointer compression in C and the like: http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html Even if pointer compression can cause problems at the interface between C and D, there can be ways to decompress pointers when they are given to C libraries. So you can perform more efficient computations inside D code, and adapt (inflate) your pointers when they are needed for processing inside C code. There are things (like pointer compression, de-virtualization, dynamic decompilation, and so on) that future C-class languages can find useful to do that C compilers ten years ago didn't even think possible. Things are not set in stone, there's change too. Don't kill an idea just because it was kind of impossible (and probably kind of useless too) fifteen years ago.

The paper describes an automatic way to do what I'd suggested previously - replacing the pointers with offsets from a base pointer. This is a lot like how the 'far' memory model in 16 bit code worked. Doing it in an automated way requires whole program analysis, something not entirely practical in a language designed to support separate compilation. On the other hand, D has plenty of abstraction abilities to make this doable by hand for selected data structures.
May 23 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Doing it in an automated way 
 requires whole program analysis, something not entirely practical in a
language 
 designed to support separate compilation.

Compiling programs of a dynamic language like Lua was seen as hopelessly inefficient. But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. So it's all in having a positive attitude toward technological problems: if the need to do something grows strong enough, people usually find a way to do it :-) Bye, bearophile
May 23 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 Do you have any citations of that?  All I can find on LuaJIT.org is
 comparisons of LuaJIT vs other versions of Lua.

On my site you can see a version of the SciMark2 benchmark (that contains several sub-benchmarks, naive scientific kernels, mostly) for D with numerous timings. LDC is able to compile it quite well. You can find a version of that code here: http://luajit.org/download/scimark.lua I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings against ldc, dmd. I have taken similar timings for another benchmark (nboby, from Shootout site). Bye, bearophile
May 25 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 So LuaJIT beats D on some or all of those benchmarks?

It's faster or close, D code compiled with dmd.
From that it looks like LuaJIT can't beat g++ for speed on any of the


I don't disagree with those results, in my original post I have said: >But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD.< This means comparing FP-heavy programs compiled with LUA jit 2.0a4 and DMD 2.x. I have not given hard timings because the point of my post was qualitative and not quantitative :-) Bye, bearophile
May 25 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 I don't think the D community is really interested in hearing something 
 positive about dynamically typed non-native languages. Traditionally 
 that's the best way to wreck your efficiency and it's tough to admit that 
 those languages are now better. The traditional native code way is to use 
 primitive compilers and brute force via inline asm.

If this were true, C and C++ would be dead languages. C++, for example, is often used in combination with Python. The C++ part is for the bits that need to be fast. BTW, even the best compilers fall far short of what an expert can do with assembler.
May 25 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 The Oracle JavaVM is already using this optimization, but indeed it doesn't
 need to keep compatibility with the C compiler. This shows pointer
 compression in C and the like: 
 http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html

Oh, I forgot to mention. Back in the 16 bit days, I invented something called a "handle pointer". http://www.digitalmars.com/ctg/handle-pointers.html It was a special pointer type that was dereferenced through a function call. The particular implementation of it was to enable to use bank-switched EMS memory as if it were regularly addressible memory. In D this would be better off making the special pointer types a user defined struct type. Compiler support isn't necessary.
May 23 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 In D this would be better off making the special pointer types a user defined 
 struct type. Compiler support isn't necessary.

Nice, thank you :-) I will try to implement this, I have already written something similar in D2. Bye, bearophile
May 23 2010
prev sibling parent Pelle <pelle.mansson gmail.com> writes:
On 05/23/2010 09:39 AM, Walter Bright wrote:
 Oh, I forgot to mention. Back in the 16 bit days, I invented something
 called a "handle pointer".

 http://www.digitalmars.com/ctg/handle-pointers.html

"You must be sure your program frees memory when it exits; otherwise, it will be unavailable to other programs until the machine is re-booted." Ha ha, oh wow. :)
May 23 2010
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 25, 2010 at 12:45 PM, Bill Baxter <wbaxter gmail.com> wrote:
 On Tue, May 25, 2010 at 12:11 PM, bearophile <bearophileHUGS lycos.com> w=

 Bill Baxter:
 Do you have any citations of that? =A0All I can find on LuaJIT.org is
 comparisons of LuaJIT vs other versions of Lua.

On my site you can see a version of the SciMark2 benchmark (that contain=


rous timings. LDC is able to compile it quite well.
 You can find a version of that code here:
 http://luajit.org/download/scimark.lua
 I have compiled the awesome LUA JIT (it's easy) on Linux, and found timi=


 I have taken similar timings for another benchmark (nboby, from Shootout=


 So LuaJIT beats D on some or all of those benchmarks? =A0I can't quite
 remember what your website URL is.
 But I did find this:
 http://shootout.alioth.debian.org/u64/benchmark.php?test=3Dall&lang=3Dlua=

 I was thinking LuaJIT would be too new and/or fringe for it to be on
 the Alioth shootout, but it's there.
 From that it looks like LuaJIT can't beat g++ for speed on any of the
 benchmarks. =A0You disagree with those results?

Nevermind. I realize you didn't say that LuaJIT was faster than g++, just faster than DMD. But that last part made it sound like you thought LuaJIT was on track to eventually outperform all compilers. As in the need for fast JIT is strong enough that eventually people will figure out how to make it faster than everything else out there. --bb
May 25 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Sorry for pulling out that, but I thought the claim "most apps" was a bit 
 overoptimistic. If D is The next gen language, it probably also should 
 solve the next generation of problems.

FWIW, I fully agree with the notion that D needs to fully support 64 bit compilation.
May 22 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 retard wrote:
 Sorry for pulling out that, but I thought the claim "most apps" was a bit
 overoptimistic. If D is The next gen language, it probably also should
 solve the next generation of problems.

compilation.

Is that still the next priority after finishing D2? Now that most of the more annoying bugs in DMD and Phobos have been fixed, lack of 64-bit support has become by far my number 1 complaint about D. I do bioinformatics research in D and overall I love it because it's about the only language that allows me to get prototypes up and running quickly and yet still have them execute efficiently. On the other hand, we have compute nodes at my university with 100+ _gigabytes_ of RAM that I can't use. Even the lack of libraries in D doesn't bother me much because I can roll my own and they end up having better APIs than would be possible in an older, cruftier, less featureful language. The only time I've ever seriously regretted using D as my language of choice is when I'm working with huge datasets and want access to all this memory and had to resort to kludges to cram my programs into the artificial limits of 32-bit address space.
May 22 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Is that still the next priority after finishing D2?

Yes. I think no support for 64 bits is a serious deficit.
May 22 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:
 dsimcha wrote:
 Is that still the next priority after finishing D2?

Yes. I think no support for 64 bits is a serious deficit.

I should amend that by saying that post D2 emphasis will be on addressing problems with the toolchain, of which 64 bit support is a big one. Language changes will be a very low priority. Other toolchain problems are things like shared libraries, installation, bugzilla bugs, etc.
May 22 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 I should amend that by saying that post D2 emphasis will be on addressing 
 problems with the toolchain, of which 64 bit support is a big one.
 
 Language changes will be a very low priority.
 
 Other toolchain problems are things like shared libraries, installation, 
 bugzilla bugs, etc.

Things are not as simple as you say: among the Bugzilla bugs there is more than just pure implementation bugs, there are design bugs too, and they are essentially "language changes". I can list you many of them. Bye, bearophile
May 22 2010
parent Bane <branimir.milosavljevic gmail.com> writes:
bearophile Wrote:

 Walter Bright:
 
 I should amend that by saying that post D2 emphasis will be on addressing 
 problems with the toolchain, of which 64 bit support is a big one.
 
 Language changes will be a very low priority.
 
 Other toolchain problems are things like shared libraries, installation, 
 bugzilla bugs, etc.

Things are not as simple as you say: among the Bugzilla bugs there is more than just pure implementation bugs, there are design bugs too, and they are essentially "language changes". I can list you many of them. Bye, bearophile

I just hope D won't try to become Jack of All Trades, ad least not to early :D
May 23 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.

Installation? What kind of problems are those? -- Bruno Medeiros - Software Engineer
May 24 2010
next sibling parent reply dsimcha <dsimcha gmail.com> writes:
== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.
May 24 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:
 On Windows there's been some talk of making an installer.  Personally, I think
 this should be a very low priority.  Unpacking a zip file may not be the most
 friendly installation method for someone who's completely computer illiterate,
but
 we're talking about programmers here.  Even novice ones should be able to
figure
 out how to unpack a zip file into a reasonable directory.

Some cases: - A person that is expert of Linux but is ignorant of Windows, and has to install it on Windows. This person can solve the install problem, but can enjoy some help. - An university student of the first year that wants to try D. Such person knows basic programming, data structures, and some OOP, but doesn't know much else about computers, OS, GUI, etc. A very easy installer can help. Expert C++ programmers can be more interested in keep using C++, while young people that don't know C++ yet can be interested in learning D. Such kind of people must be taken into account by D designers because they are the future. - A person that at work has just 10 free minutes, and wants to install and take a quick look at D language. Even reading the pages that explain how to install D can take time better spent in other ways. - A person that is kind of interested about some kind of language different from Java, but is not sure what to try, D, Scala, or some other language. So for such person it's good to lower the entry costs of D usage as much as possible. If D catches the interest of such person, this person can later spend even months learning D. So I'd the digitalmars (or other site) to keep the zip version, but I think a very easy and fast installer can be useful (For the Windows version of ShedSkin we use a similar simple installer based on WinRar). Even a few clicks installer can be a lot for the casual person that is not sure about trying D. For such persons the codepad and ideone sites can offer a way to try to compile and run D snippets online. Even faster than an installer, for people that just want to try the language quickly it can be useful a single-file zero-install download-and-go thing (this doesn't replace the installer and the zip, this can be a third download option). This thing when clicked on can show a basic editor window based on Scintilla. Bye, bearophile
May 24 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Leandro Lucarella (llucax gmail.com)'s article
 dsimcha, el 24 de mayo a las 13:05 me escribiste:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source.

ideal either. In Linux you have to make the binaries executables. The only straighforward option for Linux is the .deb, but it's only straightforward for Ubuntu 32-bits, anything else needs some (non-trivial) work.

If packaging nightmares like this don't explain why Linux hasn't succeeded on the desktop, then nothing will.
May 24 2010
parent reply Justin Johansson <no spam.com> writes:
retard wrote:
 The files inside the .zip won't run because one particular Mr. Bright 
 doesn't set the +x flag on. It's not a fault of Linux if he is using 
 retarded Windows version of the zip packager. It's easy to fix, he just 
 doesn't care. The zip works just fine even on a 64-bit system if the 32-
 bit libraries have been installed.

Hey retard, while I enjoy reading a lot of the controversy that you like to create on this NG, sorry, on this occasion I think you are being somewhat unfair towards one particular person here. My understanding is that .zip files are traditionally a DOS (originally PKZIP) then come Windows thing then come Unix available. http://en.wikipedia.org/wiki/ZIP_%28file_format%29 Being so, .zip files do not inherently/traditionally support recording Unix file permissions such as +x within the archive. If such facilities exist today in Unix .zip utilities (and I am unaware of the same) these would have to be extensions over and above what .zip files are commonly understood to support given the DOS/PKZIP history of this file format. Recording of Unix file permissions in archives is traditionally achieved with .tar files (and compressed variants) as I am sure you are well aware. When downloading archive from the net, I look for .zip files if wanting to install on Windows and .tar or .tar.gz if wanting to install on Unixes. I imagine that most Unix-aware folks would do the same. In this instance I think you should be asking that archives be available in both .tar and .zip variants for the respective platforms and not accusing a certain somebody of being delinquent in not setting a +x flag on a file in a .zip file. Cheers Justin Johansson
May 25 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-25 20:00:44 -0400, retard <re tard.com.invalid> said:

 Because of the non-free license he is the only person who
 can fix this -- I can't officially redistribute a fixed .zip package or
 any other repackaged dmd.

Well, there is a way: create something that automatically downloads, extract, and set the executable bits on the proper file. This is exactly what D for Xcode does. If anyone is interested, I've put the scripts it uses for that here: <http://michelf.com/docs/dmd-install/> I expect they'll work fine on Linux, but you may want to change the DX_INSTALL_DIR variable in the dmd1download.sh and dmd2download.sh files (D for Xcode installs in /Library/Compilers). Feel free to adapt and redistribute the scripts as you like; they're available under GPL 2 or later, same as the rest of D for Xcode. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
May 26 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 On Windows there's been some talk of making an installer.  Personally, I think
 this should be a very low priority.  Unpacking a zip file may not be the most
 friendly installation method for someone who's completely computer illiterate,
but
 we're talking about programmers here.  Even novice ones should be able to
figure
 out how to unpack a zip file into a reasonable directory.

There is an installer for Windows. See http://www.digitalmars.com/d/download.html
May 24 2010
prev sibling next sibling parent sybrandy <sybrandy gmail.com> writes:
On 05/24/2010 09:05 AM, dsimcha wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.

Actually, if you use InstallJammer, creating an installer could/should be very easy. I used it at work for a project and it will allow you to create an installer for a number of different platforms and a plain-old .zip/.tar.gz. Though, IMHO, I really like the way it's currently distributed. I've grown to appreciate the simple "unzip to install"/"delete directory to uninstall" way of doing things a lot. I just really hate the dependency that damn near everything has on the Windows registry. Casey
May 24 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/05/2010 14:05, dsimcha wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.

Ah, ok, I've only used DMD windows so far, thus I wasn't aware of those problems. (in windows its fine) And I think the zip file installation is fine versus using an installer, in fact I even prefer it. -- Bruno Medeiros - Software Engineer
May 26 2010
parent reply Don <nospam nospam.com> writes:
Bruno Medeiros wrote:
 On 24/05/2010 14:05, dsimcha wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, 
 installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.

Ah, ok, I've only used DMD windows so far, thus I wasn't aware of those problems. (in windows its fine) And I think the zip file installation is fine versus using an installer, in fact I even prefer it.

sure what they're going to do, and what problems they're about to cause.
May 26 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/26/2010 05:07 AM, Don wrote:
 Bruno Medeiros wrote:
 On 24/05/2010 14:05, dsimcha wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries,
 installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.

Ah, ok, I've only used DMD windows so far, thus I wasn't aware of those problems. (in windows its fine) And I think the zip file installation is fine versus using an installer, in fact I even prefer it.

sure what they're going to do, and what problems they're about to cause.

Hmmm, that's quite a change of attitude since my Windows days. I remember I wouldn't look twice at an application that didn't come with an installer. Andrei
May 26 2010
next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 26/05/2010 14:23, Andrei Alexandrescu wrote:
 On 05/26/2010 05:07 AM, Don wrote:
 Bruno Medeiros wrote:
 On 24/05/2010 14:05, dsimcha wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries,
 installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source. On Windows there's been some talk of making an installer. Personally, I think this should be a very low priority. Unpacking a zip file may not be the most friendly installation method for someone who's completely computer illiterate, but we're talking about programmers here. Even novice ones should be able to figure out how to unpack a zip file into a reasonable directory.

Ah, ok, I've only used DMD windows so far, thus I wasn't aware of those problems. (in windows its fine) And I think the zip file installation is fine versus using an installer, in fact I even prefer it.

sure what they're going to do, and what problems they're about to cause.

Hmmm, that's quite a change of attitude since my Windows days. I remember I wouldn't look twice at an application that didn't come with an installer. Andrei

I may not agree entirely with Don, because I my preference for zip files was referring to the DMD case only, its not a general preference, it depends on the application. I would say an installer makes sense when the application needs to do other OS tasks other than just extracting its files onto a folder, such as creating Program menu shortcuts, setting up file associations, configuring environment variables or OS services. Also if the application stores data or configuration in user home folders, or in the registry. Any of these reasons most likely merit an installer (and uninstaller). -- Bruno Medeiros - Software Engineer
May 26 2010
prev sibling parent sybrandy <sybrandy gmail.com> writes:
 And I think the zip file installation is fine versus using an
 installer, in fact I even prefer it.

sure what they're going to do, and what problems they're about to cause.

Hmmm, that's quite a change of attitude since my Windows days. I remember I wouldn't look twice at an application that didn't come with an installer. Andrei

I too prefer the zip file approach. I guess what turned me to it was simplicity of installation (especially if you have limited rights), portability across machines, ease of removal, and it doesn't bloat your registry which, AFAIK, will still slow your machine down since it's read every time you launch a program. Though, if you package the compiler as a portable app (PortableApps.com), that would be cool too. You get the benefits of an installer and the installation is still unobtrusive. Casey
May 26 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2010 06:21 AM, Bruno Medeiros wrote:
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.

Installation? What kind of problems are those?

E.g. I can't install the .deb file on my 64-bit Linux. Andrei
May 24 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.
May 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Just tried again, same error message: Error: Wrong architecture 'i386' Let me know how I can help. Andrei
May 24 2010
next sibling parent reply eles <eles eles.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
article
 On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Error: Wrong architecture 'i386' Let me know how I can help. Andrei

just type sudo dpkg -i --force-architecture dmd_X.XXX-0_i386.deb where dmd_X.XXX-0_i386.deb is the name of the .deb file
May 24 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2010 07:16 PM, eles wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Error: Wrong architecture 'i386' Let me know how I can help. Andrei

just type sudo dpkg -i --force-architecture dmd_X.XXX-0_i386.deb where dmd_X.XXX-0_i386.deb is the name of the .deb file

Thanks. Is there a way to make that directive automatic inside the .deb file? Andrei
May 25 2010
prev sibling next sibling parent eles <eles eles.com> writes:
installation instructions for linux (incl. 32-bit or 64 bit) are here:

http://www.digitalmars.com/d/2.0/dmd-linux.html

however, i would like to have it ported on 64-bit

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
article
 On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Error: Wrong architecture 'i386' Let me know how I can help. Andrei

May 24 2010
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrei Alexandrescu wrote:

 On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Just tried again, same error message: Error: Wrong architecture 'i386' Let me know how I can help. Andrei

DDebber will build packages for i386 and AMD64. The main difference is that the AMD64 package will depended on the required ia32 libraries which will not be pulled in with -force-architecture. Just say'n Ok, it still isn't that simple because if you don't have the required packages then dmd will be left unconfigured since dpkg will not install dependencies. # apt-get -f should fix this.
May 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/24/2010 08:03 PM, Jesse Phillips wrote:
 Andrei Alexandrescu wrote:

 On 05/24/2010 05:20 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Just tried again, same error message: Error: Wrong architecture 'i386' Let me know how I can help. Andrei

DDebber will build packages for i386 and AMD64. The main difference is that the AMD64 package will depended on the required ia32 libraries which will not be pulled in with -force-architecture. Just say'n Ok, it still isn't that simple because if you don't have the required packages then dmd will be left unconfigured since dpkg will not install dependencies. # apt-get -f should fix this.

I think at the end of the day we need a link that people can click on and that's that. How can we make that work? Do we need a 64-bit .deb, or is it possible to automatically instruct the package manager (in the case of Ubuntu gdebi) to install it with dependencies and all? Andrei
May 25 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrei Alexandrescu wrote:

 I think at the end of the day we need a link that people can click on 
 and that's that. How can we make that work? Do we need a 64-bit .deb, or 
 is it possible to automatically instruct the package manager (in the 
 case of Ubuntu gdebi) to install it with dependencies and all?

 Andrei

Ubuntu (and family) is probably the only distro that you can expect gdebi to be installed on. And the only way to have it install the proper packages is to install a package with the required dependencies e.g. an AMD64 package. To really make many Linux users happy would be to provide a repository. Even Google doesn't provide a one-click install for their programs (I bring them up because they try very hard to be user friendly).
May 25 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/25/2010 09:22 AM, Jesse Phillips wrote:
 Andrei Alexandrescu wrote:

 I think at the end of the day we need a link that people can click on
 and that's that. How can we make that work? Do we need a 64-bit .deb, or
 is it possible to automatically instruct the package manager (in the
 case of Ubuntu gdebi) to install it with dependencies and all?

 Andrei

Ubuntu (and family) is probably the only distro that you can expect gdebi to be installed on. And the only way to have it install the proper packages is to install a package with the required dependencies e.g. an AMD64 package.

OK, thank you.
 To really make many Linux users happy would be to provide a repository.
 Even Google doesn't provide a one-click install for their programs (I
 bring them up because they try very hard to be user friendly).

Good point. Who here knows what steps need be taken to create a repository? Andrei
May 25 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrei Alexandrescu wrote:

 Good point. Who here knows what steps need be taken to create a repository?

 Andrei

I haven't tried myself, someone has for the Tango side. It doesn't look to be too difficult: http://www.debian-administration.org/articles/286 If you would like I could try to come up with a configuration file this week/weekend
May 25 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 05/25/2010 10:38 PM, Jesse Phillips wrote:
 Andrei Alexandrescu wrote:

 Good point. Who here knows what steps need be taken to create a repository?

 Andrei

I haven't tried myself, someone has for the Tango side. It doesn't look to be too difficult: http://www.debian-administration.org/articles/286 If you would like I could try to come up with a configuration file this week/weekend

That would be awesome, thanks! Walter, it would be also great if you could contact the person who did the .deb file to also kindly ask for a 64-bit .deb. Thanks all, Andrei
May 26 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 26 de mayo a las 08:19 me escribiste:
 On 05/25/2010 10:38 PM, Jesse Phillips wrote:
Andrei Alexandrescu wrote:

Good point. Who here knows what steps need be taken to create a repository?

Andrei

I haven't tried myself, someone has for the Tango side. It doesn't look to be too difficult: http://www.debian-administration.org/articles/286 If you would like I could try to come up with a configuration file this week/weekend

That would be awesome, thanks! Walter, it would be also great if you could contact the person who did the .deb file to also kindly ask for a 64-bit .deb.

As Jesse Phillips said: DDebber will build packages for i386 and AMD64. The main difference is that the AMD64 package will depended on the required ia32 libraries which will not be pulled in with -force-architecture. http://dsource.org/projects/ddebber "The goal is to give this program to Walter so he is able to build .deb packages and host them on digitalmars.com" Maybe he can take a look at that. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Ever tried? Ever failed? - Try again! Fail better!
May 26 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el 25 de mayo a las 14:22 me escribiste:
 Andrei Alexandrescu wrote:
 
 I think at the end of the day we need a link that people can click on 
 and that's that. How can we make that work? Do we need a 64-bit .deb, or 
 is it possible to automatically instruct the package manager (in the 
 case of Ubuntu gdebi) to install it with dependencies and all?

 Andrei

Ubuntu (and family) is probably the only distro that you can expect gdebi to be installed on. And the only way to have it install the proper packages is to install a package with the required dependencies e.g. an AMD64 package. To really make many Linux users happy would be to provide a repository. Even Google doesn't provide a one-click install for their programs (I bring them up because they try very hard to be user friendly).

In Ubuntu is extremely easy, just create a PPA[1]. For Debian is not that east but is not that hard either and I think providing a (well done) .deb is acceptable. In Debian (or even Ubuntu) it could be possible to pull the package "upstream" (to the non-free repositories in Debian and to the multiverse repositories in Ubuntu, I think). *That* would be the ideal for a Debian/Ubuntu user. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Yo soy Peperino, mártir latino, venid al asado pero traed el vino. -- Peperino Pómoro
May 25 2010
prev sibling parent retard <re tard.com.invalid> writes:
Tue, 25 May 2010 13:38:00 -0300, Leandro Lucarella wrote:

 Justin Johansson, el 25 de mayo a las 22:42 me escribiste:
 retard wrote:
The files inside the .zip won't run because one particular Mr. Bright
doesn't set the +x flag on. It's not a fault of Linux if he is using
retarded Windows version of the zip packager. It's easy to fix, he
just doesn't care. The zip works just fine even on a 64-bit system if
the 32-
bit libraries have been installed.

Hey retard, while I enjoy reading a lot of the controversy that you like to create on this NG, sorry, on this occasion I think you are being somewhat unfair towards one particular person here. My understanding is that .zip files are traditionally a DOS (originally PKZIP) then come Windows thing then come Unix available. http://en.wikipedia.org/wiki/ZIP_%28file_format%29 Being so, .zip files do not inherently/traditionally support recording Unix file permissions such as +x within the archive. If such facilities exist today in Unix .zip utilities (and I am unaware of the same) these would have to be extensions over and above what .zip files are commonly understood to support given the DOS/PKZIP history of this file format.

Yes, it does: $ touch bin $ chmod a+x bin $ ls -l bin -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin $ zip bin.zip bin adding: bin (stored 0%) $ rm bin $ ls -l bin ls: cannot access bin: No such file or directory $ unzip bin.zip Archive: bin.zip extracting: bin $ ls -l bin -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin
 Recording of Unix file permissions in archives is traditionally
 achieved with .tar files (and compressed variants) as I am sure you are
 well aware.
 
 When downloading archive from the net, I look for .zip files if wanting
 to install on Windows and .tar or .tar.gz if wanting to install on
 Unixes.  I imagine that most Unix-aware folks would do the same.

That makes no sense. Even when history is interesting, now both zip and tar works just fine in both Unix and Windows, so retard is right, the zip being broken is entirely Walter's fault. And I think he knows it, that's why he said he wanted to give some love to the toolchain and distribution issues when D2 is finished. I don't think either attacking Walter gratuitously or defending him blindly is a good for D.

I wasn't attacking anyone, just pointing out the cause. Yes, it's because he uses a windows version of zip so it's his decision to make it harder for *nix users. Because of the non-free license he is the only person who can fix this -- I can't officially redistribute a fixed .zip package or any other repackaged dmd. And Justin is also right, I wouldn't mind having a .tar.gz package with the executable flags correctly set (and without win32 executables). Just repacking the distribution on a *nix computer would be enough to fix it and would probably be the easiest solution if windows zip archivers don't support setting the flag.
May 25 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Justin Johansson, el 25 de mayo a las 22:42 me escribiste:
 retard wrote:
The files inside the .zip won't run because one particular Mr.
Bright doesn't set the +x flag on. It's not a fault of Linux if he
is using retarded Windows version of the zip packager. It's easy
to fix, he just doesn't care. The zip works just fine even on a
64-bit system if the 32-
bit libraries have been installed.

Hey retard, while I enjoy reading a lot of the controversy that you like to create on this NG, sorry, on this occasion I think you are being somewhat unfair towards one particular person here. My understanding is that .zip files are traditionally a DOS (originally PKZIP) then come Windows thing then come Unix available. http://en.wikipedia.org/wiki/ZIP_%28file_format%29 Being so, .zip files do not inherently/traditionally support recording Unix file permissions such as +x within the archive. If such facilities exist today in Unix .zip utilities (and I am unaware of the same) these would have to be extensions over and above what .zip files are commonly understood to support given the DOS/PKZIP history of this file format.

Yes, it does: $ touch bin $ chmod a+x bin $ ls -l bin -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin $ zip bin.zip bin adding: bin (stored 0%) $ rm bin $ ls -l bin ls: cannot access bin: No such file or directory $ unzip bin.zip Archive: bin.zip extracting: bin $ ls -l bin -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin
 Recording of Unix file permissions in archives is traditionally
 achieved with .tar files (and compressed variants) as I am sure you
 are well aware.
 
 When downloading archive from the net, I look for .zip files if
 wanting to install on Windows and .tar or .tar.gz if wanting to
 install on Unixes.  I imagine that most Unix-aware folks would do
 the same.

That makes no sense. Even when history is interesting, now both zip and tar works just fine in both Unix and Windows, so retard is right, the zip being broken is entirely Walter's fault. And I think he knows it, that's why he said he wanted to give some love to the toolchain and distribution issues when D2 is finished. I don't think either attacking Walter gratuitously or defending him blindly is a good for D. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- He cometido pecados, he hecho el mal, he sido víctima de la envidia, el egoísmo, la ambición, la mentira y la frivolidad, pero siempre he sido un padre argentino que quiere que su hijo triunfe en la vida. -- Ricardo Vaporeso
May 25 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 25 de mayo a las 08:27 me escribiste:
 On 05/24/2010 07:16 PM, eles wrote:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
article
On 05/24/2010 05:20 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
E.g. I can't install the .deb file on my 64-bit Linux.

I think the current .deb files can be.

Error: Wrong architecture 'i386' Let me know how I can help. Andrei

just type sudo dpkg -i --force-architecture dmd_X.XXX-0_i386.deb where dmd_X.XXX-0_i386.deb is the name of the .deb file

Thanks. Is there a way to make that directive automatic inside the .deb file?

No, that's a broken deb file. The "right thing to do" is make 2 packages, one for i386 and one for amd64. The amd64 packages should depend on the necessary 32-bit libraries like ia32-libs. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Every day 21 new born babies will be given to the wrong parents
May 25 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 In my case the wisdom teeth didn't really fit in my mouth and harmed the 
 occlusion. The doctors first tried to fix it with braces, but the growing 
 wisdow tooth pushed it so hard that the first iteration of braces broke. 
 After they removed the wisdom teeth, the treatment has again improved the 
 occlusion to its previous pre wisdom teeth state.

There can be good reasons to remove wisdom teeth. In my case, the dentist did not have a good reason, and in Nick's case the first clearly did not, either. I've also seen dentists that do astonishingly good work. Just be careful. They're your teeth, not the dentist's, and you're the one who has to live with the results. There's no going back from having one pulled. For me, this all went back to when I was a kid my dad told me a story about a colleague of his with bad teeth. He had a lot of trouble with them, and his dentist eventually convinced him to have them pulled and replaced with dentures. My father said he sure was sorry, because no matter the trouble he had with his teeth, they were a heluva lot better than dentures.
May 22 2010
parent BCS <none anon.com> writes:
Hello Walter,

 They're your teeth, not the dentist's,

But only as long as they are in your mouth. Once they get pulled they are a bio-hazard and you can't have it back. Or so says some dentists. : -- ... <IXOYE><
May 23 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
dsimcha, el 24 de mayo a las 13:05 me escribiste:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries, installation,
 bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source.

BTW, distributing a huge .zip with the binaries for all platforms is not ideal either. In Linux you have to make the binaries executables. The only straighforward option for Linux is the .deb, but it's only straightforward for Ubuntu 32-bits, anything else needs some (non-trivial) work. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- I would love to fix this world but I'm so lazy... so lazy...
May 24 2010
prev sibling parent retard <re tard.com.invalid> writes:
Mon, 24 May 2010 17:45:01 +0000, dsimcha wrote:

 == Quote from Leandro Lucarella (llucax gmail.com)'s article
 dsimcha, el 24 de mayo a las 13:05 me escribiste:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s
 article
 On 23/05/2010 01:45, Walter Bright wrote:
 Walter Bright wrote:

 Other toolchain problems are things like shared libraries,
 installation, bugzilla bugs, etc.


On Linux, DMD can be a PITA to install if you're using an ancient distribution due to glibc being a different version than what DMD expects. I use such a machine and the only way to get DMD to work is to compile from source.

not ideal either. In Linux you have to make the binaries executables. The only straighforward option for Linux is the .deb, but it's only straightforward for Ubuntu 32-bits, anything else needs some (non-trivial) work.

If packaging nightmares like this don't explain why Linux hasn't succeeded on the desktop, then nothing will.

The files inside the .zip won't run because one particular Mr. Bright doesn't set the +x flag on. It's not a fault of Linux if he is using retarded Windows version of the zip packager. It's easy to fix, he just doesn't care. The zip works just fine even on a 64-bit system if the 32- bit libraries have been installed. The Microsoft installer stuff doesn't work well either. Try running 64- bit installers on a 32-bit Windows system or the latest .NET expecting .msi files on Windows 95/98/ME or Windows NT4/2000.. now how does it handle package dependencies - the answer is it doesn't. A 32-bit .deb works in most (if not all) 32-bit Debian derivatives unless the package is expecting some Ubuntu related configuration. Your solution seems to be: "because it's too complex to build packages for every distro, don't provide anything". Yay, nothing works.
May 25 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:

 "Robert Clipsham" <robert octarineparrot.com> wrote in message
 news:ht8m7t$2qua$1 digitalmars.com...
  - and should I ever feel there's a use for my apps outside of
  localhost
 people will wonder why they don't support x86_64 natively (I believe
 this will change after D2 from various comments from Walter).

Most apps don't need native x86_64. Only things that really push the limits of CPU/memory utilization need it, which, aside from bloatware (which admittedly is at epidemic levels lately), is really only a minority of apps. For the rest, if it already runs fine on 32-bit, then the same exec on a 64-bit machine is only going to run better anyway, and if is already ran fine before, then there's no problem.

You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature. On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating system without PAE support. In addition, x86 programs might be tuned for i586 or i386, forcing them to not utilize only 50% of the registers available. In the worst case they don't even use SSE at all! Some assembly experts here probably know how much slower x87 is when compared to SSE2+. Guess how much a 64-bit system with 4 GB of RAM costs these days - a quick search gave me the number $379 at http://www.bestbuy.com/site/HP+-+Factory-Refurbished+Desktop+with+AMD +Athlon&%23153;+II+X2+Dual-Core+Processor/9880623.p? id=1218188306780&skuId=9880623 I already have 24 GB in my Core i7 system. I can't imagine how a 32-bit system would benefit modern users.
May 22 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:ht9atu$rop$1 digitalmars.com...
 Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:
 Most apps don't need native x86_64. Only things that really push the
 limits of CPU/memory utilization need it, which, aside from bloatware
 (which admittedly is at epidemic levels lately), is really only a
 minority of apps. For the rest, if it already runs fine on 32-bit, then
 the same exec on a 64-bit machine is only going to run better anyway,
 and if is already ran fine before, then there's no problem.

You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature.

I never said it was. All I said was that most apps don't need native 64-bit versions. Don't go pulling out strawmen.
 On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating
 system without PAE support. In addition, x86 programs might be tuned for
 i586 or i386, forcing them to not utilize only 50% of the registers
 available. In the worst case they don't even use SSE at all! Some
 assembly experts here probably know how much slower x87 is when compared
 to SSE2+.

Take a 32-bit executable optimized for i386 or i586, that runs acceptably well on a 32-bit system (say, a P4, or even a P4-era Celeron). Take that same binary, put it on a 64-bit system (say, your Core i7). It will run *at least* at fast, most likely faster. Could it be made even faster than that with a 64-bit-native recompile? Sure. But if the 32-bit binary already ran acceptably well on the 32-bit system, and even faster on the 64-bit system, then who gives a shit?
 Guess how much a 64-bit system with 4 GB of RAM costs these days - a
 quick search gave me the number $379 at

Guess how much more that costs me than using my 32-bit system that already does everything I need it to do? $379. Keep in mind, I live in a normal place, not some fantasy land like California where a million dollars is pocket change. If I had hundreds of dollars to toss around, I'd get my bad tooth pulled. At least then I'd be getting a non-trivial benefit.
May 22 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 If I had hundreds of dollars to toss around, I'd get my bad 
 tooth pulled.

Your original teeth are always better than the replacements, no matter how bad they are, unless they are causing you great pain. Don't let some greedy dentist convince you otherwise. Pulling a tooth can also destabilize its neighbors. 30 years ago, the dentist told me I needed my wisdom teeth pulled. I refused, and I still have them, and they're fine. Another thing - dentistry advances rapidly, along with their ability to save teeth. I don't know your situation, but be reluctant and skeptical about pulling teeth. Get a second opinion.
May 22 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:ht9ka3$1dqd$1 digitalmars.com...
 Nick Sabalausky wrote:
 If I had hundreds of dollars to toss around, I'd get my bad tooth pulled.

Your original teeth are always better than the replacements, no matter how bad they are, unless they are causing you great pain. Don't let some greedy dentist convince you otherwise. Pulling a tooth can also destabilize its neighbors. 30 years ago, the dentist told me I needed my wisdom teeth pulled. I refused, and I still have them, and they're fine. Another thing - dentistry advances rapidly, along with their ability to save teeth. I don't know your situation, but be reluctant and skeptical about pulling teeth. Get a second opinion.

Good to know. In my case though, it's a wisdom tooth and, I would say that it's chipped, but it would be more accurate to say that half of it is gone, and what remains has two sharp edges (Kinda like a two-pronged fork pointing into the gums). It's not really causing much pain, but I do conciously try to chew on the other side (unnatural for me) because if I were to bite down on something the wrong way, then it would hurt like hell. Plus two dentists have already said it should go. The first one did wanted me to get all the wisdoms out. But the second one just said the one needed it and that the other three didn't matter either way. I know I didn't actually need to say any of that, but, well, HIPAA be damnned ;)
May 22 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 Good to know. In my case though, it's a wisdom tooth and, I would say that 
 it's chipped, but it would be more accurate to say that half of it is gone, 
 and what remains has two sharp edges (Kinda like a two-pronged fork pointing 
 into the gums). It's not really causing much pain, but I do conciously try 
 to chew on the other side (unnatural for me) because if I were to bite down 
 on something the wrong way, then it would hurt like hell. Plus two dentists 
 have already said it should go.

My dentist told me they can now grind off the rotten top of a tooth and add a new one attached to the original root. He told me that because one of my molars has a growing crack in it. It's not a crisis now, but it will be. Wisdom teeth can be hard to work on because they're so far back. Dentists have a tendency to just pull them out rather than try to save them. I'd ask your dentist if he can just grind off the sharp edges, add a bit of epoxy (they use epoxy now to fill cavities), and keep the root in place. Or maybe do a crown.
 The first one did wanted me to get all the
 wisdoms out. But the second one just said the one needed it and that the
 other three didn't matter either way.

Never go back to that first one. I'd question the judgment of the 2nd in saying it "didn't matter" if they were pulled. I switched dentists when that one greedy jerk wanted to pull my wisdom teeth, and found one that shared my views on preserving the natural teeth as much as possible.
May 22 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:ht9qvs$1po0$1 digitalmars.com...
 Nick Sabalausky wrote:
 Good to know. In my case though, it's a wisdom tooth and, I would say 
 that it's chipped, but it would be more accurate to say that half of it 
 is gone, and what remains has two sharp edges (Kinda like a two-pronged 
 fork pointing into the gums). It's not really causing much pain, but I do 
 conciously try to chew on the other side (unnatural for me) because if I 
 were to bite down on something the wrong way, then it would hurt like 
 hell. Plus two dentists have already said it should go.

My dentist told me they can now grind off the rotten top of a tooth and add a new one attached to the original root. He told me that because one of my molars has a growing crack in it. It's not a crisis now, but it will be. I'd ask your dentist if he can just grind off the sharp edges, add a bit of epoxy (they use epoxy now to fill cavities), and keep the root in place.

Good stuff to know.
 Wisdom teeth can be hard to work on because they're so far back. Dentists 
 have a tendency to just pull them out rather than try to save them.

Yea, not surprised.
 Or maybe do a crown.

The second one did say something like "It wouldn't be worth it to do a crown". Seemed to be implying that would be overkill. But I may check into that and the other stuff though. I checked into the dental surgeons he recommended (apparently, ordinary dentists don't do teeth pulling, or at least not wisdom teeth, or at least not busted up wisdom teeth...I dunno), and it was around $700 at either place. That's including being put under, but I'm an absolute baby about these sorts of things: if I'm going to have a tooth pulled, I'm sure as hell not gonna be awake for it ;)
 The first one did wanted me to get all the
 wisdoms out. But the second one just said the one needed it and that the
 other three didn't matter either way.

Never go back to that first one.

Yea, never planned to. For various reasons actually. That one was actually the instructor of a student dentist that was working on me (because they're cheap and I'm poor ;) ). What she was telling me did seem slightly suspicious and I was convinced right then and there I needed a second opinion. Another thing though, is that this was part of a hospital system we have in Cleveland called University Hospitals, and I've had MAJOR problems with other offices in that system since then. I've always considered the other major system, Cleveland Clinic, to have absolute piss-poor management, but University Hospitals makes Cleveland Clinic look downright competent by comparison.
 I'd question the judgment of the 2nd in saying it "didn't matter" if they 
 were pulled.

Well, his exact words were more like "It's up to you if you want them pulled." Same thing, I suppose.
 I switched dentists when that one greedy jerk wanted to pull my wisdom 
 teeth, and found one that shared my views on preserving the natural teeth 
 as much as possible.

Yea, it can be difficult to find good people.
May 22 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 The second one did say something like "It wouldn't be worth it to do a 
 crown". Seemed to be implying that would be overkill. But I may check into 
 that and the other stuff though. I checked into the dental surgeons he 
 recommended (apparently, ordinary dentists don't do teeth pulling, or at 
 least not wisdom teeth, or at least not busted up wisdom teeth...I dunno), 
 and it was around $700 at either place. That's including being put under, 
 but I'm an absolute baby about these sorts of things: if I'm going to have a 
 tooth pulled, I'm sure as hell not gonna be awake for it ;)

Shopping around for a good price is a good idea, asking for a discount also can give good results. That said, the health of one's mouth is a canary for the rest of the body. Good teeth also are a major quality of life issue. It's not a good place to cut corners. I once knew a woman who came here from Russia. She had bad teeth, and a cringe-worthy smile. She had no money, but saved every dime until she could afford the dentist. The results were amazing. It completely transformed her face in a good way, and I think it turned around her life for the better.
May 22 2010
prev sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 5/24/10, bearophile <bearophileHUGS lycos.com> wrote:
 Even faster than an installer, for people that just want to try the language
 quickly it can be useful a single-file zero-install download-and-go thing

That's exactly what the zip is. Unzip it and go. To uninstall, just delete the folder. On Linux, you could argue that you have to chmod +x it (not strictly true, but granted). Don't even have that on Windows.
May 24 2010
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, May 23, 2010 at 1:14 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Walter Bright:

 Compiling programs of a dynamic language like Lua was seen as hopelessly
inefficient. But today programs running on the the Lua JIT are often faster
than equivalent FP-heavy D programs compiled with DMD.

Do you have any citations of that? All I can find on LuaJIT.org is comparisons of LuaJIT vs other versions of Lua. --bb
May 25 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 5/22/10, retard <re tard.com.invalid> wrote:
 On a 4 GB system you lose 600+ MB of memory when using a 32-bit operating
 system without PAE support.

You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries.
May 22 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote:

 On 5/22/10, retard <re tard.com.invalid> wrote:
 On a 4 GB system you lose 600+ MB of memory when using a 32-bit
 operating system without PAE support.

You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries.

I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture.
May 22 2010
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 25, 2010 at 12:11 PM, bearophile <bearophileHUGS lycos.com> wro=
te:
 Bill Baxter:
 Do you have any citations of that? =A0All I can find on LuaJIT.org is
 comparisons of LuaJIT vs other versions of Lua.

On my site you can see a version of the SciMark2 benchmark (that contains=

ous timings. LDC is able to compile it quite well.
 You can find a version of that code here:
 http://luajit.org/download/scimark.lua
 I have compiled the awesome LUA JIT (it's easy) on Linux, and found timin=

 I have taken similar timings for another benchmark (nboby, from Shootout =

So LuaJIT beats D on some or all of those benchmarks? I can't quite remember what your website URL is. But I did find this: http://shootout.alioth.debian.org/u64/benchmark.php?test=3Dall&lang=3Dluaji= t&lang2=3Dgpp I was thinking LuaJIT would be too new and/or fringe for it to be on the Alioth shootout, but it's there.
From that it looks like LuaJIT can't beat g++ for speed on any of the

--bb
May 25 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 5/22/10, retard <re tard.com.invalid> wrote:
 I can't believe the 64-bit processes are twice as large.

They probably aren't. I don't think we're talking about the same thing here. I, and I don't think Nick is either, am not saying that 64-bit is bad. We're just saying not having 64 bit isn't a big deal for most applications, since 32-bit apps aren't bad either. Yes, it would be nice to have a 64 bit compiler for when you need it, but odds are, your application doesn't need it.
May 22 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 5/22/10, bearophile <bearophileHUGS lycos.com> wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=4165

I don't think that's a bug. It should only worry about converting, not filtering out bad stuff. That's an orthogonal problem that the other function does well, and easily too.
May 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 22 May 2010 16:23:35 -0500, Andrei Alexandrescu wrote:

 On 05/22/2010 02:38 PM, retard wrote:
 Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote:

 On 5/22/10, retard<re tard.com.invalid>  wrote:
 On a 4 GB system you lose 600+ MB of memory when using a 32-bit
 operating system without PAE support.

You can run 32 bit programs on a 64 bit operating system. The point isn't that 64 bits is useless in general, it is just that most *applications* work just fine as 32 bit binaries.

I can't believe the 64-bit processes are twice as large. Typically the binary size is only a fraction of the amount of data processed by the application. Moreover, most of the memory allocations contain array like structures for storing bitmaps, I/O buffers etc. For example, if you're storing 8-bit pixels in a game, you're not forced to use int64 data type on a 64-bit architecture.

It all depends on what the largest payload is. One of my apps' largest structures was a hash, which was almost twice as large in the 64-bit version.

Ah, good to know. I haven't really seen many comparisons of 32-bit code vs 64-bit code. Haven't researched to topic much, either. But it makes sense when the payload is small vs the size of the pointer. I think some VMs deal with the issue by compressing pointers ( http://wikis.sun.com/ display/HotSpotInternals/CompressedOops ). In JVM, the maximum size of compressed pointer heap is only 32 GB, though, so we need to invent something new for desktop systems in 2020.
May 22 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 22 May 2010 16:25:55 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:ht9atu$rop$1 digitalmars.com...
 Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:
 Most apps don't need native x86_64. Only things that really push the
 limits of CPU/memory utilization need it, which, aside from bloatware
 (which admittedly is at epidemic levels lately), is really only a
 minority of apps. For the rest, if it already runs fine on 32-bit,
 then the same exec on a 64-bit machine is only going to run better
 anyway, and if is already ran fine before, then there's no problem.

You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature.

64-bit versions. Don't go pulling out strawmen.

Sorry for pulling out that, but I thought the claim "most apps" was a bit overoptimistic. If D is The next gen language, it probably also should solve the next generation of problems. I don't see much point in rewriting notepad, mspaint or solitaire in D. If you only need to deal with a small amount of data, why use native low-level languages? The fact is that resource usage will grow and artificial limitations (32-bit code) just makes the language irrelevant a lot faster. Another problem with x86 code is that you need to install all kinds of 32- bit libraries on a x86-64 (Linux) system. You also don't have the full 2.5 - 3.7 GB (depending on of RAM available for processes, the limit is something like 2 or 3 GB depending on the OS settings [1] (in some cases you need to assume the user has only allowed 2 GB for user mode processes). So in reality you could probably have even less than 2 GB available. Is that a problem? Yes, it is a serious problem in professional audio/video/photo applications, soon games (huge game worlds, complex SVM/ANN AI), and all kinds of servers.
 Take a 32-bit executable optimized for i386 or i586, that runs
 acceptably well on a 32-bit system (say, a P4, or even a P4-era
 Celeron). Take that same binary, put it on a 64-bit system (say, your
 Core i7). It will run *at least* at fast, most likely faster.

Yea, it will run faster, but who said the original application ran fast enough? CPU demanding applications never run fast enough. The applications tend to require more and more resources. It seems the x87 instructions (i386/586) have 5-6x larger latency than SSE2+ and SSE2+ has 2-4x greater throughput. Combined, that could mean 20x slower loops.
 Could it be made even faster than that with a 64-bit-native recompile?
 Sure. But if the 32-bit binary already ran acceptably well on the 32-bit
 system, and even faster on the 64-bit system, then who gives a shit?
 
 Guess how much a 64-bit system with 4 GB of RAM costs these days - a
 quick search gave me the number $379 at

already does everything I need it to do? $379.

Sure. And I have to admit I don't really know what's your target audience. It might even be 8086 systems since IIRC dmd/dmc support old 16- bit dos environments. But most commercial applications aren't geared towards Your 32-bit system. There's a good reason - people do upgrade their systems at least once in 5 years (x86-64 appeared 7 years ago..). Your system *will* physically break at some point and you have to replace it, probably with a faster one, because they won't be selling compatible parts anymore. Computers have a limited life time. Ordinary people don't lubricate their fans or replace bad capacitors themselves. You can find used parts, but those are more expensive than new ones. For example a used 128MB/SDRAM-100 module typically costs as much as a 1GB/ DDR2-800 here. Budget GPUs for the PCI bus cost 4x as much as similar PCI Express cards. A 750GB PATA disk costs as much as a 1500GB SATA-2 disk. And let's be honest, $379 isn't that much - if you only upgrade the cpu +mobo+ram+gpu, it's closer to $100-150. If you can't afford that much once in 5 years, you should stop developing software, seriously. If Your application doesn't require new hardware, the 3rd party software forces you to upgrade. For example, recently I noticed that the Ati/ Nvidia GPU control panel requires a .NET version that is not available for Windows 2000 (and that's not the only program not working on Windows 2000 anymore..). So I must buy a new operating system.. but people can't legally sell their used OEM Windows without also selling me their 64-bit machines =) And I can't buy a new Windows XP/Vista license, only Windows 7 available on stores. So basically I'm forced to also upgrade the hardware. [1] http://www.brianmadden.com/blogs/brianmadden/archive/2004/02/19/ the-4gb-windows-memory-limit-what-does-it-really-mean.aspx
May 22 2010
parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:ht9n8n$rop$4 digitalmars.com...
 Sat, 22 May 2010 16:25:55 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:ht9atu$rop$1 digitalmars.com...
 Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:
 Most apps don't need native x86_64. Only things that really push the
 limits of CPU/memory utilization need it, which, aside from bloatware
 (which admittedly is at epidemic levels lately), is really only a
 minority of apps. For the rest, if it already runs fine on 32-bit,
 then the same exec on a 64-bit machine is only going to run better
 anyway, and if is already ran fine before, then there's no problem.

You're suffering Stockholm syndrome there. Not having a functional 64-bit compiler isn't a positive feature.

64-bit versions. Don't go pulling out strawmen.

Sorry for pulling out that, but I thought the claim "most apps" was a bit overoptimistic. If D is The next gen language, it probably also should solve the next generation of problems.

I never said D or DMD shouldn't support x64, hence, yea, I agree that it should support 64-bit to, as you say "solve the next generation of problems". I just think that, for most apps, it's silly for someone to feel that they must have a 64-bit binary.
 I don't see much point in
 rewriting notepad, mspaint or solitaire in D.

For someone who seems to believe so strongly in "out with the old, in with the new", it seems rather odd that you expect apps along the lines of notepad, mspaint, etc to all stick around forever and with the same old langauge.
 If you only need to deal
 with a small amount of data, why use native low-level languages?

1. Why not? There's nothing about smaller apps that necessitates anything like a VM. 2. To avoid pointless bloat. Just because some people have a gajillion cores and petabytes of ram doesn't mean there's any reason to settle for a notepad that eats up a third of that. 3. I know this isn't in line with the current trendiness-compliant viewpoints, but I'd much rather find a good language and be able to stick with it for whatever I need than constantly bounce around a hundred different languages for every little thing.
 The fact
 is that resource usage will grow and artificial limitations (32-bit code)
 just makes the language irrelevant a lot faster.

Why do you still imply that I've advocated keeping D/DMD 32-bit-only?
 Another problem with x86 code is that you need to install all kinds of 32-
 bit libraries on a x86-64 (Linux) system.

If your Core i7 system with 24 GB RAM has any trouble keeping around the 32-bit libs in addition to 64-bit ones, then you got royally screwed over. But if you're talking about the bother of installing the 32-bit libs, well, that's Linux for you (Not that I'm a fan of any particular OS).
 You also don't have the full
 2.5 - 3.7 GB (depending on of RAM available for processes, the limit is
 something like 2 or 3 GB depending on the OS settings [1] (in some cases
 you need to assume the user has only allowed 2 GB for user mode
 processes). So in reality you could probably have even less than 2 GB
 available.

I only have 1 GB installed, so I couldn't care less. (Although I could have sworn I had 2 GB. Weird...Maybe I moved the other stick over to my Linux box when I built it...)
 Is that a problem? Yes, it is a serious problem in
 professional audio/video/photo applications, soon games (huge game
 worlds, complex SVM/ANN AI), and all kinds of servers.

Video: By what I admit is a rather big coincidence, I have some video processing going on in the background right as I type this. Seriously. I do video processing on this machine and I get by fine. Obviously, I would want to get a 64-bit multi-core with gobs of RAM if I were doing it professionally, but I think you're seriously underestimating the capabilities of P4-era hardware. Games: I'll put it this way: I bought a Wii, and not a 360 or a PS3, specifically because I don't give a rat's ass about game graphics that are anything more than, frankly, Gamecube or XBox 1 level. One of my favorite games is Megaman 9. So you can't tell me that all that fancy hardware is, or will ever be, necessary for games. It is necessary for *some* types of games, but these days that's only because developers like Epic are in bed with the hardware manufacturers and refuse to care one bit about anyone who isn't a High-Def graphics whore. Also, I hate playing games at a desk (or on a laptop, for that matter), so I almost always play on a console system, and therefore don't need my PC to play games anyway. A lot of gamers feel the same way (and there's plenty of other issues with games-on-a-PC too, like rootkit DRM and lack of second-hand-market). And for that matter, most PC users never go anywhere near the sorts of games that require fancy hardware anyway. So again, not a particularly compelling argument. Servers: Sure, for a lot of servers. But that's only a subset of software in general. Besides, half of the sites out there run on notably slow platforms like PHP and Python, so really, there's lot of people who clearly don't care about speed even for a server.
 Take a 32-bit executable optimized for i386 or i586, that runs
 acceptably well on a 32-bit system (say, a P4, or even a P4-era
 Celeron). Take that same binary, put it on a 64-bit system (say, your
 Core i7). It will run *at least* at fast, most likely faster.

Yea, it will run faster, but who said the original application ran fast enough?

I did when I said "**that runs acceptably well** on a 32-bit system". And contrary to popular belief, "software that runs acceptably well on a 32-bit system" is far from unreasonable. Most of the software I use runs acceptably well on my 32-bit system (a Celeron, even). And as for the software I use that doesn't run particularly well on this system (like FireFox 2), well, I can still get by fine with it, and there are always alternatives out there that do run much faster (meaning it's not an issue with my hardware being too slow), but that I just don't use because they have other drawbacks (like Chrome) and speed isn't always my top priority in choosing an app (or in choosing hardware, for that matter).
 CPU demanding applications never run fast enough. The
 applications tend to require more and more resources. It seems the x87
 instructions (i386/586) have 5-6x larger latency than SSE2+ and SSE2+ has
 2-4x greater throughput. Combined, that could mean 20x slower loops.

I used to have a double-speed CD burner. Got it way back when they were $200-$300 and triple-/quad-speeds didn't exist. Used to set up a burn, get something else useful done for half an hour, and then it'd be done. Later on, I got one of those super-fast burners, something like 32x, maybe 50x or so, I don't remember. God was it fast by comparison. Practically instant, it seemed. Soon after, I realized that it hardly ever made any real difference at all in overall time savings. Sometimes a 20x speed-up matters, sure. But not as often as people think. When it improves responsiveness, that's when it usually matters. When it improves something that's already inherently slow, it doesn't always matter quite as much as people think it does.
 Guess how much more that costs me than using my 32-bit system that
 already does everything I need it to do? $379.

Sure. And I have to admit I don't really know what's your target audience. It might even be 8086 systems since IIRC dmd/dmc support old 16- bit dos environments.

I don't know about DMC, but DMD, and even the D spec itself, doesn't do 16-bit. (A number of embedded developers (low-level, naturally) have voiced disappointment with that.)
 But most commercial applications aren't geared towards Your 32-bit
 system. There's a good reason - people do upgrade their systems at least
 once in 5 years (x86-64 appeared 7 years ago..). Your system *will*
 physically break at some point and you have to replace it, probably with
 a faster one, because they won't be selling compatible parts anymore.
 Computers have a limited life time.

If your computers break down in just five years, you're buying crap.
 (x86-64 appeared 7 years ago..)

Which hardly counts, since at the time it cost an arm and a leg and nothing used it. Basically, your average Joe was definitely *not* buying it.
 Ordinary people don't lubricate their
 fans or replace bad capacitors themselves.

Neither do I.
 You can find used parts, but those are more expensive than new ones. For
 example a used 128MB/SDRAM-100 module typically costs as much as a 1GB/
 DDR2-800 here. Budget GPUs for the PCI bus cost 4x as much as similar PCI
 Express cards. A 750GB PATA disk costs as much as a 1500GB SATA-2 disk.
 And let's be honest, $379 isn't that much - if you only upgrade the cpu
 +mobo+ram+gpu, it's closer to $100-150. If you can't afford that much
 once in 5 years, you should stop developing software, seriously.

First of all, I have gotten upgrades to this machine. Replaced the CD burner with a dual-layer DVD burner. Constantly add bigger hard drives (I admit, I can never have enough HDD space). Got a Bluetooth dongle to mess around with the Wii remote. Got a video capture card. Stuck in one of those memory card readers that fits in a 3.5" floppy bay (also have a 3.5" floppy drive, of course ;) ). Replaced my GeForce 2MX with a cheap Radeon 9200SE (IIRC) so I could mess around with pixel shading (which turned out to be a waste, since I never did get around to it). But you're still sidestepping the bigger picture here: If my computer is working fine for me, does what I need it to do, why in the world should I be expected to replace it at all? (Just to please some damn gear-heads, or lazy developers?) Especially if I have other things to spend money on that actually *do* matter.
 If Your application doesn't require new hardware, the 3rd party software
 forces you to upgrade. For example, recently I noticed that the Ati/
 Nvidia GPU control panel requires a .NET version that is not available
 for Windows 2000 (and that's not the only program not working on Windows
 2000 anymore..).

So what? Most 3rd party software is crap anyway. And as far as OEM software goes (and I'm definitely including both ATI and NVIDIA, as well as Toshiba, HP, and others, all from personal experience), well, I *would* say OEM software is always crap, but "crap" is far too kind a word for it. There's crap software, and then there's OEM software. And I've long been saying that hardware companies don't know a damn thing about software. Besides, ever since XP came out, Win2k was primarily just used by businesses. And MS-businesses always flock unquestioningly to the latest versions within about a year of release, and since Win2k, there's been XP, 2k3, Vista, 7, and there may have been another server one I'm forgetting. *I* probably wouldn't have yanked Win2k support, but it's not a great example of software forcing a hardware upgrade.
 So I must buy a new operating system.. but people can't
 legally sell their used OEM Windows without also selling me their 64-bit
 machines =) And I can't buy a new Windows XP/Vista license, only Windows
 7 available on stores. So basically I'm forced to also upgrade the
 hardware.

I don't know first hand, but I keep hearing [non-MS] people claiming that Win7 runs faster than XP even on XP-era hardware.
May 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 22 May 2010 16:56:39 -0700, Walter Bright wrote:

 Nick Sabalausky wrote:
 Good to know. In my case though, it's a wisdom tooth and, I would say
 that it's chipped, but it would be more accurate to say that half of it
 is gone, and what remains has two sharp edges (Kinda like a two-pronged
 fork pointing into the gums). It's not really causing much pain, but I
 do conciously try to chew on the other side (unnatural for me) because
 if I were to bite down on something the wrong way, then it would hurt
 like hell. Plus two dentists have already said it should go.

My dentist told me they can now grind off the rotten top of a tooth and add a new one attached to the original root. He told me that because one of my molars has a growing crack in it. It's not a crisis now, but it will be. Wisdom teeth can be hard to work on because they're so far back. Dentists have a tendency to just pull them out rather than try to save them. I'd ask your dentist if he can just grind off the sharp edges, add a bit of epoxy (they use epoxy now to fill cavities), and keep the root in place. Or maybe do a crown. > The first one did wanted me to get all the wisdoms out. But the > second one just said the one needed it and that the other three > didn't matter either way. Never go back to that first one. I'd question the judgment of the 2nd in saying it "didn't matter" if they were pulled. I switched dentists when that one greedy jerk wanted to pull my wisdom teeth, and found one that shared my views on preserving the natural teeth as much as possible.

In my case the wisdom teeth didn't really fit in my mouth and harmed the occlusion. The doctors first tried to fix it with braces, but the growing wisdow tooth pushed it so hard that the first iteration of braces broke. After they removed the wisdom teeth, the treatment has again improved the occlusion to its previous pre wisdom teeth state.
May 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 23 May 2010 04:14:30 -0400, bearophile wrote:

 Walter Bright:
 Doing it in an automated way
 requires whole program analysis, something not entirely practical in a
 language designed to support separate compilation.

Compiling programs of a dynamic language like Lua was seen as hopelessly inefficient. But today programs running on the the Lua JIT are often faster than equivalent FP-heavy D programs compiled with DMD. So it's all in having a positive attitude toward technological problems: if the need to do something grows strong enough, people usually find a way to do it :-)

I don't think the D community is really interested in hearing something positive about dynamically typed non-native languages. Traditionally that's the best way to wreck your efficiency and it's tough to admit that those languages are now better. The traditional native code way is to use primitive compilers and brute force via inline asm.
May 25 2010
prev sibling parent retard <re tard.com.invalid> writes:
Tue, 25 May 2010 14:22:47 -0700, Walter Bright wrote:

 retard wrote:
 I don't think the D community is really interested in hearing something
 positive about dynamically typed non-native languages. Traditionally
 that's the best way to wreck your efficiency and it's tough to admit
 that those languages are now better. The traditional native code way is
 to use primitive compilers and brute force via inline asm.

If this were true, C and C++ would be dead languages. C++, for example, is often used in combination with Python. The C++ part is for the bits that need to be fast. BTW, even the best compilers fall far short of what an expert can do with assembler.

It's impossible to say whether e.g. LuaJIT is faster than some C++ compiler. The code matters. Bad code written by a novice programmer often works faster when a higher level language is used because there's more room for optimizations. However, it really depends on the quality of the optimzations done by the compiler. What I wanted to point out was that if a person needs to choose between D (DMD) and Lua (LuaJIT), it would probably make more sense to use LuaJIT if the user wants better performing code. However, D (LDC) and D (some other vendor who uses modern backends like LLVM/GCC) probably win DMD here. Almost all compilers probably beat it.
May 25 2010