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: Another XML DOM Package
Guillaume Piolat via Digitalmars-d-announce napsal St, led 4, 2017 v 11∶48 : On Friday, 30 December 2016 at 04:19:47 UTC, apz28 wrote: This is my first package to learn D. Suggestion for improvement is welcome. https://github.com/apz28/dlang-xml Welcome here! - you don't have to commit .sln files, dub can generate them as needed - that is for a package that will be reused you can use dub :) - no need to use @property, there was a recent discussion about it. I think you can ignore it altogether. Yes he can but I still prefer it for documentation purposes :) - you can use "final" before a class declaration to have all methods be final final class C { /* all methods are final /= } Most common and IMHO better pattern is put final as first thing in class like this: class C { final: // all methods after this are final } It has some advantages (class C is not final so you can still use inheritance), marking class final does not need to mean all methods are final (it makes sense to mark them and in curent implementation it is) you can still add easy one method which is virtual. To be fair I mostly use struct instead of final clases - no need for "public import std.exception : Exception;" to use Exception imho the XML parser to beat in our ecosystem is kxml, which is small and serviceable
Re: Another XML DOM Package
On Friday, 30 December 2016 at 04:19:47 UTC, apz28 wrote: This is my first package to learn D. Suggestion for improvement is welcome. https://github.com/apz28/dlang-xml Welcome here! - you don't have to commit .sln files, dub can generate them as needed - that is for a package that will be reused you can use dub :) - no need to use @property, there was a recent discussion about it. I think you can ignore it altogether. - you can use "final" before a class declaration to have all methods be final final class C { /* all methods are final /= } - no need for "public import std.exception : Exception;" to use Exception imho the XML parser to beat in our ecosystem is kxml, which is small and serviceable
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 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 like the social media part. More people, more man power, more noise about D.
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.
Vision document for H1 2017
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
Re: Terminix Year In Review
On Wednesday, 4 January 2017 at 04:08:00 UTC, Adam D. Ruppe wrote: On Monday, 2 January 2017 at 21:11:47 UTC, Getald wrote: I'm not sure a textview would be viable, it might work for the command prompt but I doubt it would handle ncurses type applications like vi or nano very well. I don't know GTK at all, but my terminal thing's frontend just needs keyboard and mouse input events and a canvas to draw onto (including text string drawing functions). So I'm guessing the TextView is actually overfeatured for what I'd want. Yep, that would be my expectation. I suspect you would just inherit from GtkWidget and go from there.
Re: PostgreSQL native impl
On 2017-01-04 12:26, Nemanja Boric wrote: Shameless plug, I've been working in my spare time on a similar project: https://github.com/Burgos/postgres-native Progress is super slow, though, but I'm really happy how the things are working out, so just publishing here if somebody wants to take the inspiration from the API or any part of it, or if somebody wants to help :-) There's already a bunch of Postgres drivers here [1], some are native ones, some uses the C library. ddb [2] is, I believe, the oldest native driver at code.dlang.org. That's the one I've been using. Compatible with vibe.d as well. [1] http://code.dlang.org [2] http://code.dlang.org/packages/ddb -- /Jacob Carlborg
Re: PostgreSQL native impl
On Tuesday, 3 January 2017 at 09:07:35 UTC, Arun Chandrasekaran wrote: On Tuesday, 3 January 2017 at 01:08:28 UTC, Chris Wright wrote: On Mon, 02 Jan 2017 20:29:55 +, Anton wrote: Today i spent about hour to write pure-D simple PostgreSQL driver for demonstration purposes. I was looking for developers interested in complete PostgreSQL driver (pure D) That demo not implements auth, therefore requires trusted user [1] https://github.com/anton-dutov/postgresql-native-d [2] https://www.postgresql.org/docs/9.6/static/protocol.html Nice! Looks like it wouldn't be much work to add prepared queries. I notice you rolled your own uri library. Might I point you toward urld? It supports ipv6 hosts (probably handy) and unicode domain names (nice to have, probably not useful here). http://code.dlang.org/packages/urld This is really neat! I've been looking for one such. I'm used to https://github.com/cpp-netlib/uri in C++. Shameless plug, I've been working in my spare time on a similar project: https://github.com/Burgos/postgres-native Progress is super slow, though, but I'm really happy how the things are working out, so just publishing here if somebody wants to take the inspiration from the API or any part of it, or if somebody wants to help :-) I hope in 2017 I'll build a simple web project around it, which should help alot.
Re: Aedi 0.1.0 release
On Tuesday, 3 January 2017 at 18:24:50 UTC, Chris Wright wrote: On Tue, 03 Jan 2017 11:47:44 +, Alexandru Ermicioi wrote: Aedi release 0.1.0 is available now. This would be the perfect place to describe what Aedi is and why people might be interested in it. It is a dependency injection library. Dependency injection libraries, usually are used at bootstrap stage of application, when application is creating and connecting all of it's components (objects, structs etc.). The process of wiring components between them, can be tedious and complex, in case when it is done manually. A DI library like Aedi, will take the task of creating and wiring components between them, instead of developer. It will wire them according to configuration, passed to it. The configuration itself can be done by code or by annotation for Aedi, and it is easier to write it, since the DI library will take the rest of work on itself.