On Wednesday 17 November 2010 21:51:24 Kagamin wrote:
> Jonathan M Davis Wrote:
> > I'd have to study up on it to see whether there are any real problems
> > with it.
>
> Speaking in posix terms, performance counter is more like CLOCK_MONOTONIC
> and using it as CLOCK_REALTIME is a dependency on u
DOLIVE ôµ½:
> Why do not you update it? GDC has been updated to dmd2.049 .
refuel, make an all out effort
thank you very much!
On Wednesday 17 November 2010 21:57:58 Steve Teale wrote:
> It's difficult to find a suitable entry point in this thread, so I'll just
> arbitrarily use here.
>
> Various language libraries have flexible facilities for formatting
> date/time values, maybe c#, and certainly PHP, whereby you can spe
On Wednesday 17 November 2010 21:35:03 Steve Teale wrote:
> Jonathan M Davis Wrote:
>
> ... (though in the case of adjusting for NTP, the internal stdTimes for the
> SysTimes
>
> > would be off as well, while in the leap second case, they aren't).
> >
> > - Jonathan M Davis
>
> OK, all, thanks
Steve Teale Wrote:
> So if I want to write a timed log entry, what's the recommendation?
I won't dare to use std.date.
It's difficult to find a suitable entry point in this thread, so I'll just
arbitrarily use here.
Various language libraries have flexible facilities for formatting date/time
values, maybe c#, and certainly PHP, whereby you can specify a format string,
something like "%d'th %M %Y".
Is this a us
Jonathan M Davis Wrote:
> I'd have to study up on it to see whether there are any real problems with it.
Speaking in posix terms, performance counter is more like CLOCK_MONOTONIC and
using it as CLOCK_REALTIME is a dependency on undefined behavior.
Andrei Alexandrescu Wrote:
>
> It's probably common courtesy that should be preserved. I just committed
> the fix prompted by Lutger (thanks).
>
> Andrei
Thanks Andrei. When the next version is released I'll remove the temporary
findRex() function from my current code.
Steve ;=)
Jonathan M Davis Wrote:
... (though in the case of adjusting for NTP, the internal stdTimes for the
SysTimes
> would be off as well, while in the leap second case, they aren't).
>
> - Jonathan M Davis
OK, all, thanks for answering that question, but my primary gripe was that the
current std.d
On Wednesday 17 November 2010 16:09:22 Todd VanderVeen wrote:
> The article was written in 2004. A high precision event timer has been
> incorporated in chipsets since 2005.
>
> http://en.wikipedia.org/wiki/High_Precision_Event_Timer
>
> I hope were not basing decisions on support for NT4.0 :)
I
The article was written in 2004. A high precision event timer has been
incorporated in chipsets since 2005.
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
I hope were not basing decisions on support for NT4.0 :)
== Quote from Kagamin (s...@here.lot)'s article
> Jonathan M Davis Wrote:
On Wednesday, November 17, 2010 13:44:32 Kagamin wrote:
> Jonathan M Davis Wrote:
> > Latest: http://is.gd/gSwDv
>
> You use QueryPerformanceCounter.
> Is this code tested on Windows? MSDN doesn't specify what
> QueryPerformanceCounter returns. see
> http://msdn.microsoft.com/en-us/magazine/cc1639
Matthias Pleh wrote:
Am 17.11.2010 14:55, schrieb Steven Schveighoffer:
Being someone who likes the "brace-on-its-own-line" style
i++
Surely you mean:
i
++
;
--
Simen
Jonathan M Davis Wrote:
> Latest: http://is.gd/gSwDv
>
You use QueryPerformanceCounter.
Is this code tested on Windows? MSDN doesn't specify what
QueryPerformanceCounter returns.
see http://msdn.microsoft.com/en-us/magazine/cc163996.aspx
On Wednesday 17 November 2010 12:37:18 Kagamin wrote:
> Jonathan M Davis Wrote:
> > > This is how it looked on linux:
> > >
> > > bash-2.05b# date
> > > Thu Jan 1 00:59:58 CET 2009
> > > bash-2.05b# date
> > > Thu Jan 1 00:59:59 CET 2009
> > > bash-2.05b# date
> > > Thu Jan 1 00:59:60 CET 2009
> >
On 11/17/2010 05:10, spir wrote:
> Output in general, programmer feedback in particuliar, should simply
> not be considered effect. It is transitory change to dedicated areas
> of memory -- not state. Isn't this the sense of "output", after all?
My debug output actually goes through my logging lib
Jonathan M Davis Wrote:
> > This is how it looked on linux:
> >
> > bash-2.05b# date
> > Thu Jan 1 00:59:58 CET 2009
> > bash-2.05b# date
> > Thu Jan 1 00:59:59 CET 2009
> > bash-2.05b# date
> > Thu Jan 1 00:59:60 CET 2009
> > bash-2.05b# date
> > Thu Jan 1 01:00:00 CET 2009
> > bash-2.05b# date
On 11/17/2010 03:26, Daniel Gibson wrote:
> Rainer Deyke schrieb:
>> Let's say I see something like this in C/C++/D:
>>
>> if(blah())
>> {
>> x++;
>> }
>>
>> This is not my usual style, so I have to stop and think.
>
> What about
> if( (blah() || foo()) && (x > 42)
> && (baz.iDontKnowHowto
On Wed, 17 Nov 2010 13:58:55 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Wed, 17 Nov 2010 12:09:11 -0500, dsimcha wrote:
> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
>> The issue is that if you append to such an array and
On 11/11/2010 11:50, lurker wrote:
ruben niemann Wrote:
Diego Cano Lagneaux Wrote:
Well, I think a simple look at the real world is enough to agree that you
need several years of experience and good skills. Moreover, my personal
experience is that it's easier to get a job (and therefore the m
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Wed, 17 Nov 2010 12:09:11 -0500, dsimcha wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> >> The issue is that if you append to such an array and it adds more pages
> >> in
> >> place, the block
On 18/10/2010 19:45, Steven Schveighoffer wrote:
On Mon, 18 Oct 2010 14:36:57 -0400, Andrei Alexandrescu
wrote:
...bury the hatch and...
Sorry, I can't let this one pass... bury the *hatchet* :)
This isn't Lost.
-Steve
LOOOL
Oh man, I miss that series, even though it was go
On Wed, 17 Nov 2010 12:09:11 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
The issue is that if you append to such an array and it adds more pages
in
place, the block length location will move. Since each thread caches
its
own copy of the block i
Nick Sabalausky:
>Sad as it may be, most people, and worse still, most programmers, have no
>qualms about "safety by convention".<
This is an interesting topic, there is a lot to say about it. Bugs and errors
have many sources, and you need to balance different and sometimes opposed
needs to m
On Wednesday, November 17, 2010 09:51:30 Jonathan M Davis wrote:
> On Wednesday, November 17, 2010 04:15:52 Kagamin wrote:
> > Daniel Gibson Wrote:
> > > > Synchronization can fail if the code asserts that number of seconds
> > > > is not greater than 59 (Jonathan's lib does the same, I think). Is
On Wednesday, November 17, 2010 04:15:52 Kagamin wrote:
> Daniel Gibson Wrote:
> > > Synchronization can fail if the code asserts that number of seconds is
> > > not greater than 59 (Jonathan's lib does the same, I think). Is it the
> > > cause?
> >
> > How are leap seconds handled on a computer a
atomicOp uses a CAS loop for the RMW operations.
Ignore my comment. I should have looked at the code in core.atomic
before commenting. I just had one test case with atomicOp!("+=") that
worked, and assumed that atomicOp!("+=") was implemented with "lock xadd".
I'm thinking of exposing atomicS
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> The issue is that if you append to such an array and it adds more pages in
> place, the block length location will move. Since each thread caches its
> own copy of the block info, one will be wrong and look at array data
> thinki
On Wed, 17 Nov 2010 11:58:20 -0500, Sean Kelly
wrote:
Steven Schveighoffer Wrote:
There is specific code in array appending that locks a global lock when
appending to shared arrays. Appending to __gshared arrays from multiple
threads likely will not work in some cases though. I don't know
Steven Schveighoffer Wrote:
>
> There is specific code in array appending that locks a global lock when
> appending to shared arrays. Appending to __gshared arrays from multiple
> threads likely will not work in some cases though. I don't know how to
> get around this, since the runtime is
On Wed, 17 Nov 2010 10:14:21 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
I think that we need a wrapper for containers that implements the shared
methods required and manually locks things in order to use them. Then
you
apply this wrapper to any
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> I think that we need a wrapper for containers that implements the shared
> methods required and manually locks things in order to use them. Then you
> apply this wrapper to any container type, and it's now a shared container.
> T
"Andrei Alexandrescu" wrote in message
news:ic03ui$gj...@digitalmars.com...
> On 11/17/10 12:00 AM, Jay Byrd wrote:
>> On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:
>>
>>> On 11/16/2010 22:24, Andrei Alexandrescu wrote:
I'm curious what the response to my example will be. So far I
Am 17.11.2010 14:55, schrieb Steven Schveighoffer:
Being someone who likes the "brace-on-its-own-line" style
i++
greets
Matthias
On Wed, 17 Nov 2010 09:17:05 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
I think in general containers don't work across multiple threads unless
specifically designed to do that.
I'm making the assumption that you'd handle all the synchronization
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> I think in general containers don't work across multiple threads unless
> specifically designed to do that.
I'm making the assumption that you'd handle all the synchronization issues
yourself. When you need to update the contain
On Wed, 17 Nov 2010 02:03:05 -0500, Rainer Deyke
wrote:
On 11/16/2010 21:53, Steven Schveighoffer wrote:
It makes me think that this is going to be extremely confusing for a
while, because people are so used to pure being equated with a
functional language, so when they see a function is pur
On Wed, 17 Nov 2010 02:56:09 -0500, Jay Byrd wrote:
On Wed, 17 Nov 2010 00:58:28 -0500, Steven Schveighoffer wrote:
On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu
wrote:
On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
wrot
Steven Schveighoffer:
>It makes me think that this is going to be extremely confusing for a while,
>because people are so used to pure being equated with a functional language,
>so when they see a function is pure but takes mutable data, they will be
>scratching their heads.<
I agree, it's a (
Hi,
I've written a small module for debugging on Posix systems.
It uses raise(SIGTRAP) and a custom errorHandlerType with
setAssertHandler. But setAssertHandler is deprecated.
Why is it deprecated? How should I do it instead?
I want to do it generally for Error and Exception. Don't know how yet.
On Tue, 16 Nov 2010 23:28:37 -0800
Jonathan M Davis wrote:
> It has already been argued that I/O should be exempt (at least for debugging
> purposes), and I think that that would could be acceptable for weakly pure
> functions. But it's certainly true that as it stands, dealing with I/O and
>
>From wiki:
>There was originally some controversy over whether the Unix time_t should be
>signed or unsigned. If unsigned, its range in the future would be doubled,
>postponing the 32-bit overflow (by 68 years). However, it would then be
>incapable of representing times prior to 1970. Dennis R
Daniel Gibson Wrote:
> > Synchronization can fail if the code asserts that number of seconds is not
> > greater than 59 (Jonathan's lib does the same, I think). Is it the cause?
>
> How are leap seconds handled on a computer anyway? Does the clock really
> count
> to 60 seconds (instead of 59)
I had accidentally written:
immutable pi = 4.0 * reduce ! ( "a + b" ) ( 0 , outputData ) * delta ;
the error message received was:
Error: template instance std.algorithm.reduce!("a +
b").reduce!(int,Map!(partialSum,Tuple!(int,int,double)[])) error instantiating
which isn't wrong, but neither
On Wed, 17 Nov 2010 00:03:05 -0700
Rainer Deyke wrote:
> Making functions weakly pure by default means that temporarily adding a
> tiny debug printf to any function will require a shitload of cascading
> 'impure' annotations. I would consider that completely unacceptable.
Output in general, pro
> That one point you made would be a
> deal-killer for me (not that I'm close to using Go or anything, but no
> need to invest any more time on it after that).
That was a good point and it's a deal-killer for me too.
It's too much similar to the Javascript object literal syntax
http://stackove
Kagamin schrieb:
Daniel Gibson Wrote:
I think, it's ok, computers work with nominal time and synchronize with world
as needed. Hardly you can catch a bug with leap seconds.
As long as you're not Oracle and your enterprise clusterware crap reboots:
http://www.theregister.co.uk/2009/01/07/oracl
Daniel Gibson Wrote:
> > I think, it's ok, computers work with nominal time and synchronize with
> > world as needed. Hardly you can catch a bug with leap seconds.
>
> As long as you're not Oracle and your enterprise clusterware crap reboots:
> http://www.theregister.co.uk/2009/01/07/oracle_leap
Daniel Gibson schrieb:
Rainer Deyke schrieb:
On 11/16/2010 22:24, Andrei Alexandrescu wrote:
I'm curious what the response to my example will be. So far I got one
that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same
line as 'if'. It's somethin
Rainer Deyke schrieb:
On 11/16/2010 22:24, Andrei Alexandrescu wrote:
I'm curious what the response to my example will be. So far I got one
that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same
line as 'if'. It's something you learn once and nev
Kagamin schrieb:
Jonathan M Davis Wrote:
Honestly, leap seconds are complete stupidity with regards to computers. They
just complicate things.
I think, it's ok, computers work with nominal time and synchronize with world
as needed. Hardly you can catch a bug with leap seconds.
As long as y
It *isn't* required. But if you don't put it there, *you get the wrong
result*.
You didn't mean that, did you?
Oh you did! and i agree.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
The problem pointed out can readily be fixed by requiring statements to
have at least one token. go has much more severe problems than that. And
there are plenty of bugs and mistakes in D, harder to fix, that could be
deemed "deal-killers" by someone with an axe to grind. It's not an
intellectuall
It *isn't* required. But if you don't put it there, *you get the wrong
result*.
You didn't mean that, did you?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On 11/17/10 12:00 AM, Jay Byrd wrote:
On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:
On 11/16/2010 22:24, Andrei Alexandrescu wrote:
I'm curious what the response to my example will be. So far I got one
that doesn't even address it.
I really don't see the problem with requiring that
On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:
> On 11/16/2010 22:24, Andrei Alexandrescu wrote:
>> I'm curious what the response to my example will be. So far I got one
>> that doesn't even address it.
>
> I really don't see the problem with requiring that '{' goes on the same
> line as
56 matches
Mail list logo
