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!
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 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: 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: 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?
D support for the Meson build system
Hi! Last week I was at this year's GUADEC conference and listened to a very interesting talk on the Meson build system[2] which is designed for very fast builds and as a much more modern replacement for Automake with a simple syntax. In the past few days I added support for D (all three major compilers) to the Meson build system, with some great results- While dub is awesome for simple and small projects, you usually want a bit more for bigger projects, especially if you are mixing D code with C bits or are linking against libraries written in C (which is what pretty much all the D code I write does excessively). You also make the life of Linux distribution packagers much easier with this, since dub isn't really working well for us in that usecase (only one D package in Debian uses it at time, and only for an experiment I made to check whether using dub is viable. At time, dub is pretty high up on my D complaints list[3]). So, should you consider adding Meson support for your project? That depends. A few highlights of Meson include: * Very fast builds using the Ninja[4] build tool (which is also used by projects like Google Chrome) - for a project like Terminix, dub with LDC builds in 8.6s, while Meson and ninja take only 6s here. The change is even more dramatic with a lot more D source files. * Support for installing files, and generally good support for Linux distributions. * Mixing in parts written in C or C++ is very simple. * Depending on system libraries (Cairo, Libarchive, GTK+) is really easy, and you can also version the dependencies. * You can configure files at build time and also run arbitrary commands to e.g. generate additional code to compile in or to compile additional resources, which is needed for a lot of applications. If you want to see a real world example on how to use Meson, check out my example patch for Terminix: https://github.com/gnunn1/terminix/commit/01d11dcff7da4626a91cf0344897c4ff1783a69e For simpler examples, check out the D unit tests for Meson: https://github.com/mesonbuild/meson/tree/master/test%20cases/d Meson supports building files for Visual Studio and is supposed to work on Windows as well. I developed the D pieces solely on Linux and couldn't test anything on Windows yet (but it would be interesting to know if this works). D support will be available in Meson with the upcoming 0.34 release, which is when it will show up in Linux distributions like Ubuntu and Debian. Until then, it's really easy to try Meson from Git master[5]. I hope you find this as useful as I do :-) Cheers, Matthias [1]: https://en.wikipedia.org/wiki/GNOME_Users_And_Developers_European_Conference [2]: http://mesonbuild.com/ [3]: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b [4]: https://ninja-build.org/ [5]: https://github.com/mesonbuild/meson
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: 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.
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: 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, 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: 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 2016-08-21 22:01, Dicebot wrote: 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. It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together. It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture. I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback. -- /Jacob Carlborg
Re: On the future of DIP1000
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote: It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together. It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture. I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback. What he said !
