Re: Release D 2.073.0
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote: On 1/27/2017 4:43 PM, deadalnix wrote: I mostly went silent on this because I this point, I have no idea how to reach to you and Andrei. This is bad because of all the same reasons inout is bad, plus some other on its own, and is going down exactly like inout so far, plus some extra problems on its own. If you've got a case, make it. If you see problems, explain. If you want to help, please do. I did so repeatedly for years and never reached to you or Andrei, so I'm not sure how that's going to change anything but here you go. The root problem you are trying to solve is to be able to specify that what comes out of a function has a common property with what come in. In the case of inout, this property is the type qualifier, in the case of return/scope this is the lifetime. Same problem, same solution, same fallout.
Re: Release D 2.073.0
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote: If you've got a case, make it. If you see problems, explain. If you want to help, please do. So, do what numerous people have done numerous times already, to no great effect?
Re: Release D 2.073.0
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote: If you've got a case, make it. If you see problems, explain. If you want to help, please do. For what it's worth, here are my problems with 'return scope': - As far as I can tell, it's not properly documented. The github page for DIP-1000 is apparently pending a rewrite, and I can't find a formal definition of 'return scope' anywhere (the D reference 'Functions' page only mentions 'return ref', and in passing). - I personally don't like using the return keyword as anything but an instruction; when I'm reading code, I can have a good feeling of the code's flow by just looking at the indentation, the if/while/for blocks, and the break/throw/return instructions. I'll be the first to admit it's kind of minor though. - It's an obvious monkey patch, and it will clearly have to be replaced at some point. It only addresses cases where a reference might be escaped through a single return value; it doesn't address escaping through 'out' parameters, or through a returned tuple. - It fails to enable useful features like the swap function, or storing a scoped value in a container (well, outside of @trusted code, but that's beside the point). - Because it isn't an integral part of the type system, but more of an external addition, it has a ton of special cases and little gotcha's when you try to do something complex with it. (ref parameters can't be scope, can't have pointers on scope values, which means you can't pass any kind of scope value by reference, you can't have scope types as template parameters, etc) The two last ones feel like the most important problems to me. If all you want to do is variants of the identity function, and returning references to attributes, then return ref and return scope is everything you need (arguably). If you want to store containers of scoped values, swap scope values, and generally treat scope as a first-class citizen, then return scope and return ref seem like a step in the wrong direction. The meta problem people seem to have with 'return scope' seems more of a social problem. Apparently a lot of people feel like you haven't treated their concerns seriously; part of it is that as far as I'm aware there hasn't been a proper, open brainstorming on how to address lifetime analysis in D. My reading of the situation, which may be completely off-base, is that you took inspiration from Marc Schütz's proposal, and wrote something simpler, easier to understand and to code with, and following the model you developed when coming up with inout (no templates, KISS, don't use up too much language complexity estate on an optional feature), then entered a cycle of gradually improving it, eventually making DIP-1000. People who don't like the direction DIP-1000 goes towards are upset because they feel way too much effort is going towards refining an idea they don't agree with in the first place. To speak bluntly, I don't think you've addressed their concerns at all, and I hope you do so before 'scope return' is set in stone. So, do what numerous people have done numerous times already, to no great effect? Please don't be hostile. When you have a communication problem, being passive-aggressive will only makes it worse.
llvm-d 2.0
New major release of `llvm-d` with some backwards-incompatible API changes, please read the release message for the details. Cliffnotes: - Just `import llvm` - Remove `LLVM.load`, (dynamically) link against the appropriate library/libraries - Set a D version `LLVM_Target_XyZ' for every LLVM target 'XyZ' you need. https://github.com/Calrama/llvm-d/releases/v2.0.0 https://code.dlang.org/packages/llvm-d/2.0.0 - Moritz
Re: LDC talk @ FOSDEM'17
On Monday, 23 January 2017 at 19:56:33 UTC, Johan Engelen wrote: Keep me in the loop when preparing your slides! ;-) Thanks for the offer. Expect a version beginning next week. ;-) Regards, Kai
Re: LDC talk @ FOSDEM'17
On Monday, 23 January 2017 at 22:15:57 UTC, David Nadlinger wrote: On Monday, 23 January 2017 at 19:56:33 UTC, Johan Engelen wrote: Great! :-) Keep me in the loop when preparing your slides! ;-) Glad to help out in any way as well. I might also make it to FOSDEM myself this year, but that's not quite sure yet. — David Great! Is there anyone else planning to go to FOSDEM? Regards, Kai
Re: Release D 2.073.0
On 1/28/2017 3:51 AM, deadalnix wrote: I did so repeatedly for years and never reached to you or Andrei, so I'm not sure how that's going to change anything but here you go. By being specific. The root problem you are trying to solve is to be able to specify that what comes out of a function has a common property with what come in. In the case of inout, this property is the type qualifier, in the case of return/scope this is the lifetime. Yup. Same problem, same solution, same fallout. What problem?
Re: D IDE Coedit - version 3 beta 3
On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on?
Re: Release D 2.073.0
On 1/28/2017 6:56 AM, Olivier FAURE wrote: For what it's worth, here are my problems with 'return scope': - As far as I can tell, it's not properly documented. The github page for DIP-1000 is apparently pending a rewrite, and I can't find a formal definition of 'return scope' anywhere (the D reference 'Functions' page only mentions 'return ref', and in passing). Yes, the documentation could be much better, and will be. Like any battle plan doesn't survive the first day of warfare, actually implementing -dip1000 has forced several adjustments. I expect more adjustments will be necessary. One of the larger difficulties is getting code with -dip1000 and without -dip1000 to play together. The bug Dicebot mentioned above is one of those. But this is the sort of problem any such scheme will have to deal with. - I personally don't like using the return keyword as anything but an instruction; when I'm reading code, I can have a good feeling of the code's flow by just looking at the indentation, the if/while/for blocks, and the break/throw/return instructions. I'll be the first to admit it's kind of minor though. There's got to be some added syntax somewhere. I'd love to do it as pure compiler magic. Amazingly, if the code is all templates, that seems to work (the compiler can infer 'return' and 'scope' as necessary there). - It's an obvious monkey patch, All new features of D have to be worked in to existing features with minimal disruption. We're stuck with that reality. and it will clearly have to be replaced at some point. It only addresses cases where a reference might be escaped through a single return value; it doesn't address escaping through 'out' parameters, Yes it does (the general case is storing a value into any data structure pointed to by an argument). or through a returned tuple. Yes it does (it's as if the tuple elements were fields of a struct). In general, the idea is to understand what happens with pointers and values. Then, to understand how X works, reduce X to its constituent pointers and values, and that's how X must work. It's like in electronics you'll get nowhere trying to understand how an amplifier works without thoroughly understand how voltage, current, and resistance works. Understanding the amplifier is built up from that. - It fails to enable useful features like the swap function, or storing a scoped value in a container (well, outside of @trusted code, but that's beside the point). There will be a need for @system code for some things, that is correct. That's also true of Rust, where cyclic data structures have to be marked as unsafe, and functions cannot access mutable global data. Storing a non-trivial data structure in a container is done by hiding the pointers in it with 'private' and providing access via the appropriate member functions. Safely managing memory is done with ref counted objects or GC memory. 'scope return' and 'ref return' allow ref counting containers to return temporary references to their internal data. - Because it isn't an integral part of the type system, but more of an external addition, it has a ton of special cases and little gotcha's when you try to do something complex with it. (ref parameters can't be scope, can't have pointers on scope values, which means you can't pass any kind of scope value by reference, you can't have scope types as template parameters, etc) D is a complex language. There are LOTs of ways pointers can be handed around. Maybe if we throw D away and start over there would be fewer special cases, but we have to work it into the existing semantics. Yes, you cannot express things in D like a pointer to a scope pointer. Time will tell, but in real code I've seen very little need for such things - little enough that it can be handled with @system code. The two last ones feel like the most important problems to me. If all you want to do is variants of the identity function, and returning references to attributes, then return ref and return scope is everything you need (arguably). If you want to store containers of scoped values, swap scope values, and generally treat scope as a first-class citizen, then return scope and return ref seem like a step in the wrong direction. Nobody has come up with a better plan. A Rust-like system would require users to not just add annotations, but redesign all their code and data structures. It's out of the question. The meta problem people seem to have with 'return scope' seems more of a social problem. Apparently a lot of people feel like you haven't treated their concerns seriously; part of it is that as far as I'm aware there hasn't been a proper, open brainstorming on how to address lifetime analysis in D. There has been off and on for about 10 years. Little has come of it. Then came -dip25, which addressed the return ref problem. It worked surprisingly well. There was some severe criticism of it last year as
Re: D IDE Coedit - version 3 beta 3
On Saturday, 28 January 2017 at 22:18:52 UTC, dminded wrote: On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on? Yes. 1/ Do you have a proper GTK2 runtime environment ? Try to verify with this command: pkg-config --modversion gtk+-2.0 2/ If you replace dastworx by this new version, does it still crash ? new version: https://github.com/BBasile/Coedit/releases/download/3_beta_3/dastworx.linux.x86_64.zip 3/ You can try to log the output by launching from a console: coedit > cecession.txt Do 1/ Do 2/, if it still crashes then do 3/
Re: Release D 2.073.0
On Saturday, 28 January 2017 at 22:31:23 UTC, Walter Bright wrote:
It only addresses cases where a reference might be escaped
through a
single return value; it doesn't address escaping through 'out'
parameters,
Yes it does (the general case is storing a value into any data
structure pointed to by an argument).
I don't understand. Let's say I have an arbitrary class
'Container', and I want a function that stores a pointer to an
int in this container, in a way that lets the function's caller
know that the int* given to it will last only as long as the
container, and I want to do it without return values. The
prototype would be akin to
void store(ref Container cont, int*
ptr);
And the code it would be used in would look like:
{
scope Container c;
scope int* ptr = ...;
store(c, ptr);
}
What would the syntax be?
or through a returned tuple.
Yes it does (it's as if the tuple elements were fields of a
struct).
I meant a little more specific. You have no way to do this
Pair!(int*, float*) makePair( int*,
float*);
You can declare them both a scope return, but then their scope is
"merged" into the return value, which may be undesirable if you
want to treat them differently. Although it's not that important,
because this particular case would rarely appear in actual
practical code, unlike swap and out parameters.
There will be a need for @system code for some things, that is
correct. That's also true of Rust, where cyclic data structures
have to be marked as unsafe, and functions cannot access
mutable global data.
Yeah, but cyclic data structures and complex types are one thing.
I'm just talking about having a (scope int*)[] type, and a swap
function. Those should be covered in the scope system, and
shouldn't need GC or RC.
Nobody has come up with a better plan. A Rust-like system would
require users to not just add annotations, but redesign all
their code and data structures. It's out of the question.
There has been off and on for about 10 years. Little has come
of it.
Then came -dip25, which addressed the return ref problem. It
worked surprisingly well. There was some severe criticism of it
last year as being unusable, but those turned out to be
implementation bugs that were not difficult to resolve.
Well, I liked Schultz's original proposal. It seemed easier to
theorize formally, and didn't need major redesign the way Rust's
templates do.
And having read the thread it was proposed in... I didn't see any
brainstorming? It seems to me that dip25 replaced Schult's
proposal without transition, or without debate about the merits
and trade-offs of either proposition, or any rationale explaining
why Schultz's proposition was abandoned.
It's fair if you don't agree with my rationale, but that isn't
the same as not addressing them at all. I believe I have
addressed the issues you brought up here. If you'd like further
clarification, please ask.
I'll probably have more to say on that later, but I think THIS is
the major point of contention. I don't feel like you've addressed
my concerns, because I'm pretty sure you haven't understood my
concerns. You interpreted my remarks as obstacles to be overcome,
not as information I was trying to communicate to you.
I feel like your opinion is that the reason I'm arguing against
dip1000 is that I don't understand it or its context well enough.
I feel you have the same opinion of others people who argue
against the dip. This is what I meant by "not being taken
seriously".
I didn't write that.
Sorry, I was replying another poster above in the thread. I'm not
used to mailing list forums.
Re: Release D 2.073.0
On 1/28/2017 3:56 PM, Olivier FAURE wrote:
Let's say I have an arbitrary class 'Container', and I want
a function that stores a pointer to an int in this container, in a way that lets
the function's caller know that the int* given to it will last only as long as
the container, and I want to do it without return values. The prototype would be
akin to
void store(ref Container cont, int* ptr);
And the code it would be used in would look like:
{
scope Container c;
scope int* ptr = ...;
store(c, ptr);
}
What would the syntax be?
c.ptr = ptr;
You can also do:
ref Container store(ref return scope c, return scope int* ptr);
You can declare them both a scope return, but then their scope is "merged" into
the return value, which may be undesirable if you want to treat them
differently. Although it's not that important, because this particular case
would rarely appear in actual practical code, unlike swap and out parameters.
Yes, the result is the "merged" scope. This issue is a known (discussed
previously on the n.g.) limitation. Is it a significant one? I doubt it, as I
have a hard time contriving a realistic example. Time will tell, though.
And having read the thread it was proposed in... I didn't see any brainstorming?
It seems to me that dip25 replaced Schult's proposal without transition, or
without debate about the merits and trade-offs of either proposition, or any
rationale explaining why Schultz's proposition was abandoned.
The rationale is I was looking for a much simpler scheme. Even -dip25 is a very
simple scheme, and I have a hard time convincing people to use it. What chance
does a complex annotation scheme have?
I'll probably have more to say on that later, but I think THIS is the major
point of contention. I don't feel like you've addressed my concerns, because I'm
pretty sure you haven't understood my concerns. You interpreted my remarks as
obstacles to be overcome, not as information I was trying to communicate to you.
Aren't problems obstacles to be overcome? I don't really understand your point.
You ask me to clarify, I try to clarify. You ask how can this be done, I try to
answer. You say you don't like the syntax, I agree and say I can't find anything
better. You say there's a limitation, I agree and say based on my experience
with it so far it is not a killer limitation.
Please keep in mind we do not have a blank slate. There are serious constraints:
1. dip1000 and non-dip1000 has to coexist
2. cannot ask people to rethink and redesign algorithms and data structures
3. new syntax has to be minimal
4. breaking existing code is unacceptable
5. creating a bondage-and-discipline lifetime tracking annotation system will
not be acceptable to most users
6. using it needs to be opt-in
7. once one tries to implement something, it gets a lot harder than just writing
a spec. Trying to shepherd it through the test suite, Phobos, and existing
projects is not at all straightforward.
Any system has to deal with those things.
Remember the 'const' system introduced in D2 was nearly universally disliked for
years. Over time it has proven its value.
The reason -dip1000 is behind a switch is so it can be developed without
disruption. Dicebot's bug report in this thread is a crack in that, but I'm
working on closing it.
Re: D IDE Coedit - version 3 beta 3
On Saturday, 28 January 2017 at 23:55:58 UTC, Basile B. wrote: On Saturday, 28 January 2017 at 22:18:52 UTC, dminded wrote: On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on? Yes. 1/ Do you have a proper GTK2 runtime environment ? Try to verify with this command: pkg-config --modversion gtk+-2.0 2/ If you replace dastworx by this new version, does it still crash ? new version: https://github.com/BBasile/Coedit/releases/download/3_beta_3/dastworx.linux.x86_64.zip 3/ You can try to log the output by launching from a console: coedit > cecession.txt Do 1/ Do 2/, if it still crashes then do 3/ Thank you. I got it working and Hello World compiles and runs :D. ... I followed the 'Setup program' instructions, but skipped the important point above the heading: "In all the cases, the DMD D2 compiler must setup and its location has to match to one of the directory of the PATH environment variable.". I only had ldc2 installed. After installing dmd coedit did work. After playing around a bit i noticed, that something is wrong with the project management. While the single Hello world compiles and runs, I can not compile a project. i get the following messages: - compiling - has been successfully compiled - output executable missing: /tmp/app I found the compiled 'app' file next to the coedit executable. Also the 'project inspector' seems not to work. When i add files, they are not listed there. Something seems not to be setup properly on my machine.
Re: D IDE Coedit - version 3 beta 3
On Sunday, 29 January 2017 at 01:06:32 UTC, dminded wrote: On Saturday, 28 January 2017 at 23:55:58 UTC, Basile B. wrote: On Saturday, 28 January 2017 at 22:18:52 UTC, dminded wrote: On Friday, 27 January 2017 at 04:48:56 UTC, Basile B. wrote: This would probably have been a RC or even the final version if I hadn't to wait for the development platform I use to reach its next milestone, which may not happen before the next spring, so another beta is worth. All important information, links and other downloads are here: https://github.com/BBasile/Coedit/releases/tag/3_beta_3 You can report any problem here: https://github.com/BBasile/Coedit/issues If you have questions, exactly today, I'll probably be there: irc://irc.freenode.net/d as "DotBatch" I am new to dlang and wanted to try out Coedit. But it does not run on my platform... I tried the zip archive and the installer for the 64-bit version. I am running Linux Mint 18 Cinnamon x86_64. Running "coedit" will log me out of the current session!? Any idea whats going on? Yes. 1/ Do you have a proper GTK2 runtime environment ? Try to verify with this command: pkg-config --modversion gtk+-2.0 2/ If you replace dastworx by this new version, does it still crash ? new version: https://github.com/BBasile/Coedit/releases/download/3_beta_3/dastworx.linux.x86_64.zip 3/ You can try to log the output by launching from a console: coedit > cecession.txt Do 1/ Do 2/, if it still crashes then do 3/ Thank you. I got it working and Hello World compiles and runs :D. ... I followed the 'Setup program' instructions, but skipped the important point above the heading: "In all the cases, the DMD D2 compiler must setup and its location has to match to one of the directory of the PATH environment variable.". I only had ldc2 installed. After installing dmd coedit did work. After playing around a bit i noticed, that something is wrong with the project management. While the single Hello world compiles and runs, I can not compile a project. i get the following messages: - compiling - has been successfully compiled - output executable missing: /tmp/app I found the compiled 'app' file next to the coedit executable. Also the 'project inspector' seems not to work. When i add files, they are not listed there. Something seems not to be setup properly on my machine. I'm on IRC right now. Communication on the forum is really painfull, it looks like I need to explain a few things. Also you can ask questions on the bugtracker, although it's the same problem as here (not real time...).
