On Friday, May 25, 2012 15:04:16 Alex Rønne Petersen wrote:
> So I was writing a container class and in some test code, I called
> container.clear(). Reasonable enough, right? Hell, it even compiled!
>
> Turns out, my program completely broke at runtime. Apparently, I'd
> forgotten to implement cl
On 30.05.2012 3:04, Andrei Alexandrescu wrote:
On 5/29/12 3:56 PM, Alex Rønne Petersen wrote:
A mutex can be stored privately.
It can, but that doesn't mean it will.
Any object can be locked on, meaning no
lock is effectively protected or private or... anything.
To paraphrase you, "An obje
On May 29, 2012, at 4:07 PM, Andrei Alexandrescu
wrote:
> On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
>> On 30-05-2012 00:45, Andrei Alexandrescu wrote:
>>> On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
> On 5/29/12 1:37 AM, deadalnix
On 30.05.2012 3:02, Andrei Alexandrescu wrote:
On 5/29/12 3:06 PM, Dmitry Olshansky wrote:
Again strictly speaking I'm of an opinion that having mutex together
with object guarded by it is at least better then 2 separate entities
bound together by virtue of code comments :)
Absolutely. I hope
On Wednesday, May 30, 2012 07:47:22 Katayama Hirofumi MZ wrote:
> Look this source:
> http://codepad.org/QXAeG2aJ
>
> The content of RbArray won't be released at the moment of
> deleting an RbArray.
>
> Why?
It's probably only releasing the memory for RbArray and not what it refers to.
m_object
On Wednesday, 30 May 2012 at 02:18:58 UTC, darkstalker wrote:
Is there an OAuth library for D?
I have one... but last time I tried it for twitter, it didn't
work. (But it does work for LinkedIn and a few others. WTF.)
http://arsdnet.net/dcode/oauth.d
It needs some modules from my other page t
Is there an OAuth library for D? I'm interested in writing
twitter stuff, but haven't found an OAuth library (or even better
a twitter one, but I can write that myself).
On 2012-05-29 23:22:38 +, Alex Rønne Petersen said:
Possibly. I haven't thought that through, but I think that that could
work. In fact, it would probably be a good way to ensure safety
statically, since a synchronized class tells its user "I take care of
synchronization".
More or less.
Just a general note: going the "make a special case for two
comparisons" route won't work if, for example, someone decides to
use a lambda for comparing pointers.
On 30-05-2012 01:22, Andrei Alexandrescu wrote:
On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate on an implicit, hidden, global mutex. You can't screw
On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate on an implicit, hidden, global mutex. You can't screw up with
that.
I think there's quite some discon
On 30-05-2012 01:07, Andrei Alexandrescu wrote:
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that
On 30-05-2012 01:10, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
But mutexes allow proper encapsulation by hiding the mutex resource. As
I've proven in the very OP of this thread, both druntime and phobos
suffer from the anti-pattern that is locking on
On 30-05-2012 01:10, Andrei Alexandrescu wrote:
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate on an implicit, hidden, global mutex. You can't screw up with
that.
I think there's quite some disconnect here. If there's any anti-pattern
in this d
On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
Synchronized blocks are good because they
operate on an implicit, hidden, global mutex. You can't screw up with that.
I think there's quite some disconnect here. If there's any anti-pattern
in this discussion, it's operating on an implicit, hidde
On Wednesday, May 30, 2012 01:02:53 Alex Rønne Petersen wrote:
> But mutexes allow proper encapsulation by hiding the mutex resource. As
> I've proven in the very OP of this thread, both druntime and phobos
> suffer from the anti-pattern that is locking on a public resource when
> you shouldn't. Th
On 30-05-2012 00:35, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 00:01:49 Alex Rønne Petersen wrote:
Besides, it seems to me that D can't quite make up its mind. We have TLS
by default, and we encourage message-passing (through a library
mechanism), and then we have the synchronized state
On 5/29/12 3:56 PM, Alex Rønne Petersen wrote:
A mutex can be stored privately.
It can, but that doesn't mean it will.
Any object can be locked on, meaning no
lock is effectively protected or private or... anything.
To paraphrase you, "An object can be stored privately".
It encourages
sha
On 5/29/12 3:58 PM, Alex Rønne Petersen wrote:
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:56 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:38, Andrei Alexandrescu wrote:
On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
Generalized object monitors is the worst idea in programming language
and virtual machine design, ever.
On 5/29/12 3:06 PM, Dmitry Olshansky wrote:
On 30.05.2012 1:41, Andrei Alexandrescu wrote:
If anything I'd rather re-implement the whole v-table infrastructure via
mixins, templates & friends.
Could you please elaborate how that would help multithreading?
It's unrelated to "ease multithread
On 30-05-2012 00:45, Andrei Alexandrescu wrote:
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we u
On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should proba
On 30-05-2012 00:50, Andrei Alexandrescu wrote:
On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision. It is
dea
On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should proba
On 30-05-2012 00:35, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 21:42:29 Alex Rønne Petersen wrote:
Hi,
Is it by design that Ddoc does not emit documentation for manifest
constants, or is it a bug? I'd really like to have documentation for
some public manifest constants in my code, and I
On 5/29/12 2:59 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision. It is
deadlock prone, it is liquid lock prone, it cause an
On 5/29/12 2:56 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:38, Andrei Alexandrescu wrote:
On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
Generalized object monitors is the worst idea in programming language
and virtual machine design, ever.
I think that's an exaggeration. Care to elabora
On 5/29/12 2:57 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecat
On 5/29/12, Don Clugston wrote:
> Oh yeah. Orders of magnitude, easily.
Does this also imply speedups for static foreach loops? I've got quite
a few of those and they seem to slow down compilation a bit. I've had
a funny error message once saying there's an error on line ~50_000 in
a 1000-line mo
Walter Bright:
tl,dr: CTFE started out as a glorified constant folder, not an
interpreter. An interpreter needs a different design.
And I presume a basic JITting interpreter for CTFE (like one in
LDC2 using existing LLVM JIT tools) needs yet another design.
Bye,
bearophile
On Wednesday, May 30, 2012 00:01:49 Alex Rønne Petersen wrote:
> Besides, it seems to me that D can't quite make up its mind. We have TLS
> by default, and we encourage message-passing (through a library
> mechanism), and then we have the synchronized statement and attribute.
> It just seems so inc
On Tuesday, May 29, 2012 21:42:29 Alex Rønne Petersen wrote:
> Hi,
>
> Is it by design that Ddoc does not emit documentation for manifest
> constants, or is it a bug? I'd really like to have documentation for
> some public manifest constants in my code, and I can't really think of a
> reason why D
On 30.05.2012 1:48, Andrei Alexandrescu wrote:
I know. If anything it's hardly a good excuse, it should have been
revisited once TLS was introduced. It still can be now.
Don't be hatin'. You'd appreciate the matter considerably more after you
defined your own language and had its users yell at
On 30.05.2012 1:41, Andrei Alexandrescu wrote:
If anything I'd rather re-implement the whole v-table infrastructure via
mixins, templates & friends.
Could you please elaborate how that would help multithreading?
It's unrelated to "ease multithreading part strictly speaking.
My observation is
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and yet w
On 5/29/2012 7:20 AM, Michel Fortin wrote:
Wouldn't it be possible to just catch the case where you compare two pointers
not assigned from the same memory block and issue an error?
Here's an idea: make each CTFE pointer some kind of struct with a pointer to the
memory block and an offset. When c
On 29-05-2012 23:31, Andrei Alexandrescu wrote:
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision. It is
deadlock prone, it is liquid lock prone, it cause an overhead on any
object, and even worse, it is u
On 5/29/2012 6:29 AM, Don Clugston wrote:
I think that's a no-go.
Implementation-specific behaviour at runtime is bad enough, but at compile time,
it's truly horrible. Consider that any change to unrelated code can change the
results. Something that makes it really terrible is that the same funct
On 29-05-2012 23:38, Andrei Alexandrescu wrote:
On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
Generalized object monitors is the worst idea in programming language
and virtual machine design, ever.
I think that's an exaggeration. Care to elaborate a bit?
Andrei
1) You waste an entire word
On 5/29/2012 8:06 AM, Manu wrote:
On 29 May 2012 15:52, Don Clugston mailto:d...@nospam.com>>
wrote:
On 29/05/12 12:25, Manu wrote:
Is there any way to improve it?
Oh yeah. Orders of magnitude, easily. The slowness is not in any way
inherent to CTFE. The experience will b
On 29-05-2012 23:33, Andrei Alexandrescu wrote:
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
core.sync.mute
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and yet we adopted
it anyway... blergh.
That is what I
On 5/29/12 2:50 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:41, Andrei Alexandrescu wrote:
On 5/29/12 5:29 AM, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by
default.
Looks like we have 'oh my god, what were they thinking' moment here.
The synch
On 29-05-2012 23:41, Andrei Alexandrescu wrote:
On 5/29/12 5:29 AM, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by
default.
Looks like we have 'oh my god, what were they thinking' moment here.
The synchronized class feature was copied by Walter from
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and yet we adopted
it anyway... blergh.
That is what I was about to say. No point of doing D if it is t
On 5/29/12 12:41 PM, Dmitry Olshansky wrote:
On 29.05.2012 17:59, Jacob Carlborg wrote:
On 2012-05-29 14:29, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by
default.
Looks like we have 'oh my god, what were they thinking' moment here.
If anything I'd
On 5/29/12 5:29 AM, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by default.
Looks like we have 'oh my god, what were they thinking' moment here.
The synchronized class feature was copied by Walter from Java while he
at the time had only little unders
On 5/29/12 5:26 AM, Alex Rønne Petersen wrote:
Generalized object monitors is the worst idea in programming language
and virtual machine design, ever.
I think that's an exaggeration. Care to elaborate a bit?
Andrei
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
On 5/29/12 1:32 AM, deadalnix wrote:
I already did some comment about this.
Making any object synchronization is a very bad design decision. It is
deadlock prone, it is liquid lock prone, it cause an overhead on any
object, and even worse, it is useless most of the time as D promote
thread local
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and yet we adopted
it anyway... blergh.
That is what I was about to say. No point of doing D if it is to repeat
previously done errors.
So what is the
On Tue, May 29, 2012 at 2:52 PM, Don Clugston wrote:
>> Is there any way to improve it?
>
>
> Oh yeah. Orders of magnitude, easily.
!
>The slowness is not in any way
> inherent to CTFE. The experience will be completely different, once I have
> some time to work on it -- I know exactly how to d
Hi,
Is it by design that Ddoc does not emit documentation for manifest
constants, or is it a bug? I'd really like to have documentation for
some public manifest constants in my code, and I can't really think of a
reason why Ddoc shouldn't handle them.
--
Alex Rønne Petersen
a...@lycus.org
ht
On 29.05.2012 17:59, Jacob Carlborg wrote:
On 2012-05-29 14:29, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by
default.
Looks like we have 'oh my god, what were they thinking' moment here.
If anything I'd rather re-implement the whole v-table infrastr
Le 29/05/2012 18:56, Alex Rønne Petersen a écrit :
On 29-05-2012 17:52, deadalnix wrote:
Le 29/05/2012 14:26, Alex Rønne Petersen a écrit :
shared isn't working properly ATM, so anyway, things will have to
change
in regard of shared memory support in the language.
And it never will. ;)
It
On Tuesday, 29 May 2012 at 17:35:12 UTC, Michel Fortin wrote:
On 2012-05-29 15:09:00 +, Artur Skawina
said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
if (da_is_a_slice_of_a())
still_inside_a();
On 29.05.2012 21:04, Andrej Mitrovic wrote:
On 5/29/12, Dmitry Olshansky wrote:
I'm reiterating prior info on the subject and provide some motivating
examples. For those convinced of necessity of virtual function templates
already - skip to the bottom ;)
I've run into an issue like this, curr
On 29-05-2012 19:37, Jess wrote:
On Tuesday, 29 May 2012 at 17:01:01 UTC, Alex Rønne Petersen wrote:
druntime is the low-level runtime library of D. This discussion is about
high-level class design.
I should also add that the reason I started this thread was to prevent
common locking error
On Tue, May 29, 2012 at 9:47 PM, Tobias Pankrath wrote:
> On Tuesday, 29 May 2012 at 16:32:17 UTC, Gor Gyolchanyan wrote:
>
>> On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath > >wrote:
>>
>>
>>
>> Going this path means that you have to turn the compiler into a full
>>> build
>>> system. That fin
On Tuesday, 29 May 2012 at 16:32:17 UTC, Gor Gyolchanyan wrote:
On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath
wrote:
Going this path means that you have to turn the compiler into
a full build
system. That finds the right tools in the path, gives good
error messages
if they are absent, th
On 2012-05-29 15:09:00 +, Artur Skawina said:
int a[1024];
int[] da = a[0..1024];
if (whatever)
da = da[3..14];
if (something_else)
da = [42] ~ da;
// etc
if (da_is_a_slice_of_a())
still_inside_a();
How do you implement da_is_a_slice_of_a()?
Indeed,
On Tuesday, 29 May 2012 at 17:01:01 UTC, Alex Rønne Petersen
wrote:
druntime is the low-level runtime library of D. This
discussion is about
high-level class design.
I should also add that the reason I started this thread was to
prevent common locking errors induced by the anti-patterns
>
>
> Alright, well I've got a case of beer with your name on it if you can pull
> it off! ;)
>
+1. I too am waiting for CTFE improvements. I am working on a DSL and with
the present limitations, it is impractically slow and memory consuming
while compiling.
On Mon, May 28, 2012 at 11:42 PM, John Belmonte wrote:
> Fair enough. I did notice the following in the markdown PEG though which
> could benefit from first class patterns:
>
>
> # Parsers for different kinds of block-level HTML content.
> # This is repetitive due to constraints of PEG grammar.
>
On 5/29/12, Dmitry Olshansky wrote:
> I'm reiterating prior info on the subject and provide some motivating
> examples. For those convinced of necessity of virtual function templates
> already - skip to the bottom ;)
I've run into an issue like this, currently I use this sort of workaround:
clas
On 29-05-2012 18:57, Alex Rønne Petersen wrote:
On 29-05-2012 18:41, Jess wrote:
On Monday, 28 May 2012 at 23:55:04 UTC, Alex Rønne Petersen wrote:
On 29-05-2012 01:46, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 01:38:25 Alex Rønne Petersen wrote:
I should probably add that Java learned
On 29-05-2012 18:41, Jess wrote:
On Monday, 28 May 2012 at 23:55:04 UTC, Alex Rønne Petersen wrote:
On 29-05-2012 01:46, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 01:38:25 Alex Rønne Petersen wrote:
I should probably add that Java learned it long ago, and yet we adopted
it anyway... ble
On 29-05-2012 17:52, deadalnix wrote:
Le 29/05/2012 14:26, Alex Rønne Petersen a écrit :
shared isn't working properly ATM, so anyway, things will have to change
in regard of shared memory support in the language.
And it never will. ;)
It has been successful done in other languages and has
On May 24, 2012, at 11:50 PM, Jacob Carlborg wrote:
> On 2012-05-24 21:33, Sean Kelly wrote:
>
>> This is a good point. OutOfMemory conditions aside, the only time I'd want
>> to recover from an Error condition was at the point the event occurred, not
>> somewhere up the stack.
>
> You never
On Monday, 28 May 2012 at 23:55:04 UTC, Alex Rønne Petersen
wrote:
On 29-05-2012 01:46, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 01:38:25 Alex Rønne Petersen wrote:
I should probably add that Java learned it long ago, and yet
we adopted
it anyway... blergh.
The "lesson learned" from
On Tue, May 29, 2012 at 4:02 PM, Tobias Pankrath wrote:
> Going this path means that you have to turn the compiler into a full build
> system. That finds the right tools in the path, gives good error messages
> if they are absent, that caches results etc.
>
>
... which is precisely what we need t
Le 29/05/2012 14:26, Alex Rønne Petersen a écrit :
shared isn't working properly ATM, so anyway, things will have to change
in regard of shared memory support in the language.
And it never will. ;)
It has been successful done in other languages and has proven itself
useful. This is a diffi
On Tue, May 29, 2012 at 3:59 PM, Dmitry Olshansky wrote:
> I'm reiterating prior info on the subject and provide some motivating
> examples. For those convinced of necessity of virtual function templates
> already - skip to the bottom ;)
>
> Ultimately template is a way to use the same source code
Le 29/05/2012 14:26, Alex Rønne Petersen a écrit :
On 29-05-2012 14:19, Dmitry Olshansky wrote:
On 29.05.2012 16:07, Regan Heath wrote:
According to the docs here:
http://dlang.org/class.html#synchronized-functions
A synchronized function locks "this" and as "this" is exposed
publicly... In t
On 05/29/12 16:20, Michel Fortin wrote:
> On 2012-05-29 13:29:35 +, Don Clugston said:
>
>> On 27/05/12 02:45, Walter Bright wrote:
>>> You could implement it as simply comparing the addresses - you'd be no
>>> worse off than C is, and you would get the correct answer for pointers
>>> both in
On 2012-05-29 14:37, Manu wrote:
That's interesting. I can probably give that a shot.
So you think that's a bigger cost than the CTFE code that generates the
strings?
I don't know. I just did a test with Derelict that needed to be
compatible with D1 and D2 and therefore used string mixins for
On 29 May 2012 15:52, Don Clugston wrote:
> On 29/05/12 12:25, Manu wrote:
>
>> Is there any way to improve it?
>
>
> Oh yeah. Orders of magnitude, easily. The slowness is not in any way
> inherent to CTFE. The experience will be completely different, once I have
> some time to work on it -- I kn
On 2012-05-29 13:29:35 +, Don Clugston said:
On 27/05/12 02:45, Walter Bright wrote:
You could implement it as simply comparing the addresses - you'd be no
worse off than C is, and you would get the correct answer for pointers
both in and out of the array without needing special cases.
I
On 2012-05-29 14:29, Dmitry Olshansky wrote:
Agreed, awfuly crippled design for a language with Thread-local by default.
Looks like we have 'oh my god, what were they thinking' moment here.
If anything I'd rather re-implement the whole v-table infrastructure via
mixins, templates & friends.
I'
You can actually set timeouts using the get function by providing the
HTTP instance as a second parameter to get() e.g.:
auto client = HTTP();
client.dataTimeout = dur!"seconds"(10);
auto data = get!(HTTP,ubyte)("www.dlang.org", client);
/Jonas
Good to know, thanks.
I used the chance to
On 27/05/12 02:45, Walter Bright wrote:
On 5/26/2012 3:59 AM, Don wrote:
Yes, that's what happens now. But that doesn't help the programmer.
If it is inside, no problem, the expression is true. But if it is not
inside,
the expression is not false -- it's a compile-time error.
Ok, I understand
On 29/05/12 12:25, Manu wrote:
I've been trying to work out why my compile times have gone to hell
recently.
I have a lib, it takes 3.5 seconds to compile.
I add one CTFE heavy module, it's not huge, certainly much smaller than
the rest of the app, and it blows out to 18 seconds. I've done some
On 29 May 2012 15:10, Jacob Carlborg wrote:
> On 2012-05-29 12:25, Manu wrote:
>
>> I've been trying to work out why my compile times have gone to hell
>> recently.
>>
>> I have a lib, it takes 3.5 seconds to compile.
>> I add one CTFE heavy module, it's not huge, certainly much smaller than
>> t
On 29.05.2012 16:26, Alex Rønne Petersen wrote:
On 29-05-2012 14:19, Dmitry Olshansky wrote:
On 29.05.2012 16:07, Regan Heath wrote:
According to the docs here:
http://dlang.org/class.html#synchronized-functions
A synchronized function locks "this" and as "this" is exposed
publicly... In the
On 29-05-2012 14:19, Dmitry Olshansky wrote:
On 29.05.2012 16:07, Regan Heath wrote:
According to the docs here:
http://dlang.org/class.html#synchronized-functions
A synchronized function locks "this" and as "this" is exposed
publicly... In the following code the "lock" statement and "synchron
On 29-05-2012 10:37, deadalnix wrote:
Le 29/05/2012 01:35, Alex Rønne Petersen a écrit :
On 29-05-2012 01:24, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 01:11:49 Alex Rønne Petersen wrote:
I have no idea how synchronized classes work; they are not a documented
feature of the language. We
On 29-05-2012 14:07, Regan Heath wrote:
On Tue, 29 May 2012 01:08:59 +0100, Jonathan M Davis
wrote:
On Tuesday, May 29, 2012 01:54:59 Alex Rønne Petersen wrote:
On 29-05-2012 01:41, Jonathan M Davis wrote:
> On Tuesday, May 29, 2012 01:35:23 Alex Rønne Petersen wrote:
>> I don't think arguing
On 29.05.2012 16:07, Regan Heath wrote:
According to the docs here:
http://dlang.org/class.html#synchronized-functions
A synchronized function locks "this" and as "this" is exposed
publicly... In the following code the "lock" statement and "synchronized
void bar" lock the same mutex.
class Foo
On Tue, 29 May 2012 13:07:29 +0100, Regan Heath
wrote:
void main()
{
Foo foo = new Foo();
lock(foo)
{
...statements...
}
}
Apologies..I've been writing more C# than D lately. "lock" above should
be "synchronized" for D.
R
--
Using Opera's revolutionary email client: htt
On 2012-05-29 12:25, Manu wrote:
I've been trying to work out why my compile times have gone to hell
recently.
I have a lib, it takes 3.5 seconds to compile.
I add one CTFE heavy module, it's not huge, certainly much smaller than
the rest of the app, and it blows out to 18 seconds. I've done som
On Tue, 29 May 2012 01:08:59 +0100, Jonathan M Davis
wrote:
On Tuesday, May 29, 2012 01:54:59 Alex Rønne Petersen wrote:
On 29-05-2012 01:41, Jonathan M Davis wrote:
> On Tuesday, May 29, 2012 01:35:23 Alex Rønne Petersen wrote:
>> I don't think arguing about them makes sense at this point.
On Tuesday, 29 May 2012 at 11:51:34 UTC, Gor Gyolchanyan wrote:
On Tue, May 29, 2012 at 2:53 PM, Tobias Pankrath
wrote:
On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
Yeah, but it requires re-implementing all those tools. If you
already have
them implemented in D, then it's
I'm reiterating prior info on the subject and provide some motivating
examples. For those convinced of necessity of virtual function templates
already - skip to the bottom ;)
Ultimately template is a way to use the same source code for multiple
entities (typically called instantiations).
In th
On 29 May 2012 14:28, Michel Fortin wrote:
> On 2012-05-29 10:25:54 +, Manu said:
>
> What are the bottlenecks? Is there any way to improve it?
>>
>
> The answer to those questions is usually found by profiling. Asking people
> for what they think is slow is almost certain to give you wrong
On Tue, May 29, 2012 at 2:53 PM, Tobias Pankrath wrote:
> On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
>
>> Yeah, but it requires re-implementing all those tools. If you already have
>> them implemented in D, then it's not a problem, but if you don't or they
>> are closed-source
On 2012-05-29 10:25:54 +, Manu said:
What are the bottlenecks? Is there any way to improve it?
The answer to those questions is usually found by profiling. Asking
people for what they think is slow is almost certain to give you wrong
answers.
--
Michel Fortin
michel.for...@michelf.com
On Monday, 28 May 2012 at 08:21:36 UTC, Araq wrote:
Granted, from *top to bottom* would be nicer, but I have never
seen that happen in practice in C# (which allows for arbitrary
order); but admittedly that's a very weak point.
I wrote tons of C# and I never did it bottom to top. They're
eithe
On Sunday, 2 January 2011 at 06:46:46 UTC, bearophile wrote:
That fantasy of yours means that I am interested in using my
time to explain to Nimrod developers what's good in D, what may
be modified or improved, to steal some of the good ideas of the
D language for the development and spreading
On Tuesday, 29 May 2012 at 10:08:51 UTC, Gor Gyolchanyan wrote:
Yeah, but it requires re-implementing all those tools. If you
already have
them implemented in D, then it's not a problem, but if you
don't or they
are closed-source, then import(filename) won't do much good.
You just need a two
1 - 100 of 109 matches
Mail list logo
