Re: bug with CTFE std.array.array ?

On Thursday, 11 July 2013 at 01:06:12 UTC, Timothee Cour wrote: import std.array; void main(){ //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at compile time enum a2=" ".array;//OK import std.string; //enum a3=" ".splitLines.array;//NG enum a4="".splitLines.array;/

Re: The interaction of encapsulation and properties in D

On Thursday, July 11, 2013 04:55:09 =?UTF-8?B?Ikx1w61z?=.Marques @puremagic.com wrote: > So, summing it up: even assuming that performance is not an > issue, does the advice to always encapsulate your member > variables (as one would do, for instance, in idiomatic Java) > actually make sense for D

Re: Is the compiler supposed to accept this?

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 2013/7/11 Kenji Hara > This is accepts-valid behavior. > > function(parameters) => expr > > means the combi

Re: [OT] Why mobile web apps are slow

There is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface. Your correct John, totally my bad. I'll be more vigilant in which post I reply to as I didn't realize that anyone really read into the reply's source. I'm critical about

Re: isCallableCTFE trait to test whether an expression is callable during CTFE

On Thursday, 11 July 2013 at 03:29:13 UTC, Kenji Hara wrote: On Thursday, 11 July 2013 at 03:10:38 UTC, timotheecour wrote: On Thursday, 11 July 2013 at 02:17:13 UTC, Timothee Cour wrote: [snip] can we add this to std.traits? it allows (among other things) to write unittests for CTFE, etc.

Re: bug with CTFE std.array.array ?

This issue is already fixed in git head. Kenji Hara 2013/7/11 Timothee Cour > import std.array; > > void main(){ > //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at > compile time > enum a2=" ".array;//OK > > import std.string; > //enum a3=" ".splitLines.array;//NG >

Re: Is the compiler supposed to accept this?

This is accepts-valid behavior. function(parameters) => expr means the combination of: 1. specifying "context pointer is not necessary" 2. lambda syntax "(parameters) => expr" I think website documentation has a bug. Kenji Hara 2013/7/10 Brian Schott > While finishing up work on my parser

Re: The interaction of encapsulation and properties in D

On Thursday, 11 July 2013 at 02:55:24 UTC, Luís Marques wrote: So, summing it up: even assuming that performance is not an issue, does the advice to always encapsulate your member variables (as one would do, for instance, in idiomatic Java) actually make sense for D, or would you recommend usin

Re: The interaction of encapsulation and properties in D

(Of course I forgot to change the variable to private in the versions with accessors)

Re: isCallableCTFE trait to test whether an expression is callable during CTFE

On Thursday, 11 July 2013 at 03:10:38 UTC, timotheecour wrote: On Thursday, 11 July 2013 at 02:17:13 UTC, Timothee Cour wrote: [snip] can we add this to std.traits? it allows (among other things) to write unittests for CTFE, etc. Phobos has an internal helper function for testing CTFEable. h

Re: isCallableCTFE trait to test whether an expression is callable during CTFE

On Thursday, 11 July 2013 at 02:17:13 UTC, Timothee Cour wrote: template isCallableCTFE(alias fun){ template isCallableCTFE_aux(alias T){ enum isCallableCTFE_aux=T; } enum isCallableCTFE=__traits(compiles,isCallableCTFE_aux!(fun())); } template isCallableCTFE2(fun...){ enum isCallableCTFE2=tru

Re: isCallableCTFE trait to test whether an expression is callable during CTFE

On Wed, Jul 10, 2013 at 7:16 PM, Timothee Cour wrote: > template isCallableCTFE(alias fun){ > template isCallableCTFE_aux(alias T){ > enum isCallableCTFE_aux=T; > } > enum isCallableCTFE=__traits(compiles,isCallableCTFE_aux!(fun())); > } > > template isCallableCTFE2(fun...){ > enum isCallableCTFE

The interaction of encapsulation and properties in D

Maybe this has already been discussed (if so sorry), but I would like to ask your opinion about the following. The condensed version: because we have properties, is it wise to use public member variables in D, in some circumstances? The long version, starting with the context: AFAIK, standard

isCallableCTFE trait to test whether an expression is callable during CTFE

template isCallableCTFE(alias fun){ template isCallableCTFE_aux(alias T){ enum isCallableCTFE_aux=T; } enum isCallableCTFE=__traits(compiles,isCallableCTFE_aux!(fun())); } template isCallableCTFE2(fun...){ enum isCallableCTFE2=true; } unittest{ int fun1(){ return 1; } auto fun1_N(){ import std.a

Re: [OT] Why mobile web apps are slow

On Wednesday, 10 July 2013 at 14:01:51 UTC, Paulo Pinto wrote: 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 ker

Re: bug with CTFE std.array.array ?

On Wed, Jul 10, 2013 at 6:11 PM, Jonathan M Davis wrote: > On Wednesday, July 10, 2013 18:06:00 Timothee Cour wrote: > > import std.array; > > > > void main(){ > > //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at > > compile time > > enum a2=" ".array;//OK > > > > import std.str

Re: Is the compiler supposed to accept this?

On Wednesday, 10 July 2013 at 21:33:00 UTC, Brian Schott wrote: On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote: // (parameters) => expression ? In any case, please consider that it actually makes no sense to restrict the expressiveness of the type signature based on how the func

Re: bug with CTFE std.array.array ?

On Wednesday, July 10, 2013 18:06:00 Timothee Cour wrote: > import std.array; > > void main(){ > //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at > compile time > enum a2=" ".array;//OK > > import std.string; > //enum a3=" ".splitLines.array;//NG > enum a4="".splitLines.array;/

bug with CTFE std.array.array ?

import std.array; void main(){ //enum a1=[1].array;//NG: Error: gc_malloc cannot be interpreted at compile time enum a2=" ".array;//OK import std.string; //enum a3=" ".splitLines.array;//NG enum a4="".splitLines.array;//OK enum a5=" ".split.array;//OK //enum a6=" a ".split.array;//N

Re: D graph library -- update

On 07/11/2013 02:18 AM, bearophile wrote: > If you want a meaningful memory comparison then perhaps you need a 10 or 100 > (or > more) times larger graph. 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 stori

Re: D graph library -- update

Joseph Rushton Wakeling: The memory usage for the example D code is slightly higher than for its comparable igraph C code, clocking in at about 2MB as opposed to 1.7. If you want a meaningful memory comparison then perhaps you need a 10 or 100 (or more) times larger graph. Bye, bearophile

Re: D graph library -- update

On 07/11/2013 01:59 AM, Joseph Rushton Wakeling wrote: > There is also a simple test file that can be used for benchmarking against > comparable igraph code. With the current method of adding edges one by one, > this code already benchmarks as faster than its igraph equivalent, running in > 2.4s o

D graph library -- update

Hi all, Following earlier discussion about a D graph library , this evening I sat down and had a go at coming up with some basic code to support such a venture. You can find it here: https://github.com/WebDrake/Dgraph This takes the b

Re: [OT] Why mobile web apps are slow

On Wednesday, 10 July 2013 at 22:22:41 UTC, H. S. Teoh wrote: On Wed, Jul 10, 2013 at 11:32:29PM +0200, John Colvin wrote: On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote: >My 2cents: for D to be successful for the game development >community, it has to be possible to mostly

Re: [OT] Why mobile web apps are slow

On Wed, Jul 10, 2013 at 11:32:29PM +0200, John Colvin wrote: > On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote: > >My 2cents: for D to be successful for the game development > >community, it has to be possible to mostly sidestep the GC or opt > >into a minimal one like ARC. Gran

Re: Is the compiler supposed to accept this?

On 07/10/2013 11:32 PM, Brian Schott wrote: On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote: // (parameters) => expression ? In any case, please consider that it actually makes no sense to restrict the expressiveness of the type signature based on how the function body is specified

Re: Is the compiler supposed to accept this?

On 07/10/2013 02:32 PM, Brian Schott wrote: > On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote: >> The documentation is in error here. > > "(parameters) => expression" is mentioned in the source and I agree it's > valid. I must have forgotton to copy-paste it. > > I don't agree that "f

Re: [OT] Why mobile web apps are slow

On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote: My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support

Re: Is the compiler supposed to accept this?

On Wednesday, 10 July 2013 at 21:16:30 UTC, Timon Gehr wrote: // (parameters) => expression ? In any case, please consider that it actually makes no sense to restrict the expressiveness of the type signature based on how the function body is specified. (Why on earth should one have to use the

Re: Is the compiler supposed to accept this?

On 07/10/2013 07:47 PM, Brian Schott wrote: There are severel comments in the part of the dmd front end that show the syntax that the parser is looking for. Here's a listing: // function type (parameters) { statements... } // delegate type (parameters) { statements... } // function (parameters)

Re: [OT] Why mobile web apps are slow

My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.

Re: Is the compiler supposed to accept this?

On 07/10/2013 08:47 PM, Brian Schott wrote: On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote: Accepts-valid is not a bug. I think you know what I meant. :-) Well, I am going to guess you meant accepts-invalid, though I'd prefer if you didn't. :o)

Re: Rust moving away from GC into reference counting

Interesting read on the subject of ARC and GC: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ It does seem that ARC would be a preferred strategy for D to pursue (even if it's a first pass before resorting to GC sweeps).

Re: Rust moving away from GC into reference counting

Opps, just saw that this link was already posted here: http://forum.dlang.org/thread/krhjq8$2r8l$1...@digitalmars.com

Re: [OT] Why mobile web apps are slow

On 7/10/2013 12:40 PM, Nick Sabalausky wrote: On Wed, 10 Jul 2013 10:47:16 -0700 Walter Bright wrote: On 7/10/2013 7:52 AM, qznc wrote: On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote: PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the

Re: Current version of D.

On 7/10/13 11:27 AM, Rob T wrote: On Wednesday, 10 July 2013 at 04:15:12 UTC, Kapps wrote: The download page has the wrong link, it doesn't seem to have been updated for 2.063.2. Can just manually add a .2 at the end, such as http://downloads.dlang.org/releases/2013/dmd.2.063.2.zip Thanks, tha

Re: [OT] Why mobile web apps are slow

On Wed, 10 Jul 2013 10:47:16 -0700 Walter Bright wrote: > On 7/10/2013 7:52 AM, qznc wrote: > > On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote: > >> PS: That silhouette of the SR-71 at the point allocators are > >> mentioned sets a high bar for the design! > > > > I did not like that

Re: Is the compiler supposed to accept this?

On Wednesday, 10 July 2013 at 18:17:07 UTC, Timon Gehr wrote: Accepts-valid is not a bug. I think you know what I meant. :-)

Re: [OT] Why mobile web apps are slow

Am 10.07.2013 20:32, schrieb Jacob Carlborg: On 2013-07-10 19:25, Sean Kelly wrote: On Jul 9, 2013, at 11:12 AM, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Oh, regarding ObjC (and I'll qualify this by saying tha

Re: [OT] Why mobile web apps are slow

On 2013-07-10 19:25, Sean Kelly wrote: On Jul 9, 2013, at 11:12 AM, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understand

Re: Current version of D.

On Wednesday, 10 July 2013 at 04:15:12 UTC, Kapps wrote: The download page has the wrong link, it doesn't seem to have been updated for 2.063.2. Can just manually add a .2 at the end, such as http://downloads.dlang.org/releases/2013/dmd.2.063.2.zip Thanks, that worked. Yup the download page

Re: Is the compiler supposed to accept this?

On 07/10/2013 07:47 PM, Brian Schott wrote: There are severel comments in the part of the dmd front end that show the syntax that the parser is looking for. Here's a listing: // function type (parameters) { statements... } // delegate type (parameters) { statements... } // function (parameters)

Re: Memory management design

On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: One can already choose their own memory model in their own code. The issue is with the core library and pre-existing code that forces you to use the GC model. It's possible to use your own memory model, but that doesn't mean it's necessa

Re: Is the compiler supposed to accept this?

There are severel comments in the part of the dmd front end that show the syntax that the parser is looking for. Here's a listing: // function type (parameters) { statements... } // delegate type (parameters) { statements... } // function (parameters) { statements... } // delegate (parameters) {

Re: [OT] Why mobile web apps are slow

On 7/10/2013 7:52 AM, qznc wrote: On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote: PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design! I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.l

Re: [OT] Why mobile web apps are slow

Sean Kelly: However, reference counting *is* garbage collection, Of course, it's explained well here: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf Bye, bearophile

Re: [OT] Why mobile web apps are slow

On Jul 9, 2013, at 11:12 AM, Paulo Pinto wrote: > A bit off-topic, but well worth reading, > > http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally refer

Re: Memory management design

Am Wed, 10 Jul 2013 18:12:42 +0200 schrieb Paulo Pinto : > Who is going to write two versions of the library then? > > Throwing exceptions with @nogc pointers floating around would just > lead to the same headache as in C++. This will really be an issue if/once we support systems which just can'

Re: [OT] Why mobile web apps are slow

Thanks for the link. In my experience, mobile networking is slow in general. When I run Speedtest on my phone vs. a laptop sitting right next to it, the phone has a fraction of the bandwidth of the laptop. So there's even more at issue than raw JS performance. Sean is right, this is only

Re: Unhelpful error messages

On Wed, Jul 10, 2013 at 03:05:25PM +0200, Don wrote: > On Monday, 8 July 2013 at 20:46:35 UTC, H. S. Teoh wrote: > >On Mon, Jul 08, 2013 at 09:47:46PM +0200, Peter Alexander wrote: [...] > >>Maybe the compiler could just spew out every possible error for > >>every instantiation, and expect the user

Re: Memory management design

Am 10.07.2013 15:57, schrieb John Colvin: On Wednesday, 10 July 2013 at 13:00:53 UTC, Kagamin wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: most functions may actually be @nogc Most functions can't be @nogc because they throw exceptions. I think I mentioned before, elsewher

Re: Memory management design

sclytrack: Why not just go manual memory. Just store everything in a tree-like structure. SuperOwner --Child1 --Child2 SubChild1 SubChild2 --Container1 --Container2 --TStringList Freeing a Child2 disposes of everything below. Something like this? http://swapped.cc/?_escap

Re: Memory management design

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote: Given all of this talk about memory management, it would seem that it's time for people to start putting forward some ideas for improved memory management designs. I've got an idea or two of my own, but I'd like to discuss my ideas before I

Re: A thread-safe weak reference implementation

On 3/14/12, Alex Rønne Petersen wrote: > auto ptr = cast(size_t)cast(void*)object; I think this should be: auto ptr = cast(size_t)*cast(void**)&object; The object might have an opCast method, and this is one way to avoid calling it by accident.

Re: [OT] Why mobile web apps are slow

On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote: PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design! I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.likecool.com/Gear/Pic/Spy%20Plane%2

Re: Memory management design

On Wednesday, 10 July 2013 at 13:57:50 UTC, John Colvin wrote: How much of the exception model would have to change in order to free them from the GC? I don't see high performance as a concern for exceptions so even an inefficient situation would be fine. Well, you can just throw malloc'ed ex

Re: [OT] Why mobile web apps are slow

Paulo Pinto: They used to have special hardware, but now they use standard kernels. This is very good. (Maybe in the meantime someone has folded their needs inside the standard kernel). Bye, bearophile

Re: [OT] Why mobile web apps are slow

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

Re: Memory management design

On Wednesday, 10 July 2013 at 13:00:53 UTC, Kagamin wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: most functions may actually be @nogc Most functions can't be @nogc because they throw exceptions. I think I mentioned before, elsewhere, that @nogc could allow exceptions. No o

Re: Memory management design

Kagamin: Most functions can't be @nogc because they throw exceptions. Probably about half of my functions/metods are tagged with "nothrow". And as ".dup" becomes nothrow and few more functions become nothrow (iota, etc), that percentage will increase. I have also proposed to add to Phobos s

Re: [OT] Why mobile web apps are slow

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. Bye, bearophile

Re: [OT] Why mobile web apps are slow

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. They're viable if you have a lot of RAM to spare. They cause noticeabl

Re: Unhelpful error messages

On Monday, 8 July 2013 at 20:46:35 UTC, H. S. Teoh wrote: On Mon, Jul 08, 2013 at 09:47:46PM +0200, Peter Alexander wrote: On Monday, 8 July 2013 at 18:10:45 UTC, H. S. Teoh wrote: >On Sun, Jul 07, 2013 at 02:06:46PM +0200, Peter Alexander >wrote: >>It's a tough situation and I think the only w

Re: [OT] Why mobile web apps are slow

On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ The chart of different kinds of GC is very worth looking there. It shows how much generational GCs are faster than simple scan-wh

Re: Memory management design

On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: most functions may actually be @nogc Most functions can't be @nogc because they throw exceptions.

Re: A thread-safe weak reference implementation

Am 09.07.2013 23:35, schrieb Robert: > >> if (GC.addrOf(cast(void*)obj)) >> return obj; > > > Smart :-) You are waiting for the collection to complete, if we are one > of the threads started before destructor calls happen. Brilliant. > > Is it ok if I shamelessly copy parts

Re: access CTFE variables at compile time.

Don: Although that's a problem, it's not at all what's happened here. Right. I presume that several of the patches that are waiting for some time have some significant problems. Bye, bearophile

Re: Memory management design

On Wednesday, 10 July 2013 at 11:38:35 UTC, JS wrote: On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote: On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: On

Re: Memory management design

On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote: On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: On 10 July 2013 17:53, Dicebot wrote: On Wednesday, 10

Re: Memory management design

On Wednesday, 10 July 2013 at 10:49:04 UTC, Dicebot wrote: On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote: ... @nogc itself does not help here as this code will still be affected by stop-the-world. Those issues are related, but not directly. It will help to avoid memory leaks when yo

Re: Memory management design

On 2013-07-10 08:00:42 +, Manu said: I'd push for an ARC implementation. I've become convinced that's what I actually want, and that GC will never completely satisfy my requirements. There's two ways to implement ARC. You can implement it instead of the GC, but things with cycles in them

Re: access CTFE variables at compile time.

On Wednesday, 10 July 2013 at 01:23:20 UTC, bearophile wrote: Meta: I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it. That's not true. This is the ER: http://d.puremagic.com/issues/show_bug.cgi?id=39

Re: Memory management design

On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote: On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: On 10 July 2013 17:53, Dicebot wrote: On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: ... I am pretty sure s

Re: Memory management design

On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote: ... @nogc itself does not help here as this code will still be affected by stop-the-world. Those issues are related, but not directly. It will help to avoid memory leaks when you switch the GC off though.

Re: Memory management design

On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote: On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: On 10 July 2013 17:53, Dicebot wrote: On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: ... I am pretty sure stuff like @nogc (or probably @noheap. or both) will ha

Re: Memory management design

On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: On 10 July 2013 17:53, Dicebot wrote: On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: ... I am pretty sure stuff like @nogc (or probably @noheap. or both) will have no problems in being accepted into the mainstream once prope

Re: Memory management design

On Wednesday, 10 July 2013 at 08:16:55 UTC, Mr. Anonymous wrote: I thought about allowing attributes to be applied to a whole module, such as: @safe @nogc module foo_bar; Then, "@system", "@allowheap" and friends could be used where needed. You can do it, but it is not always possible to "di

Re: Memory management design

On Wednesday, 10 July 2013 at 08:09:46 UTC, Dicebot wrote: Yes, this is a common issue not unique to @nogc. I am personally much in favor of having restrictive attributes enabled by default and then adding "mutable" "@system" and "@allowheap" where those are actually needed. But unfortunately

Re: Memory management design

On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote: I'd push for an ARC implementation. I've become convinced that's what I actually want, and that GC will never completely satisfy my requirements. I think those issues are actually orthogonal. I'd love to have verified @noheap attribute e

Re: Memory management design

On 10 July 2013 17:53, Dicebot wrote: > On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: > >> ... >> > > I am pretty sure stuff like @nogc (or probably @noheap. or both) will have > no problems in being accepted into the mainstream once properly > implemented. It is mostly a matter of volunt

Re: Memory management design

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote: 1. "scope": refers to stack-allocated memory (which seems to be the original design behind "scope"). "scope" references may not be stashed anywhere where they might become invalid. Since this is the "safest" type of reference, any object ma

Re: Memory management design

On Tuesday, 9 July 2013 at 23:32:13 UTC, BLM768 wrote: Given all of this talk about memory management, it would seem that it's time for people to start putting forward some ideas for improved memory management designs. I've got an idea or two of my own, but I'd like to discuss my ideas before I

Re: Memory management design

On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote: ... I am pretty sure stuff like @nogc (or probably @noheap. or both) will have no problems in being accepted into the mainstream once properly implemented. It is mostly a matter of volunteer wanting to get dirty with the compiler.

Re: [OT] Why mobile web apps are slow

On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote: Walter Bright: It isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC. There's a long way from recognizing those problems, to having good enough solutions in D. Some possible attack strategies

Re: [OT] Why mobile web apps are slow

On Tuesday, 9 July 2013 at 19:44:26 UTC, Joakim wrote: On Tuesday, 9 July 2013 at 19:27:22 UTC, QAston wrote: On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo I think t