Re: A Refcounted Array Type
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven
Schveighoffer wrote:
In that case, you shouldn't be subject to any kind of race
conditions.
But we can't make the library/language based on this
assumption. Your
case is the exceptional case.
His case is not @safe, so we can ignore that problem.
the compiler tends to disagree:
=== test.d ===
int myglobal;
class A {
~this () @safe { if (myglobal == 42) assert(0); }
}
void main () {
auto a = new A;
}
==
dmd -w -c -o- test.d
wow! no warnings, no errors!
Slighty off-topic,
If DIP74 is approved it would be nice if destructors were
redesigned(and possibly dropped altogether for non-deterministic
lifetimes.)
[Issue 14230] New: [REG2.067b2] std.array.join misses the first element which is empty string
https://issues.dlang.org/show_bug.cgi?id=14230
Issue ID: 14230
Summary: [REG2.067b2] std.array.join misses the first element
which is empty string
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
I sometimes use join() in this way.
join( [] ~ [aa,bb,cc], @ )
-- @aa @bb @cc
This doesn't work properly in D2.
This is a regression, probably.
--
import std.stdio;
import std.array;
void main()
{
string[] ary = [,aa,bb,cc]; // leaded by _empty_ element
writeln(ary.join( @));
// In 2.067b2, this outputs aa @bb @cc or asserts inside of join()
assert(ary.join( @) == @aa @bb @cc); // OK in 2.067b1 and olders
}
--
--
[Issue 14229] RAII ordering is wrong
https://issues.dlang.org/show_bug.cgi?id=14229 Etienne etci...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Etienne etci...@gmail.com --- I realized this is not an issue, because the destructors are called before the destruction. So, this doesn't map the actual free'ing of the structs. --
Re: DIP74: Reference Counted Class Objects
On Fri, 27 Feb 2015 20:13:31 +, weaselcat wrote: Are op* considered reserved member names? no. that's just the we can break your code, and you can't break ours! it's funny how the argument we will not break user's code pops up even for breaking invalid code, but completely ignored for perfectly valid code not forbidden by the specs. signature.asc Description: PGP signature
[Issue 13729] [REG2.067a] One not detected case of not purity
https://issues.dlang.org/show_bug.cgi?id=13729 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13729] [REG2.067a] One not detected case of not purity
https://issues.dlang.org/show_bug.cgi?id=13729 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3a9a56bce0d595fbe538946321e2fb8692711386 fix Issue 13729 - One not detected case of not purity https://github.com/D-Programming-Language/dmd/commit/8b3bd7381a82dac630f5a8374618caf5a3b8ae98 Merge pull request #4447 from 9rnsr/fix13729 [REG2.067a] Issue 13729 - One not detected case of not purity --
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2015-02-27 23:11:55 +, deadalnix said: On Friday, 27 February 2015 at 23:06:26 UTC, Andrei Alexandrescu wrote: OK, so at least in theory autorelease pools are not necessary for getting ARC to work? -- Andrei ARC need them, this is part of the spec. You can have good RC without them IMO. Apple's ARC needs autorelease pools to interact with Objective-C code. But if by ARC you just mean what the acronym stands for -- automatic reference counting -- there's no need for autorelease pools to implement ARC. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: A Refcounted Array Type
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer wrote:
In that case, you shouldn't be subject to any kind of race conditions.
But we can't make the library/language based on this assumption. Your
case is the exceptional case.
His case is not @safe, so we can ignore that problem.
the compiler tends to disagree:
=== test.d ===
int myglobal;
class A {
~this () @safe { if (myglobal == 42) assert(0); }
}
void main () {
auto a = new A;
}
==
dmd -w -c -o- test.d
wow! no warnings, no errors!
signature.asc
Description: PGP signature
Re: GC deadlocks on linux
On Sat, 28 Feb 2015 06:09:16 +0100, Martin Nowak wrote: Meanwhile the author of daemonized came up with another idea, using exec instead of fork. https://github.com/NCrashed/daemonize/issues/2 ahem. http://forum.dlang.org/post/mc35ap$2dvo$5...@digitalmars.com signature.asc Description: PGP signature
Re: Last week for DConf 2015 submissions
On 2/27/2015 5:30 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: You should have one from me now. Sorry it took this long to get it to you. Yes, got it. Thanks!
Re: GC deadlocks on linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 09:27 PM, Byron Heads wrote: I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Have you been able to resolve the issue? There were a number of suggestions in the thread, but we never heard back from you. Meanwhile the author of daemonized came up with another idea, using exec instead of fork. https://github.com/NCrashed/daemonize/issues/2 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8U14AAoJELJzgRYSuxk5wnEP/R6nFZECdFsNSFK/Bmsys5WI RmYt8FyS5WJt/2tM/jKgN6k5WJLP+ZniSHPTMdWO4pGxJTaK6zGvMXVYEHPFgIDp RPcJhZ/J1KXyfOyR3by/23opvGaWqAJXIx3yBfYBhvjNNpjQrGxqQEwdT4sbDvz1 AtUZ+Tc1CoBo+3hRNESyk9FNa3c58adu5SWkpErJezrg4TFzYg7sKytbZEtb5T6U OWLVlMqY8Q6AyskbEUqxfQt8lba9fM5Eeg8gbzf7ShCZwrzviBkrhdTWrodv8kHo HeMZmRIBKmz/L0Ce/7NSV+U0htEB+DAB2LSYRKhy/qYwoLHi8UNruqv3pf4PU7Ly 4atq5XTcFNS/ywL8qkP8OMmcdBN0pBQNsDfmG2w1DsWANtK/cLqwS50O8TXCxpv1 hlQ/CgRD6jJWujleaDOhuOZWYzJ0Xwk1a5BGjoO5MkQaHeRZgalSN4rkmoPZQz1t H2kA03JMTVkEx2AllPKHdQCcNEV0wpI7sJNRWh9kewtdzW0SQtlV2NYM9U2gXPJe u+zYuWRLGpWOrqItzZGt+Z+NSrNziV0cO/IpogQRjMPtLXsRgaFofzaOO81l7OWk SWnE3bT2PO2sdZ0Z3uf/c+KAosDJ+5AhD9FXmuEemIc4S4/1yKJSVj7BtsomBxE+ hGfLvRuNjUDQil+WjC0t =MNgH -END PGP SIGNATURE-
Re: My Reference Safety System (DIP???)
On Friday, 27 February 2015 at 23:18:24 UTC, Marc Schütz wrote: I think I have an inference algorithm that works. It can infer the required scope levels for local variables given the constraints of function parameters, and it can even infer the annotations for the parameters (in template functions). It can also cope with local variables that are explicitly declared as `scope`, though these are mostly unnecessary. Interestingly, the rvalue/lvalue problem deadalnix found is only relevant during assignment checking, but not during inference. That's because we are free to widen the scope of variables that are to be inferred as needed. It's based on two principles: * We start with the minimum possible scope a variable may have, which is empty for local variables, and its own lifetime for parameters. * When a scoped value is stored somewhere, it is then reachable through the destination. Therefore, assuming the source's scope is fixed, the destination's scope must be widened to accommodate the source's scope. * From the opposite viewpoint, a value that is to be stored somewhere must have at least the destination's scope. Therefore, assuming the destination's scope is fixed, the source's scope needs to be widened accordingly. I haven't formalized it yet, but I posted a very detailed step-by-step demonstration on my wiki talk page (nicer to read because it has syntax highlighting): http://wiki.dlang.org/User_talk:Schuetzm/scope2 I need to sleep as well right now. But I still don't understand where the cycles come from. Taken from your example: *b = c; // assignment from `c`: // = SCOPE(c) |= SCOPE(*b) // = DEFER because SCOPE(*b) = SCOPE(b) is incomplete `c` is merely being copied, but you indicate here that it will now inherit b's (or some part of b's) scope. Why would c's scope inherit b's when it is merely being copied and not written to?
Re: Does static ctor/dtor of struct behave differently in 2.067-b2?
On Fri, 27 Feb 2015 23:58:16 +, amber wrote:
On Friday, 27 February 2015 at 23:50:51 UTC, amber wrote:
Hi All,
[snip]
Thanks, amber
[edited subject]
Sorry I should add that I'm talking about static ctor/dtor of struct.
The bug I see with 2.067-b2 is this:
1. static this() {} called and static fields of struct are initialised
2. app runs, static fields are initialised.
3. static ~this() {} called and static fields of struct are NOT
initialised.
In step 3 with 2.066.1 all the static fields of struct are still
initialised, as expected, and my app shuts down cleanly.
is your struct GC-allocated? and can you provide dustmited code or
something we can play with?
signature.asc
Description: PGP signature
Re: DIP74: Reference Counted Class Objects
On Saturday, 28 February 2015 at 03:49:04 UTC, ketmar wrote: On Fri, 27 Feb 2015 20:13:31 +, weaselcat wrote: Are op* considered reserved member names? no. that's just the we can break your code, and you can't break ours! it's funny how the argument we will not break user's code pops up even for breaking invalid code, but completely ignored for perfectly valid code not forbidden by the specs. I think this is justified to break the code here, but I share the irritation in front of the inconsistency.
DMD Zip for Mac OS X
I'm not a Mac user and I'm fairly clueless about it. The DMD zip for OS X contains one executable. I assume it's a 64-bit binary. Is that true?
Re: Last week for DConf 2015 submissions
On 23/02/15 01:03, Andrei Alexandrescu via Digitalmars-d wrote: At this point we don't have enough submissions to make DConf 2015 viable. Those we have are of good quality, but simply put more are needed. We're counting on our core community (i.e. frequent contributors to this forum) to both participate and spread the news about the conference. The call for submissions closes at the end of day of February 27 (this coming Friday). You should have one from me now. Sorry it took this long to get it to you.
Re: DIP74: Reference Counted Class Objects
On 2/27/15 12:53 AM, Kagamin wrote: On Thursday, 26 February 2015 at 22:02:51 UTC, Andrei Alexandrescu wrote: So is the end game of dip25 and dip74 to not have to wrap types you intend to manage with RC like C++ but just design the classes/structs themselves around being RCed from the start? That is correct. Well as shown there are ways to design classes that work both with RC and GC. -- Andrei If a class is meant to be refcounted at compile time, what's a difference from alias MyClass = RefCounted!MyClassImpl; // use MyClass instead except for it introduces an additional check for null and a branch? The typechecking on RCOs is stricter, which makes them safe. -- Andrei
Re: Contradictory justification for status quo
On 2/27/15 1:09 AM, John Colvin wrote: On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote: I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed. Everyone's a Marxist when it comes to their own labour :) Nice! -- Andrei
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 13:36:33 UTC, Marc Schütz wrote: AddRef/Release is established COM terminology. Which is from 1993, a period of time where MS was completely ignorant of everything outside MS. Common resource-access terminology is: acquire/release retain/release inc_ref/dec_ref add_ref/remove_ref down/up wait/signal P/V open/close enter/exit begin/end … Notice the symmetry?
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: One of the first things that stood out to me is that add ref is two words and release is one. For the sake of symmetry, how about these: * opIncRef, opDecRef * opAcquire, opRelease All - please PLEASE do not derail this into yet another debate about which names are best. -- Andrei Using protocols rather than enforcing a particular implementation is nice, but D needs to stop reinventing terminology and syntax matters. -- snip -- AddRef/Release is established COM terminology.
Re: DIP74: Reference Counted Class Objects
On 2/27/15 1:09 AM, ted wrote: Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei Trivial typos: struct, class, and closure types that have RCO members accommodate calls to Release during their destruction. s/Release/opRelease/ Explicit casting to of from void* does not entail a call to opAddRef. s/of/or/ also: s/opReleasecalls/opRelease calls/ The examples in Defining a reference counted object with deallocation, and defining a type that owns resources both define '_refs', and manipulate 'refs'. Fixed, thanks! This is probably a really stupid question, but how does the 'new' work for an RCO. I assume it uses the GC memory allocation system, but must mark it as 'not for collection' (or similar), for the GC.free() call to work (as used in the examples). DIP74 does not prescribe specific allocation techniques. They are left to the user. One nice point of the design space would be to use the GC for allocation and early deallocation, in such a way that the GC is still able to collect cycles. Probably another silly question: How would the examples work with const/immutable (using examples in howtos)? e.g. const Widget a = new Widget; auto b = a; -- mutable method Widget.opAddRef is not callable using a const object This is tricky. I meant to discuss it; for now I planted a TODO. Andrei
Re: @trusted and return ref
On 2/27/15 3:29 AM, Kagamin wrote: On Thursday, 26 February 2015 at 16:25:59 UTC, Steven Schveighoffer wrote: However, we have an issue here. At any point inside the code, you could do: oldcount = count; And now, there is still potentially a dangling pointer somewhere. This means every place count is used must be checked. In this case, all uses of count have to be re-checked when the file is edited. Because count leaks the memory details of the trusted call to free (In other words, the fact that count, or any copy of it, can become a dangling pointer), I believe every call in that type that deals with count should be marked trusted. The counter is freed in the destructor, nothing can happen after that. So the code is now etched in stone and cannot be changed? Is there an attribute for that? :P -Steve
Re: @trusted and return ref
On Friday, 27 February 2015 at 10:49:25 UTC, Ola Fosheim Grøstad wrote: 2. You construct a transform T(x) that can transform language D into x. = D is proven safe. Eh: 2. You construct a transform T(x) that can transform programs in language D into P...
Re: DIP74: Reference Counted Class Objects
On Fri, Feb 27, 2015 at 08:00:20AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/27/15 7:42 AM, H. S. Teoh via Digitalmars-d wrote: S.foo() should have been annotated with 'return', but the programmer forgot and the compiler still accepts the code without any warnings, thereby violating @safe. That is correct. However, the user is on the hook because her use of @trusted when deallocating the array. [...] Which shows just how dangerous @trusted is. :-P But that's a good point. The use of @trusted in theory should have raised red flags that the programmer needs to be careful here. There's also the case of using malloc/free to allocate the array, but I suppose that falls in the same category. T -- A bend in the road is not the end of the road unless you fail to make the turn. -- Brian White
[Issue 6586] feqrel for const values too
https://issues.dlang.org/show_bug.cgi?id=6586 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Contradictory justification for status quo
Andrei Alexandrescu: Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. I have suggested to switch to @safe by default: https://issues.dlang.org/show_bug.cgi?id=13838 Bye, bearophile
Re: std.allocator ready for some abuse
On Friday, 27 February 2015 at 08:18:53 UTC, ANtlord wrote: I think, that if use this project https://github.com/andralex/std_allocator/, than you can post the issue to related issue tracker. Oh, I must be blind. I thought the issue tracker was disables on the repository in the same way as for Phobos. Thanks for checking. I submitted the issue. And I see, that types in traceback are different from source https://github.com/andralex/std_allocator/blob/master/source/std/allocator.d#L857. Maybe you need to upgrade package. If you mean size_t and uint difference it's because size_t is an alias for uint on 32-bit os. roundUpToMultipleOf(size_t s, uint base) becomes roundUpToMultipleOf (uint s, uint base) Piotrek
[Issue 6586] feqrel for const values too
https://issues.dlang.org/show_bug.cgi?id=6586 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/09ebc581ec022d0e1091d47887aab26366df79e0 rework and try to fix Issue 6586 https://github.com/D-Programming-Language/phobos/commit/62acd72cec052169e7eb56d1c63c860ae92f9ef9 Merge pull request #3017 from 9il/frexp [2.067.0-b2][regression] fix Issues 14212 and 6586 --
Re: [OT] HTML: div/iframe hybrid?
On 02/26/2015 02:59 PM, Nick Sabalausky wrote: On 02/26/2015 03:30 AM, Kagamin wrote: AFAIK, div src=... syntax was proposed for this purpose (with fallback) in early editions of html5, don't know if it made it into the standard. Hmm, just looked that up, but all I found on that was one page that implies (sadly, with no sources referenced) it did not make it in: http://hannah.wf/why-dont-all-html-elements-have-a-src-attribute/ However, looks like what happened instead was iframe grew a seamless attribute, which frankly looks pretty damn sweet: http://benvinegar.github.io/seamless-talk/#/12 Still researching browser compatibility and adoption though. TL;DR: New in HTML5: iframe seamless src=url / is the answer (assuming it isn't still *too* new, not sure yet) Well, it appears seamless iframes are basically useless despite (from what I can tell) apparently being in the spec for a few years now. Doesn't work at all in even the latest FF. Didn't bother testing the others, but according to this, even today seamless iframes are still supported in exactly *nothing*: http://caniuse.com/#feat=iframe-seamless Setting the display:block on the iframe's css doesn't help, it just affects placement, not how it gets sized. There are a few basic CSS settings that help a *little* bit though: border-width: 0px; background-color: transparent; padding: 0px; overflow: hidden; Too bad :( Is it just me or does the moniker HTML5 seem pretty useless since there doesn't appear to have ever been any *actual* HTML5 spec, just an ever-changing target with piecemeal browser adoption?
Re: DIP74: Reference Counted Class Objects
On 2/27/15 9:24 AM, Nick Treleaven wrote: On 26/02/2015 22:04, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: The DIP states that Any attributes are allowed on these methods., but later states The complexity of this code underlies the importance of making opAddRef and especially opRelease nothrow. Should the DIP require that these two functions be marked nothrow? It's a liberty still left to user code. -- Andrei ISTM nothrow would be a sensible starting point. That would simplify compiler implementation and avoid invisible inefficiency in user code. Shouldn't we wait for a compelling use case for throwing in these functions before supporting it? I don't know of a compelling use case. Note that quite a few of the implementations complications remain; the surrounding code may still throw. -- Andrei
[Issue 14212] frexp for const and immutable fails to compile
https://issues.dlang.org/show_bug.cgi?id=14212 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14212] frexp for const and immutable fails to compile
https://issues.dlang.org/show_bug.cgi?id=14212 --- Comment #6 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/62acd72cec052169e7eb56d1c63c860ae92f9ef9 Merge pull request #3017 from 9il/frexp [2.067.0-b2][regression] fix Issues 14212 and 6586 --
Re: DIP74: Reference Counted Class Objects
On 26/02/2015 22:04, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: The DIP states that Any attributes are allowed on these methods., but later states The complexity of this code underlies the importance of making opAddRef and especially opRelease nothrow. Should the DIP require that these two functions be marked nothrow? It's a liberty still left to user code. -- Andrei ISTM nothrow would be a sensible starting point. That would simplify compiler implementation and avoid invisible inefficiency in user code. Shouldn't we wait for a compelling use case for throwing in these functions before supporting it?
Re: Contradictory justification for status quo
On 2/26/15 8:21 PM, Zach the Mystic wrote: Can I ask you a general question about safety: If you became convinced that really great safety would *require* more function attributes, what would be the threshold for including them? I'm trying to go the whole hog with safety, but I'm paying what seems to me the necessary price -- more parameter attributes. Some of these gains (out! parameters, e.g.) seem like they would only apply to very rare code, and yet they *must* be there, in order for functions to talk to each other accurately. Are you interested in accommodating the rare use cases for the sake of robust safety, or do you just want to stop at the very common use cases (ref returns, e.g.)? ref returns will probably cover more than half of all use cases for memory safety. Each smaller category will require additions to what a function signature can contain (starting with expanding `return` to all reference types, e.g.), while covering a smaller number of actual use cases... but on the other hand, it's precisely because they cover fewer use cases that they will appear so much less often. Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. A feature that is safe except for certain constructs is undesirable. Generally having a large number of corner cases that require special language constructs to address is a Bad Sign. Andrei
Re: Berlin D Meetup Feb 2015
I thought I would give a brief summary of the last meetup. Joseph Wakeling gave a presentation entitled “Random number generation in Phobos and beyond”. It was a great talk and we had some interesting discussions afterwards. The talk began by mentioning some naive ways of generating random numbers and some of the negative consequences this can cause. Joseph then mentioned other methods of generating random numbers including big tables of random numbers, physical randomness, and deterministic methods (pseudo-random). Pseudo-random number generators (RNGs) use a state variable and a transition function that maps from the current state to the next state and this sounds like a good match for a forward range. Currently in Phobos all RNGs are implemented as ForwardRange structs. Other ranges such as randomCover and randomSample wrap the Phobos RNGs. Wrapping the RNGs can cause problems as structs are passed by value. This means that if the same RNG is used in subsequent calls to say randomCover then the same sequence of random numbers will be produced by each range. A simple solution to this would be make random ranges classes. This can also cause problems but with memory management (we want to avoid lots of small alloc and free events). It also does not address problems with functions that make bad assumptions about their arguments. If we can solve these problems then there are several different avenues to push forward with new RNG wrapper functionality. There are also other opportunities for looking at random number generation. After the talk there was some discussion on a number of points including: Testing RNGs. The unittests in std.random don't (and can't) provide tests of randomness. There are existing RNG tests in linux. It would be good to get a good randomness test suite in D. Does the c++ standard library have the same problems? Possibly, there was some certainty that the boost documentation has some reference to the same problems. Is this a general problem with forward ranges? Could there be something missing from the range interface or perhaps it would be better to have a distinct range type for random numbers. There was then a discussion of the various types of hardware RNGs. Martin Novak mentioned “haveged” a C program that can generate large numbers of random numbers. It generates randomness based on variations in code execution time on a processor. Thanks, Ben.
Re: 3 dimension arrays
On Thursday, 26 February 2015 at 23:25:22 UTC, Ali Çehreli wrote:
On 02/26/2015 12:01 PM, Andrey wrote: HI guys!!!
Have a problem with 3d array memory allocation in next code:
//
class NeuronNet(T, const uint layersNum)
{
T[]_inputs;
T[][layersNum - 2]_hidden;
T[]_outputs;
T[]_target;
//waights [col][row][dimension]
T[][][layersNum - 1] _waightsArray;
(Unrelated: That may be a typo if its actually weights.)
this(in uint[] nodesArr)
{
//values init
_inputs = new T[nodesArr[0]];
_outputs = new T[nodesArr[$-1]];
for(uint j = 0; j layersNum - 2; j++)
Better:
foreach (j; 0 .. layersNum - 2)
{
_hidden[][j] = new T[nodesArr[j + 1]];
You have extra [] up there. This is equivalent:
_hidden[j] = new T[nodesArr[j + 1]];
The reason is, _hidden[] means the entire _hidden slice
anyway. So, the empty [] has no meaning at all.
}
//waights init
for(uint i = 0; i layersNum - 1; i++)
{
_waightsArray[][][i] = new T[][nodesArr[1+i]];
Same there:
_waightsArray[i] = new T[][nodesArr[1+i]];
for(uint ii = 0; ii nodesArr[1+i]; ii++)
{
_waightsArray[][ii][i] = new T[nodesArr[i]];
You want to set ii'th element of the i'th element, right? This
is the right way to do it in D:
_waightsArray[i][ii] = ...
Unlike C and C++, the array syntax is natural in D. In other
words, it is not inside out.
T[] -- A slice of Ts
T[][] -- A slice of T slices
T[][][layersNum - 1] -- A number of those
So, _waightsArray[i] is one of the slices that you've just set
in the previous for loop.
Ali
I very much appreciate. The author of D-book respond to me.
THANKS VERY MUCH!
Re: Berlin D Meetup Feb 2015
On Thursday, 12 February 2015 at 01:58:04 UTC, Walter Bright wrote: I see you're doing the presentation! I note that you haven't submitted a presentation proposal for Dconf 2015 yet. Please submit this one! Why not get the most mileage out of it? Submitted :-)
[Issue 14220] Bad codegen for optimized std.conv.text in combination with concatenation
https://issues.dlang.org/show_bug.cgi?id=14220
--- Comment #3 from Kenji Hara k.hara...@gmail.com ---
Reduced test case:
extern(C) int printf(const char*, ...);
void main()
{
auto a = toString(14);
printf(a.ptr = %p, a.length = %d\n, a.ptr, cast(int)a.length);
return;
}
auto toString(int value)
{
uint mValue = value;
char[int.sizeof * 3] buffer = void;
size_t index = buffer.length;
do
{
uint div = cast(int)(mValue / 10);
char mod = mValue % 10 + '0';
buffer[--index] = mod;// Line 22
mValue = div;
} while (mValue);
//printf(buffer.ptr = %p, index = %d\n, buffer.ptr, cast(int)index);
return dup(buffer[index .. $]);
}
char[] dup(char[] a)
{
//printf(a.ptr = %p, a.length = %d\n, a.ptr, cast(int)a.length);
a[0] = 1; // segfault
return a;
}
The wrong-code bug is introduced by the change:
https://github.com/D-Programming-Language/dmd/pull/4415
However, the PR 4415 only affects to line 22. so I think the root issue would
exist in dmd backend optimizer.
--
Re: Last week for DConf 2015 submissions
On 23/02/15 12:30, Iain Buclaw via Digitalmars-d wrote: On 23 February 2015 at 01:30, Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: I could prolly do two talks... especially if someone else wants to suggest a topic. Heck, I could improvise in a round table or something too. I'd happily be on a panel talk. :) It would be really nice if there could be an organized panel talk of the maintainers and major contributors of the various D compilers out there (including DDMD and SDC).
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 07:44:18 UTC, anonymous wrote: On Friday, 27 February 2015 at 00:10:00 UTC, deadalnix wrote: On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei The compiler detects automatically and treats specially all classes and interfaces that define the following two methods: Well, RefCounted could use compile time reflexion to do so. Even better, we could define a lvalue property for RefCounted to use a counter so we can do intrusive counting in both classes and structs. @safe code may not issue explicit calls to opAddRef/opRelease. I guess we could simply make them @system . RCOs objects are subject to additional limitations compared to their GC counterparts: No conversion to Object or interfaces that are not reference counted No problem, I'm gonna duplicate all my code and as will every single library writer out there. Missing: All write of RCO reference to statics must be atomic and ordered as long as the language can't enforce thread locality (at least in @safe code). Generally: This DIP works around (announced) limitations of DIP25. As escape can only be checked properly for type with no indirections, and only solve the problem for classes/interfaces. Other type with indirection remains an unsolved problem. If I were in charge, that would be a clear no, and the sign that DIP25 approach needs to be reworked, as wack-a-mole is not a good way to handle design. We all pray you become less of a gaping asshole before youre in charge of anything. In fact, we all don't. Quite the opposite, several of the participants of these forums (me included) happen to agree with him on many things, not just this particular topic. That's because he brings forward good arguments for his opinions, which is evidently something you aren't capable of.
[Issue 13729] [REG2.067a] One not detected case of not purity
https://issues.dlang.org/show_bug.cgi?id=13729 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4447 --
Re: On opCmp
On Friday, 27 February 2015 at 11:04:51 UTC, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in
the following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum
strength)
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
if (this.rank rhs.rank)
{
return -1;
}
else if (this.rank rhs.rank)
{
return +1;
}
else
{
return 0;
}
}
}
}
by reusing something like
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
return this.rank.standardOpCmp(rhs.rank)
}
}
Two things come to mind:
A) std.algorithm.cmp
auto opCmp(const Hit rhs) const
{
import std.algorithm: cmp;
import std.range: only;
if(auto c = cmp(only(count), only(rhs.count)))
{
return c;
}
else /* 'count' values are equal. */
{
return cmp(only(rank), only(rhs.rank));
}
}
Maybe there should be a std.algorithm.cmp for non-ranges, too, so
that `only` wouldn't be needed here.
B) std.typecons.Tuple has an opCmp that compares all fields in
order.
auto opCmp(const Hit rhs) const
{
import std.typecons: tuple;
return tuple(count, rank).opCmp(tuple(rhs.count, rhs.rank));
}
This exact behaviour is not documented, though. So I guess it
should not be relied on. Maybe the documentation should be more
specific. In the meantime, you could duplicate the functionality
in a function of your own:
import std.typecons: Tuple;
/** Put a proper, specific description here.
*/
int cmpTuples(Types ...)(Tuple!Types a, Tuple!Types b)
{
// copied from std.typecons.Tuple.opCmp
foreach (i, Unused; Types)
{
if (a[i] != b[i])
{
return a[i] b[i] ? -1 : 1;
}
}
return 0;
}
struct Hit
{
size_t count;
NWeight rank;
auto opCmp(const Hit rhs) const
{
import std.typecons: tuple;
return cmpTuples(tuple(count, rank), tuple(rhs.count,
rhs.rank));
}
}
Re: DIP74: Reference Counted Class Objects
On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei It's kind of funny that you were looking for an edge to my safety system -- I'll admit I don't know whether it really has an edge or not (it might be too bloated, both function-signature-wise and compile-time-wise) -- but one key advantage to any sophisticated ownership system is that automated reference counting can elide calls which it knows are unnecessary. What struck me in particular about DIP74 is how the pass-by-value protocol will force many function calls to endure an opAddRef/opRelease cycle, even if they do nothing to the reference count. What really worries me is that if the caller is responsible for the opAddRef, while the callee is responsible for the opRelease, isn't the potential optimization of eliding them just being sacrificed?
Re: DIP74: Reference Counted Class Objects
On 2/27/15 9:09 AM, Andrei Alexandrescu wrote: On 2/27/15 1:09 AM, ted wrote: Probably another silly question: How would the examples work with const/immutable (using examples in howtos)? e.g. const Widget a = new Widget; auto b = a;-- mutable method Widget.opAddRef is not callable using a const object This is tricky. I meant to discuss it; for now I planted a TODO. Wouldn't you bless this mechanism of logical const the same way synchronized does? -Steve
Re: DIP74: Reference Counted Class Objects
On 2/27/15 6:36 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: One of the first things that stood out to me is that add ref is two words and release is one. For the sake of symmetry, how about these: * opIncRef, opDecRef * opAcquire, opRelease All - please PLEASE do not derail this into yet another debate about which names are best. -- Andrei Using protocols rather than enforcing a particular implementation is nice, but D needs to stop reinventing terminology and syntax matters. -- snip -- AddRef/Release is established COM terminology. One reason for keeping COM terminology might be if std.c.windows.com.IUnknown can automatically take advantage of DIP74. Of course this could also be a downside—would DIP74 break existing COM code in D?
Re: DIP74: Reference Counted Class Objects
On 2/27/15 10:34 AM, David Gileadi wrote: On 2/27/15 6:36 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: One of the first things that stood out to me is that add ref is two words and release is one. For the sake of symmetry, how about these: * opIncRef, opDecRef * opAcquire, opRelease All - please PLEASE do not derail this into yet another debate about which names are best. -- Andrei Using protocols rather than enforcing a particular implementation is nice, but D needs to stop reinventing terminology and syntax matters. -- snip -- AddRef/Release is established COM terminology. One reason for keeping COM terminology might be if std.c.windows.com.IUnknown can automatically take advantage of DIP74. Of course this could also be a downside—would DIP74 break existing COM code in D? I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei
Improving DIP74: functions borrow by default, retain only if needed
DIP74's function call protocol for RCOs has the caller insert opAddRef for each RCO passed by value. Then the callee has the responsibility to call opRelease (or defer that to another entity). This choice of protocol mimics the constructor/destructor protocol and probably shows our C++ bias. However, ARC does not do that. Instead, it implicitly assumes the callee is a borrower of the reference. Only if the callee wants to copy the parameter to a member or a global (i.e. save it beyond the duration of the call), a new call to retain() (= opAddRef) is inserted. That way, functions that only need to look at the object but not store it incur no reference call overhead. So I was thinking of changing DIP74 as follows: * Caller does NOT insert an opAddRef for byval RCOs * Callee does NOT insert an opRelease for its byval RCO parameters It seems everything will just work with this change (including all move scenarios), but it is simple enough to make me worry I'm missing something. Thoughts? Andrei
Re: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
On Fri, 2015-02-27 at 04:12 +, AJ via Digitalmars-d-learn wrote: […] I am in the same boat and totally agree. It's tough going from the user-experience of IntelliJ IDEA or Visual Studio back to vi on OS X with D. There seems to be a large hole in support for D debugging outside of Visual D (line numbers, variable values, etc). I was hoping to use D for a new project, but I don't feel the tools are ready yet. Kingsley Hendrickse is developing a D plugin for IntelliJ IDEA. Should also work with CLion. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [OT] HTML: div/iframe hybrid?
On 02/27/2015 02:17 AM, H. S. Teoh via Digitalmars-d wrote: but in the webdev world, sometimes it's all about unreasonable deadlines and shipping it as fast as possible. Well, that's not just webdev, that's true in just about any commercial software development. Hey, the sales guys just sold (nonexistent) feature X and promised it by (absurd) time Y, so go do it. When Opera ditched Presto, I died a little inside. Back in the day, Presto was the only serious alternative to the other major offerings (I even introduced Opera to my non-techie cousin and she liked it!), and was the only one that offered the level of configurability that I liked. In the early days it was also slim and fast, though it started bloating up toward the final days. But then Opera died and went the way of Chrome and now we're stuck with the IMO inferior choices. Yea, choice is good. Can't say I was surprised by what happened to opera though. I was more surprised (impressed) that a paid web browser managed to stay afloat for as long as it did, in the face of free browsers packaged with every OS. And content does NOT mean A barely-meaningful slogan or two and a vaguely related image tossed onto a mostly-blank page. Scroll down to get a few more slogans and clipart. (*cough* mobile-first design *cough*) I've already given up that fight. I used to think time machines were fictitious, but clearly *somebody* has invented one and is seriously screwing with our timeline, it's now the 90's in 2015 and contentless splash pages are all the rage. Only, instead of Flash or Java like in the real 90's, it's now CSS and HTML5 canvas. I don't know where all the lessons learned in the 90's went -- y'know, all those webpage design tutorials advising against contentless splash pages and recommending delivering oh, y'know, actual content? And sane navigation? -- but clearly the guy with the time machine has seriously screwed things up and nobody remembers the past to learn from its mistakes. Except users, whose memories were left intact so that they'll suffer for it needlessly. Sigh... Hah! :) You're right of course. Another part of the time warp: Remember how developers used to actually *care* about from-click-to-fully-rendered page loading times? My how I miss that. My library's (off-the-shelf) web inventory system, when viewed on my phone, takes about a full minute to respond to clicks (erm, taps) - even just on ordinary form fields. 'Course, that's an extreme example, but more generally, devs don't pay one bit of attention to page loading times. The theory is that AJAX's partial-page loading speeds things up because, well, you decrease the page download size by half of a kilobyte, and that's automagically faster than downloading a partial page, downloading a JS script, executing the JS script which then performs one of more AJAX requests to download other parts of the page separately, and then the browser finished piecing it together. Yea, brilliant optimization. Sites loaded and performed faster back when I was on 56k. No exaggeration. And forward/back/bookmarking *always* worked correctly. Not too long ago, when discussing page load times, I actually had one web developer try to tell me that none of time spent executing onLoad JS and such actually counts because page loading is different from onLoad processing. I'm amazed that anyone could convince themselves that technical distinction would actually matter to the user. But I'm convinced the time warp extends back to the 80's (or more). Remember when content used to be inseparably tied to the specific application it was created with? Then we got standardized data formats and interoperability. It was an ENORMOUS improvement. And now that's nearly gone. I can install any of a hundred different video players, music players and image viewers. But they're all nearly useless because (without hacking) YouTube videos only run on YouTube's player, NetFlix videos are only viewable on NetFlix's player, Spotify is only playable on Spotify's player, Flicker images are only viewable through Flicker, etc., and they all actively PROTECT their lack of interoperability. This allegedly modern shit has sent us straight back to the computing stone age before there was such a thing as widespread interoperability. But the extra bitch of it is: All these wonderful BD services are BUILT ON and RELY ON the interoperable stuff (like mpeg4, SQL DBs, etc) as their base! They couldn't realistically EXIST without taking advantage of interoperability! And TBH, I also despise the word content... because it makes it sound as if there's anything else that matters. Back in the day, the whole point of going online was to get what people nowadays call content, or more accurately, information. The 'net back then *was* primarily just content. Nowadays, however, content is a rare commodity, a mere tool to be hogged, controlled, and exploited to lure hapless netizens to
Re: Will D have a serious dedicated well supported IDE like Visual Studio or Eclipse?
On Friday, 27 February 2015 at 07:08:26 UTC, Ali Çehreli wrote: What version of gdb is needed and is that version easy to install? Something from late 2014 or newer is the best (7.8.50-cvs or 7.9.50-cvs) as it has got Ian's patches merged, but even an old stock Debian gdb (7.4.1) works reasonably well. GDB is acually easy to install if you compile it yourself. Just copy the binary to /usr/local/bin.
Re: Contradictory justification for status quo
On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. [...] @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 There are probably other holes that we haven't discovered yet. All in all, it's not looking like much of a guarantee right now. It's more like a cheese grater. This is a symptom of the fact that @safe, as currently implemented, starts by assuming the whole language is @safe, and then checking for exceptions that are deemed unsafe. Since D has become quite a large, complex language, many unsafe operations and unsafe combinations of features are bound to be overlooked (cf. combinatorial explosion), hence there are a lot of known holes and probably just as many, if not more, unknown ones. Trying to fix them is like playing whack-a-mole: there's always yet one more loophole that we overlooked, and that one hole compromises the whole system. Not to mention, every time a new language feature is added, @safe is potentially compromised by newly introduced combinations of features that are permitted by default. Rather, what *should* have been done is to start with @safe *rejecting* everything in the language, and then gradually relaxed to permit more operations as they are vetted to be safe on a case-by-case basis. That way, instead of having a long list of holes in @safe that need to be plugged, we *already* have guaranteed safety and just need to allow more safe operations that are currently prohibited. @safe bugs should have been of the form operation X is rejected but ought to be legal, rather than operation X is accepted but compromises @safe. In the former case we would already have achieved guaranteed safety, but in the latter case, as is the current situation, we don't have guaranteed safety and it's an uphill battle to get there (and we don't know if we'll ever arrive). See: https://issues.dlang.org/show_bug.cgi?id=12941 T -- Verbing weirds language. -- Calvin ( Hobbes)
Re: DIP74: Reference Counted Class Objects
On 2/27/15 6:46 AM, Steven Schveighoffer wrote: On 2/27/15 9:09 AM, Andrei Alexandrescu wrote: On 2/27/15 1:09 AM, ted wrote: Probably another silly question: How would the examples work with const/immutable (using examples in howtos)? e.g. const Widget a = new Widget; auto b = a;-- mutable method Widget.opAddRef is not callable using a const object This is tricky. I meant to discuss it; for now I planted a TODO. Wouldn't you bless this mechanism of logical const the same way synchronized does? Yes, it's a similar matter. -- Andrei
Re: DIP74: Reference Counted Class Objects
On 2/27/15 7:52 AM, Manu via Digitalmars-d wrote: Can I call opAddRef/opRelease from within the postblit/destructor manually and expect the compiler to elide calls correctly? That doesn't seem foolproof though, and you also said manual calls are not @safe. Why not specify a call sequence? Ah, I think you mean structs that have a class member? The compiler will insert opAddRef and opRelease appropriately: = * struct, class, and closure types that have RCO members accommodate calls to opRelease during their destruction. = Andrei
Re: On opCmp
On 2/27/15 6:04 AM, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in the
following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum strength)
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
if (this.rank rhs.rank)
{
return -1;
}
else if (this.rank rhs.rank)
{
return +1;
}
else
{
return 0;
}
}
}
}
Hm... what about:
return count rhs.count ? -1 : count rhs.count ? 1 : rank rhs.rank
? -1 : rank rhs.rank;
by reusing something like
auto opCmp(const Hit rhs) const
{
if (this.count rhs.count)
{
return -1;
}
else if (this.count rhs.count)
{
return +1;
}
else
{
return this.rank.standardOpCmp(rhs.rank)
}
}
A standard opCmp would be nice. Why wouldn't you use it for count as well?
-Steve
Re: On opCmp
On 02/27/2015 03:04 AM, Nordlöw wrote: Is there a more compact way to describe the opCmp function in the following struct Please see: http://forum.dlang.org/thread/lnr99a$vvd$1...@digitalmars.com#post-lnr99a:24vvd:241:40digitalmars.com Ali
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 14:02:58 UTC, Andrei Alexandrescu wrote: Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. A feature that is safe except for certain constructs is undesirable. It seems like you're agreeing with my general idea of going the whole hog. Generally having a large number of corner cases that require special language constructs to address is a Bad Sign. But D inherits C's separate compilation model. All these cool function and parameter attributes (pure, @safe, return ref, etc.) could be kept hidden and just used and they would Just Work if D didn't have to accommodate separation compilation. From my perspective, the only Bad Sign is that D has to navigate the tradeoff between: * concise function signatures * accurate communication between functions * enabling separate compilation It's like you have to sacrifice one to get the other two. Naturally I'm not keen on this, so I rush to see how far attribute inference for all functions can be taken. Then Dicebot suggests automated .di file generation with statically verified matching binaries: http://forum.dlang.org/post/otejdbgnhmyvbyaxa...@forum.dlang.org The point is that I don't feel the ominous burden of a Bad Sign here, because of the inevitability of this conflict.
Re: Contradictory justification for status quo
On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. [...] @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 There are probably other holes that we haven't discovered yet. Yah, @safe is in need of some good TLC. How about we make it a priority for 2.068? All in all, it's not looking like much of a guarantee right now. It's more like a cheese grater. This is a symptom of the fact that @safe, as currently implemented, starts by assuming the whole language is @safe, and then checking for exceptions that are deemed unsafe. Since D has become quite a large, complex language, many unsafe operations and unsafe combinations of features are bound to be overlooked (cf. combinatorial explosion), hence there are a lot of known holes and probably just as many, if not more, unknown ones. I'd have difficulty agreeing with this. The issues you quoted don't seem to follow a pattern of combinatorial explosion. On another vein, consider that the Java Virtual Machine has had for many, many years bugs in its safety, even though it was touted to be safe from day one. With each of the major bugs, naysayers claimed it's unfixable and it belies the claim of memory safety. A @safe function may assume that the code surrounding it has not broken memory integrity. Under that assumption, it is required (and automatically checked) that it leaves the system with memory integrity. This looks like a reasonable stance to me, and something I'm committed to work with. Trying to fix them is like playing whack-a-mole: there's always yet one more loophole that we overlooked, and that one hole compromises the whole system. Not to mention, every time a new language feature is added, @safe is potentially compromised by newly introduced combinations of features that are permitted by default. There aren't many large features to be added, and at this point with @safe being a major priority I just find it difficult to understand this pessimism. Probably a good thing to do, whether you're right or overly pessimistic, is to fix these bugs. In the worst case we have a slightly tighter cheese grate. In the best case we get to safety. Rather, what *should* have been done is to start with @safe *rejecting* everything in the language, and then gradually relaxed to permit more operations as they are vetted to be safe on a case-by-case basis. Yah, time travel is always so enticing. What I try to do is avoid telling people sentences that start with You/We should have. They're not productive. Instead I want to focus on what we should do starting now. See: https://issues.dlang.org/show_bug.cgi?id=12941 I'm unclear how this is actionable. Andrei
Re: DIP74: Reference Counted Class Objects
On 28 February 2015 at 01:43, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/27/15 7:17 AM, Manu via Digitalmars-d wrote: I'm not clear on structs. What is the order for calls; postblit, opInc, opDec, destructor? 75% of my use cases today are thin structs that wrap C/C++ api's. Structs don't get any special treatment with DIP74, only classes and interfaces. Well this is the case of the highest value to me, and DIP74 offers nothing? Can I call opAddRef/opRelease from within the postblit/destructor manually and expect the compiler to elide calls correctly? That doesn't seem foolproof though, and you also said manual calls are not @safe. Why not specify a call sequence? There's no mention of 'scope'. I presume functions that receive scope RC arguments will have the opportunity to have opAddRef/opRelesae elided around the call? That might be a future improvement. In fact that may be possible today; I've spoken to an ARC expert who read DIP74 and said Apple's ARC does not insert a retain() for a function call, i.e. it assumes functions only borrow unless they actually do keep a pointer (e.g. assign to a member or global), and only in that case inserts a retain(). If I'm not missing something, we can do this with DIP74 which will reduce the opAddRef/opRelease traffic quite a bit. Hmmm, that does sound right. Very nice.
Re: DIP74: Reference Counted Class Objects
On 2/27/15 7:52 AM, Manu via Digitalmars-d wrote: Well this is the case of the highest value to me, and DIP74 offers nothing? For structs you use postblit and destructors. -- Andrei
Re: DIP74: Reference Counted Class Objects
On 2/27/15 7:42 AM, H. S. Teoh via Digitalmars-d wrote: S.foo() should have been annotated with 'return', but the programmer forgot and the compiler still accepts the code without any warnings, thereby violating @safe. That is correct. However, the user is on the hook because her use of @trusted when deallocating the array. I think the right thing to do about owned data is to give it its own abstraction, and plant it in the standard library. RCSlice would be an obvious go-to structure. Could you consider defining an OwnedSlice and see how far you can get? Andrei
Re: DIP74: Reference Counted Class Objects
On 27 February 2015 at 07:50, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei I'm excited for this. I'm very happy with the approach. I'm particularly happy that it is implemented as a pair of operators. This is what I've always hoped it to look like. My initial reactions are: There's no mention of const/immutable...? Surely we can have RC immutable things right? I can't see how that works here... but it's very important. I'm not clear on structs. What is the order for calls; postblit, opInc, opDec, destructor? 75% of my use cases today are thin structs that wrap C/C++ api's. There's no mention of 'scope'. I presume functions that receive scope RC arguments will have the opportunity to have opAddRef/opRelesae elided around the call? I wonder if some standard GetRefCount function should exist? Otherwise they will probably end up being named all sorts of different things. I guess I can't think of any value in a standardisation of the function otherwise though...
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim Grøstad wrote: No. If I can't open a file I'd better not create a File object in an invalid state. Invalid states defeats RAII. This is the attitude I don't like, because it means that you have to use pointers when you could just embed the file-handle. That leads to more allocations and more cache misses. I really don't understand how any of this is related to what we were previously discussing: error handling. So you can't re-enter that mutex as you asked, so I will grant you a scopedLock, but it is in an errored state so you'd better check that it is valid! A file can always enter an errored state. So can OpenGL. That doesn't mean you have to react immediately in all cases. This is counter to my experience. It does't make much sense to go on after an error, in any software that want some reliability.
Re: DIP74: Reference Counted Class Objects
On 2/27/15 7:17 AM, Manu via Digitalmars-d wrote: There's no mention of const/immutable...? Surely we can have RC immutable things right? I can't see how that works here... but it's very important. Yah. I've added a TODO. I'm not clear on structs. What is the order for calls; postblit, opInc, opDec, destructor? 75% of my use cases today are thin structs that wrap C/C++ api's. Structs don't get any special treatment with DIP74, only classes and interfaces. There's no mention of 'scope'. I presume functions that receive scope RC arguments will have the opportunity to have opAddRef/opRelesae elided around the call? That might be a future improvement. In fact that may be possible today; I've spoken to an ARC expert who read DIP74 and said Apple's ARC does not insert a retain() for a function call, i.e. it assumes functions only borrow unless they actually do keep a pointer (e.g. assign to a member or global), and only in that case inserts a retain(). If I'm not missing something, we can do this with DIP74 which will reduce the opAddRef/opRelease traffic quite a bit. I wonder if some standard GetRefCount function should exist? Otherwise they will probably end up being named all sorts of different things. I guess I can't think of any value in a standardisation of the function otherwise though... Yah, leave that to users. Andrei
Re: DIP74: Reference Counted Class Objects
On Thu, Feb 26, 2015 at 11:35:55PM -0800, Walter Bright via Digitalmars-d wrote:
On 2/26/2015 5:37 PM, H. S. Teoh via Digitalmars-d wrote:
Wait, are you saying that forgetting the 'return' annotation will
still compile without any warning?? Wow, that's ... not nice. :-(
Indeed, and the compiler will error out if you try that:
---
struct S {
int x;
}
ref int foo(ref S s) {
return s.x;
}
---
dmd -c foo -dip25
foo.d(7): Error: escaping reference to local ref variable s
There'd be no point to DIP25 if it didn't.
Huh? We weren't talking about that -- it's already a given that this
case works, otherwise DIP25 would truly have no point.
The problematic case comes from the manually-managed array member that
you can freely return, yet it may become a dangling reference once
opRelease deallocates it:
class S {
int[] data;
int[] foo() { return data; } // -- happily compiles
void opAddRef() { ... }
void opRelease() {
...
GC.free(data); // -- uh oh
}
}
int[] fun() {
S s = /* create instance of S */
return s.foo();
// s goes out of scope here, and opRelease() cleans up
// but we now have an escaping reference to s.data
}
void main() {
int[] dangling = fun();
dangling[0] = 1;// kaboom
}
S.foo() should have been annotated with 'return', but the programmer
forgot and the compiler still accepts the code without any warnings,
thereby violating @safe.
T
--
Bomb technician: If I'm running, try to keep up.
Re: Is there such a thing?
On Friday, 27 February 2015 at 07:26:06 UTC, Jacob Carlborg wrote: On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things...
Re: Improving DIP74: functions borrow by default, retain only if needed
On Friday, 27 February 2015 at 18:24:27 UTC, Andrei Alexandrescu wrote: DIP74's function call protocol for RCOs has the caller insert opAddRef for each RCO passed by value. Then the callee has the responsibility to call opRelease (or defer that to another entity). This choice of protocol mimics the constructor/destructor protocol and probably shows our C++ bias. However, ARC does not do that. Instead, it implicitly assumes the callee is a borrower of the reference. Only if the callee wants to copy the parameter to a member or a global (i.e. save it beyond the duration of the call), a new call to retain() (= opAddRef) is inserted. That way, functions that only need to look at the object but not store it incur no reference call overhead. So I was thinking of changing DIP74 as follows: * Caller does NOT insert an opAddRef for byval RCOs * Callee does NOT insert an opRelease for its byval RCO parameters It seems everything will just work with this change (including all move scenarios), but it is simple enough to make me worry I'm missing something. Thoughts? I think it's fine. I couldn't even figure out the original motive for wanting to add those calls -- I thought it must have something to do with threads or exceptions or something, but even then I couldn't figure it out. Any reference argument will, by definition, outlive its function -- it can't possibly die within the function itself, since the caller still thinks it's a valid reference. Another thing is that local references in general need not participate in reference counting. They will retain and release the reference automatically when they go in and out of scope. I'm really no expert (except that I like to study and think and by thinking become somewhat expert it appears), but if all ARC could be confined to global/heap = global/heap copies, you'd get the most efficient code. And I'm not trying to advertise a reference tracking system :-), but the real hiccup is that global reference can go *through* the stack and land back at a global... and you would need to keep track of that.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Friday, 27 February 2015 at 07:09:20 UTC, Benjamin Thaut wrote: Am 27.02.2015 um 00:05 schrieb deadalnix: Note that in D, you have union and all kind of crap like that, so what is writing a pointer is non obvious and so the tradeof is very different than it is in other languages. To have any chance of implementing a better GC in D I would simly start of with assuming all code is @safe. For code that is not @safe the user would have to make sure it plays nice with the GC. This would also apply to unions which contain pointer types. If you wan't to write a good GC that does support non @safe features without user input you don't even have to start in my opinion. That is a reasonable approach (and indeed, I would assume that @system code have to ensure that it does not do something that will confuse the GC). Still, what you can do when compiling AOT is different than what you can do when you JIT. For instance, when you JIT, you can add write barrier and remove them on the fly when you need to. When doing AOT, they must be always on or always of.
Re: DIP74: Reference Counted Class Objects
On 2015-02-27 19:38, Andrei Alexandrescu wrote: I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei It's still a breaking change. See one of my other replies [1] for a possible solution. [1] http://forum.dlang.org/post/mcp5nu$1nus$1...@digitalmars.com -- /Jacob Carlborg
[Issue 14225] [REG2.067a] GDB: error reading variable (string + dup)
https://issues.dlang.org/show_bug.cgi?id=14225 --- Comment #2 from Martin Krejcirik m...@krej.cz --- Small correction: -gc doesn't make it work. Also the problem is not limited to recent gdb version, 7.4.1-debian is affected too for example. --
D support in syntax highlighters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would be nice to get up-to-date syntax highlighting support for D in the commonly used libraries. Those libraries are used by many other tools and it's important for D's visibility that it's present in any list of programming languages. - - https://highlightjs.org/ - - http://pygments.org/ - - https://code.google.com/p/google-code-prettify/ - - http://prismjs.com/extending.html#language-definitions - - https://github.com/jneen/rouge - - https://github.com/rumpelsepp/rugments As usual go is already supported by all of them. Updating the existing support in pygments and highlight.js might be a good starting point. https://bitbucket.org/birkenfeld/pygments-main/src/943cb8da8444b832804f6cebf9679305b22f8b15/pygments/lexers/d.py https://github.com/isagalaev/highlight.js/blob/master/src/languages/d.js -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8NEyAAoJELJzgRYSuxk57k4QALXFMY2RFECltWV9kq2gCi0v 8VicmWM/nSfKJCMrxduIP/Hu3vZ5jzFtKRgKPHtxKdKjRfpDOWc79EcnyxMC2T/u 2GdWZJl6q9nWWVQcFCr/ejxdLUt4Eew8hnN5hTGb8UHF7HfOxpQv0Ch+2RfV5KhA xDGfoRGK6B8MspCO3xP+5lgXt9CUp9GRHo8gq6UgObO8fepj4j3ut1oilVJQBD0K WvRE4T7cls3ZuuW0jaabTpbHR8MoS6C2UR64fCAnSAFPN6t5hX4url0xu5h08Ffh ztE+fxEiWcUoI2X/qLAcIGkR0YIUjng8o9yqCagOoMjjhWqOeikSOmtCH4dkBDPS Ldpzp29MFnjeUNy5VBWTiEVcoV7G1/+B3S/T3ZYVzfIe9lOWEeN9Y1gfJ3g02zMd 7yBLOeKMZ8c8ORZLXiNzvBtkV79xJ5JWAbjG22mykSlqRMvPSFzRQx1NE0sEeKMs VC6LYY71xB76h41spSzGpn82s2NauK79o3kwaLhALM6LukQqrkQGeuxrLxYlgWRq mEUGUwq0Nv//pajIx0DDcsN9cD7yKXlI8rQrH5yS5clRExKRsT+vcQ4HzBT2d6Gy AA44GkHWEtKUrMMCjgpvKrJuC+rMBoMrs2biVjRjqyxVy9zYp2Gf/Ua01YTiJlHL zu/+/GDJsrN8j4uRrVbt =24UH -END PGP SIGNATURE-
[Issue 14199] [REG2.067a] Dwarf Error: mangled line number section
https://issues.dlang.org/show_bug.cgi?id=14199 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2a0108edaf3895ac2f23dc28b1d20c9c5edfe85e Merge pull request # from MartinNowak/fix14199 fix Issue 14199 - [REG2.067a] Dwarf Error: mangled line number section --
LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
Hi all! Finally, LLVM 3.6 has been released! See the release notes here: http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html Downloads: http://llvm.org/releases/download.html#3.6.0 Also note that LDC is mentioned in the release notes as one of the projects who are already supporting LLVM 3.6. Just recompile LDC using master branch from GitHub or from the 0.15.1 source. This is the 6th time that LDC and D are mentioned in the LLVM release notes! Regards, Kai
Re: Improving DIP74: functions borrow by default, retain only if needed
On Fri, Feb 27, 2015 at 10:24:26AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: DIP74's function call protocol for RCOs has the caller insert opAddRef for each RCO passed by value. Then the callee has the responsibility to call opRelease (or defer that to another entity). This choice of protocol mimics the constructor/destructor protocol and probably shows our C++ bias. However, ARC does not do that. Instead, it implicitly assumes the callee is a borrower of the reference. Only if the callee wants to copy the parameter to a member or a global (i.e. save it beyond the duration of the call), a new call to retain() (= opAddRef) is inserted. That way, functions that only need to look at the object but not store it incur no reference call overhead. So I was thinking of changing DIP74 as follows: * Caller does NOT insert an opAddRef for byval RCOs * Callee does NOT insert an opRelease for its byval RCO parameters So if the callee assigns the RCO to something else, that's when opAddRef/retain will get called, but if the callee doesn't do that, then no call is inserted? Sounds reasonable. It seems everything will just work with this change (including all move scenarios), but it is simple enough to make me worry I'm missing something. Thoughts? [...] As long as there is no sharing of the RCO between threads, this looks like it should work. (But I'm no ARC expert, so don't take my word for it.) But if there's sharing, the story becomes drastically more complex. T -- Lottery: tax on the stupid. -- Slashdotter
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
Bleh, that was dumb.
void main()
{
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Still same question. The issue here is how do you know that the
reference that you are sure is keeping the thing alive is not going to
release it through some back door.
-Steve
Re: Contradictory justification for status quo
On Friday, 27 February 2015 at 15:35:46 UTC, H. S. Teoh wrote:
@safe has some pretty nasty holes right now... like:
https://issues.dlang.org/show_bug.cgi?id=5270
https://issues.dlang.org/show_bug.cgi?id=8838
My new reference safety system:
http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org
...would solve the above two bugs. In fact, it's designed
precisely for bugs like those. Here's your failing use case for
bug 5270. I'll explain how my system would track and catch the
bug:
int delegate() globDg;
void func(scope int delegate() dg) {
globDg = dg; // should be rejected but isn't
globDg();
}
If func is marked @safe and no attribute inference is permitted,
this would error, as it copies a reference parameter to a global.
However, let's assume we have inference. The signature would now
be inferred to:
void func(noscope scope int delegate() dg);
Yeah it's obviously weird having both `scope` and `noscope`, but
that's pure coincidence, and moreover, I think the use of `scope`
here would be made obsolete by my system anyway. (Note also that
the `noscope` bikeshed has been suggested to be painted `static`
instead -- it's not about the name, yet... ;-)
void sub() {
int x;
func(() { return ++x; });
}
Well I suppose this rvalue delegate is allocated on the stack,
which will have local reference scope. This is where you'd get
the safety error in the case of attribute inference, as you can't
pass a local reference to a `noscope` parameter. The rest is just
a foregone conclusion (added here for completion):
void trashme() {
import std.stdio;
writeln(globDg()); // prints garbage
}
void main() {
sub();
trashme();
}
The next bug, 8838, is a very simple case, I think:
int[] foo() @safe
{
int[5] a;
return a[];
}
`a`, being a static array, would have a reference scope depth of
1, and when you copy the reference to make a dynamic array in the
return value, the reference scope inherits that of `a`. Any scope
system would catch this one, I'm afraid. Mine seems like overkill
in this case. :-/
Re: What am I doing wrong here - canFind with iota is not working
immutable float item = 0.174531f;
r.canFind!q{ feqrel(cast()a, cast()b) = 21 }(item).writeln;
}
With a recent Phobos bug fix you can now write:
r.canFind!q{ feqrel(a, b) = 21 }(item).writeln;
Bye,
bearophile
Re: DIP74: Reference Counted Class Objects
On 2/27/15 11:58 AM, Jacob Carlborg wrote: On 2015-02-27 19:38, Andrei Alexandrescu wrote: I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei It's still a breaking change. See one of my other replies [1] for a possible solution. [1] http://forum.dlang.org/post/mcp5nu$1nus$1...@digitalmars.com I'm fine with breaking code of people who happen to use the names opAddRef and opRelease. -- Andrei
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2/27/15 1:24 PM, Andrei Alexandrescu wrote:
DIP74's function call protocol for RCOs has the caller insert opAddRef
for each RCO passed by value. Then the callee has the responsibility to
call opRelease (or defer that to another entity). This choice of
protocol mimics the constructor/destructor protocol and probably shows
our C++ bias.
However, ARC does not do that. Instead, it implicitly assumes the callee
is a borrower of the reference. Only if the callee wants to copy the
parameter to a member or a global (i.e. save it beyond the duration of
the call), a new call to retain() (= opAddRef) is inserted. That way,
functions that only need to look at the object but not store it incur no
reference call overhead.
So I was thinking of changing DIP74 as follows:
* Caller does NOT insert an opAddRef for byval RCOs
* Callee does NOT insert an opRelease for its byval RCO parameters
It seems everything will just work with this change (including all move
scenarios), but it is simple enough to make me worry I'm missing
something. Thoughts?
I recall saying something like this, and someone came up with a reason
why you still have to add the calls. I'll see if I can dig it up.
OK, I found the offending issue. It's when you pass a parameter, the
only reference holding onto it may be also passed as well. Something like:
void foo(C c, C2 c2)
{
c2.c = null; // this destroys 'c' unless you opAddRef it before passing
c.someFunc(); // crash
}
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
How does the compiler know in this case that it *does* have to opAddRef
c before calling? Maybe your ARC expert can explain how that works.
BTW, Michel Fortin is who pointed this out.
-Steve
[Issue 14212] frexp for const and immutable fails to compile
https://issues.dlang.org/show_bug.cgi?id=14212 --- Comment #7 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/cf57c7529a63ac970167c65cb659d5249a3a1ab9 Merge pull request #3017 from 9il/frexp [2.067.0-b2][regression] fix Issues 14212 and 6586 --
Re: Is there such a thing?
On 2015-02-27 20:49, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... I think that's a completely different topic. -- /Jacob Carlborg
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote: On 2/27/15 11:58 AM, Jacob Carlborg wrote: On 2015-02-27 19:38, Andrei Alexandrescu wrote: I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei It's still a breaking change. See one of my other replies [1] for a possible solution. [1] http://forum.dlang.org/post/mcp5nu$1nus$1...@digitalmars.com I'm fine with breaking code of people who happen to use the names opAddRef and opRelease. -- Andrei Are op* considered reserved member names?
[Issue 6586] feqrel for const values too
https://issues.dlang.org/show_bug.cgi?id=6586 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/cf57c7529a63ac970167c65cb659d5249a3a1ab9 Merge pull request #3017 from 9il/frexp [2.067.0-b2][regression] fix Issues 14212 and 6586 --
[Issue 14229] New: RAII ordering is wrong
https://issues.dlang.org/show_bug.cgi?id=14229
Issue ID: 14229
Summary: RAII ordering is wrong
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: etci...@gmail.com
I'm having issues with the ordering of copy constructors / destructors, and
this causes my reference counting utilities to break down.
Here's the relevant code:
```
import std.stdio;
struct A {
this(B!A- i) {
b = i;
writeln(A.__ctor);
}
~this() { writeln(A.__dtor); }
this(this) { writeln(A.__copy); }
B!A- b;
}
struct B(string ident) {
this(C!B1- i, C!B2- j, C!B3- k) {
c = i;
c2 = j;
c3 = k;
writeln(ident ~ B.__ctor);
}
~this() { writeln(ident ~ B.__dtor); }
this(this) { writeln(ident ~ B.__copy); }
C!B1- c;
C!B2- c2;
C!B3- c3;
}
struct C(string ident) {
this(int i, int j, int k) {
a = i;
b = j;
c = k;
writeln(ident ~ C.__ctor);
}
~this() { writeln(ident ~ C.__dtor); }
this(this) { writeln(ident ~ C.__copy); }
int a;
int b;
int c;
}
C!B1- getC(A a) {
C!B1- c = a.b.c;
writeln(Returning B1-C);
return c;
}
void main() {
A a;
C!B1- c1 = C!B1-(1,2,3);
C!B2- c2 = C!B2-(4,5,6);
C!B3- c3 = C!B3-(7,8,9);
B!A- b = B!A-(c1, c2, c3);
a.b = b;
writeln(Getting C);
C!B1- c;
c = getC(a);
writeln(Got C);
}
```
The relevant output is:
Getting C
B1-C.__copy
B2-C.__copy
B3-C.__copy
A-B.__copy
A.__copy
B1-C.__copy
Returning B1-C
A.__dtor
A-B.__dtor
B3-C.__dtor
B2-C.__dtor
B1-C.__dtor
B1-C.__dtor
Got C
There's a mistake here.
The copy pattern under Getting C is fine. From the top down. To be equally
fine, destruction pattern should reverse it! It should propagate the
destruction tree from the bottom up. ie. you should be seeing:
B3-C.__dtor
B2-C.__dtor
B1-C.__dtor
A-B.__dtor
A.__dtor
Unfortunately, this might end up in the early destruction of an object
(segfault), and an absolute nightmare for the poor programmer debugging this
while expecting a bottom up destruction pattern.
--
[Issue 12983] overload not recognized depending on order of declaration
https://issues.dlang.org/show_bug.cgi?id=12983 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12983] overload not recognized depending on order of declaration
https://issues.dlang.org/show_bug.cgi?id=12983 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ac443bd294103807f047ed9d74a05755f4e08f35 fix Issue 12983 - overload not recognized depending on order of declaration https://github.com/D-Programming-Language/dmd/commit/dc11b92c6a3dce3f041e665c721cc83f5c0f5086 Merge pull request #4430 from 9rnsr/fix12983 Issue 12983 - overload not recognized depending on order of declaration --
Re: DIP74: Reference Counted Class Objects
On 2/27/15 12:13 PM, weaselcat wrote: On Friday, 27 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote: On 2/27/15 11:58 AM, Jacob Carlborg wrote: On 2015-02-27 19:38, Andrei Alexandrescu wrote: I explicitly avoided the COM names in order to avoid potential confusion and code breakage. People can easily add IUnknownAuto that does the forwarding. -- Andrei It's still a breaking change. See one of my other replies [1] for a possible solution. [1] http://forum.dlang.org/post/mcp5nu$1nus$1...@digitalmars.com I'm fine with breaking code of people who happen to use the names opAddRef and opRelease. -- Andrei Are op* considered reserved member names? No. -- Andrei
Re: DIP74: Reference Counted Class Objects
When a function makes/destroys multiple references to an object it should always be safe to coalesce all AddRefs into the first AddRef and all Releases to into the last Release call. This could be a small performance win, but opAddRef/opRelease would need the count as argument or maybe as template parameter.
Typo in DIP25 ?
Hi,
In DIP25, what is the meaning of pairing an open parenthesis with a
closing curly brace? Is this a typo?
From Dec 28, 2014:
http://wiki.dlang.org/?title=DIP25oldid=5279#In_a_nutshell
ref int fun(ref int a} { return a; } // ERROR
ref int fun(ref inout int a} { return a; } // FINE
From today:
http://wiki.dlang.org/DIP25#In_a_nutshell
ref int fun(ref int a} { return a; } // ERROR
ref int gun(return ref int a} { return a; } // FINE
ref T hun(T)(ref T a} { return a; } // FINE, templates use deduction
Thanks!
-Parke
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 03:23 AM, Walter Bright wrote: - RC is slower overall This claim isn't true for almost all applications when using a conservative GC, except for programs that produce a lot of garbage and have very few long-lived objects. The memory bandwidth consumed to mark long-lived objects during every collection dominates the GC cost even for small heaps (say 100MB). -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8Nu9AAoJELJzgRYSuxk5ONwP/0vfyS4UH4OuyXASpyTRdEYQ PsAi68S1oSqJaZXGkjVYSsPBASA3qn8Vf/n2002c4NKjGnEbywVyUGijmzyEx94q Ja8TKtIvw4HJ8xCQEd3NvKwttJhY+K868hAH2YWEiOknad0x7MV3N0GXb7yyEFbt b5AMJmr5Qs+6wTvOYcwgdJevznaE4LjxtI/iURsjQ7X3tfg6igb3W96Ehx/5URFB upP5lCswBJ5agz8TbOSVeqk1AjR7dYYgtSDhF+IhkH9Ig5lJ68SECWNG7Ru9ixmK JqUhyGJXWpK5UWkDE9zggUQ2M1QVXTnX/QzzUGcvnbqC1SgHbd79gTwQWOLSOy8i 5e464zCVe1QcMmDK5vUxcuNCr9XiATV/k9M+SHtkXu2AZvx0mQdWBKPVnQmTzizQ Tf+yKT84zKz4kZK6cfoP9KsrDlWLcU+L6vmghkqFfkk0mpvkoXEF7mNsPlWw+bvn GAEJvj+xItFkulaE9X+HWbvRs5YeFOSuV7qXRKoTGRvhnr49XaDLi2jANLBt2SLu Ku/pjkwl20rHUB3Q8+7qfoqjm/iunujZxqVw+vXzRvp3hrvbMiFW2b6jHzl8WN7n LceLniG/sk4/hLILlu4CKgiLQRk3PxQEBJHqUaSqNZZS7Wrp/g6b3nKaGzqv2ehM 2RRjU57Ptw6AQsw+QT9E =ANkN -END PGP SIGNATURE-
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2/27/15 1:02 PM, Michel Fortin wrote:
On 2015-02-27 20:34:08 +, Steven Schveighoffer said:
On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
Bleh, that was dumb.
void main()
{
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Still same question. The issue here is how do you know that the
reference that you are sure is keeping the thing alive is not going to
release it through some back door.
You have to retain 'c' for the duration of the call unless you can prove
somehow that calling the function will not cause it to be released. You
can prove it in certain situations:
- you are passing a local variable as a parameter and nobody has taken a
mutable reference (or pointer) to that variable, or to the stack frame
(be wary of nested functions accessing the stack frame)
- you are passing a global variable as a parameter to a pure function
and aren't giving to that pure function a mutable reference to that
variable.
- you are passing a member variable as a parameter to a pure function
and aren't giving to that pure function a mutable reference to that
variable or its class.
There are surely other cases, but you get the idea. These three
situations are probably the most common, especially the first one. For
instance, inside a member function, 'this' is a local variable and you
will never pass it to another function by ref, so it's safe to call
'this.otherFunction()' without retaining 'this' first.
Thanks. So it seems we continue as we were with DIP74 and leave the rest
to the implementation.
Andrei
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2015-02-27 20:34:08 +, Steven Schveighoffer said:
On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
Bleh, that was dumb.
void main()
{
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Still same question. The issue here is how do you know that the
reference that you are sure is keeping the thing alive is not going to
release it through some back door.
You have to retain 'c' for the duration of the call unless you can
prove somehow that calling the function will not cause it to be
released. You can prove it in certain situations:
- you are passing a local variable as a parameter and nobody has taken
a mutable reference (or pointer) to that variable, or to the stack
frame (be wary of nested functions accessing the stack frame)
- you are passing a global variable as a parameter to a pure function
and aren't giving to that pure function a mutable reference to that
variable.
- you are passing a member variable as a parameter to a pure function
and aren't giving to that pure function a mutable reference to that
variable or its class.
There are surely other cases, but you get the idea. These three
situations are probably the most common, especially the first one. For
instance, inside a member function, 'this' is a local variable and you
will never pass it to another function by ref, so it's safe to call
'this.otherFunction()' without retaining 'this' first.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
[Issue 14229] RAII ordering is wrong
https://issues.dlang.org/show_bug.cgi?id=14229 Etienne etci...@gmail.com changed: What|Removed |Added Severity|enhancement |major --
Re: Improving DIP74: functions borrow by default, retain only if needed
On 2/27/15 12:34 PM, Steven Schveighoffer wrote:
On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
Bleh, that was dumb.
void main()
{
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Still same question. The issue here is how do you know that the
reference that you are sure is keeping the thing alive is not going to
release it through some back door.
Thanks! In ARC, there are autorelease pools that keep at least one
reference to the objects they own. I think that's what they are for.
So let me add a complete example:
class C {
void someFunc();
void opAddRef();
void opRelease();
}
class C2 {
C c;
void opAddRef();
void opRelease();
}
void foo(C c, C2 c2) {
c2.c = null;
c.someFunc(); // crash
}
void main() {
C2 c2 = new C2;
c2.c = new C;
foo(c2.c, c2);
}
Distinguishing these is an interesting problem. In fact we can reduce
the matter to one class only:
class C {
C c;
void someFunc();
void opAddRef();
void opRelease();
}
void foo(C c1, C c2) {
c2.c = null;
c1.someFunc(); // crash
}
void main() {
C obj = new C;
obj.c = new C;
foo(obj.c, obj);
}
Andrei
Re: DIP74: Reference Counted Class Objects
On Friday, 27 February 2015 at 07:44:18 UTC, anonymous wrote: We all pray you become less of a gaping asshole before youre in charge of anything. Thank you for the compliment :)
Re: A Refcounted Array Type
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer wrote: In that case, you shouldn't be subject to any kind of race conditions. But we can't make the library/language based on this assumption. Your case is the exceptional case. His case is not @safe, so we can ignore that problem. However, this do not change the fact that the type qualifier do not provide the guarantee they are supposed to.
Re: Typo in DIP25 ?
On 2/27/15 12:22 PM, Parke via Digitalmars-d wrote:
Hi,
In DIP25, what is the meaning of pairing an open parenthesis with a
closing curly brace? Is this a typo?
From Dec 28, 2014:
http://wiki.dlang.org/?title=DIP25oldid=5279#In_a_nutshell
ref int fun(ref int a} { return a; } // ERROR
ref int fun(ref inout int a} { return a; } // FINE
From today:
http://wiki.dlang.org/DIP25#In_a_nutshell
ref int fun(ref int a} { return a; } // ERROR
ref int gun(return ref int a} { return a; } // FINE
ref T hun(T)(ref T a} { return a; } // FINE, templates use deduction
Thanks!
-Parke
Fixed, thanks. -- Andrei
Re: Improving DIP74: functions borrow by default, retain only if needed
On Friday, 27 February 2015 at 20:30:20 UTC, Steven Schveighoffer
wrote:
OK, I found the offending issue. It's when you pass a
parameter, the only reference holding onto it may be also
passed as well. Something like:
void foo(C c, C2 c2)
{
c2.c = null; // this destroys 'c' unless you opAddRef it
before passing
c.someFunc(); // crash
}
void main()
{
C c = new C; // ref counted class
C2 c2 = new C2; // another ref counted class
c2.c = c;
foo(c, c2);
}
How does the compiler know in this case that it *does* have to
opAddRef c before calling? Maybe your ARC expert can explain
how that works.
Split-passing nested ref-counted classes with null loads! How
insidious!
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 01:43 AM, Manu via Digitalmars-d wrote: D's GC is terrible, and after 6 years hanging out in this place, I have seen precisely zero development on the GC front. Nobody can even imagine, let alone successfully implement a GC that covers realtime use requirements. We have achieved quite some speedup on the GC front (up to 50% faster allocations) and we work on a few more improvements for the next release (good for at least another 20% speedup). There is even a useful idea how to implement an incremental GC. I might give a talk about the current state at DConf. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8N0MAAoJELJzgRYSuxk5/4IP/AzBOzt3jc77vwovtV+J9C5E D6jE/y1pCkmlQ9Wjb7yl5F0Ul0bQiDXhGH55rkzYO/AHrCZLGZ2TSr+CchCeDR64 7dVmDCLxDN+Tipo3iOZVZzrosDKISRv0H3o82NUqmWF2jqoXdRZJthSigdiKENAW 4wIIfScBqRdATHtFCw2heSScYMxE480WeEQx2rIjLLuDMD2S0uua0cKDBOlMVV+v t32AnCOyeTL2TGwtO1TTCZVbRH7c4ob1F1dTH6G/nu9K+vTbMJ9FNhBmnwVnYu12 V+RK+WDgogxN9I4hTE/kUKTxbhA6k9u3sG09tql0mIBbLBkVoSsC3ib9WHSOS/ki KcHDNJAvy3pOR5gBTlR/x24r3G1RGkJcjiFTPaCan4oqrsveY4wQ63wImQqoejXj 8iOvJ88ssYTWkol0nSR4QntOeGNK+ni37U2MpBizKdflaVMN75GhDkGlZ55Rt1BA L1SpKUC5c9Kyz43Wvf0QZjWoSvB4LZJc9daU1sMIkCn20nKM6G8rY9PtONE9xoQE 2hYW9S5ufrm9YRuKy2qJmsfEw0Ou2S5MiH6brgHhqnmgWpU9mK3AKN0o1JfwxTAK nHQxrudAB0egpAePUs2wW8jHWXbdtP2GSM575AKr8JMYZkf/K8UoXsibTGPSKb5W VLL35ZKr8y0oVctWnUEd =UARS -END PGP SIGNATURE-
Re: Contradictory justification for status quo
On Fri, Feb 27, 2015 at 07:57:22AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...] Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. [...] @safe has some pretty nasty holes right now... like: https://issues.dlang.org/show_bug.cgi?id=5270 https://issues.dlang.org/show_bug.cgi?id=8838 https://issues.dlang.org/show_bug.cgi?id=12822 https://issues.dlang.org/show_bug.cgi?id=13442 https://issues.dlang.org/show_bug.cgi?id=13534 https://issues.dlang.org/show_bug.cgi?id=13536 https://issues.dlang.org/show_bug.cgi?id=13537 https://issues.dlang.org/show_bug.cgi?id=14136 https://issues.dlang.org/show_bug.cgi?id=14138 There are probably other holes that we haven't discovered yet. Yah, @safe is in need of some good TLC. How about we make it a priority for 2.068? If we're going to do that, let's do it right. Let's outlaw everything in @safe and then start expanding it by adding explicitly-vetted operations. See below. All in all, it's not looking like much of a guarantee right now. It's more like a cheese grater. This is a symptom of the fact that @safe, as currently implemented, starts by assuming the whole language is @safe, and then checking for exceptions that are deemed unsafe. Since D has become quite a large, complex language, many unsafe operations and unsafe combinations of features are bound to be overlooked (cf. combinatorial explosion), hence there are a lot of known holes and probably just as many, if not more, unknown ones. I'd have difficulty agreeing with this. The issues you quoted don't seem to follow a pattern of combinatorial explosion. No, what I meant was that in an assume safe unless proven otherwise system, there's bound to be holes because the combinatorial explosion of feature combinations makes it almost certain there's *some* unsafe combination we haven't thought of yet that the compiler currently accepts. And it may be a long time before we discover this flaw. This means that the current implementation almost certainly has holes (and in fact it has quite a few known ones, and very likely more as-yet unknown ones), therefore it's not much of a guarantee of safety at all. What I'm proposing is that we reverse that: start with prohibiting everything, which is by definition safe, since doing nothing is guaranteed to be safe. Then slowly add to it the things that are deemed safe after careful review, until it becomes a usable subset of the language. This way, we actually *have* the guarantee of safety from day one, and all we have to do is to make sure each new addition to the list of permitted operations doesn't introduce any new holes. And even in the event that it does, the damage is confined because we know exactly where the problem came from: we know that X commits in the past @safe had no holes, and now there's a hole, so git bisect will quickly locate the offending change. Whereas in our current approach, everything is permitted by default, which means the safety guarantee is broken *by default*, except where we noticed and plugged it. We're starting with a cheese grater and plugging the holes one by one, hoping that one day it will become a solid plate. Why not start with a solid plate in the first place, and make sure we don't accidentally punch holes through it? On another vein, consider that the Java Virtual Machine has had for many, many years bugs in its safety, even though it was touted to be safe from day one. With each of the major bugs, naysayers claimed it's unfixable and it belies the claim of memory safety. Fallacy: Language X did it this way, therefore it's correct to do it this way. A @safe function may assume that the code surrounding it has not broken memory integrity. Under that assumption, it is required (and automatically checked) that it leaves the system with memory integrity. This looks like a reasonable stance to me, and something I'm committed to work with. That's beside the point. Assuming the surrounding context is safe or not has no bearing on whether certain combinations of operations inside the @safe function has unsafe semantics -- because the compiler failed to recognize a certain construct as unsafe. The latter is what I'm talking about. Trying to fix them is like playing whack-a-mole: there's always yet one more loophole that we overlooked, and that one hole compromises the whole system. Not to mention, every time a new language feature is added, @safe is potentially compromised by newly introduced combinations of features that are permitted by default. There aren't many large features to be added, and at this point with @safe being a
Re: DIP74: Reference Counted Class Objects
Yup, it sound like the destruction should be delegated to the destructor. Maybe the release method could return the refcount ?
