On 18.05.2013 00:47, Igor Stepanov wrote:
On Friday, 17 May 2013 at 17:57:54 UTC, Rainer Schuetze wrote:
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO l
On 18.05.2013 00:49, Dmitry Olshansky wrote:
17-May-2013 21:57, Rainer Schuetze пишет:
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO link in always.
And
On Saturday, 18 May 2013 at 02:34:46 UTC, Andrej Mitrovic wrote:
On 5/18/13, Timothee Cour wrote:
S.init should be known at compile time by the spec.
But why is this needed?
It is needed in any place where such object is created due to
default initialization. However if default ctor is CTF
On 5/18/13, Timothee Cour wrote:
> S.init should be known at compile time by the spec.
But why is this needed?
calling the default ctor static this() removes any such illusion.
struct A{
int[]x;
static this(){
x=[1,2,3];
}
}
void main(){
enum a=A.init;
static assert(a is A.init);
}
would work under this proposal.
What would be your alternate proposal that would still allow to initialize
x to [1,2,
When programmer see constructor, he think that it will be
evaluated each time when he create a new object.
This code will seem obvious for any C++ coder.
And this coder will be deceived.
If we'll add default constructor to structs, we'll must safe of
illusion, that constructor is called any tim
>> But there is one trouble.
I don't see the trouble.
struct Foo
> {
> int[] arr;
> this()//can be interpreted at compile time
> {
>arr = new int[3];
>arr[0] = 1;
>arr[1] = 2;
>arr[2] = 3;
> }
> }
> semantically, all new instances of Foo must get se
module fmod;
public immutable int[] fable = [1,2,3];
module mod;
//import fmod;
int foo(int i)
{
pragma(mangle, "_D4fmod5fableyAi") extern immutable int[]
fable;
return fable[i];
}
On Friday, 17 May 2013 at 22:45:01 UTC, Timothee Cour wrote:
Although I agree that having a default constructor would be
convenient, I
think the problem is that S.init should be known at compile
time by the
spec.
Maybe we could support the following syntax, with a static this
instead of
this
And how then I would use these tables if even importing these
modules
then pulls in the data?
without import with pragma(mangle) help. But this dark linker
magic no much better you template solution.
On Friday, 17 May 2013 at 21:06:30 UTC, Diggory wrote:
I think we all understand it's not going to catch every race
condition, or even a given race condition every time, ie. it
can't prove that the code is correct.
What it can do however is prove that code is incorrect. If the
unit test fails
17-May-2013 21:57, Rainer Schuetze пишет:
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO link in always.
And I believe this is a key problem - each function
On Friday, 17 May 2013 at 17:57:54 UTC, Rainer Schuetze wrote:
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use
it?
Thanks for this try, but they DO link in always.
And I believe this is a key pr
Although I agree that having a default constructor would be convenient, I
think the problem is that S.init should be known at compile time by the
spec.
Maybe we could support the following syntax, with a static this instead of
this :
struct S
{
int x=11;
int y = void;
static this()
On 5/17/13, Walter Bright wrote:
> I oppose this. D has a lot of nice features because of the .init property.
> Default constructors wreck that.
Would they? I'm thinking the process would be:
struct S
{
int x;
int y = void;
this() // hypothetical
{
// x would already be
I think we all understand it's not going to catch every race
condition, or even a given race condition every time, ie. it
can't prove that the code is correct.
What it can do however is prove that code is incorrect. If the
unit test fails there is definitely something wrong with the
code, the
On Friday, 17 May 2013 at 10:16:21 UTC, Dmitry Olshansky wrote:
Can you show the code actually - bogus singleton and correct
one?
Here: https://gist.github.com/someboddy/5601276
I thinned down the implementation to a minimum working example.
`enum BREAK_IMPLEMENTATION` at the top of the file d
On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github
with dlang. While we're at it, project
d-programming-language.org should be renamed dlang.org.
This may cause disruption. Thoughts?
Andrei
I suggest renaming the
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO link in always.
And I believe this is a key problem - each function goes into a separate
object but globals ar
On 5/16/13 5:24 PM, luka8088 wrote:
Hello everyone.
Today I ran into a interesting issue. I wrote
auto offset = text1.length - text2.length;
and in case text2 was longer then text1 I got something around 4294967291.
So I opened an issue:
http://d.puremagic.com/issues/show_bug.cgi?id=10093
On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github
with dlang. While we're at it, project
d-programming-language.org should be renamed dlang.org.
This may cause disruption. Thoughts?
Andrei
The URL in the descrip
On Friday, 17 May 2013 at 15:40:40 UTC, Andrei Alexandrescu wrote:
On 5/16/13 8:39 PM, Mehrdad wrote:
On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu
wrote:
I'm thinking we should rename D-programming-language on
github with
dlang. While we're at it, project d-programming-language.o
On 5/16/13 8:39 PM, Mehrdad wrote:
On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github with
dlang. While we're at it, project d-programming-language.org should be
renamed dlang.org.
This may cause disruption. Thoughts
On 12 May 2013 18:29, Calin Grosan wrote:
> On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
>
>> I'm thinking we should rename D-programming-language on github with
>> dlang. While we're at it, project d-programming-language.org should be
>> renamed dlang.org.
>>
>> This may ca
On 5/16/13 9:18 PM, Andrej Mitrovic wrote:
Also please rename the d-programming-language.org *project* into
dlang.org if you can. (the website files)
Probably that's the only thing I'll end up renaming for now.
Andrei
On Fri, 17 May 2013 02:46:31 -0400, Stewart Gordon
wrote:
On 27/04/2013 06:29, Steven Schveighoffer wrote:
Have you considered what this does? Consider a standard [1.0, 2.0]
call:
In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
to allocate the memory and use the
On Fri, 17 May 2013 13:53:20 +0100, Jacob Carlborg wrote:
On 2013-05-17 10:46, Regan Heath wrote:
On Fri, 17 May 2013 08:44:14 +0100, Jacob Carlborg wrote:
.. lots of great things. Can we get all the advice from the article and
these replies onto a D wiki or howto page pls. If someone can
On 2013-05-17 10:46, Regan Heath wrote:
On Fri, 17 May 2013 08:44:14 +0100, Jacob Carlborg wrote:
.. lots of great things. Can we get all the advice from the article and
these replies onto a D wiki or howto page pls. If someone can point me
to where to add it, I can do a rough copy/paste. As
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO link in always.
And I believe this is a key problem - each function goes into a separate
object but globals are always pulled in!
Anyone ever used digits,
On 05/17/2013 11:41 AM, Jonathan M Davis wrote:
We need to do more to optimize Phobos, but given our stance of correctness by
default, we're kind of stuck with string functions taking a performance hit in
a number of common cases simply due to the necessary decoding of code points.
We can do bett
On Friday, 17 May 2013 at 11:26:27 UTC, deadalnix wrote:
On Friday, 17 May 2013 at 10:09:11 UTC, John Colvin wrote:
If naive D code has to be significantly faster than optimised
C for people to not go "D sucks, it's only as fast as python"
then we're pretty much doomed by peoples stupidity.
N
On Friday, 17 May 2013 at 10:09:11 UTC, John Colvin wrote:
If naive D code has to be significantly faster than optimised C
for people to not go "D sucks, it's only as fast as python"
then we're pretty much doomed by peoples stupidity.
No. The whole benefit of D is lost if you have to tweak
ev
17-May-2013 04:57, Idan Arye пишет:
On Thursday, 16 May 2013 at 21:10:52 UTC, Dmitry Olshansky wrote:
16-May-2013 02:21, Idan Arye пишет:
But
I *want* to (almost)cause a race condition here
You can't "cause" a race condition - it's there by definition of code.
What you can cause is a data cor
On Friday, 17 May 2013 at 08:28:38 UTC, Jacob Carlborg wrote:
On 2013-05-16 21:54, Walter Bright wrote:
We should also be aware that while Python code itself is slow,
its
library functions are heavily optimized C code. So, if the
benchmark
consists of calling a Python library function, it'll r
On Thursday, May 16, 2013 12:54:35 Walter Bright wrote:
> On 5/16/2013 12:15 PM, Jonathan M Davis wrote:
> > And if python is faster than
> > D at something, odds are that either the code in question is poorly
> > written or that whatever Phobos functions it's using haven't been
> > properly optimi
On Friday, May 17, 2013 11:15:24 Dicebot wrote:
> On Thursday, 16 May 2013 at 19:15:57 UTC, Jonathan M Davis wrote:
> > 1. In general, if you want to operate on ASCII, and you want
> > your code to be
> > fast, use immutable(ubyte)[], not immutable(char)[]. Obviously,
> > that's not
> > gonig to wo
On Thursday, 16 May 2013 at 19:15:57 UTC, Jonathan M Davis wrote:
1. In general, if you want to operate on ASCII, and you want
your code to be
fast, use immutable(ubyte)[], not immutable(char)[]. Obviously,
that's not
gonig to work in this case, because the function is in
std.string, but maybe
On Thursday, 16 May 2013 at 14:23:22 UTC, nazriel wrote:
Very nice blog post.
Something similar should go into D wiki database so it won't
get lost in "In 80s we had..." topics.
For sure there is a space for improvements in Phobos but such
articles are good start to prevent wave of "D is slo
On Thursday, 16 May 2013 at 13:52:01 UTC, Juan Manuel Cabo wrote:
...
Thanks for the tool, it is a good one. But I was not doing
benchmarks this time, only cared about 2x difference at least, so
"time" was enough :)
On Thursday, 16 May 2013 at 13:48:45 UTC, Juan Manuel Cabo wrote:
On Thursday, 16 May 2013 at 10:35:12 UTC, Dicebot wrote:
Want to bring into discussion people that are not on Google+.
Samuel recently has posted there some simple experiments with
bioinformatics and bad performance of Phobos-bas
On Fri, 17 May 2013 08:44:14 +0100, Jacob Carlborg wrote:
.. lots of great things. Can we get all the advice from the article and
these replies onto a D wiki or howto page pls. If someone can point me to
where to add it, I can do a rough copy/paste. Assuming both authors are
happy with
On Thu, 16 May 2013 23:23:20 +0100, Marco Leise wrote:
Am Thu, 16 May 2013 22:39:16 +0200
schrieb luka8088 :
On 16.5.2013. 22:29, Andrej Mitrovic wrote:
> On Thursday, 16 May 2013 at 20:24:31 UTC, luka8088 wrote:
>> Hello everyone.
>>
>> Today I ran into a interesting issue. I wrote
>>
>> aut
On Thursday, 16 May 2013 at 11:37:14 UTC, bearophile wrote:
Dicebot:
In the first of his posts I don't see -noboundscheck used, and
it compares different algorithms from C++ (a switch) and D (two
nested ifs, that are not optimal).
From my experience if you have some care you are able to write
On 2013-05-16 21:54, Walter Bright wrote:
We should also be aware that while Python code itself is slow, its
library functions are heavily optimized C code. So, if the benchmark
consists of calling a Python library function, it'll run as fast as any
optimized C code.
But someone using Python w
On 2013-05-16 02:37, Walter Bright wrote:
http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122
http://www.reddit.com/r/programming/comments/1eerd9/binding_d_to_c/
https://news.ycombinator.com/newest
It's a good article. I haven't read it completely to the e
45 matches
Mail list logo
