On 4/19/2011 7:11 PM, Brad Roberts wrote:
The stronger argument, that I agree with, is not having flag based
sometimes warnings. The more flags you have, the more complex the matrix
of landmines there are. I hate micro-managment, in all it's forms.
True, if you have N compiler switches, you h
bearophile Wrote:
> In Bugzilla I have just added an enhancement request that asks for a little
> change in D, I don't know if it was already discussed or if it's already
> present in Bugzilla:
> http://d.puremagic.com/issues/show_bug.cgi?id=5864
Loosing precision on a fractional number seems l
Bearophile (you should change your nick or not) wrote:
[I found this litter while walking along the highway]:
"If one of the challenges of evolving a widely used language is
that there's a lot of code out there that we don't want to break,
one of the benefits is that there's a lot of code out the
Vladimir Panteleev Wrote:
> One classic example of this is passing arguments by
> reference, something D inherited from C++. For example:
>
> int x, y;
> // ...
> someObject.updateCoords(x, y);
>
> What can you say about this code?
D IS TEH typesaving language. Go the D way or go away :3
On Tue, 19 Apr 2011 19:47:57 -0400, Vladimir Panteleev
wrote:
On Wed, 20 Apr 2011 02:43:50 +0300, bearophile
wrote:
I agree. In my opinion the problem is not you using in your module a
language feature designed for that very purpose. What's in question is
the syntax of that language f
On 4/19/2011 10:42 PM, bearophile wrote:
Andrei:
Yes please. I once felt the same way, but learned better since.
OK :-) But I will probably write an article about this, because I have found a
performance problem, that currently DMD doesn't help me avoid, that a C lint
has avoided me.
Bye,
On Tue, 19 Apr 2011 14:18:46 -0400, Sean Kelly
wrote:
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
wrote:
The dmd startup code (actually the C startup code) does an fninit. I
never thought about new thread starts. So, yeah, drun
On Tue, 19 Apr 2011 20:37:47 -0400, bearophile
wrote:
dsimcha:
I know what you suggest could prevent bugs in a lot of
cases, but it also has the potential to get in the way in a lot of
cases.
You are right, and I am ready to close that enhancement request at once
if the consensus is aga
Andrei:
> Yes please. I once felt the same way, but learned better since.
OK :-) But I will probably write an article about this, because I have found a
performance problem, that currently DMD doesn't help me avoid, that a C lint
has avoided me.
Bye,
bearophile
On 4/19/11 7:37 PM, bearophile wrote:
dsimcha:
I know what you suggest could prevent bugs in a lot of
cases, but it also has the potential to get in the way in a lot of cases.
You are right, and I am ready to close that enhancement request at once if the
consensus is against it.
Yes please
On Tue, 19 Apr 2011, Walter Bright wrote:
> On 4/19/2011 6:46 PM, bearophile wrote:
> > Walter:
> >
> > > Hence my reluctance to add in a lot of these suggestions.
> >
> > In an answer I've suggested the alternative solution of a
> > -warn_fp_precision_loss compiler switch, that produces warning
On 4/19/2011 6:46 PM, bearophile wrote:
Walter:
Hence my reluctance to add in a lot of these suggestions.
In an answer I've suggested the alternative solution of a
-warn_fp_precision_loss compiler switch, that produces warnings only when you
use it. In theory this avoids most of the Nagging N
Walter:
> Hence my reluctance to add in a lot of these suggestions.
In an answer I've suggested the alternative solution of a
-warn_fp_precision_loss compiler switch, that produces warnings only when you
use it. In theory this avoids most of the Nagging Nellie problem, because you
use this swi
On 4/19/2011 5:02 PM, dsimcha wrote:
Generally I worry about D's type system becoming like the Boy Who Cried Wolf,
where it flags so many potential errors (as opposed to things that are
definitely errors) that people become conditioned to just put in whatever casts
they need to shut it up. I defi
On 4/19/2011 8:37 PM, bearophile wrote:
dsimcha:
I know what you suggest could prevent bugs in a lot of
cases, but it also has the potential to get in the way in a lot of cases.
You are right, and I am ready to close that enhancement request at once if the
consensus is against it.
double->f
dsimcha:
> I know what you suggest could prevent bugs in a lot of
> cases, but it also has the potential to get in the way in a lot of cases.
You are right, and I am ready to close that enhancement request at once if the
consensus is against it.
double->float and real->float cases are not so c
On 4/19/2011 12:08 PM, Dmitry Olshansky wrote:
slackCat should probably use the common type, not the first one passed?
Fixed.
https://github.com/dsimcha/TempAlloc/commit/5e3fd0db9c905d361695d267e460a436c2b2
https://github.com/dsimcha/TempAlloc/commit/5e74dd20d92c545cb4e3945c81175307c60b12
On 4/19/2011 7:49 PM, bearophile wrote:
In Bugzilla I have just added an enhancement request that asks for a little
change in D, I don't know if it was already discussed or if it's already
present in Bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=5864
In a program like this:
void mai
On 4/19/2011 7:47 PM, Vladimir Panteleev wrote:
David's library evaluates these expressions *in different threads*!
Minor correction: No it doesn't. It constructs a WorkerLocalStorage
object in a regular class method in the thread from which
workerLocalStorage() was called. It does evalua
On 4/19/2011 7:30 PM, spir wrote:
And what about requiring "lazy" (and "ref") at the call site; I mean in
the long term? I find this very sensible.
Denis
I wouldn't mind this for "lazy" but would argue heavily against it for
"ref". ref parameters are both more frequently used and less surpri
In Bugzilla I have just added an enhancement request that asks for a little
change in D, I don't know if it was already discussed or if it's already
present in Bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=5864
In a program like this:
void main() {
uint x = 10_000;
ubyte b = x
On Wed, 20 Apr 2011 02:43:50 +0300, bearophile
wrote:
I agree. In my opinion the problem is not you using in your module a
language feature designed for that very purpose. What's in question is
the syntax of that language feature. I don't mind lazy arguments, but it
can be argued that's
On 04/19/2011 05:18 PM, dsimcha wrote:
== Quote from Vladimir Panteleev (vladi...@thecybershadow.net)'s article
To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer knows
the function's signature. I've notice
dsimcha:
> I did it because it seemed like things like this were kind of the point of
> lazy
> parameters.
I agree. In my opinion the problem is not you using in your module a language
feature designed for that very purpose. What's in question is the syntax of
that language feature. I don't m
On Wed, 20 Apr 2011 02:18:39 +0300, dsimcha wrote:
My vote is weakly in favor of lazy parameters, since a maintenance
programmer would probably look at what such a function does and not be
surprised for very long.
Not contradicting you, but I'd like to clarify my point: given a large
fun
On 04/20/2011 01:18 AM, dsimcha wrote:
== Quote from Vladimir Panteleev (vladi...@thecybershadow.net)'s article
To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer knows
the function's signature. I've notice
On 04/20/2011 01:09 AM, Vladimir Panteleev wrote:
To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer knows the
function's signature. I've noticed a worrying adoption in D of this
"antipattern", which, frankl
== Quote from Vladimir Panteleev (vladi...@thecybershadow.net)'s article
> To elaborate, I mean allowing code which appears to behave surprisingly
> different from the at-a-glance interpretation, unless the programmer knows
> the function's signature. I've noticed a worrying adoption in D of this
>
To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer knows
the function's signature. I've noticed a worrying adoption in D of this
"antipattern", which, frankly, I believe doesn't belong in a well-designed
Andrei:
> (Some GCs are unable to implement
> "delete" meaningfully.)
>
> Manual memory disposal for the GC heap will be implemented as a template
> function with semantics defined by the GC implementation.
Now the function(s) that replace "delete" are meant to be hints for the GC. In
a syste
On 4/19/11 1:04 PM, Timon Gehr wrote:
Steven Schveighoffer wrote:
And one other note -- delete will eventually be deprecated. In order to
free memory, you must use clear and GC.free.
-Steve
Well, why? It seems like a bad decision to me.
The feature is not going away, just the keyword.
"
YES.
YES
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
> On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
> wrote:
>>
>>
>> The dmd startup code (actually the C startup code) does an fninit. I never
>> thought about new thread starts. So, yeah, druntime should do an fninit on
>> thread creation
YES
--
Mike Wey
Yes.
This module is a great example of the expressive powers of D.
Maybe it's too late for comments, but skipping over the documentation
again, I think parallel foreach is the flagship of the module and the
simplest concept to understand, so I would expect the example from
parallel(R) to be s
On Tue, 19 Apr 2011 14:04:38 -0400, Timon Gehr wrote:
Steven Schveighoffer wrote:
And one other note -- delete will eventually be deprecated. In order to
free memory, you must use clear and GC.free.
-Steve
Well, why? It seems like a bad decision to me.
I'm neutral on the subject, you'd
Thank you for your quick reply. I am now starting to see how it should be used.
As a little bit of encouragement, your code is being used in in-house
applications doing millions to trillions of calculations that are creating
leading edge economic data.
Thank you again,
Jonathan
dsimcha wrote
YES
Steven Schveighoffer wrote:
> And one other note -- delete will eventually be deprecated. In order to
> free memory, you must use clear and GC.free.
> -Steve
Well, why? It seems like a bad decision to me.
A bit of quantitative design for computer languages (about Java):
http://www.ibm.com/developerworks/java/library/j-ldn1/
>From the article:
>If one of the challenges of evolving a widely used language is that there's a
>lot of code out there that we don't want to break, one of the benefits is th
dsimcha:
> Probably nothing will ever be able to hold your hand about high level
> invariants.
Who knows? Probably there are papers with ideas about such problems.
Bye,
bearophile
== Quote from Jonathan Crapuchettes (jcrapuchet...@gmail.com)'s article
> I've been looking at your std.parallelism module and am really interested in
> it,
> but there is one problem that I have run into that I can't seem to find a
> solution. If I have code that requires a database connection in
I've been looking at your std.parallelism module and am really interested in it,
but there is one problem that I have run into that I can't seem to find a
solution. If I have code that requires a database connection in each thread, I
don't really want to be creating and then deleting a lot (e.g.
== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article
> slackCat should probably use the common type, not the first one passed?
Good point. Will fix.
> Also it would be cool to have addRange/removeRange somehow automated for
> types that have indirections.
> Or it's too much state to
slackCat should probably use the common type, not the first one passed?
Also it would be cool to have addRange/removeRange somehow automated for
types that have indirections.
Or it's too much state to carry around?
--
Dmitry Olshansky
YES
YES
YES
YES
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> I say yes.
> I want to mention that I am a left a little skeptical about the lack of
> low-level race safety in this module, but I understand that this is
> more a language- or compiler-level problem than one with the module
> itse
Am 19.04.2011 17:02, schrieb Denis Koroskin:
> On Tue, 19 Apr 2011 18:34:33 +0400, dsimcha wrote:
>
>> == Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
>>> Nice work. I've tried it out with allocating some large float arrays,
>>> quick two test cases were a 94MB and 282MB audi
On Tue, 19 Apr 2011 18:34:33 +0400, dsimcha wrote:
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
Nice work. I've tried it out with allocating some large float arrays,
quick two test cases were a 94MB and 282MB audio file.
File 1 w/o TempAlloc: 410msecs
File 1 w/ TempAllo
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> Ok, perhaps you should put a note in the docs about falling back to
> the C heap. Or maybe that's just common sense for people in the
> know-how?
Right. This is roughly equivalent to allocating a new segment. I might put
mor
Ok, perhaps you should put a note in the docs about falling back to
the C heap. Or maybe that's just common sense for people in the
know-how?
I've realized the allocation attempt was actually quite a bit more
than 500Mb. The C lib returned the number of channels and frame count,
which totalled to
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> Nice work. I've tried it out with allocating some large float arrays,
> quick two test cases were a 94MB and 282MB audio file.
> File 1 w/o TempAlloc: 410msecs
> File 1 w/ TempAlloc: 184msecs
> File 2 w/o TempAlloc 1321 msecs
>
Oh, I should mention I was using a C library to actually load the data
into the buffer, so I didn't use -J imports or anything like that.
Nice work. I've tried it out with allocating some large float arrays,
quick two test cases were a 94MB and 282MB audio file.
File 1 w/o TempAlloc: 410msecs
File 1 w/ TempAlloc: 184msecs
File 2 w/o TempAlloc 1321 msecs
File 2 w/ TempAlloc 567 msecs
Btw, how much *can* I allocate at once by using
On Tue, 19 Apr 2011 03:25:06 -0400, Lars T. Kyllingstad
wrote:
As announced a week ago, the formal review process for David Simcha's
std.parallelism module is now over, and it is time to vote over whether
the module should be included in Phobos. See below for more information
on the module a
Lars T. Kyllingstad Wrote:
> As announced a week ago, the formal review process for David Simcha's
> std.parallelism module is now over, and it is time to vote over whether
> the module should be included in Phobos. See below for more information
> on the module and on previous reviews.
>
> P
== Quote from Michel Fortin (michel.for...@michelf.com)'s article
> I say yes.
> I want to mention that I am a left a little skeptical about the lack of
> low-level race safety in this module, but I understand that this is
> more a language- or compiler-level problem than one with the module
> itse
I say yes.
I want to mention that I am a left a little skeptical about the lack of
low-level race safety in this module, but I understand that this is
more a language- or compiler-level problem than one with the module
itself. I hope these problem will be addressed eventually and that
std.par
On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
[ . . . ]
> I would like to make a comment if that's okay. If a person is not an
> expert on parallelism, library development, or we can't verify his or
> her background and such, I don't see why their vote should count. I'm
> not voting because I'
Am 19.04.2011 06:09, schrieb Eric Poggel (JoeCoder):
> On 4/18/2011 9:20 PM, Daniel Gibson wrote:
>
>> What about successful languages like C(++) or Python? I think they were
>> and still are pretty neutral (even though at least C and C++ were
>> developed at a commercial company).
>
> C++ is hor
My TempAlloc module's been ready for review for a while, but
std.net.isemail and std.parallelism were ahead of it in the review
queue. Now that the reviews for both are done (I doubt running a review
concurrently with a vote is problematic), I want to put this next in
line. I'd like to get it
YES
On Tue, Apr 19, 2011 at 7:11 AM, bearophile wrote:
> Caligo:
>
>> I would like to make a comment if that's okay. If a person is not an
>> expert on parallelism, library development, or we can't verify his or
>> her background and such, I don't see why their vote should count. I'm
>> not voting b
Caligo:
> I would like to make a comment if that's okay. If a person is not an
> expert on parallelism, library development, or we can't verify his or
> her background and such, I don't see why their vote should count. I'm
> not voting because I'm just an ordinary D user, and I have no
> experti
He's not hiding behind an alias, he made numerous blog posts here:
http://leonardo-m.livejournal.com/
My vote is YES.
On Tue, Apr 19, 2011 at 5:49 AM, Jonathan M Davis wrote:
>> Lars T. Kyllingstad:
>> > Please vote in this thread, by replying with
>> >
>> > - "YES" if you think std.parallelism should be included in Phobos
>> >
>> > in its present form,
>> >
>> > - "NO" if you think it shouldn't.
>>
>> If
> Lars T. Kyllingstad:
> > Please vote in this thread, by replying with
> >
> > - "YES" if you think std.parallelism should be included in Phobos
> >
> > in its present form,
> >
> > - "NO" if you think it shouldn't.
>
> If my vote counts then Yes.
Everyone's vote on the newsgroup
Lars T. Kyllingstad:
> Please vote in this thread, by replying with
>
> - "YES" if you think std.parallelism should be included in Phobos
> in its present form,
>
> - "NO" if you think it shouldn't.
If my vote counts then Yes.
Bye,
bearophile
YES
--
Dmitry Olshansky
YES
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russ
As announced a week ago, the formal review process for David Simcha's
std.parallelism module is now over, and it is time to vote over whether
the module should be included in Phobos. See below for more information
on the module and on previous reviews.
Please vote in this thread, by replying w
=
What a wonderful resource. The test results are fascinating, and
provide
some insight I've been idly wondering about recently. Thanks :)
David, it appears should be able to simply go backwards ("Older")
until
you see a good compile and test, and check out that revision from
git,
76 matches
Mail list logo
