On Monday, December 24, 2012 06:20:04 Martin Nowak wrote:
> On 12/23/12 03:35, Walter Bright wrote:
> > On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
> >> I think this is a fallacious argument because it concludes that apples
> >> should be
> >> peeled because oranges should.
> >
> > Given, in
Recently Ada 2012 was accepted as ISO standard, and on the good
Lambda the Ultimate blog there is a small thread about it, with
an interesting post:
http://lambda-the-ultimate.org/node/4661#comment-73731
The post makes two simple valid points, worth considering.
Currently in D this code compi
On 12/23/12 03:35, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(float)
On 12/23/12 04:02, Jonathan M Davis wrote:
In addition, in my experience, it's quite rare for classes to have public and
private functions with the same name, meaning that you just don't hit this
problem very often.
Having public and private constructors is a common idiom.
On Monday, 24 December 2012 at 04:19:44 UTC, Jonathan M Davis
wrote:
On Sunday, December 23, 2012 23:13:53 Andrei Alexandrescu wrote:
On 12/23/12 11:08 PM, Jonathan M Davis wrote:
> It's just the WHATSNEW section that makes no sense to
> automate.
Enhancement requests may fill most of the bil
If a type of a variable changes don't you want to *know* the
new type of the variable?
Actually, not at all.
Consider this C++ code as an example:
std::vector foo;
template
void process(T &data) { ... }
int test()
{
auto copy = foo;
process(copy);
if (copy.size() =
On Sunday, December 23, 2012 23:13:53 Andrei Alexandrescu wrote:
> On 12/23/12 11:08 PM, Jonathan M Davis wrote:
> > It's just the WHATSNEW section that makes no sense to automate.
>
> Enhancement requests may fill most of the bill...
They definitely don't fill all of it though. We need to be abl
On 12/23/12 11:08 PM, Jonathan M Davis wrote:
It's just the WHATSNEW section that makes no sense to automate.
Enhancement requests may fill most of the bill...
Andrei
On Monday, December 24, 2012 05:04:24 Maxim Fomin wrote:
> Why not enforce github pulls to provide updates to changelog?
Because then you get merge conflicts galore.
It makes a _lot_ of sense to automate the bugs section of the changelog. Worst
case, it's not all that hard to write a program to
On Sunday, December 23, 2012 22:48:47 Andrei Alexandrescu wrote:
> On 12/23/12 10:35 PM, Jonathan M Davis wrote:
> > So, I fully support doing something to automate the portion of the
> > changelog which contains all of the bugzilla entries, but the portion
> > above that where non-bugzilla stuff i
On Monday, 24 December 2012 at 01:55:04 UTC, Andrei Alexandrescu
wrote:
Hello,
We've discussed this a bit before. It's becoming obvious that
changelog.dd doesn't scale well: it's difficult to keep in
sync, people forget to add bugs to it etc.
How about we abolish changelog.dd in favor of bu
On Monday, 24 December 2012 at 03:48:47 UTC, Andrei Alexandrescu
wrote:
Some other way may as well be introduce entries in bugzilla.
Is adding things that don't belong in bugzilla to bugzilla really
a great idea?
On 12/23/12 10:35 PM, Jonathan M Davis wrote:
So, I fully support doing something to automate the portion of the changelog
which contains all of the bugzilla entries, but the portion above that where
non-bugzilla stuff is entered still needs to be there. We can handle it in some
way other than ch
On Sunday, December 23, 2012 20:55:03 Andrei Alexandrescu wrote:
> Hello,
>
>
> We've discussed this a bit before. It's becoming obvious that
> changelog.dd doesn't scale well: it's difficult to keep in sync, people
> forget to add bugs to it etc.
>
> How about we abolish changelog.dd in favor o
On 12/23/12 9:13 PM, Peter Alexander wrote:
On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic wrote:
You say auto helps with refactoring. I say not using it helps with
catching bugs. It comes down to a question of what you value more,
your time while coding, or your time while debuggi
On Sunday, 23 December 2012 at 21:03:40 UTC, Chris wrote:
There exist some GUI Toolkits for D, however, they are more or
less all based on bindings to native toolkits.
Is anyone working on or are there plans to develop a pure
Swing-like GUI Framework for D? While bindings have the
advantage o
On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic
wrote:
You say auto helps with refactoring. I say not using it helps
with
catching bugs. It comes down to a question of what you value
more,
your time while coding, or your time while debugging.
Or even just reading code, which is w
Hello,
We've discussed this a bit before. It's becoming obvious that
changelog.dd doesn't scale well: it's difficult to keep in sync, people
forget to add bugs to it etc.
How about we abolish changelog.dd in favor of bugzilla queries? There's
a simple rule to follow: all changes should have
On Sunday, December 23, 2012 16:11:02 Walter Bright wrote:
> 6. I'd also throw in getting rid of the "protected" access attribute
> completely, as I've seen debate over that being a useless idea
Really? I'm shocked at that. It's necessary for stuff like NVI if private
functions aren't virtual as
On 12/23/2012 4:03 AM, "Jérôme M. Berger" wrote:
Because C++ *can* hide symbols from other modules with the
anonymous namespace. D has no equivalent.
Everyone here has raised some good points. But this isn't a simple issue, so I
suggest getting together and preparing a DIP. A DIP shoul
On Monday, December 24, 2012 00:12:47 Benjamin Thaut wrote:
> Yes this is it. So should I know go in and change everything back
> to auto?
Feel free to do so.
- Jonathan M Davis
On Sunday, 23 December 2012 at 22:49:16 UTC, Andrei Alexandrescu
wrote:
Is this it?
https://github.com/D-Programming-Language/druntime/pull/368
As a general rule, there should be justification for cases
where auto is not to be used. Auto should be reached for by
default.
Andrei
Yes this
On 12/23/12 4:54 PM, Benjamin Thaut wrote:
I just created my first pull request for druntime and there where
multiple commonets to _not_ use auto. I don't quite understand why it
shouldn't be used in library functions. If it should not be used why is
it in the language in the first place?
Is th
On Sunday, December 23, 2012 23:34:41 Phil Lavoie wrote:
> In this case, I am convinced that there is no use of having the
> "no accessibility but visibility" particularity, because I cannot
> find any reason for it to stay like that (feature/exploit wise).
> On the other hand, I don't work on the
On 12/23/12, Jonathan M Davis wrote:
> It makes refactoring the code much easier and reduces code breakage
> due to type changes.
I don't buy that. If a type of a variable changes don't you want to
*know* the new type of the variable? If between two commits you have:
auto x = z;
and then:
auto
In this case, I am convinced that there is no use of having the
"no accessibility but visibility" particularity, because I cannot
find any reason for it to stay like that (feature/exploit wise).
On the other hand, I don't work on the compiler and I have no
idea of what difficulties in would imp
On Sunday, December 23, 2012 23:21:19 Benjamin Thaut wrote:
> It's always about local variables.
Then I don't agree with Andrej at all. For local variables, in general, I
think that auto should be used unless you actually need to explicitly give the
type. It makes refactoring the code much easie
On Sunday, 23 December 2012 at 22:16:54 UTC, Jonathan M Davis
wrote:
Yeah. I don't know what they were complaining about in the pull
request, but I
think that Andrej has it right. Basically, when declaring the
return type, if
you need type inference, use auto, but if you don't, then put
the e
On Sunday, December 23, 2012 14:16:02 Jonathan M Davis wrote:
> On Sunday, December 23, 2012 23:05:28 Andrej Mitrovic wrote:
> > On 12/23/12, Benjamin Thaut wrote:
> > > I just created my first pull request for druntime and there where
> > > multiple commonets to _not_ use auto. I don't quite unde
On Sunday, December 23, 2012 23:05:28 Andrej Mitrovic wrote:
> On 12/23/12, Benjamin Thaut wrote:
> > I just created my first pull request for druntime and there where
> > multiple commonets to _not_ use auto. I don't quite understand
> > why it shouldn't be used in library functions. If it should
On 12/23/12, Benjamin Thaut wrote:
> I just created my first pull request for druntime and there where
> multiple commonets to _not_ use auto. I don't quite understand
> why it shouldn't be used in library functions. If it should not
> be used why is it in the language in the first place?
>
> Kind
I just created my first pull request for druntime and there where
multiple commonets to _not_ use auto. I don't quite understand
why it shouldn't be used in library functions. If it should not
be used why is it in the language in the first place?
Kind Regards
Benjamin Thaut
I read some comment on D on the need for a "killer application" to boost
popularity.
What about "inline D" in javascript (/php)?
What strikes me is the perfect profile of D. The compiler is fast, and the
resulting code is fast as well. Still, with some few issues (like
documentation), D is re
On Sunday, December 23, 2012 22:12:17 Phil Lavoie wrote:
> > private is _always_ module scope.
>
> Ooops I meant private functions inside a module. I was wondering
> if that would be allowed:
>
> module a;
> public auto aFunc( T )( T t ) { cantSeeMe( t ); }
> private auto canSeeMe( SomeType t ) {
private is _always_ module scope.
Ooops I meant private functions inside a module. I was wondering
if that would be allowed:
module a;
public auto aFunc( T )( T t ) { cantSeeMe( t ); }
private auto canSeeMe( SomeType t ) { ... }
module b;
import a;
alias a.canSeeMe canSeeMe
public auto canSeeM
There exist some GUI Toolkits for D, however, they are more or
less all based on bindings to native toolkits.
Is anyone working on or are there plans to develop a pure
Swing-like GUI Framework for D? While bindings have the advantage
of using native widgets, they tend to lack behind as native
On Sunday, December 23, 2012 21:47:13 Phil Lavoie wrote:
> Ok so it's the feature that allows you to write something like
> myObject.notInClassDeclarationMethod( zeParam );
> Which is awesome.
>
> I'd like to know if there is any functionality provided by having
> private functions/methods being v
On Sunday, December 23, 2012 21:36:34 Phil Lavoie wrote:
> Never mind my last question. Found that it stands for: uniform
> function call syntax. Now I am going to look into what that means
> and how it affects the "no accessibility but visibility" thingy.
It means that any free function can be ca
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for modul
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for mo
Never mind my last question. Found that it stands for: uniform
function call syntax. Now I am going to look into what that means
and how it affects the "no accessibility but visibility" thingy.
I'd like to add that I have programmed with google Go for some
time and moved to D for various reasons. It is true that unused
imports and variables may be a hint that something was done
wrong, or forgotten, and a review might be desirable. I am all
for being warned about this. However, it is a
Am 23.12.2012 14:58, schrieb Jacob Carlborg:
> I think it would be better if there was more space for the Name column and
> let the Description
> column automatically wrap. It's better that the description uses multiple
> rows than the symbol names.
>
I changed the first column from "width: 150
On Sunday, December 23, 2012 18:54:15 Peter Alexander wrote:
> Would it be possible to split the library up and add public
> imports to std.algorithm of the moved symbols?
DIPs 15 and 16 relate to the ability to split up a module into separate
modules within a package with the same name without b
On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
> So the nice thing to have here would be a standardized interface to the
> compiler, or even compiler as a library, with direct data access to this
> kind of information.
The plan is to have a lexer and parser for D in the standard library
Yes, thank you!
Tired apparently, I need to rest...
Am 23.12.2012 14:52, schrieb Jacob Carlborg:
> On 2012-12-22 18:53, Sönke Ludwig wrote:
>
>> - jumps to line numbers on github (which are off because of changes after
>> the release)
>
> Can you lock it to the same hash that the docs are generated from?
>
I've locked it to the v2.060 tag now
On Sunday, 23 December 2012 at 19:43:54 UTC, Shadow_exe wrote:
for(uint y=0; y<10; ++y){
auto m = new Mutex();
writeln(&m);
}
That's the address of the local variable. The object it points to
is somewhere else.
An Object in D is more like an Object* in C++.
Object* o = new O
On 12/23/12, Shadow_exe wrote:
> for(uint y=0; y<10; ++y){
> auto m = new Mutex();
> writeln(&m);
> }
Use writeln(cast(void*)m) to get the address of the object, otherwise
you're writing the address of the reference (which each time refers to
a different object).
for(uint y=0; y<10; ++y){
auto m = new Mutex();
writeln(&m);
}
run:
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
7F66E5A05CF8
As I understand it, all the time return one object
But:
auto m = new Mutex();
wr
On Sunday, 23 December 2012 at 12:20:01 UTC, Tobias Pfaff wrote:
So the nice thing to have here would be a standardized
interface to the
compiler, or even compiler as a library, with direct data
access to this
kind of information.
Yes the concept of what a complier is, how how it is implement
On 12/23/12 12:54 PM, Peter Alexander wrote:
On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu wrote:
I like std.algorithm the way it is.
Andrei
Same here. In my mind it's about generality:
General purpose algor
On Sunday, 23 December 2012 at 16:06:57 UTC, John Colvin wrote:
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei
Alexandrescu wrote:
I like std.algorithm the way it is.
Andrei
Same here. In my mind it's about generality:
General purpose algorithms (sort, partition etc.) belong in
std.alg
dmd ./main.d -debug -profile -w -v -g -cov -gs
// version v2.060
Reproducible.
dmd ./main.d -release -noboundscheck -O
// version v2.060
Irreproducible.
Win 8 x64, dmd x32.
On Sunday, 23 December 2012 at 14:43:25 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 9:08 AM, foobar wrote:
Regarding std.algorithm, the module isn't called - 'classic,
consecrated
algorithms the kind you'll find in a book entitled
"Algorithms"'. It is
simply called 'std.algorithm' and there are
Jonathan M Davis:
(since D1 made the mistake of having opEquals return int),
I think it wasn't a mistake, more like a design choice. In some
cases (especially when there is no inlining) computing and
returning an int is more efficient than converting to bool.
In practice I think the increa
On 12/23/12 9:08 AM, foobar wrote:
Regarding std.algorithm, the module isn't called - 'classic, consecrated
algorithms the kind you'll find in a book entitled "Algorithms"'. It is
simply called 'std.algorithm' and there are many, *many* books on
algorithms. Should this module include concurrent a
On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu
wrote:
On 12/23/12 6:44 AM, foobar wrote:
Using an all encompassing "algorithms" module is also
unhelpful as all
code is essentially an algorithm to accomplish some task. This
is akin
to opening a store called - "A store" or perha
On 2012-12-22 17:15, Andrei Alexandrescu wrote:
Looks great! I think that belongs in an index page (which doesn't exist
yet, though we do define a sitemap http://dlang.org/sitemap.html).
The sitemap is a bit different. The list of symbols could be the index
page or a part of the index page fo
On 2012-12-22 18:53, Sönke Ludwig wrote:
In the latest upload a number of items is addressed:
- vertical margins at the top
- redundant column headers
- +/- signs for the package tree
- jumps to line numbers on github (which are off because of changes after the
release)
- some macro p
On Monday, 14 May 2012 at 02:35:11 UTC, Jonathan M Davis wrote:
On Monday, May 14, 2012 02:53:20 Alex Rønne Petersen wrote:
Hi,
Would anyone be terribly angry if equals_t was deprecated and
later
removed? I sent a patch a while back to add a compare_t type
for
consistency, but the consensus e
On 2012-12-22 18:53, Sönke Ludwig wrote:
- jumps to line numbers on github (which are off because of changes after the
release)
Can you lock it to the same hash that the docs are generated from?
--
/Jacob Carlborg
On 12/23/12 6:44 AM, foobar wrote:
Using an all encompassing "algorithms" module is also unhelpful as all
code is essentially an algorithm to accomplish some task. This is akin
to opening a store called - "A store" or perhaps "A place to sell you
stuff".
That I disagree with a bit. I think it's
On Sunday, 23 December 2012 at 09:54:18 UTC, Shadow_exe wrote:
There is an error, which I can not solve, because I can't
understand why it happens.
If it's not an error, correct me please!
Code:
module main;
import core.thread;
import std.stdio;
import core.memory;
class DerivedThread : Threa
Jonathan M. Davis wrote:
> A lint-like tool is free to point them out for you, and maybe an IDE could
> highlight them, but actually making the compiler consider unused variables to
> be either a warning or an error would be an incredibly bad idea for D - on
> top
> of the fact that it would be
Walter Bright wrote:
> On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
>> Pretty much every time that this issue comes up, people are surprised
>> by the
>> fact that private symbols aren't hidden and pretty much no one wants
>> them to
>> be in overload sets.
>
> This has been discussed before, a
On Saturday, 22 December 2012 at 23:04:47 UTC, Andrei
Alexandrescu wrote:
On 12/22/12 5:10 PM, foobar wrote:
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg
wrote:
On 2012-12-21 18:05, Andrei Alexandrescu wrote:
s/remove/integrate/
s/ugly/awesome/
It's ugly that they are manuall
Am 23.12.2012 10:55, schrieb Philippe Sigaud:
> Very nice-looking docs Sönke!
>
> A minor nitpick: in some modules, the _-prefixed version appears as such (I
> mean, with an underscore
> before the name). See for example:
>
> http://vibed.org/temp/d-programming-language.org/phobos/std/paralleli
On 12/22/2012 9:36 AM, Andrei Alexandrescu wrote:
Good idea. I'm a big fan of moving uninteresting stuff off the top of a page.
Maybe the source does carry some interest though.
More creative ideas is to represent all that information not in normal paragraph
style, but as small print in a band (
There is an error, which I can not solve, because I can't
understand why it happens.
If it's not an error, correct me please!
Code:
module main;
import core.thread;
import std.stdio;
import core.memory;
class DerivedThread : Thread {
this(uint index){
this._index = index;
s
Am 23.12.2012 10:11, schrieb Rob T:
> On Sunday, 23 December 2012 at 07:38:04 UTC, Sönke Ludwig wrote:
>> What I did now was to hide the manually written "Source:" section (which is
>> not in every module) and
>> instead generate a procedural "View source code" button on the top right of
>> the p
On Sunday, 23 December 2012 at 07:38:04 UTC, Sönke Ludwig wrote:
What I did now was to hide the manually written "Source:"
section (which is not in every module) and
instead generate a procedural "View source code" button on the
top right of the page (which should
always be there).
So if you h
Why do you suck his dick? The D project is now historical. As if it was the
D project that was the -problem.
On Sat, 2012-12-22 at 20:32 +0100, Leandro Lucarella wrote:
> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
> > On 12/13/2012 4:17 PM, David Nadlinger wrote:
> >> 1. How much work would it be for the guys at Remedy Games to
> >> convert their
> >> codebase from [] to @()?
> >
>
74 matches
Mail list logo
