Re: D2 is really that stable as it is claimed to be?

[deadalnix]

On Sunday, 22 September 2013 at 05:23:50 UTC, Walter Bright wrote:

On 9/21/2013 9:34 PM, deadalnix wrote:
Most issue are being worked on. That being said, changing 
semantic in a
programming language is always a difficult matter, as people 
code relying on the

old bugguy behavior may break.


And often the same people who want semantic changes are the 
ones who complain when new features break things :-(


Guilty here :D

Re: D2 is really that stable as it is claimed to be?

[Kenji Hara]

2013/9/22 Zhouxuan 

> http://d.puremagic.com/**issues/show_bug.cgi?id=10970


That is a long-standing bug around AA value setting and opAssign, and
fortunately I recently tried to fix it by determining the language
semantics.
https://github.com/D-Programming-Language/dmd/pull/2539

Kenji Hara

Re: D2 is really that stable as it is claimed to be?

[Jonathan M Davis]

On Saturday, September 21, 2013 23:54:26 Michel Fortin wrote:
> On 2013-09-22 03:32:26 +, Jonathan M Davis  said:
> > On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
> >> Column values are of interest in an IDE because it can pinpoint the
> >> error more precisely. The IDE can show exactly where the error is (for
> >> instance with a dotted red underline), often allowing you to fix the
> >> error without even reading the error message (especially when it's a
> >> typo). With a background-compilation-as-you-type system you know almost
> >> immediately when you make an error, and you know where it is.
> > 
> > A lexer being used by an IDE definitely needs the column number, but the
> > normal compiler doesn't.
> 
> I was referring to how the IDE can show the compiler's error messages
> better when the column number is available, not to how it does syntax
> highlighting. Xcode uses this a lot, and clang's error log provides
> full character ranges for errors, not just a column number, making the
> visualization of errors much better and pleasant to work with.
> 
> But indeed, no one *needs* that. Like everything else, it's just a
> convenience.
> 
> I don't think it should be a priority, but rejecting the idea outright
> is shortsighted in my opinion.

I don't think that it's at all worth it for compiling with the compiler on the 
command line. The situation changes somewhat when an IDE gets involved.

- Jonathan M Davis

Re: D2 is really that stable as it is claimed to be?

[Maxim Fomin]

On Saturday, 21 September 2013 at 22:36:44 UTC, Walter Bright 
wrote:


Ok, so it found a latent bug in the source code - I don't think 
that's a good example of dmd being unstable - it was a good 
change.


OK, this was a latent bug in sources. I think this is not the 
first and not the last event when dmd starts rejecting buggy 
code. However that means that before the change dmd accepted 
invalid and this jeopardizes D implementation. And anyway, 
irrespectively of whether issue is a true regression or fixing 
accepts-invalid bug, for majority of users this doesn't play much 
role but means creating problems of code breakage in each release.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 8:54 PM, Michel Fortin wrote:

I don't think it should be a priority, but rejecting the idea outright is
shortsighted in my opinion.


I'm not rejecting the idea outright. I've actually implemented this in the dmc 
compiler. It's just not terribly useful, and it has costs.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 8:17 PM, Michel Fortin wrote:

You could *replace* the line number with a "byte from start of file" and then
compute lazily either the line number or the column number for the rare times
where you actually need to get the line or column number. (Ideally you'd also
keep a map of the byte offset for the start of each line in a file to make that
computation fast.)


That's an expensive computation. The trouble is, "compile with symbolic debug 
info on" is when you want fast compiles, and you'll need the line number everywhere.



Column values are of interest in an IDE because it can pinpoint the error more
precisely. The IDE can show exactly where the error is (for instance with a
dotted red underline),


I do understand this.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 9:34 PM, deadalnix wrote:

Most issue are being worked on. That being said, changing semantic in a
programming language is always a difficult matter, as people code relying on the
old bugguy behavior may break.


And often the same people who want semantic changes are the ones who complain 
when new features break things :-(

Re: Bartosz Milewski seems to like D more than C++ now :)

[Paul Jurczak]

On Friday, 20 September 2013 at 16:28:49 UTC, Joseph Rushton 
Wakeling wrote:

[...]

The canonical example would be something like,

foreach (i; iota(10)) { ... }

which in theory shouldn't be any slower than,

foreach (i; 0 .. 10) { ... }

but in practice is, no matter what the compiler.


Some compilers are unexpectedly smart in this case. I just 
benchmarked somewhat similar code with two version of the same 
function: one using a straight for loop, the other mixture of 
iota and "..". Plain for loop should be the fastest, right? 
Almost right. Here are the functions:


int e28_0(int N = 1002) {
int diagNumber = 1; 
int sum= diagNumber;

for (int width = 2; width < N; width += 2)   
for (int j = 0; j < 4; ++j) {
diagNumber += width;
sum+= diagNumber;   
}

return sum;
}

int e28_1(int N = 1002) {
int diagNumber = 1; 
int sum= diagNumber;

foreach (width; iota(2, N, 2))
foreach (_; 0..4) { 
diagNumber += width;
sum+= diagNumber;   
}

return sum;
}

Here are the results:

GDC 4.8.1: gdc-4.8 -m64 -march=native -fno-bounds-check 
-frename-registers -frelease -O3

669171001  830ns  e28_0
669171001  830ns  e28_1

DMD64 2.063.2: dmd -O -noboundscheck -inline -release
669171001  1115ns  e28_0
669171001  1958ns  e28_1

LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline -release
669171001  454ns  e28_0
669171001  395ns  e28_1

Re: D2 is really that stable as it is claimed to be?

[deadalnix]

On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
From what I see, as a new user of D, D's current feature set is 
so exciting and rich enough that I'm willing to give it a try. 
However, I feel frustrated because some simple usage about some 
feature I excerice failed, take AA for example, it's a basic 
feature as described in TDPL, but I even can't use it to store 
an array indexed by a string 
(http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter 
whatever you explaned, it's the truth that I feel AA is not 
usable and I give up AA (or maybe whole D given that AA is 
advertised to be a very basic feature).It's really a big 
problem and you guys should focus more on it if D wanna gain 
more popularity IMHO.


Yes, AA is definitively the fastest road toward problems.

On the other hand, D's feature is attractive, no matter how 
much buggy is it, the expectation that it'll be solved once D 
gain more popularity and more and more programmers are 
innvolved in D may keep me learn and practise D as a hobby, but 
where's the expectation comes from? IMHO, D need a more 
organized team, meet once a week or two on irc, report your 
effort and finally post it to public (maybe filtered) like Rust 
meeting on its wiki page. So that every new user is convinced 
that D's in a virtuous circle and every issue they care about 
is being worked on, as well as a future plan (if not being 
worked ATM) on those issues most mentioned in NG/IRC etc like 
GC.


Most issue are being worked on. That being said, changing 
semantic in a programming language is always a difficult matter, 
as people code relying on the old bugguy behavior may break.

Re: D2 is really that stable as it is claimed to be?

[Adam D. Ruppe]

On Sunday, 22 September 2013 at 03:37:02 UTC, Zhouxuan wrote:
feature as described in TDPL, but I even can't use it to store 
an array indexed by a string


If you use the built in arrays instead of the std.container Array 
type it will work. It still shouldn't be segfaulting, but this 
isn't quite as basic a flaw as it seems, since the library Array 
type is pretty complex.

Re: D2 is really that stable as it is claimed to be?

[Michel Fortin]

On 2013-09-22 03:32:26 +, Jonathan M Davis  said:


On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:

Column values are of interest in an IDE because it can pinpoint the
error more precisely. The IDE can show exactly where the error is (for
instance with a dotted red underline), often allowing you to fix the
error without even reading the error message (especially when it's a
typo). With a background-compilation-as-you-type system you know almost
immediately when you make an error, and you know where it is.


A lexer being used by an IDE definitely needs the column number, but the normal
compiler doesn't.


I was referring to how the IDE can show the compiler's error messages 
better when the column number is available, not to how it does syntax 
highlighting. Xcode uses this a lot, and clang's error log provides 
full character ranges for errors, not just a column number, making the 
visualization of errors much better and pleasant to work with.


But indeed, no one *needs* that. Like everything else, it's just a convenience.

I don't think it should be a priority, but rejecting the idea outright 
is shortsighted in my opinion.


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

Re: D2 is really that stable as it is claimed to be?

[Zhouxuan]

From what I see, as a new user of D, D's current feature set is 
so exciting and rich enough that I'm willing to give it a try. 
However, I feel frustrated because some simple usage about some 
feature I excerice failed, take AA for example, it's a basic 
feature as described in TDPL, but I even can't use it to store an 
array indexed by a string 
(http://d.puremagic.com/issues/show_bug.cgi?id=10970),no matter 
whatever you explaned, it's the truth that I feel AA is not 
usable and I give up AA (or maybe whole D given that AA is 
advertised to be a very basic feature).It's really a big problem 
and you guys should focus more on it if D wanna gain more 
popularity IMHO.
On the other hand, D's feature is attractive, no matter how much 
buggy is it, the expectation that it'll be solved once D gain 
more popularity and more and more programmers are innvolved in D 
may keep me learn and practise D as a hobby, but where's the 
expectation comes from? IMHO, D need a more organized team, meet 
once a week or two on irc, report your effort and finally post it 
to public (maybe filtered) like Rust meeting on its wiki page. So 
that every new user is convinced that D's in a virtuous circle 
and every issue they care about is being worked on, as well as a 
future plan (if not being worked ATM) on those issues most 
mentioned in NG/IRC etc like GC.
FYI, as a new user both to D and Rust, Rust is more convinced to 
me in every aspect except for its current unstable status.Its 
mainpage, wiki page and github repo are far more informative and 
active than D's counter-part, why don't we learn from Rust?


Sincerely hope/wish D to be more successful!

Re: D2 is really that stable as it is claimed to be?

[Jonathan M Davis]

On Saturday, September 21, 2013 23:17:23 Michel Fortin wrote:
> Column values are of interest in an IDE because it can pinpoint the
> error more precisely. The IDE can show exactly where the error is (for
> instance with a dotted red underline), often allowing you to fix the
> error without even reading the error message (especially when it's a
> typo). With a background-compilation-as-you-type system you know almost
> immediately when you make an error, and you know where it is.

A lexer being used by an IDE definitely needs the column number, but the normal 
compiler doesn't.

- Jonathan M Davis

Re: D2 is really that stable as it is claimed to be?

[deadalnix]

On Saturday, 21 September 2013 at 19:51:42 UTC, Andrei 
Alexandrescu wrote:

On 9/21/13 12:28 PM, QAston wrote:
Containers as planned for phobos need solving the issue of 
allocators
for them.  Andrei which is working on them is probably stuck 
in void

somewhere between compiletime and runtime worlds :)


FWIW I am making solid progress on allocators. In places the 
design comes together really really unexpectedly nice.




That is the sign of great design, or because the error is so 
obviously that nobody checked against it. Can you give q quick 
update on that in some topic ?

Re: Prorogued Proramming - somthing to consider for the D future?

[Nick Sabalausky]

On Sat, 14 Sep 2013 21:25:58 +0200
"Peter Alexander"  wrote:

> Here's a super quick summary for those without time to watch:
> 
> He proposed a language keyword, 'prorogue' used like so:
> 
> int foo = prorogue bar(x);
> 
> The keyword indicates that, instead of calling 'bar', the code 
> should ask the user for the return value, which is then memoized 
> with the value of x, and is saved across executions. bar need not 
> be defined. You can also do things like 'return prorogue;' to 
> request a value to return.
> 
> The reported uses of this are:
> - Top-down development: prorogue functions to mock them.
> - Debugging: mark a call as prorogue to provide a value to repro 
> a failure case.
> - Crowdsourcing: if you memoize across the internet then all 
> users collaborate to fill in gaps.
> 

I think that's a pretty cool idea.

Re: D2 is really that stable as it is claimed to be?

[Michel Fortin]

On 2013-09-22 01:45:33 +, Walter Bright  said:


On 9/21/2013 6:09 PM, Sean Kelly wrote:

A single pointer per file isn't much memory and a write per line isn't much
of a speed hit. Fair point about holding the file in memory except that DMD
does this anyway. Mine wasn't a general comment so much as one specifically
about the D front end. As for the rest, if you can see the problems with an
approach before starting then don't do it that way. :-)


It isn't once per file, it's once per node in the AST, plus all the 
copying around of the value(s).


You could *replace* the line number with a "byte from start of file" 
and then compute lazily either the line number or the column number for 
the rare times where you actually need to get the line or column 
number. (Ideally you'd also keep a map of the byte offset for the start 
of each line in a file to make that computation fast.)


Column values are of interest in an IDE because it can pinpoint the 
error more precisely. The IDE can show exactly where the error is (for 
instance with a dotted red underline), often allowing you to fix the 
error without even reading the error message (especially when it's a 
typo). With a background-compilation-as-you-type system you know almost 
immediately when you make an error, and you know where it is.


I do agree that it is of minor interest when you're reading the error log.

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

Re: D2 is really that stable as it is claimed to be?

[Jonathan M Davis]

On Sunday, September 22, 2013 04:38:40 Paul Jurczak wrote:
> That would do: 255 means column 256 or higher (256+). You would
> please more than 99.99% of users :-)

Except that most of us don't care about the column number. It's of marginal 
benefit at best, and it harms compilation speed, so it's not worth it IMHO.

- Jonathan M Davis

Re: Need help to finish DMD zip/7z release generator (alpha release)

[Nick Sabalausky]

On Fri, 20 Sep 2013 17:39:22 -0400
Nick Sabalausky  wrote:

> On Fri, 20 Sep 2013 21:38:06 +0200
> Rainer Schuetze  wrote:
> > 
> > I noticed that it is the git process that has a handle on that 
> > directory. It seems to able to delete the directory if you run git
> > from the parent directory and pass "dmd" instead of ".".
> 
> Hmm, well it's been working fine on my Win machine as-is, but I'll
> look into doing that. I think I had some reason for doing it this
> way, but it probably wasn't anything major.
> 

Just before I was about to make that fix, I started experiencing the
same problem, too.

I've made the change you suggested and it seems to work for me. Can you
verify?

Re: D2 is really that stable as it is claimed to be?

[Paul Jurczak]

On Sunday, 22 September 2013 at 00:33:32 UTC, Walter Bright wrote:

On 9/21/2013 5:11 PM, Sean Kelly wrote:
Tracking the column number is certainly doable, but it comes 
at a cost of
memory consumption and some compile speed, since it has to be 
tracked in
every token. I used to do it in the Digital Mars C compiler, 
but it was of

only marginal utility and I dropped it.


Can't you just hold a pointer to the beginning of the line and 
subtract to
find the column?  I agree that it's generally of marginal 
utility though.


Holding the pointer has a cost of memory consumption and 
compile speed :-) as well as having to have the source file 
buffer stay around throughout the compile (to compute column 
number you need the source in order to account for tabs & 
Unicode).


Of course, we can cheat and use a byte to store the column 
number, as after all, nobody has more than 256 columns.

[...]


That would do: 255 means column 256 or higher (256+). You would 
please more than 99.99% of users :-)

Re: Will Java go native?

[Paul Jurczak]

On Thursday, 19 September 2013 at 09:48:15 UTC, Joakim wrote:
On Thursday, 19 September 2013 at 08:26:03 UTC, Russel Winder 
wrote:
Java is no longer under-performant compared to C, C++, 
Fortran, D, Go, Rust. Check the benchmarks.
Interesting.  Java people have been saying this for years and 
it's never been quite true, so I just looked up the benchmark 
shootout to see if you're right.  It shows Java 7 doing pretty 
well against C++ these days, roughly equivalent speed or at 
worst half as fast:


http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&data=u64q
[...]


It doesn't do that well when single core is selected (always 
slower, 4x worst case):


http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=java&lang2=gpp&data=u64

It means that Java VM/libraries can explore multiple cores better 
that C++.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 6:09 PM, Sean Kelly wrote:

A single pointer per file isn't much memory and a write per line isn't much
of a speed hit. Fair point about holding the file in memory except that DMD
does this anyway. Mine wasn't a general comment so much as one specifically
about the D front end. As for the rest, if you can see the problems with an
approach before starting then don't do it that way. :-)



It isn't once per file, it's once per node in the AST, plus all the copying 
around of the value(s).

Re: D2 is really that stable as it is claimed to be?

[Sean Kelly]

On Sep 21, 2013, at 5:33 PM, Walter Bright  wrote:

> On 9/21/2013 5:11 PM, Sean Kelly wrote:
>>> Tracking the column number is certainly doable, but it comes at a cost of
>>> memory consumption and some compile speed, since it has to be tracked in
>>> every token. I used to do it in the Digital Mars C compiler, but it was of
>>> only marginal utility and I dropped it.
>> 
>> Can't you just hold a pointer to the beginning of the line and subtract to
>> find the column?  I agree that it's generally of marginal utility though.
> 
> Holding the pointer has a cost of memory consumption and compile speed :-) as 
> well as having to have the source file buffer stay around throughout the 
> compile (to compute column number you need the source in order to account for 
> tabs & Unicode).
> 
> Of course, we can cheat and use a byte to store the column number, as after 
> all, nobody has more than 256 columns.
> 
> Then you get a bug report where someone does. So raise it to an unsigned 
> short, then, sigh, you get another bug report where someone's entire source 
> file is on one line, and on it goes.

A single pointer per file isn't much memory and a write per line isn't much of 
a speed hit. Fair point about holding the file in memory except that DMD does 
this anyway. Mine wasn't a general comment so much as one specifically about 
the D front end. As for the rest, if you can see the problems with an approach 
before starting then don't do it that way. :-)

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 5:11 PM, Sean Kelly wrote:

Tracking the column number is certainly doable, but it comes at a cost of
memory consumption and some compile speed, since it has to be tracked in
every token. I used to do it in the Digital Mars C compiler, but it was of
only marginal utility and I dropped it.


Can't you just hold a pointer to the beginning of the line and subtract to
find the column?  I agree that it's generally of marginal utility though.


Holding the pointer has a cost of memory consumption and compile speed :-) as 
well as having to have the source file buffer stay around throughout the compile 
(to compute column number you need the source in order to account for tabs & 
Unicode).


Of course, we can cheat and use a byte to store the column number, as after all, 
nobody has more than 256 columns.


Then you get a bug report where someone does. So raise it to an unsigned short, 
then, sigh, you get another bug report where someone's entire source file is on 
one line, and on it goes.

Re: D2 is really that stable as it is claimed to be?

[Kapps]

On Saturday, 21 September 2013 at 20:00:52 UTC, Jakob Bornecrantz 
wrote:
On Saturday, 21 September 2013 at 18:23:20 UTC, bearophile 
wrote:

Zhouxuan:


http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 
LOCs written down.


D is not claimed to be stable, or those claims are wrong.


Then again _NOWHERE_ on the start page, the overview page
or the download* page is the word stable found. On the other
hand unstable for that matter, none of those pages really
convey that shit _IS_ going to break every new compiler
release, proceed with caution.


* Stable is found there but referring to the latest GDC release.



I've found my code to not break very frequently anymore even 
using git head. The last thing that broke any of my code was the 
stringof change in git head, and that was a 2 minute fix. I think 
it's been 2-3 minor releases before that at least.

Re: D2 is really that stable as it is claimed to be?

[Sean Kelly]

On Sep 21, 2013, at 12:47 PM, Walter Bright  wrote:

> On 9/21/2013 12:38 PM, eles wrote:
>> On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:
>>> On 9/21/2013 11:03 AM, Maxim Fomin wrote:
>>> 
>>> test.c:4: error: overflow in enumeration values
>> 
>> It would be difficult to make the front-end track also the column number 
>> where
>> it encountered (estimated) the error?
> 
> That's gcc, and 4 is the line number (and the wrong line number) of the 
> error. No column number.
> 
>> This will make error messages a bit more clear (and in the line of thos in 
>> gcc),
>> especially for long code lines (where you could have, for example, several
>> instructions on the line).
>> 
>> At the beginning, until the feature is really implemented, the front-end 
>> could
>> always provide "column=1", ie stick with current approach.
>> 
>> But this will help the gdc/ldc-implementations to be in line with the 
>> messages
>> provided by gcc and clang.
> 
> Tracking the column number is certainly doable, but it comes at a cost of 
> memory consumption and some compile speed, since it has to be tracked in 
> every token. I used to do it in the Digital Mars C compiler, but it was of 
> only marginal utility and I dropped it.

Can't you just hold a pointer to the beginning of the line and subtract to find 
the column?  I agree that it's generally of marginal utility though. 

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sun, 22 Sep 2013 01:07:08 +1000
Manu  wrote:

>[...lots of stuff snipped...]

Believe it or not, my opinions on Linux, Windows and everyday usability
are actually very, very similar to yours (including the vague
impression that Linux GUIs are just facades - which they actually sort
of are just by design, but I digress).

In fact, all that stuff is why I'm still on Windows for my main system.
Luckily, things like driver issues and major failures haven't been an
issue for me on Linux for quite some time. But it's other
everyday-productivity things like finding a filemanager and taskbar
that aren't too rough-around-the-edges (because I rely on them *sooo*
heavily), Tortoise-like VCS integration (I don't understand how
people can use Git's command line for anything non-trivial), non-manual
HDD SMART monitoring like HD Sentinel, etc. Finding suitable
replacements for all these things I use every day takes some work, and
I'm still not entirely finished.

And even when I do find what seems to be the best, it isn't always as
good as Windows: For example, there is *no* taskbar on Linux I've found
that's as well-designed as the one Windows has already had for nearly
20 years. There are a bunch of OSX-dock-alikes that, I assume, might do
a good job of emulating the OSX experience (I haven't tried since I
never liked the dock). But over a decade since I first tried them, the
taskbars in KDE, XFCE, etc still don't quite match the quality of
design that MS already had in Windows 95.

That said, I do find that Xfce 4.10 is good enough to be acceptable for
me, but it still isn't up to Windows standards.

The odd thing is, I've been finding that each new version of post-XP
Windows has required more and more effort to undo all of their...what I
find to be productivity-hindering UI "enhancements". So Windows is
requiring more and more effort (for me), and simultaneously I've been
getting more and more proficient with the ever-improving Linux (due to
my server work and doing cross-platform testing), and I don't see any
signs of MS or Linux altering their current trajectories. So the
writing's on the wall, as it were, and for me Linux is becoming a
better bet for everyday productivity. (But this is all just "FWIW" side
comments, not an argument of Linux being "better".)

I think it was mainly your reaction to H. S. Teoh's story that irked
me. It's kinda like watching a mechanic rebuild the engine of some
"known to be gearhead-friendly" car just because he'd been trying to
squeeze out some extra horsepower and erroneously saying "Wow, that
must be a bad brand of car if you have to muck with the engine just to
drive it."

Also, I disagree with your implication that a command line actually
needs to be more user-friendly in more ways than just less cryptic
names. Obviously I wouldn't have a problem if the commandline actually
was more usable to everyone (naturally that'd be a good thing), but I
don't think that's a significant issue, being that it *is* the command
line after all, and non-experts would mostly just stick to GUIs anyway.

> I'm also not 'average-joe-numskull', at least I don't like to think I
> am,

As far as I'm concerned, a programmer is by definition *not* an
average-joe-numskull. If you can write one line of code, run it, and
properly understand it, you're already waaay more advanced than 90% of
computer users.

>The only way I can reason that people can be happy being so
>unproductive, is that they don't actually know what it's like to be
>really productive in the first place. (see: my comment prior about the
>mouse scroll-wheel)

I must have missed that mouse scroll-wheel comment and I can't seem to
find it. What was it again?

FWIW, And I find this somewhat ironic: I find the mouse scroll-wheel to
be FAR more usable on Linux than Windows. On linux you just point to
what you want to scroll and...scroll it. On windows you have to go out
of your way to give the desired control focus (clicking on some
innocuous part of it, tabbing to it, whatever) and only *then* will the
scrollwheel actually do its job. Then you want to scroll something
else? Repeat the process. Imagine if you had to do that to right-click!
I actually find that scrolling issue to really get in my way quite
frequently when trying to do work on Windows. :(  I was able to fix
that on XP, but not on 7.


>If I had visual studio and PIX, I would take a screen capture, clicked
>on the bad pixel, it would immediately present a stack of every
>rendering event contributing to that pixel, and the entire state of
>the rendering hardware at every step of the way, and I'd find the
>problem in a couple of minutes.

Whoa, now that's pretty damn cool. I'd never heard of PIX before.

>I have a strong suspicion that linux works better if you use it daily.
>I'm starting to realise a pattern emerging that things tend to fuck up
>after I perform a bulk round of updates.

I've learned through pain, even in Windows land (heck, so much software
is cross platform thes

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 3:11 PM, Maxim Fomin wrote:

On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright wrote:

On 9/21/2013 2:40 PM, Maxim Fomin wrote:

Thanks, that is clear. Unfortunately, I cannot say that the explanation improves
my attidute to the language - dmd still breaks too often code and some
significant features (like AAs, scope, shared) are at risk to be seriously
changed which is a serious problem to the user.


I'm curious - was there a logic bug in your code with the overflow, or had
that been the intended behavior?


This was bug in gtkd sources when I tried to compile its most recent version
(tried even from github) with git-head dmd. I think it is a problem of gtkd
developers rather than dmd.


Ok, so it found a latent bug in the source code - I don't think that's a good 
example of dmd being unstable - it was a good change.

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Maxim Fomin:

Well, it is an option to ban dynamic arrays in boolean 
conditions

because the way they are implemented right now is buggy, but I
consider fixing semantic and still keeping syntax to be a better
option comparing to a complete ban.


Right, fixing that semantic is another option I listed in Issue 
4733 :-)


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 3:27 PM, bearophile wrote:

Walter Bright:


I believe that bugzilla is an honest list of the problems. It's the whole
point of bugzilla.


So are you saying that Bugzilla is enough for new or future D users that want to
know how much stable D is?


It's an honest list of the problems, for anyone who wants to look at them, and 
they can then make up their own mind about stability based on their needs.

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Walter Bright:

I believe that bugzilla is an honest list of the problems. It's 
the whole point of bugzilla.


So are you saying that Bugzilla is enough for new or future D 
users that want to know how much stable D is?


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Maxim Fomin]

On Saturday, 21 September 2013 at 22:06:07 UTC, Walter Bright 
wrote:

On 9/21/2013 2:40 PM, Maxim Fomin wrote:
Thanks, that is clear. Unfortunately, I cannot say that the 
explanation improves
my attidute to the language - dmd still breaks too often code 
and some
significant features (like AAs, scope, shared) are at risk to 
be seriously

changed which is a serious problem to the user.


I'm curious - was there a logic bug in your code with the 
overflow, or had that been the intended behavior?


This was bug in gtkd sources when I tried to compile its most 
recent version (tried even from github) with git-head dmd. I 
think it is a problem of gtkd developers rather than dmd.

Re: D2 is really that stable as it is claimed to be?

[Maxim Fomin]

On Saturday, 21 September 2013 at 21:58:44 UTC, bearophile wrote:

Maxim Fomin:

Thanks, that is clear. Unfortunately, I cannot say that the 
explanation improves my attidute to the language - dmd still 
breaks too often code and some significant features (like AAs, 
scope, shared) are at risk to be seriously changed which is a 
serious problem to the user.


The creation of such breaking changes should have priority over 
(= happen sooner than) most other compiler changes and bug 
fixes.


Beside AAs, scope, and shared, another smaller example of such 
breaking changes was discussed a lot today:


http://d.puremagic.com/issues/show_bug.cgi?id=11080
http://d.puremagic.com/issues/show_bug.cgi?id=4733



Yes, unfortunately D problems are not limited to those mentioned.


In Issue 11080 someone has asked to disallow code like:

assert("something going wrong");

But I suggest to not add that rule and instead implement the 
small breaking change discussed in Issue 4733, that disallows 
the use of dynamic arrays in all boolean evaluation contexts. 
So Issue 11080 becomes a special case that needs no special 
testing code in the compiler.


Bye,
bearophile


Well, it is an option to ban dynamic arrays in boolean conditions
because the way they are implemented right now is buggy, but I
consider fixing semantic and still keeping syntax to be a better
option comparing to a complete ban.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 2:40 PM, Maxim Fomin wrote:

Thanks, that is clear. Unfortunately, I cannot say that the explanation improves
my attidute to the language - dmd still breaks too often code and some
significant features (like AAs, scope, shared) are at risk to be seriously
changed which is a serious problem to the user.


I'm curious - was there a logic bug in your code with the overflow, or had that 
been the intended behavior?

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 2:27 PM, bearophile wrote:

While I don't have a solution for that that fuzzy problem, I can express some
opinions:
- My technical training has taught me to trust honest lists of problems more
than advertisements of technology wonders that break at my first usage;


I believe that bugzilla is an honest list of the problems. It's the whole point 
of bugzilla.

Re: D2 is really that stable as it is claimed to be?

[Andrej Mitrovic]

On 9/21/13, Maxim Fomin  wrote:
> (like AAs, scope, shared) are at risk to be seriously changed which is a
> serious problem to the user.

These are already a serious problem to the user when they're broken
and under-implemented.

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Maxim Fomin:

Thanks, that is clear. Unfortunately, I cannot say that the 
explanation improves my attidute to the language - dmd still 
breaks too often code and some significant features (like AAs, 
scope, shared) are at risk to be seriously changed which is a 
serious problem to the user.


The creation of such breaking changes should have priority over 
(= happen sooner than) most other compiler changes and bug fixes.


Beside AAs, scope, and shared, another smaller example of such 
breaking changes was discussed a lot today:


http://d.puremagic.com/issues/show_bug.cgi?id=11080
http://d.puremagic.com/issues/show_bug.cgi?id=4733

In Issue 11080 someone has asked to disallow code like:

assert("something going wrong");

But I suggest to not add that rule and instead implement the 
small breaking change discussed in Issue 4733, that disallows the 
use of dynamic arrays in all boolean evaluation contexts. So 
Issue 11080 becomes a special case that needs no special testing 
code in the compiler.


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Maxim Fomin]

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
wrote:

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

For example, I was pissed off two days ago when
git-head dmd rejected to compile large code base due to some 
'enum overflow'
error. Being watching bugzilla and github for two years, that 
change was neither

expected nor clear for me.


Enum members with no initializer are defined to be set to the 
previous enum member's value + 1. This, of course, can overflow 
if the previous value is the max value for the type. For 
example,


enum E {
A = int.max,
B
}

C:\cbx\mars>dmd test
test.d(3): Error: enum member test.E.B overflow of enum value 
cast(E)2147483647


This change was made because the behavior of ignoring the 
overflow was listed as a bug.


Since you said it was unclear, how could this be made clear?


As C code:

enum E {
A = 2147483647,
B
};

and gcc reports:

test.c:4: error: overflow in enumeration values


Thanks, that is clear. Unfortunately, I cannot say that the 
explanation improves my attidute to the language - dmd still 
breaks too often code and some significant features (like AAs, 
scope, shared) are at risk to be seriously changed which is a 
serious problem to the user.

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Andrei Alexandrescu:

I'm ambivalent because the matter is fuzzy. It is factually 
true that new releases will break code. On the other hand, that 
is the case with most compiler releases even for mature 
languages (at Facebook upgrading across minor gcc releases 
_always_ entails significant disruption). On the third hand 
(sic), there are companies and projects using D in the real 
world so stating that is unstable would do little else than 
either shoo people away for no good reason.


While I don't have a solution for that that fuzzy problem, I can 
express some opinions:
- My technical training has taught me to trust honest lists of 
problems more than advertisements of technology wonders that 
break at my first usage;
- I am now keeping lot of D2 code updated and in use, and the 
work needed to keep it working release after release of dmd was a 
bit too much for me. If I fix the code only every release there 
are multiple different sources of breakage and they interact 
making fixing code harder. I solved that compiling dmd once or 
more every week. Dmd compiles in a very short time, and I test my 
whole code base in a short time, both at compile-time and in 
unittests. Now there only one source of breaking, I know what's 
the cause of the breaking because it's from the last days of 
merged patches, and fixing code takes a very short time.
- Often the "breakage" is actually just an exposition of true or 
latent bugs in my D code. Such "breaking" is welcome and I want 
more of it.


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Paulo Pinto]

Am 21.09.2013 23:03, schrieb eles:

On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright wrote:

On 9/21/2013 12:38 PM, eles wrote:

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

test.c:4: error: overflow in enumeration values


It would be difficult to make the front-end track also the column
number where
it encountered (estimated) the error?


That's gcc, and 4 is the line number (and the wrong line number) of
the error. No column number.


I knew that.


This will make error messages a bit more clear (and in the line of
thos in gcc),
especially for long code lines (where you could have, for example,
several
instructions on the line).

At the beginning, until the feature is really implemented, the
front-end could
always provide "column=1", ie stick with current approach.

But this will help the gdc/ldc-implementations to be in line with the
messages
provided by gcc and clang.


Tracking the column number is certainly doable, but it comes at a cost
of memory consumption and some compile speed, since it has to be
tracked in every token. I used to do it in the Digital Mars C
compiler, but it was of only marginal utility and I dropped it.


See this thread, pls:

http://forum.dlang.org/thread/vtpcxubtuquvelsof...@forum.dlang.org

Also, this link ("C family") for colors and caret:

http://gcc.gnu.org/gcc-4.9/changes.html

clang implemented this and pressure was put on gcc to do the same.

Good and clear diagnostic messages/display are of big help, I think.


The funny thing is that this was already supported since a few years in 
the form of colorgcc.


--
Paulo

Re: D2 is really that stable as it is claimed to be?

[Andrei Alexandrescu]

On 9/21/13 1:06 PM, bearophile wrote:

Jakob Bornecrantz:


On the other
hand unstable for that matter, none of those pages really
convey that shit _IS_ going to break every new compiler
release, proceed with caution.


I agree, and in my opinion this should be fixed adding a small note to
the D home page, that explains that you should expect every new D
version to break your older code and that someday this will stop. Is
Andrei agreeing on this small homepage change?


I'm ambivalent because the matter is fuzzy. It is factually true that 
new releases will break code. On the other hand, that is the case with 
most compiler releases even for mature languages (at Facebook upgrading 
across minor gcc releases _always_ entails significant disruption). On 
the third hand (sic), there are companies and projects using D in the 
real world so stating that is unstable would do little else than either 
shoo people away for no good reason.



Andrei

Re: D2 is really that stable as it is claimed to be?

[eles]

On Saturday, 21 September 2013 at 19:47:08 UTC, Walter Bright 
wrote:

On 9/21/2013 12:38 PM, eles wrote:
On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
wrote:

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

test.c:4: error: overflow in enumeration values


It would be difficult to make the front-end track also the 
column number where

it encountered (estimated) the error?


That's gcc, and 4 is the line number (and the wrong line 
number) of the error. No column number.


I knew that.

This will make error messages a bit more clear (and in the 
line of thos in gcc),
especially for long code lines (where you could have, for 
example, several

instructions on the line).

At the beginning, until the feature is really implemented, the 
front-end could

always provide "column=1", ie stick with current approach.

But this will help the gdc/ldc-implementations to be in line 
with the messages

provided by gcc and clang.


Tracking the column number is certainly doable, but it comes at 
a cost of memory consumption and some compile speed, since it 
has to be tracked in every token. I used to do it in the 
Digital Mars C compiler, but it was of only marginal utility 
and I dropped it.


See this thread, pls:

http://forum.dlang.org/thread/vtpcxubtuquvelsof...@forum.dlang.org

Also, this link ("C family") for colors and caret:

http://gcc.gnu.org/gcc-4.9/changes.html

clang implemented this and pressure was put on gcc to do the same.

Good and clear diagnostic messages/display are of big help, I 
think.

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Jakob Bornecrantz:


On the other
hand unstable for that matter, none of those pages really
convey that shit _IS_ going to break every new compiler
release, proceed with caution.


I agree, and in my opinion this should be fixed adding a small 
note to the D home page, that explains that you should expect 
every new D version to break your older code and that someday 
this will stop. Is Andrei agreeing on this small homepage change?


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Jakob Bornecrantz]

On Saturday, 21 September 2013 at 18:23:20 UTC, bearophile wrote:

Zhouxuan:


http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.


D is not claimed to be stable, or those claims are wrong.


Then again _NOWHERE_ on the start page, the overview page
or the download* page is the word stable found. On the other
hand unstable for that matter, none of those pages really
convey that shit _IS_ going to break every new compiler
release, proceed with caution.


* Stable is found there but referring to the latest GDC release.

Re: D2 is really that stable as it is claimed to be?

[Andrei Alexandrescu]

On 9/21/13 12:28 PM, QAston wrote:

Containers as planned for phobos need solving the issue of allocators
for them.  Andrei which is working on them is probably stuck in void
somewhere between compiletime and runtime worlds :)


FWIW I am making solid progress on allocators. In places the design 
comes together really really unexpectedly nice.


To the original poster: thanks for submitting those bugs. They concern 
simple code and it is an embarrassment for us that this kind of 
"out-of-the-box experience" bugs still appear.



Andrei

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 10:41 AM, Zhouxuan wrote:

http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs written down.
Should I continue?

Despite these tiny issues, I see a lot of people complain about container, GC
etc, but I can't found any offical reply, also no roadmap at all.


Thanks for taking the time to make some nice bug reports. They're a big help.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 12:38 PM, eles wrote:

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright wrote:

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

test.c:4: error: overflow in enumeration values


It would be difficult to make the front-end track also the column number where
it encountered (estimated) the error?


That's gcc, and 4 is the line number (and the wrong line number) of the error. 
No column number.



This will make error messages a bit more clear (and in the line of thos in gcc),
especially for long code lines (where you could have, for example, several
instructions on the line).

At the beginning, until the feature is really implemented, the front-end could
always provide "column=1", ie stick with current approach.

But this will help the gdc/ldc-implementations to be in line with the messages
provided by gcc and clang.


Tracking the column number is certainly doable, but it comes at a cost of memory 
consumption and some compile speed, since it has to be tracked in every token. I 
used to do it in the Digital Mars C compiler, but it was of only marginal 
utility and I dropped it.

Re: Move VisualD to github/d-programming-language ?

[eles]

On Saturday, 21 September 2013 at 16:37:08 UTC, Manu wrote:

On 21 September 2013 21:06, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:


On 9/21/13 3:04 AM, SomeDude wrote:

On Saturday, 7 September 2013 at 19:26:11 UTC, Peter 
Alexander wrote:


On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright 
wrote:


Recent threads here have made it pretty clear that VisualD 
is a

critical piece of D infrastructure.



Then it should be here: http://dlang.org/download.html

That's the most important change that needs to be made.



+1



Preapproved. Looking forward to the appropriate pull request. 
Rainer?



I think it's equally important to move DMD1 and DMC down the 
bottom into

small text links.


Or link towards a D1 download page and DMC's download page.

Re: compiled code file size

[Vladimir Panteleev]

On Friday, 20 September 2013 at 16:20:34 UTC, Duke Normandin 
wrote:
I'm re-visiting the D language. I've compared the file sizes of 
2 executables - 1 is compiled C code using gcc; the other is D 
code using dmd.


helloWorld.d => helloWorld.exe = 146,972 bytes
ex1hello.c => ex1-hello.exe = 5,661 bytes

Why such a huge difference???


You can upload a .map file here, and see what's taking up all the 
space:

http://thecybershadow.net/d/mapview/

Re: D2 is really that stable as it is claimed to be?

[eles]

On Saturday, 21 September 2013 at 18:55:46 UTC, Walter Bright 
wrote:

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

test.c:4: error: overflow in enumeration values


It would be difficult to make the front-end track also the column 
number where it encountered (estimated) the error?


This will make error messages a bit more clear (and in the line 
of thos in gcc), especially for long code lines (where you could 
have, for example, several instructions on the line).


At the beginning, until the feature is really implemented, the 
front-end could always provide "column=1", ie stick with current 
approach.


But this will help the gdc/ldc-implementations to be in line with 
the messages provided by gcc and clang.

Re: D2 is really that stable as it is claimed to be?

[QAston]

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:

http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.

Should I continue?



I have had similar feelings when I started with D i think. Well, 
as soon as you see a language which has so many capabilities 
you've never seen before in one place (reflection and native code 
- yay!) you start pushing it to the limit. Sometimes you're doing 
a thing noone even thought about before :).


Exercising the capabilites of D is fun but there are some things 
which do not work yet. After some experience I've settled on 
using a simpler subset of D functionality; both because I think 
simpler sollutions are better and because simpler parts of D tend 
to work very well.


Go ahead and report more bugs, this is improving the situation in 
longer term. People which will use D after you will be glad 
you've spent a little time on doing that because their experience 
will be smoother. It'd be nice if D was perfect already but 
things simply take a lot of time and effort to be done. It's hard 
to compete with already mature enviroments because of that.


Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.


As for containers there's std.container and builtin arrays and 
hasmaps - that's somewhat a poor set, but you can use container 
libraries from github.


Containers as planned for phobos need solving the issue of 
allocators for them.  Andrei which is working on them is probably 
stuck in void somewhere between compiletime and runtime worlds :)

Re: D2 is really that stable as it is claimed to be?

[Peter Alexander]

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:

http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.

Should I continue?

Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.


D is not what I would call stable, but it is very usable. 
Apparently D is used at Facebook in some capacity, but Andrei 
won't tell us more than that :-)


Not long ago I would find bugs every hour or so, but now I rarely 
find bugs. Perhaps I have just learned to write code in the 
subset of D that works well, but the language is definitely a lot 
more stable.


Please continue to submit bugs. The D contributors do fix bugs 
very rapidly in general.

Re: D2 is really that stable as it is claimed to be?

[Walter Bright]

On 9/21/2013 11:03 AM, Maxim Fomin wrote:

For example, I was pissed off two days ago when
git-head dmd rejected to compile large code base due to some 'enum overflow'
error. Being watching bugzilla and github for two years, that change was neither
expected nor clear for me.


Enum members with no initializer are defined to be set to the previous enum 
member's value + 1. This, of course, can overflow if the previous value is the 
max value for the type. For example,


enum E {
A = int.max,
B
}

C:\cbx\mars>dmd test
test.d(3): Error: enum member test.E.B overflow of enum value cast(E)2147483647

This change was made because the behavior of ignoring the overflow was listed as 
a bug.


Since you said it was unclear, how could this be made clear?


As C code:

enum E {
A = 2147483647,
B
};

and gcc reports:

test.c:4: error: overflow in enumeration values

Re: D2 is really that stable as it is claimed to be?

[bearophile]

Zhouxuan:


http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.


D is not claimed to be stable, or those claims are wrong.

About three years ago I used to find a new compiler bug about 
every 20 lines of my code. Now the situation is improved a lot 
and I am able to write more lines before hitting bugs. They have 
fixed hundreds of the bugs I have submitted, so dmd is now more 
debugged for the code patterns I usually write. If your code 
patterns are different from mine, you will see significantly more 
bugs than me :-)




Should I continue?


Of course you should continue to submit bugs. Fixing 100+ bugs in 
every D release is having positive visible effects on the 
language+compiler. If you submit bugs and they get fixed in some 
days/weeks/months/years, your code patterns will work more and 
more.



Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.


There is no official roadmap because D is not developed in that 
way, and because there is not enough workforce. Perhaps someday a 
roadmap will be present.


Bye,
bearophile

Re: D2 is really that stable as it is claimed to be?

[Maxim Fomin]

On Saturday, 21 September 2013 at 17:41:38 UTC, Zhouxuan wrote:

http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.

Should I continue?

Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.


Yes, it is unstable and still is advertized as being so. There 
are significant misfunctioning features which would break code 
when are fixed, let alone each release breaks something minor. 
For example, I was pissed off two days ago when git-head dmd 
rejected to compile large code base due to some 'enum overflow' 
error. Being watching bugzilla and github for two years, that 
change was neither expected nor clear for me. Now I see, that two 
years ago when I abandoned not reach for features but fully 
stable lang, I was undervaluing neccessity of a lang to be a 
stable.

D2 is really that stable as it is claimed to be?

[Zhouxuan]

http://d.puremagic.com/issues/show_bug.cgi?id=11086
http://d.puremagic.com/issues/show_bug.cgi?id=11010
http://d.puremagic.com/issues/show_bug.cgi?id=10970

I've found and reported these bugs after about merely 100 LOCs 
written down.

Should I continue?

Despite these tiny issues, I see a lot of people complain about 
container, GC etc, but I can't found any offical reply, also no 
roadmap at all.

Re: [OT] Which IDE / Editor do you use?

[Minas]

I use mono develop (on ubuntu).

Re: [OT] Which IDE / Editor do you use?

[Danni Coy]

On Fri, Sep 20, 2013 at 12:11 PM, Manu  wrote:
> On 20 September 2013 00:25, H. S. Teoh  wrote:
>>
>> On Thu, Sep 19, 2013 at 03:04:44PM +0200, Wyatt wrote:
>> [...]
>> > Dolphin is pretty nice, though there are cases where Konqueror still
>> > runs circles around it. For example, if you want a horizontal split
>> > or more than one split.  Also, I don't think Dolphin has the file
>> > size view plugin, which is nice for finding hidden monsters in your
>> > ~.
>>
>> du ~ | sort -r -n | less
>
>
> This is exactly why linux is shit.
>
>
>> :-)

By far the best way of doing that I have found of dealing with that
problem is the program filelight. I have tried to find something as
good on windows but so far no dice.

As far as I can tell Dolphin was an attempt to take the best features
of konqueror and make them discoverable if not as flexible.

Re: Move VisualD to github/d-programming-language ?

[Manu]

On 21 September 2013 21:06, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:

> On 9/21/13 3:04 AM, SomeDude wrote:
>
>> On Saturday, 7 September 2013 at 19:26:11 UTC, Peter Alexander wrote:
>>
>>> On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote:
>>>
 Recent threads here have made it pretty clear that VisualD is a
 critical piece of D infrastructure.

>>>
>>> Then it should be here: http://dlang.org/download.html
>>>
>>> That's the most important change that needs to be made.
>>>
>>
>> +1
>>
>
> Preapproved. Looking forward to the appropriate pull request. Rainer?


I think it's equally important to move DMD1 and DMC down the bottom into
small text links.
Last time I went looking for GDC I didn't see the link there because it was
off the screen, and I skipped past presuming that page was just for
walter's binaries since they dominated my screen.

enum, std.traits and "is(SomeEnumOfStruct == struct)" ?

[monarch_dodra]

I'm investigating a "inconsistent" behavior in std.traits 
regarding how the traits react when being passed an enum. To make 
things simple, they don't react the way you'd expect.


Consider the simple types:
//
struct User
{
char c;
alias c this;
}

enum E_char : char {a = char.init}
enum E_User : User {a = User.init}
//

Question: Which of these are aggregates? which of these are some 
char type?

Answer:
static assert(!isAggregateType!char);   //Makes sense
static assert( isAggregateType!User);   //Makes sense
static assert(!isAggregateType!E_char); //Makes sense
static assert(!isAggregateType!E_User); //[1] Makes no sense

static assert(  isSomeChar!char);   //Makes sense
static assert( !isSomeChar!User);   //Makes sense
static assert(  isSomeChar!E_char); //[2] Makes sense?
static assert(  isSomeChar!E_User); //[3] Makes no sense

As you can see, I think behaviors [1] and [3] simply make no 
sense. "[2]" is arguably up to debate.


In any case, I was wondering what the root issue was: Is it the 
implementation of std.trait or does it come from this behavior 
for "is", when enums are involved:


static assert ( is(User == struct));
static assert ( is(E_char == enum));
static assert ( is(E_User == enum));
static assert (!is(E_char == struct));
static assert (!is(E_User == struct)); //[HERE]

Question 1: Does the scenario [HERE] make sense? Is this correct 
behavior?


Question 2: Would the syntax: "is (T : struct)" or "is (T : 
enum)" make sense? It would work around the "problem" elegantly, 
as well as also provide support for asking things such as "does 
this class have an alias this to a struct", or "does this struct 
have an alias this to an enum"?

Re: [OT] Which IDE / Editor do you use?

[Manu]

On 22 September 2013 01:38, Peter Alexander wrote:

> On Saturday, 21 September 2013 at 15:07:17 UTC, Manu wrote:
>
>> I have fuck-all tools available, it's near impossible to debug. Something
>> that I know would take me 5 minutes in windows with that toolset has taken
>> me a whole day so far...
>> I honestly don't understand how linux users think it's okay.
>>
>
> Well, you aren't alone. Valve recently announced that they're working on a
> Linux debugger. They wouldn't bother wasting time and money doing that if
> the debugging experience on Linux was any good. As far as I'm aware,
> they're not working on a debugger for Windows, and I can only assume that's
> because debugging on Windows is bearable.
>

Yeah, there is discussion about this in another thread somewhere else.
I'm very much looking forward to what they bring to the table. But like I
said before, I fear they've got a LOT of catching up to do...

Re: compiled code file size

[Manu]

On 21 September 2013 21:34, Temtaime  wrote:

> Are you saying about passing a function via pointer to winapi for example?
> The logic is simple: if someone gets function address, then function
> cannot be stripped. It's logic of all c++ compilers.
>

Totally OT, but every single time I read your name when you post, I can't
help but start hearing lines from Terry Prachett's Hogfather in my head...
http://www.youtube.com/watch?v=M0mU3393PGk

Although I suspect not many people would have seen it.
My brain is a strange place...

Re: [OT] Which IDE / Editor do you use?

[Peter Alexander]

On Saturday, 21 September 2013 at 15:07:17 UTC, Manu wrote:
I have fuck-all tools available, it's near impossible to debug. 
Something
that I know would take me 5 minutes in windows with that 
toolset has taken

me a whole day so far...
I honestly don't understand how linux users think it's okay.


Well, you aren't alone. Valve recently announced that they're 
working on a Linux debugger. They wouldn't bother wasting time 
and money doing that if the debugging experience on Linux was any 
good. As far as I'm aware, they're not working on a debugger for 
Windows, and I can only assume that's because debugging on 
Windows is bearable.

Re: [OT] Which IDE / Editor do you use?

[Manu]

On 21 September 2013 21:27, Joseph Rushton Wakeling <
joseph.wakel...@webdrake.net> wrote:

>
> Specifically in this case: the user-friendliness of GNU/Linux distros has
> come a _huge_ way in the last 10 years, but there's no reason why they
> shouldn't be every bit as surface-friendly (maybe even more so) than the
> popular commercial OS's while retaining all the power that experts need and
> want.  It's a terrible shame that more attention is not given to this
> surface-friendliness, and it's striking how resistant many old-school free
> software people are to usability-oriented improvements _that don't
> necessarily constrain them_.
>
> ** Example 1 **
> I was a longstanding KDE user until with the 12.04 release of Ubuntu, I
> switched over to using Unity.  I found it much more usable and effective in
> all sorts of ways, but initially I was frustrated because there were
> superficially less config options available.  It was striking how quickly I
> realized _I didn't miss them_ and that most of that configurability I'd had
> with KDE was a distraction rather than something that assisted me.  As
> someone wrote round-about that time, there's a tendency for customisability
> to be an excuse for lack of design.
>

I really like this point. It's something I think I'll definitely keep in
mind in the future. I'm certainly guilty of this myself; "surely people
would prefer the option" when I'm writing some code.
But in reality, in almost every piece of software I use myself, even as a
'power user', I tend to use it in it's default configuration.

What this really highlights is that I'm a terrible UX coder myself :P

Re: Eliminating code duplication for static/nonstatic functions

[Vladimir Panteleev]

On Thursday, 19 September 2013 at 17:10:43 UTC, Andrei 
Alexandrescu wrote:
Consider a struct that may or may not have state depending on a 
type parameter:


I would like to note that this problem is a specific case of the 
general problem of changing a function's signature based on a 
compile-time value. The same problem exists with other 
attributes, and varying the presence of a template or function 
parameter. One example was that I wanted to define an overload 
set of function templates, where in some overloads, some 
parameters were function parameters, and in other overloads, the 
same parameters were template parameters (there was a significant 
optimization opportunity when the parameters were known at 
compile-time).

Re: [OT] Which IDE / Editor do you use?

[Manu]

On 21 September 2013 19:05, Nick Sabalausky <
seewebsitetocontac...@semitwist.com> wrote:

> On Sat, 21 Sep 2013 11:04:10 +1000
> Manu  wrote:
>
> > On 20 September 2013 22:15, H. S. Teoh  wrote:
> > >
> > > There is no argument here, actually. The problem is really
> > > historical -- names like 'du' or 'grep' or 'awk' meant something
> > > back in who knows when, but they no longer mean anything to us
> > > today (well, those of us not old enough *cough*). If I were to
> > > reinvent Unix today, I'd choose better names for these things. But
> > > think about it, if the above line were instead written like this:
> > >
> > > diskUsage $HOME | sort --reverse --numeric | pager
> > >
> > > it would make so much more sense, wouldn't it? So the "nonsensical"
> > > part is really just in the poor choice of naming, not an inherent
> > > weakness of the interface.
> > >
> >
> > I'd still argue that it is. It is how it is, and it's completely
> > prohibitive to casual or new users.
>
> So? Does everything have to be targeted at new/casual users? Can't
> experienced users have stuff that's made for them? Who ever said
> command lines are still intended for everybody? Keep in mind, a
> programmer is NOT a casual or new user. But in any case, please don't
> mistake "Windows vs Linux" as a "one size fits all" topic, because you
> seem to be steering things that way.
>
> Rant: Seems to be a big trend in computing these days. Everything is all
> about catering to Average Joe Numbskull and Little Miss Facebook, and to
> hell anyone who has more advanced experience and needs where "usable
> by anyone's grandmother" is the least of their concerns.
>
> Average Joes need their tools, sure, but so do the rest of us.
>
> You do realize that in the time you've spent taking a friendly OS
> discussion and single-handedly trying[1] to turn it into yet another
> ill-informed OS flamewar (congratulations, btw) you could have already
> learned quite a bit about using a unix command line?
>
> [1] Don't deny it. Your intent to bait was obvious a few posts back, but
> due to your good standing here I've been giving you a chance.
>

;)
Sure, I do like to stir the pot to some extent, I won't deny that, but my
primary position in this thread is actually just a recount of my own
experience trying to use linux _productively_.
I just reviewed my last few posts, I don't think I was being particularly
unreasonable. I'm trying to use linux, right now, and it's frustrating. If
it just worked, I wouldn't be frustrated.

I've said about 3 times already, and I'll say again, I actually *really*
like the idea of linux, I really do wish to see it succeed. I've made deals
with myself on numerous occasions to try and force myself to adapt.
The problem is, every time I make a good solid effort, I just become
frustrated with inevitable problems, and end up wasting so much time. And
the end point, even if I were somewhat more expert at fighting the OS, is
I'm left with a suite of tools which are simply inferior and less
productive by a huge huge margin to what I'm used to. I wish this weren't
the case. (I've already acknowledged loads of cool projects that look
promising, but isn't that ALWAYS the way with linux? And I'm talking about
things that were rock solid over 10 years ago)
Philosophically, I hate windows, apple, and everything they stand for. I'd
love to be all-out linux. I'm honestly just expressing my frustration with
the offering, and that people seem to genuinely think it's okay.
I'm not flame baiting (well, maybe a little bit, just because it always
gets a good reaction), I don't think my criticisms are unrealistic. And
they're not even really baits, I'm just sharing personal experience.

I'm also not 'average-joe-numskull', at least I don't like to think I am,
but that doesn't mean I want to know how a car is built, and then in turn
how each individual part was built, and how to fix it, before I can have
confidence it will get me to Sydney in one piece.
I don't actually really care about how linux works, or any of the little
bits and pieces that form it's awkward foundation... and I shouldn't need
to in order to like the premise of an open system, and want to use it on
that merit alone.
I don't actually enjoy OPERATING a computer, I enjoy the creative process
of working, and getting work done. Solving interesting problems. If the
computer gets in my way, it has failed me at some level.
That might sound strange coming from a software engineer, but I guess
that's how I see it. I just don't have the patience to mess with my OS
anymore.
I enjoyed _operating_ my Amiga 15-20 years ago. You should have seen how
pimp my desktop was!
I don't like operating computers anymore, I like using them.

I likewise don't want to know how the video driver interacts with the
kernel, and that I'm supposed to download source code to manually build
some driver shim to correct a fault of the system auto-update tool failing
to resolve a dependency correctly.
Or 

Re: Eliminating code duplication for static/nonstatic functions

[deadalnix]

On Friday, 20 September 2013 at 15:20:36 UTC, Andrei Alexandrescu 
wrote:

On 9/19/13 1:02 PM, Andrej Mitrovic wrote:
On 9/19/13, Andrei Alexandrescu 
 wrote:

I'm not sure I understand how that would work.


-
module test;

[snip]

Thanks, that's the simplest and most effective. I reduced it to:

struct A
{
enum hasState = false;
private mixin template funDef()
{
void fun(int x) { writeln(x); }
}
static if (hasState)
mixin funDef!();
else
static mixin funDef!();
}

void main()
{
A a;
a.fun(42);
}

I see no way to extract the scaffolding into a library.


Andrei


You'll be very disapointed when some of your overloads will 
disapear.

Re: std.serialization: pre-voting review / discussion

[mrd]

On Thursday, 22 August 2013 at 13:13:48 UTC, Jacob Carlborg wrote:

On 2013-08-22 13:57, ilya-stromberg wrote:


Can std.serialization load data from old file to the new class?


Yes. In this case it will use the name of the instance fields 
when searching for values in the archive.


Is this the right way?

There are special formats (Protocol Buffers, for example) for a 
binary format what can be changed over time without breaking old 
code.


But for normal serialization is not this redundant?
Besides, search by name slower compared with other methods (field 
numbers, for example).

Re: std.serialization: pre-voting review / discussion

[mrd]

On Thursday, 15 August 2013 at 07:07:13 UTC, Jacob Carlborg wrote:

On 2013-08-14 21:55, ilya-stromberg wrote:

Can you use another serialization format and supports file 
output for

it? For example, can you use JSON, BSON or binary format?


The idea of the library is that it can support multiple archive 
types. Currently only XML is implemented. I have been working 
on a binary archive for a while but I haven't finished it yet.


I am also working on my own binary archive implementation (I just 
want to quickly get a serialization of integral types, arrays and 
structs into binary) and I have a question:


What is the purpose of the "keys"?
If they really needed, can it be realised as option and disable 
them?
(I see also that they are forces to add a lot of duplicate 
functions.)


I guess if it succeeded binary format can be made very compact 
(and possibly faster) as Protocol Buffers.

Re: compiled code file size

[Peter Alexander]

On Saturday, 21 September 2013 at 11:11:09 UTC, deadalnix wrote:

On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander
There's no theoretical reason, but plenty of practical 
reasons. bearophile linked to a talk by Chandler Carruth that 
explains the difficulties encountered by inlining optimisers.


Either you are confusing with me ( 
http://forum.dlang.org/thread/mvbqiwajntrivndyl...@forum.dlang.org?page=8#post-mqcwjbgxildixehsxthe:40forum.dlang.org 
) or I missed that post by bearophile.


Sorry, I am just confused :-)

Re: compiled code file size

[Dicebot]

On Saturday, 21 September 2013 at 11:34:10 UTC, Temtaime wrote:
Are you saying about passing a function via pointer to winapi 
for example?
The logic is simple: if someone gets function address, then 
function cannot be stripped. It's logic of all c++ compilers.


More like passing an object instance to plugin which knows it 
only via .di import. Compiler can't possibly know what methods of 
that object (or function indirectly   accessible from it) will be 
available in the .di and/or called and must act conservatively, 
preserving everything.


It will also need to be aware of fact that function pointer 
retrieved via `dlsym` is actually some external function and use 
that knowledge during optimization.


Also it is worth noting that naive preservation of all functions 
that got their address may not work very well with frequent 
lambda usage for algorithms in D.


Same stuff with inheritance. It is just another side of a problem 
why compiler can't de-virtualize certain methods based on whole 
program class graph.


I won't be as harsh as to say it is impossible but this clearly 
requires defining some parts of the language that are currently 
vague.


P.S. C++ compilers are not much better here in that regard, 
unless you are going to try some non-standard tweaks.

Re: compiled code file size

[Dicebot]

On Saturday, 21 September 2013 at 11:46:13 UTC, Dicebot wrote:

...


P.S. A lot of those problems can be avoided even without Whole 
Program Optimization if internal linkage attribute is introduced 
;)

Re: [OT] Which IDE / Editor do you use?

[Joseph Rushton Wakeling]

On 21/09/13 12:44, Paulo Pinto wrote:

Basically, one of his messages is that nothing comes for free and learning
requires effort.

He makes the remark that only in the software industry people seem to have the
"learn in xxx days" mentality and suff for dummies.


One reason I like D is because it gives you access to all the difficult 
concepts, but doesn't wrap them up in difficult or finnicky syntax.


Sometimes highly expert developers are not good at appreciating the difference.

Re: [OT] Which IDE / Editor do you use?

[Joseph Rushton Wakeling]

On 21/09/13 12:12, Nick Sabalausky wrote:

That came out overly-harsh and not how I intended. ("Yea, no shit,
Nick") Uhh, yea...


Hah, and I just managed to write a huge long "Profundus Maximus" post in 
response to try and negotiate the peace ... :-P


http://www.flamewarriorsguide.com/warriorshtm/profundusmaximus.htm


What I mean is just, in this section of the thread, it has been
sounding as if you're simply flame-baiting or arguing for the sake of
arguing.

(And then I somehow managed to awkwardly weave that into a completely
different and not-terribly-important point about "time it takes", bleh,
whatever...)


Honestly, I think a bit of good-humoured trolling among friends is sometimes a 
good thing.  Keeps everyone on their toes and thinking ... :-)

Re: compiled code file size

[Temtaime]

Are you saying about passing a function via pointer to winapi for 
example?
The logic is simple: if someone gets function address, then 
function cannot be stripped. It's logic of all c++ compilers.

Re: compiled code file size

[Dicebot]

On Saturday, 21 September 2013 at 11:17:46 UTC, Temtaime wrote:

It's executable, not a DLL. So any functions can be stripped.
Isn't it ?


Not any. You must preserve those symbols that are exposed to DLL 
via callbacks or parameter types (functions are not only symbols 
that bloat). Now, it may be possible to compiler to detect those 
automatically  as passing parameter implies manual reference from 
code but I am not sure about that (D never stops to surprise me 
about weird hacks it can do :P)

Re: [OT] Which IDE / Editor do you use?

[Joseph Rushton Wakeling]

On 21/09/13 11:05, Nick Sabalausky wrote:

So? Does everything have to be targeted at new/casual users? Can't
experienced users have stuff that's made for them? Who ever said
command lines are still intended for everybody? Keep in mind, a
programmer is NOT a casual or new user. But in any case, please don't
mistake "Windows vs Linux" as a "one size fits all" topic, because you
seem to be steering things that way.


There's a difference between difficulty that is inherent, versus difficulty that 
is unnecessary and arises out of a lack of concern for usability.


Or, in the case being discussed here, more likely it arises out of historical 
priorities that apply much less today.  I would imagine that back in the early 
days of UNIX, processing key-presses was much more expensive than it is today, 
and there was thus a strong functional benefit in minimizing the amount of 
typing.  (That still applies to an extent today if you're typing commands over a 
slow ssh connection, for example.)


If we were designing command-line scripting from scratch, today, we'd do 
something very different and it would definitely be much more user-friendly, and 
no one would lose from that -- both experts and novices would benefit.



Rant: Seems to be a big trend in computing these days. Everything is all
about catering to Average Joe Numbskull and Little Miss Facebook, and to
hell anyone who has more advanced experience and needs where "usable
by anyone's grandmother" is the least of their concerns.

Average Joes need their tools, sure, but so do the rest of us.


Speaking as a hopefully non-average Joe ... making things usable by anyone's 
grandmother doesn't necessarily have to come at the cost of making things less 
good for experts.  Well-done usability design makes life easier for experts as 
well as for novices.


The problem is that because experts are as good as they are, they are much more 
capable of dealing with unnecessary complexity.  And, having mastered 
unnecessary complexity, it's then that bit more difficult to invest the time to 
learn a new, simpler way of doing things, because it means investing time to 
re-learn how to do stuff _you can already do_, and that learning curve means 
you'll go through a period of being less capable (because you're learning) than 
you are with your existing toolkit.  And then of course there's all the legacy 
stuff that does things using the old tools and which you know you'll have to 
keep using, so it's another reason to stick with what you know ... and thus 
lockin happens.


Case in point: C++ vs. D.  Is anyone here going to claim that, _as a language_, 
D is not significantly more user-friendly than C++?  Yet it's no less powerful 
-- in fact, the enhanced user-friendliness frees up experts to do more things 
better.



You do realize that in the time you've spent taking a friendly OS
discussion and single-handedly trying[1] to turn it into yet another
ill-informed OS flamewar (congratulations, btw) you could have already
learned quite a bit about using a unix command line?

[1] Don't deny it. Your intent to bait was obvious a few posts back, but
due to your good standing here I've been giving you a chance.


For what it's worth, I think you may have missed the humour of Manu's posts. 
Over-the-top criticism, in the right tone of voice, can be a pretty good way to 
get people who are used to a particular way of doing things to re-evaluate their 
assumptions.  It's important to occasionally engage in mockery and caricature of 
the things that we value, because it helps to re-engage our critical faculties 
about what is good and bad.


Specifically in this case: the user-friendliness of GNU/Linux distros has come a 
_huge_ way in the last 10 years, but there's no reason why they shouldn't be 
every bit as surface-friendly (maybe even more so) than the popular commercial 
OS's while retaining all the power that experts need and want.  It's a terrible 
shame that more attention is not given to this surface-friendliness, and it's 
striking how resistant many old-school free software people are to 
usability-oriented improvements _that don't necessarily constrain them_.


** Example 1 **
I was a longstanding KDE user until with the 12.04 release of Ubuntu, I switched 
over to using Unity.  I found it much more usable and effective in all sorts of 
ways, but initially I was frustrated because there were superficially less 
config options available.  It was striking how quickly I realized _I didn't miss 
them_ and that most of that configurability I'd had with KDE was a distraction 
rather than something that assisted me.  As someone wrote round-about that time, 
there's a tendency for customisability to be an excuse for lack of design.


** Example 2 **
The first GNU/Linux distro I ever installed on my own machine was Ubuntu 5.10, 
which I decided I should try out after seeing video of Mark Shuttleworth's talk 
at DebConf 2005.  Coming from Windows there was a fairly steep lea

Re: compiled code file size

[Temtaime]

It's executable, not a DLL. So any functions can be stripped.
Isn't it ?

Re: compiled code file size

[deadalnix]

On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander 
wrote:

On Saturday, 21 September 2013 at 10:29:35 UTC, Dicebot wrote:
Lot of code bloat comes from stuff which is unnecessary in the 
big picture but compiler has to means to decide it during 
compilation. There is no real reason why


`[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`

can't be reduce to single loop and inlined, leaving no traces 
of actual std.algorithm usage.


There's no theoretical reason, but plenty of practical reasons. 
bearophile linked to a talk by Chandler Carruth that explains 
the difficulties encountered by inlining optimisers.


Either you are confusing with me ( 
http://forum.dlang.org/thread/mvbqiwajntrivndyl...@forum.dlang.org?page=8#post-mqcwjbgxildixehsxthe:40forum.dlang.org 
) or I missed that post by bearophile.


Also, Dicebot have some very good points. Function can't be 
stripped from the executable if they are exported by default.

Re: Eliminating code duplication for static/nonstatic functions

[Andrei Alexandrescu]

On 9/20/13 8:52 AM, Simen Kjaeraas wrote:

I see no way to extract the scaffolding into a library.


Like this?


import std.stdio;

mixin template maybeStatic(bool isStatic, alias funDef, args...) {
 static if (isStatic) {
 static mixin funDef!args;
 } else {
 mixin funDef!args;
 }
}

struct A
{
 enum hasState = false;
 private mixin template funDef()
 {
 void fun(int x) { writeln(x); }
 }
 mixin maybeStatic!(!hasState, funDef);
}

void main()
{
 A a;
 a.fun(42);
}



This is nice. Works with shared, too.

Andrei

Re: Move VisualD to github/d-programming-language ?

[Andrei Alexandrescu]

On 9/21/13 3:04 AM, SomeDude wrote:

On Saturday, 7 September 2013 at 19:26:11 UTC, Peter Alexander wrote:

On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote:

Recent threads here have made it pretty clear that VisualD is a
critical piece of D infrastructure.


Then it should be here: http://dlang.org/download.html

That's the most important change that needs to be made.


+1


Preapproved. Looking forward to the appropriate pull request. Rainer?

Andrei

Re: compiled code file size

[Dicebot]

On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander 
wrote:

On Saturday, 21 September 2013 at 10:29:35 UTC, Dicebot wrote:
Lot of code bloat comes from stuff which is unnecessary in the 
big picture but compiler has to means to decide it during 
compilation. There is no real reason why


`[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`

can't be reduce to single loop and inlined, leaving no traces 
of actual std.algorithm usage.


There's no theoretical reason, but plenty of practical reasons. 
bearophile linked to a talk by Chandler Carruth that explains 
the difficulties encountered by inlining optimisers.


I wasn't referring to actual inlining but to "remove all unused 
that is left after inlining". You point is solid, of course, 
there is nothing trivial about robust inline optimizations - but 
is possible within existing language design.

Re: compiled code file size

[Peter Alexander]

On Saturday, 21 September 2013 at 10:29:35 UTC, Dicebot wrote:
Lot of code bloat comes from stuff which is unnecessary in the 
big picture but compiler has to means to decide it during 
compilation. There is no real reason why


`[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`

can't be reduce to single loop and inlined, leaving no traces 
of actual std.algorithm usage.


There's no theoretical reason, but plenty of practical reasons. 
bearophile linked to a talk by Chandler Carruth that explains the 
difficulties encountered by inlining optimisers.

Re: [OT] Which IDE / Editor do you use?

[Paulo Pinto]

Am 21.09.2013 12:12, schrieb Nick Sabalausky:

On Sat, 21 Sep 2013 05:05:41 -0400
Nick Sabalausky  wrote:


You do realize that in the time you've spent taking a friendly OS
discussion and single-handedly trying[1] to turn it into yet another
ill-informed OS flamewar (congratulations, btw) you could have already
learned quite a bit about using a unix command line?

[1] Don't deny it. Your intent to bait was obvious a few posts back,
but due to your good standing here I've been giving you a chance.



That came out overly-harsh and not how I intended. ("Yea, no shit,
Nick") Uhh, yea...

What I mean is just, in this section of the thread, it has been
sounding as if you're simply flame-baiting or arguing for the sake of
arguing.

(And then I somehow managed to awkwardly weave that into a completely
different and not-terribly-important point about "time it takes", bleh,
whatever...)



Just yesterday I've watched a cool talk from Rich Hickey (clojure 
designer) about design and the time it takes to learn stuff.


http://www.infoq.com/presentations/Design-Composition-Performance

Basically, one of his messages is that nothing comes for free and 
learning requires effort.


He makes the remark that only in the software industry people seem to 
have the "learn in xxx days" mentality and suff for dummies.


--
Paulo

Re: compiled code file size

[Dicebot]

On Friday, 20 September 2013 at 23:03:48 UTC, H. S. Teoh wrote:
I'll continue refining the analysis while Walter works on more 
lazy
instantiations for imports. I'm expecting to see a lot of 
improvements

in this area. :)


I have been doing similar analysis for some time too, only mostly 
manually (was curious what symbols actually get included for 
trivial programs), with pretty much the same conclusion.


Right now I am pretty much convinced that we need some sort of 
whole program optimization and tweak language spec to allow it 
safely (i.e. force dynamically loaded symbols to be marked with 
export).


Lot of code bloat comes from stuff which is unnecessary in the 
big picture but compiler has to means to decide it during 
compilation. There is no real reason why


`[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`

can't be reduce to single loop and inlined, leaving no traces of 
actual std.algorithm usage.


Other than compiler can't possibly be sure that you won't try to 
link to those generate instances somewhere (or pass it to shared 
library). That feels like a language design issue to address.

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 21 Sep 2013 05:05:41 -0400
Nick Sabalausky  wrote:
> 
> You do realize that in the time you've spent taking a friendly OS
> discussion and single-handedly trying[1] to turn it into yet another
> ill-informed OS flamewar (congratulations, btw) you could have already
> learned quite a bit about using a unix command line?
> 
> [1] Don't deny it. Your intent to bait was obvious a few posts back,
> but due to your good standing here I've been giving you a chance.
> 

That came out overly-harsh and not how I intended. ("Yea, no shit,
Nick") Uhh, yea...

What I mean is just, in this section of the thread, it has been
sounding as if you're simply flame-baiting or arguing for the sake of
arguing.

(And then I somehow managed to awkwardly weave that into a completely
different and not-terribly-important point about "time it takes", bleh,
whatever...)

Re: Will Java go native?

[SomeDude]

On Thursday, 19 September 2013 at 23:37:05 UTC, Russel Winder 
wrote:


I do note though that The Disruptor (by LMAX) is a seriously 
cool lock

free ring buffer based system written entirely in Java.


The Apache Cassandra distributed database is using it in its 
latest incarnation, among other things.

Re: Move VisualD to github/d-programming-language ?

[SomeDude]

On Saturday, 7 September 2013 at 19:26:11 UTC, Peter Alexander 
wrote:
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright 
wrote:
Recent threads here have made it pretty clear that VisualD is 
a critical piece of D infrastructure.


Then it should be here: http://dlang.org/download.html

That's the most important change that needs to be made.


+1

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 21 Sep 2013 04:21:24 -0400
Nick Sabalausky  wrote:

> On Sat, 21 Sep 2013 00:41:39 +0200
> "Brian Schott"  wrote:
> > 
> > I hope you've heard of OCRemix.org. Tons of remixes of classic 
> > video game music.
> > 
> 
> Yes. There's a lot of junk (lots and lots of amateur "techno"
> remixes), but some real gems, too.
> 
> DJ Pretzel is fantastic.
> 

Ehh, to clarify: OCRemix is awesome :)

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 21 Sep 2013 11:04:10 +1000
Manu  wrote:

> On 20 September 2013 22:15, H. S. Teoh  wrote:
> >
> > There is no argument here, actually. The problem is really
> > historical -- names like 'du' or 'grep' or 'awk' meant something
> > back in who knows when, but they no longer mean anything to us
> > today (well, those of us not old enough *cough*). If I were to
> > reinvent Unix today, I'd choose better names for these things. But
> > think about it, if the above line were instead written like this:
> >
> > diskUsage $HOME | sort --reverse --numeric | pager
> >
> > it would make so much more sense, wouldn't it? So the "nonsensical"
> > part is really just in the poor choice of naming, not an inherent
> > weakness of the interface.
> >
> 
> I'd still argue that it is. It is how it is, and it's completely
> prohibitive to casual or new users.

So? Does everything have to be targeted at new/casual users? Can't
experienced users have stuff that's made for them? Who ever said
command lines are still intended for everybody? Keep in mind, a
programmer is NOT a casual or new user. But in any case, please don't
mistake "Windows vs Linux" as a "one size fits all" topic, because you
seem to be steering things that way.

Rant: Seems to be a big trend in computing these days. Everything is all
about catering to Average Joe Numbskull and Little Miss Facebook, and to
hell anyone who has more advanced experience and needs where "usable
by anyone's grandmother" is the least of their concerns.

Average Joes need their tools, sure, but so do the rest of us.

You do realize that in the time you've spent taking a friendly OS
discussion and single-handedly trying[1] to turn it into yet another
ill-informed OS flamewar (congratulations, btw) you could have already
learned quite a bit about using a unix command line?

[1] Don't deny it. Your intent to bait was obvious a few posts back, but
due to your good standing here I've been giving you a chance.


> [...]
> > > I had a video card driver problem the other day. The bundled
> > > auto-update app failed, and totally broke my computer.
> > > I had to download kernel source, and run some scripts to compile
> > > some
> > sort
> > > of shim that made the video driver compatible with my kernel to
> > > get it working again... absolutely astounding.
> >
> > Uh... you do realize that this is because Linux actually *lets* you
> > fix things? If something like this happened on Windows, the only
> > real solution is to nuke the system from orbit and start from
> > ground zero again (i.e. reinstall). One can hardly expect that
> > repairing a broken car engine should require no thought.
> >
> 
> Nothing like that has EVER happened to me in a few decades of windows.
> In my experience asa linux user, these sort of problems are a daily
> chore.
> 

I've had stuff like that happen on Windows. Not on my own system within
the last few years, but over "a few decades"? Oh hell yea.

OTOH, I don't think I've had such trouble with Linux in at least as
long. I think 2002 was probably the last time.


> Speaking of which, I managed to totally break my computer last night /
> > this morning too.
> 
> 
> No shit. Should I be surprised? ;)
> 
[...]
> 
> > but the hardy little thing just kept going. It was
> > causing subtle breakages like my printer mysteriously failing to
> > work, and when I finally figured out the problem, I downloaded a
> > new kernel and recompiled it.
> 
> 
> ... speechless ;)
> 
> 
[...]
> 
> I rest my case.
> 

Ok, now I know you're just trying to troll. But I've never seen you
troll before so you should know better.

He made it perfectly clear he had been messing around with his own
internals. *Plus* you know perfectly well messing around with Windows
internals can also lead to problems requiring expert-skill recovery
techniques, so really, you *know* that you know better, so cut the
shit.

Yes, Linux sucks. And guess what? So does Windows. I use both, by
choice. End of story.

> 
> I think the main difference is quality-assurance. Windows software is
> more likely to be released only after it's reasonably proven that it
> works.
> 

Like Debian.

And if you bring up some broken Linux distro, I'll bring up WinME, and
then we'll all have added a whole lot of usefulness to the discussion ;)


> I'm not a mechanic, and I shouldn't have to be to drive a car.
> 

Strawman, in too many ways to be worth listing.

Re: Qt Creator and D

[Joseph Rushton Wakeling]

On 18/09/13 16:49, Joseph Rushton Wakeling wrote:

I'm just wondering how many people would be interested in seeing better D
support in this IDE, and how many people have more experience or can offer
insight into how to proceed.


Just as an update -- I asked around on the Qt Forums and Qt Creator mailing 
list.  It looks like (i) for better indentation/syntax support, we'd need a 
parser (DCD, I guess?); (ii) there's a Python plugin in the latest release, 
which we could model a D plugin on.


I do not have a huge amount of time to dedicate to this, but I'll keep following 
up as I can.  Any help appreciated :-)

Re: Qt Creator and D

[Arjan]

This I actually disagree with that on a couple of levels.

First, "edit and continue" is really only a absolute necessity for the  
AAA
game industry (and some others).. since the ability to make changes  
without
having to re-navigate the game to the area being effected is a crucial  
time

saver.


Surely not only for games and some others, I is really a very useful  
feature of MSVC debugging, which will save lots of precious time once one  
starts using it. I can attest to that. Another useful feature is the ease  
in which one might adjust the instruction pointer. I'm using those two  
quite often in concert, which is really a time(and ass)saver.


For D to gain more traction (at least on the windows platforms) it has to  
have these kind of features.

So I'm really happy to see what is happening twith visual-D!


It's certainly missed in my professional environment, but even outside
that, it's still super handy and saves a lot of time. Particularly if you
are in the habit of using it.


+100

Linux can also be very pretty and feature-rich, and, as a geek, I like  
the

available choice in DEs Linux offers rather than being stuck with the
sometimes unsavory "advancements" Windows makes in their design (i'm
looking at you, Windows 8).


Well you could give this a try: http://windows.kde.org/

I still think the biggest problem by far is that only an expert can fix  
it

when anything goes wrong. And things *always* go wrong. It might seem
trivial if you love computer OS's at the command line and text file  
level,

but I think to most users it just appears to be unstable and tedious.
It's getting better. I want it to succeed... I really do.


Although I'm a long time FreeBSD/Linux and KDE user (my primairy OS's) I  
have to agree. There is a reason for the rise of Apple products. Most  
heard non techies comment: "It just works".

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 21 Sep 2013 00:41:39 +0200
"Brian Schott"  wrote:
> 
> I hope you've heard of OCRemix.org. Tons of remixes of classic 
> video game music.
> 

Yes. There's a lot of junk (lots and lots of amateur "techno" remixes),
but some real gems, too.

DJ Pretzel is fantastic.

Re: [OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Sat, 21 Sep 2013 03:29:59 +0200
"Adam D. Ruppe"  wrote:

> On Friday, 20 September 2013 at 19:17:45 UTC, H. S. Teoh wrote:
> > I dunno, I find that my good memories of those old games are 
> > quite tainted by nostalgia.
> 
> True in some cases, but in others I find myself able to 
> appreciate them even more now. But I avoid the taint by playing 
> them again every few years :)
> 

I agree. I don't really get when people say that older games are just
nostalgia. I mean, I'm sure it is for some people, but I genuinely do
like a lot of those other games even when I actually go back and replay
them (not *all* of course).

Yea, there are occasionally areas where those older games are rough
around the edges by today's standards. Ex: The mouse handling in
Lemmings 3 is really awkward, and save systems weren't always good in
the rare cases they existed at all. But most of these issues are either:

A. Obviated by save states

or B. Easier to put up with than extremely *inane* non-skippable
cutscenes (*cough*Assassin's Creed, Shift 2, and the original
non-blood-dragon FarCry 3*cough*), endless company logos, patronizing
tutorials, endless chatter, inability to use keyboard/mouse for FPSes
on systems with *actual USB ports* (ie every console FPS except CS:GO),
bad framerates *despite* being on hardware several orders of magnitude
more powerful (16-bit systems ran at 30 fps, there's *no* excuse for
bad framerates anymore - I'm looking at you Sonic. If you're having
framerate difficulties then quit being such graphics whores and tone
down all the effects and poly counts for godssakes, you're not
targeting 1991 hardware, you can make things run at least *that* well),
and all the other shit from so many modern games.

But back to the topic: I admit there are a few "retro" games I've
played and enjoyed S much over the years that I've started to just 
get tired of (like the NES Marios), but more often than not my reaction
isn't disappointment of "Ehh, I remember it being better" but
frequently one of these:

A. It's been too long since I've played this. It's really nice to get
back to games where you have to actually *think* and/or *try*. Man I
like this game.

B. Hmmm, I wasn't into this at the time, but all of a sudden it all
just "clicks" and I "get it" now. Sweet!

C. I never played/heard of this at the time, and that's a shame because
this is fantastic! (Ex: I'm currently going through a fan translation
of Monster World 4 on Genesis.)

Of course there *are* plenty of duds on those old systems, but that's
true of modern systems, too: Last Of Us[1], anyone? No thanks. God no.

However, all that said, there *is* a lot of modern stuff I like, too.
Just *some* of them off the top of my head:

- Rayman Origins/Legends
- Splinter Cell 1-3 (4's not terrible either, haven't played 5 or 6)
- 3D Dot Game Heroes
- Forza/Gran Turismo/Need for Speed: Shift 1
- Sonic Racing Transformed
- Sonic 4/Generations
- Limbo
- Hatsune Miku: Project Diva F
- BioShock (once you get past the completely worthless first ~20-30min)
- Portal 1 and 2
- Disgaea
- From Dust
- Kirby's Epic Yarn
- New Mario
- Kororinpa
- Pikmin
- Wii Sports Resort (believe it or not)
- Angry Birds in Space (believe it or not)
- Adventures of Big and Tiny (or something like that)
- Braid

So I'm not really a "new games" hater so much as an "idiotic bullcrap"
hater. There *are* good games being made; it's just there are also some
very irritating trends: For example, a *lot* of the modern AAA games
that are actually good, are complete and total shit for the first 30-60
minutes - *then* they become worthwhile. It's as if they're *trying* to
make their games leave a bad first impression.

Wanna see a *good* first impression? Play "Castlevania: Symphony of the
Night". But a lot of AAA devs take what leads to good first impressions
and do exactly the opposite. (BTW: No personal offense intended, Manu.
I don't know how long you've been there, but I actually love the first
two Max Paynes. I honestly do.)

[1] Last Of Us  Ie "Lets
make a game about wandering from one empty, pointless room to the next,
to the next, to the next, while seeing how much inane whining you can
tolerate from the NPCs, and after every so many rooms of non-gameplay
force people to watch parts of a generic zombie movie with the only
distinction being a protagonist who's a grown male drama queeen ('What,
she's infected and lied to us?! Whine whine whine, bitch bitch bitch.')
and then watch the whole industry to praise it as an alleged
breakthrough in cinematic gaming" What horseshit. And yes, I've played
it, as well as Assassin's Creed 2 which isn't any better.

Last Of Us isn't even good as a zombie *movie*. It's more like "If JJ
Abrams made a zombie movie". Want a good zombie movie? Try Zombieland
or Sean of the Dead.

Zombies are supernaturally reanimated corpses, not viral
infections. Supernatural: Cool. Virus: Boring.

> > many annoyances that have bee