Re: On the future of DIP1000
On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote: Well, if you typically try and restrict your @system code to small parts of your program and use @trusted to turn them into @safe, then the vast majority of your program will be @safe. As I understand it, that's at least how it was _intended_ that @system be dealt with - though plenty of folks just don't bother with @safe, and it's certainly the case that code out there doesn't restrict the @system portions as much as it could. So, at least _in theory_, if you're using @safe as intended, even if you have a fair number of code snippets which are @system, you can take advantage of stuff like scope in most of your code. I don't know how well that will work in practice though. I can think of two big reasons to restrict something like this to @safe code though. One is that implementing something like this usually means declaring some stuff illegal that is actually safe, because the compiler can't be perfect about it (a similar example would be how a lot of lambdas end up allocating closures in order to be @safe when they don't actually need to; the compiler simply isn't smart enough to figure out that it isn't necessary and may or may not be able to with what the language allows the programmer to do). Another reason is that sometimes in order to make certain guarantees, the compiler has to be able to assume things that aren't necessarily true in @system code, even if they happen to be true for most @system code. I agree. If there's a lot of @system code in a program, something has gone awry in its design. I understand the desire to be able to turn each individual safety feature on and off, but don't think the code really will be better off that way.
Re: On the future of DIP1000
On Sunday, August 21, 2016 21:52:59 John Colvin via Digitalmars-d-announce wrote: > On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote: > > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: > >> - scope is @safe only > > > > Why? I might have @system code that could still benefit from > > scope. > > I guess it would be too restrictive, but I'm just a bit > frustrated at having to choose between lots of compiler checking > and none at all. I wish there was a flag for the compiler that > would give @safe violations as warnings in @system / @trusted > code, it would be too noisy for routine use but it would be great > to occasionally look through. Well, if you typically try and restrict your @system code to small parts of your program and use @trusted to turn them into @safe, then the vast majority of your program will be @safe. As I understand it, that's at least how it was _intended_ that @system be dealt with - though plenty of folks just don't bother with @safe, and it's certainly the case that code out there doesn't restrict the @system portions as much as it could. So, at least _in theory_, if you're using @safe as intended, even if you have a fair number of code snippets which are @system, you can take advantage of stuff like scope in most of your code. I don't know how well that will work in practice though. I can think of two big reasons to restrict something like this to @safe code though. One is that implementing something like this usually means declaring some stuff illegal that is actually safe, because the compiler can't be perfect about it (a similar example would be how a lot of lambdas end up allocating closures in order to be @safe when they don't actually need to; the compiler simply isn't smart enough to figure out that it isn't necessary and may or may not be able to with what the language allows the programmer to do). Another reason is that sometimes in order to make certain guarantees, the compiler has to be able to assume things that aren't necessarily true in @system code, even if they happen to be true for most @system code. - Jonathan M Davis
Re: D support for the Meson build system
On Sunday, 21 August 2016 at 19:08:59 UTC, Matthias Klumpp wrote: for a project like Terminix, dub with LDC builds in 8.6s, while Meson and ninja take only 6s here. Did you try to build with DUB but with WIFI or ethernet interface toggled off ?
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote: On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope. I guess it would be too restrictive, but I'm just a bit frustrated at having to choose between lots of compiler checking and none at all. I wish there was a flag for the compiler that would give @safe violations as warnings in @system / @trusted code, it would be too noisy for routine use but it would be great to occasionally look through.
Re: On the future of DIP1000
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote: - scope is @safe only Why? I might have @system code that could still benefit from scope.
On the future of DIP1000
This week I had a tele-meeting with Andrei and Walter regarding the fate of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) and intented way to move forward with it. This is a short summary of the meeting. Approval of DIP1000 --- DIP1000 is going to be approved as the basis of the idea but exact specification may change during implementation and as a result of incorporating some ideas from feedback threads (http://forum.dlang.org/thread/pqsiqmkxenrwxoruz...@forum.dlang.org and http://forum.dlang.org/thread/rwxcfapvpfiqmfsui...@forum.dlang.org). Core principles that are sure to stay at this point: - scope is a storage class - scope is non-transitive - scope is @safe only - responsibility of implementing complicated scope-using types is on developer, compiler magic is intended to be minimal Any changes in intended DIP1000 spec will be reflected in original document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). Implementation of DIP1000 - Walter is currently working on implementing the support via https://github.com/dlang/dmd/pull/5972, which will take some time. Once it is more feature complete I'll contact Martin for possible out-of-release preview compiler builds from that branch to try it out easily. About that time we will start another feedback thread in the NG with a more practical focus - featuring more code examples and design idioms. Life after DIP1000 -- It is acknowledged that DIP1000 itself does not allow to implemented completely @safe reference counting, primarily because of an issue with @trusted destructor and re-assignment. Intention is to follow up with another proposal (not directly related) to address the issue from another angle - but this will only become in focus after DIP1000 is finished.
Re: QtE5 - is a wrapping of Qt-5 for D
On Sunday, 21 August 2016 at 13:18:04 UTC, MGW wrote: Hello, could you share your experience with D language? How it feels to work with it?
Re: ggplotd version 1.0.0 released
On Saturday, 20 August 2016 at 16:37:29 UTC, Edwin van Leeuwen wrote: I just wanted to announce the 1.0.0 version release of ggplotd [1]. The main addition is support for legends. Other than that the release focused on cleaning up/refactoring the code. It should still be backwards compatible though. As always I also released a new version of plotcli (the commandline plotting tool), which now also supports legends [2]. I am afraid there is currently no prebuild plotcli version with gtk support available OSX due to a linker error with gtkd on OSX [3]. I don't have a mac, so have been unable to solve this. Any input would be appreciated :) [1] https://github.com/BlackEdder/ggplotd [2] https://github.com/BlackEdder/plotd [3] https://github.com/gtkd-developers/GtkD/issues/162 This is excellent. I shall give it a try this week. Thanks! SD
Re: ggplotd version 1.0.0 released
On Sunday, 21 August 2016 at 12:32:11 UTC, ZombineDev wrote: I've worked extensively with data-viz UI components for WPF/SL and ASP.NET and I have to say that, after a quick glance at the readme, I really like the API of your library! Nice work! Thanks! Although I must give most of the props to ggplot2 (the R package), because it is inspired by their API :)
Re: QtE5 - is a wrapping of Qt-5 for D
On Thursday, 23 June 2016 at 13:04:09 UTC, Jozsef wrote: Nice work! I do not know if performance of the Forth interpreter is important, but I would replace the following sequence to spare a function call. CALL label; ret; --->>> JMP label; Many thanks for the note on forth! Development of QtE5 - a ready installer. QtE5 - from a box. Before installation the compiler DMD shall be already set! Ready installer: https://yadi.sk/d/sqhTCMneuN7rj It isn't recommended to change the directory of installation since in "Program Files" by default record is forbidden, and during installation there is a compilation of programs D. In particular, there is a compilation of the check program RunTime Qt-5 and ide5. The installer creates an icon for "compilation and start" ide5. If every time again it isn't necessary to compile ide5, then create other icon with the necessary parameters. In Linux installation is also possible if you have Wine. If you have DMD for Linux, then operation and with it is possible. For this purpose it is necessary to launch a script: "sh start_ide5.sh" - which compiles ide5 using the compiler dmd for Linux and QtE5 for Linux. There are ready 32 and 64 Linux of assembly and 32 Windows assembly.
Re: ggplotd version 1.0.0 released
On Saturday, 20 August 2016 at 16:47:07 UTC, Edwin van Leeuwen wrote: On Saturday, 20 August 2016 at 16:37:29 UTC, Edwin van Leeuwen wrote: I just wanted to announce the 1.0.0 version release of ggplotd [1]. The main addition is support for legends. Other than that the release focused on cleaning up/refactoring the code. It should still be backwards compatible though. Forgot to add what ggplotd actually is :) ggplotd is a plotting library, which uses cairo to do the actual for drawing. It supports saving as svg, pdf and png file. It also has basic support for drawing to gtk. The library design is inspired by ggplot2 for R, which in turn is based on a book called: grammar of graphics (hence gg(plot)). It supports plotting lines/points, histograms(2d) and density(2d) plots. It is written in such a way that it is easy to add your own type of plots (see the README). I've worked extensively with data-viz UI components for WPF/SL and ASP.NET and I have to say that, after a quick glance at the readme, I really like the API of your library! Nice work!
