Actually, scratch that. Any 4 byte pattern can look like a pointer.
Unless you manage to encode it in a way the 4 byte cells look like
they're pointing into an address range not managed by the GC. For
example, most OSes reserve the last 1 or 2 GBs for the kernel. If your
byte quadruple looks li
On Mon, 30 Mar 2009 22:04:57 +0200, Trass3r wrote:
>Max Samukha schrieb:
>> It's possible to statically unroll the foreach's with a template
>> generating a tuple of consequtive integers (not tested):
>>
>> template Sequence(size_t count, size_t index = 0)
>> {
>>static if (index < count)
>>
Sergey Gromov Wrote:
> > This is a lie. There is just no way for cigarette-chomping executives to
> > not know, what are licenses and how they work.
>
> Sure they know. They know too well that one wrong step, one ignorant
> developer, and they may kiss good-bye to their precious intellectual
>
Chris Wrote:
> You agree to indemnify Symantec from all claims or demands
Note the use of "from" preposition. Indemnify from = defend, indemnify for =
compensate.
Unknown W. Brackets Wrote:
> Well, I'm not so sure. Every time you invent meta data, someone will
> invent a language that goes outside that meta data. It's reality.
API will do the same.
> Programs would benefit from such an API as well; it could provide basic
> runtime information (manglin
On Tue, 31 Mar 2009 10:55:22 +0200, Max Samukha
wrote:
>On Mon, 30 Mar 2009 22:04:57 +0200, Trass3r wrote:
>
>>Max Samukha schrieb:
>>> It's possible to statically unroll the foreach's with a template
>>> generating a tuple of consequtive integers (not tested):
>>>
>>> template Sequence(size_t
BTW, how do you understand Microsoft EULA?
"you will indemnify, hold harmless, and defend Microsoft from and against any
claims or lawsuits, including attorneys and experts fees, that arise or
result from the use or distribution of your Application"
Max Samukha schrieb:
So it is a tuple although the docs tell us it's an array?
Yeah, __traits returns expressions of various types depending on the
Id. In case of getVirtualFunctions, it's a tuple expression. You may
want to look through traits.c in dmd sources to see what's going on.
So th
Yes, in probably a couple of months.
Andrei
Saaa wrote:
Will we be able to read the article online after polishing?
I am writing an article for a programming magazine entitled "The Case for
D".
Would anyone be interested in reviewing it before publication? Please send
me private email if s
Max Samukha schrieb:
"variable main.main.i voids have no value"
__traits is buggy.
template isFunction(C, string member)
{
enum isFunction = is(typeof(mixin("C." ~ member)) == function);
}
void main()
{
//SpinLock lock;
enum members = __traits(allMembers, Class);
foreach (i;
Mon, 30 Mar 2009 18:09:21 -0400, Steven Schveighoffer wrote:
> On Mon, 30 Mar 2009 18:03:02 -0400, Bill Baxter wrote:
>
>> On Tue, Mar 31, 2009 at 6:36 AM, Steven Schveighoffer
>> wrote:
>>> On Mon, 30 Mar 2009 16:00:02 -0400, Yigal Chripun
>>> wrote:
>>>
people in the US sued MacDonald's
On Tue, 31 Mar 2009 13:53:02 +0200, Trass3r wrote:
>Max Samukha schrieb:
>>> So it is a tuple although the docs tell us it's an array?
>>>
>>
>> Yeah, __traits returns expressions of various types depending on the
>> Id. In case of getVirtualFunctions, it's a tuple expression. You may
>> want to
Tue, 31 Mar 2009 05:15:24 -0400, Kagamin wrote:
> Sergey Gromov Wrote:
>
>>> This is a lie. There is just no way for cigarette-chomping executives to
>>> not know, what are licenses and how they work.
>>
>> Sure they know. They know too well that one wrong step, one ignorant
>> developer, and
Well, an API allows programatic reduction, handshaking (version
upgrades), and the like. A file format can do some of these things as
well, but it starts to get more complicated, and you start wasting space
for bc, etc. etc.
Also, a file format would have to be generated by running the compil
grauzone wrote:
Sean Kelly wrote:
== Quote from Sergey Gromov (snake.sc...@gmail.com)'s article
Sun, 29 Mar 2009 17:42:48 -0400, Chad J wrote:
Maybe what you are looking for are the GC.removeRoot or GC.removeRange
functions which are available in both Phobos and Tango?
http://www.dsource.org/p
On Tue, 31 Mar 2009 02:02:03 -0400, Yigal Chripun
wrote:
On 31/03/2009 00:36, Steven Schveighoffer wrote:
No, it would not be reasonable. In fact that would just be a nice fat
paycheck for the plaintiff's lawyer (and probably the defendant's
lawyer) and nothing else.
Nobody can expect someo
Bill Baxter wrote:
> On Tue, Mar 31, 2009 at 7:09 AM, Steven Schveighoffer
> wrote:
>> On Mon, 30 Mar 2009 18:03:02 -0400, Bill Baxter wrote:
>>> Peanuts aren't actually nuts, you know. They're legumes. So there
>>> might well be a case where the lable said "100% peanuts" and someone
>>> aller
dsimcha wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
That said, I don't think there is a need for something like this.
Certainly no speedup and little clarity compared to declaring variable
right before invoking doStuff.
Here's an example of where it would be a useful pi
Kagamin wrote:
BTW, how do you understand Microsoft EULA?
"you will indemnify, hold harmless, and defend Microsoft from and
against any claims or lawsuits, including attorneys’ and experts’
fees, that arise or result from the use or distribution of your
Application"
That's clear enough. You
On Tue, 31 Mar 2009 12:08:29 -0400, Georg Wrede wrote:
Or, while I know some istalling programs make you check a box stating
you agree, but say you buy a PC with the OS already installed, and then
start programming, say, using this PowerShell thingy, and the crap hits
the fan -- because of so
2009/3/30 dsimcha :
> // How it works now:
> uint foo;
> string bar;
> unpack(foo, bar) = someFunction();
>
> // vs. how I want it to work:
> unpack(auto foo, auto bar) = someFunction();
Cute, but uh, I'd much rather see tuples just be returnable. That
would practically remove the need for out pa
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
> 2009/3/30 dsimcha :
> > // How it works now:
> > uint foo;
> > string bar;
> > unpack(foo, bar) = someFunction();
> >
> > // vs. how I want it to work:
> > unpack(auto foo, auto bar) = someFunction();
> Cute, but uh, I'd
Reply to Yigal,
On 30/03/2009 04:42, Mike Parker wrote:
No, it gives no freedom to developers at all. Using any GPL code in
your project /forces/ you to open your source. It takes the decision
of whether to open or not out of your hands and puts it in the hands
of whomever created the GPLed pr
"Kagamin"
> Chris Wrote:
>
>> You agree to indemnify Symantec from all claims or demands
>
> Note the use of "from" preposition. Indemnify from = defend, indemnify for
> = compensate.
Ok this could be a solution.
Thanks to everybody.
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
uint foo;
string bar;
unpack(foo, bar) = someFunction();
// vs. how I want it to work:
unpack(auto foo, auto bar) = someFunction();
Cute, but uh, I'd much rather see tuples just be returnable.
They are.
Andrei
I have been doing some work on this, based on Eric Anderton et al's DDL.
I wanted something that would be compatible with DMD2.x and Phobos, and was
relatively simple to understand.
The result can be found at http://www.britseyeview.com/dml/.
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
> Jarrett Billingsley wrote:
>>
>> 2009/3/30 dsimcha :
>>>
>>> // How it works now:
>>> uint foo;
>>> string bar;
>>> unpack(foo, bar) = someFunction();
>>>
>>> // vs. how I want it to work:
>>> unpack(auto foo, auto bar) = someFunction()
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
uint foo;
string bar;
unpack(foo, bar) = someFunction();
// vs. how I want it to work:
unpack(auto foo, auto bar) = someFunction();
Cute
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
>
> import std.typecons;
>
> Tuple!(int, float) foo()
> {
> return tuple(2, 4.5);
> }
>
> The addition of the alias this feature and of constructor templates makes
> std.typecons.Tuple even better.
>
Cool, but..
Why not just make tup
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
> Jarrett Billingsley wrote:
>> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
>> wrote:
>>> Jarrett Billingsley wrote:
2009/3/30 dsimcha :
> // How it works now:
> uint foo;
> string bar;
> unpack(foo, bar) =
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
>
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>
> > Jarrett Billingsley wrote:
> >> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
> >> wrote:
> >>> Jarrett Billingsley wrote:
> 2009/3/30 dsimcha :
> > // How it
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates makes
std.typecons.Tuple even better.
Cool, but..
Why not j
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
u
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates
makes
std.typecons.Tuple even bet
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
Trass3r wrote:
Yeah extreeemely buggy. dmd also crashes if that enum members is changed
to const members or invariant members.
Buggy __traits is the major reason I'm not on d2. If __traits were not
buggy, I could do, god, so many things!
Though it would be even better to have the runtime equ
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>
>> Jarrett Billingsley wrote:
>>> On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
>>> wrote:
Jarrett Billingsley wrote:
> 2009/3/30 dsimcha :
>> // How it works n
Christopher Wright schrieb:
Buggy __traits is the major reason I'm not on d2. If __traits were not
buggy, I could do, god, so many things!
Though it would be even better to have the runtime equivalent.
Any chance traits get fixed anytime soon?
In this post I list four random things I have seen/found lately. Some of them
may be interesting for the development of D.
C# has arrays of arrays as D, plus it has built-in multidimensional arrays too:
http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx
They have some advantages:
- On t
Hi
This is the monthly status for the unofficial d wish list:
http://all-technology.com/eigenpolls/dwishlist/
Right now the wish list looks like this:
199 Stack tracing (#26)
195 Reflection API (#6)
132 vectorization (#10)
112 Multiple return values (tuples (#28)
99 Multiple opCast per cl
On Tue, Mar 31, 2009 at 7:31 PM, bearophile wrote:
>
> Java has tons of standard exceptions, you can see some of them humorously
> explained here:
> http://rymden.nu/exceptions.html
> I don't need hundreds of different exceptions organized in a deep tree, but I
> have felt the need to define few
Andrei Alexandrescu wrote:
> Jarrett Billingsley wrote:
>> On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
>> wrote:
>>> import std.typecons;
>>>
>>> Tuple!(int, float) foo()
>>> {
>>>return tuple(2, 4.5);
>>> }
>>>
>>> The addition of the alias this feature and of constructor templates
Bill Baxter, el 1 de abril a las 05:22 me escribiste:
> Right. In my ideal world I could use tuples like this:
>
> (int,float) a;
>
> a = returns_tuple();
>
> a[0] = 2;
> a[1] = 3.4;
>
> (int,float) z = returns_tuple();
>
> (int x, float y) = returns_tuple();
>
> auto tup = (2, 3.4);
>
> t
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha :
// How it works now:
u
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 3:18 PM, Andrei Alexandrescu
wrote:
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates
makes
std.type
Leandro Lucarella wrote:
Bill Baxter, el 1 de abril a las 05:22 me escribiste:
Right. In my ideal world I could use tuples like this:
(int,float) a;
a = returns_tuple();
a[0] = 2;
a[1] = 3.4;
(int,float) z = returns_tuple();
(int x, float y) = returns_tuple();
auto tup = (2, 3.4);
takes
Tue, 31 Mar 2009 17:54:30 -0700, Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
>> wrote:
>>> Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
wrote:
> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote
Trass3r wrote:
Christopher Wright schrieb:
Buggy __traits is the major reason I'm not on d2. If __traits were not
buggy, I could do, god, so many things!
Though it would be even better to have the runtime equivalent.
Any chance traits get fixed anytime soon?
I was using __traits + CTFE aro
Andrei Alexandrescu, el 31 de marzo a las 17:57 me escribiste:
> Leandro Lucarella wrote:
> >Bill Baxter, el 1 de abril a las 05:22 me escribiste:
> >>Right. In my ideal world I could use tuples like this:
> >>
> >>(int,float) a;
> >>
> >>a = returns_tuple();
> >>
> >>a[0] = 2;
> >>a[1] = 3.4;
>
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the comma expression from
an assignment expression which otherwise would become a part of c
Leandro Lucarella wrote:
Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
But in Python or ML, no question. I'd happily write a function that
returns (2, 4.2) without giving it much thought. Now perhaps cogent
arguments like "blech" and "belch" can convince me that I should
embrac
Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
> >But in Python or ML, no question. I'd happily write a function that
> >returns (2, 4.2) without giving it much thought. Now perhaps cogent
> >arguments like "blech" and "belch" can convince me that I should
> >embrace the Tuple!(int
Andrei Alexandrescu:
> Well I think a language can only have so many built-in types. We can't
> go on forever.
Too many built-ins become confusing (see Fortress), but D is quite far from
that point (see Python, that has more than D and they are just fine and easy to
use and remember. I'd also
Leandro Lucarella wrote:
Andrei Alexandrescu, el 31 de marzo a las 17:57 me escribiste:
Agree. They should be first class citizen as dynamic arrays or hashes.
Why? Not grokking it.
It's perfectly explained in this thread why, all I have to say will
repeate something already said (the int[] vs
bearophile wrote:
Andrei Alexandrescu:
Well I think a language can only have so many built-in types. We
can't go on forever.
Too many built-ins become confusing (see Fortress), but D is quite
far from that point (see Python, that has more than D and they are
just fine and easy to use and reme
Sergey Gromov wrote:
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the com
Sergey Gromov wrote:
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the com
On Wed, Apr 1, 2009 at 9:55 AM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov
>> wrote:
>>>
>>> Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
>>>
Jarrett Billingsley wrote:
>
> On Tue, Mar 31, 2009 at 1:32 PM, Andrei
Andrei Alexandrescu, el 31 de marzo a las 18:42 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 31 de marzo a las 17:55 me escribiste:
> >>>But in Python or ML, no question. I'd happily write a function that
> >>>returns (2, 4.2) without giving it much thought. Now perhaps cog
Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Comma expression is not ambiguous. It's a comma expression. Renaming
>> it into a tuple constructor expression does not add any ambiguity.
>> Parentheses here are only required to separate the comma expression
bearophile wrote:
> C# has arrays of arrays as D, plus it has built-in multidimensional
> arrays too:
> http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx They
> have some advantages: - On them the compiler can use some extra
> optimizations, common in all Fortran compilers. D seems a la
Tue, 31 Mar 2009 18:55:10 -0700, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Tue, 31 Mar 2009 18:38:35 -0700, Andrei Alexandrescu wrote:
>>
>>> Sergey Gromov wrote:
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression doe
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> Ok, then we'll introduce balanced budget amendment for types to ensure
> this doesn't happen. For every new type added one must be removed.
> We're going to vote complex types off the island, right? Maybe we
> could get rid of associative
On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
wrote:
> I guess I can't bring myself to dislike tuple(1, 2) in D.
>
I'd actually be a heck of a lot happier with that than Tuple!(1,2).
Especially if using it didn't require any explicit import.
--bb
== Quote from Bill Baxter (wbax...@gmail.com)'s article
> On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
> wrote:
> > I guess I can't bring myself to dislike tuple(1, 2) in D.
> >
> I'd actually be a heck of a lot happier with that than Tuple!(1,2).
> Especially if using it didn't require an
Andrei Alexandrescu wrote:
> Daniel Keep wrote:
>>
>> Andrei Alexandrescu wrote:
>>> Jarrett Billingsley wrote:
...
Why not just make tuples first-class types? <_<
>>> Why not not?
>>>
>>> Andrei
>>
>> Because people keep having to invent hacks to work around the fact that
>> we can
On Wed, Apr 1, 2009 at 11:15 AM, dsimcha wrote:
> == Quote from Bill Baxter (wbax...@gmail.com)'s article
>> We're going to vote complex types off the island, right? Maybe we
>> could get rid of associative arrays as a built-in too.
>
> Aren't builtin complex types on the way out anyhow?
Right.
I frequently look at the changelog of Phobos on dsource. Is there a similar
place to look for the dmd front end as well as the back end? If not, can we set
one up?
Bill Baxter wrote:
On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
wrote:
I guess I can't bring myself to dislike tuple(1, 2) in D.
I'd actually be a heck of a lot happier with that than Tuple!(1,2).
Especially if using it didn't require any explicit import.
--bb
Tuple!(...) tuple(.
Bill Baxter wrote:
Ok, then we'll introduce balanced budget amendment for types to ensure
this doesn't happen. For every new type added one must be removed.
We're going to vote complex types off the island, right? Maybe we
could get rid of associative arrays as a built-in too.
Ironic as that
On Wed, Apr 1, 2009 at 1:12 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Wed, Apr 1, 2009 at 10:53 AM, Andrei Alexandrescu
>> wrote:
>>
>>> I guess I can't bring myself to dislike tuple(1, 2) in D.
>>>
>>
>> I'd actually be a heck of a lot happier with that than Tuple!(1,2).
>> Es
Andrei Alexandrescu:
> So we must add lists too.
Notice the the python "list" is an array dynamic on the right, it's not a
linked list.
Regarding tuple: I don't like the name "tuple" of typecons, because they aren't
the tuples of D, they are structs. That's why I have named them Record/record
Rainer Deyke:
> However, I'm not sure what advantage a built-in type would provide over a
> library type.<
Some C++ libs show that you can implement some of the optimizations I was
talking about (present in Fortran compilers, that juggle, split, merge and
slice nested for loops in various ways
bearophile wrote:
Andrei Alexandrescu:
So we must add lists too.
Notice the the python "list" is an array dynamic on the right, it's
not a linked list.
I know. My point was that I might want to add a reasonable data
structure to the language, and it's hard to build an argument on what to
Andrei Alexandrescu:
>D is at fault because it called typelists tuples. I told Walter not to, and he
>went ahead and did so anyway. Now we're living with the consequences.<
I see, and you are right. Then why not rename tuples of D2 to a more correct
name (typelists)? Being D2 in alpha still the
77 matches
Mail list logo
