On Thursday, 6 February 2014 at 01:01:59 UTC, Chris Williams
wrote:
I think that the advantages that are added by template-based
compilability checks can be gained without losing flexibility
if we add a more lenient interface definition, like:
I love the idea of some kind of "static interface"
On Thursday, 6 February 2014 at 02:31:19 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 February 2014 at 00:42:20 UTC, Andrei
Alexandrescu
wrote:
One school of thought seems to be that D should be everything
it is today, just with reference counting throughout instead
of garbage collection. On
On 5.2.2014. 0:51, Andrei Alexandrescu wrote:
> Consider we add a library slice type called RCSlice!T. It would have the
> same primitives as T[] but would use reference counting through and
> through. When the last reference count is gone, the buffer underlying
> the slice is freed. The underlying
On Wednesday, 5 February 2014 at 20:37:44 UTC, Sean Kelly wrote:
As for when this will be available... I will have a pull request
sorted out shortly, so you could start playing with it soon. It
being included in an actual release means a review and such, but
as this is really just a fairly succ
On 2/6/14, 12:28 AM, luka8088 wrote:
On 5.2.2014. 0:51, Andrei Alexandrescu wrote:
Consider we add a library slice type called RCSlice!T. It would have the
same primitives as T[] but would use reference counting through and
through. When the last reference count is gone, the buffer underlying
th
On Thursday, 6 February 2014 at 08:06:54 UTC, Paulo Pinto wrote:
That won't play ball with third party libraries distributed in
binary form.
That is not obvious, you specify the runtime. Anyway, whole
program analysis also does not play well with binary libraries
without detailed semantic met
On Thursday, 6 February 2014 at 08:28:34 UTC, luka8088 wrote:
is manual or automatic. And it seems to me that a new type
qualifier is
a way to go:
class A {
garbageCollected(B) child1;
referenceCounted(B) child2;
manualMemory(B) child3;
}
class A {
@shared @delayedrelease @nodestructor
Here is a document about the scheduler design in Go:
https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit
The C sources for the Go scheduler are here:
http://code.google.com/p/go/source/browse/src/pkg/runtime/proc.c?r=01acf1dbe91f673f6308248b8f45ec0564b1d751
Mayb
On Thursday, 6 February 2014 at 08:38:57 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 February 2014 at 08:06:54 UTC, Paulo Pinto wrote:
That won't play ball with third party libraries distributed in
binary form.
That is not obvious, you specify the runtime. Anyway, whole
program analysis al
On Thursday, 6 February 2014 at 09:27:19 UTC, Paulo Pinto wrote:
So what do you do when different libraries require different
runtimes?
I guess a given compiler could have a "cross compiler option"
that generates libraries for all the available runtimes the
compiler supports?
To be more spe
Am 06.02.2014 11:21, schrieb "Ola Fosheim Grøstad"
Not having the source code to a library is rather risky in terms
of having to work around bugs by trail and error, without even
knowing what the bug actually is.
so you're not work in the normal software development business where
non-source co
On Thursday, 6 February 2014 at 01:01:59 UTC, Chris Williams
wrote:
1. You only know what the target is that you have to hit by
looking at their source. Or, the person who wrote the template
checker needs to, effectively, rewrite their check as a
document comment. (E.g. see std.range isInputRan
On Thursday, 6 February 2014 at 10:29:20 UTC, dennis luehring
wrote:
so you're not work in the normal software development business
where
non-source code third party dependicies are fully normal :)
Not in terms of libraries no, what libraries would that be?
In terms of infrastructure, yes, bu
Am 06.02.2014 11:43, schrieb "Ola Fosheim Grøstad"
":
On Thursday, 6 February 2014 at 10:29:20 UTC, dennis luehring
wrote:
so you're not work in the normal software development business
where
non-source code third party dependicies are fully normal :)
Not in terms of libraries no, what librari
On Tuesday, 4 February 2014 at 03:01:28 UTC, Andrei Alexandrescu
wrote:
On 2/3/14, 6:24 PM, Mathias LANG wrote:
Hi all,
Registration for mentoring organization has begun for GSoC
2014 !
As mentionned in the announce [1], it will end the 14th of
February, 2014.
Will Digital Mars be a mentorin
On 6 February 2014 20:21, <"Ola Fosheim Grøstad\"
"@puremagic.com> wrote:
> On Thursday, 6 February 2014 at 09:27:19 UTC, Paulo Pinto wrote:
>
>> So what do you do when different libraries require different runtimes?
>>
>
> I guess a given compiler could have a "cross compiler option" that
> gener
On Thursday, 6 February 2014 at 11:08:51 UTC, dennis luehring
wrote:
all libraries that other deparments don't want you to see or
you don't
need to see - so unnormal in your environment?
My environment is kind of not the point (but yes that would have
been un-normal :-). If it is internal the
On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
Yes these are C libs, but the idea that people don't regularly
use
proprietary libs is fantasy.
I never claimed that people don't do it. I claimed that it is
risky if you don't have a replacement for it. And I don't think
one should l
Anti-GC crowd tries to promote ARC as an deterministic alternative for
memory management.
I noticed that people promoting ARC do not provide any disadvantages
for proposed approach.
The thing is in gamedev and other soft-realitime software background
only a handfull types of resources are real
On 2014-02-06 04:56:28 +, Andrei Alexandrescu
said:
On 2/5/14, 4:53 PM, Michel Fortin wrote:
On 2014-02-05 22:19:27 +, Andrei Alexandrescu
said:
I want to make one positive step toward improving memory allocation in
the D language.
I know. But I find your proposal confusing.
Per
On Thursday, 6 February 2014 at 11:37:59 UTC, Max Klyga wrote:
Anti-GC crowd tries to promote ARC as an deterministic
alternative for memory management.
I noticed that people promoting ARC do not provide any
disadvantages for proposed approach.
The thing is in gamedev and other soft-realitime
On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
Some that I regularly encounter: system libs, opengl, directx,
fmod,
physics (havok, phyzx, etc), animation (euphoria, natural
And just to nitpick:
1. Games are hit or miss with a very short life cycle. This is
not typical. Most softw
On Thursday, 6 February 2014 at 11:59:49 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 February 2014 at 11:29:35 UTC, Manu wrote:
Some that I regularly encounter: system libs, opengl, directx,
fmod,
physics (havok, phyzx, etc), animation (euphoria, natural
And just to nitpick:
1. Games are
On Thursday, 6 February 2014 at 12:12:31 UTC, Paulo Pinto wrote:
D will never be taken serious by its target audience if no
proper support is available.
What is the target audience? Is it clearly defined?
In the enterprise world I work on, very few projects have 100%
source code available.
What is nice about CSP is that you can proof that your code is
free of deadlocks. The Go guys have developed a tool that
parses the code and then tells you what it has found.
Note that the Go race detector isn't a static analysis tool that
identifies deadlocks at compile time; it instruments t
On Thursday, 6 February 2014 at 12:43:19 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 6 February 2014 at 12:12:31 UTC, Paulo Pinto wrote:
D will never be taken serious by its target audience if no
proper support is available.
What is the target audience? Is it clearly defined?
In the enterpri
On Thursday, 6 February 2014 at 13:03:43 UTC, Paulo Pinto wrote:
You would be amazed how many times I have written FFI code that
decrypts source code on load.
You can probably create a decent decompiler for D-code given the
reliance on GC/stack frames etc, so I am not sure if that is a
ration
Am 06.02.2014 12:37, schrieb Max Klyga:
Anti-GC crowd tries to promote ARC as an deterministic alternative for
memory management.
I noticed that people promoting ARC do not provide any disadvantages for
proposed approach.
The thing is in gamedev and other soft-realitime software background
only
On Thursday, 6 February 2014 at 13:23:14 UTC, Sönke Ludwig wrote:
Am 06.02.2014 12:37, schrieb Max Klyga:
Anti-GC crowd tries to promote ARC as an deterministic
alternative for
memory management.
I noticed that people promoting ARC do not provide any
disadvantages for
proposed approach.
The
On Thursday, 6 February 2014 at 13:00:51 UTC, logicchains wrote:
Note that the Go race detector isn't a static analysis tool
that identifies deadlocks at compile time; it instruments the
code and then detects race conditions at runtime. It's based on
the C/C++ ThreadSanitizer runtime library,
I still wonder where the idea of replacing GC with something as a
silver bullet came from. There is no problem with GC itself as
you can remove it easily. Problem is state of language after it
was removed and it is something completely different and
unrelated.
All this ARC fuss came from few
On Thursday, 6 February 2014 at 05:27:22 UTC, Mike Parker wrote:
A cursory look at Nitro suggests they are using an ECS with
DOP. Given that they're providing ranges for iterating the
data, it will fit into D's range-based component pipelines
(std.algorithm and such).
That seems cool. I can o
On Thursday, 6 February 2014 at 11:37:59 UTC, Max Klyga wrote:
Anti-GC crowd tries to promote ARC as an deterministic
alternative for memory management.
I noticed that people promoting ARC do not provide any
disadvantages for proposed approach.
Feel free to extend this wiki page:
http://wiki
Recently Erlang language has added several things:
http://joearms.github.io/2014/02/01/big-changes-to-erlang.html
One interesting change is the syntax to handle associative arrays
(that are meant to be used a little like records):
Updating a map is done as follows:
NewX = X#{ key1 => Val1, .
On Thursday, 6 February 2014 at 14:15:47 UTC, bearophile wrote:
Recently Erlang language has added several things:
http://joearms.github.io/2014/02/01/big-changes-to-erlang.html
One interesting change is the syntax to handle associative
arrays (that are meant to be used a little like records):
On Thursday, 6 February 2014 at 13:47:22 UTC, Meta wrote:
On Thursday, 6 February 2014 at 05:27:22 UTC, Mike Parker wrote:
A cursory look at Nitro suggests they are using an ECS with
DOP. Given that they're providing ranges for iterating the
data, it will fit into D's range-based component pipe
On Thursday, 6 February 2014 at 11:37:59 UTC, Max Klyga wrote:
Anti-GC crowd tries to promote ARC as an deterministic
alternative for memory management.
I noticed that people promoting ARC do not provide any
disadvantages for proposed approach.
The thing is in gamedev and other soft-realitime
Tobias Pankrath:
AA[key] = val; ?
I don't understand. That syntax doesn't give you an error if
'key' is missing in AA.
Bye,
bearophile
Am 06.02.2014 14:35, schrieb Meta:
On Thursday, 6 February 2014 at 13:23:14 UTC, Sönke Ludwig wrote:
Am 06.02.2014 12:37, schrieb Max Klyga:
Anti-GC crowd tries to promote ARC as an deterministic alternative for
memory management.
I noticed that people promoting ARC do not provide any disadvant
https://d.puremagic.com/issues/show_bug.cgi?id=3672
Let's see if we can make this work in two steps: first, making
the existing scope storage class work, and second, but
considering making it the default.
First, let's define it. A scope reference may never escape its
scope. This means:
0) Note that scope is irrelevant on value types. I believ
Am Thu, 6 Feb 2014 14:37:59 +0300
schrieb Max Klyga :
>
> My point is that we should not ruin the language ease of use. We do
> need to deal with Phobos internal allocations, but we should not
> switch to ARC as a default memory management scheme.
What's with all this finger pointing and drawi
On Thursday, 6 February 2014 at 06:46:06 UTC, Arjan wrote:
On Wednesday, 5 February 2014 at 23:47:03 UTC, Chris Williams
wrote:
Nice and clear write up.
I would love to see more of these kind of articles.
I wanted to say the same think. I found your write up very
readable and informative.
Sorry, my lines got mangled, let me try pasting it again.
Making scope the default
===
There's five points to discuss:
1) All variables are assumed to be marked with scope implicitly
2) The exception is structs with a special annotation which marks
that they encapsulate
Making scope the default
===
There's five points to discuss:
1) All variables are assumed to be marked with scope implicitly
2) The exception is structs with a special annotation which marks
that they encapsulate a resource. An encapsulated resource
explicitly marked
On 2/6/14, 3:44 AM, Michel Fortin wrote:
On 2014-02-06 04:56:28 +, Andrei Alexandrescu
said:
On 2/5/14, 4:53 PM, Michel Fortin wrote:
On 2014-02-05 22:19:27 +, Andrei Alexandrescu
said:
I want to make one positive step toward improving memory allocation in
the D language.
I know.
On 2/6/14, 7:11 AM, ponce wrote:
On Thursday, 6 February 2014 at 11:37:59 UTC, Max Klyga wrote:
Anti-GC crowd tries to promote ARC as an deterministic alternative for
memory management.
I noticed that people promoting ARC do not provide any disadvantages
for proposed approach.
The thing is in g
splitting from the ARC thread
On Thursday, 6 February 2014 at 15:47:48 UTC, Johannes Pfau wrote:
As they do not keep references there's no need for ARC or GC,
we just need a way to tell every function how it should
allocate.
yea. I think it is time we hashed out output ranges the same way
we
On 2/6/14, 7:22 AM, Sönke Ludwig wrote:
I'm just not convinced (far from it) that Phobos should be built on top
of such an RCSlice type. I rather strongly agree with Dicebot that the
API should be extended to work with ranges or pre-allocated buffers
where possible + support for custom allocators
On Thursday, 6 February 2014 at 06:30:04 UTC, Benjamin Thaut
wrote:
Am 05.02.2014 23:39, schrieb Martin Cejp:
On Wednesday, 5 February 2014 at 21:37:22 UTC, Benjamin Thaut
wrote:
Am 05.02.2014 22:21, schrieb Ryan Voots:
At the moment I don't think it really does deal with GC
pause times and
Would anyone be willing to take on the ingrate task of creating a
comprehensive list with all Phobos functions (and more generally
artifacts) that allocate memory? That would help a lot with focusing the
discussion.
Andrei
On 2/6/14, 7:47 AM, Johannes Pfau wrote:
Am Thu, 6 Feb 2014 14:37:59 +0300
schrieb Max Klyga :
My point is that we should not ruin the language ease of use. We do
need to deal with Phobos internal allocations, but we should not
switch to ARC as a default memory management scheme.
What's with
On 2/6/14, 8:25 AM, Andrei Alexandrescu wrote:
rcstring rc!(string s) { ... }
I meant
rcstring rc(string s)() { ... }
Andrei
On Thursday, 6 February 2014 at 16:25:37 UTC, Andrei Alexandrescu
wrote:
// lib code
struct RCSlice(T) { ... }
alias rcstring = RCSlice!(immutable char);
rcstring rc!(string s) { ... }
// user code
auto s1 = buildPath!("hello", "world");
auto s2 = buildPath!(rc!"hello", rc!"world");
In this exa
On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu
wrote:
Would anyone be willing to take on the ingrate task of creating
a comprehensive list with all Phobos functions (and more
generally artifacts) that allocate memory? That would help a
lot with focusing the discussion.
Andr
Am 06.02.2014 16:22, schrieb Sönke Ludwig:
Am 06.02.2014 14:35, schrieb Meta:
On Thursday, 6 February 2014 at 13:23:14 UTC, Sönke Ludwig wrote:
Am 06.02.2014 12:37, schrieb Max Klyga:
Anti-GC crowd tries to promote ARC as an deterministic alternative for
memory management.
I noticed that peopl
On Thursday, 6 February 2014 at 16:40:32 UTC, Andrei Alexandrescu
wrote:
The issue here is that Phobos functions need to document
whether e.g. they return memory that can be deallocated or not.
Counterexamples would be returning static strings or subslices
of allocations.
This is why specifyi
On Thu, Feb 06, 2014 at 04:30:31PM +, Dicebot wrote:
> On Thursday, 6 February 2014 at 16:25:37 UTC, Andrei Alexandrescu
> wrote:
> >// lib code
> >struct RCSlice(T) { ... }
> >alias rcstring = RCSlice!(immutable char);
> >rcstring rc!(string s) { ... }
> >
> >// user code
> >auto s1 = buildPat
On 2/6/14, Dicebot wrote:
> Merging https://github.com/D-Programming-Language/dmd/pull/1886
> and running phobos unit tests should make it relatively simple,
> at least for a first pass.
Running the tests is overkill, all you have to do is iterate over each
module and call "-o- -vgc" on it.
We h
On 2/6/14, Andrej Mitrovic wrote:
> We have so many allocations in Phobos that I couldn't even upload my
> text over to a paste site, most sites have a limit of 150Kb! So here
> it is on github:
>
> https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
Ah just rea
On 2/6/14, Andrej Mitrovic wrote:
> On 2/6/14, Andrej Mitrovic wrote:
>> https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
>
> Ah just realized there are duplicates in the report. I guess -vgc is
> emitting dupes.
Updated to remove duplicate reports.
On Thursday, 6 February 2014 at 17:18:59 UTC, Andrej Mitrovic
wrote:
On 2/6/14, Dicebot wrote:
Merging https://github.com/D-Programming-Language/dmd/pull/1886
and running phobos unit tests should make it relatively simple,
at least for a first pass.
Running the tests is overkill, all you have
On Thu, Feb 06, 2014 at 04:47:05PM +0100, Johannes Pfau wrote:
[...]
> Some people seem to want some implicit way to set a 'default'
> allocator, but I haven't heard of any solution that works. (E.g. having
> a thread-local default allocator, per library default allocator, how
> would that even wor
The documentation states:
"The two ranges are assumed to be sorted by less."
Would it make more sense for this function, and its siblings, to
take a SortedRange instead. This would be a breaking change as it
would require people to either sort or assumeSorted before
calling.
But SortedRange
Am Thu, 06 Feb 2014 08:40:28 -0800
schrieb Andrei Alexandrescu :
> >
> > auto gcString = toUpper("test");
> > auto mallocString = toUpper!Malloc("test");
> > ubtye[64] sbuf;
> > auto stackString = toUpper(sbuf[], "test");
> >
> > What's so bad about this?
>
> The issue here is that Phobos functio
On 2/6/14, 9:18 AM, Adam D. Ruppe wrote:
Something that mallocs should return Malloced!T which calls the
appropriate free (specified by the allocator) in the destructor. GC
should return GC!T. Refconted should return RefCounted!T, and so on.
That ain't going to work.
Malloced!T and GC!T sugges
Any time you hard code code something you are also creating
constraints. If people build something on top of what you have
built they inherit those constrains.
Take building a house, once the foundation is laid and the
framework is added it becomes next to impossible to go back and
modify the fo
On 2/6/14, 9:19 AM, H. S. Teoh wrote:
On Thu, Feb 06, 2014 at 04:30:31PM +, Dicebot wrote:
On Thursday, 6 February 2014 at 16:25:37 UTC, Andrei Alexandrescu
wrote:
// lib code
struct RCSlice(T) { ... }
alias rcstring = RCSlice!(immutable char);
rcstring rc!(string s) { ... }
// user code
a
On 2/6/14, 9:21 AM, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
Ah just realized there are duplicates in the report. I guess -vgc is
emitting dupes.
Update
On 2/6/14, 9:35 AM, Jesse Phillips wrote:
The documentation states:
"The two ranges are assumed to be sorted by less."
Would it make more sense for this function, and its siblings, to take a
SortedRange instead. This would be a breaking change as it would require
people to either sort or assume
On Thursday, 6 February 2014 at 17:57:45 UTC, Andrei Alexandrescu
wrote:
On 2/6/14, 9:21 AM, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
Ah just realized th
On Thu, Feb 06, 2014 at 04:21:51PM +, Adam D. Ruppe wrote:
> splitting from the ARC thread
>
> On Thursday, 6 February 2014 at 15:47:48 UTC, Johannes Pfau wrote:
> >As they do not keep references there's no need for ARC or GC,
> >we just need a way to tell every function how it should allocate
On 2/6/14, Andrei Alexandrescu wrote:
> Thanks. I guess we'd need to cross-reference to function names from there.
Updated to include function names.
On Thu, Feb 06, 2014 at 09:56:14AM -0800, Andrei Alexandrescu wrote:
> On 2/6/14, 9:19 AM, H. S. Teoh wrote:
> >On Thu, Feb 06, 2014 at 04:30:31PM +, Dicebot wrote:
> >>On Thursday, 6 February 2014 at 16:25:37 UTC, Andrei Alexandrescu
> >>wrote:
> >>>// lib code
> >>>struct RCSlice(T) { ... }
>
Am Thu, 06 Feb 2014 16:32:08 +
schrieb "Dicebot" :
> On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu
> wrote:
> > Would anyone be willing to take on the ingrate task of creating
> > a comprehensive list with all Phobos functions (and more
> > generally artifacts) that allo
On Thursday, 6 February 2014 at 17:56:15 UTC, Andrei Alexandrescu
wrote:
I will mention again that output ranges lead to quite a bit
more code on the caller site.
People are asking for control over memory management. You can't
then complain that you get control over memory management!
I'd fu
On 2/6/14, 9:54 AM, Frustrated wrote:
Any time you hard code code something you are also creating
constraints. If people build something on top of what you have
built they inherit those constrains.
Nice thought.
So, why not create a design pattern that allows one, at compile
time, to use any
On 2/6/14, 10:05 AM, Johannes Pfau wrote:
Am Thu, 06 Feb 2014 16:32:08 +
schrieb "Dicebot" :
On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu
wrote:
Would anyone be willing to take on the ingrate task of creating
a comprehensive list with all Phobos functions (and more
gen
On 2/6/14, 10:05 AM, grm wrote:
On Thursday, 6 February 2014 at 17:57:45 UTC, Andrei Alexandrescu wrote:
On 2/6/14, 9:21 AM, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allo
On Thursday, 6 February 2014 at 17:57:45 UTC, Andrei Alexandrescu
wrote:
On 2/6/14, 9:21 AM, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
On 2/6/14, Andrej Mitrovic wrote:
https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
Ah just realized th
On 2/6/14, 10:15 AM, Andrej Mitrovic wrote:
On 2/6/14, Andrei Alexandrescu wrote:
Thanks. I guess we'd need to cross-reference to function names from there.
Updated to include function names.
Noice. One
less phobos_allocations.txt | grep 'In function'| sed
"s/.*'\\(.*\\)':/\\1/"|sort|uniq
On 6 Feb 2014 16:56, "Adam D. Ruppe" wrote:
> Making scope the default
> ===
> [...]
I just stumbled upon Rust's memory management scheme yesterday and it
seemed similar to this.
On first glance, I really like it.
I just slapped this together in the other thread, let me
copy/paste it here, talk about it a bit, then I'll finish reading
what you wrote:
struct GCSink(T) {
// so this is a reference type
private struct Impl {
T[] data;
void put(T t) { data ~= t; }
T[] finish()
On 2/6/14, 10:15 AM, H. S. Teoh wrote:
That's only because the current output range API consists of only a
single .put method. Please see the other thread started by Adam Ruppe:
we should spend some time to think about how we can streamline output
ranges so that they can be used just as easily as
On Thursday, 6 February 2014 at 18:25:34 UTC, Andrei Alexandrescu
wrote:
Noice. One
less phobos_allocations.txt | grep 'In function'| sed
"s/.*'\\(.*\\)':/\\1/"|sort|uniq
>phobos_allocating_functions.txt
later, and...
Well I'm just hacking on the -vgc pull to output what I want, but
I should
On 2/6/14, Andrei Alexandrescu wrote:
> Noice. One
>
> less phobos_allocations.txt | grep 'In function'| sed
> "s/.*'\\(.*\\)':/\\1/"|sort|uniq >phobos_allocating_functions.txt
>
> later, and...
Ah you've attached a file, didn't notice it on the left since I
usually skim the avatar part:
http://f
I like the idea, but instead of new!strategy I would prefer:
use @strategy(RefCount)
or
use @strategy(GC) // Default
We would have in druntime some functions which are tagged with
@strategy(Whatever) (which are invoked if the use comes):
@strategy(C_Memory)
T[] new(T : U[], U)(size_t count
On Thursday, 6 February 2014 at 18:18:49 UTC, Andrei Alexandrescu
wrote:
On 2/6/14, 9:54 AM, Frustrated wrote:
{
auto a = new!strategy A;
// implicit deallocation: compiler inserts
strategy.scopeDeallocation(a);
}
I don't think this works. The scope of "strategy" and "a" may
be unrelated. Mo
That's only for implicit allocations though. And please, don't
merge
yet, it'll get another rewrite this weekend ;-)
Please close if you plan to rewrite.
Andrei
expecting the requested close, so some OTs (in random order):
- bought TDPL shortly after it's been released
- was very impress
On Thursday, 6 February 2014 at 18:10:53 UTC, H. S. Teoh wrote:
Would it make sense to have a .full method/property analogous
to input ranges' .empty? Perhaps something like:
That could be ok but I agree that having to check is a pain.
Besides, what are you going to do if it is full? Suppose I
On Thursday, 6 February 2014 at 10:31:45 UTC, Jakob Ovrum wrote:
It seems only the interface approach can claim being less error
prone.
Making them interchangeable with Interfaces is certainly an
option. It's easy to write and doesn't actually lose anything in
the end result. I was figuring t
On 6 February 2014 18:52, fra wrote:
> On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
>>>
>>> One interesting point is that module that were written with avoiding
>>> allocations in mind usually still allocate when throwing exceptions.
>>
>>
>> Good point, we need to addr
On 2/6/14, 10:52 AM, fra wrote:
On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
One interesting point is that module that were written with avoiding
allocations in mind usually still allocate when throwing exceptions.
Good point, we need to address that as well.
Andr
Am Thu, 06 Feb 2014 18:52:20 +
schrieb "fra" :
> On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu
> wrote:
> >> One interesting point is that module that were written with
> >> avoiding
> >> allocations in mind usually still allocate when throwing
> >> exceptions.
> >
> > G
On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu
wrote:
One interesting point is that module that were written with
avoiding
allocations in mind usually still allocate when throwing
exceptions.
Good point, we need to address that as well.
Andrei
Hey, wait a second. How do
On Thursday, 6 February 2014 at 18:29:48 UTC, Matej Nanut wrote:
I just stumbled upon Rust's memory management scheme yesterday
and it seemed similar to this.
Yeah, I haven't used rust but I have read about it, and the more
I think about it, the more I realize it really isn't that new -
it is
On 6 February 2014 18:05, Johannes Pfau wrote:
> Am Thu, 06 Feb 2014 16:32:08 +
> schrieb "Dicebot" :
>
>> On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu
>> wrote:
>> > Would anyone be willing to take on the ingrate task of creating
>> > a comprehensive list with all Phobos
Am Thu, 6 Feb 2014 20:00:50 +0100
schrieb Johannes Pfau :
> Am Thu, 06 Feb 2014 18:52:20 +
> schrieb "fra" :
>
> > On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu
> > wrote:
> > >> One interesting point is that module that were written with
> > >> avoiding
> > >> allocatio
On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu
wrote:
On 2/6/14, 10:05 AM, Johannes Pfau wrote:
Am Thu, 06 Feb 2014 16:32:08 +
schrieb "Dicebot" :
On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei
Alexandrescu
wrote:
Would anyone be willing to take on the ingrate tas
On Thursday, 6 February 2014 at 19:05:49 UTC, Andrej Mitrovic
wrote:
On Thursday, 6 February 2014 at 19:01:33 UTC, Johannes Pfau
wrote:
You can store the exception as a global and that's done for the
OutOfMemoryError IIRC.
Hmm.. is that even safe? I mean in some case of exception
chaining the
1 - 100 of 209 matches
Mail list logo
