Currently rdmd is broken because of (Issue 8856, Issue 8858, Issue 7016),
ie local import does not create -deps dependency, which results in link
errors.
This makes people use global imports as opposed to local ones, which is
less clean.
I wrote a recursive dependency analyzer and plugged it in a
12-Jul-2013 02:23, Joseph Rushton Wakeling пишет:
On 07/11/2013 10:43 PM, Dmitry Olshansky wrote:
In such a case if inserting exactly one element into a sorted range you may want
to special case it to lowerbound + insert.
E.g. something like this:
auto idx = sortedRange.lowerbound(val).length;
On 07/11/2013 08:27 PM, H. S. Teoh wrote:
> Yeah, constraining the number of vertices/edges at ctor time is not
> feasible. We need to have an implementation that allows modifying the
> graph post-construction, such as adding edges.
You can add as many edges as you like -- right now, the implement
On 07/11/2013 08:14 PM, w0rp wrote:
> 3. I have to control the graph's capacity manually, and I can't use arbitrary
> numbers for edges.
I'm not sure I understand why this is a problem with the class presented here.
Can you clarify what your concern is?
On 07/11/2013 10:43 PM, Dmitry Olshansky wrote:
> In such a case if inserting exactly one element into a sorted range you may
> want
> to special case it to lowerbound + insert.
> E.g. something like this:
>
> auto idx = sortedRange.lowerbound(val).length;
> //insert should be called on array bac
Am 11.07.2013 21:58, schrieb bearophile:
thedeemon:
HotSpot and, I suppose, other mature JVMs provide generational GCs, so
you won't get 5 seconds delay after each 8 MB of allocated data there.
They need a certain amount of seconds for each GB of heap memory
(assuming an average amount of poi
11-Jul-2013 20:02, Joseph Rushton Wakeling пишет:
On 07/11/2013 05:17 PM, Andrei Alexandrescu wrote:
Unstable sort should be faster than stable sort. If I remember correctly (1) our
TimSort is indeed slower than quicksort on random numbers, (2) there is a
performance bug that makes our quicksort
thedeemon:
HotSpot and, I suppose, other mature JVMs provide generational
GCs, so you won't get 5 seconds delay after each 8 MB of
allocated data there.
They need a certain amount of seconds for each GB of heap memory
(assuming an average amount of pointers in that GB of data
structures. Ja
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:
thedeemon:
No mature GCed languages behave that bad.
I think there is one JavaVM that manages to avoid part of the
problem you explain (and maybe it needs special kernel
support). I think all other JavaVMs suffer it, more or less
On Thursday, 11 July 2013 at 18:42:10 UTC, H. S. Teoh wrote:
However, I think we should also provide friendlier
representations for
user-facing types. One possibility is a wrapper type that
accepts string
IDs for nodes/edges, and internally maintains a mapping between
them and
numerical IDs, s
On Thu, Jul 11, 2013 at 08:34:17PM +0200, Joseph Rushton Wakeling wrote:
> On Thursday, 11 July 2013 at 18:14:01 UTC, w0rp wrote:
> >I don't like it. Here is why.
> >
> >1. You can only use a size_t type as the vertex type. What about
> >strings?
>
> This is a core graph type designed explicitly f
On Thursday, 11 July 2013 at 18:14:01 UTC, w0rp wrote:
I don't like it. Here is why.
1. You can only use a size_t type as the vertex type. What
about strings?
This is a core graph type designed explicitly for speed and
efficiency. If you want string ids for vertices, it's better to
wrap thi
On Thu, Jul 11, 2013 at 08:14:00PM +0200, w0rp wrote:
> I don't like it. Here is why.
>
> 1. You can only use a size_t type as the vertex type. What about
> strings?
> 2. The distinction between directed and undirected graphs is made
> with an boolean type parameter? Why not an enum? Better yet, w
I don't like it. Here is why.
1. You can only use a size_t type as the vertex type. What about
strings?
2. The distinction between directed and undirected graphs is made
with an boolean type parameter? Why not an enum? Better yet, why
not just use interfaces? (You are already using classes and
On Thursday, 11 July 2013 at 15:17:03 UTC, Andrei Alexandrescu
wrote:
(2) there is a performance bug that makes our quicksort perform
quadratically on data that's essentially sorted but has one
unsorted element at the end.
Do you have a link? I couldn't find it on the bugzilla, though I
do re
On 07/11/2013 05:17 PM, Andrei Alexandrescu wrote:
> Unstable sort should be faster than stable sort. If I remember correctly (1)
> our
> TimSort is indeed slower than quicksort on random numbers, (2) there is a
> performance bug that makes our quicksort perform quadratically on data that's
> esse
On 7/11/13 3:25 AM, Joseph Rushton Wakeling wrote:
By default, schwartzSort uses SwapStrategy.unstable, which means quicksort is
used as the sorting mechanism. If we replace this with SwapStrategy.stable or
SwapStrategy.semistable, TimSort is used instead, and this dramatically cuts the
running
On Thursday, 11 July 2013 at 10:25:40 UTC, Joseph Rushton
Wakeling wrote:
On 07/11/2013 02:24 AM, Joseph Rushton Wakeling wrote:
I know, and it's coming. :-) The main memory-related issues
will probably not
show up in a situation like this where all we're doing is
storing the graph
data, but i
On 2013-07-11 10:46, Paulo Pinto wrote:
This is way there was such a joy when ARC was announced, not because GC
per se is bad.
Guess I didn't know about all these flaws in the GC.
--
/Jacob Carlborg
On 07/11/2013 02:24 AM, Joseph Rushton Wakeling wrote:
> I know, and it's coming. :-) The main memory-related issues will probably not
> show up in a situation like this where all we're doing is storing the graph
> data, but in the case where algorithms are being performed on the data.
For compar
On Thursday, 11 July 2013 at 08:53:07 UTC, renoX wrote:
They cause noticeable hiccups at unpredictable times unless
you have a battery-hungry overpowered CPU that makes pauses
impossible to notice.
Yes and "pauseless GCs" have even higher CPU usage..
It is more about floating garbage than C
On Wednesday, 10 July 2013 at 13:33:15 UTC, Michel Fortin wrote:
On 2013-07-09 18:12:25 +, Paulo Pinto
said:
A bit off-topic, but well worth reading,
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
What I'm retaining from this is that garbage collectors are
wasteful. The
On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
On 2013-07-10 20:43, Paulo Pinto wrote:
What sometimes goes missed between the lines is that one of the
decisions to go ARC instead of GC, is because the Objective-C
GC never
worked properly and ARC offers a better fit for the cu
On Thursday, 11 July 2013 at 07:50:38 UTC, Jonathan M Davis wrote:
On Thursday, July 11, 2013 09:37:56 Jacob Carlborg wrote:
[snip]
Also, if we could make it so that something like
@property int value;
+1
It would be a great timesaver and give a reason for @property to
exist :-)
-=mike
On Thursday, July 11, 2013 09:37:56 Jacob Carlborg wrote:
> I use public fields sometimes but as you say, there are problems. One
> can also run into problems with returning structs by value. The compiler
> would also need to do property rewriting to work flawlessly.
Property rewrites would defini
On Thursday, 11 July 2013 at 04:59:14 UTC, Kenji Hara wrote:
I filed the website bug in bugzilla, and posted pull request.
http://d.puremagic.com/issues/show_bug.cgi?id=10605
https://github.com/D-Programming-Language/dlang.org/pull/351
Kenji Hara
http://msalvarez1.edublogs.org/files/2010/01/
On Thursday, 11 July 2013 at 02:55:24 UTC, Luís Marques wrote:
...
I often find it cleaner to consider D minimal hard encapsulation
unit to be a module, not a class - it just maps naturally to
protection and module system. That means avoiding aggregate
methods as part of stable API/ABI.
Th
On 2013-07-11 07:26, Jonathan M Davis wrote:
In general, I would strongly advise against using public fields if you ever
might want to replace them with property functions. The reason for this is
that property functions really don't do all that great a job of emulating
variables. For instance, t
On 2013-07-11 04:55, "Luís Marques" " wrote:
A case where such reasoning would not apply is when source code
compatibility is not enough, such as when you have a D library. But this
could be solved by something like...
class X
{
@property public int phone;
}
...which wo
On 2013-07-10 20:43, Paulo Pinto wrote:
What sometimes goes missed between the lines is that one of the
decisions to go ARC instead of GC, is because the Objective-C GC never
worked properly and ARC offers a better fit for the current state of
Objective-C world.
First of all, GC was an opt-in a
30 matches
Mail list logo
