Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 2014-12-03 21:58, Walter Bright wrote: Should be up now. Yes, thanks. -- /Jacob Carlborg
Re: LogLevel [was std.experimental.logger formal review round 3]
On 2014-12-04 02:10, Martin Nowak wrote: I just found a very compelling alternative solution to the LogLevel disabling problem. This was one of the reasons for the delay of std.log and the current solution still isn't great [1]. This idea here achieves - fine grained control over log levels (per module/package) - zero overhead for statically disabled log levels - zero (almost) boilerplate (works even with the global stdlog) - and it establishes a nice convention to enable logging for a library `pkg.logLevel = LogLevel.info;` Basically it works by declaring a logLevel in a module or package. Then the std.logger module does a reverse lookup of that declaration. This is kind of cool that you can do in D, but it feels like a hack. I have stopped following the std.log thread, could you summarize what issues you're having and trying to solve and why not a more obvious solution doesn't work? -- /Jacob Carlborg
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 12/4/2014 12:12 AM, Jacob Carlborg wrote: On 2014-12-03 21:58, Walter Bright wrote: Should be up now. Yes, thanks. welcs
Re: Reference Counting and Static Checker
On Thursday, 4 December 2014 at 06:24:35 UTC, Suminda Dharmasena wrote: What I am saying is, if it is introduced in D it should be more flexible than Rust. This isn't the first post of you who makes me think that you're a troll but I'll answer anyway. Having types for static memory safety analysis is, by definition, not transparent and not flexible either, so it's unlikely that if D ever implements this feature it will be much different from what Rust provide. There can still be interesting differences (syntax), scope (Rust use block scope currently but this will probably change), but they are quite minor..
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 01:10:43 UTC, Martin Nowak wrote:
```d
module mypkg.foo.bar;
public import mypkg.logLevel;
void baz(T)(T t)
{
info("baz");
}
```
Not bad. Does info="baz" compile?
DIP69 - Implement scope for escape proof references
http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one.
Re: DIP69 - Implement scope for escape proof references
On Thu, 04 Dec 2014 01:24:13 -0800
Walter Bright via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP69
>
> Despite its length, this is a fairly simple proposal. It adds the missing
> semantics for the 'scope' storage class in order to make it possible to pass
> a
> reference to a function without it being possible for it to escape.
>
> This, among other things, makes a ref counting type practical. It also makes
> it
> more practical to use other storage allocation schemes than garbage
> collection.
>
> It does not make scope into a type constructor, nor a general type-annotation
> system.
>
> It does not provide an ownership system, though it would complement one.
cosmetic issue: some comments are referring to rules by number ("Error,
rule 5"), yet the rules aren't explicitly numbered. not a big deal, but
still somewhat hard to follow.
signature.asc
Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. Making it implicit and requiring an explicit "escape" for un-scoped variables?
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
cosmetic issue: some comments are referring to rules by number ("Error,
rule 5"), yet the rules aren't explicitly numbered. not a big deal, but
still somewhat hard to follow.
Yeah, still learning wiki markup!
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 1:51 AM, eles wrote: On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. Making it implicit and requiring an explicit "escape" for un-scoped variables? Was afraid that would break too much code.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote:
On 12/4/2014 1:51 AM, eles wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright
wrote:
http://wiki.dlang.org/DIP69
Was afraid that would break too much code.
An annotation for functions could make all variables "scope"?
Similar to:
int foo(int x) @scopedvars {
//all declarations are implicit "scope"; use "escape" for the
others
}
Re: DIP69 - Implement scope for escape proof references
On Thu, 04 Dec 2014 10:04:07 +
eles via Digitalmars-d wrote:
> On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote:
> > On 12/4/2014 1:51 AM, eles wrote:
> >> On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright
> >> wrote:
> >>> http://wiki.dlang.org/DIP69
>
> > Was afraid that would break too much code.
>
> An annotation for functions could make all variables "scope"?
>
> Similar to:
>
> int foo(int x) @scopedvars {
> //all declarations are implicit "scope"; use "escape" for the
> others
>
> }
please, don't steal this nice identifier! i love variables with name
"escape"! stolen "body" still hurts me.
signature.asc
Description: PGP signature
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg wrote: On 2014-12-04 02:10, Martin Nowak wrote: I just found a very compelling alternative solution to the LogLevel disabling problem. This was one of the reasons for the delay of std.log and the current solution still isn't great [1]. This idea here achieves - fine grained control over log levels (per module/package) - zero overhead for statically disabled log levels - zero (almost) boilerplate (works even with the global stdlog) - and it establishes a nice convention to enable logging for a library `pkg.logLevel = LogLevel.info;` This is kind of cool that you can do in D, but it feels like a hack. I have stopped following the std.log thread, could you summarize what issues you're having and trying to solve and why not a more obvious solution doesn't work? Zero overhead for statically disabled log levels. The current proposal uses global version identifiers to alter the behavior of std.logger. Fine grained (at least per library) control over log levels. The current proposal required to use different logger wrappers in each library and scoped global version identifiers, see [1] in the OP.
Re: DIP69 - Implement scope for escape proof references
thank you for pushing on this. Lifetime last bullet point: ", but lower than any variables in higher scopes." isn't that redundant to the first bullet point? Or am I missing something? Scope affects variables according to these rules: Could you enumerate the list instead of bullet points, I can't count. Base operation: That one I don't get. I would assume this is legal as the function is not @safe. e = &c; // Error, lifetime(e's view) is ∞ and is greater than lifetime(c)
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 08:42:36 UTC, Kagamin wrote: Not bad. Does info="baz" compile? That's not my business, if it's callable with a single argument, it would work, but it's not @property.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 10:11:25 UTC, ketmar via Digitalmars-d wrote: On Thu, 04 Dec 2014 10:04:07 + eles via Digitalmars-d wrote: On Thursday, 4 December 2014 at 10:00:37 UTC, Walter Bright wrote: > On 12/4/2014 1:51 AM, eles wrote: >> On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright >> wrote: please, don't steal this nice identifier! i love variables with name "escape"! stolen "body" still hurts me. It was just an idea, I do not push for it.
Re: LogLevel [was std.experimental.logger formal review round 3]
That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ "_loggerinfo.d" and then describe the import constraint in the documentation.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. Haven't got the time to look at this in detail right now, but if it's as good as it looks on the surface, I'm very excited to use it. Thanks for all the hard work, all involved.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 10:16:52 UTC, Martin Nowak wrote: On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg hack. I have stopped following the std.log thread, could you summarize what issues you're having and trying to solve and why not a more obvious solution doesn't work? Zero overhead for statically disabled log levels. The current proposal uses global version identifiers to alter the behavior of std.logger. Fine grained (at least per library) control over log levels. The current proposal required to use different logger wrappers in each library and scoped global version identifiers, see [1] in the OP. I like the direction you are taking, but I think the better solution is to have: 1. A manifest/config file where you configure these and other settings in a uniform manner. 2. Provide support for configurations and switching between configurations at realtime. 3. Compiler support for the manifest file that allows library code to query it at compile time as well as generating bitfields for real time switching between configurations. (Just memcpy to change configuration) 4. Have logInfo(…) etc as always inlined stubs. 5. Have one bit per log level (32 should be sufficient), rather than a number. 6. Allow for compiler profiling so that bits in the configuration that are accessed together become co-located on the same word/64 bytes cacheline. Something like this: href="file://var/myfile.txt"/>
Re: LogLevel [was std.experimental.logger formal review round 3]
As I have explained countless times, the configuration in source and through inheritance will always be more powerful and flexible than a config file. I'm not gone create any config file support, as there will be always one feature missing and there is just no way to anticipate all possible configuration requirements. So one shouldn't even try.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ "_loggerinfo.d" and then describe the import constraint in the documentation. Good idea, that would work for libraries (dub packages) where adding a single module is cheap. It's a bit annoying for script like D usage so I'd only do this optionally. But then the compiler would hit the hard disk every time you call log, trying to find that non-present module, so maybe it's simpler and more transparent to always only look in the calling context.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner Schadek wrote: As I have explained countless times, the configuration in source and through inheritance will always be more powerful and There is no contradiction. Configuration is level 1, implementation is level 2.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 10:44:22 UTC, Ola Fosheim Grøstad wrote: I like the direction you are taking, but I think the better solution is to have: It's a nice idea for generic feature testing flags, but it's a lot of implementation work in the compiler. And it seems odd to implement a big part of a library in the compiler.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ "_loggerinfo.d" and then describe the import constraint in the documentation. Importing a different module wouldn't reliably work, when file paths differ from module paths. The nice thing about importing __MODULE__ is that the compiler already knows it, because it's the caller. Also importing a different file by name feels a bit too much like magic ruby bindings.
Re: DIP69 - Implement scope for escape proof references
Errors for scope violations are only reported in @safe code. Why? If I've explicitly designated a reference as scope, why should it be ignored in un-@safe code?
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:02:39 UTC, Martin Nowak wrote: It's a nice idea for generic feature testing flags, but it's a lot of implementation work in the compiler. And it seems odd to implement a big part of a library in the compiler. I think D lacks a generic project configuration mechanism. I generally want configurations to be located in one or at least a few files that are easy to modify and which can have tools written for them. So yes, this should not be written for logger alone. I don't know how much work it is for the compiler, but I suspect a lot of it could be written as a compiler extension in D that communicates with the C++ compiler core. It would be very useful for server programmers to be able to swap configuration for the whole program on a live server when you detect a problem. Third parties could create a GUI tool for managing configuration settings with automatic transfer of new bitpatterns over tcp/udp, or even automatic rebuilds.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 11:21:27 UTC, Marc Schütz wrote:
Errors for scope violations are only reported in @safe code.
Why? If I've explicitly designated a reference as scope, why
should it be ignored in un-@safe code?
Agreed, it should also work for any other code with some function
to cast away scope.
ref T unscope(scope ref T t) @system
{
auto p = &t;
return *p;
}
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Great stuff.
Will this be possible, it's a fairly important use-case.
scope ref T setVal(scope ref T t)
{
t.val = 12;
return t;
}
Another question, how would a reference counted pointer take
advantage of scope, i.e. avoid the increment/decrement when being
passed to a function?
One solution would be to add a function that returns a scoped
reference to the underlying value.
struct RefCounted(T)
{
scope ref T borrow() { return *p; }
}
Will it be possible to deduce, that the lifetime of that scoped
value is tied to the smart pointer?
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:02:23 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner Schadek wrote: As I have explained countless times, the configuration in source and through inheritance will always be more powerful and There is no contradiction. Configuration is level 1, implementation is level 2. Either I don't see your point or you didn't see mine.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:49:53 UTC, Ola Fosheim Grøstad wrote: I think D lacks a generic project configuration mechanism. I generally want configurations to be located in one or at least a few files that are easy to modify and which can have tools written for them. So yes, this should not be written for logger alone. I think D lacks a good std.serialization module
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:12:02 UTC, Martin Nowak wrote: On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ "_loggerinfo.d" and then describe the import constraint in the documentation. Importing a different module wouldn't reliably work, when file paths differ from module paths. The nice thing about importing __MODULE__ is that the compiler already knows it, because it's the caller. Also importing a different file by name feels a bit too much like magic ruby bindings. Well, the static if mixin stuff also a bit like magic. How do you suggest do we solve the dependency cycle? Anyway, the code you showed needs a default case where there is no LogLevel defined and no parent is left.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 12:16:54 UTC, Robert burner Schadek wrote: I think D lacks a good std.serialization module That would be a good point if you did binary logging…
D Meetup in Berlin
Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 How inout fits the picture? It has some scope semantics too. Section about expressions suggests you will tack scoping carefully, but then why would you need return by ref tricks, which don't rely on scope tracking and hence look hackable?
Re: DIP69 - Implement scope for escape proof references
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Despite its length, this is a fairly simple proposal. It adds
the missing semantics for the 'scope' storage class in order to
make it possible to pass a reference to a function without it
being possible for it to escape.
Looks pretty solid, but I have one question based on the
following two statements:
1) "Scope is inferred for function parameters if not specified,
under the same circumstances as pure, nothrow, @nogc and safety
are inferred."
2) "Scope is covariant, meaning it can be added to overriding
functions."
How would this be handled in the current proposal?
class C
{
int bar(ref T); // <-- inferred to be scope
}
class D : C
{
override int bar(ref T); // <-- inferred to be NOT scope (but
cannot remove scope when overriding)
}
Re: DIP69 - Implement scope for escape proof references
I am not expert in such things, but here are few comments and
questions.
Errors for scope violations are only reported in @safe code.
This seems acceptable only if the compiler switch "-scope"
implies functions to be @safe by default and @system on request,
because currently lot of D programmers don't apply annotations
like @safe to their D code. Opt-in safety doesn't work well (and
in D we still have the problems caused by null pointers and
references).
- - - - - - - - - -
Also consider an annotation like "!scope" or "@escape" for the
opposite purpose.
- - - - - - - - - -
Delegates currently defensively allocate closures with the GC.
Few actually escape, and with scope only those that actually
escape need to have the closures allocated.<
So there's no need for extra annotations to make delegates @nogc
in most cases?
- - - - - - - - - -
Regarding array literals, some people proposed a syntax for
fixed-size arrays to avoid heap-allocations (the "s" after the
array literal):
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Is DIP69 able to infer those arrays can be both stack-allocated?
Is the "s" annotations still useful?
- - - - - - - - - -
Regarding the benefits, is escape analysis going to be used to
allocate _automatically_ some small dynamic arrays and
classes/structs on the stack instead of heap?
And is escape analysis going to automatically give hints to the
GC to deallocate faster GC-allocated memory that doesn't escape?
void foo() {
// Both dynamic arrays don't escape foo
// Automatically stack allocated.
auto a = new int[3];
// Heap-allocated but deterministically
// deleted at the end of foo scope.
auto b = new int[10_000];
}
- - - - - - - - - -
Bye,
bearophile
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben. Hi, another Sociomantic developer checking in. This sounds like a great idea, I will definitely be there.
Do everything in Java…
It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on." http://www.teamten.com/lawrence/writings/java-for-everything.html -- 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 signature.asc Description: This is a digitally signed message part
Re: DIP69 - Implement scope for escape proof references
How would this be handled in the current proposal?
class C
{
int bar(ref T); // <-- inferred to be scope
}
class D : C
{
override int bar(ref T); // <-- inferred to be NOT scope (but
cannot remove scope when overriding)
}
Attribute inference only works for function literals and template
functions. So no inference is done for both methods. Template
methods can not be overwritten.
Re: D support in Exuberant Ctags 5.8 for Windows
On 03/12/2014 23:02, Martin Nowak wrote: On 11/27/2014 10:30 AM, Gary Willoughby wrote: There seems to be an effort to resurrect ctags[1] so i've taken the D language support from this patch and applied it to the newly resurrected ctags. [1]: https://github.com/fishman/ctags How about making turning it into a pull request? It's been merged into fishman/ctags: https://github.com/fishman/ctags/pull/133 I'll be submitting a supplementary pull, but that shouldn't stop anyone else from contributing who wants to. My understanding of ctags is not that great.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. A fun read, and I see his POV. It is a pity Python does not include some static typing, but I think he undervalues the access to a REPL! I think Swift is being a bit innovative here by having a REPL built into the debugger. Good move, wish I had a project that was suitable for it (but requiring ios8 makes it DOA for now). For speed… I dunno. In the cloud you can run Python on 10 instances with little effort, so 10x faster is often not so important if development is slower. Cloud computing has changed my perception of speed: if you can partition the problem then Python is fast enough for low frequency situations… I think the main benefit of prototype based dynamic languages like javascript is forward-compatibility and mixed type containers. By being able to "patch" the prototype you can make IE9 support new functionality by emulating newer features like "classList"… That's pretty nice. Java on the browser turned out to be a disaster… This stood out for me: !…other languages like D and Go are too new to bet my work on." I did not find that odd, they are not perceived as stable and proven. Go is still working on finding the right GC solution.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on." http://www.teamten.com/lawrence/writings/java-for-everything.html I stand by him. Since 2004, our projects are either pure Java stacks or .NET stacks depending on the customer. When people compare new languages against Java, .NET and friends they always forget how rich the eco-systems are in terms of tooling. Go, D and Rust might win over the poor tooling C and C++ developers have, but not over the richness Java and .NET worlds enjoy in application monitoring, IDEs and libraries. Now with Java and .NET official SDKs supporting AOT compilation, instead of forcing developers to buy commercial AOT compilers, the eco-systems are even better. This is why, at least on my area of work, enterprise consulting. It is very hard to sell alternatives to the JVM and .NET eco-systems, like D. It is a world that has left C++ in the mid-2000 and fully embraced GC based languages and their eco-systems. Being just better than C++ isn't enough. -- Paulo
Re: On heap segregation, GC optimization and @nogc relaxing
Finally got a look at your proposal. While I do agree with many initial statements and, specifically, proposal for heap segregation, proposed semantics of `owned` does leave me skeptical. It is effectively a more refined/mature approach to "cooking of immutables" concept and Marc proposal, while being more complicated semantic-wise, allows for much more than that.
Re: Would you trade 0.1% in performance for a better debugging experience?
I think it is a better default, at least in absence of multiple release flavors.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 14:12:34 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. A fun read, and I see his POV. It is a pity Python does not include some static typing, but I think he undervalues the access to a REPL! I think Swift is being a bit innovative here by having a REPL built into the debugger. Good move, wish I had a project that was suitable for it (but requiring ios8 makes it DOA for now). For speed… I dunno. In the cloud you can run Python on 10 instances with little effort, so 10x faster is often not so important if development is slower. Cloud computing has changed my perception of speed: if you can partition the problem then Python is fast enough for low frequency situations… I rather pay for just one instance. Honestly, I could never see an use for Python outside shell scripting. And I was an heavy user of it during my stay at CERN, and later companies, for build and test automation.
Re: New std.range submodule
I disagree that `traits` and `constraints` are the same. Constraint is a specific case of a trait which returns boolean value and has semantical from of `isSomething`. Trait is pretty much any static reflection utility, whatever it does.
Mathematical formulae in documentation / Mathjax
Hi, MathJax is a Javascript trick that can nicely typeset mathematical equations written in TeX, on-the-fly, in any HTML document. Enabling it is easily done by adding some in the , which I managed to do by overriding DDOC. However, if I have a piece of code like /// Return \(x^2\) int square(int x) dmd -D produces Return \(x\) Mathjax searches for \( ... \) in the page and then typeset as if it was written in TeX it but here it does not recognise and gives up. Editing DDOC_PARAM is not an option of course. Is there a way around? Thanks in advance!
Re: LogLevel [was std.experimental.logger formal review round 3]
"Martin Nowak" wrote in message news:m5ocaj$2i8t$1...@digitalmars.com... I just found a very compelling alternative solution to the LogLevel disabling problem. This was one of the reasons for the delay of std.log and the current solution still isn't great [1]. This idea here achieves - fine grained control over log levels (per module/package) - zero overhead for statically disabled log levels - zero (almost) boilerplate (works even with the global stdlog) - and it establishes a nice convention to enable logging for a library `pkg.logLevel = LogLevel.info;` Basically it works by declaring a logLevel in a module or package. Then the std.logger module does a reverse lookup of that declaration. FWIW I don't really like this - it feels like a hack. I'd rather just declare a private logger alias (or something like that) and use that in the library. Decision can be made at compile time, doesn't require reverse module imports, doesn't depend on global versions. eg alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info);
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 13:10:20 UTC, Stefan wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. Hi, another Sociomantic developer checking in. This sounds like a great idea, I will definitely be there. I would be totally in but unfortunately I won't be in Berlin at the time. I hope it goes well and there is another meetup soon! :-)
Re: Do everything in Java…
On Thursday, 4 December 2014 at 14:25:52 UTC, Paulo Pinto wrote: I rather pay for just one instance. That depends. What makes Go and Python attractive on AppEngine is the fast spin up time, you only pay for 15 minutes, and it scales up to 100 instances transparently. With java you need multiple idle instances 24/7 because the spin up is slow. Honestly, I could never see an use for Python outside shell scripting. Not having static typing is a weakness, but not as bad as I thought it would be when you learn how to deal with it. Dropbox likes Python enough to develop a JIT for it according to this blog: https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/ So I'd say it all depends.
Re: DIP69 - Implement scope for escape proof references
"Walter Bright" wrote in message news:m5p99m$luk$1...@digitalmars.com... http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. This looks really good. Nice work.
Re: Would you trade 0.1% in performance for a better debugging experience?
On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote: I think it is a better default, at least in absence of multiple release flavors. I don't think it's going to happen. The arguments would need to overrule Walter Bright and Martin Nowak (effectively Druntime's current maintainer). Plus, there's Rainer's benchmark results, which show a different figure. I think I'm going to keep improving Digger instead, to the point that the default build flags become of little importance.
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 4:24 AM, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. "There can be at most one owner for any piece of data." This doesn't seem right. For GC data, the GC owns the data, that is true. But for Ref-counted data, there is more than one owner, and only when all the owners disown the data can it be destroyed. I think there is a disconnect here, you can't say *nobody* owns the data, and if you say one variable owns the data, which one is it? Continuing to read... -Steve
Re: Do everything in Java…
On Thursday, 4 December 2014 at 14:40:10 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 December 2014 at 14:25:52 UTC, Paulo Pinto wrote: I rather pay for just one instance. That depends. What makes Go and Python attractive on AppEngine is the fast spin up time, you only pay for 15 minutes, and it scales up to 100 instances transparently. With java you need multiple idle instances 24/7 because the spin up is slow. Honestly, I could never see an use for Python outside shell scripting. Not having static typing is a weakness, but not as bad as I thought it would be when you learn how to deal with it. Dropbox likes Python enough to develop a JIT for it according to this blog: https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/ So I'd say it all depends. PyPy has now 10 year of research spent into it, and it still doesn't support all Python features. I am aware of Dropbox efforts. Lets see if they go Unladen Swallow direction or not.
Re: Phobos - breaking existing code
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote: Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago. I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today. I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old. I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better. We have deprecation cycle of one year. Expecting unmaintained application to compile after 2 years has passed is completely unreasonable. Almost every single D program out there breaks with _each_ DMD release, Phobos deprecations are least of all evils there. Try fixing that before complaining about #breakmycode Also it feels like you consider D at stable version. It isn't. There is a huge amount of work to be done before it can be considered even honest 1.0.0 - doing something with scope, finishing @nogc / rc attempts, cleaning up qualifier mess etc. Once it is all done, maybe (maybe!) we can talk about stability. Right now it is a fallacy.
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 4:24 AM, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. "Scope affects: local variables allocated on the stack" ... "scope int i; // scope is ignored because integers are not references and so are not views" I think I understand what you are trying to say -- the (big S) Scope of a local variable cannot escape, but it serves no purpose to declare a local int as (keyword) scope, since it's not going to be assigned any references. But it reads contradictory. -Steve
Re: DIP69 - Implement scope for escape proof references
"There can be at most one owner for any piece of data." This doesn't seem right. For GC data, the GC owns the data, that is true. But for Ref-counted data, there is more than one owner, and only when all the owners disown the data can it be destroyed. I think there is a disconnect here, you can't say *nobody* owns the data, and if you say one variable owns the data, which one is it? Continuing to read... -Steve It is in line with this definition A variable owns the data it contains if, when the lifetime of the variable is ended, the data can be destroyed. and the definiton of the lifetime of a variable The lifetime of variables is based purely on their lexical scope and order of declaration. The following rules define a hierarchy of lifetimes: A variable's lifetime starts at the point of its declaration, and ends with the lexical scope it is defined in. An (rvalue) expression's lifetime is temporary; it lives till the end of the statement that it appears in. The lifetime of A is higher than that of B, if A appears in a higher scope than B, or if both appear in the same scope, but A comes lexically before B. This matches the order of destruction of local variables. The lifetime of a function parameter is higher than that of that function's local variables, but lower than any variables in higher scopes. Because the lifetimes of any two variables are different by this definition and the definition of ownership links to variable lifetime, only one variable can own the data. So if you have multiple ref-counted slices to an array, no one owns the array until the ref-count goes down to 1. Question remains, if this is a definition of ownership we want to employ. There can be at most one owner for any piece of data.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 15:04:44 UTC, Paulo Pinto wrote: On Thursday, 4 December 2014 at 14:40:10 UTC, Ola Fosheim Grøstad wrote: PyPy has now 10 year of research spent into it, and it still doesn't support all Python features. Armin Rigo is a smart guy, but well, some things are really a no-way in python. --- Paolo
Re: Phobos - breaking existing code
On Monday, 1 December 2014 at 02:44:24 UTC, Walter Bright wrote: D's module system is very good at avoiding name collisions, and dealing with them when they do arise. Really laughed here. dstep got broken when going from 2.065 to 2.066 exactly because new symbol was added to object.d and it clashed with one defined in application. Very good in avoiding name collisions, right.
Re: Symbol lookup rules and imports
On Tuesday, 2 December 2014 at 22:02:23 UTC, H. S. Teoh via Digitalmars-d wrote: However, there are major issues with scoped imports currently, that make this otherwise ideal solution less-than-ideal, which stem from the way 'import' is implemented in D. When the compiler encounters an 'import' statement, what it essentially does is to parse the symbols in the target module, and add them to the symbol table for the current scope. This is probably single thing I hate most about D module system. Especially the fact that it is default behaviour with plain "import". I wish all symbols required to be force-qualified with a module by default :(
Re: D Meetup in Berlin
I would like to take part, i won't be in the area at that time. Hoping for the next time. On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben.
Re: Symbol lookup rules and imports
On Wednesday, 3 December 2014 at 13:34:42 UTC, Jacob Carlborg wrote: On 2014-12-02 23:00, H. S. Teoh via Digitalmars-d wrote: I'm finding it harder and harder to accept Walter's stance that symbol lookups should be kept simple and free from complications and convoluted corner cases, etc.. Except that it is *already* full of convoluted pitfalls and corner cases you must avoid, as illustrated above. I wish we would just acknowledge that the current symbol lookup / import rules (or at least the implementation thereof) are inadequate, and find a clean solution to this long-standing issue, instead of hoping that denying the problem will somehow, magically, make it all go away. I fully agree. +1 So far it seems there is huge amount of anecdotal evidence that D module system does not work as designed and people keep inventing hacks and workaround to get over it. And yet Walter still considers it success. Well, compared to C includes - no doubt. Compared to actually usable modle system.. meh. Right now it pretty much requires relying on coding discipline and custom rules for import formatting.
Re: DIP69 - Implement scope for escape proof references
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) > lifetime(bar())
I'm trying to understand how foo can be implemented in any case. It has
no scope ints to return, so where does it get the int from?
I don't see where the proposal defines what exactly can be returned via
scope.
Another thing I saw early on:
void abc() {
scope int* a;
int* b;
scope ref int* c = a; // Error, rule 5
scope ref int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) < lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) < lifetime(global_ptr)
int* j;// Ok, scope is inferred for i
global_ptr = j;// Ok, j is not scope
}
Does this mean ref can now be applied to a variable?
I'm not sure what the difference between scope ref and scope is. is d
defined as a reference to b, or is d defined as a new variable that is
initialized to what b points at (a la C++ &) ?
-Steve
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Sounds great, wanted to initiate that myself for quite a while, but lacked the time to do so. Lot of people use http://www.meetup.com/, maybe that would get us some more visitors.
Re: Need help deciphering posix.mak
Please no additional 3d-party dependencies for D core tool stack.
Re: Would you trade 0.1% in performance for a better debugging experience?
On Thursday, 4 December 2014 at 14:39:07 UTC, Vladimir Panteleev wrote: On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote: I think it is a better default, at least in absence of multiple release flavors. I don't think it's going to happen. The arguments would need to overrule Walter Bright and Martin Nowak (effectively Druntime's current maintainer). Plus, there's Rainer's benchmark results, which show a different figure. I think I'm going to keep improving Digger instead, to the point that the default build flags become of little importance. I am not going to fight over this (not _that_ important) but it is a sad mistake. Providing plesant out of the box experience is more important that perfect out of the box performance.
Re: 2 types of D users, both can live together happily if we adjust
It is all solved by semver and release discipline - something language authors are strongly against.
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 10:06 AM, Tobias Pankrath wrote: So if you have multiple ref-counted slices to an array, no one owns the array until the ref-count goes down to 1. Question remains, if this is a definition of ownership we want to employ. This is like saying you have multiple owners :) I don't see the reason to avoid that. It's not like you can't define the owners when there are multiple references. Only one of them will end up destroying the variable, but it's not some other entity that will do it, you have a clear definition of who the owners are. -Steve
Re: DIP69 - Implement scope for escape proof references
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Perhaps better:
void foo(int[2]) {}
void bar(scope int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Bye,
bearophile
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 15:29:58 UTC, Martin Nowak wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Sounds great, wanted to initiate that myself for quite a while, but lacked the time to do so. Lot of people use http://www.meetup.com/, maybe that would get us some more visitors. We thought of at first targeting more towards the existing community. Then see how it goes and if there is momentum and interest in doing a more open event, hosting a few talks, some of them targeted as non-D users. I think that kind of event might be more suitable to announce in http://www.meetup.com/. But we are open to other ideas too I think (I don't want to talk in Ben's behalf ;-).
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 13:10:20 UTC, Stefan wrote: On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Hi All, I am a Berlin based D developer who has been working with D for about 2 and a half years. Like other more well known names in these forums I work for a company called Sociomantic. I am interested in organizing some meetups for D programmers in the nearby area. The first of these will be very informal and involve a social meeting at a cafe or bar to chat and gauge any interest in future events and in what direction people think these should head. I was thinking of arranging this for mid January next year but am very flexible on the dates. Let me know if you are interested in taking part in this or any future Berlin based events. Thanks, Ben. Hi, another Sociomantic developer checking in. This sounds like a great idea, I will definitely be there. One more sociomantic developer here is joining as well. Glad that we finally got that going.
Re: Would you trade 0.1% in performance for a better debugging experience?
Why when an DMD developer said « no » to you in ticket you go to the forum and troll there ? If one wants debug information he will use debug version of phobos. In fine-tune application there's no need for -gs flag.
Re: D Meetup in Berlin
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote: Let me know if you are interested in taking part in this or any future Berlin based events. Count me in!
Re: Do everything in Java…
On 12/4/14, 10:47 AM, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on." http://www.teamten.com/lawrence/writings/java-for-everything.html Very interesting read. But the world of humans still has time to grow and evolve, and humans always try to do better, you can't stop that. He says Java is verbose and "so what?". Well, couldn't it be less verbose and still be that good? Could you be very DRY (Don't Repeat Yourself) in a language that's statically typed, but with good type inference and very good performance, superior to those of VM languages? Yes, you can. You shouldn't stop there. OK, use Java now, but don't stop there. Try to think of new ideas, new languages. At least as a hobby. If Python makes you happy and Java not, but Java gets the work done, who cares? I don't want to spend my time in the world being unhappy but doing work (which probably isn't for my own utility, and probably isn't for anyone's *real* utility), I'd rather be happy. Just my 2 cents :-)
Re: Do everything in Java…
On 12/4/14, 2:11 PM, Ary Borenszweig wrote: On 12/4/14, 10:47 AM, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on." http://www.teamten.com/lawrence/writings/java-for-everything.html Very interesting read. But the world of humans still has time to grow and evolve, and humans always try to do better, you can't stop that. He says Java is verbose and "so what?". Well, couldn't it be less verbose and still be that good? Could you be very DRY (Don't Repeat Yourself) in a language that's statically typed, but with good type inference and very good performance, superior to those of VM languages? Yes, you can. You shouldn't stop there. OK, use Java now, but don't stop there. Try to think of new ideas, new languages. At least as a hobby. If Python makes you happy and Java not, but Java gets the work done, who cares? I don't want to spend my time in the world being unhappy but doing work (which probably isn't for my own utility, and probably isn't for anyone's *real* utility), I'd rather be happy. Just my 2 cents :-) Like, cool, Java helped Twitter improve their search engine. Yes, Twitter has some real value for the humanity.
Re: Do everything in Java…
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via Digitalmars-d wrote: It's an argument for Java over Python specifically but a bit more general in reality. This stood out for me: !…other languages like D and Go are too new to bet my work on." http://www.teamten.com/lawrence/writings/java-for-everything.html This crap is told so often it is not even interesting anymore.
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 01:57:43AM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
> >cosmetic issue: some comments are referring to rules by number
> >("Error, rule 5"), yet the rules aren't explicitly numbered. not a
> >big deal, but still somewhat hard to follow.
>
> Yeah, still learning wiki markup!
I don't understand the line where rule 5 was invoked:
scope int* a;
...
scope int** f = &a;// Error, rule 5
Why is it an error, since f has a shorter lifetime than a? And what has
it gotta do with rule 5, which currently reads:
A scope ref variable can be initialized with another scope ref
variable - scope ref is idempotent.
?
T
--
Real men don't take backups. They put their source on a public
FTP-server and let the world mirror it. -- Linus Torvalds
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 10:31:07AM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Dec 04, 2014 at 01:57:43AM -0800, Walter Bright via Digitalmars-d
> wrote:
> > On 12/4/2014 1:53 AM, ketmar via Digitalmars-d wrote:
> > >cosmetic issue: some comments are referring to rules by number
> > >("Error, rule 5"), yet the rules aren't explicitly numbered. not a
> > >big deal, but still somewhat hard to follow.
> >
> > Yeah, still learning wiki markup!
>
> I don't understand the line where rule 5 was invoked:
>
> scope int* a;
> ...
> scope int** f = &a;// Error, rule 5
>
> Why is it an error, since f has a shorter lifetime than a? And what
> has it gotta do with rule 5, which currently reads:
>
> A scope ref variable can be initialized with another scope ref
> variable - scope ref is idempotent.
>
> ?
[...]
Ah, nevermind, it should be rule 4, not rule 5. Rule 4 states that the
address of scope variables cannot be assigned to another scope variable.
Please fix the comment. ;-)
T
--
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of
thought about your programming problem. In the end they wind up
contributing one or two pieces to the collective wisdom, and fade away
in the rearview mirror. -- Walter Bright
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 01:49:06PM +, Tobias Pankrath via Digitalmars-d
wrote:
> >
> >How would this be handled in the current proposal?
> >
> >class C
> >{
> > int bar(ref T); // <-- inferred to be scope
> >}
> >
> >class D : C
> >{
> > override int bar(ref T); // <-- inferred to be NOT scope (but cannot
> >remove scope when overriding)
> >}
>
> Attribute inference only works for function literals and template
> functions. So no inference is done for both methods. Template methods
> can not be overwritten.
However, AFAIK, template *classes* trigger attribute inference on its
(non-template) member functions, so this would be problematic:
class Base(T) {
T data;
void method(ref T); // inferred to be scope
}
class Derived : Base!int {
override void method(ref T); // oops, cannot override
}
T
--
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 01:24:13AM -0800, Walter Bright via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP69
>
> Despite its length, this is a fairly simple proposal. It adds the
> missing semantics for the 'scope' storage class in order to make it
> possible to pass a reference to a function without it being possible
> for it to escape.
Finally! Thanks for the hard work, looking forward for this to be
implemented (in some shape of form -- see comments below).
> This, among other things, makes a ref counting type practical. It also
> makes it more practical to use other storage allocation schemes than
> garbage collection.
>
> It does not make scope into a type constructor, nor a general
> type-annotation system.
[...]
Can we pretty please use the term "type qualifier" instead of "type
constructor"? ;-)
Anyway, here are a few comments:
1) Why are scope violations only reported for @safe code?? IMO this
greatly limits the usefulness of this DIP. If I mark something as
scope, I'd expect it should be enforced by the compiler regardless of
@safe annotations, otherwise what's the point??
Currently, due to the incompleteness of @safe, it's difficult to use
@safe annotations everywhere I'd like to (e.g. I need to use some
un-@safe Phobos functions that really ought to be @safe, but aren't due
to various reasons, like compiler limitations, etc.). This greatly
limits the usefulness of this DIP, if scope is only enforced in @safe
code!
2) Is there a way to detect if something is marked as scope? If not, how
does this proposal actually enable ref-counted types? (I'm assuming a
library ref-counting type here; or are we expecting further compiler
enhancements for ref counting?)
3) What does scope mean for delegate parameters? To what does the scope
apply, the delegate itself, its body, or its return value, or ...?
struct S {
void opApply(scope void delegate(ref int) loopBody) {
...
// what restrictions (might) apply here w.r.t.
// how loopBody can be called?
}
}
And what would be the effect on the caller's side?
S s;
foreach (i; s) {
// what restrictions (might) apply here?
}
4) Under "Expressions", how does scope interact with overloaded
operators? Do the same rules apply to expressions that use overloaded
operators as they apply to built-in operators, or do they apply as
though the overloaded operators were written out in function-call
syntax? What happens if some overloaded operators take a mix of scope
and non-scope parameters?
Finally, the following isn't directly related to this DIP, since scope
is intended to solve this problem, but I thought I should bring it up.
:-) In the section "escaping via return", 5 points are listed as
sufficient for detecting the "return func(t);" case. The following
section "scope ref" states that these 5 points are "correct" (in
implementing escaping reference detection). However, isn't the following
a loophole?
struct S {
int x;
}
ref int func(ref S s) {
return s.x;
}
ref T foo() {
S s;
return func(s); // escaping reference
}
Since S cannot implicitly convert to int, it would appear that this
circumvents escaping reference detection. (In fact, dmd happily accepts
this code, even if everything is annotated with @safe.) Note that the
escaping reference to x can be arbitrarily deeply nested inside S, so
it's non-trivial to decide whether there's no possibility for references
to (parts of) S to leak from func().
T
--
If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: Need help deciphering posix.mak
04-Dec-2014 18:32, Dicebot пишет: Please no additional 3d-party dependencies for D core tool stack. What are current 3rd-party deps? Dependency on DMC make and compiler is already there, GNU make is not installed by default on FreeBSD. What would you suggest we do? -- Dmitry Olshansky
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 3:21 AM, "Marc Schütz" " wrote: Errors for scope violations are only reported in @safe code. Why? If I've explicitly designated a reference as scope, why should it be ignored in un-@safe code? To interface to code that presents a safe interface, but does things under the hood that can't be verified.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 10:34 AM, H. S. Teoh via Digitalmars-d wrote: Please fix the comment. ;-) done
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 6:58 AM, Steven Schveighoffer wrote: This doesn't seem right. For GC data, the GC owns the data, that is true. But for Ref-counted data, there is more than one owner, and only when all the owners disown the data can it be destroyed. I think there is a disconnect here, you can't say *nobody* owns the data, and if you say one variable owns the data, which one is it? The owner of the refcounted data is the refcounting wrapper - and the wrapper decides when to destroy the payload. (For GC, the "wrapper" is the GC system, which decides to destroy the payload when there are no longer references to it. Just like a ref counting system.)
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 4:55 AM, bearophile wrote:
I am not expert in such things, but here are few comments and questions.
Errors for scope violations are only reported in @safe code.
This seems acceptable only if the compiler switch "-scope" implies functions to
be @safe by default and @system on request, because currently lot of D
programmers don't apply annotations like @safe to their D code. Opt-in safety
doesn't work well (and in D we still have the problems caused by null pointers
and references).
Safety by default is outside of the sco[pe (!) of this discussion. Also, you can
merely put:
@safe:
at the beginning of a module and it is now all safe.
Also consider an annotation like "!scope" or "@escape" for the opposite purpose.
That's part of a more general issue of negation of attributes.
Delegates currently defensively allocate closures with the GC. Few actually
escape, and with scope only those that actually escape need to have the
closures allocated.<
So there's no need for extra annotations to make delegates @nogc in most cases?
Marking delegates as @nogc does not affect the closure, as the closure is
allocated when the enclosing function is entered.
Regarding array literals, some people proposed a syntax for fixed-size arrays to
avoid heap-allocations (the "s" after the array literal):
void foo(int[2]) {}
void bar(int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
Is DIP69 able to infer those arrays can be both stack-allocated? Is the "s"
annotations still useful?
It's an idea worth exploring.
Regarding the benefits, is escape analysis going to be used to allocate
_automatically_ some small dynamic arrays and classes/structs on the stack
instead of heap?
This is an optimization opportunity that scope enables.
And is escape analysis going to automatically give hints to the GC to deallocate
faster GC-allocated memory that doesn't escape?
void foo() {
// Both dynamic arrays don't escape foo
// Automatically stack allocated.
auto a = new int[3];
// Heap-allocated but deterministically
// deleted at the end of foo scope.
auto b = new int[10_000];
}
Another optimization opportunity.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 4:03 AM, Martin Nowak wrote:
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Great stuff.
Will this be possible, it's a fairly important use-case.
scope ref T setVal(scope ref T t)
{
t.val = 12;
return t;
}
Yes, it would be written:
scope ref T setVal(ref T t)
{
t.val = 12;
return t;
}
Another question, how would a reference counted pointer take advantage of scope,
i.e. avoid the increment/decrement when being passed to a function?
One solution would be to add a function that returns a scoped reference to the
underlying value.
struct RefCounted(T)
{
scope ref T borrow() { return *p; }
}
Will it be possible to deduce, that the lifetime of that scoped value is tied to
the smart pointer?
struct RefCounted(T)
{
T t;
scope ref T borrow() { return t; }
alias this t;
}
This enables RefCounted!T to be implicitly converted to a T, but with a scoped
result. This is a critical feature, one I spent a lot of time thinking about,
and hope it's right :-)
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 4:56 AM, Kagamin wrote: On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 How inout fits the picture? It has some scope semantics too. s/inout/ref/ > Section about expressions suggests you will tack scoping carefully, but then why > would you need return by ref tricks, which don't rely on scope tracking and > hence look hackable? Couldn't think of another way.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 7:04 AM, Steven Schveighoffer wrote: "Scope affects: local variables allocated on the stack" ... "scope int i; // scope is ignored because integers are not references and so are not views" I think I understand what you are trying to say -- the (big S) Scope of a local variable cannot escape, but it serves no purpose to declare a local int as (keyword) scope, since it's not going to be assigned any references. But it reads contradictory. If you think that is contradictory, you should have read the earlier drafts :-) Basically, I had to get straight in my head the difference between the scope of the variable and the scope of its payload. The keyword 'scope' only affects the payload.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 7:25 AM, Steven Schveighoffer wrote:
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) > lifetime(bar())
I'm trying to understand how foo can be implemented in any case. It has no scope
ints to return, so where does it get the int from?
Could be from a global variable. Or a new'd value.
I don't see where the proposal defines what exactly can be returned via scope.
The scope return value does not affect what can be returned. It affects how that
return value can be used. I.e. the return value cannot be used in such a way
that it escapes the lifetime of the expression.
Another thing I saw early on:
void abc() {
scope int* a;
int* b;
scope ref int* c = a; // Error, rule 5
scope ref int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) < lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) < lifetime(global_ptr)
int* j;// Ok, scope is inferred for i
global_ptr = j;// Ok, j is not scope
}
Does this mean ref can now be applied to a variable?
scope ref int p = x;
is the same meaning as:
foo(scope ref int p);
foo(x);
as far as what scope ref means. I found it convenient to use scope ref local
variables to describe semantics. Whether we want to actually enable their usage
hinges on if there's a point to it. Technically, it should work.
I'm not sure what the difference between scope ref and scope is. is d defined as
a reference to b, or is d defined as a new variable that is initialized to what
b points at (a la C++ &) ?
Scope refers to the payload. A scope ref is applying scope to the implied ref
pointer. ref works like C++ &.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 10:45 AM, H. S. Teoh via Digitalmars-d wrote:
However, AFAIK, template *classes* trigger attribute inference on its
(non-template) member functions, so this would be problematic:
class Base(T) {
T data;
void method(ref T); // inferred to be scope
}
class Derived : Base!int {
override void method(ref T); // oops, cannot override
}
I agree, it's a good point. Scope inference cannot be done for virtual
functions. I amended the DIP.
Re: DIP69 - Implement scope for escape proof references
On 12/4/2014 11:41 AM, H. S. Teoh via Digitalmars-d wrote:
Can we pretty please use the term "type qualifier" instead of "type
constructor"? ;-)
I think "type constructor" is the more pedantically correct term, but you'll
have to ask Andrei :-)
1) Why are scope violations only reported for @safe code?? IMO this
greatly limits the usefulness of this DIP. If I mark something as
scope, I'd expect it should be enforced by the compiler regardless of
@safe annotations, otherwise what's the point??
Because there are inevitably cases where you'll need to wrap unsafe code with a
safe interface. By screwing this down too tightly for @system code, you'll force
people to use really ugly workarounds.
Currently, due to the incompleteness of @safe, it's difficult to use
@safe annotations everywhere I'd like to (e.g. I need to use some
un-@safe Phobos functions that really ought to be @safe, but aren't due
to various reasons, like compiler limitations, etc.). This greatly
limits the usefulness of this DIP, if scope is only enforced in @safe
code!
Are there bug reports on this?
2) Is there a way to detect if something is marked as scope?
Using __traits(compiles,...) ought to work.
If not, how
does this proposal actually enable ref-counted types? (I'm assuming a
library ref-counting type here; or are we expecting further compiler
enhancements for ref counting?)
The ref counting would be done by a wrapper, which implicitly converts to the
wrappee by exposing a scope ref.
3) What does scope mean for delegate parameters? To what does the scope
apply, the delegate itself, its body, or its return value, or ...?
struct S {
void opApply(scope void delegate(ref int) loopBody) {
...
// what restrictions (might) apply here w.r.t.
// how loopBody can be called?
}
}
Hmmm, looks like a problem I didn't think of. darnit!
And what would be the effect on the caller's side?
S s;
foreach (i; s) {
// what restrictions (might) apply here?
}
i would get its scope inferred as necessary, so restrictions would apply as they
would to a 'scope i'.
4) Under "Expressions", how does scope interact with overloaded
operators? Do the same rules apply to expressions that use overloaded
operators as they apply to built-in operators, or do they apply as
though the overloaded operators were written out in function-call
syntax? What happens if some overloaded operators take a mix of scope
and non-scope parameters?
Overloaded operators are treated like calls to the functions that back them.
Finally, the following isn't directly related to this DIP, since scope
is intended to solve this problem, but I thought I should bring it up.
:-) In the section "escaping via return", 5 points are listed as
sufficient for detecting the "return func(t);" case. The following
section "scope ref" states that these 5 points are "correct" (in
implementing escaping reference detection). However, isn't the following
a loophole?
struct S {
int x;
}
ref int func(ref S s) {
return s.x;
}
ref T foo() {
S s;
return func(s); // escaping reference
}
Since S cannot implicitly convert to int, it would appear that this
circumvents escaping reference detection.
No, because under this proposal, s.x is treated as if it were just s as far a
scope rules are concerned.
(In fact, dmd happily accepts
this code, even if everything is annotated with @safe.)
I know, the current escape detection is quite inadequate - hence this proposal.
Note that the
escaping reference to x can be arbitrarily deeply nested inside S, so
it's non-trivial to decide whether there's no possibility for references
to (parts of) S to leak from func().
This proposal should lock that down.
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 3:41 PM, Walter Bright wrote:
On 12/4/2014 4:03 AM, Martin Nowak wrote:
Will it be possible to deduce, that the lifetime of that scoped value
is tied to
the smart pointer?
struct RefCounted(T)
{
T t;
scope ref T borrow() { return t; }
alias this t;
}
This enables RefCounted!T to be implicitly converted to a T, but with a
scoped result. This is a critical feature, one I spent a lot of time
thinking about, and hope it's right :-)
Hm... did you mean `alias this borrow`?
-Steve
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 12:41:58PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
> struct RefCounted(T)
> {
> T t;
> scope ref T borrow() { return t; }
> alias this t;
> }
>
> This enables RefCounted!T to be implicitly converted to a T, but with
> a scoped result. This is a critical feature, one I spent a lot of time
> thinking about, and hope it's right :-)
Hold on, how does this convert to T with a scoped result? Or did you
mean:
...
@property scope ref T borrow() { ... }
alias borrow this;
?
T
--
Let's call it an accidental feature. -- Larry Wall
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 12:58:56PM -0800, Walter Bright via Digitalmars-d wrote: > On 12/4/2014 7:25 AM, Steven Schveighoffer wrote: [...] > >I don't see where the proposal defines what exactly can be returned > >via scope. > > The scope return value does not affect what can be returned. It > affects how that return value can be used. I.e. the return value > cannot be used in such a way that it escapes the lifetime of the > expression. [...] Ahhh, this certainly clears things up a lot. You should add this explanation to the DIP. T -- Famous last words: I *think* this will work...
Re: DIP69 - Implement scope for escape proof references
On 12/4/14 3:58 PM, Walter Bright wrote:
On 12/4/2014 7:25 AM, Steven Schveighoffer wrote:
int* bar(scope int*);
scope int* foo();
bar(foo()); // Ok, lifetime(foo()) > lifetime(bar())
I'm trying to understand how foo can be implemented in any case. It
has no scope
ints to return, so where does it get the int from?
Could be from a global variable. Or a new'd value.
Well, OK, but why do that?
I don't see where the proposal defines what exactly can be returned
via scope.
The scope return value does not affect what can be returned. It affects
how that return value can be used. I.e. the return value cannot be used
in such a way that it escapes the lifetime of the expression.
I assumed the scope return was so you could do things like:
scope int *foo(scope int *x)
{
return x;
}
which would be fine, I assume, right?
Another thing I saw early on:
void abc() {
scope int* a;
int* b;
scope ref int* c = a; // Error, rule 5
scope ref int* d = b; // Ok
int* i = a;// Ok, scope is inferred for i
global_ptr = d;// Error, lifetime(d) < lifetime(global_ptr)
global_ptr = i;// Error, lifetime(i) < lifetime(global_ptr)
int* j;// Ok, scope is inferred for i
global_ptr = j;// Ok, j is not scope
}
Does this mean ref can now be applied to a variable?
scope ref int p = x;
is the same meaning as:
foo(scope ref int p);
foo(x);
as far as what scope ref means. I found it convenient to use scope ref
local variables to describe semantics. Whether we want to actually
enable their usage hinges on if there's a point to it. Technically, it
should work.
My question was about how this kind of allows declaring a ref variable
in the middle of a function, which was never allowed before.
-Steve
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 01:10:31PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/4/2014 11:41 AM, H. S. Teoh via Digitalmars-d wrote:
> >Can we pretty please use the term "type qualifier" instead of "type
> >constructor"? ;-)
>
> I think "type constructor" is the more pedantically correct term, but
> you'll have to ask Andrei :-)
Recently there was a bug filed by Andrei himself, and a bunch of merged
PRs, that renamed "type constructor" to "type qualifier". The general
sense I got was that we're deprecating "type constructor" in preference
for "type qualifier".
> >1) Why are scope violations only reported for @safe code?? IMO this
> >greatly limits the usefulness of this DIP. If I mark something as
> >scope, I'd expect it should be enforced by the compiler regardless of
> >@safe annotations, otherwise what's the point??
>
> Because there are inevitably cases where you'll need to wrap unsafe
> code with a safe interface. By screwing this down too tightly for
> @system code, you'll force people to use really ugly workarounds.
Are there any use cases for bypassing scope semantics in @system code?
How common are they? Maybe such code *should* look ugly -- to draw
attention to the fact that something un-@safe is going on.
Or perhaps we can make cast() strip away scope? I much rather require
explicit annotation for potentially unsafe operations, than to have
subtle bugs creep into the code just because I forgot to mark something
as @safe.
> >Currently, due to the incompleteness of @safe, it's difficult to use
> >@safe annotations everywhere I'd like to (e.g. I need to use some
> >un-@safe Phobos functions that really ought to be @safe, but aren't
> >due to various reasons, like compiler limitations, etc.). This
> >greatly limits the usefulness of this DIP, if scope is only enforced
> >in @safe code!
>
> Are there bug reports on this?
There are, though probably incomplete, and there's also an ongoing
stream of Phobos PR's for marking things @safe that ought not to be
@system. There's a *lot* of Phobos code that needs to be cleaned up in
this way before this can be workable. (Unless we abuse @trusted as a
temporary workaround -- but that's not an approach I'd like to
recommend!)
> >2) Is there a way to detect if something is marked as scope?
>
> Using __traits(compiles,...) ought to work.
I see.
> >If not, how does this proposal actually enable ref-counted types?
> >(I'm assuming a library ref-counting type here; or are we expecting
> >further compiler enhancements for ref counting?)
>
> The ref counting would be done by a wrapper, which implicitly converts
> to the wrappee by exposing a scope ref.
Just saw your other post on this topic, makes sense.
Still not sure how it would address the RC folks' request for compiler
support, but I suppose that's a different topic.
> >3) What does scope mean for delegate parameters? To what does the
> >scope apply, the delegate itself, its body, or its return value, or
> >...?
> >
> > struct S {
> > void opApply(scope void delegate(ref int) loopBody) {
> > ...
> > // what restrictions (might) apply here w.r.t.
> > // how loopBody can be called?
> > }
> > }
>
> Hmmm, looks like a problem I didn't think of. darnit!
I think it's a fairly important issue, since making this work correctly
will also open up optimization opportunities for a good chunk of
delegate-based code.
> >And what would be the effect on the caller's side?
> >
> > S s;
> > foreach (i; s) {
> > // what restrictions (might) apply here?
> > }
>
> i would get its scope inferred as necessary, so restrictions would
> apply as they would to a 'scope i'.
I was thinking more of what implications may hold in the loop body for
references to (local) variables outside the loop, since that presents
another potential optimization opportunity if we do it right.
> >4) Under "Expressions", how does scope interact with overloaded
> >operators? Do the same rules apply to expressions that use overloaded
> >operators as they apply to built-in operators, or do they apply as
> >though the overloaded operators were written out in function-call
> >syntax? What happens if some overloaded operators take a mix of
> >scope and non-scope parameters?
>
> Overloaded operators are treated like calls to the functions that back
> them.
OK. You might want to state this explicitly in the DIP, just so it isn't
left up to interpretation. :-)
> >Finally, the following isn't directly related to this DIP, since
> >scope is intended to solve this problem, but I thought I should bring
> >it up. :-) In the section "escaping via return", 5 points are listed
> >as sufficient for detecting the "return func(t);" case. The following
> >section "scope ref" states that these 5 points are "correct" (in
> >implementing escaping reference detection). However, isn't the
> >following a loophole?
> >
> > str
Re: DIP69 - Implement scope for escape proof references
On 12/04/2014 09:41 PM, Walter Bright wrote:
Yes, it would be written:
scope ref T setVal(ref T t)
{
t.val = 12;
return t;
}
But when there is no scope on the argument, I could not call setVal with
a local T variable.
Re: DIP69 - Implement scope for escape proof references
On Thu, Dec 04, 2014 at 01:52:09PM -0800, H. S. Teoh via Digitalmars-d wrote: > On Thu, Dec 04, 2014 at 01:10:31PM -0800, Walter Bright via Digitalmars-d > wrote: > > On 12/4/2014 11:41 AM, H. S. Teoh via Digitalmars-d wrote: > > >Can we pretty please use the term "type qualifier" instead of "type > > >constructor"? ;-) > > > > I think "type constructor" is the more pedantically correct term, > > but you'll have to ask Andrei :-) > > Recently there was a bug filed by Andrei himself, and a bunch of > merged PRs, that renamed "type constructor" to "type qualifier". The > general sense I got was that we're deprecating "type constructor" in > preference for "type qualifier". [...] FYI: https://issues.dlang.org/show_bug.cgi?id=13671 T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Re: DIP69 - Implement scope for escape proof references
On 12/04/2014 10:54 PM, Martin Nowak wrote:
On 12/04/2014 09:41 PM, Walter Bright wrote:
Yes, it would be written:
scope ref T setVal(ref T t)
{
t.val = 12;
return t;
}
But when there is no scope on the argument, I could not call setVal with
a local T variable.
Ah, it's inferred. Makes sense now.
Review needed for the wiki - Pascal to D page
"Attack" me on the content of: http://wiki.dlang.org/Coming_From/Delphi This is my user experience about coming from Pascal/Delphi to D.
