On Tue, 27 Dec 2011 10:35:02 -0800, Sean Cavanaugh
wrote:
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
As a first step, we must make all allocations except stack type-aware,
and leave only the stack to be imprecise.
Couldn't the GC'ing the stack be handled in a similar style to how
On 12/28/11 12:59 AM, Robert Jacques wrote:
I would have thought that the template parameters would be passed to
opDispatch i.e.
obj.opDispatch!("foo",bar,baz)(a,b);
although I don't know how opDispatch would be written to handle such a
call in a generic manner, i.e. I would want to define it a
On Tue, 27 Dec 2011 07:10:14 -0800, Andrei Alexandrescu
wrote:
On 12/27/11 4:32 AM, Peter Alexander wrote:
On 27/12/11 3:05 AM, Andrei Alexandrescu wrote:
On 12/26/11 8:23 PM, Peter Alexander wrote:
I am
not convinced that it can be used seamlessly without some relatively
large changes to t
On 12/28/11 02:52, Timon Gehr wrote:
> On 12/28/2011 02:31 AM, Artur Skawina wrote:
>> So far the compiler isn't really helping:
>>
>>> Error: constraint IsPow2 is not constant or does not evaluate to a bool
>>
>> for:
>>
>> ---
>> bool IsPow2(alias N)() {
>> if (!(N& N-1))
>>return 1;
On 12/28/2011 02:31 AM, Artur Skawina wrote:
On 12/28/11 01:29, Jonathan M Davis wrote:
On Tuesday, December 27, 2011 18:59:55 Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { e
On 12/28/11 01:29, Jonathan M Davis wrote:
> On Tuesday, December 27, 2011 18:59:55 Artur Skawina wrote:
>> Is there a way to *force* CTFE? Without using an extra wrapper like this:
>>
>> auto f_impl(alias a)() { / * ... ctfeable ... */ }
>> auto f(alias a)() { enum ctfed = f_impl!a; return ctfed;
...to dlang.org/downloads.html
Andrei
On Tuesday, December 27, 2011 18:59:55 Artur Skawina wrote:
> Is there a way to *force* CTFE? Without using an extra wrapper like this:
>
> auto f_impl(alias a)() { / * ... ctfeable ... */ }
> auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
>
> A "@compile" (or "@ctfe" etc) function at
On Tuesday, December 27, 2011 18:43:14 Andrej Mitrovic wrote:
> Wouldn't it be great if Santa were to give us named arguments this year too?
> :)
Only if he hates me. But I guess that I'm in the minority around here in that
I hate the idea of named arguments.
- Jonathan M Davis
On Tuesday, December 27, 2011 14:07:25 Jakob Ovrum wrote:
> And it is indeed very important. It's one of the few syntax woes
> we have to deal with in D, it would be a shame to let the
> benefits of std.algorithm and any other functional D code be
> overshadowed by the powerful but often excessive
On Tuesday, December 27, 2011 15:41:59 Kagamin wrote:
> On Tuesday, 27 December 2011 at 10:51:25 UTC, Jonathan M Davis
>
> wrote:
> > On the other hand, let's say that on 2 am on October 30th, the
> > time falls back to 1:00 am taking that time zone out of DST.
> > That means that the times of 1 a
On 12/27/11 23:10, Timon Gehr wrote:
> I don't think your example helps your point a lot. Compiling in error
> checking code is a matter of debug/release mode, not a matter of compile-time
> vs runtime. Assertions are always checked in CTFE and always stripped from
> runtime release code.
I r
Timon Gehr:
> What about making => syntax available to named functions as well?
>
> class C{
> private int x;
> int getX() => x;
> }
>
>
> void main(){
> int[] arr;
> bool isOdd(int x) => x&1;
> writeln(arr.filter!isOdd());
> }
>From the Ada 2012 changes:
http://www.di
On 12/27/11, Vladimir Panteleev wrote:
> and temporarily disabling "Windows Sounds"
> works well enough.
Oh man, I forgot those could block. But I had them off anyway. They
were fun back in Win98 days with those cool space themes. They had
awesome intro's. :)
On 27-12-2011 23:18, Timon Gehr wrote:
On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
On 27-12-2011 21:32, Jacob Carlborg wrote:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now t
On 12/27/2011 11:27 PM, Timon Gehr wrote:
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What about making => syntax available to named functions as well?
class C{
private in
On 12/27/2011 05:25 AM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Great! =)
What about making => syntax available to named functions as well?
class C{
private int x;
int getX() => x;
}
void main(
On 12/27/2011 10:53 PM, Alex Rønne Petersen wrote:
On 27-12-2011 21:32, Jacob Carlborg wrote:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now that's very cool. Does it work for non-tem
On 12/27/2011 10:44 PM, Artur Skawina wrote:
On 12/27/11 20:18, so wrote:
On Tue, 27 Dec 2011 21:02:49 +0200, Artur Skawina wrote:
On 12/27/11 19:29, Vladimir Panteleev wrote:
On Tuesday, 27 December 2011 at 18:00:27 UTC, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an
On 27-12-2011 21:32, Jacob Carlborg wrote:
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now that's very cool. Does it work for non-template arguments as well.
Nope. When passing such l
On 12/27/11 20:18, so wrote:
> On Tue, 27 Dec 2011 21:02:49 +0200, Artur Skawina wrote:
>
>> On 12/27/11 19:29, Vladimir Panteleev wrote:
>>> On Tuesday, 27 December 2011 at 18:00:27 UTC, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like this:
On 2011-12-27 15:48:56 +, Andrei Alexandrescu
said:
On 12/27/11 9:27 AM, Michel Fortin wrote:
It can't be a library feature because it requires the compiler to
implicitly add a "ref" to functions parameters when they are of a "ref
struct" type. That's pretty much all it does: add a flag
On Tue, Dec 27, 2011 at 9:25 AM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> The way I see it is, you are a customer (and one who has had enough
> faith to hang around for a while), so your issues should be given
> priority. We can and we should improve quality in the abstract, b
On 12/27/11 2:38 PM, Jacob Carlborg wrote:
On 2011-12-27 07:00, Long Chang wrote:
Lambda very cool!
I hope we can add shared lib support for linux& freebsd in 2012.
On 27 December 2011 12:25, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0b
On 12/27/11 2:38 PM, Walter Bright wrote:
On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
One good realization to make is how less efficient that makes you. You
got used
to that overhead so plentily, you consider it now par for the course.
What takes time is running the unittests, not compi
On 2011-12-27 07:00, Long Chang wrote:
Lambda very cool!
I hope we can add shared lib support for linux& freebsd in 2012.
On 27 December 2011 12:25, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
And Ma
On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:
One good realization to make is how less efficient that makes you. You got used
to that overhead so plentily, you consider it now par for the course.
What takes time is running the unittests, not compiling dmd.
Am 27.12.2011 21:27, schrieb Vladimir Panteleev:
On Tuesday, 27 December 2011 at 20:11:32 UTC, Joshua Reusch wrote:
Am 27.12.2011 20:51, schrieb Vladimir Panteleev:
On Tuesday, 27 December 2011 at 19:46:31 UTC, Joshua Reusch wrote:
Am 27.12.2011 20:35, Vladimir Panteleev wrote:
Halting proble
On 2011-12-27 05:25, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Now that's very cool. Does it work for non-template arguments as well.
--
/Jacob Carlborg
Am 27.12.2011 21:03, schrieb Artur Skawina:
On 12/27/11 20:31, Joshua Reusch wrote:
Am 27.12.2011 18:59, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { enum ctfed = f_impl!a;
On Tuesday, 27 December 2011 at 20:11:32 UTC, Joshua Reusch wrote:
Am 27.12.2011 20:51, schrieb Vladimir Panteleev:
On Tuesday, 27 December 2011 at 19:46:31 UTC, Joshua Reusch
wrote:
Am 27.12.2011 20:35, Vladimir Panteleev wrote:
Halting problem?
Makes an not-stopping pure function really se
On 12/27/11 2:10 PM, Walter Bright wrote:
On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:
Problem is lack of automation (in this case makdepend).
I've used makedepend before. (I even wrote one!) It just never caught on.
It's improved a tone lately, particularly since gcc has built-in supp
On 12/27/2011 12:24 PM, Alex Rønne Petersen wrote:
On 27-12-2011 21:17, Walter Bright wrote:
http://drdobbs.com/blogs/parallel/232301070
Anyone care to do the Reddit honors?
Andrei already did:
http://www.reddit.com/r/programming/comments/nsj7d/native_osx64_codegen_complex_code/
Ships cross
On 2011-12-27 02:30, Peter Alexander wrote:
On 27/12/11 1:14 AM, Robert Jacques wrote:
On Mon, 26 Dec 2011 17:09:02 -0800, Peter Alexander
If the held object has a method with the same name as RefCounted (e.g.
asConst) then how do you call the held object's method instead of
RefCounted's method
On 27-12-2011 21:17, Walter Bright wrote:
http://drdobbs.com/blogs/parallel/232301070
Anyone care to do the Reddit honors?
Andrei already did:
http://www.reddit.com/r/programming/comments/nsj7d/native_osx64_codegen_complex_code/
- Alex
http://drdobbs.com/blogs/parallel/232301070
Anyone care to do the Reddit honors?
Am 27.12.2011 20:51, schrieb Vladimir Panteleev:
On Tuesday, 27 December 2011 at 19:46:31 UTC, Joshua Reusch wrote:
Am 27.12.2011 20:35, Vladimir Panteleev wrote:
Halting problem?
Makes an not-stopping pure function really sense?
No, but you don't know if the user is expecting the function
On 12/27/2011 10:09 AM, Andrei Alexandrescu wrote:
Problem is lack of automation (in this case makdepend).
I've used makedepend before. (I even wrote one!) It just never caught on.
> As usual, I have an
> optimistic view on the help that automation can bring to our project.
All my build scrip
On 12/27/2011 11:50 AM, so wrote:
If C++ or Java (or what have you) had support for string as template parameters,
string lambdas probably would be irreplaceable to many.
|"a % 2"|
|a => a % 2|
Still it is shorter.
I know.
Unfortunately, the C/C++ text preprocessor has left such a bad taste
Am 27.12.2011 19:09, schrieb Andrei Alexandrescu:
On 12/27/11 12:03 PM, Walter Bright wrote:
On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
On 12/27/11 10:50 AM, Trass3r wrote:
But even the dmd source itself has to be rebuilt every time if you
don't
want strange errors and that's C++.
I do
On 12/27/11 20:31, Joshua Reusch wrote:
> Am 27.12.2011 18:59, Artur Skawina wrote:
>> Is there a way to *force* CTFE? Without using an extra wrapper like this:
>>
>> auto f_impl(alias a)() { / * ... ctfeable ... */ }
>> auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
>>
>> A "@compile"
On 2011-12-27 02:09, Peter Alexander wrote:
On 26/12/11 5:25 PM, Andrei Alexandrescu wrote:
(a) All interaction with the held object is done via opDispatch. In fact
opDispatch can be engineered to statically enforce no reference to the
held object escapes.
I have a separate, but very much rela
On Tuesday, 27 December 2011 at 19:46:31 UTC, Joshua Reusch wrote:
Am 27.12.2011 20:35, Vladimir Panteleev wrote:
Halting problem?
Makes an not-stopping pure function really sense?
No, but you don't know if the user is expecting the function to
take a long time to run, or it's stuck due to
On Tue, 27 Dec 2011 20:11:41 +0200, Walter Bright
wrote:
On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:
Imagine how bitter I am that the string lambda syntax didn't catch on!
As I told Andrei last night, I think it was a great experiment. Sure, it
failed, but it was a great idea, tech
On 2011-12-27 00:23, Robert Jacques wrote:
On Mon, 26 Dec 2011 07:43:46 -0800, Jacob Carlborg wrote:
On 2011-12-26 15:52, Andrei Alexandrescu wrote:
On 12/26/11 6:53 AM, Jacob Carlborg wrote:
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup
Am 27.12.2011 20:35, Vladimir Panteleev wrote:
Halting problem?
Makes an not-stopping pure function really sense?
If you evaluate a function creating an infinite loop at compile-time,
you get for sure in this state. Then, the compiler could stop the
evaluation after some time and print an err
On 2011-12-26 21:55, Walter Bright wrote:
On 12/26/2011 3:47 AM, Jacob Carlborg wrote:
It's like when you see code like this (Ruby):
unless !foo
end
Double negation. Code like the snippet above can be really annoying.
In general, variables and conditions should never be labeled with negatio
On Tuesday, 27 December 2011 at 19:31:58 UTC, Joshua Reusch wrote:
more general: is there any reason to not evaluate a pure
function with const arguments always at compile-time ?
Halting problem?
Am 27.12.2011 18:59, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
A "@compile" (or "@ctfe" etc) function attribute would eliminate the
On Tuesday, 27 December 2011 at 19:03:07 UTC, Artur Skawina wrote:
Umm, the point was to *avoid* the extra useless wrapper.
Sorry, I thought you were writing one wrapper per CTFE-able
function.
Hence the "@compile" attribute suggestion, and list selection.
Presently I don't see how your s
On Tuesday, 27 December 2011 at 17:05:59 UTC, Andrej Mitrovic
wrote:
On 12/27/11, Nick Sabalausky wrote:
And segfaults are handled better on linux because linux merely
prints a message to stderr instead of popping up a dialog box
that you, or a
program (one is available on the DustMite wiki) m
On Tue, 27 Dec 2011 21:02:49 +0200, Artur Skawina
wrote:
On 12/27/11 19:29, Vladimir Panteleev wrote:
On Tuesday, 27 December 2011 at 18:00:27 UTC, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like
this:
auto f_impl(alias a)() { / * ... ctfeable ...
On 12/27/11 19:29, Vladimir Panteleev wrote:
> On Tuesday, 27 December 2011 at 18:00:27 UTC, Artur Skawina wrote:
>> Is there a way to *force* CTFE? Without using an extra wrapper like this:
>>
>> auto f_impl(alias a)() { / * ... ctfeable ... */ }
>> auto f(alias a)() { enum ctfed = f_impl!a; retur
On 27-12-2011 19:47, Alex Rønne Petersen wrote:
Hi,
I think it would be useful if we had a standard version identifier that
is defined when no floating point support is enabled (i.e. dmd's
-nofloat switch), say, "NoFloat" or something along the lines of that.
Any input on this before I put it i
Hi,
I think it would be useful if we had a standard version identifier that
is defined when no floating point support is enabled (i.e. dmd's
-nofloat switch), say, "NoFloat" or something along the lines of that.
Any input on this before I put it in Bugzilla?
- Alex
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
As a first step, we must make all allocations except stack type-aware,
and leave only the stack to be imprecise.
Couldn't the GC'ing the stack be handled in a similar style to how the
Windows x64 ABI functions with respect to exception handl
On Tuesday, 27 December 2011 at 18:00:27 UTC, Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper
like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
A "@compile" (or "@ctfe" etc) function attr
Artur Skawina wrote:
Is there a way to *force* CTFE? Without using an extra wrapper like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
A "@compile" (or "@ctfe" etc) function attribute would eliminate the need for
the wrapper
On 12/27/2011 7:21 AM, dsimcha wrote:
On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu wrote:
Imagine how bitter I am that the string lambda syntax didn't catch on!
Andrei
Please tell me they're not going anywhere.
On 12/27/2011 7:11 AM, Andrei Alexandrescu wrote:
Imagine how bitter I am that the string lambda syntax didn't catch on!
As I told Andrei last night, I think it was a great experiment. Sure, it failed,
but it was a great idea, technically sound, and the fact that it worked is a
testament to D
On 12/27/2011 2:51 AM, deadalnix wrote:
Maybe I'll seem bitter, but I do not think this changement was really that
important. This is nice, ok, but we have some other really serious flaw, like
shared not doing what it is supposed to do.
Technically, it is not important at all. It adds zero powe
On 12/27/11 12:03 PM, Walter Bright wrote:
On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
On 12/27/11 10:50 AM, Trass3r wrote:
But even the dmd source itself has to be rebuilt every time if you don't
want strange errors and that's C++.
I don't even know if it's a laughing matter or not.
I
On 12/27/2011 9:40 AM, Andrei Alexandrescu wrote:
On 12/27/11 10:50 AM, Trass3r wrote:
But even the dmd source itself has to be rebuilt every time if you don't
want strange errors and that's C++.
I don't even know if it's a laughing matter or not.
I think it's a makefile matter.
The makefil
On 12/26/2011 11:56 PM, Caligo wrote:
I need to figure out what this is because I can't compile my code anymore, and I
get this:
dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0' failed.
Aborted
Kenji prepared a fix for it, and I'm testing it now.
Is there a way to *force* CTFE? Without using an extra wrapper like this:
auto f_impl(alias a)() { / * ... ctfeable ... */ }
auto f(alias a)() { enum ctfed = f_impl!a; return ctfed; }
A "@compile" (or "@ctfe" etc) function attribute would eliminate the need for
the wrapper...
artur
On 12/27/11 11:37 AM, Artur Skawina wrote:
I want to warn against the paradoxical "I can't get creative use of
feature X working, therefore I'm going back to my old language
where I can't even think of X."
It may seem paradoxical at first, but isn't. That feature X, often
together with Y and Z,
On 12/27/11 10:50 AM, Trass3r wrote:
On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu wrote:
On 12/27/11 9:51 AM, Torarin wrote:
2011/12/27 Joshua Reusch:
$ ./dmd lambda_test
dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *)
&((av)->bins[((1) - 1) *
Wouldn't it be great if Santa were to give us named arguments this year too? :)
> I want to warn against the paradoxical "I can't get creative use of feature X
> working, therefore I'm going back to my old language where I can't even think
> of X."
It may seem paradoxical at first, but isn't. That feature X, often together
with Y and Z, could be one of the main reasons for
I've posted a patch to fix the bug.
https://github.com/D-Programming-Language/dmd/pull/587
Please wait until be merged it.
(But I don't know when it will be done.)
Kenji Hara
2011/12/28 Caligo :
>
>
> On Tue, Dec 27, 2011 at 9:10 AM, Adam D. Ruppe
> wrote:
>>
>> On Tuesday, 27 December 2011 at
Le 27/12/2011 18:03, Peter Alexander a écrit :
On 27/12/11 4:32 PM, deadalnix wrote:
Le 27/12/2011 16:09, Andrei Alexandrescu a écrit :
On 12/27/11 5:27 AM, kenji hara wrote:
I've already posted a dmd patch to fix all of opDispatch problems:
https://github.com/D-Programming-Language/dmd/pull/
Sorry, there was a typo. The actuall full path is:
~/Digital-Mars/phobos/generated/linux/release/32/libphobos2.a
So I changed to command into:
~/Digital-Mars/dmd/src/dmd -I~/Digital-Mars/druntime/import
-I~/Digital-Mars/phobos
-L-L~/Digital-Mars/phobos/generated/linux/release/32 test.d
And the sa
On 12/27/11, Nick Sabalausky wrote:
> And segfaults are handled better on linux because linux merely
> prints a message to stderr instead of popping up a dialog box that you, or a
> program (one is available on the DustMite wiki) must click "Ok" on to
> continue.
I wonder if it would be faster if
"Alex Rønne Petersen" wrote in message
news:jdckl1$1hfb$1...@digitalmars.com...
>
> Or perhaps even better, when we get fully working UFCS:
>
> auto ints = [0, 1, 2, 3, 4, 5].filter(x => x % 2 != 0);
>
That is just beautiful.
"Andrew Wiley" wrote in message
news:mailman.1922.1324972797.24802.digitalmar...@puremagic.com...
>
>Have you tried Dustmite?
>https://github.com/CyberShadow/DustMite
>
>It works excellently for reducing ICE bugs. More Linux friendly than
>Windows because you've got to write some shell scripts, b
ProxyOf rewrites the expression
> obj.foo!(bar, baz)(a, b);
to
obj.opDispatch!("foo").opDispatch!(bar, baz)(a, b)
// opDispatch!("foo").opDispatch generates a temporary member template
for forwarding.
// And it is actually processed as 'eponymous template'.
Thanks.
Kenji Hara
2011/12/28 Andrei
On 27/12/11 4:32 PM, deadalnix wrote:
Le 27/12/2011 16:09, Andrei Alexandrescu a écrit :
On 12/27/11 5:27 AM, kenji hara wrote:
I've already posted a dmd patch to fix all of opDispatch problems:
https://github.com/D-Programming-Language/dmd/pull/280
As far a I understand you pass the whole t
On Tuesday, 27 December 2011 at 16:33:30 UTC, Andrei Alexandrescu
wrote:
On 12/27/11 9:51 AM, Torarin wrote:
2011/12/27 Joshua Reusch:
$ ./dmd lambda_test
dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top ==
(((mbinptr) (((char *)
&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
ma
On 27-12-2011 17:14, deadalnix wrote:
Le 27/12/2011 16:25, Andrei Alexandrescu a écrit :
Again, that's not a justification for the code not working with a
meaningless error message. I want to warn against the paradoxical "I
can't get creative use of feature X working, therefore I'm going back t
Le 27/12/2011 16:04, Andrei Alexandrescu a écrit :
On 12/27/11 5:32 AM, deadalnix wrote:
The first thing that I see looking at the source code is how many null
check you'll find in RefCounted . As the RefCounted struct is useless
without a payload, we should ensure that the payload exists, in al
Le 27/12/2011 16:25, Andrei Alexandrescu a écrit :
Again, that's not a justification for the code not working with a
meaningless error message. I want to warn against the paradoxical "I
can't get creative use of feature X working, therefore I'm going back to
my old language where I can't even th
Le 27/12/2011 16:06, Andrei Alexandrescu a écrit :
On 12/27/11 5:43 AM, deadalnix wrote:
BTW, the plan is to have the same thread that constructed objects to
call their destructors; each thread would have a worklist of garbage
objects to destroy. The list can be reduced during calls to allocatio
On 12/27/11 9:51 AM, Torarin wrote:
2011/12/27 Joshua Reusch:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5
Le 27/12/2011 16:09, Andrei Alexandrescu a écrit :
On 12/27/11 5:27 AM, kenji hara wrote:
I've already posted a dmd patch to fix all of opDispatch problems:
https://github.com/D-Programming-Language/dmd/pull/280
As far a I understand you pass the whole template as a string inside
opDispatch?
On Tue, Dec 27, 2011 at 9:10 AM, Adam D. Ruppe wrote:
> On Tuesday, 27 December 2011 at 08:59:33 UTC, Caligo wrote:
>
>> But, I found the bug!
>>
>
> I'm pretty sure that's the same bug I hit over the weekend,
> but couldn't get isolated.
>
> In my case, it was caused by one of the parameters bein
On 12/27/11 9:34 AM, Peter Alexander wrote:
I don't believe this will work in general when the template parameter
passed in requires name look-up in the local scope.
struct Foo
{
int bar(alias f)() { return f(); }
}
void main()
{
static int fun() { return 1; }
RefCounted!Foo foo;
writeln(foo.
2011/12/27 Joshua Reusch :
> Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
>>
>>
>> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>>
>>
>> Andrei
>
>
> -
> import std.algorithm;
>
> void main() {
> auto arr = [0, 5, 4, 3, 2, 1];
On 12/27/11 9:27 AM, Michel Fortin wrote:
On 2011-12-27 14:57:18 +, Andrei Alexandrescu
said:
I talked a lot about this with Walter and we concluded that the story
with const and immutable goes like this: in a RefCounted!T object, the
T is constant, not the RefCounted. So it would be
RefCou
On 12/27/11 9:21 AM, Joshua Reusch wrote:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
sort!((a, b) =>
On 2011-12-27 14:57:18 +, Andrei Alexandrescu
said:
On 12/27/11 8:21 AM, Michel Fortin wrote:
On 2011-12-27 02:47:50 +, Andrei Alexandrescu
1. "Basic" containers - reference semantics, using classic garbage
collection
2. Reference counted containers - still reference semantics, usin
Am 27.12.2011 02:14, schrieb Robert Jacques:
On Mon, 26 Dec 2011 17:09:02 -0800, Peter Alexander
wrote:
On 26/12/11 5:25 PM, Andrei Alexandrescu wrote:
(a) All interaction with the held object is done via opDispatch. In fact
opDispatch can be engineered to statically enforce no reference to t
On 12/27/11 1:56 AM, Caligo wrote:
At the moment I don't see how anything serious can be done with D. In
the past few weeks, while working on a _toy_ project, I've
encountered several bugs that have caused a lot of problems and
wasted a lot of time. Sorry, but it's just frustrating. it's
gotten
On 27/12/11 3:10 PM, Andrei Alexandrescu wrote:
On 12/27/11 4:32 AM, Peter Alexander wrote:
On 27/12/11 3:05 AM, Andrei Alexandrescu wrote:
On 12/26/11 8:23 PM, Peter Alexander wrote:
I am
not convinced that it can be used seamlessly without some relatively
large changes to the language.
I r
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
sort!((a, b) => a < b)(arr);
}
-
On Tuesday, 27 December 2011 at 15:19:07 UTC, dsimcha wrote:
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei
Alexandrescu wrote:
Imagine how bitter I am that the string lambda syntax didn't
catch on!
Andrei
Please tell me they're not going anywhere. I **really** don't
want to deal wit
On Tuesday, 27 December 2011 at 15:11:25 UTC, Andrei Alexandrescu
wrote:
Imagine how bitter I am that the string lambda syntax didn't
catch on!
Andrei
Please tell me they're not going anywhere. I **really** don't
want to deal with those being deprecated.
On 12/27/11 2:24 AM, Jonathan M Davis wrote:
On Monday, December 26, 2011 20:47:50 Andrei Alexandrescu wrote:
1. "Basic" containers - reference semantics, using classic garbage
collection
2. Reference counted containers - still reference semantics, using
reference counting
3. COW containers -
On 12/27/11 3:35 AM, bearophile wrote:
This program contains wrong syntax because x lacks a type:
void main() {
double delegate(double) f;
f = (x) => x + 1;
}
DMD gives the error messages:
test.d(3): Error: undefined identifier x, did you mean variable f?
test.d(3): Error: cannot i
On Tuesday, 27 December 2011 at 08:59:33 UTC, Caligo wrote:
But, I found the bug!
I'm pretty sure that's the same bug I hit over the weekend,
but couldn't get isolated.
In my case, it was caused by one of the parameters being
of type __error__ which isn't handled in the totym() switch.
On 12/27/11 4:51 AM, deadalnix wrote:
Le 27/12/2011 05:25, Andrei Alexandrescu a écrit :
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
Maybe I'll seem bitter, but I do not think this changement was really
that important. This is nice, o
1 - 100 of 142 matches
Mail list logo
