Re: Spikes in array capacity
BCS wrote:
>> There is something strange in the array capacity algorithm.
>> [...]
>> Is that intended?
> I'm going to take a guess that the gc is (after some point) allocating
> into the smallest hole with "enough" capacity.
You may be right. :)
> If you re run the test
> but with something else going on to add some noise, do the spikes move?
Yes, the spikes move.
> void makeNoise()
> {
> static byte[][256] data;
> data[rand() % $] = new byte[rand() % 512];
> }
I am not familiar with the dmd internals; but following the code took me
to the function newCapacity() in src/druntime/src/rt/lifetime.d. The
capacity growth is more complicated than what I've been assuming so far.
And yes, GC is in the picture. Quoting the comments from that file:
/*
* Better version by Dave Fladebo:
* This uses an inverse logorithmic algorithm to pre-allocate a bit more
* space for larger arrays.
* - Arrays smaller than PAGESIZE bytes are left as-is, so for the most
* common cases, memory allocation is 1 to 1. The small overhead added
* doesn't affect small array perf. (it's virtually the same as
* current).
* - Larger arrays have some space pre-allocated.
* - As the arrays grow, the relative pre-allocated space shrinks.
* - The logorithmic algorithm allocates relatively more space for
* mid-size arrays, making it very fast for medium arrays (for
* mid-to-large arrays, this turns out to be quite a bit faster than the
* equivalent realloc() code in C, on Linux at least. Small arrays are
* just as fast as GCC).
* - Perhaps most importantly, overall memory usage and stress on the GC
* is decreased significantly for demanding environments.
*/
So there may not be a bug after all...
Ali
Re: Spikes in array capacity
Hello Ali,
There is something strange in the array capacity algorithm.
[...]
Is that intended?
Ali
I'm going to take a guess that the gc is (after some point) allocating into
the smallest hole with "enough" capacity. If you re run the test but with
something else going on to add some noise, do the spikes move?
void makeNoise()
{
static byte[][256] data;
data[rand() % $] = new byte[rand() % 512];
}
--
... <
Re: Bit disappointed with TDPL build quality
Hello Strtr, I just got my (44E) copy of the TDPL and I love the stuff I've read so far. But, the book as an object kind of disappoints me.. I know it isn't a hard-cover, but still: I don't own any book with this kind of translucent pages. It makes all the pages look smudgy and you can actually read the bibliography through page 431. Also, maybe I don't own any books which use the same cutting process, but it looks really sloppy cut. Maybe it's just my book, but just thought I should mention this. Ditto on 431 but only where the isn't text covering it up. Also keep in mind that more opaque paper would be thicker and the book is not exactly thin to begin with. -- ... <
Re: D: An Up and Coming Embedded Software Language
On Thu, 01 Jul 2010 17:54:54 -0400, bearophile wrote: > > Michel Fortin: > > I sure hope it will. In the meanwhile, more and more code is being > > written in (or ported to) D2 which is potentially missing 'override' > > everywhere. Wouldn't it be better to do this sooner rather than later? > > Both Walter and Andrei want it, so it's a matter of time. It doesn't even > need to be implemented, because this test is already present in the compiler: > I generally suggest D programmers to compile their code with the -w > (warnings), it helps catch some bugs and it forces you to use override. > And even if some D2 code lacks override, you need a very short place add a > hundred missing "override" in a large program. > > Bye, > bearophile Object not being const correct is probably a blocker for mandatory use of "override": http://d.puremagic.com/issues/show_bug.cgi?id=1824 I compile with -w, and trying to write correct overrides for toString(), toHash(), etc. is a pain.
Re: mangle
On Thu, 1 Jul 2010 19:34:09 -0700, Jonathan M Davis wrote: > > On Thursday, July 01, 2010 19:13:02 Rainer Deyke wrote: > > On 7/1/2010 19:32, Jonathan M Davis wrote: > > > By the way, why _does_ D mangle its names? What's the advantage? I > > > understood that C++ does it because it was forced to back in the days > > > when it was transformed into C code during compilation but that it's now > > > generally considered a legacy problem that we're stuck with rather than > > > something that would still be considered a good design decision. > > > > > > So, why did D go with name mangling? It certainly makes stuff like stack > > > traces harder to deal with. I've never heard of any advantage to name > > > mangling, only disadvantages. > > > > Because DMD is stuck with a C-age linker. > > Well, I guess that it just goes to show how little I understand about exactly > how linking works when I don't understand what that means. After all, C > doesn't > using name mangling. Does that mean that name mangling it meant as a > namespacing > tool to ensure that no D function could possibly have the same linking name > as a > C function? > > - Jonathan M Davis C doesn't require mangling because functions can't be overloaded. To make D (or C++) compatible with C linkers, symbol names need to be unique, so functions with identical names but different types need to be represented with different symbols.
Re: mangle
On 7/1/2010 20:34, Jonathan M Davis wrote: > On Thursday, July 01, 2010 19:13:02 Rainer Deyke wrote: >> Because DMD is stuck with a C-age linker. > > Well, I guess that it just goes to show how little I understand about exactly > how linking works when I don't understand what that means. After all, C > doesn't > using name mangling. Does that mean that name mangling it meant as a > namespacing > tool to ensure that no D function could possibly have the same linking name > as a > C function? That, and to allow for overloaded functions, functions with the same name in different modules, and member functions. Each symbol with external linkage must map to a single unique identifier. The concerns are exactly the same as those in C++. -- Rainer Deyke - rain...@eldwood.com
Re: mangle
On Thursday, July 01, 2010 19:13:02 Rainer Deyke wrote: > On 7/1/2010 19:32, Jonathan M Davis wrote: > > By the way, why _does_ D mangle its names? What's the advantage? I > > understood that C++ does it because it was forced to back in the days > > when it was transformed into C code during compilation but that it's now > > generally considered a legacy problem that we're stuck with rather than > > something that would still be considered a good design decision. > > > > So, why did D go with name mangling? It certainly makes stuff like stack > > traces harder to deal with. I've never heard of any advantage to name > > mangling, only disadvantages. > > Because DMD is stuck with a C-age linker. Well, I guess that it just goes to show how little I understand about exactly how linking works when I don't understand what that means. After all, C doesn't using name mangling. Does that mean that name mangling it meant as a namespacing tool to ensure that no D function could possibly have the same linking name as a C function? - Jonathan M Davis
Re: mangle
On 7/1/2010 19:32, Jonathan M Davis wrote: > By the way, why _does_ D mangle its names? What's the advantage? I understood > that C++ does it because it was forced to back in the days when it was > transformed into C code during compilation but that it's now generally > considered a legacy problem that we're stuck with rather than something that > would still be considered a good design decision. > > So, why did D go with name mangling? It certainly makes stuff like stack > traces > harder to deal with. I've never heard of any advantage to name mangling, only > disadvantages. Because DMD is stuck with a C-age linker. -- Rainer Deyke - rain...@eldwood.com
Re: mangle
By the way, why _does_ D mangle its names? What's the advantage? I understood that C++ does it because it was forced to back in the days when it was transformed into C code during compilation but that it's now generally considered a legacy problem that we're stuck with rather than something that would still be considered a good design decision. So, why did D go with name mangling? It certainly makes stuff like stack traces harder to deal with. I've never heard of any advantage to name mangling, only disadvantages. - Jonathan M Davis
Re: mangle
http://dpldocs.info/std.demangle
mangle
test.o: In function `_D3std6random156__T11RandomCoverTAiTS3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngineZ11RandomCover4saveMFNdZS3std6random156__T11RandomCoverTAiTS3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngineZ11RandomCover': test.d:(.text._D3std6random156__T11RandomCoverTAiTS3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngineZ11RandomCover4saveMFNdZS3std6random156__T11RandomCoverTAiTS3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngineZ11RandomCover+0x69): undefined reference to `_D3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngine4saveMFNdZS3std6random98__T21MersenneTwisterEngineTkVi32Vi624Vi397Vi31Vk2567483615Vi11Vi7Vk2636928640Vi15Vk4022730752Vi18Z21MersenneTwisterEngine' collect2: ld returned 1 exit status --- errorlevel 1 err, could someone point me to a decent demangler?
Re: Bit disappointed with TDPL build quality
On Thursday, July 01, 2010 14:22:30 strtr wrote: > I just got my (44E) copy of the TDPL and I love the stuff I've read so far. > > But, the book as an object kind of disappoints me.. > I know it isn't a hard-cover, but still: > > I don't own any book with this kind of translucent pages. It makes all the > pages look smudgy and you can actually read the bibliography through page > 431. Also, maybe I don't own any books which use the same cutting process, > but it looks really sloppy cut. > > Maybe it's just my book, but just thought I should mention this. In any case, the only problem that I've had with the quality of the book's material is that I've been carrying it around so much that it's starting to get a bit worn on the edges. And given that it's paperback, that's likely pretty much a given unless you go out of your way to make sure that it's treated really carefully, or you just leave it on the shelf and don't read it. The paper is a bit translucent, but it doesn't really affect the readability IMO, and the paper does seem to be of good quality. I'm sure that you could find other books with this sort of paper - especially if you look at books from the same publisher. Overall, I really like the quality of the book. About the only thing that I could have asked for would be a hardcover, but that's not exactly the norm for programming books. - Jonathan M Davis P.S. @spam.com? I would have thought that an address like that would be taboo. What's the idea, that there's no way a spammer would label their e-mail adress as spam?
Re: D: An Up and Coming Embedded Software Language
Michel Fortin: > I sure hope it will. In the meanwhile, more and more code is being > written in (or ported to) D2 which is potentially missing 'override' > everywhere. Wouldn't it be better to do this sooner rather than later? Both Walter and Andrei want it, so it's a matter of time. It doesn't even need to be implemented, because this test is already present in the compiler: I generally suggest D programmers to compile their code with the -w (warnings), it helps catch some bugs and it forces you to use override. And even if some D2 code lacks override, you need a very short place add a hundred missing "override" in a large program. Bye, bearophile
Re: D: An Up and Coming Embedded Software Language
On 2010-07-01 15:11:07 -0400, bearophile said: Some partial comments: - The usage of override keyword will probably become obligatory in D, even when you don't use -w, see bug 3836. I sure hope it will. In the meanwhile, more and more code is being written in (or ported to) D2 which is potentially missing 'override' everywhere. Wouldn't it be better to do this sooner rather than later? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Bit disappointed with TDPL build quality
I just got my (44E) copy of the TDPL and I love the stuff I've read so far. But, the book as an object kind of disappoints me.. I know it isn't a hard-cover, but still: I don't own any book with this kind of translucent pages. It makes all the pages look smudgy and you can actually read the bibliography through page 431. Also, maybe I don't own any books which use the same cutting process, but it looks really sloppy cut. Maybe it's just my book, but just thought I should mention this.
Re: Part 1 of the Language Reference Docs Review
Leandro Lucarella Wrote: > Andrej Mitrovic, el 1 de julio a las 14:21 me escribiste: > > Okay, I've done some more reviewing and covered these: > > > > structs, > > classes, > > interfaces, > > enums, > > const, > > functions, > > contracts. > > > > I've not yet touched op-overloading, templates and a bunch of others. > > > > Anyways, I've noticed this Tracker in the bug-reports: > > http://d.puremagic.com/issues/show_bug.cgi?id=677 > > > > That one's for D1 (and it seems abandoned). > > What do you mean by abandoned? By Walter? Because I don't think it's > abandoned by the users/reporters... > > -- > Leandro Lucarella (AKA luca) http://llucax.com.ar/ > -- > GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) > -- > - is there a perl version of php?... > cause i have cgi-bin access with perl and want to use php scripts. I'm sorry, I didn't mean anything bad by it. I just assumed it's not maintained anymore, the tracker wasn't updated since August 2009 and there are still around 20 or so issues unresolved (according to the Tracker). OT: I don't know what's with this web newsreader but it didn't properly link to my other threads here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=112595 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=112596
Re: Part 1 of the Language Reference Docs Review
Andrej Mitrovic, el 1 de julio a las 14:21 me escribiste: > Okay, I've done some more reviewing and covered these: > > structs, > classes, > interfaces, > enums, > const, > functions, > contracts. > > I've not yet touched op-overloading, templates and a bunch of others. > > Anyways, I've noticed this Tracker in the bug-reports: > http://d.puremagic.com/issues/show_bug.cgi?id=677 > > That one's for D1 (and it seems abandoned). What do you mean by abandoned? By Walter? Because I don't think it's abandoned by the users/reporters... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- - is there a perl version of php?... cause i have cgi-bin access with perl and want to use php scripts.
Re: Better tuples
On Thu, Jul 1, 2010 at 01:13, bearophile wrote:
> I'd like to add five enhancement requests in Bugzilla, related to
> std.typecons.Tuple. I show them here first for possible comments or
> critiques.
>
OK, here I go.
I don't plan to make you like current D tuples, but I'd like to show some
facilities the current syntax provide... and some things I discovered while
answering this, in case other people reading this didn't know them either.
I have seen that std.typecons.Tuple is quite useful, but it misses some very
> important features. Some features can just be added to it (see for example
> bug 4381 )
Yes this one (adding a .length member) seems easy.
just add either
@property size_t length() { return Types.length; }
or
immutable length = Types.length
> and maybe the apply(). But other features can't just be added, they need
> some syntax and semantic support.
>
> Some other useful things:
> - More integration and usage of Tuple in druntime. For example the
> associative array property AA.byItem() can yield tuple(key,value) lazily,
> and AA.items can return a dynamic array of them.
>
I like that, as the range associated to AA is quite naturally a lazy
Tuple!(K,V)[].
opSlice() is not defined for AA, so whe not use it to return a range?
auto range = aa[]; // lazily produce (K,V) pairs
> - Some way to reverse the order of the items of a tuple (generating a tuple
> of different type).
>
I had some fun with this and ideas like this. Inserting elements, rotating
tuples, reversing them, etc. Even mapping polymorphic functions on tuples
and reducing them, though I don't think these should be part of any standard
library.
You can these there:
http://svn.dsource.org/projects/dranges/trunk/dranges/docs/tuple2.html
- "in" operator for tuples (as for arrays).
>
Yes, and that seems easily implementable. I use this:
bool contains(U, T...)(Tuple!T tup, U elem)
{
static if (staticIndexOf!(U,T) == -1)
return false;
else
{
foreach(i, Type; tup.Types)
{
static if (is(Type == U))
if (tup.field[i] == elem) return true;
}
return false;
}
}
But I now see I could iterate directly by jumping at staticIndexOf(U,T) and
if the value is not OK, continuing on the tail. Though on most cases, tuples
have only a few elements...
> - More tuple-aware functions in Phobos, like a function to build an AA from
> a range of tuple(key, value).
>
Oh yes.
> - Optional: Zip and other pairing ranges to yield tuple (currently for
> efficiency they yield a pair of pointers. But this breaks abstraction. Using
> a more common data structure has significant advantages. The compiler can
> recognize the idiom and in some cases can avoid the creation of the Tuples
> that Zip produce.
>
I don't like the idea of compiler magic, but I do like the idea of having a
Zip that uses the standard structure: tuples. Its easier to inferface with
other functions this way. The Proxy from phobos zip is good for sorting
(which is why Andrei defined it this way, I guess), but it's a pain to use
otherwise, because it's a one-of-a-kind struct that cannot be fed to other
functions.
> Tuple unpacking is quite handy (the following syntax is just an
> syntax-idea, other syntaxes can be used. This syntax is not valid in C, so I
> think this syntax can be used in D):
>
> auto foo() {
>return tuple(10, "hello");
> }
> void main() {
>(int n, string s) = foo();
>
I also woud like that. While waiting to convince Walter, we can use some
poor man alternative like this one:
void copy(T...)(ref T to, Tuple!T from)
{
foreach(i,Type; T)
{
to[i] = from.field[i];
}
}
usage:
auto t = tuple(1, 3.14, "abc");
int i; double d; string s;
copy(i,d,s, t);
otherwise, you can use this:
auto ids = t.expand;
ids is an instantiated typetuple: you can index it (ids[1]), slice it
(ids[0..2]), iterate on it with foreach, etc.
The only thing you cannot do is returning it from a function ...
I know it's not as good as what you want (where you define and assign you n
and s in one go).
>writeln(n, " ", s);
>(n, s) = foo(); // calls is again
>int[] arr = [1, 2, 3];
>(int a, int b, int c) = arr; // other kind of unpacking
>
I experimented with a struct called RefTuple, that took constructor values
by ref and that did the kind of destructuring you present here. I created it
with a function called _ (yes, just _).
This gave the following syntax:
int n; string s;
_(n,s) = foo();
>
> This is the syntax that can be currently used:
>
> auto foo() {
>T1 alpha = computeIt1(...);
>T1 alpha = computeIt2(...);
>return Tuple!(T1, "alpha", T2, "beta")(alpha, beta);
>//return tuple(alpha, beta); // alternative
> }
> void main() {
>auto alpha_beta = foo();
>use1(alpha_beta.alpha);
>use2(alpha_beta.beta);
>use1(alpha_beta.field[0]); // alternative
>use2(alpha_beta.field[1]); // alternative
> }
>
You ca
Re: LDC, GDC for D2
On Thu, 01 Jul 2010 18:44:55 +0100, Robert Clipsham wrote: > On 30/06/10 22:06, mwarning wrote: >> On Wed, 30 Jun 2010 18:14:47 +, dsimcha wrote: >> >>> Now that Andrei's book is out and the D2 spec is (fairly) stable, is >>> there going to be any serious effort to port LDC to D2? Also, >>> regarding GDC, I've noticed that no D2-related checkins have happened >>> in a long time. >>> >>> In both cases, is there any good technical reason for the lack of >>> focus on D2, or is it just that D2 has stabilized very recently and >>> given the limited resources of these projects, D1 is considered a >>> higher priority? >> >> The contributors so far don't have time any more or just lost interest. >> It's probably no big issue to give ppl svn access when they want to >> give it a try to work on ldc. > > I was maintaining LDC 2, unfortunately I became rather busy which > hindered my efforts. I had an email a couple of days ago from someone > who seemed interested in reviving it, I'm not sure how committed he was > to it though. Should he offer some good patches D2 wise I'm sure there'd > be no issue with giving him commit access. > Thanks for the confirmation Robert!
Re: D: An Up and Coming Embedded Software Language
Walter Bright:
> And on Reddit:
> http://www.reddit.com/r/programming/comments/ckxjv/d_an_up_and_coming_embedded_software_language/
Someone can write an answer to this:
http://www.reddit.com/r/programming/comments/ckxjv/d_an_up_and_coming_embedded_software_language/c0tbaln
Some partial comments:
- The usage of override keyword will probably become obligatory in D, even when
you don't use -w, see bug 3836.
- Templates are not the best thing, but type classes can require a new type
system and C++ programmers need to learn them.
- Using templates instead of OOP: void foo(T)(T x, T y) if (isNumeric!T) {}
- "Additionally, type equality of different values should be expressible in the
type system." I don't know if this refers to structural typing, but D is
designed differently. For nominative equality you can use is(T == U).
- The D variable/type declaration syntax is not the best possible, the Go one
looks a bit better, but...
Bye,
bearophile
Re: Part 1 of the Language Reference Docs Review
Okay, I've done some more reviewing and covered these: structs, classes, interfaces, enums, const, functions, contracts. I've not yet touched op-overloading, templates and a bunch of others. Anyways, I've noticed this Tracker in the bug-reports: http://d.puremagic.com/issues/show_bug.cgi?id=677 That one's for D1 (and it seems abandoned). I was thinking of making one for D2, and linking each language spec issue to the Depends On field. Btw., who is in charge of editing the spec page? I'd love to volunteer if the person needs an extra hand with the edits..
Re: LDC, GDC for D2
On 30/06/10 22:06, mwarning wrote: On Wed, 30 Jun 2010 18:14:47 +, dsimcha wrote: Now that Andrei's book is out and the D2 spec is (fairly) stable, is there going to be any serious effort to port LDC to D2? Also, regarding GDC, I've noticed that no D2-related checkins have happened in a long time. In both cases, is there any good technical reason for the lack of focus on D2, or is it just that D2 has stabilized very recently and given the limited resources of these projects, D1 is considered a higher priority? The contributors so far don't have time any more or just lost interest. It's probably no big issue to give ppl svn access when they want to give it a try to work on ldc. I was maintaining LDC 2, unfortunately I became rather busy which hindered my efforts. I had an email a couple of days ago from someone who seemed interested in reviving it, I'm not sure how committed he was to it though. Should he offer some good patches D2 wise I'm sure there'd be no issue with giving him commit access. Robert http://octarineparrot.com/
Re: Spikes in array capacity
Steven Schveighoffer wrote: On Thu, 01 Jul 2010 12:46:27 -0400, Ali Çehreli wrote: There is something strange in the array capacity algorithm. ... length: 1153022 capacity: 1154045 ratio: 1.00089 length: 1154046 capacity: 1155069 ratio: 1.00089 length: 1155070 capacity: 3153917 ratio: 2.7305<-- spike length: 3153918 capacity: 3154941 ratio: 1.00032 length: 3154942 capacity: 3155965 ratio: 1.00032 No, that is not intended. Please file a bugzilla against druntime. http://d.puremagic.com/issues/show_bug.cgi?id=4412 Thanks, Ali
D: An Up and Coming Embedded Software Language
https://spin.atomicobject.com/2010/06/30/d-little-language-that-could?utm_source=social-media&utm_medium=social-media&utm_campaign=technical And on Reddit: http://www.reddit.com/r/programming/comments/ckxjv/d_an_up_and_coming_embedded_software_language/
Re: Spikes in array capacity
On Thu, 01 Jul 2010 12:46:27 -0400, Ali Çehreli wrote:
There is something strange in the array capacity algorithm.
import std.stdio;
import std.array;
void main()
{
int[] a;
size_t oldCapacity;
foreach (i; 0 .. 100_000_000) {
a ~= i;
if (a.capacity != oldCapacity) {
writeln("length: ", a.length,
" capacity: ", capacity(a),
" ratio: ", cast(double)capacity(a) / oldCapacity);
oldCapacity = capacity(a);
}
}
}
Produces:
length: 1 capacity: 3 ratio: infplease ignore this one ;)
length: 4 capacity: 7 ratio: 2.3
length: 8 capacity: 15 ratio: 2.14286
length: 16 capacity: 31 ratio: 2.06667
length: 32 capacity: 63 ratio: 2.03226
length: 64 capacity: 127 ratio: 2.01587
length: 128 capacity: 255 ratio: 2.00787
length: 256 capacity: 509 ratio: 1.99608
length: 512 capacity: 1021 ratio: 2.00589
length: 1022 capacity: 2045 ratio: 2.00294
length: 2046 capacity: 3069 ratio: 1.50073
length: 3070 capacity: 4093 ratio: 1.33366
length: 4094 capacity: 5117 ratio: 1.25018
...
length: 1153022 capacity: 1154045 ratio: 1.00089
length: 1154046 capacity: 1155069 ratio: 1.00089
length: 1155070 capacity: 3153917 ratio: 2.7305<-- spike
length: 3153918 capacity: 3154941 ratio: 1.00032
length: 3154942 capacity: 3155965 ratio: 1.00032
...
length: 4741118 capacity: 4742141 ratio: 1.00022
length: 4742142 capacity: 4743165 ratio: 1.00022
length: 4743166 capacity: 12333053 ratio: 2.60017 <-- spike
length: 12333054 capacity: 12334077 ratio: 1.8
length: 12334078 capacity: 12335101 ratio: 1.8
... (there are more spikes later on)
Is that intended?
Ali
No, that is not intended. Please file a bugzilla against druntime.
-Steve
Re: Network I/O and streaming in D2
On Thu, 01 Jul 2010 12:31:19 -0400, Walter Bright wrote: Steven Schveighoffer wrote: I really think D needs to replace FILE * with it's own buffering scheme. That way we can control the underlying buffering and have access to it. We can also take advantage of D features that aren't available in the underlying code, such as thread local storage to avoid taking global locks. This isn't done because mixing D and C I/O is a desirable property. It can still be this way, just have a special D buffer implementation that outputs to a FILE * or reads from it. But I shouldn't be *required* to deal with FILE * when I open a file or network socket and only ever use it in D. Even though it's desirable, there are considerable drawbacks that need to be justified. -Steve
Re: Can someone explain why this is not an error?
I don't think this is really a special case: they are all sharing the same keywords. immutable a = 1, b = "a"; // both a and b are immutable string a = "a", b = "b"; // both a and b are strings immutable int a = 1, b = 2; // both a and b are immutable ints I'd say the bug is that the documentation uses the wrong word; it isn't "the same type" but rather that all must match the... stuff... on the left, so the comma separated list is identifiers and initializers, not types and storage classes (I don't know how to word it best, but it makes perfect sense.) What it forbids is C's habit of surprising you: int* a, b; // surprise, b is of type int! But, there's nothing really surprising in the immutable case. All variables are indeed immutable (and auto, which is inferred from the missing type).
Re: Can someone explain why this is not an error?
On 7/1/10, Adam Ruppe wrote: > (and auto, which is inferred from the missing type). Nitpicking myself, but I shouldn't have said that; auto is just the default storage class, and it is the missing type that means infer it, not the auto keyword. I think you know what I mean though.
Spikes in array capacity
There is something strange in the array capacity algorithm.
import std.stdio;
import std.array;
void main()
{
int[] a;
size_t oldCapacity;
foreach (i; 0 .. 100_000_000) {
a ~= i;
if (a.capacity != oldCapacity) {
writeln("length: ", a.length,
" capacity: ", capacity(a),
" ratio: ", cast(double)capacity(a) / oldCapacity);
oldCapacity = capacity(a);
}
}
}
Produces:
length: 1 capacity: 3 ratio: infplease ignore this one ;)
length: 4 capacity: 7 ratio: 2.3
length: 8 capacity: 15 ratio: 2.14286
length: 16 capacity: 31 ratio: 2.06667
length: 32 capacity: 63 ratio: 2.03226
length: 64 capacity: 127 ratio: 2.01587
length: 128 capacity: 255 ratio: 2.00787
length: 256 capacity: 509 ratio: 1.99608
length: 512 capacity: 1021 ratio: 2.00589
length: 1022 capacity: 2045 ratio: 2.00294
length: 2046 capacity: 3069 ratio: 1.50073
length: 3070 capacity: 4093 ratio: 1.33366
length: 4094 capacity: 5117 ratio: 1.25018
...
length: 1153022 capacity: 1154045 ratio: 1.00089
length: 1154046 capacity: 1155069 ratio: 1.00089
length: 1155070 capacity: 3153917 ratio: 2.7305<-- spike
length: 3153918 capacity: 3154941 ratio: 1.00032
length: 3154942 capacity: 3155965 ratio: 1.00032
...
length: 4741118 capacity: 4742141 ratio: 1.00022
length: 4742142 capacity: 4743165 ratio: 1.00022
length: 4743166 capacity: 12333053 ratio: 2.60017 <-- spike
length: 12333054 capacity: 12334077 ratio: 1.8
length: 12334078 capacity: 12335101 ratio: 1.8
... (there are more spikes later on)
Is that intended?
Ali
Re: Can someone explain why this is not an error?
FeepingCreature:
> Type deduction is a special case. I think the above was written before we had
> it.
OK. Special cases in a language are often bad, and I don't think that syntax is
significantly handy. So if you agree Bernard Helyer can put it in bugzilla,
asking to remove this special case:
void main() {
immutable a1 = 3, b1 = "hello";
auto a2 = 3, b2 = "hello";
static a3 = 3, b3 = "hello";
const a4 = 3, b4 = "hello";
}
Bye,
bearophile
Re: Network I/O and streaming in D2
Steven Schveighoffer wrote: I really think D needs to replace FILE * with it's own buffering scheme. That way we can control the underlying buffering and have access to it. We can also take advantage of D features that aren't available in the underlying code, such as thread local storage to avoid taking global locks. This isn't done because mixing D and C I/O is a desirable property.
Re: Better tuples
On 6/30/2010 8:03 PM, bearophile wrote: Eric Poggel: would it make sense to make struct instances and tuples the same thing?< It's a nice idea, but if all structs become tuples, and D needs to support separate compilation, then modules that define structs need to contain the compiled methods (instantiated templates) that implement all the features of Tuples. So to keep programs small I think it's better to keep structs simple, and define a Tuple with richer semantics. Bye, bearophile That's a shame. I feel like this (along with functions and delgates being different) is one of the areas where the complexity of the language really shows itself. I really liked the proposals you presented though.
Re: Can someone explain why this is not an error?
I think :
Ýmmutable, type automatic moments. Because, it is StorageClass.
Example :
import std.stdio;
void main()
{
immutable a = 3, b = 4.2, c = true;
writeln(typeof(a).stringof,typeof(b).stringof,typeof(c).stringof);
}
or
import std.stdio;
void main()
{
auto a = 3, b = 4.2, c = true;
writeln(typeof(a).stringof,typeof(b).stringof,typeof(c).stringof);
}
Keywords(StorageClass):
abstract
auto
const
deprecated
extern
final
immutable
shared
nothrow
override
pure
scope
static
synchronized
I don't know English. I'm sorry if misspelled.
Re: Can someone explain why this is not an error?
On 01.07.2010 11:49, Bernard Helyer wrote:
> http://www.digitalmars.com/d/2.0/declaration.html
>
> "In a declaration declaring multiple symbols, all the declarations must
> be of the same type:"
>
> Yet this compiles:
>
> ---
> void main()
> {
> immutable a = 3, b = 4.2, c = true;
> }
> ---
>
> a, b, and c all have different types. Unless you consider the type as
> 'type to be inferred'. Can anyone explain this behaviour to me?
>
Type deduction is a special case. I think the above was written before we had
it.
Re: GUI Library for D2+Phobos
On 07/01/2010 03:12 PM, Max Samukha wrote: On 01.07.2010 14:04, Trass3r wrote: The link doesn't work for me. This one should work http://d-coding.clanteam.com/generator.zip I've created a ticket http://www.dsource.org/projects/qtd/ticket/54. We'd better move the discussion there.
Re: GUI Library for D2+Phobos
On 01.07.2010 14:04, Trass3r wrote: The link doesn't work for me. This one should work http://d-coding.clanteam.com/generator.zip
Re: Network I/O and streaming in D2
On Wed, 30 Jun 2010 13:13:33 -0400, Andrei Alexandrescu wrote: Walter Bright wrote: Adam Ruppe wrote: My network thing is very simple: it opens a socket, then wraps it up in a File struct, via FILE*. Then, you can treat it the same way. That's the traditional way to do it, but I'm not so sure it's the right way for the future. Wouldn't it be better to have an interface to it that is a range, rather than pretend it's a FILE* ? I initially also thought that a file (or socket etc.) should be a range, but then I realized that that would overload roles. It's best to have a handle/ranges architecture in which the handle (e.g. File) is responsible for opening, closing, and managing the connection, and several ranges are responsible for fetching data in various ways (by character, by chunk, by line etc.) BTW I'm virtually done implemented readf. I only need to parse floating-point numbers and strtod won't work. Walter, could you please email me your strtod implementation? Thanks. The current issue with readf (and other similar formatted read routines) is that they require a primitive peek() that looks up the current character in a stream without swallowing it. This is not a FILE* primitive, but can be simulated (slow) by using getc() and ungetc(). Fortunately on GNU's I/O libs peek() is easy to define (actually they have an internal routine by that name), and on Windows dmd uses Walter's I/O library, which again has fast peek(). I really think D needs to replace FILE * with it's own buffering scheme. That way we can control the underlying buffering and have access to it. We can also take advantage of D features that aren't available in the underlying code, such as thread local storage to avoid taking global locks. -Steve
Re: Using ()s in @property functions
On Wed, 30 Jun 2010 00:33:54 -0400, Robert Jacques
wrote:
I agree with you from a under-the-hood perspective, but I wasn't asking
about that. I was asking about the leak in the @property abstraction.
Not being able to pass non-ref @properties to functions by ref is a
fairly serious (i.e. common) break/leak in the @property abstraction:
that @properties should be "virtually indistinguishable from a field".
properties are not fields, they are restricted fields. That is, you can
completely control access to a property, but you cannot control access to
a field.
With a field, you cannot control:
- Who has an address to it
- What the user sets it to
- The action of setting or getting it.
Properties allow control over those things. The drawback is you cannot
use it exactly like a field.
I think we would all agree that the main mode of access to a field is:
container.field = x;
x = container.field;
Properties mimic that functionality perfectly, and that is pretty much it.
The one thing I'd like to see for properties is some sort of "property
delegate." This could be generated in a struct. What I don't know is how
to make it as "virtual" as a real delegate.
Another thing I'd like to see (brought up elsewhere in this thread) is
some sort of __traits/meta means to get a delegate to a property setter or
getter, since with required omission of parens, you can no longer get a
delegate to the property. This solution could also be amended to solve
another pet peeve of mine:
struct S
{
@property void foo(int x);
@property void foo(string s);
}
S s;
auto d1 = meta.delegateOf(s.foo, int);
auto d2 = meta.delegateOf(s.foo, string);
-Steve
Re: Iterating over containers of immutable objects
On Tue, 29 Jun 2010 19:08:13 -0400, Justin Johansson wrote:
Steven Schveighoffer wrote:
On Tue, 29 Jun 2010 18:42:18 -0400, Justin Johansson
wrote:
Steven Schveighoffer wrote:
There is another solution which requires introducing an extra virtual
method (and associated cost thereof) namely "hasNext" to the iterator
interface. This allows pulling a single item (if it exists) out of
the iterator on demand.
Duh... I just thought of this too:
while(auto bar = iter.next()) // line 37
{
...
}
Sorry that does not compile, dunno if it should I'm using
the latest D2.
test.d(37): expression expected, not 'auto'
test.d(37): found 'bar' when expecting ')'
test.d(37): found '=' instead of statement
test.d(41): unrecognized declaration
Hm... a common idiom to deal with whether an object casts to a type is
this:
if(auto c = cast(C)obj)
{
// use c
}
I wonder why while doesn't work...
Walter?
-Steve
Re: GUI Library for D2+Phobos
The link doesn't work for me.
Re: Can someone explain why this is not an error?
On Thu, 01 Jul 2010 06:26:34 -0400, dolive wrote: > immutable int a = 3, b = 4.2, c = true; // is error Uhhh, yes. Yes it is. ?_?
Re: Can someone explain why this is not an error?
Bernard Helyer дµ½:
> http://www.digitalmars.com/d/2.0/declaration.html
>
> "In a declaration declaring multiple symbols, all the declarations must
> be of the same type:"
>
> Yet this compiles:
>
> ---
> void main()
> {
> immutable a = 3, b = 4.2, c = true;
> }
> ---
>
> a, b, and c all have different types. Unless you consider the type as
> 'type to be inferred'. Can anyone explain this behaviour to me?
>
immutable int a = 3, b = 4.2, c = true; // is error
Re: GUI Library for D2+Phobos
On 01.07.2010 12:16, Trass3r wrote: Though it should work. The one in qt/bin has the right mangling. 002F FC64 002E 0021D8FD _Z17qt_message_output9QtMsgTypePKc Can you replace generator.exe with http://content5.files.mail.ru/U614WO/14cd74a490b9316173600cd95e161df6 and see if it starts? If it does, there's something wrong with mingw toolchain or the way it is invoked in the build script.
Can someone explain why this is not an error?
http://www.digitalmars.com/d/2.0/declaration.html
"In a declaration declaring multiple symbols, all the declarations must
be of the same type:"
Yet this compiles:
---
void main()
{
immutable a = 3, b = 4.2, c = true;
}
---
a, b, and c all have different types. Unless you consider the type as
'type to be inferred'. Can anyone explain this behaviour to me?
Re: GUI Library for D2+Phobos
Though it should work. The one in qt/bin has the right mangling. 002FFC64002E0021D8FD _Z17qt_message_output9QtMsgTypePKc
Re: GUI Library for D2+Phobos
Strangefully there are 2 different versions in bin and qt/bin. I think the one in qt/bin is loaded because I added qt/bin to PATH which seems to be compiled with MSVC?!
