Andrei Alexandrescu wrote:
Jason House wrote:
The first follow-up to your reply captured the kind of messiness bind
can bring in C++. So far, all your examples are trivial (lack
argument reordering, function composition, etc...). It's true that
your examples look clean, but the devil
Walter Bright wrote:
Jason House wrote:
I'd give better examples/details if I wasn't typing this with my thumb
into a cell phone...
You do caps, quotes, special characters, correct grammar with your thumb
on a cell phone?! I'm impressed! I can't bother with that without a full
keyboard
downs Wrote:
Let me say first that I don't use std.bind myself, but tools.base:fix fills
essentially the same need - creating full closures from dynamic ones.
Say you have a function that takes a number and returns a delegate that does
something with that number.
void delegate()
Walter Bright wrote:
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
Apparently, setting an array length to -1 will cause this issue.
It's unfortunate to not have a stack trace in the error output,
or a functional gdb to capture it! I really hope gdb
compatiblity
Walter Bright Wrote:
Let me put it this way - I thought doing the mac port, which is stuff
like that, would take a week. It took 6 weeks.
... so we can expect a 64 bit dmd next week? g
Does anybody know when core.sync will be part of the druntime release with
D2? It's been in the druntime source for a month. I thought it'd be in the
latest release (2.025), but I don't see it :(
Walter Bright Wrote:
Jason House wrote:
Apparently, setting an array length to -1 will cause this issue. It's
unfortunate to not have a stack trace in the error output, or a functional
gdb to capture it! I really hope gdb compatiblity will be fixed :(
What's wrong with gdb?
See my
Has anyone else gotten the Memory allocation failed exception in D2? I have
to dig deeper to concretely prove it's not my fault, but I do know I wrote my
app to avoid memory allocation and watching top showed about 20k of growth over
the ~10 minutes it takes to reproduce the bug.
I don't look
BCS wrote:
Reply to Jason,
Has anyone else gotten the Memory allocation failed exception in D2?
I have to dig deeper to concretely prove it's not my fault, but I do
know I wrote my app to avoid memory allocation and watching top showed
about 20k of growth over the ~10 minutes it takes to
Andrei Alexandrescu Wrote:
Steve Schveighoffer wrote:
4. While we're at it, should uniform(a, b) generate by default something
in [a, b] or [a, b)?
[a,b)
Every other piece of range-like code is zero based, and excludes the
upper bound. This should be no different. It makes the
Andrei Alexandrescu Wrote:
bearophile wrote:
Andrei Alexandrescu:
Say at some point there are k available (not taken) slots out of
n. There is a k/n chance that a random selection finds an
unoccupied slot. The average number of random trials needed to find
an unoccupied slot is
Jason House Wrote:
Andrei Alexandrescu Wrote:
bearophile wrote:
Andrei Alexandrescu:
Say at some point there are k available (not taken) slots out of
n. There is a k/n chance that a random selection finds an
unoccupied slot. The average number of random trials needed to find
Walter Bright Wrote:
Andrei Alexandrescu wrote:
2. The global random generator will be allocated per thread. Are you
cool with this too?
That could have speed problems with a tight loop accessing thread local
storage. If it's a shared global with no locking, the thread randomness
Jason House Wrote:
Andrei Alexandrescu Wrote:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
Ok, following Leonardo's and Denis' ideas on covering an immutable array
in random order, I thought about it and came up with one algorithm
Andrei Alexandrescu Wrote:
Jason House wrote:
Andrei Alexandrescu Wrote:
No. Your wording sounds like you're doing
stuff that's way off, but the resulting math is correct. My
calculation would be based on the average length of a sequence of 1's
(k/(n-k)). That means the work is 1
Andrei Alexandrescu Wrote:
Andrei Alexandrescu wrote:
Given an array of length m, return a range that iterates the array in
random order such that the entire array is visited without going through
the same element more than once. Consume minimal amounts of memory and
time. Baseline
Andrei Alexandrescu Wrote:
Andrei Alexandrescu wrote:
Andrei Alexandrescu wrote:
Given an array of length m, return a range that iterates the array in
random order such that the entire array is visited without going
through the same element more than once. Consume minimal amounts of
dsimcha Wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
bearophile wrote:
Andrei AlexandrescuThe quest for finding a random cover of an array
with as little extra memory consumed and with good complexity is on!
This thread is very long and
Andrei Alexandrescu Wrote:
Ok, following Leonardo's and Denis' ideas on covering an immutable array
in random order, I thought about it and came up with one algorithm, in
addition to the obvious one that stores one integer per element (see
Denis' code).
Here's the algorithm. It stores
Andrei Alexandrescu Wrote:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Ok, following Leonardo's and Denis' ideas on covering an immutable array
in random order, I thought about it and came up with one algorithm, in
addition to the obvious
Walter Bright Wrote:
5. Why can't one 'version out' syntax that is not recognized by the
compiler?
The problem is that supporting this requires semantic analysis in order
to successfully lex and parse the source code. Breaking this will make
the lexing and parsing an order of
Andrei Alexandrescu Wrote:
Jason House wrote:
What constitutes escaping?
The callee tucks away the address of the ref parameter, or the address
of a direct field of it.
Ok, so this is head-escape analysis instead of transitive escape analysis.
Still, there are a few issues that I can
Andrei Alexandrescu wrote:
Hey,
I've been doing a hecatomb of coding in D lately, and had an insight
that I think is pretty cool. Consider:
struct Widget
{
private Midget * m;
...
this(ref Midget mdgt) { m = mdgt; ... }
}
It's a rather typical pattern in C++ for
Brian wrote:
On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
So, let's ask the community: Would you like to see nullable types in D?
http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
by voting multiple time)
Explain your reasoning in newsgroups. Thank
Andrei Alexandrescu Wrote:
Derek Parnell wrote:
On Sat, 31 Jan 2009 07:22:17 -0800, Andrei Alexandrescu wrote:
The truth is, the reasons against using strings for short functions are
shrinking. I mean, you don't want to not use strings just to not use
strings, right? I hope I
Andrei Alexandrescu Wrote:
Jason House wrote:
I think algorithm signatures should not be made unnecessarily
complex, and instead rely on other utilities for complex behavior.
For example map!(a*a)(r1,r2) can be implemented as
map!(a*a)(chain(r1,r2))
Yah, good point. I'm ambivalent
Andrei Alexandrescu Wrote:
Jason House wrote:
Andrei Alexandrescu Wrote:
Jason House wrote:
I also see in the docs that the structs returned are documented,
complete with all the functions that they include. I'd hope that we
could somehow document this stuff simpler
Andrei Alexandrescu wrote:
Proxying is a useful technique for achieving nice effects like e.g.
expression templates. Consider, for example, a matrix operators package
that returns lazy matrices in the form of expression templates:
struct Matrix
{
LazyMatrix!(a + b) opAdd(ref Matrix
I was chatting on #gdb earlier today and it sounds like getting a patch for the
d programming language into gdb shouldn't be too bad. There's a patches
mailing list and some kind of paperwork to resolve copyright issues.
Is there any legal/copyright issues that prevent the gdb patch from
Denis Koroskin Wrote:
On Thu, 22 Jan 2009 23:38:04 +0300, Jason House jason.james.ho...@gmail.com
wrote:
Denis Koroskin Wrote:
I think believe we could take advantage of current state of both
libraries in D2 - they are both incomplete and being redesigned to fit
D2 better.
We
dsimcha Wrote:
Every once in a while, it comes up on this NG that a significant limitation of
templates is that they can't add virtual functions to classes. Of course,
removing this limitation for the general case is impossible w/o completely
changing the compilation model in ways that are
Robert Fraser Wrote:
dsimcha wrote:
Every once in a while, it comes up on this NG that a significant limitation
of
templates is that they can't add virtual functions to classes. Of course,
removing this limitation for the general case is impossible w/o completely
changing the
I was just looking at Atomic.d in the D2 port of tango and I see that all the
volatile keywords are commented out. My understanding is that the ordering of
the assembly in those blocks is incredibly important to preserve as-is. What
is the way to ensure that in D2?
Andrei Alexandrescu Wrote:
Steven Schveighoffer wrote:
Andrei Alexandrescu wrote
Steven Schveighoffer wrote:
When looking at ranges, it seems like a much better model for iteration
than opApply. It seems like it could be a whole replacement for opApply.
But when looking at the
dsimcha Wrote:
Yeah, but we also want decent performance and even compared to opApply,
coroutines/fibers are slow as molasses in January at the North Pole during the
last Ice Age.
One type of coroutine optimization was mentioned previously on this list:
Walter Bright wrote:
Druntime is there, and it's up to the Tango team now.
As I understand it, the biggest fear of the Tango team is to make an official
D2 version and then have to chase after a moving standard. If an official port
of Tango 0.99.7 was ported to work with dmd v2.023 how
Andrei Alexandrescu wrote:
Speed is a small part of the equation, in fact a perk only. Ranges are
composable; you can combine them to e.g. do parallel iteration over two
ranges. Ranges really open std.algorithm to all data structures. I find
opApply incredibly obtuse and fostering bad design.
Andrei Alexandrescu wrote:
Jason House wrote:
Andrei Alexandrescu wrote:
Speed is a small part of the equation, in fact a perk only. Ranges
are composable; you can combine them to e.g. do parallel iteration
over two ranges. Ranges really open std.algorithm to all data
structures. I find
Silvio Ricardo Cordeiro wrote:
Is there any good reason why the following code doesn't work?
The function foo requires as its argument a delegate that
receives a B. This means that, because of the type soundness
of the D language, the delegate will only be called with instances
of B. Now,
Steven Schveighoffer wrote:
Hoenir wrote
So why don't they port tango to that D1 version of druntime?
What is the need?
I can only think of one reason: When porting Tango to D2, it'll be one less
thing to do.
Walter Bright Wrote:
John Reimer wrote:
Sounds exciting. Hope it all works out.
It's especially nice to hear even a general statement of direction here
now and again. So thank-you. I know it must be tough slogging. :)
I know I've been quiet lately, but that doesn't mean I'm not
Andrei Alexandrescu wrote:
I'd be curious to find out more about a runtime queryable struct
interface. How would it work? What idioms would it enable?
I don't know what Lars is thinking of, but I think of struct interfaces as a
non-polymorphic / compile-time inheritance. AKA, you can have a
Andrei Alexandrescu Wrote:
bearophile wrote:
Andrei Alexandrescu:
I'll wait for bearophile to tell if he feels he hasn't gotten the
credit he believes he deserves before I answer this particular
point.
I'm having a bad week for matters unrelated to D. You are doing lot
of work for
It sounds good. I have one question:
How do we avoid surprising the user?
That can be...
lazy output when expecting non-lazy
non-lazy output when expecting lazy
later input changes altering output
When returning lazy should be be safe:
immutable input data
consumable ranges
the
bearophile wrote:
My interest for this community and for D is decreasing quickly.
This may be a stupid question, but why is that?
Andrei Alexandrescu wrote:
opApply should be first dipped in tar, then dipped in feathers, and
finally walked around town in a wooden cage. I think it's the least of
all D in the D spirit. Abstractions that look cute and pretend there's
no cost = ~D.
I like opApply. From a lazy container
Claus D. Volko wrote:
Hi,
I'm currently writing a D tutorial for people new to programming, and I've
experienced some strange behavior:
The following program works as intended:
// The Hello World! program
import std.stdio;
import std.c.stdio;
void main ()
{
int i;
Andrei Alexandrescu wrote:
That's way beyond the ability of a compiler to do automatically. The
compiler would have to understand that the pure function produces
continuous results.
You're replying to the wrong guy. I'm saying: the compiler shouldn't
have to do so, but it should allow
Andrei Alexandrescu Wrote:
Jason House wrote:
Walter Bright Wrote:
Michel Fortin wrote:
Hum, could the compiler be trusted to add the memoization code to pure
functions so they can stay pure?
If the compiler does general memoization on pure functions, all it has
to do is use
Mike wrote:
So I'm trying to link a C file to be used in a D program:
I compile the C file with dmc: dmc -c hw.c
and the D file with dmd: dmd -c hw_main.d
I usually keep it simple and do: dmd main.d hw.obj
In the latest D2, both the frontend and backend support use and optimization
when user code declares pure code. This isn't particularly useful when pure
functions can't call standard library code.
When considering the standard library changes, I realized that object.d could
change. I believe a
Walter Bright Wrote:
Jason House wrote:
When considering the standard library changes, I realized that
object.d could change. I believe a pure opCmp or toString could break
user code with impure versions of those functions. Would that kind of
a change to object.d cause any real problems
Walter Bright wrote:
Memoization and purity don't mix.
True, but...
All pure functions can be memoized. They can be memoized by the caller of the
pure function, or the pure function could be rewritten to automatically memoize.
When writing a pure but potentially costly function, the coder
Walter Bright Wrote:
Michel Fortin wrote:
Hum, could the compiler be trusted to add the memoization code to pure
functions so they can stay pure?
If the compiler does general memoization on pure functions, all it has
to do is use the bits of the arguments passed on the stack to the
K.Wilson Wrote:
Hello all,
The example for alias declarations is incorrect here:
http://digitalmars.com/d/1.0/declaration.html
struct S { static int i; }
S s;
alias s.i a; // illegal, s.i is an expression
alias S.i b; // ok
b = 4; // sets S.i to 4
The 'alias s.i a;'
Denis Koroskin wrote:
On Mon, 05 Jan 2009 04:16:43 +0300, Jason House
jason.james.ho...@gmail.com wrote:
Stewart Gordon wrote:
I was just looking at this
http://d.puremagic.com/issues/show_bug.cgi?id=2544
which describes how it's possible to bypass const by doing this:
const(int
Walter Bright Wrote:
You know, the unimplemented 128 bit integer types.
Does anyone have a use for these?
If that means bitwise operations on them would optimize to SSE instructions,
then I would love to see them.
Andrei Alexandrescu wrote:
Jason House wrote:
Andrei Alexandrescu Wrote:
There are two issues here. One is that the const guarantees that foo
does not legally change a, so it is useful for an optimization (e.g.
assume that a == 5 after the call to foo). The second issue is that
compilers
Don wrote:
Walter Bright wrote:
You know, the unimplemented 128 bit integer types.
Does anyone have a use for these?
I would have liked them when implementing a fallback (non-asm) bigint
implementation for 64-bit CPUs. Actually the only operations required are:
ulong * ulong - ulong[2]
Andrei Alexandrescu Wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Const is still useful because inside a function you know for sure that
another thread can't modify the data.
I think you meant immutable.
I meant const.
Andrei
At least for the current D2, your
Andrei Alexandrescu Wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Tue, Dec 23, 2008 at 11:30 AM, Jerry Quinn
jlqu...@optonline.net wrote:
This was an interesting read. It would be nice to see a
Is it possible to close the bugzilla bugs that were fixed?
More generally, bug owners get e-mails when bugs are closed, but don't receive
e-mails when new releases are made. Here I was sitting around waiting for one
of my bugs to get fixed, and here it's been fixed a week and a half :(
Walter
SFINAE
Accidental use of SFINAE is confusing.
Code using SFINAE is tough or impossible to follow.
Use of SFINAE can lead to longer compile times.
Removing SFINAE will expose shortfalls in D's metaprogramming facilities.
Combining all of these faults into a templated library and you have
Bill Baxter Wrote:
On Tue, Dec 2, 2008 at 6:40 AM, Jarrett Billingsley
[EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 4:19 PM, llee [EMAIL PROTECTED] wrote:
Is is possible to index the elements within a tuple using strings?
Something similar to the way that associative arrays allow
Extrawurst Wrote:
But why is it that since 2.020 i cannot name a package shared anymore?
moudle shared.foo;
dmd: Identifier expected following module
WTF ?
Because shared is now a keyword.
Ok, what is it for ? Where is it documented ? Or is it another reserved
keyword
401 - 465 of 465 matches
Mail list logo
