Andrei Alexandrescu Wrote:
> And how would you use such a feature effectively? I've seen such
> "optional implementation" policies in standards such as SQL
> (compatibility levels) and C++ (export). They _always_ fare disastrously.
Just like we do it now: write code for the garbage collected env
On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis
wrote:
Ideally, you'd want things to blow up when such an object was used, with
it clearly indicating that it was because you used an object which isn't
supposed to exist anymore.
I suggested this as well, by stomping on the object's memo
Okay. I really don't know much about garbage collectors, how they work, or what
makes one particularly good or bad (other than the fact that it needs to be
efficient execution-wise and manage memory wisely so that you don't use too
much
of it or do anything else that would be an overall negativ
On Thu, 15 Jul 2010 09:08:24 +0200, Vladimir Panteleev
wrote:
On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis
wrote:
Ideally, you'd want things to blow up when such an object was used, with
it clearly indicating that it was because you used an object which isn't
supposed to exist an
On Thu, 15 Jul 2010 11:03:07 +0300, Rory McGuire
wrote:
On Thu, 15 Jul 2010 09:08:24 +0200, Vladimir Panteleev
wrote:
On Thu, 15 Jul 2010 04:00:49 +0300, Jonathan M Davis
wrote:
Ideally, you'd want things to blow up when such an object was used,
with
it clearly indicating that it w
On Thu, 15 Jul 2010 10:18:38 +0300, Jonathan M Davis
wrote:
Okay. I really don't know much about garbage collectors, how they work,
or what makes one particularly good or bad (other than the fact that it
needs to be efficient execution-wise and manage memory wisely so that
you don't use
dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
[snip]
Thanks, that's definitely a bug. The code in core.cpuid has not been
tested on the most recent CPUs (Intel added a totally new method) and
their documentation is quite convoluted. It's hard to get it right
without an actual ma
On 14 July 2010 14:28, bearophile wrote:
> (...)
> P 10:
> In this line of code:
> while (!input.empty) {
> There is not so much need of using an external function plus a negation:
> while (input.length) {
> (...)
>
I like writing:
while (!input.empty) {
To me, it better shows the meaning of t
I hope Andrei appreciated my efforts :-)
- The non-alphabetical index page 439 is a good idea.
- The page thickness is OK for me.
More comments on Chapter 1:
Page 17: using null to represent empty arrays is not good. In D there is []
that's better for this.
P 18: "foo in
On 07/14/2010 10:43 PM, Andrei Alexandrescu wrote:
There is no early failure with dangling pointers.
There is:
class A
{
void foo() {}
}
class B : A
{
override void foo() {}
}
A a = new B;
A a2 = a;
clear(a);
a2.foo();
If you reset the object state to .init, foo will succeed and t
Once property syntax is fully enforced (not necessarily recommended) will it
be possible to overload properties against non-properties? My use case is
that I'm thinking about API improvements for my dflplot lib and one thing that
I would really like is to give a fluent interface to everything to f
On Thu, 15 Jul 2010 12:13:27 +0200, Tim Verweij wrote:
> On 14 July 2010 14:28, bearophile wrote:
>
>> (...)
>> P 10:
>> In this line of code:
>> while (!input.empty) {
>> There is not so much need of using an external function plus a
>> negation: while (input.length) {
>> (...)
>>
>>
> I like w
On Thu, 15 Jul 2010 09:16:47 -0400, dsimcha wrote:
Once property syntax is fully enforced (not necessarily recommended)
will it
be possible to overload properties against non-properties? My use case
is
that I'm thinking about API improvements for my dflplot lib and one
thing that
I would
Jonathan M Davis, el 15 de julio a las 00:18 me escribiste:
> Okay. I really don't know much about garbage collectors, how they work, or
> what
> makes one particularly good or bad (other than the fact that it needs to be
> efficient execution-wise and manage memory wisely so that you don't use
Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:
> P 61: this is so hard to read that I don't want to see anything similar
> even in small script-like programs. The D compiler can even disallow
> such long chains: int c = (a = b, b = 7, 8);
I suppose this mostly explains why the real tuples are
== Quote from Don (nos...@nospam.com)'s article
> dsimcha wrote:
> > == Quote from Don (nos...@nospam.com)'s article
> >> [snip]
> >> Thanks, that's definitely a bug. The code in core.cpuid has not been
> >> tested on the most recent CPUs (Intel added a totally new method) and
> >> their documentat
== Quote from Max Samukha (spam...@d-coding.com)'s article
> Not that I fiercely disagree but ideally I'd want it to be obliterated
> to an invalid but easily recognizable state. It might help to discover
> dangling pointer errors early. Otherwise, leaving a destroyed object in
> a perfectly valid
On 15.07.2010 15:16, dsimcha wrote:
Once property syntax is fully enforced (not necessarily recommended) will it
be possible to overload properties against non-properties? My use case is
that I'm thinking about API improvements for my dflplot lib and one thing that
I would really like is to give
On Thu, 15 Jul 2010 04:28:43 -0400, Vladimir Panteleev
wrote:
On Thu, 15 Jul 2010 10:18:38 +0300, Jonathan M Davis
wrote:
Okay. I really don't know much about garbage collectors, how they work,
or what makes one particularly good or bad (other than the fact that it
needs to be efficie
== Quote from torhu (n...@spam.invalid)'s article
> In case the answer is no, that example of yours is the perfect
> opportunity to dust off the almost-forgotten with statement :)
> with (Histogram(someData, 10)) {
> barColor = getColor(255, 0, 0);
> histType = HistType.Probability;
>
dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
[snip]
Thanks, that's definitely a bug. The code in core.cpuid has not been
tested on the most recent CPUs (Intel added a totally new method) and
their documentation is
== Quote from Don (nos...@nospam.com)'s article
> dsimcha wrote:
> > == Quote from Don (nos...@nospam.com)'s article
> >> dsimcha wrote:
> >>> == Quote from Don (nos...@nospam.com)'s article
> [snip]
> Thanks, that's definitely a bug. The code in core.cpuid has not been
> tested on t
On 12 July 2010 21:28, bearophile wrote:
> Andrei Alexandrescu:
> > > sort is all but deprecated, since std.algorithm.sort exists.
> > >
> > > reverse could even more easily be implemented as a library function
> than
> > > sort, it should be removed as well.
> >
> > http://www.digitalmars.com/d/
On 07/15/2010 09:10 AM, retard wrote:
Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:
P 61: this is so hard to read that I don't want to see anything similar
even in small script-like programs. The D compiler can even disallow
such long chains: int c = (a = b, b = 7, 8);
I suppose this mos
Hi folks,
When porting some D1 code to D2, i had the idea to add an alternative
syntax of deprecated:
deprecated ( string )
where string is any valid string or char.
The sense of this would be 'deprecated by', so the compiler should then
output "xy is deprecated by ..." instead of "xy is depre
On 07/14/2010 07:28 AM, bearophile wrote:
I have finally received my copy of The D Programming Language :-)
This is a first post of notes that I am writing while I read this
text for the first time.
Thanks. Though the effort is definitely to be appreciated, there is a
high risk that such long
On Jul 16, 10 01:18, Mafi wrote:
Hi folks,
When porting some D1 code to D2, i had the idea to add an alternative
syntax of deprecated:
deprecated ( string )
where string is any valid string or char.
The sense of this would be 'deprecated by', so the compiler should then
output "xy is deprecated b
As a side note, why is there both a std.cpuid and a core.cpuid?
Does std use core? In that case, why not import std.cpuid?
Philippe Sigaud wrote:
As a side note, why is there both a std.cpuid and a core.cpuid?
Does std use core?
No.
In that case, why not import std.cpuid?
std.cpuid is deprecated.
If I had to chose one topic with most bitchin' on this newsgroup I have
impression it would be the one about GC. They usually goes from 'GC managed
programs are slow, D ain't good enough', to 'language X has better GC than D',
to ' GC that D has is bad at Z'.
Why not make D summer of code - wri
dsimcha wrote:
Here's the error message I'm getting. I know basically nothing about make
except
that it's a build system and that it almost never works, so I can't even begin
to
debug this. Here's the error message I've been getting, on a freshly unpacked
2.047 directory on some ancient Linu
Anyway, I'm here bitching myself :) Just want to say that idea to have more
than one GC type to chose when compiling would be very interesting thing, if
single implementation can't be good for all cases.
> If I had to chose one topic with most bitchin' on this newsgroup I have
> impression it w
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> > And here's the error I get when I try on a different machine w/ a more
> > modern
> > distro (this one is probably due to lack of 64 bit libs):
> >
> > $ make -flinux.mak
> > make --no-print-directory -f linux.mak OS=posix BUIL
On Thu, 15 Jul 2010 21:34:36 +0300, Bane
wrote:
Why not make D summer of code - write your own GC optimized for special
case of XYZ, send it, bundle all up in D with compiler switch
'--useGC=XYZ'. That is only way to really compare what is best for
special case.
In D1, the garbage coll
== Quote from Bane (branimir.milosavlje...@gmail.com)'s article
> Anyway, I'm here bitching myself :) Just want to say that idea to have more
> than
one GC type to chose when compiling would be very interesting thing, if single
implementation can't be good for all cases.
> > If I had to chose one
As a practical habit, once I stumble upon a very tricky error, I usually
share the valuable knowledge of "when you do this ... and get that ...
it's probably because ... "
Damn, sometimes they can even become cool quizzes...
So to warn those oblivious to the dangers of opDispatch, here is my the
On Thu, 15 Jul 2010 15:34:23 -0400, Dmitry Olshansky
wrote:
As a practical habit, once I stumble upon a very tricky error, I usually
share the valuable knowledge of "when you do this ... and get that ...
it's probably because ... "
Damn, sometimes they can even become cool quizzes...
So t
Walter Bright, el 15 de julio a las 11:40 me escribiste:
> dsimcha wrote:
> >Here's the error message I'm getting. I know basically nothing about make
> >except
> >that it's a build system and that it almost never works, so I can't even
> >begin to
> >debug this. Here's the error message I've b
Bane, el 15 de julio a las 14:34 me escribiste:
> If I had to chose one topic with most bitchin' on this newsgroup
> I have impression it would be the one about GC. They usually goes from
> 'GC managed programs are slow, D ain't good enough', to 'language
> X has better GC than D', to ' GC that D h
Weren't you leaving for good this list?
On Thu, 15 Jul 2010 09:10:03 -0500, retard wrote:
Thu, 15 Jul 2010 07:51:55 -0400, bearophile wrote:
P 61: this is so hard to read that I don't want to see anything similar
even in small script-like programs. The D compiler can even disallow
such long
On 15.07.2010 17:42, dsimcha wrote:
== Quote from torhu (n...@spam.invalid)'s article
In case the answer is no, that example of yours is the perfect
opportunity to dust off the almost-forgotten with statement :)
with (Histogram(someData, 10)) {
barColor = getColor(255, 0, 0);
hi
dsimcha, el 15 de julio a las 19:23 me escribiste:
> == Quote from Bane (branimir.milosavlje...@gmail.com)'s article
> > Anyway, I'm here bitching myself :) Just want to say that idea to have more
> > than
> one GC type to chose when compiling would be very interesting thing, if single
> implement
== Quote from Leandro Lucarella (l...@llucax.com.ar)'s article
> dsimcha, el 15 de julio a las 19:23 me escribiste:
> > == Quote from Bane (branimir.milosavlje...@gmail.com)'s article
> > > Anyway, I'm here bitching myself :) Just want to say that idea to have
> > > more than
> > one GC type to ch
Walter Bright Wrote:
> >
> > $ make -flinux.mak
> > make --no-print-directory -f OS=posix BUILD=release
> > make[1]: OS=posix: No such file or directory
> > make[1]: *** No rule to make target `OS=posix'. Stop.
> > make: *** [release] Error 2
>
> The "OS=posix" sets the macro OS to the value p
Hello dsimcha,
Histogram(someData, 10)
.barColor(getColor(255, 0, 0))
.histType(HistType.Probability)
.toFigure.title("A Histogram")
.xLabel("Stuff").showAsMain();
With a little meta programming you might be able to make a type that generate
a fluent interface for any type. Using opDispatch y
"Dmitry Olshansky" wrote in message
news:i1nns8$d4...@digitalmars.com...
>
> The tricky part is that *any* class with unconstrained (or loosely
> constrained) opDispatch is also a Range, and at least a bidirectional one,
> since it "provides" all the primitives: front, popFront etc.
> In fact s
On 07/14/2010 08:55 PM, dsimcha wrote:
== Quote from eris (jvbur...@gmail.com)'s article
This is a relatively difficult problem in general to do portably due to hardware
differences, topology differences, changes to hardware, OS variations. Even the
pthreads library doesn't reliably implement
On 16.07.2010 01:46, BCS wrote:
Hello dsimcha,
Histogram(someData, 10)
.barColor(getColor(255, 0, 0))
.histType(HistType.Probability)
.toFigure.title("A Histogram")
.xLabel("Stuff").showAsMain();
With a little meta programming you might be able to make a type that generate
a fluent inter
Georg Wrede wrote:
On 07/14/2010 08:55 PM, dsimcha wrote:
== Quote from eris (jvbur...@gmail.com)'s article
This is a relatively difficult problem in general to do portably due
to hardware
differences, topology differences, changes to hardware, OS
variations. Even the
pthreads library doesn'
I've refactored my dflplot lib to the point where the GUI-specific stuff is
well abstracted from the GUI-agnostic stuff in preparation for a port to a GUI
lib that supports rotated fonts, saving bitmaps, and/or *nix. The plan is to
support multiple GUI libs, including DFL (already working except f
OK, only 98%
http://www.hulu.com/initial-d
--
... <
Just to satisfy my curiousity about how many D users think that the
delete operator really is evil, I launched a poll in micropoll.com.
http://www.micropoll.com/akira/mpview/979834-265542
52 matches
Mail list logo
