Readln returns a string which contains the line terminator.
Is there a grand reason for this?
Currently there are a few drawbacks with this. The naive user doesn't
expect it, and the seasoned user has to keep stripping it. And then he
has to search the docs (or get hold of other OSs) to deter
Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> Actually, I've been thinking and I realised that in 95% of cases, you
>> can assume a range is resumable if it has no references.
>
> Well I'm not so sure. How about a range around an integral file handle
> or socket?
Most of the time, I'd expe
Andrei Alexandrescu wrote:
Daniel Keep wrote:
Actually, I've been thinking and I realised that in 95% of cases, you
can assume a range is resumable if it has no references.
Well I'm not so sure. How about a range around an integral file handle
or socket?
If ranges can advertise their resuma
Daniel Keep wrote:
Actually, I've been thinking and I realised that in 95% of cases, you
can assume a range is resumable if it has no references.
Well I'm not so sure. How about a range around an integral file handle
or socket?
If it has no
references, the only way the range can be non-resu
bearophile wrote:
Benji Smith:
Especially since an associative array should have a .keys property that
returns a set.
I don't agree. I think associative arrays should have .keys/.values/.items that return a
lazy view that acts like a .set/.list/.list of pairs. Such "lazy views" don't
actua
Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>> ...
>
> So essentially we're looking at a symbolic approach - a resumable range
> would need to advertise that. I've used that for isSorted too, and it
> works pretty well.
>
> The remaining question is one of defaults - are most ranges resumab
On Mon, 13 Apr 2009 14:54:57 -0400, Frits van Bommel
wrote:
Sean Kelly wrote:
Leandro Lucarella wrote:
But right now gc_malloc() doesn't take any TypeInfo argument. I can't
see
where I can get the TypeInfo in the first place =/
The call would have to be modified. Right now the best you
Frits van Bommel, el 13 de abril a las 20:33 me escribiste:
> >But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
> >where I can get the TypeInfo in the first place =/
>
> Ah, you're right. But if you'll look at your nearest lifetime.d[1]
> you'll see that all the allocation
Daniel Keep wrote:
Looking at the documentation, I found std.range.isForwardRange. I had a
look at the implementation, and it basically just checks to make sure
you can do this:
R r1;
R r2 = r1;
How do you construct an input range which is not also a forward range?
In fact you can't. Thank
bearophile wrote:
Does someone has some need for Ternary Search Trees into Phobos (for D1. And
eventually later for D2 too)?
TSTs allow to find keys, key prefixes, or even keys with holes. Keys are arrays
of T, where T is the template type.
They can be designed to store the keys alone, or as an
Sean Kelly wrote:
Leandro Lucarella wrote:
But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
where I can get the TypeInfo in the first place =/
The call would have to be modified. Right now the best you can do is
pass BlkAttr.NO_SCAN. And storing a pointer per block
Kagamin wrote:
Michel Fortin Wrote:
is there still a reason for
it to require an empty parenthesis?
It's a function :)
So is unittest.
Andrei Alexandrescu wrote:
Lars Kyllingstad wrote:
Michel Fortin wrote:
On 2009-04-12 11:09:51 -0400, Lars Kyllingstad
said:
Andrei Alexandrescu wrote:
Lars Kyllingstad wrote:
I think isInfinite!() should be called isInfiniteRange!(). The
current name is, in my opinion, too general.
I'm
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced from the stack, and move
anything that is only referenced from the heap.
That's m
Paul D. Anderson wrote:
Don Wrote:
Paul D. Anderson wrote:
The implementation will comply with IEEE 754-2008. I just wanted to illustrate
that precision can depend on the operation as well as the operands.
Paul
I'm not sure why you think there needs to be a precision depending on
the operat
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced from the stack, and move
anything that is only referenced from the heap.
That's m
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
> Leandro Lucarella wrote:
> >Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
> Or you can pin anything that's referenced from the stack, and move
> anything that is only referenced from the heap.
> >>>That's more likel
Don Wrote:
> Paul D. Anderson wrote:
> >
> > The implementation will comply with IEEE 754-2008. I just wanted to
> > illustrate that precision can depend on the operation as well as the
> > operands.
> >
> > Paul
>
> I'm not sure why you think there needs to be a precision depending on
> the
Michel Fortin wrote:
> I disagree. How adding the "is" it disambiguate between the predicate
> and the assertion? "x.isBounded" reads more like "x is bounded" (the
> assertion) than "is x bounded" (the predicate).
Method syntax usually leads to incorrect word order. "a.b(c)", should
not be read a
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced from the stack, and move
anything that is only referenced from the heap.
That's more likely to happen, but it requires a compiler change too
(provide type information o
On Mon, Apr 13, 2009 at 3:00 PM, Denis Koroskin <2kor...@gmail.com> wrote:
> On Mon, 13 Apr 2009 16:44:25 +0400, Tomas Lindquist Olsen
> wrote:
>
>> On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
>> wrote:
>>>
>>> Kagamin wrote:
Stewart Gordon Wrote:
> At the moment, the pro
Frits van Bommel wrote:
Stewart Gordon wrote:
[rearrangement of class fields]
Right, forgot about that bit. Probably because AFAIK no D compiler
actually reorganizes them...
(How does this combine with the "D ABI" anyway? I know binary
compatibility between the different compilers is a bi
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
> >>Or you can pin anything that's referenced from the stack, and move
> >>anything that is only referenced from the heap.
> >That's more likely to happen, but it requires a compiler change too
> >(provide type information on allocation).
Lars Kyllingstad wrote:
Michel Fortin wrote:
On 2009-04-12 11:09:51 -0400, Lars Kyllingstad
said:
Andrei Alexandrescu wrote:
Lars Kyllingstad wrote:
I think isInfinite!() should be called isInfiniteRange!(). The
current name is, in my opinion, too general.
I'm undecided about this (and s
On Mon, 13 Apr 2009 01:45:00 -0400, bearophile
wrote:
dsimcha:
What if the key is a long?
At the moment an AA like this:
byte[long] aa;
allocates 16 or more bytes/pair, so it needs the same memory as:
long[long] aa;
A built-in set can of course use only about 8 bytes (plus few empty
cel
Stewart Gordon wrote:
Frits van Bommel wrote:
Kagamin wrote:
Such mood was always in the spec: "AlignAttribute is ignored when
applied to declarations that are not structs or struct members".
I never saw that before. So it doesn't work for class members?
http://www.digitalmars.com/d/1.0/c
I came upon realization that you can already create properties
accepting various operators in D, using a template mixin. The only
missing part is getting the value without a getter function.
struct Z
{
int value2Cache;
template Property()
{
int v
On Mon, 13 Apr 2009 16:44:25 +0400, Tomas Lindquist Olsen
wrote:
On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
wrote:
Kagamin wrote:
Stewart Gordon Wrote:
At the moment, the problem seems to be that the compiler is silently
ignoring many cases of (a), (b) and (c) alike. Some people
Frits van Bommel wrote:
Kagamin wrote:
Such mood was always in the spec: "AlignAttribute is ignored when
applied to declarations that are not structs or struct members".
I never saw that before. So it doesn't work for class members?
http://www.digitalmars.com/d/1.0/class.html
"The D compil
On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
wrote:
> Kagamin wrote:
>>
>> Stewart Gordon Wrote:
>>
>>> At the moment, the problem seems to be that the compiler is silently
>>> ignoring many cases of (a), (b) and (c) alike. Some people argue that the
>>> spec doesn't forbid such use of inapp
Kagamin wrote:
Stewart Gordon Wrote:
At the moment, the problem seems to be that the compiler is silently
ignoring many cases of (a), (b) and (c) alike. Some people argue that
the spec doesn't forbid such use of inapplicable attributes explicitly,
and so the compiler's treatment of these can
Michel Fortin wrote:
D 2.020's changelog:
- immutable now is implemented.
I though this meant that invariant was replaced by immutable as a type
modifier.
My first reaction was to look for documentation on what the keyword
means and have no success. And so I filed this
http://d.pure
Leandro Lucarella wrote:
Christopher Wright, el 12 de abril a las 17:54 me escribiste:
Absolutely. When writing parallel code to do large scale data mining in D, the
lack of precision and multithreaded allocation are real killers. My interests
are, in order of importance:
1. Being able to al
Does someone has some need for Ternary Search Trees into Phobos (for D1. And
eventually later for D2 too)?
TSTs allow to find keys, key prefixes, or even keys with holes. Keys are arrays
of T, where T is the template type.
They can be designed to store the keys alone, or as an associative data
s
On 2009-04-13 01:53:41 -0400, bearophile said:
(Incidentally, I also think the natural set operations, like
intersection and mutual exclusion, are just as handy for maps as for sets.)
It's less semantically clean to define certain set operations on AAs,
because for example you have to decide
On 2009-04-13 04:20:32 -0400, Lars Kyllingstad
said:
...except that my example, and indeed any range produced by sequence,
recurrence, etc. are bounded at one end. Thus the term "infinite range"
is more precise, and fits in well with the mathematical terms "infinite
series" and "infinite seq
On 2009-04-13 03:56:11 -0400, Rainer Deyke said:
Michel Fortin wrote:
Which makes me think of one thing: why "isBounded" instead of plain and
simple "bounded"? Ranges don't respond to "isEmpty": they have "empty"
instead.
"bounded(x)" can be read as a predicate ("Is x bounded?"), an assertio
On Sun, 12 Apr 2009 22:00:43 +0300, Walter Bright
wrote:
Jarrett Billingsley wrote:
Whether it'll be going away, I'm not sure. I guess Walter is the only
one who knows that.
I see no point to breaking invariant() again.
Will 'invariant' as a type modifier go away? If so, then of course th
Stewart Gordon Wrote:
> At the moment, the problem seems to be that the compiler is silently
> ignoring many cases of (a), (b) and (c) alike. Some people argue that
> the spec doesn't forbid such use of inapplicable attributes explicitly,
> and so the compiler's treatment of these cannot be ca
Michel Fortin Wrote:
> is there still a reason for
> it to require an empty parenthesis?
It's a function :)
Michel Fortin wrote:
On 2009-04-12 11:09:51 -0400, Lars Kyllingstad
said:
Andrei Alexandrescu wrote:
Lars Kyllingstad wrote:
I think isInfinite!() should be called isInfiniteRange!(). The
current name is, in my opinion, too general.
I'm undecided about this (and similar cases). isInfinite
Michel Fortin wrote:
> Which makes me think of one thing: why "isBounded" instead of plain and
> simple "bounded"? Ranges don't respond to "isEmpty": they have "empty"
> instead.
"bounded(x)" can be read as a predicate ("Is x bounded?"), an assertion
("x is bounded, so treat it as such.") or even
42 matches
Mail list logo
