Re: GtkD 3.9.0, A GTK+ D binding.
On Wednesday, 29 May 2019 at 20:30:03 UTC, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. At this point it feels long overdue, but finally there is an GtkD release that is updated for the latest GTK+ libraries. And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org Full changelog: https://gtkd.org/changelog.html Download: https://gtkd.org/download.html Thanks a lot for this project I'm using gtkd in several of my projects and really enjoying it.
Re: GtkD 3.9.0, A GTK+ D binding.
On Wednesday, 29 May 2019 at 22:07:14 UTC, Mike Wey wrote: Or changing `string specialPreprocessor` in doc2.d to `__gshared') Oh geeze, indeed! I made that change locally, I prolly won't push it up to github for a bit tho cuz I broke other stuff in my copy I need to fix first. But yeah thanks!
Re: GtkD 3.9.0, A GTK+ D binding.
On 29-05-2019 23:37, Adam D. Ruppe wrote: On Wednesday, 29 May 2019 at 20:30:03 UTC, Mike Wey wrote: And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org A tip: when you generate the code with adrdox, use --special-preprocessor=gtk I was already using that, but looking a bit closer it only works when also passing `--jobs=1`. (Or changing `string specialPreprocessor` in doc2.d to `__gshared'). Should be updated soon. BTW nice work on teh css! It obviously needs to match the website ;) -- Mike Wey
Re: GtkD 3.9.0, A GTK+ D binding.
On 29-05-2019 22:38, M.M. wrote: So cool! I guess it will be a lot of work to get the bindings and wrapper to the upcoming GTK 4... Hopefully the generator can handle most of it without intervention. -- Mike Wey
Re: GtkD 3.9.0, A GTK+ D binding.
On Wednesday, 29 May 2019 at 20:30:03 UTC, Mike Wey wrote: And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org A tip: when you generate the code with adrdox, use --special-preprocessor=gtk in addition to your other command line args. That will trigger its support for the gtk-specific doc comment syntax and fix up some C -> D reference links, etc. It still isn't perfect, but like you can compare here: http://gtk-d.dpldocs.info/gdk.AppLaunchContext.AppLaunchContext.html with yours https://api.gtkd.org/gdk.AppLaunchContext.AppLaunchContext.html to see some of the differences. BTW nice work on teh css!
Re: Variant Graph Support to BioD
On Wednesday, 29 May 2019 at 03:16:19 UTC, Nicholas Wilson wrote: On Tuesday, 28 May 2019 at 09:41:18 UTC, Njagi Mwaniki wrote: Hello I’m Njagi Mwaniki, I am part of the 2019 Google Summer of Code under the Open Bioinformatics Foundation with a project aimed to add variation graph support to BioD under mentors George Githinji and Pjotr Prins. Awsome! can you supply some links please? I don't have a lot of links but the D lib is here https://github.com/biod/biod I'm prototyping a bit of the data structures here in racket https://github.com/urbanslug/GSoC-experiments I plan on writing blog posts soon explaining the graph, it's implementation and progress as well.
Re: Variant Graph Support to BioD
On Tuesday, 28 May 2019 at 21:24:54 UTC, James Blachly wrote: On 5/28/19 5:41 AM, Njagi Mwaniki wrote: Hello I’m Njagi Mwaniki, I am part of the 2019 Google Summer of Code under the Open Bioinformatics Foundation with a project aimed to add variation graph support to BioD under mentors George Githinji and Pjotr Prins. ... VG is a set of tools that already implements variation graphs but which is a bit broad in its focus. In this project we are building upon the existing tools and knowledge from VG and looking for ways to improve its performance in terms of lookups and also its application with small genomes, specifically viruses and smaller mammals such as mice. This sounds like a great project. Be aware that the size of the organism (e.g. mouse) has naught to do with the size of its genome. Thank you. With regards to the complexity of the genome, we're starting with a very small virus dataset and building up from it https://github.com/urbanslug/GSoC-experiments/tree/master/data/RSV/refererence_and_vcf_file The mouse is a possible application area of the genome really and a good place to test the robustness of the tool.
Re: GtkD 3.9.0, A GTK+ D binding.
On Wednesday, 29 May 2019 at 20:30:03 UTC, Mike Wey wrote: And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org Great stuff, thanks for your work. Jordan
Re: GtkD 3.9.0, A GTK+ D binding.
On Wednesday, 29 May 2019 at 20:30:03 UTC, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. At this point it feels long overdue, but finally there is an GtkD release that is updated for the latest GTK+ libraries. And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org Full changelog: https://gtkd.org/changelog.html Download: https://gtkd.org/download.html So cool! I guess it will be a lot of work to get the bindings and wrapper to the upcoming GTK 4...
GtkD 3.9.0, A GTK+ D binding.
GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. At this point it feels long overdue, but finally there is an GtkD release that is updated for the latest GTK+ libraries. And i finally took the time to change the documentation on the website from candydoc to one generated by Adam's adrdox. https://api.gtkd.org Full changelog: https://gtkd.org/changelog.html Download: https://gtkd.org/download.html -- Mike Wey
Re: nogc v0.5.0 - DIP1008 works!
On 29.05.19 18:37, Valeriy Fedotov wrote: In my point of view @trusted means "I use pointer-related operations correctly. Also I am using all @system interfaces correctly". @trusted means: "This function is as safe as an @safe function. But the compiler doesn't verify the implementation." Whether you use anything correctly only matters when it affects safety. And "being safe" means that the function doesn't exhibit undefined behavior (when called with valid inputs), and that it doesn't lead to undefined behavior in @safe code that is executed later on (e.g., an @trusted function must not return an invalid pointer). [...] If a user supplies mallocator that is not correct, there are two possibilities: - Allocator is buggy. Nothing to do with @trusted code. - Allocator do not conforms to allocator interface. User has broken the contract. Nothing to do with @trusted code. In my example, UnsafeAllocator is correct. It's not buggy, and it conforms to the allocator interface (which doesn't require @safe methods). Still the program exhibits memory corruption. So there must be something else that's wrong. The problem is that I'm setting UnsafeAllocator.instance.i to bad values which leads to out-of-bounds accesses. I do that in the @safe `main`. You might say: "Don't do that then. It's your own fault if you do that. Your mistake is not the library's fault." But D's @safe is supposed catch exactly that kind of mistake. The point of @safe is that I can make all the mistakes in the world in @safe code (except typing out "@trusted") without ever seeing memory corruption. I think we should keep in mind not only technical aspects of @trusted and @system, but this contract too. No. A contract that can be broken in @safe code cannot be relied upon in @trusted code. This is fundamental to D's safety system.
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 14:26:16 UTC, ag0aep6g wrote: Oh, yeah. Getting @trusted right is hard. Getting it right when user-provided types are involved is extra hard, because you can't even trust fundamental operations like assignment or copying. In my point of view @trusted means "I use pointer-related operations correctly. Also I am using all @system interfaces correctly". The code in question uses allocator interface correctly. User of this code has a contract to supply allocator that conforms to this interface. If a user supplies mallocator that is not correct, there are two possibilities: - Allocator is buggy. Nothing to do with @trusted code. - Allocator do not conforms to allocator interface. User has broken the contract. Nothing to do with @trusted code. I think we should keep in mind not only technical aspects of @trusted and @system, but this contract too.
Re: Reloaded Vibes: Smart auto-reloading service and server for (web) development.
On Monday, 13 May 2019 at 21:56:11 UTC, 0xEAB wrote: [1] https://github.com/voidblaster/reloaded-vibes [2] http://reloaded-vibes.dub.pm/ Reloaded Vibes v0.2.0 was released today. Let me summarize what changed: - First, the executable's target name changed (from `reloaded-vibes`) to simply `rlv`. - Most importantly, the UI got improved. - The startup info shows up above all. - Sockets in startup info are now shown as URLs. --> Allows terminals can interpreted them as links. - Action commands outputs are cleanly separated with dashed lines. - The manual was slightly enhanced. - In previous releases, Reloaded Vibes wouldn't detect changes when there were no active websocket connections, and therefore no action commands did get executed in such a case. This is finally fixed. (Note: --noservice mode wasn't affected.) Go check it out: https://github.com/voidblaster/reloaded-vibes/releases/tag/v0.2.0 Kind regards, Elias
Re: D GUI Framework (responsive grid teaser)
On Wednesday, 29 May 2019 at 05:56:45 UTC, Nick Sabalausky (Abscissa) wrote: I think I still have a stack of floppies from an early version of MS Visual C/C++. Plus similar floppy stacks from other 90's compilers[1] But 31 install disks is quite impressive, I'm not sure I can match that[2]. I tip my retro-hat to you, good sir! [1] I realize others have me beat here, but just the memory of taking college classes that utilized Visual Basic 6 makes me feel old... My first assembler for the C64 loaded from tape… so I had to reload everything from tape every time my program crashed… On the other hand, it made you look very closely at the code before you ran it…
Re: D-Scanner 0.7.2 (and dparse 0.11.5)
On Wednesday, 29 May 2019 at 11:17:22 UTC, user1234 wrote: D-Scanner 0.7.2 was released yesterday, justified by a couple of bug fixed. This version relies on dparse 0.11.5 which is (exceptionally) a branch with backports. All the tools will be upgraded to use dparse 0.13.0 during the summer. See https://github.com/dlang-community/D-Scanner/releases/tag/v0.7.2 for more details. Sorry i just see that the pre built binaries were not uploaded this time. This should still work with dub though.
D-Scanner 0.7.2 (and dparse 0.11.5)
D-Scanner 0.7.2 was released yesterday, justified by a couple of bug fixed. This version relies on dparse 0.11.5 which is (exceptionally) a branch with backports. All the tools will be upgraded to use dparse 0.13.0 during the summer. See https://github.com/dlang-community/D-Scanner/releases/tag/v0.7.2 for more details.
D:YAML 0.8.0
D:YAML 0.8.0 was released a few days ago. D:YAML is a project for reading or writing yaml files, 100% written in D. The project is getting closer to a 1.0 release, which means official test suite supported and more D-ish way of doing stuff (range or less class for example). see https://github.com/dlang-community/D-YAML/releases/tag/v0.8.0 for more details. User of D:YAML might encounter breaking changes in this release, as the project follows the semantic of semver.
LDC 1.16.0-beta2
Glad to announce the second beta for LDC 1.16:
* Based on DMD stable from 2 days ago (with an unusually high
number of fixes since 2.086.0).
* Non-Windows x86: Faster `real` versions of std.math.{tan,expi}.
* Windows: Fix linking DLLs with MinGW-based libs.
* WebAssembly: No need for an explicit `-L--export-dynamic`
anymore.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0-beta2
Please help test, and thanks to all contributors!
Re: D GUI Framework (responsive grid teaser)
On 5/28/19 6:50 PM, Abdulhaq wrote: On Tuesday, 28 May 2019 at 20:54:59 UTC, Robert M. Münch wrote: . The software we sell, would still fit on one floppy disk (if there are still people knowing what it is). And I'm always saying: "Every good software fits on one floppy-disk." Most people can't believe that this is still possible. I'd argue games are the obvious exception, just on account of the graphics/sound/etc assets, but you definitely make a fair point. I remember VisiCalc.com. And I remember when no program would need more than 640k RAM. But I also remember installing msoffice from 31 floppy discs I think I still have a stack of floppies from an early version of MS Visual C/C++. Plus similar floppy stacks from other 90's compilers[1] But 31 install disks is quite impressive, I'm not sure I can match that[2]. I tip my retro-hat to you, good sir! [1] I realize others have me beat here, but just the memory of taking college classes that utilized Visual Basic 6 makes me feel old... [2] I think my earliest version of Office is new enough to be on CD-ROM - back from the "Encarta" era - anyone remember that? I actually kinda miss it, it made heavier use of audio/video than Wikipedia does. Heck, it made the future seem much brighter than what we ended up with! (And, interestingly, it also served as an early example of MS disregarding their OS's UI design guidelines in their own apps. Still relevant today!)
