On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
I've been working on a project that makes relatively heavy use
of nullable values. I've been using std.typecons.Nullable, and
it mostly works well, but there are some improvements that
could be made to the implementation:
* A toString(
On Tuesday, 8 October 2013 at 00:16:45 UTC, Andrei Alexandrescu
wrote:
To put my money where my mouth is, I have a proof-of-concept
tokenizer for C++ in working state.
http://dpaste.dzfl.pl/d07dd46d
Why do you use "\0" as end-of-stream token:
/**
* All token types include regular and re
Am 09.10.2013 07:23, schrieb PauloPinto:
Apple dropped the GC and went ARC instead, because they never
managed to make it work properly.
It was full of corner cases, and the application could crash if
those cases were not fully taken care of.
Or course the PR message is "We dropped GC because A
On Tue, 08 Oct 2013 20:58:01 -0700, Andrei Alexandrescu
wrote:
http://google-opensource.blogspot.de/2013/10/google-code-in-2013-and-google-summer.html
Andrei
Do you think they'll let us in this year?
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehor
On 9 October 2013 09:05, Walter Bright wrote:
> On 10/8/2013 12:34 PM, Jonathan M Davis wrote:
>
>> I think that it's clear that for some projects, it's critical to minimize
>> the
>> GC, and I think that it's clear that we need to do a better job of
>> supporting
>> the folks who want to minimiz
On Wednesday, 9 October 2013 at 05:15:53 UTC, Manu wrote:
On 9 October 2013 08:58, ponce wrote:
On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe
wrote:
Eh, not necessarily. If it expands to static
assert(!__traits(**hasAnnotationRecursive,
uses_gc));, then the only ones that *nee
On 9 October 2013 08:58, ponce wrote:
> On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:
>
>>
>> Eh, not necessarily. If it expands to static
>> assert(!__traits(**hasAnnotationRecursive,
>> uses_gc));, then the only ones that *need* to be marked are the lowest
>> level ones. The
On Wednesday, 9 October 2013 at 04:38:02 UTC, Andrei Alexandrescu
wrote:
On 10/8/13 9:32 PM, deadalnix wrote:
Overall, I think this is going into the right direction.
However, there
is one thing I don't like with that design.
When you go throw the big switch of death, you match the
beginning
On Wednesday, 9 October 2013 at 03:42:50 UTC, Nick Sabalausky
wrote:
Personally, I find Nullable's "alias this" functionality to be a
wonderful convenience. FWIW.
Yeah, it's convenient to be able to switch out T with Nullable(T)
and have it work without breaking the API... Well, it sort of
wo
On Wednesday, 9 October 2013 at 03:46:20 UTC, Walter Bright wrote:
On 10/8/2013 8:38 PM, Andrei Alexandrescu wrote:
Only Levenshtein distance produces garbage in std.algorithm.
Perhaps the documentation should reflect that:
http://dlang.org/phobos/std_algorithm.html#levenshteinDistance
I th
On 10/8/13 9:32 PM, deadalnix wrote:
Overall, I think this is going into the right direction. However, there
is one thing I don't like with that design.
When you go throw the big switch of death, you match the beginning of
the string and then you go back to a function that will test where does
i
On 10/8/13 9:33 PM, Brian Schott wrote:
On Wednesday, 9 October 2013 at 03:55:42 UTC, Andrei Alexandrescu wrote:
for the greater good.
YOU CALL YOURSELVES A COMMUNITY THAT CARES?
http://www.youtube.com/watch?v=yUpbOliTHJY
I swear I had that in mind when I wrote "the greater good". Awesome
On Wednesday, 9 October 2013 at 04:24:23 UTC, Jonathan M Davis
wrote:
Except that for the most part, that's the only way that
immutable objects can
be created - particularly if you're talking about arrays or
AAs. It's _very_
common to do what Walter is describing. On top of that, we're
forced t
On Wednesday, 9 October 2013 at 03:55:42 UTC, Andrei Alexandrescu
wrote:
On 10/8/13 6:26 PM, Walter Bright wrote:
On 10/4/2013 5:24 PM, Andrei Alexandrescu wrote:
[...]
Some points:
1. This is a replacement for the switch statement starting at
around
line 505 in advance()
https://github.c
On Wednesday, 9 October 2013 at 03:55:42 UTC, Andrei Alexandrescu
wrote:
for the greater good.
YOU CALL YOURSELVES A COMMUNITY THAT CARES?
http://www.youtube.com/watch?v=yUpbOliTHJY
On 10/8/13 9:24 PM, Jonathan M Davis wrote:
On Tuesday, October 08, 2013 20:46:16 Andrei Alexandrescu wrote:
On 10/8/13 8:31 PM, Walter Bright wrote:
On 10/8/2013 8:18 PM, deadalnix wrote:
We also badly need to be able to use type qualifier. We must
stop the world when collecting thread local
On Tuesday, October 08, 2013 20:46:16 Andrei Alexandrescu wrote:
> On 10/8/13 8:31 PM, Walter Bright wrote:
> > On 10/8/2013 8:18 PM, deadalnix wrote:
> >> We also badly need to be able to use type qualifier. We must
> >> stop the world when collecting thread local data or immutable one.
> >> That
On Tue, 08 Oct 2013 19:22:34 -0700
Andrei Alexandrescu wrote:
>
> It's clear that the perception of GC will not change soon, however
> good or not the arguments may be as applied to various situations and
> projects. It is also a reality that our GC is slow.
>
> So we need to attack this proble
On Wednesday, 9 October 2013 at 03:46:16 UTC, Andrei Alexandrescu
wrote:
On 10/8/13 8:31 PM, Walter Bright wrote:
On 10/8/2013 8:18 PM, deadalnix wrote:
We also badly need to be able to use type qualifier. We must
stop the world when collecting thread local data or immutable
one.
That do not
On 10/8/13 6:26 PM, Walter Bright wrote:
On 10/4/2013 5:24 PM, Andrei Alexandrescu wrote:
[...]
Some points:
1. This is a replacement for the switch statement starting at around
line 505 in advance()
https://github.com/Hackerpilot/phobos/blob/9bdb7f97bb8021f3b0d0291896b8fe21a6fead23/std/d/l
http://google-opensource.blogspot.de/2013/10/google-code-in-2013-and-google-summer.html
Andrei
On Tuesday, 8 October 2013 at 17:26:46 UTC, Stefan Frijters wrote:
andrei wrote:
* We need to have a battery of multidimensional array shapes
along with
simple iteration and access primitives, at least for interfacing
with
scientific libraries that define and expect such formats. I'm
thinking
On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
* Making isNull() @property
Hmm... looks like it's already @property. I guess this happened
after the last update to the Phobos docs.
I'll still need to fix the other stuff, though.
On 10/8/13 8:45 PM, Walter Bright wrote:
On 10/8/2013 8:38 PM, Andrei Alexandrescu wrote:
Only Levenshtein distance produces garbage in std.algorithm.
Perhaps the documentation should reflect that:
http://dlang.org/phobos/std_algorithm.html#levenshteinDistance
I'll need to fix the function
On 10/8/2013 8:38 PM, Andrei Alexandrescu wrote:
Only Levenshtein distance produces garbage in std.algorithm.
Perhaps the documentation should reflect that:
http://dlang.org/phobos/std_algorithm.html#levenshteinDistance
On 10/8/13 8:31 PM, Walter Bright wrote:
On 10/8/2013 8:18 PM, deadalnix wrote:
We also badly need to be able to use type qualifier. We must
stop the world when collecting thread local data or immutable one.
That do not
make any sense.
Making this work is fraught with difficulty. It is normal
On Tue, 08 Oct 2013 22:55:34 +0200
"monarch_dodra" wrote:
>
> A Nullable!T isn't a T. It's a T handler.
I see that as an (unavoidable) implementation detail.
> "alias this" allows implicit cast, which should
> only happen with a "is a" relation. Using it in a different
> context (such as null
On Wednesday, 9 October 2013 at 03:38:56 UTC, Andrei Alexandrescu
wrote:
Only Levenshtein distance produces garbage in std.algorithm.
Yeah, I was referring more to phobos as a whole than algorithm
specifically there, just using the principle on principle.
On 10/8/13 4:29 PM, Adam D. Ruppe wrote:
On Tuesday, 8 October 2013 at 22:58:02 UTC, ponce wrote:
But is it even necessary?
It is nice to have stdlib functions available that can be used anywhere.
For std.algorithm, Andrei has said if you ever implement an algorithm by
hand, it means the libra
On 10/8/13 4:45 PM, Jonathan M Davis wrote:
On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
I thought about an alternative approach:
Instead of using a (yet another) annotation, how about
introducing a flag similar to -cov, which would output lines in
which the GC is used.
This informatio
On 10/8/13 4:22 PM, Sean Kelly wrote:
On Oct 8, 2013, at 3:38 PM, Walter Bright wrote:
On 10/8/2013 3:02 PM, Peter Alexander wrote:
You may argue that profiling won't always catch accidental allocations due to
test coverage. This is true, but then @nogc is only a partial fix to this
anyway. I
On 10/8/2013 8:18 PM, deadalnix wrote:
We also badly need to be able to use type qualifier. We must
stop the world when collecting thread local data or immutable one. That do not
make any sense.
Making this work is fraught with difficulty. It is normal behavior in D to
create local data with n
On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu
wrote:
* Get Robert Schadek's precise GC in. Walter and I have become
101% convinced a precise GC is the one way to go about GC.
This make sense. We also badly need to be able to use type
qualifier. We must stop the world when
On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei Alexandrescu
wrote:
* Advertise all of the above in a top module such as
std.refcounted. It's amazing how many D programmers have no
idea RefCounted even exists.
std.typecons is a little treasure trove of stuff nobody can find
or knows ab
On 10/8/13 9:29 AM, ponce wrote:
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
It is not overblown. It is simply "@nogc" which is lacking but
absolutely mandatory. Amount of hidden language allocations makes
manually cleaning code of those via runtime asserts completely
unreasonable
On 10/08/2013 11:43 AM, ponce wrote:
At least on Internet forums, there seems to be an entire category of
people dismissing D immediately because it has a GC.
I have just read an interesting blog post about GC
http://prog21.dadgum.com/15.html
On Tuesday, 8 October 2013 at 20:55:35 UTC, monarch_dodra wrote:
Or we could just nuke the alias this. A Nullable!T isn't a T.
It's a T handler. "alias this" allows implicit cast, which
should only happen with a "is a" relation. Using it in a
different context (such as nullable) is wrong, and
On 10/4/2013 5:24 PM, Andrei Alexandrescu wrote:
[...]
Some points:
1. This is a replacement for the switch statement starting at around line 505 in
advance()
https://github.com/Hackerpilot/phobos/blob/9bdb7f97bb8021f3b0d0291896b8fe21a6fead23/std/d/lexer.d
It is not a replacement for the r
On Wednesday, 9 October 2013 at 01:27:22 UTC, Walter Bright wrote:
On 10/4/2013 5:24 PM, Andrei Alexandrescu wrote:
[...]
Some points:
1. This is a replacement for the switch statement starting at
around line 505 in advance()
https://github.com/Hackerpilot/phobos/blob/9bdb7f97bb8021f3b0d02
On 10/8/2013 5:49 PM, Brad Anderson wrote:
On Wednesday, 9 October 2013 at 00:01:30 UTC, Walter Bright wrote:
On 10/8/2013 4:32 PM, Brad Anderson wrote:
Time to replace the Garbage Collector with a Memory Recycler.
"Soylent Green" ?
"You've got to tell them... It's bar...foo is made out of
On 10/8/2013 2:24 PM, Nick Sabalausky wrote:
Heck, it's a common, well-established tactic for corporations.
It's hardly just for corporations. Nuisance lawsuits are commonly filed by
individuals, too. Pretty much all corporations above a certain size have a
continuous stream of them filed aga
On 10/8/2013 2:50 PM, Joseph Rushton Wakeling wrote:
So, just to be careful, disclaimer again: I am not a lawyer, this is not legal
advice.
Isn't it sad that we feel compelled to have to insert such disclaimers?
On Wednesday, 9 October 2013 at 00:01:30 UTC, Walter Bright wrote:
On 10/8/2013 4:32 PM, Brad Anderson wrote:
Time to replace the Garbage Collector with a Memory Recycler.
"Soylent Green" ?
"You've got to tell them... It's bar...foo is made out of bar"
On Wednesday, 9 October 2013 at 00:00:09 UTC, ponce wrote:
Resource Guard?
Actually, I've been coming to see the gc as being an
implementation detail for immutability, and memory safety is a
secondary piece.
With immutable though, you are guaranteeing that the contents
never change. Never
On 10/8/2013 4:32 PM, Brad Anderson wrote:
Time to replace the Garbage Collector with a Memory Recycler.
"Soylent Green" ?
On Tuesday, 8 October 2013 at 23:32:51 UTC, Brad Anderson wrote:
On Tuesday, 8 October 2013 at 23:05:37 UTC, Walter Bright wrote:
We have a similar problem with "GC". People hear that word,
and they are instantly turned off. No amount of education will
change that. We simply have to find a bett
On 10/8/13 1:41 PM, Dicebot wrote:
On Tuesday, 8 October 2013 at 19:52:32 UTC, Brad Roberts wrote:
On 10/8/13 10:00 AM, Dicebot wrote:
proper performance
I apologize for picking out your post, Dicebot, as the illustrative example,
but I see this pop up
in various discussion and I've been me
On Wednesday, October 09, 2013 01:04:39 Tourist wrote:
> I thought about an alternative approach:
> Instead of using a (yet another) annotation, how about
> introducing a flag similar to -cov, which would output lines in
> which the GC is used.
> This information can be used by an IDE to highlight
On Tuesday, 8 October 2013 at 23:05:37 UTC, Walter Bright wrote:
We have a similar problem with "GC". People hear that word, and
they are instantly turned off. No amount of education will
change that. We simply have to find a better way to deal with
this issue.
Time to replace the Garbage Col
On Tuesday, 8 October 2013 at 22:58:02 UTC, ponce wrote:
But is it even necessary?
It is nice to have stdlib functions available that can be used
anywhere. For std.algorithm, Andrei has said if you ever
implement an algorithm by hand, it means the library has failed.
But there's two places w
On Oct 8, 2013, at 3:38 PM, Walter Bright wrote:
> On 10/8/2013 3:02 PM, Peter Alexander wrote:
>> You may argue that profiling won't always catch accidental allocations due to
>> test coverage. This is true, but then @nogc is only a partial fix to this
>> anyway. It will catch GC allocations, bu
On 10/8/2013 12:34 PM, Jonathan M Davis wrote:
I think that it's clear that for some projects, it's critical to minimize the
GC, and I think that it's clear that we need to do a better job of supporting
the folks who want to minimize GC usage, but I also think that for the vast
majority of cases,
On Tuesday, 8 October 2013 at 22:53:35 UTC, Walter Bright wrote:
What you're suggesting is called "interprocedural analysis" and
doesn't work in a system with separate compilation (meaning
that function bodies are hidden from the compiler).
Eh, that's not a dealbreaker, especially with phobos
On Tuesday, 8 October 2013 at 10:34:23 UTC, Chris wrote:
A short OT question: A friend of mine wants to set up a forum
or mailing list and would like to know to which extent the
moderator or owner of the forum is liable, if some random troll
or member puts libelous, insulting or racist remarks
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
At least on Internet forums, there seems to be an entire
category of people dismissing D immediately because it has a GC.
http://www.reddit.com/r/programming/comments/1nxs2i/the_state_of_rust_08/ccne46t
http://www.reddit.com/r/programming
On Tuesday, 8 October 2013 at 22:45:51 UTC, Adam D. Ruppe wrote:
Eh, not necessarily. If it expands to static
assert(!__traits(hasAnnotationRecursive, uses_gc));, then the
only ones that *need* to be marked are the lowest level ones.
Then it figures out the rest only on demand.
Then, on the
On 10/8/2013 3:45 PM, Adam D. Ruppe wrote:
On Tuesday, 8 October 2013 at 22:37:28 UTC, Walter Bright wrote:
Every function an @nogc function calls will also have to be @nogc.
Eh, not necessarily. If it expands to static
assert(!__traits(hasAnnotationRecursive, uses_gc));, then the only ones th
On Tuesday, 8 October 2013 at 22:37:28 UTC, Walter Bright wrote:
Every function an @nogc function calls will also have to be
@nogc.
Eh, not necessarily. If it expands to static
assert(!__traits(hasAnnotationRecursive, uses_gc));, then the
only ones that *need* to be marked are the lowest leve
On 10/8/2013 3:02 PM, Peter Alexander wrote:
You may argue that profiling won't always catch accidental allocations due to
test coverage. This is true, but then @nogc is only a partial fix to this
anyway. It will catch GC allocations, but what about accidental calls to malloc,
mmap, or maybe an a
On 10/8/2013 9:22 AM, Dicebot wrote:
It is simply "@nogc" which is lacking but absolutely
mandatory.
Adding @nogc is fairly simple. The trouble, though, is (like purity) it is
transitive. Every function an @nogc function calls will also have to be @nogc.
This will entail a great deal of work
On Tuesday, 8 October 2013 at 20:44:56 UTC, deadalnix wrote:
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
Is there a plan to have a standard counter-attack to that
kind of overblown problems?
It could be just a solid blog p
On 10/8/2013 1:38 PM, Chris wrote:
Was just wondering if anyone on this forum has any experience with these things.
After a little bit of research I've come to the conclusion that it's a
minefield. The old Windows slogan applies: Click and pray!
PS Ask a lawyer? You're kidding. Seriously.
The
On Tuesday, 8 October 2013 at 20:44:55 UTC, Dicebot wrote:
On Tuesday, 8 October 2013 at 19:38:22 UTC, Peter Alexander
wrote:
Making sure your code doesn't allocate isn't that difficult.
What would you use for that? It is not difficult, it is
unnecessary (and considerably) time-consuming.
J
What would you use for that? It is not difficult, it is
unnecessary (and considerably) time-consuming.
It's likely allocations would show up in a profiler since GC
collections are started by those. But I never tested it.
On Tuesday, 8 October 2013 at 21:24:07 UTC, Nick Sabalausky wrote:
Obviously don't take this as true legal advice, just one
random curmudgeon's opinion ;)
Indeed. In the UK I'd like to see the lawsuit that would reach
court for "This bloke on the internet told me it was like this
and he turn
On Tue, 08 Oct 2013 17:42:20 +0200
Joseph Rushton Wakeling wrote:
>
> But that is "unlikely", not "impossible". Someone who had a bone to
> pick with you could probably still launch suit. In some
> circumstances I wouldn't bet against that happening if somebody's
> goal was to shut down a websi
On Tuesday, 8 October 2013 at 20:55:39 UTC, Paulo Pinto wrote:
How did you manage to keep the request size portable across
processors/motherboards?
Was the hardware design fixed?
Yes it was tightly coupled h/w + s/w solution sold as a whole and
portability was out of question. I am still und
Am 08.10.2013 22:39, schrieb Dicebot:
On Tuesday, 8 October 2013 at 17:55:33 UTC, Araq wrote:
O(1) malloc implementations exist, it is a solved problem.
(http://www.gii.upv.es/tlsf/)
custom allocator != generic malloc
In such conditions you almost always want to use incremental region
allocat
On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
I've been working on a project that makes relatively heavy use
of nullable values. I've been using std.typecons.Nullable, and
it mostly works well, but there are some improvements that
could be made to the implementation:
* A toString(
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
Is there a plan to have a standard counter-attack to that kind
of overblown problems?
It could be just a solid blog post or a @nogc feature.
It is not overblown.
I'm certain t
On Tuesday, 8 October 2013 at 19:52:32 UTC, Brad Roberts wrote:
On 10/8/13 10:00 AM, Dicebot wrote:
proper performance
I apologize for picking out your post, Dicebot, as the
illustrative example, but I see this pop up in various
discussion and I've been meaning to comment on it for a while.
On Tuesday, 8 October 2013 at 19:38:22 UTC, Peter Alexander wrote:
Making sure your code doesn't allocate isn't that difficult.
What would you use for that? It is not difficult, it is
unnecessary (and considerably) time-consuming.
On Tuesday, 8 October 2013 at 17:55:33 UTC, Araq wrote:
O(1) malloc implementations exist, it is a solved problem.
(http://www.gii.upv.es/tlsf/)
custom allocator != generic malloc
In such conditions you almost always want to use incremental
region allocator anyway. Problem is hidden automatic
On Tuesday, 8 October 2013 at 19:54:40 UTC, Brad Roberts wrote:
On 10/8/13 3:34 AM, Chris wrote:
A short OT question: A friend of mine wants to set up a forum
or mailing list and would like to know
to which extent the moderator or owner of the forum is liable,
if some random troll or member put
On Tuesday, 8 October 2013 at 19:20:05 UTC, Brad Anderson wrote:
The wiki has a pretty good guide of the overall process:
http://wiki.dlang.org/Pull_Requests
That answers most of my questions, but it seems a little...
informal. I guess the formal review process doesn't really apply
to minor
On 10/8/13 3:34 AM, Chris wrote:
A short OT question: A friend of mine wants to set up a forum or mailing list
and would like to know
to which extent the moderator or owner of the forum is liable, if some random
troll or member puts
libelous, insulting or racist remarks on the forum. I guess it
On 10/8/13 10:00 AM, Dicebot wrote:
proper performance
I apologize for picking out your post, Dicebot, as the illustrative example, but I see this pop up
in various discussion and I've been meaning to comment on it for a while.
Please stop using words like 'proper', 'real', and other simila
On Tuesday, 8 October 2013 at 15:42:25 UTC, Joseph Rushton
Wakeling wrote:
On 08/10/13 15:56, Chris wrote:
I see. A private person wouldn't possibly be able to moderate
the forum all the
time. However, mailing lists (a forum via email) might be a
different beast
altogether, because everyone is
On Tuesday, October 08, 2013 18:29:36 ponce wrote:
> On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
> > It is not overblown. It is simply "@nogc" which is lacking but
> > absolutely mandatory. Amount of hidden language allocations
> > makes manually cleaning code of those via runtime as
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
Is there a plan to have a standard counter-attack to that kind
of overblown problems?
It could be just a solid blog post or a @nogc feature.
It is not overblown. It is simply "@
On Tuesday, 8 October 2013 at 19:04:33 UTC, BLM768 wrote:
I've been working on a project that makes relatively heavy use
of nullable values. I've been using std.typecons.Nullable, and
it mostly works well, but there are some improvements that
could be made to the implementation:
* A toString(
I've been working on a project that makes relatively heavy use of
nullable values. I've been using std.typecons.Nullable, and it
mostly works well, but there are some improvements that could be
made to the implementation:
* A toString() method (needed to fix bug #10915)
* An opEquals for compa
On Wednesday, 4 September 2013 at 12:41:52 UTC, Luís Marques
wrote:
I posted it here hoping Walter might comment on this. Maybe he
had a good reason to choose a different section. I'll wait a
while, and if no feedback is given ("it really has to be a
different section because X, Y, Z"), I'll po
DMD does not seem to generate the code coverage report file if
the program is not run from the same directory as the source
file. The documentation does not mention this as a desired
behavior, so it seems to be a bug, but maybe it is a safeguard?
For instance, this works:
~/test$ dmd -cov
Imagine stuff like vibe.d - for proper performance you don't
want to make any allocations during request handling. Neither
GC, nor malloc.
This is absurd.
O(1) malloc implementations exist, it is a solved problem.
(http://www.gii.upv.es/tlsf/)
TLSF executes a maximum of 168 processor instruct
On Tuesday, 8 October 2013 at 17:00:35 UTC, Dicebot wrote:
On Tuesday, 8 October 2013 at 16:29:38 UTC, ponce wrote:
Hidden language allocations:
- concatenation operator ~
- homogeneous arguments void (T[]... args)
- "real" closures that escapes
- array literals
- some phobos calls
What els
On Tuesday, 8 October 2013 at 16:29:38 UTC, ponce wrote:
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
It is not overblown. It is simply "@nogc" which is lacking but
absolutely mandatory. Amount of hidden language allocations
makes manually cleaning code of those via runtime assert
On Sat, 28 Sep 2013 18:38:47 +0200, simendsjo wrote:
> I've been working on a more or less complete rewrite of the
> mysql-native module.
>
I think this is a great first step. Code is more readable, easier
to follow (compared to the pointer stuff in the original).
Code has some distinctly 64bi
On Tuesday, 8 October 2013 at 14:41:47 UTC, Denis Shelomovskij
wrote:
I accidentally discovered Andrei wrote [1] multidimensional
array implementation is needed. If it really is, I will work to
revise the API and prepare my implementation [2] for review if
nobody is doing it already.
Also as
On 10/8/13, Adam D. Ruppe wrote:
> That brings up another interesting advantage to my extensible
> scheme: we could also define @blocking in the library to put on
> I/O calls and then vibe.d does a check for it and complains if
> you called one.
Kind of relevant, I've recently filed this:
http://
On Tuesday, 8 October 2013 at 17:00:35 UTC, Dicebot wrote:
Imagine stuff like vibe.d - for proper performance you don't
want to make any allocations during request handling.
That brings up another interesting advantage to my extensible
scheme: we could also define @blocking in the library to p
On Tuesday, 8 October 2013 at 16:24:05 UTC, Dicebot wrote:
Runtime check is almost useless for this.
They're how I do most the allocation checks now and could also be
put in unit tests.
But I agree the ideal would be a compile time check. The way I
want it to work is to define a new thing i
On Tuesday, 8 October 2013 at 16:29:38 UTC, ponce wrote:
Hidden language allocations:
- concatenation operator ~
- homogeneous arguments void (T[]... args)
- "real" closures that escapes
- array literals
- some phobos calls
What else am I missing?
I don't see the big problem, and a small fra
On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
It is not overblown. It is simply "@nogc" which is lacking but
absolutely mandatory. Amount of hidden language allocations
makes manually cleaning code of those via runtime asserts
completely unreasonable for real project.
Hidden lang
On Tuesday, 8 October 2013 at 16:18:50 UTC, Adam D. Ruppe wrote:
On Tuesday, 8 October 2013 at 16:02:05 UTC, Tourist wrote:
On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe
wrote:
2) have a flag where you can make gc allocations throw an
assert error at runtime for debugging critical s
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
Is there a plan to have a standard counter-attack to that kind
of overblown problems?
It could be just a solid blog post or a @nogc feature.
It is not overblown. It is simply "@nogc" which is lacking but
absolutely mandatory. Amount of
On Tuesday, 8 October 2013 at 16:18:50 UTC, Adam D. Ruppe wrote:
One is I can implement a runtime check pretty easily so it'd
just be the first step because it would go quickly.
Runtime check is almost useless for this.
On Tuesday, 8 October 2013 at 16:02:05 UTC, Tourist wrote:
On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe wrote:
2) have a flag where you can make gc allocations throw an
assert error at runtime for debugging critical sections
Why handle it at runtime and not at compile time?
One
On Tuesday, 8 October 2013 at 15:53:47 UTC, Adam D. Ruppe wrote:
2) have a flag where you can make gc allocations throw an
assert error at runtime for debugging critical sections
Why handle it at runtime and not at compile time?
Am 08.10.2013 17:55, schrieb qznc:
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
Whatever rational rebutal we have it's never heard.
The long answer is that it's not a real problem. But it seems people
want a short answer. It's also an annoying fight to have since so much
of it is bas
1 - 100 of 132 matches
Mail list logo
