Rainer Schuetze writes:
> On 14.05.2014 12:56, "Marc Schütz" " wrote:
>> On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
>>> class C { C next; }
>>>
>>> shared(C) list;
>>>
>>> C newC()
>>> {
>>> return new C; // allocated on the local heap?
>>
>> Yes, because it doesn't say "
On Friday, 16 May 2014 at 16:58:38 UTC, Rainer Schuetze wrote:
On 14.05.2014 12:56, "Marc Schütz" " wrote:
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
Yes, because it doesn'
On 14.05.2014 12:56, "Marc Schütz" " wrote:
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
Yes, because it doesn't say "new shared(C)".
}
void prependToList(C c)
{
synch
On Thursday, 15 May 2014 at 06:30:40 UTC, Jacob Carlborg wrote:
On 14/05/14 23:47, Dmitry Olshansky wrote:
This is curious:
http://burntsushi.net/rustdoc/regex/
It seems they have compile time regular expressions too.
Yeah looks like my knowledge about their macro system is very
outdated.
On 14/05/14 23:47, Dmitry Olshansky wrote:
This is curious:
http://burntsushi.net/rustdoc/regex/
It seems they have compile time regular expressions too.
--
/Jacob Carlborg
14-May-2014 17:16, Dicebot пишет:
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you
On 05/14/2014 06:41 PM, Wyatt wrote:
To me, shared is a type modifier that doesn't implicitely convert to
anything else without casting.
Interesting, maybe this should be clarified better. Having skimmed back
over chapter 13 of TDPL, my understanding of its semantics are that it
only really
On Tuesday, 13 May 2014 at 19:56:20 UTC, Rainer Schuetze wrote:
I just read the first chapters, and according to that, existing
local gcs needs write barriers, so we are back to my second
proposal. The implementation in the paper even adds read
barriers.
At this point, I suspect write barri
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by
http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been
proposing,
more like hy
Walter Bright:
On 5/12/2014 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating
them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and
on
std.variant.VariantN is based on an union, and oft
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
On 13.05.2014 13:09, "Marc Schütz" " wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, "Marc Schütz" " wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zone
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by
http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been
proposing,
more like hy
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been proposing,
more like hygienic version of C macros.
Hmm, I haven't looked at Rust ma
On 13.05.2014 14:20, Wyatt wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
This comes up from time to time, but to me it is very blurry how this
can work in reality.
The paper I linked on Friday [0] presents a collector like this. Are
there concerns I've missed that m
On 13.05.2014 13:09, "Marc Schütz" " wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, "Marc Schütz" " wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where references to
objects of a particular heap c
On Tuesday, 13 May 2014 at 17:22:19 UTC, Steven Schveighoffer
wrote:
The idea I had was to make them pause-on-write. This means,
when the original process attempts to write to the page, it
gets a page-fault, which pauses the thread until the collector
is done with it. This causes the same halti
On Tuesday, 13 May 2014 at 17:37:05 UTC, Steven Schveighoffer
wrote:
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
wrote:
"Steven Schveighoffer" wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching
non-Scanned mem
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been proposing,
more like hygienic version of C macros.
Hmm, I haven't looked at Rust macros that much.
--
/Jacob Carlborg
"Steven Schveighoffer" wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching non-Scanned memory,
it continues.
How long do threads usually go without touching the stack?
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
wrote:
"Steven Schveighoffer" wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching non-Scanned
memory, it continues.
How long do threads usually go without touchin
On Tue, 13 May 2014 13:37:05 -0400, Steven Schveighoffer
wrote:
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
wrote:
"Steven Schveighoffer" wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching non-Scanned
m
On Tue, 13 May 2014 12:14:06 -0400, Ola Fosheim Grøstad
wrote:
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote:
I know this is coming from a position of extreme ignorance, but why do
we have to do copy on write? What about pause on write?
Not sure how that will help? P
On Tuesday, 13 May 2014 at 16:14:07 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer
wrote:
Not sure how that will help? Pointers may still escape
collection?
(as in not being traced, leading to freeing live memory)
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer
wrote:
I know this is coming from a position of extreme ignorance, but
why do we have to do copy on write? What about pause on write?
Not sure how that will help? Pointers may still escape collection?
(but you get that with transact
On 05/13/2014 03:56 PM, Dicebot wrote:
On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is damn
addictive when you try it of D caliber.
It has macros, that basically requires great sup
On Tue, 13 May 2014 02:12:44 -0400, Rainer Schuetze
wrote:
On 13.05.2014 00:15, Martin Nowak wrote:
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual collection in another
th
On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is
damn
addictive when you try it of D caliber.
It has macros, that basically requires great support for static
reflection to be usabl
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
This comes up from time to time, but to me it is very blurry
how this can work in reality.
The paper I linked on Friday [0] presents a collector like this.
Are there concerns I've missed that make that not applicable?
Conside
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, "Marc Schütz" " wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where
references to
objects of a particular heap can be placed), exempting certain
threads
fro
On Tuesday, 13 May 2014 at 06:12:46 UTC, Rainer Schuetze wrote:
On 13.05.2014 00:15, Martin Nowak wrote:
There is a problem with this scheme, copy-on-write is extremely
expensive when a mutation happens. That's one page fault
(context
switch) + copying a whole page + mapping the new page.
On 13.05.2014 00:15, Martin Nowak wrote:
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual collection in another
thread/process while the application can continue to run. This is
On 12.05.2014 13:53, "Marc Schütz" " wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where references to
objects of a particular heap can be placed), exempting certain threads
from GC completely, ...
This comes up from time to time, but to me it
On 5/12/2014 2:28 PM, Xavier Bigand wrote:
All compile time things of D are marvelous.
This with the compile time and the language less error prone make me want D.
I am not sure I need safety so much. It's nice but not mandatory for any of my
projects. The only one which has to be safe is DQuick.
On 5/12/2014 2:32 PM, Steven Schveighoffer wrote:
It's still forbidden. Andrei wrote a template that will verify this at
runtime, but I don't recall its name.
Can you cite the spec where it says it's forbidden? Forgotten templates are not
a convincing argument.
Regardless, Java can use a movin
On Monday, 12 May 2014 at 22:27:06 UTC, Kapps wrote:
because it's so short. This is quite sufficient for most
projects, but perhaps could be tweaked a bit more for certain
aspects like gaming, possibly even enabling concurrent
collection
for generation 0/1, but I'm not sure if this works well o
On Monday, 12 May 2014 at 19:13:50 UTC, Ola Fosheim Grøstad wrote:
On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote:
Depending on how tunable the GC is, I feel like it should be
possible to get away with a GC even for soft real-time programs
like games.
Even if you manage to make it work fo
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual collection in another
thread/process while the application can continue to run. This is the
way Leandro Lucarellas concurrent GC wor
On Monday, 12 May 2014 at 21:22:09 UTC, Steven Schveighoffer
wrote:
On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it is roughly 1/256. This problem is j
On Mon, 12 May 2014 17:32:09 -0400, Steven Schveighoffer
wrote:
The workaround is simply to keep it around, but that's not always a
scalable solution.
Sorry, actually you can free it. That's the correct workaround.
-Steve
On Mon, 12 May 2014 13:52:20 -0400, Walter Bright
wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
It doesn't matter where the false pointers are. The largest issue with
false
pointers is not how many false pointers there are. It only matters how
large the
block is that it "points
Le 12/05/2014 19:14, Dicebot a écrit :
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
But D is *so close*... and I like it! >_<
I have to say that this discussion has certainly left me somewhat
intrigued by Rust though.
I've never given it a fair go because I find the syn
On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it is roughly 1/256. This problem is just about eliminated
with
64-bit pointers.
Not generally true.
On 5/12/2014 12:36 PM, Timon Gehr wrote:
Do you mean the table is not actually global but passed by parameter,
Yes.
But note that the distinction between the two is often blurry. Under the hood on
some systems, global data is accessed via the equivalent of a hidden parameter.
Andrei Alexandrescu:
How did I give the impression it has anything to do with
unions? -- Andrei
OK, so yours is not an answer to my proposal, nor related to it.
Bye,
bearophile
On 5/12/14, 12:59 PM, bearophile wrote:
Andrei Alexandrescu:
I, too, felt the need of onGC() - actually preGC() - in my allocators
implementation.
...
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
How is this going to help increase tracing precis
Andrei Alexandrescu:
I, too, felt the need of onGC() - actually preGC() - in my
allocators implementation.
...
A hook that nulls all freelist heads just as the collection
process starts would be helpful.
How is this going to help increase tracing precision of unions
(and Algebraic built on
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is damn
addictive when you try it of D caliber.
It has macros, that basically requires great support for static
reflection to be usable.
--
/Jacob Carlborg
On 05/12/2014 06:37 PM, Walter Bright wrote:
On 5/12/2014 5:15 AM, Timon Gehr wrote:
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright :
As long as those pointers don't escape. Am I right in that on
On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote:
Depending on how tunable the GC is, I feel like it should be
possible to get away with a GC even for soft real-time programs
like games.
Even if you manage to make it work for game clients you also
should make it work for low latency game se
On 13 May 2014 04:07, Kapps via Digitalmars-d
wrote:
> On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d
> wrote:
>>
>> How long is a collect liable to take in the event the GC threads need
>>
>> to collect? Am I likely to lose my service threads for 100s of
>> milliseconds at a time?
On 5/12/14, 11:17 AM, Dmitry Olshansky wrote:
12-May-2014 22:08, Andrei Alexandrescu пишет:
On 5/12/14, 10:25 AM, bearophile wrote:
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
One word - weak pointers. Then head of freelist is weak and can be
co
12-May-2014 22:08, Andrei Alexandrescu пишет:
On 5/12/14, 10:25 AM, bearophile wrote:
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
One word - weak pointers. Then head of freelist is weak and can be
collected at whim.
Andrei
--
Dmitry Ols
On 5/12/14, 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use algebraic
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it is roughly 1/256. This problem is just about
eliminated with
64-bit pointers.
Not generally true. This presumes that the heap is not in the
lower region of the addres
On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d
wrote:
How long is a collect liable to take in the event the GC
threads need
to collect? Am I likely to lose my service threads for 100s of
milliseconds at a time?
I'll think on it, but I don't think there's anything practically
app
On 13 May 2014 03:44, Walter Bright via Digitalmars-d
wrote:
> On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote:
>>
>> I just searched through my code, and 7 out of 12 unions had pointers.
>
>
> Relative number of objects with unions, not declarations with unions!
Ah, well I have 3 different t
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
It doesn't matter where the false pointers are. The largest issue with false
pointers is not how many false pointers there are. It only matters how large the
block is that it "points" at. The larger your blocks get, the more likely they
are "point
Walter Bright:
BTW, the RTinfo can be used to discriminate unions.
I don't know if std.variant.VariantN is already using such
RTinfo. I don't know much about RTinfo.
Bye,
bearophile
On 5/12/2014 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use algebrai
On 5/12/2014 10:07 AM, Dicebot wrote:
We have already had discussion where I did state that current @nogc
implementation is not robust enough and failed to explain the use case for
weaker @nogc clearly. Conclusion was that we should return to this topic after
Don's DConf talk ;)
Sure - next wee
On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote:
I just searched through my code, and 7 out of 12 unions had pointers.
Relative number of objects with unions, not declarations with unions!
On 13 May 2014 03:14, Dicebot via Digitalmars-d
wrote:
> On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
>>
>> But D is *so close*... and I like it! >_<
>>
>> I have to say that this discussion has certainly left me somewhat
>> intrigued by Rust though.
>> I've never given it
On 13 May 2014 03:17, Walter Bright via Digitalmars-d
wrote:
> On 5/12/2014 4:35 AM, bearophile wrote:
>>
>> I suggested to add an optional method named "onGC" to unions that if
>> present is
>> called at run-time by the GC to know what's the real type of stored data,
>> to
>> make tracing more pr
Walter Bright:
Unions of pointers are so rare in actual code that treating
them conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use
algebraic data types to represent trees and simi
On 5/12/2014 4:35 AM, bearophile wrote:
I suggested to add an optional method named "onGC" to unions that if present is
called at run-time by the GC to know what's the real type of stored data, to
make tracing more precise.
Unions of pointers are so rare in actual code that treating them conser
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d
wrote:
But D is *so close*... and I like it! >_<
I have to say that this discussion has certainly left me
somewhat
intrigued by Rust though.
I've never given it a fair go because I find the syntax so
distasteful
and deterring.
I
On Monday, 12 May 2014 at 17:03:18 UTC, Walter Bright wrote:
On 5/12/2014 2:12 AM, Dicebot wrote:
I think this is more of library writing culture problem than
engineering
problem. High quality library shouldn't rely on any internal
allocations at all,
deferring this decision to user code. Other
On Monday, 12 May 2014 at 16:16:06 UTC, bearophile wrote:
Perhaps the game industry has to start the creation of a
language designed for its needs, like the scientific people
have done (Julia), the browser ones (Rust), the Web ones have
done, etc. With lot of work in less than ten years you can
On 5/12/2014 2:12 AM, Dicebot wrote:
I think this is more of library writing culture problem than engineering
problem. High quality library shouldn't rely on any internal allocations at all,
deferring this decision to user code. Otherwise you will eventually have
problems, GC or not.
Consider m
On 13 May 2014 02:16, bearophile via Digitalmars-d
wrote:
> Manu:
>
>
>> we are an industry in desperate need of salvation,
>> it's LONG overdue, and I want something that actually works well for us,
>> not a crappy set of compromises because the
>> language has a fundamental incompatibility with
On 5/12/2014 5:15 AM, Timon Gehr wrote:
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright :
As long as those pointers don't escape. Am I right in that one cannot
store a
borrowed pointer into a globa
On 5/12/2014 3:18 AM, Marco Leise wrote:
Your were arguing against Michel Fortin's proposal on the
surface, when your requirement cannot even be fulfilled
theoretically it seems.
Lots of people use ARC without a GC.
Which could mean that you don't like
the idea of replacing D's GC with an AR
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
2. you can have the non-pausible code running in a thread that
is not registered with the gc, so the gc won't pause it. This
requires that this thread not allocate gc memory, but it can
use gc memory allocated by other threads, as lon
Manu:
we are an industry in desperate need of salvation,
it's LONG overdue, and I want something that actually works
well for us, not a crappy set of compromises because the
language has a fundamental incompatibility with my industry :/
Perhaps the game industry has to start the creation of
On 12 May 2014 18:45, Walter Bright via Digitalmars-d
wrote:
> On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
>>
>> What? You've never offered me a practical solution.
>
>
> I have, you've just rejected them.
>
>
>> What do I do?
>
>
> 1. you can simply do C++ style memory management. shared
On Sun, 11 May 2014 16:33:04 -0400, Walter Bright
wrote:
On 5/11/2014 2:48 AM, Benjamin Thaut wrote:
Mostly percise doesn't help. Its either fully percise or beeing stuck
with a
impercise mark & sweep.
This is not correct. It helps because most of the false pointers will be
in the heap
On Mon, 12 May 2014 03:39:12 -0400, Manu via Digitalmars-d
wrote:
On 12 May 2014 17:24, Dicebot via Digitalmars-d
You will like Don's talk this year ;)
I'm super-disappointed I can't make it this year!
?!! http://dconf.org/2014/talks/evans.html
We were evicted from
our house, have to
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright :
As long as those pointers don't escape. Am I right in that one cannot
store a
borrowed pointer into a global data structure?
Right, and that's the
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
For a reasonable GC I currently see 2 possible directions:
1. Use a scheme that takes a snapshot of the heap, stack and
registers at the moment of collection and do the actual
collection in another thread/process while the applicat
Timon Gehr:
(Probably more, actually, because it does not provide
precision-unfriendly constructs such as undiscriminated unions.)
I suggested to add an optional method named "onGC" to unions that
if present is called at run-time by the GC to know what's the
real type of stored data, to make
On 05/12/2014 02:50 AM, Walter Bright wrote:
On 5/11/2014 1:59 PM, Timon Gehr wrote:
On 05/11/2014 10:05 PM, Walter Bright wrote:
That's clearly an additional benefit of the borrowed pointer notion. But
have you examined generated Rust code for the cost of inc/dec? I
haven't, but I don't see an
On Monday, 12 May 2014 at 10:51:33 UTC, Marco Leise wrote:
Time will tell if all "well written" D libraries will be @nogc
to move the question of allocations to the user.
If there was such a thing as "weakly &nogc" then we would could
do this
//some library function
void foo(OR, IR)(OR o, I
Am Mon, 12 May 2014 09:32:58 +
schrieb "Paulo Pinto" :
> On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
> > On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
> >> On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
> >>> What? You've never offered me a practical solutio
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
I like this owner/unique, borrow thing.
@ is managed (currently reference counted)
~ is owner
& is borrow
I like it too. But a few notes:
1) The managed pointer @T has been deprecated and you should use
the standard library types Gc an
Am Mon, 12 May 2014 01:54:58 -0700
schrieb Walter Bright :
> On 5/11/2014 10:57 PM, Marco Leise wrote:
> > Am Sun, 11 May 2014 17:50:25 -0700
> > schrieb Walter Bright :
> >
> >> As long as those pointers don't escape. Am I right in that one cannot
> >> store a
> >> borrowed pointer into a global
Am Sun, 11 May 2014 22:11:28 -0700
schrieb Walter Bright :
> > But I thought ARC cannot be designed without GC to resolve
> > cycles.
>
> It can be, there are various schemes to deal with that, including "don't
> create
> cycles". GC is just one of them.
>
> http://en.wikipedia.org/wiki/Refere
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can sim
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
The only solutions to the libraries problem that I can see here
require drastic separation of calls to said libraries from any
even vaguely time critical code. This is quite r
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can simply do C++ style memory management. shared_ptr<>,
etc.
2.
Walter Bright:
But I don't see how this could work in Rust.
Ask it to competent Rust developers/programmers.
Bye,
bearophile
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright :
As long as those pointers don't escape. Am I right in that one cannot store a
borrowed pointer into a global data structure?
Right, and that's the point and entirely positive-to-do™.
This me
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can simply do C++ style memory management. shared_ptr<>, etc.
2. you can have the non-pausible code running in a thread that is
On Monday, 12 May 2014 at 08:10:43 UTC, Tommi wrote:
Perhaps: [..]
Somewhat surprisingly to me, you can later on change the borrowed
pointer in the mutable static 'Test' to point at a mutable static
int:
struct Test {
n: &'static int
}
static old: int = 111;
static mut new: int = 222;
On Monday, 12 May 2014 at 00:50:24 UTC, Walter Bright wrote:
On 5/11/2014 1:59 PM, Timon Gehr wrote:
Borrowed pointers are not even superficially similar to near*.
They are
compatible with everything else, because they can store data
that was borrowed
from anywhere else.
As long as those poi
On 12 May 2014 17:24, Dicebot via Digitalmars-d
wrote:
> On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d wrote:
>>
>> You haven't told me how I can use the GC (or whatever memory
>> management scheme, I really don't care) in the low frequency code
>> (again, read: almost all code ev
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of "@", it's mostly "&" and "~".
Heck I
didn't find any @ while casually browsing the code. It's like
they a
On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d
wrote:
You haven't told me how I can use the GC (or whatever memory
management scheme, I really don't care) in the low frequency
code
(again, read: almost all code ever), and not have it interfere
with
the high frequency code.
Yo
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of "@", it's mostly "&" and "~".
Heck I
didn't find any @ while casually browsing the code. It's like
they a
On 12.05.2014 06:57, "Ola Fosheim Grøstad"
" wrote:
On Sunday, 11 May 2014 at 20:45:08 UTC, Rainer Schuetze wrote:
On 11.05.2014 22:33, Walter Bright wrote:
The Boehm collector cannot move objects around, the D one can.
Oh it can? Really?
Yes. D, for example, requires that objects not
On 12 May 2014 10:50, Walter Bright via Digitalmars-d
wrote:
>
>> They are using Rust to write a safe and performant web browser while
>> developing
>> the language.
>
>
> Sure. But that browser hasn't been released yet. Consider that I've written
> safe and performant code in D, but others tell m
1 - 100 of 421 matches
Mail list logo
