BCS wrote:
Adding a 2nd binary to the zip file (or a 2nd zip file) shouldn't be
hard if the build is set up well.
I don't understand how that would be useful if you're not able to build
the compiler.
make debdmd
is the way to do it.
Steven Schveighoffer wrote:
On Sat, 06 Mar 2010 19:41:57 -0500, BLS wrote:
..and frankly said I wonder .. no offense.. why you are the (only) one
who is creating and designing the collection library ?
finally :
from a pragmatic view > why create from scratch instead of reusing
Stevens data-s
Sun, 07 Mar 2010 05:05:03 +, BCS wrote:
> Hello Jane,
>
>> Is D a cult?
>>
>>
> No, not yet. Walter hasn't figured out how to brain wash people over a
> newsgroup yet. However I think Andrei's working on it and Don should
> have a patch in time for TDPL going out ;b
FWIW, I think there is
Steven Schveighoffer wrote:
On Sat, 06 Mar 2010 14:55:49 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
In the STL world, writing container-independent code is generally
shunned (see e.g.
http://www.informit.com/content/images/0201749629/items/ite
retard Wrote:
> Sun, 07 Mar 2010 05:05:03 +, BCS wrote:
>
> > Hello Jane,
> >
> >> Is D a cult?
> >>
> >>
> > No, not yet. Walter hasn't figured out how to brain wash people over a
> > newsgroup yet. However I think Andrei's working on it and Don should
> > have a patch in time for TDPL go
I am coming late into this discussion, some comments:
I like a duck typing approach whenever possible, and don't need runtime
adaptability (which seems to be in line with others)
different container have different trade offs, and switching between
them should be a design choice
Generic algo
retard wrote:
> Sun, 07 Mar 2010 05:05:03 +, BCS wrote:
>
>> Hello Jane,
>>
>>> Is D a cult?
>>>
>>>
>> No, not yet. Walter hasn't figured out how to brain wash people over a
>> newsgroup yet. However I think Andrei's working on it and Don should
>> have a patch in time for TDPL going out
Robert Jacques Wrote:
> On Sat, 06 Mar 2010 21:54:50 -0500, Steven Schveighoffer
> wrote:
> > On Sat, 06 Mar 2010 11:19:15 -0500, Robert Jacques
> > wrote:
> >
> >> On Sat, 06 Mar 2010 08:19:36 -0500, Steven Schveighoffer
> >> wrote:
> >>>
> >>> How can softRemove not affect iterating ran
Sat, 06 Mar 2010 21:30:35 -0500, bearophile wrote:
> In D null can also be used to represent an empty associative array. If
> you think of AAs as instances of a class to be used by reference, then
> using a null to represent an empty AA is meaningful (the main difference
> is that you don't need "
Sun, 07 Mar 2010 14:12:14 +0100, Lutger wrote:
> retard wrote:
>
>> Sun, 07 Mar 2010 05:05:03 +, BCS wrote:
>>
>>> Hello Jane,
>>>
Is D a cult?
>>> No, not yet. Walter hasn't figured out how to brain wash people over a
>>> newsgroup yet. However I think Andrei's working on
This comes from a small thread that is going on in digitalmars.D.learn.
This program asserts:
import std.c.string;
struct S { // 16 bytes, with a hole
ushort s;
double d;
}
void main() {
S s1, s2;
memset(&s1, ubyte.min, S.sizeof);
memset(&s2, ubyte.max, S.sizeof);
s1.s =
On 2010-03-07 15:09:53 +0100, bearophile said:
This comes from a small thread that is going on in digitalmars.D.learn.
This program asserts:
import std.c.string;
struct S { // 16 bytes, with a hole
ushort s;
double d;
}
void main() {
S s1, s2;
memset(&s1, ubyte.min, S.sizeof)
retard wrote:
> Sun, 07 Mar 2010 14:12:14 +0100, Lutger wrote:
>
>> retard wrote:
>>
>>> Sun, 07 Mar 2010 05:05:03 +, BCS wrote:
>>>
Hello Jane,
> Is D a cult?
>
>
No, not yet. Walter hasn't figured out how to brain wash people over a
newsgroup yet. Howeve
Fawzi Mohamed:
>I am not sure of what is the best solution,<
This is true for me too, that's why I have created this thread, to find a way
to solve this problem.
>I am not sure that defining a special comparison operation by default for each
>struct is the correct solution (it can be quite so
There are other solutions.
For example remove the current opEquals from structs, so doing == among two
structs become a syntax error. And then add a property like @equable that when
present beside the struct name adds a specific and correct and recursive
opEquals to it.
@equable stuct Foo {
i
Nick Sabalausky wrote:
> "Chad J" wrote in message
> news:hmul75$qs...@digitalmars.com...
>
> ...
>
>> Question though, why not just have llvm emit code in another language?
>
> A few (admittedly not very big) reasons, in no order:
>
> - I wanted some experience writing lexer/parser code on m
On 2010-03-07 14:23:03 +0100, Steven Schveighoffer said:
Robert Jacques Wrote:
On Sat, 06 Mar 2010 21:54:50 -0500, Steven Schveighoffer
wrote:
On Sat, 06 Mar 2010 11:19:15 -0500, Robert Jacques
wrote:
On Sat, 06 Mar 2010 08:19:36 -0500, Steven Schveighoffer
wrote:
How can softRemove n
On Sun, 07 Mar 2010 08:23:03 -0500, Steven Schveighoffer
wrote:
Robert Jacques Wrote:
On Sat, 06 Mar 2010 21:54:50 -0500, Steven Schveighoffer
wrote:
> On Sat, 06 Mar 2010 11:19:15 -0500, Robert Jacques
> wrote:
>
>> On Sat, 06 Mar 2010 08:19:36 -0500, Steven Schveighoffer
>> wrote:
>>>
bearophile wrote:
This comes from a small thread that is going on in digitalmars.D.learn.
This program asserts:
import std.c.string;
struct S { // 16 bytes, with a hole
ushort s;
double d;
}
void main() {
S s1, s2;
memset(&s1, ubyte.min, S.sizeof);
memset(&s2, ubyte.max, S.
retard wrote:
Let's see what features I had in mind:
- Algrebraic data types
std.variant covers this.
- Pattern matching (extension to enum/string/integer accepting switch)
Andrei and Sean have shown how to do that nicely with existing language
features.
- Higher kinded types
Don't k
retard wrote:
The associative array is a sad type in D. It has nasty semantics. I'd
like to see it as a real library defined type with just syntactic sugar
for constructing literals. Too bad that's not what Walter thinks.
Actually, that's how D2 associative arrays are done.
retard wrote:
Sat, 06 Mar 2010 21:30:35 -0500, bearophile wrote:
In D null can also be used to represent an empty associative array. If
you think of AAs as instances of a class to be used by reference, then
using a null to represent an empty AA is meaningful (the main difference
is that you don
Walter Bright Wrote:
> retard wrote:
> > The associative array is a sad type in D. It has nasty semantics. I'd
> > like to see it as a real library defined type with just syntactic sugar
> > for constructing literals. Too bad that's not what Walter thinks.
>
> Actually, that's how D2 associativ
bearophile wrote:
But a correctly implemented opEquals (and opCmp) among structs has to
ignore the contents of the holes, because they can be filled with
anything,
The "holes" are defined to be filled with 0, and are when initialized by
the compiler. This is specifically so that memcmp can be
In this post I am *not* asking for new features in D, I just try to give few
answers :-) I think most of those things are not fit for D, they require a
different language, a different compiler, different programmers, and probably a
different compiler writer too :-) (I think in D for example list
Fawzi Mohamed wrote:
one could argue that the unsafe operation is memset.
That's right.
The compiler always initializes a struct, so that what you describe
should never happen in a safe program.
Right.
Still as you say the following example that might indeed considered a bug:
S s1=void
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
> retard wrote:
>> Let's see what features I had in mind:
>>
>> - Algrebraic data types
>
> std.variant covers this.
>
>> - Pattern matching (extension to enum/string/integer accepting switch)
>
> Andrei and Sean have shown how to do that n
Jane Doe wrote:
Is D a cult?
Welcome back! :) Have you started understanding C++ yet?
Ali
"real"
On 03/07/2010 08:17 PM, Walter Bright wrote:
What's the difference between ?: and functional if-then-else?
?: combined with some fun delegate thunks would be equivalent to
functional if-then-else.
like this:
return x > y ? ({writeln(); return 6;})() : ({frobnicate_the_freezer;
return 2;})(
Hello retard,
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
Let's see what features I had in mind:
- Algrebraic data types
std.variant covers this.
- Pattern matching (extension to enum/string/integer accepting
switch)
Andrei and Sean have shown how to do that ni
retard wrote:
It's perfectly clear to me that no matter what you do, D won't become a
functional language because the core runs on an imperative Turing
machine. But the functional constructs can help building more readable
and reliable code. That's why C# and Scala got those features..
I'll r
Walter Bright, el 7 de marzo a las 11:17 me escribiste:
> >- Tuples (no auto-folding, real product types)
>
> Tuples can be better, I agree.
Is nice to see that at least now you recognize that tuples can use some
improvement.
--
Leandro Lucarella (AKA luca) http://llucax.c
Leandro Lucarella wrote:
Walter Bright, el 7 de marzo a las 11:17 me escribiste:
- Tuples (no auto-folding, real product types)
Tuples can be better, I agree.
Is nice to see that at least now you recognize that tuples can use some
improvement.
There are significant technical problems with
retard wrote:
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
- Pattern matching (extension to enum/string/integer accepting switch)
Andrei and Sean have shown how to do that nicely with existing language
features.
Really? I'd really like to see how this is done.
foo(
Hello Walter,
retard wrote:
Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
retard wrote:
- Pattern matching (extension to enum/string/integer accepting
switch)
Andrei and Sean have shown how to do that nicely with existing
language features.
Really? I'd really like to see how th
Sun, 07 Mar 2010 14:52:09 -0800, Walter Bright wrote:
> retard wrote:
>> It's perfectly clear to me that no matter what you do, D won't become a
>> functional language because the core runs on an imperative Turing
>> machine. But the functional constructs can help building more readable
>> and rel
BCS wrote:
I think (from context in other strands) that the OP was referring to
value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
Walter Bright:
> The "holes" are defined to be filled with 0, and are when initialized by
> the compiler. This is specifically so that memcmp can be done to compare
> the struct contents.
Thank you for your answer. I didn't read this important detail in the online
documentation, I must have mis
Sun, 07 Mar 2010 15:38:07 -0800, Walter Bright wrote:
> retard wrote:
>> Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:
>>
>>> retard wrote:
- Pattern matching (extension to enum/string/integer accepting
switch)
>>> Andrei and Sean have shown how to do that nicely with existing
>
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
> BCS wrote:
>> I think (from context in other strands) that the OP was referring to
>> value, not type, pattern matching.
>
> Value pattern matching is just a regular switch statement.
So what types does the regular switch accept in D 2 ?
retard:
> So what types does the regular switch accept in D 2 ?
It accepts all integral values, including all chars and true enums. It accepts
strings but not arrays.
It doesn't accept floating point values, complex numbers (that are FP),
structs, objects and associative arrays.
Eventually sup
Walter Bright:
>There are significant technical problems with having functions return tuples.<
A possibly stupid question: isn't it enough to return a custom struct?
D Tuples have another problem, that they don't nest, as Perl arrays. Can this
be fixed?
Bye,
bearophile
> That IS what Walter thinks, actually. It's being moved to libraries
> (which is why there have been some nasty AA regressions in the past few
> compiler releases :-( ).
Sounds good. So the source is in druntime?
Does that mean I can find out how to implement opIn ?.
I found the file druntime/
Was this already shown here?
http://www.linux-kongress.org/2009/slides/
compiler_survey_felix_von_leitner.pdf
retard wrote:
On the other hand Scala does provide a shallow form of immutability and
some immutable data structures in the standard library.
My experience with shallow const (in C++) is that it's nearly useless.
Most C++ code I've seen seems to rely on an implicit assumption of
transitive co
retard wrote:
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
BCS wrote:
I think (from context in other strands) that the OP was referring to
value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
So what types does the regular switch accept in D
retard wrote:
The matching is all done at compile time, of course, and the delegate
can be inlined.
I guess this tells a lot. No feature is added to D unless it can do
something statically with zero runtime cost.
You did mention in another post in this thread that you were concerned
about o
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions return tuples.<
A possibly stupid question: isn't it enough to return a custom struct?
No, because of the alignment mismatches with other uses of tuples.
retard:
> Was this already shown here?
> http://www.linux-kongress.org/2009/slides/
> compiler_survey_felix_von_leitner.pdf
Few months ago I have submitted some bugs to LLVM on the base of that paper :-)
Bye,
bearophile
Walter Bright Wrote:
> No, because of the alignment mismatches with other uses of tuples.
And I guess all the other uses of tuples can't be changed to this one? :-)
Bye,
a hopeless bearophile
On Sun, 07 Mar 2010 12:43:09 -0500, Robert Jacques
wrote:
On Sun, 07 Mar 2010 08:23:03 -0500, Steven Schveighoffer
wrote:
How do you know when to stop? A range has a beginning and an ending,
otherwise it's an iterator. Whether you store it via a pointer to the
last (not-to-be-iterat
On Sun, 07 Mar 2010 06:42:10 -0500, Andrei Alexandrescu
wrote:
Iterator invalidation has been a notion thoroughly explored by the STL
and a commonly-mentioned liability of STL iterators. People find it very
jarring that syntactically identical interfaces have distinct effects on
iterato
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
> > The mutation index has been used in Tango forever, and I think was in
> > Doug Lea's original container implementations. I'm pretty sure it is
> > sound in single-threaded uses.
> No it's not. version tags + integer overflow = bug. Doug
Hello Walter,
bearophile wrote:
Walter Bright:
There are significant technical problems with having functions
return tuples.<
A possibly stupid question: isn't it enough to return a custom
struct?
No, because of the alignment mismatches with other uses of tuples.
What about passing an
On Sun, 07 Mar 2010 22:07:14 -0500, Steven Schveighoffer
wrote:
On Sun, 07 Mar 2010 12:43:09 -0500, Robert Jacques
wrote:
On Sun, 07 Mar 2010 08:23:03 -0500, Steven Schveighoffer
wrote:
[snip]
Please define for me an O(1) slice or index operation for a linked-list.
One for which you ha
Hello Walter,
retard wrote:
Sun, 07 Mar 2010 15:59:37 -0800, Walter Bright wrote:
BCS wrote:
I think (from context in other strands) that the OP was referring
to value, not type, pattern matching.
Value pattern matching is just a regular switch statement.
So what types does the regular
BCS wrote:
I think what retard was asking was what types are legal as the argument
for a switch?
IIRC the list is: all the arithmetic types and the string types.
The value pattern matching that is being asked for would allow just
about anything that has a compile time literal syntax:
void f
On Fri, 04 Dec 2009 10:05:16 +0200, Lionello Lunesu wrote:
> Perhaps reusing a constructor of an inherited class should be easier.
> Something like "alias this"? But how to refer to specific ctor
> overloads?
>
> L.
>
> On 30-11-2009 1:03, Andrei Alexandrescu wrote:
>> Walter and I just discusse
Walter Bright Wrote:
> Fawzi Mohamed wrote:
> > one could argue that the unsafe operation is memset.
>
> That's right.
>
>
> > The compiler always initializes a struct, so that what you describe
> > should never happen in a safe program.
>
> Right.
>
>
> > Still as you say the following exa
59 matches
Mail list logo
