Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 I guess the 2017H1 document is quite final now. Why not turn that into a blog post? It could be official (by the leaders) or informal (interview with Andrei).
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 04:02:38 UTC, Jonathan M Davis wrote: On Thursday, January 12, 2017 21:57:37 Andrew Browne via Digitalmars-d- announce wrote: On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: > We release a brief Vision document summarizing the main > goals we plan to pursue in the coming six months. This half > we are focusing on three things: safety, lifetime > management, and static introspection. > > https://wiki.dlang.org/Vision/2017H1 > > > Andrei Is there a design document for how D will achieve safety with nogc? How does D plan to prevent leaks, use-after-free, double-free bugs when not using the GC? Part of the reason that we have the GC in D is because of the safety guarantees that you can have with a GC that you can't have with mechanisms like malloc and free. Some amount of @nogc code can be @safe, but some of it will never be able to be @safe. e.g. the very nature of malloc and free makes @safe impossible in the general case. This is why I ask. Because the vision document says "2. @nogc: Use of D without a garbage collector, most likely by using reference counting and related methods Unique/Weak references) for reclamation of resources. This task is made challenging by the safety requirement." It sounds like @safe @nogc code is the goal. I know it is challenging, I'd like to know if there is a plan/design for how to achieve this. It's trivial for a piece of code to free something that's currently in use by other code. If they're constrained within a ref-counting system, then @safety becomes more possible, but even then, when you have to start worrying about stuff like weak references in order to get around circular reference problems, it gets dicey if not impossible to make it fully @safe. Yep, circular references are a difficulty of ref-counting. Is there a plan/design for how to handle this? It might be possible to guarantee safety if you have a whole bunch of extra constraints like Rust does with its borrowing stuff, but we're not going to add something like that to D, because it's too complicated on top of everything else that we already have. So that level of safety is just not a goal of D? If I want memory safe code without a GC, should I just use Rust? I fully expect that certain idioms will be in place to help maintain @safety in @nogc code, but to some extent, by abandoning the GC, you're abandoning @safety - or at least you're making a lot more of your code need to be @trusted, and you can rely less on the compiler to guarantee @safety for you. Taking the freeing of memory out of the hands of the programmer like happens with the GC is _huge_ in guaranteeing the memory safety of code. Will @nogc also have first class support in the language? And what do you mean my first class support? Some features require the GC, and I wouldn't expect it to ever be otherwise. Giving up the GC means giving up on certain features. We don't want that list to be longer that it needs to be, but some stuff fundamentally needs the GC to do what it does. That is what I meant. The next questions are examples of what I meant. Afaik the GC is currently needed for language features like array concatenation. Will features like array concatentation still work with @nogc? I don't see how it possibly could given how dynamic arrays work in D. It would have to have some sort of reference counting mechanism, which would likely be a nightmare with slicing and certainly does not at all play well with how low level D arrays are. We may very well get some sort of ref-counted array type that has concatenation, but it would be a library construct rather than in the language, because it doesn't need to be in the language, and the built-in arrays would not be affected by it. GC allocations have a keyword 'new' (afaik 'new' currently never means anything other than GC allocation). Will we be able to do @nogc allocations by the 'new' keyword? I very much doubt it. Constructing objects into memory is done via emplace, which is a library construct, and there's really no need for it to be in the language. As it is, if we were doing things from scratch, new probably wouldn't even be a keyword. It would likely be a library construct in druntime, because D is powerful enough that new doesn't need to be in the language to do what it does. And in general, at this point, Walter and Andrei don't want to put stuff in the language unless it actually needs to be there. If it can be done with a library, it will be done with a library. The only reason that they decided that we needed some sort of ref-counting mechanism in the language is because they decided that it wasn't actually possible to make it fully @safe without it being part of the language. And even then, I'm not sure that the intention is that the ref-counting mechanism use anything other than the GC. It's not yet clear what it's going to
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 12:53:16 UTC, Nick Treleaven wrote: On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote: On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. That might be slower sometimes as slices wouldn't fit in two registers then. Although for custom data structures, offset & length could often share one register. Then the magic looking up of the base address can be avoided, saving time.
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote: On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. That might be slower sometimes as slices wouldn't fit in two registers then. You could put metadata just before the start of the array, including the reference count. Yes, but GC arrays already do that with GC metadata (alloc size) without having offset, so that technique could in theory be done with RC too. It's a bit mysterious how the base address is found, would be nice to have some clear docs on this to point to.
Re: Vision document for H1 2017
On Friday, 13 January 2017 at 05:33:07 UTC, Chris Wright wrote: On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via Digitalmars-d-announce wrote: I don't see how it possibly could given how dynamic arrays work in D. It would have to have some sort of reference counting mechanism, which would likely be a nightmare with slicing On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. You could put metadata just before the start of the array, including the reference count. I know that you mean for the general case, but the structure you describe is the same as `std.experimental.ndclice`s Slice!(1,T*): pointer, length, stride triplet. This would also work with higher dimensional Slices as well. Combine that with prefix allocator ét voilá.
Re: Vision document for H1 2017
On Friday, January 13, 2017 05:33:07 Chris Wright via Digitalmars-d-announce wrote: > On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via > > Digitalmars-d-announce wrote: > > I don't see how it possibly could given how dynamic arrays work in D. It > > would have to have some sort of reference counting mechanism, which > > would likely be a nightmare with slicing > > On that topic, D's arrays would play nicer with both refcounting *and* > modern garbage collectors if they were structured as base, offset, length > instead of start, length. You could put metadata just before the start of > the array, including the reference count. It's actually really nice as well as performant for D's dynamic arrays to be the way that they are. Adding any kind of reference count into them would add overhead as well as not play nicely when you're doing stuff like slicing pointers or static arrays, which should definitely not be ref-counted. If you're willing to use the GC, they way that D's dynamic arrays work right now is fantastic. And even if you're not willing to use the GC, the way they work is great if you have other code managing their memory appropriately and just don't use the concatentation or appending operations. Plenty of code would not want any ref-counting to be going on when passing a dynamic array around. Having a ref-counted object that's like an array in addition to D's current dynamic arrays would be fine and great for some programs, but I sure wouldn't want to lose what we have now. - Jonathan M Davis
Re: Vision document for H1 2017
On Thu, 12 Jan 2017 20:02:38 -0800, Jonathan M Davis via Digitalmars-d-announce wrote: > I don't see how it possibly could given how dynamic arrays work in D. It > would have to have some sort of reference counting mechanism, which > would likely be a nightmare with slicing On that topic, D's arrays would play nicer with both refcounting *and* modern garbage collectors if they were structured as base, offset, length instead of start, length. You could put metadata just before the start of the array, including the reference count.
Re: Vision document for H1 2017
On Thursday, January 12, 2017 21:57:37 Andrew Browne via Digitalmars-d- announce wrote: > On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu > > wrote: > > We release a brief Vision document summarizing the main goals > > we plan to pursue in the coming six months. This half we are > > focusing on three things: safety, lifetime management, and > > static introspection. > > > > https://wiki.dlang.org/Vision/2017H1 > > > > > > Andrei > > Is there a design document for how D will achieve safety with > nogc? > How does D plan to prevent leaks, use-after-free, double-free > bugs when not using the GC? Part of the reason that we have the GC in D is because of the safety guarantees that you can have with a GC that you can't have with mechanisms like malloc and free. Some amount of @nogc code can be @safe, but some of it will never be able to be @safe. e.g. the very nature of malloc and free makes @safe impossible in the general case. It's trivial for a piece of code to free something that's currently in use by other code. If they're constrained within a ref-counting system, then @safety becomes more possible, but even then, when you have to start worrying about stuff like weak references in order to get around circular reference problems, it gets dicey if not impossible to make it fully @safe. It might be possible to guarantee safety if you have a whole bunch of extra constraints like Rust does with its borrowing stuff, but we're not going to add something like that to D, because it's too complicated on top of everything else that we already have. I fully expect that certain idioms will be in place to help maintain @safety in @nogc code, but to some extent, by abandoning the GC, you're abandoning @safety - or at least you're making a lot more of your code need to be @trusted, and you can rely less on the compiler to guarantee @safety for you. Taking the freeing of memory out of the hands of the programmer like happens with the GC is _huge_ in guaranteeing the memory safety of code. > Will @nogc also have first class support in the language? And what do you mean my first class support? Some features require the GC, and I wouldn't expect it to ever be otherwise. Giving up the GC means giving up on certain features. We don't want that list to be longer that it needs to be, but some stuff fundamentally needs the GC to do what it does. > Afaik the GC is currently needed for language features like array > concatenation. Will features like array concatentation still work > with @nogc? I don't see how it possibly could given how dynamic arrays work in D. It would have to have some sort of reference counting mechanism, which would likely be a nightmare with slicing and certainly does not at all play well with how low level D arrays are. We may very well get some sort of ref-counted array type that has concatenation, but it would be a library construct rather than in the language, because it doesn't need to be in the language, and the built-in arrays would not be affected by it. > GC allocations have a keyword 'new' (afaik 'new' currently never > means anything other than GC allocation). Will we be able to do > @nogc allocations by the 'new' keyword? I very much doubt it. Constructing objects into memory is done via emplace, which is a library construct, and there's really no need for it to be in the language. As it is, if we were doing things from scratch, new probably wouldn't even be a keyword. It would likely be a library construct in druntime, because D is powerful enough that new doesn't need to be in the language to do what it does. And in general, at this point, Walter and Andrei don't want to put stuff in the language unless it actually needs to be there. If it can be done with a library, it will be done with a library. The only reason that they decided that we needed some sort of ref-counting mechanism in the language is because they decided that it wasn't actually possible to make it fully @safe without it being part of the language. And even then, I'm not sure that the intention is that the ref-counting mechanism use anything other than the GC. It's not yet clear what it's going to look like, but previously, the talk was using the GC to take care of circular references, which would mean that the memory was still GC-allocated even if it were ref-counted. We'll have to wait and see though. > Is the same code always expected to work with/without @nogc? That would depend entirely on the code. std.experimental.allocator has a GC allocator. So, code that is designed around it could work with the GC or without. But the whole mechanism of newing something up and then not worrying about ownership which happens by default with the GC doesn't play at all nicely with how memory has to be managed via other mechanisms like malloc and free. I don't think that it's at all reasonable to expect that code that is written with the idea that its memory will be managed by the GC will also work without the
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei Is there a design document for how D will achieve safety with nogc? How does D plan to prevent leaks, use-after-free, double-free bugs when not using the GC? Will @nogc also have first class support in the language? Afaik the GC is currently needed for language features like array concatenation. Will features like array concatentation still work with @nogc? GC allocations have a keyword 'new' (afaik 'new' currently never means anything other than GC allocation). Will we be able to do @nogc allocations by the 'new' keyword? Is the same code always expected to work with/without @nogc?
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu wrote: On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote: C++ integration has disappeared? Is this now "done"? We have a student on that. I've added a line for that to the doc. -- Andrei I did a lot of work on C++ name mangling for D so feel free to introduce me to the student. I can probably save her/him a lot of time. After *many* attempts it seems the only way to get this right is to look at how clang does it and replicate the logic (starting point https://github.com/llvm-mirror/clang/blob/google/stable/include/clang/AST/Mangle.h) The state of my research on mangling so far are summed up here https://github.com/gchatelet/gcc_cpp_mangling_documentation I also have a bunch of failed experiments branches: - https://github.com/gchatelet/dmd/tree/new_cpp_mangle - https://github.com/gchatelet/dmd/tree/new_cpp_mangle2 - https://github.com/gchatelet/dmd/tree/new_cpp_mangling2 - https://github.com/gchatelet/dmd/tree/more_mangling_tests Unfortunately I couldn't spend more time on this :(
Re: Vision document for H1 2017
On Thursday, 12 January 2017 at 09:54:08 UTC, Mark wrote: I think the "D for C++ programmers" page could use a revamp: https://dlang.org/cpptod.html At the moment it mainly explains where and how D differs from C++. Whoever reads it may be ready to write C++ code in D, but this seems pointless and may give the impression that D is just C++ with a different syntax plus a few minor features (strong typedef and the scope statement). The page doesn't mention D's dynamic arrays, associative arrays, ranges, UFCS, function attributes and so on). It's intended to help C++ programmers switch to D, not as a comparison. It also links to: https://dlang.org/ctod.html which does mention arrays and various other small things. (I noticed some minor things to fix and submitted a pull request). One idea on my mind is providing various (honest, not specifically tailored) examples of C++ code that aims to solve a certain problem, and how the same problem can be solved in D in a better way (in some sense). I've seen this done effectively with Java vs. Scala. Sounds good. I think this thread is for big issues that need core focus though, anyone here can and should submit documentation.
Re: Vision document for H1 2017
On Sunday, 8 January 2017 at 00:15:23 UTC, Seb wrote: On Saturday, 7 January 2017 at 23:33:45 UTC, Benjiro wrote: Maybe something to add ( for new users ) is something similar to: http://rustbyexample.com/ Easy to use, lots of information, simple tasks that involve interaction for the user, feedback on success. Do you know about the existing Dlang Tour? https://tour.dlang.org PRs/Issues to improve it are welcome Its translation into a couple of languages is WIP: https://github.com/dlang-tour I think the "D for C++ programmers" page could use a revamp: https://dlang.org/cpptod.html At the moment it mainly explains where and how D differs from C++. Whoever reads it may be ready to write C++ code in D, but this seems pointless and may give the impression that D is just C++ with a different syntax plus a few minor features (strong typedef and the scope statement). The page doesn't mention D's dynamic arrays, associative arrays, ranges, UFCS, function attributes and so on). The tour does mention these features (under "D's gems") so maybe some of its contents can be used to extend the "D for C++" page. One idea on my mind is providing various (honest, not specifically tailored) examples of C++ code that aims to solve a certain problem, and how the same problem can be solved in D in a better way (in some sense). I've seen this done effectively with Java vs. Scala.
Re: Vision document for H1 2017
- tagging instead of hierarchical categories The categories are in fact just a form of hierarchical tags. This is quite useful, because applying a tag will bring in the ancestor tags for free. The UI for both, applying tags and filtering, could be better, though. And some form of crowd sourced management of available tags could also be interesting to think about.
Re: Vision document for H1 2017
On Sunday, January 08, 2017 18:06:53 Brian via Digitalmars-d-announce wrote: > On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu > > wrote: > > We release a brief Vision document summarizing the main goals > > we plan to pursue in the coming six months. This half we are > > focusing on three things: safety, lifetime management, and > > static introspection. > > > > https://wiki.dlang.org/Vision/2017H1 > > > > > > Andrei > > I hope dlang can support QT5 binding Binding to Qt in general is really nasty in comparison to a lot of C++ code, since Qt does stuff like have its own preprocessor to generate additional code so that signals and slots work. We had qtd (which did Qt4), but it seems to have lost all its contributors and died off a few years ago, and it seems to have used Qt Jambi stuff (or at least been based on it) and Qt Jambi doesn't seem to have ever made the transition to Qt5. So, I don't know how possible it would be to get qtd to work with Qt5, even if the original contributors were still working on it (but it doesn't seem to compile now, so it's not even currently viable for Qt4). I think that someone put up a solution on code.dlang.org that involves QML, but I have no idea how well it works or how complete it is (personally, I have less than zero interest in QML). I've actually started work on a solution for binding Qt5 to D, because I have something I'm working on that uses Qt, and I'm sick of doing the GUI portion in C++. So, I may end up releasing a Qt5 bindings project at some point here, but I'm making no promises. - Jonathan M Davis
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei Dlang should strive to improve the standard library, such as Python, go, rust.
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 19:55:30 UTC, Martin Nowak wrote: On 01/05/2017 11:00 AM, Basile B. wrote: I don't known what did you decide in intern but when the discussion between users was hot (just after version 2.071.1 I think) I've proposed that: https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md This is superfluous by now. We figured that allowing access to private fields wouldn't clash with important optimizations, so it can be allowed via traits. The visibility of allMembers was adjusted in https://github.com/dlang/dmd/pull/6078. All access checks will go away once the visibility changes have been fully deprecated. So far those changes were adopted fairly slow (not even phobos has fixed them all), hence we haven't yet switched over to the new visibility semantics. -Martin Awesome! I tried to write a whole-module reflection tool, but was unable to finish satisfactorily due to the requirement that code actually be included in the module itself in order to reflect all it's members.
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 15:58:43 UTC, Andrei Alexandrescu wrote: On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote: C++ integration has disappeared? Is this now "done"? We have a student on that. I've added a line for that to the doc. -- Andrei Cool. C++ integration would be a big plus for D so it would be great if this feature was completed to a defined standard - by this I mean that there ought to be documentation on what works, but more importantly, what doesn't, so that users don't have to try to work this out by trial and error. Regards Dibyendu
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 23:33:45 UTC, Benjiro wrote: Maybe something to add ( for new users ) is something similar to: http://rustbyexample.com/ Easy to use, lots of information, simple tasks that involve interaction for the user, feedback on success. Do you know about the existing Dlang Tour? https://tour.dlang.org PRs/Issues to improve it are welcome Its translation into a couple of languages is WIP: https://github.com/dlang-tour
Re: Vision document for H1 2017
On Saturday, 7 January 2017 at 20:10:17 UTC, Martin Nowak wrote: I think there won't be much discussions about the goals (maybe about the priorities). Many people come up with the same ideas to resolve the pain points. Actually I have a draft for a renewed site, will look at implementing that (hopefully with Sebastian, Söhnke, and others) in the next few month. So far haven't found an angle at breaking up the story though, it's fairly intermingled. If we can't do it incrementally, that would require a bit more orchestration for a major rerelease. - better search, also on README bodies (e.g. sqlite FTS) - tagging instead of hierarchical categories - ranking (downloads, stars, dependents, testing...) - better landing page (big search form and listing 10 top, 10 trending, and 10 newest packages) - better GH integration Maybe something to add ( for new users ) is something similar to: http://rustbyexample.com/ Easy to use, lots of information, simple tasks that involve interaction for the user, feedback on success.
Re: Vision document for H1 2017
On 01/07/2017 02:55 PM, Martin Nowak wrote: On 01/05/2017 11:00 AM, Basile B. wrote: I don't known what did you decide in intern but when the discussion between users was hot (just after version 2.071.1 I think) I've proposed that: https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md This is superfluous by now. We figured that allowing access to private fields wouldn't clash with important optimizations, so it can be allowed via traits. The visibility of allMembers was adjusted in https://github.com/dlang/dmd/pull/6078. All access checks will go away once the visibility changes have been fully deprecated. So far those changes were adopted fairly slow (not even phobos has fixed them all), hence we haven't yet switched over to the new visibility semantics. -Martin Oh, now I remember. Yes, introspection works in "sudo" mode - all information is available to it, including what's private and what isn't :o). Thanks Martin for fielding this and other questions. -- Andrei
Re: Vision document for H1 2017
On 01/05/2017 11:45 PM, Sönke Ludwig wrote: > Am 05.01.2017 um 01:59 schrieb Paul O'Neil: >> On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote: >>> We release a brief Vision document summarizing the main goals we plan to >>> pursue in the coming six months. This half we are focusing on three >>> things: safety, lifetime management, and static introspection. >>> >>> https://wiki.dlang.org/Vision/2017H1 >>> >>> >>> Andrei >> >> What are the plans for the dub registry? Have there been discussions >> already? > > I'm not aware of concrete discussions w.r.t. the vision document I think there won't be much discussions about the goals (maybe about the priorities). Many people come up with the same ideas to resolve the pain points. Actually I have a draft for a renewed site, will look at implementing that (hopefully with Sebastian, Söhnke, and others) in the next few month. So far haven't found an angle at breaking up the story though, it's fairly intermingled. If we can't do it incrementally, that would require a bit more orchestration for a major rerelease. - better search, also on README bodies (e.g. sqlite FTS) - tagging instead of hierarchical categories - ranking (downloads, stars, dependents, testing...) - better landing page (big search form and listing 10 top, 10 trending, and 10 newest packages) - better GH integration Personally would approach this mid/end of March, but if enough people have time we could do it earlier. https://dlang.slack.com/messages/dub/
Re: Vision document for H1 2017
On 01/06/2017 11:09 PM, Anton wrote: > On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: >> We release a brief Vision document summarizing the main goals we plan >> to pursue in the coming six months. This half we are focusing on three >> things: safety, lifetime management, and static introspection. >> >> https://wiki.dlang.org/Vision/2017H1 >> >> >> Andrei > > dub registry required review > 1. By myself current page rename to "last updates", and "Main" may be > (scoped) category view? > IMHO main page currently unfriendly > > 2. dub registry search unexpected > i'm looking for network libs, entered "net" and take: > ... > freeimage > dyaml > ... Thanks, we are aware of the various limitations, hence it'll be a major priority to improve the site. Improving search and tagging is one bigger aspect of that, distinguishing high quality packages another one. -Martin
Re: Vision document for H1 2017
On 01/05/2017 11:00 AM, Basile B. wrote: > I don't known what did you decide in intern but when the discussion > between users was hot (just after version 2.071.1 I think) I've proposed > that: > https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md This is superfluous by now. We figured that allowing access to private fields wouldn't clash with important optimizations, so it can be allowed via traits. The visibility of allMembers was adjusted in https://github.com/dlang/dmd/pull/6078. All access checks will go away once the visibility changes have been fully deprecated. So far those changes were adopted fairly slow (not even phobos has fixed them all), hence we haven't yet switched over to the new visibility semantics. -Martin
Re: Vision document for H1 2017
On 01/05/2017 05:43 AM, Basile B. wrote: > To simplify introspection with library traits that use the compiler > "__traits()" someone has to remove the restrictions related to > protection attributes. This is not a new topic. Without this, the new > library traits won't work well and people won't use them. That's already what we decided in September, so where is the problem? http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org https://github.com/dlang/dmd/pull/6111
Re: Vision document for H1 2017
On 01/04/2017 11:43 PM, Basile B. wrote: To simplify introspection with library traits that use the compiler "__traits()" someone has to remove the restrictions related to protection attributes. This is not a new topic. Without this, the new library traits won't work well and people won't use them. Is this formalized in bugzilla? -- Andrei
Re: Vision document for H1 2017
On 01/04/2017 08:06 PM, Dibyendu Majumdar wrote: C++ integration has disappeared? Is this now "done"? We have a student on that. I've added a line for that to the doc. -- Andrei
Re: Vision document for H1 2017
P/S strange search one of cases why registry has a lot of similar projects
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei dub registry required review 1. By myself current page rename to "last updates", and "Main" may be (scoped) category view? IMHO main page currently unfriendly 2. dub registry search unexpected i'm looking for network libs, entered "net" and take: ... freeimage dyaml ... ??? Than query for "network", very different result
Re: Vision document for H1 2017
Am 05.01.2017 um 01:59 schrieb Paul O'Neil: On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei What are the plans for the dub registry? Have there been discussions already? I'm not aware of concrete discussions w.r.t. the vision document, but the two major improvements that come to mind are GitHub authentication, which enables push notifications for repository changes, and some form of pagination for the package list views. Also, one thing we discussed at the last DConf is a "popularity" score that would be used for sorting results. This would include things like download numbers and GitHub stars. It would also take into account the dependencies (which affects the download numbers), so that the score actually reflects the perceived popularity as close as possible. Finally, we want to have a form of CI integration to put packages that have tests/pass tests first (i.e. give an incentive for package authors to setup and use CI for their project). Generating documentation is another possibility, as well as testing DMD frontend version compatibility.
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 21:07:00 UTC, H. S. Teoh wrote: On Wed, Jan 04, 2017 at 08:45:09PM +, Stefan Koch via Digitalmars-d-announce wrote: [...] I claim dips on templates. (as in the colloquial english for asserting rights/ownership ) [...] FYI, it's spelt "dibs" (with a 'b'). ;-) T Actually, I think it's spelt "DIPs" (with capitalization) in dland ;) -- Just a random thought
Re: Vision document for H1 2017
On Thursday, 5 January 2017 at 09:49:16 UTC, Jonathan M Davis wrote: On Thursday, January 05, 2017 04:43:12 Basile B. via Digitalmars-d-announce wrote: On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: > We release a brief Vision document summarizing the main > goals we plan to pursue in the coming six months. This half > we are focusing on three things: safety, lifetime > management, and static introspection. > > https://wiki.dlang.org/Vision/2017H1 > > > Andrei quote from the document: > Redoing compiler code into lowerings and __traits-based > introspection that leverage client code, thus moving > compiler smarts into simpler library facilities To simplify introspection with library traits that use the compiler "__traits()" someone has to remove the restrictions related to protection attributes. This is not a new topic. Without this, the new library traits won't work well and people won't use them. IIRC, it was already agreed that they had to be removed and would be soon, but we couldn't do it right away either because of code breakage or because it was a point release that was trying to get out the door. I'm thinking that it's supposed to be fixed in 2.073, but I'm not 100% sure.. - Jonathan M Davis I don't known what did you decide in intern but when the discussion between users was hot (just after version 2.071.1 I think) I've proposed that: https://github.com/BBasile/DIPs/blob/3d5e3f81c541c6e23c69555a230b4d42a7bb6de6/DIPs/DIP8484.md There's no need to DIP this, the idea is just to add an optional parameter that remove the compliance with the protection attributes. Anyway if this or any alternative is planned for the next version that's perfect.
Re: Vision document for H1 2017
On Thursday, January 05, 2017 04:43:12 Basile B. via Digitalmars-d-announce wrote: > On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu > > wrote: > > We release a brief Vision document summarizing the main goals > > we plan to pursue in the coming six months. This half we are > > focusing on three things: safety, lifetime management, and > > static introspection. > > > > https://wiki.dlang.org/Vision/2017H1 > > > > > > Andrei > > quote from the document: > > Redoing compiler code into lowerings and __traits-based > > introspection that leverage client code, thus moving compiler > > smarts into simpler library facilities > > To simplify introspection with library traits that use the > compiler "__traits()" someone has to remove the restrictions > related to protection attributes. This is not a new topic. > Without this, the new library traits won't work well and people > won't use them. IIRC, it was already agreed that they had to be removed and would be soon, but we couldn't do it right away either because of code breakage or because it was a point release that was trying to get out the door. I'm thinking that it's supposed to be fixed in 2.073, but I'm not 100% sure.. - Jonathan M Davis
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei Do we have a list of "high-impact research projects"?
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei quote from the document: Redoing compiler code into lowerings and __traits-based introspection that leverage client code, thus moving compiler smarts into simpler library facilities To simplify introspection with library traits that use the compiler "__traits()" someone has to remove the restrictions related to protection attributes. This is not a new topic. Without this, the new library traits won't work well and people won't use them.
Re: Vision document for H1 2017
On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote: Templatize dmd <-> druntime API I'm curious as to why. I'm guessing this is for things like creating runtime type information? This thread (http://forum.dlang.org/post/mr7a65$2hc$1...@digitalmars.com) should provide some context. Mike
Re: Vision document for H1 2017
On 05/01/2017 8:22 AM, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei The suggestion I want to make related to druntime is, make TypeInfo/ModuleInfo actually have (opt-in) full reflection. This can help decrease template bloat significantly for (de)serializers as well as making it so you don't have to explicitly tell your web router about all the routes (instead chuck a UDA down and be done with it!). Andrei: we should talk in a few months about turning my (honors) dissertation into research papers. And maybe what I may end up doing for masters the following semester.
Re: Vision document for H1 2017
On Thursday, 5 January 2017 at 02:32:00 UTC, Chris Wright wrote: I'm curious as to why. I'm guessing this is for things like creating runtime type information? There's a lot of benefits to it: it'd simplify the compiler a bit, it'd simplify making custom runtimes, and it'd give us options to both expand and minimize the runtime info with things like compiler switches in druntime.
Re: Vision document for H1 2017
> Templatize dmd <-> druntime API I'm curious as to why. I'm guessing this is for things like creating runtime type information?
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Hi, its interesting to view this in context of previous vision documents: https://wiki.dlang.org/Vision/2015H1 https://wiki.dlang.org/Vision/2015H2 https://wiki.dlang.org/Vision/2016H1 https://wiki.dlang.org/Vision/2016H2 It seems safety and memory management have appeared in all of the documents, so presumably the goals haven't been achieved yet. I think it would be helpful to have more explicit definition of what it would mean for these features to be "done" and is that the aim for H1 2017. C++ integration has disappeared? Is this now "done"?
Re: Vision document for H1 2017
On 01/04/2017 02:22 PM, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei What are the plans for the dub registry? Have there been discussions already?
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 21:21:17 UTC, aberba wrote: I like the social media part. More people, more man power, more noise about D. I would read it as, with better signal-to-noise ratio.
Re: Vision document for H1 2017
On Wed, Jan 04, 2017 at 08:45:09PM +, Stefan Koch via Digitalmars-d-announce wrote: [...] > I claim dips on templates. (as in the colloquial english for asserting > rights/ownership ) [...] FYI, it's spelt "dibs" (with a 'b'). ;-) T -- It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei I claim dips on templates. (as in the colloquial english for asserting rights/ownership ) I can't wait to improve that situation.
Re: Vision document for H1 2017
On Wednesday, 4 January 2017 at 19:22:33 UTC, Andrei Alexandrescu wrote: We release a brief Vision document summarizing the main goals we plan to pursue in the coming six months. This half we are focusing on three things: safety, lifetime management, and static introspection. https://wiki.dlang.org/Vision/2017H1 Andrei Nice, a list of concrete tasks, well done. Only one criticism, some are too short: took me a bit to understand what "High-level shared library wrapper" meant, a better way to create and deal with shared libraries? If so, only reason I got that is because of your recent forum posts asking about loading shared libraries. Not sure what you want overhauled about the dub registry either, might want to expand on those, so someone interested could pick up on them.
