Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 00:45:53 UTC, Dennis Cote wrote: On Thursday, 12 October 2017 at 07:48:09 UTC, Vadim Lopatin wrote: Could you please submit issue on https://github.com/buggins/dlangide/issues Done. https://github.com/buggins/dlangide/issues/349 Thank you! Could you please attach ui.log of DlangIDE starting (while option override screen dpi is disabled - set to default).
Re: My first experience as a D Newbie
On Friday, 13 October 2017 at 06:01:25 UTC, Vadim Lopatin wrote: On Friday, 13 October 2017 at 00:45:53 UTC, Dennis Cote wrote: On Thursday, 12 October 2017 at 07:48:09 UTC, Vadim Lopatin wrote: Could you please submit issue on https://github.com/buggins/dlangide/issues Done. https://github.com/buggins/dlangide/issues/349 Thank you! Could you please attach ui.log of DlangIDE starting (while option override screen dpi is disabled - set to default). Forgot to add - use debug build - w/o --build=release
Re: My first experience as a D Newbie
On Thursday, 12 October 2017 at 03:50:31 UTC, Dennis Cote wrote: On Thursday, 12 October 2017 at 01:26:33 UTC, jmh530 wrote: You have to fetch it first if you don't already have it: dub fetch dlangide dub run dlangide Of course, you might still have an issue... I still have an issue on macOS using latest Homebrew version of dmd and dub. It seems like it builds with one deprecation warning, but fails to run. I fetched into an empty directory then run. All build and error message are in the link below: https://pastebin.com/FLQHwGXf It looks like SLD2 is missing, so I installed it via Homebrew and tried again. This time it runs but displays a window full of micro sized text and icons. It is barely readable. The link below leads to a screenshot showing the dlangide window and Dlang.org open in Safari for comparison. http://tinypic.com/r/20jiico/9 Not trying to slam dlangide (in fact it looks promising), but these kind of issues, when following the instructions given, show how incomplete or untested instructions can lead new users to have a frustrating first experience with D. Dennis Cote I've updated README on https://github.com/buggins/dlangide "Try DlangIDE" section is added with build instructions, DMD and DUB installation, libSDL2 installation, build troubleshooting.
Re: My first experience as a D Newbie
On Thursday, 12 October 2017 at 05:02:40 UTC, Dennis Cote wrote: On Thursday, 12 October 2017 at 03:50:31 UTC, Dennis Cote wrote: This time it runs but displays a window full of micro sized text and icons. It is barely readable. I figured out dlangide assumes a DPI setting of 96 which creates the tiny text and icons on my Retina display. Under preferences it shows the DPI as "Use Screen DPI (192)" but it actually uses that value only after I click the Apply button. Then the text and icons are displayed correctly. Looks like a small bug in dlangide initialization. I also noticed the check boxes in the preference dialog seem to display at 96 DPI (and are therefore very small) even after the display resolution is changed. Dennis Cote Hello, Could you please submit issue on https://github.com/buggins/dlangide/issues It looks like screen DPI is detected properly but not applied on start of app. Best regards, Vadim
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Monday, 25 September 2017 at 08:01:02 UTC, tchaloupka wrote: On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin wrote: On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote: On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote: How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too? Looks like repo owner thinks they are single threaded. Just checked threads of Go version. I see 7 'go' and 7 'main' threads. I've just tried this on my linux box (only dmd as ldc2 fails with release build - https://github.com/ldc-developers/ldc/issues/2280). rust: Requests/sec: 38757.2625 vibe-d:core libevent: Requests/sec: 27906.8119 vibe-d:core libasync: Requests/sec: 20534.3057 vibe-core: Requests/sec: 18042.4251 Didn't include the Go version as it's indeed using more threads. Results are just for the base url to not include the regex matching there. I've sent PR https://github.com/nuald/simple-web-benchmark/pull/11 to re-enable multithreading in D test app. BTW, does Rust version use multithreading?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote: On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote: How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too? Looks like repo owner thinks they are single threaded. Just checked threads of Go version. I see 7 'go' and 7 'main' threads.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote: How on earth can that be unfair when the Go, node.js and Scala versions appear to use multi-threading, too? Looks like repo owner thinks they are single threaded.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote: What's was the last status? Could you observe any meaningful thread scaling? It works for me - multithreading improves performance on my PC. So far, test results on https://github.com/nuald/simple-web-benchmark show that D is 2-3 times slower than any other language including node.js nuald reverted change which enables multithreading since it's "unfair".
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote: On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin It does. But Golang uses them, too. Goroutines. Indeed. I'm reading about them right now, and they seem to be "multiplexed". I wonder if Vibe.d does something similar. The fact that you've observed lower CPU usage by the D version makes me think some kind of scheduling or thread-priority issue is the cause. Fibers are being switched by waiting for signals/events. Waiting blocks thread. Timer should affect only non-blocked threads switching IMHO.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 18:49:00 UTC, bitwise wrote: On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin wrote: There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js): https://github.com/nuald/simple-web-benchmark I've sent PR to include D benchmark (vibe.d). I was hoping it could show performance at least not worse than other languages. But it appears to be slower than Go and even Node.js Are there any tips to achieve better performance in this test? Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower. Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go. I'm using DMD. Probably, ldc could speed up it a bit. Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests? Doesn't vibe-d use Fibers? I tried to build a simple web server with a fiber-based approach once - it was horribly slow. I hope C# (and soon C++) style stackless resumable functions will eventually come to D. It does. But Golang uses them, too. Goroutines.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 17:13:16 UTC, Daniel Kozak wrote: Ok, maybe there is a some small improvments, but it is nothing what would make this faster than rust and still undere 30K on my pc More test results: On my Win10 PC, DMD/x86/libevent:27-29K, Go:31-33K
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 13:46:49 UTC, Daniel Kozak wrote: Ok, after some more testing it seems it is almost sema with or without VibeManualMemoryManagement Do you see any benefits from using LDC instead of DMD?
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak wrote: wrong version, this is my letest version: https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR Thank you! Updated.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig
wrote:
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package
recipe. The old approach is planned to be faded out slowly,
because it requires some special DUB support that would be nice
to see gone at some point.
Thank you!
Trying to use multithreaded mode.
Under windows, best Vibe.d results are equal to results of Go
server.
Under linux, Vibe.d is still slower even if there are 4 threads
listening.
Results:
OS lang:config req/scomments
=== ===== ==
Linuxgo53K
LinuxD:default 48K 1 thread
LinuxD:libevent48K 1 thread
LinuxD:libasync46.5K4 threads
Windows go12K
Windows D:default 12K 4 threads
Windows D:libevent12K 4 threads
Windows D:libasync7K 4 threads
Under Linux in default and libevent configurations, I see error
messages from 3 of 4 threads - looks like only one thread can
process connections.
Failed to listen on 0.0.0.0:3000
Task terminated with uncaught exception: Failed to listen for
incoming HTTP connections on any of the supplied interfaces.
Re: Simple web server benchmark - vibe.d is slower than node.js and Go?
On Thursday, 21 September 2017 at 08:18:51 UTC, Suliman wrote: Can it be issue with regex speed? auto reg = ctRegex!"^/greeting/([a-z]+)$"; Did you try without it? Regex is used for request paths like "/greeting/username" and not used for path "/" There is no big slowdown caused by regex. 45.6K requests/second with regex vs 46.8K requests/second w/o regex.
Simple web server benchmark - vibe.d is slower than node.js and Go?
There is a simple set of simple web server apps written in several languages (Go, Rust, Scala, Node-js): https://github.com/nuald/simple-web-benchmark I've sent PR to include D benchmark (vibe.d). I was hoping it could show performance at least not worse than other languages. But it appears to be slower than Go and even Node.js Are there any tips to achieve better performance in this test? Under windows, I can get vibe.d configured to use libevent to show results comparable with Go. With other configurations, it works two times slower. Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only advantage of D here is CPU load - 90% vs 120% in Go. I'm using DMD. Probably, ldc could speed up it a bit. Probably, it's caused by single threaded async implementation while other languages are using parallel handling of requests?
Re: Deimos X11 bindings license question
On Tuesday, 12 September 2017 at 17:30:42 UTC, Basile B. wrote: On Monday, 11 September 2017 at 12:36:50 UTC, Vadim Lopatin wrote: On Monday, 4 September 2017 at 17:54:36 UTC, Vadim Lopatin wrote: Contributors to DUB package nomad-software/x11 nomad-software weltensturm Geod24 MartinNowak BBasile rikkimax Additionally, contributors to Deimos/libX11 growlercab bioinfornatics IanWizard WalterBright Looks like recreating of binding from scratch based on C headers could be faster than getting confirmation from all of contributors. We solved the issue **in less than 24 hours**: https://github.com/nomad-software/x11/blob/master/LICENSE Most of the "code owners" agreed to change the license. The list of pseudo has been really useful to ping everybody in one shot. The Social Network aspect of Github has helped much i believe. Cool! Very fast! I didn't believe it can be done. DlangUI does not violate license anymore :)
Re: Deimos X11 bindings license question
On Monday, 11 September 2017 at 13:41:39 UTC, rikki cattermole wrote: Needs more work but... https://github.com/Devisualization/spew/tree/master/src/utils/cf/spew/bindings/x11 yeah. Have you created this binding yourself w/o using of Deimos code?
Re: Deimos X11 bindings license question
On Monday, 4 September 2017 at 17:54:36 UTC, Vadim Lopatin wrote: Contributors to DUB package nomad-software/x11 nomad-software weltensturm Geod24 MartinNowak BBasile rikkimax Additionally, contributors to Deimos/libX11 growlercab bioinfornatics skilion CyberShadow Faianca Flamaros PhilipWitte edmccard arukuka IanWizard WalterBright Looks like recreating of binding from scratch based on C headers could be faster than getting confirmation from all of contributors.
Re: dub projects generate docs and host on code.dlang.org?
On Monday, 4 September 2017 at 10:47:47 UTC, Manu wrote: I've seen a lot of dub projects with embedded ddoc that follows phobos example. These projects are then hosted on code.dlang.org, but often, the docs are never generated and hosted anywhere. In the event they are, links to docs are ad-hoc and unpredictable, and the formatting/styling/etc is not standard/consistent. Suggest; code.dlang.org should attempt to generate ddoc for each hosted project, host it, and clearly link to it from the project front-page. Hosted docs should be styled consistently (matching phobos?). Having automatically updated docs hosted on code.dlang.org will motivate package developers to write better ddoc comments for their code. It will get library packages more usable, and attract more users.
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 10:14:02 UTC, Kagamin wrote: On Wednesday, 6 September 2017 at 10:05:18 UTC, Vadim Lopatin wrote: Unlike LGPL for which you can create closed source apps if library is linked dynamically, the only way to use derelict binding with LGPL license is GPL compatible license for your application. https://github.com/D-Programming-Deimos/libX11/blob/master/dub.json it doesn't look like it has any reference to derelict. Sorry, not a derelict, just header files translation as DUB package in https://github.com/nomad-software/x11
Re: Deimos X11 bindings license question
On Wednesday, 6 September 2017 at 09:23:33 UTC, Kagamin wrote: On Sunday, 3 September 2017 at 16:10:11 UTC, Gary Willoughby wrote: My question, is there a legal way to change the current license to Boost or MIT or something like? Because this particular developer wanted to use it in a project where LGPL was incompatible. [1]: https://github.com/D-Programming-Deimos/libX11 [2]: https://github.com/nomad-software/x11 I thought x11 has MIT flavor license. Where LGPL comes from? If x11 is LGPL licensed header license doesn't affect anything: application of LGPL is determined by linking. Though GPL and/or LGPL have an exception for system libraries. Under LGPL, Deimos libX11 has been released. For binding library, LGPL is actually the same as GPL since it's linked statically. Unlike LGPL for which you can create closed source apps if library is linked dynamically, the only way to use derelict binding with LGPL license is GPL compatible license for your application.
Re: dub projects generate docs and host on code.dlang.org?
On Monday, 4 September 2017 at 10:47:47 UTC, Manu wrote: I've seen a lot of dub projects with embedded ddoc that follows phobos example. These projects are then hosted on code.dlang.org, but often, the docs are never generated and hosted anywhere. In the event they are, links to docs are ad-hoc and unpredictable, and the formatting/styling/etc is not standard/consistent. Suggest; code.dlang.org should attempt to generate ddoc for each hosted project, host it, and clearly link to it from the project front-page. Hosted docs should be styled consistently (matching phobos?). Thoughts? - Manu It would be really useful feature!
Re: Deimos X11 bindings license question
On Sunday, 3 September 2017 at 16:51:53 UTC, Mike Parker wrote: On Sunday, 3 September 2017 at 16:10:11 UTC, Gary Willoughby wrote: Hi, A few years ago I forked the Deimos X11 bindings[1] repo to add dub support. Since then my repo[2] has received bug fixes and as such it's being used in many projects. (Also, in the following years dub support was added to the Deimos repo too.) I had a question from a developer as to the license of the code in my repo. I used the LGPL because the original used it. My question, is there a legal way to change the current license to Boost or MIT or something like? Because this particular developer wanted to use it in a project where LGPL was incompatible. [1]: https://github.com/D-Programming-Deimos/libX11 [2]: https://github.com/nomad-software/x11 When I first created the DerelictSDL bindings, the SDL library was LGPL (though it's since switched to MIT). I contacted Sam Lantinga (the creator of SDL) to get his take on it. He told me that his understanding was that an API binding is not a derivative work and therefore can have a separate license. I got the same answer from others. None of these folks were, or are, lawyers, but they all work for companies that have to be aware of such issues. So I felt as safe as I could be sans legal advice in licensing all of the Derelict packages under Boost. That said, I don't know if the Oracle v. Google case and its precedent that APIs are copyrightable impact this common understanding. After all, it was commonly understood prior to that case that that copyright applies to implementations, not interfaces. Now that the court has established the opposite, does the same hold true for licensing? I don't know of any legal cases that have decided either way. It looks like we need to get permission from 17 developers - all x11 binding contributors. Contributors to DUB package nomad-software/x11 nomad-software weltensturm Geod24 MartinNowak BBasile rikkimax Additionally, contributors to Deimos/libX11 growlercab bioinfornatics skilion CyberShadow Faianca Flamaros PhilipWitte edmccard arukuka IanWizard WalterBright
Re: Editor recommendations for new users.
On Tuesday, 29 August 2017 at 08:15:08 UTC, Vadim Lopatin wrote: On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote: So I will be doing a workshop on programming for the biology department at my university and I was wondering what would best suit the users. The following are a must: support windows & mac ( the more consistent between the two the better) free no large install footprint, preferably simple install procedure (running on laptops) syntax highlighting straightforward to use anything else is a bonus. Whats your experience with what you use? Many thanks Nic Try DlangIDE : https://github.com/buggins/dlangide Simple IDE with DUB based project format, uses DUB to fetch dependencies, build and run projects. Support of basic debugging. Syntax highlight, code completion, go to definition - using DCD. Supports Windows, mac, linux. Precompiled binaries for Windows: https://github.com/buggins/dlangide/releases Distribution size for Windows - 5.4Mb zipped. Includes DUB and mago-mi debugger. For Mac, it's easy to build it using DUB. New DlangIDE version v0.7.60 is released. Windows binaries are available here https://github.com/buggins/dlangide/releases
Re: Events in D
On Tuesday, 29 August 2017 at 05:10:25 UTC, bitwise wrote: I needed some C# style events, so I rolled my own. Long story short, the result was unsatisfactory. Library based events are inadequate for basically the same reasons as library based properties (often suggested/attempted in C++). The problem is that the properties/events don't have access to the fields or methods of the containing object, and as such, incur the cost of an extra pointer per event/property, or worse, a delegate if custom behavior per event is needed, in order to provide that access. One obvious example would be synchronized properties/events. Anyways, I threw together some code while thinking about what an event may look like in D: DlangUI includes signal/slot event implementation. https://github.com/buggins/dlangui/blob/master/src/dlangui/core/signals.d
Re: Editor recommendations for new users.
On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote: So I will be doing a workshop on programming for the biology department at my university and I was wondering what would best suit the users. The following are a must: support windows & mac ( the more consistent between the two the better) free no large install footprint, preferably simple install procedure (running on laptops) syntax highlighting straightforward to use anything else is a bonus. Whats your experience with what you use? Many thanks Nic Try DlangIDE : https://github.com/buggins/dlangide Simple IDE with DUB based project format, uses DUB to fetch dependencies, build and run projects. Support of basic debugging. Syntax highlight, code completion, go to definition - using DCD. Supports Windows, mac, linux. Precompiled binaries for Windows: https://github.com/buggins/dlangide/releases Distribution size for Windows - 5.4Mb zipped. Includes DUB and mago-mi debugger. For Mac, it's easy to build it using DUB.
Re: Jetbrains announce support for rust plugin, show them we want one too!
On Friday, 11 August 2017 at 11:34:44 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 9 August 2017 at 07:59:46 UTC, Ryion wrote: this here because its obvious pattern. I agree that this seems to be a very small community and it is hard to get things done in a small community. But it is counter productive to constantly tell people that there is no solution, they need to do it or pay for it. Its like hearing a broken record that keeps skipping to the same beat. It's a sign of a lack of strategy. Other languages such as Dart had an IDE strategy from the start. Dart even provided a full Eclipse based IDE until JetBrains included support (then the Dart team dropped their own IDE). Without a central organized IDE project it will be hard to reach maturity for any such effort (unless the language is popular to sustain the development of a commercial IDE). I think having IDE for some language written in the same language may show power and usability of this language. E.g. DlangIDE is written in D, uses cross-platform GUI library DlangUI which is written in D, and is cross-platform. May work even as console app. For D programmers, it's easy to contribute something to IDE written in D than to some Java or C++/C# project. Active contributing to DlangIDE can make it really useful tool. So far, it's less usable than Visual-D or Mono-D. So far, I myself use Visual-D to develop D projects (including DlangIDE), but I hope there will be a point when it would be possible to switch to DlangIDE. I'm thinking about killer feature - adding Delphi like UI designer for writing DlangUI/DML apps. Having IDE similar to Delphi or Lazarus would be great advantage of D.
Re: "I made a game using Rust"
On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote: Interesting thread I got from Reddit, someone made a game for PC and mobiles fully in Rust. https://michaelfairley.com/blog/i-made-a-game-in-rust/ "Last week, I released A Snake’s Tale on iOS, Android, Windows, Mac, and Linux.". I wonder, would it be possible for D in the current state to achieve the same? I imagine iOS isn't possible yet and Android is just getting there? DlangUI has Android support. You can develop and debug game on desktop, then build for Android.
Re: Gui in D: I miss this project
On Monday, 16 January 2017 at 07:38:31 UTC, Jacob Carlborg wrote: On 2017-01-16 07:28, Vadim Lopatin wrote: Windows support in DlangUI is not native since it does not use native controls. DlangUI draws widgets itself on all platforms. But on Win32 it's possible to build app which uses Win32 API only, and no additional DLLs will be required to run it. On Linux and Mac, there is extra dependency - libSDL2. For most application on macOS, a non-native GUI library is not interesting. There is a workaround: it's possible to create DlangUI theme which looks like native OSX app.
Re: Gui in D: I miss this project
On Saturday, 14 January 2017 at 10:58:38 UTC, Dukc wrote: Which platforms do dlangui work on? It's console feature is cool, I do that with terminal.d rather than simpledisplay.d. I guess the other difference is probably Mac, I only support it there with the X11 thing installed, which Apple no longer supports. I kinda want to wait till there's Objective-C integration in there though. If I understood the package description correctly, it supports Windows, Linux and Mac. Windows natively, so the complains about non-nativity are only partially true. Plus at least Mac native support is worked on. I also read somewhere, perhaps the official blog, that it works with Android at least to some extent. Windows support in DlangUI is not native since it does not use native controls. DlangUI draws widgets itself on all platforms. But on Win32 it's possible to build app which uses Win32 API only, and no additional DLLs will be required to run it. On Linux and Mac, there is extra dependency - libSDL2.
Re: Gui in D: I miss this project
On Friday, 13 January 2017 at 22:55:03 UTC, Adam D. Ruppe wrote: On Friday, 13 January 2017 at 20:11:08 UTC, Dukc wrote: Does not work on as many platforms as DlangUI, trough. Which platforms do dlangui work on? It's console feature is cool, I do that with terminal.d rather than simpledisplay.d. I guess the other difference is probably Mac, I only support it there with the X11 thing installed, which Apple no longer supports. I kinda want to wait till there's Objective-C integration in there though. DlangUI platforms: Win, Linux, OSX, Android. It's easy to add new platforms (each new platform requires writing 2-3K lines of code).
Re: Gui in D: I miss this project
On Wednesday, 11 January 2017 at 15:56:46 UTC, Chris Wright wrote: On Wed, 11 Jan 2017 07:21:22 +, thedeemon wrote: If you need some GUI, DLangUI is just a "dub build" away. How does DLangUI do with screen readers and magnifiers? From what I'm seeing, neither GTK+ nor Qt work with screen readers anad other assistive technologies. wxWidgets has some accessibility bugs (wxGrid is invisible to screen readers). DLangUI uses OpenGL, so it's less likely to support screen magnifiers (and equally unlikely to support screen readers). Checked magnifier under Windows. Works ok for DlangUI apps built with OpenGL support as well as software renderer (configuration="minimal"). If OpenGL is stopper for magnifier on other platforms, it's possible to try minimal configuration. Currently DlangUI does not support screen readers. I'm not sure what is API to support screen readers. If there should be ability to get control text from window by X,Y - it can be added easy.
Re: Replace/Rename DWT forum with GUIs forum?
On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote: I would like to suggest that the existing DWT forum be renamed or replaced with a more generic GUIs forum. As far as I can tell, the DWT forum doesn't get much traffic these days and I don't believe any of the current GUI options for D are sufficiently popular to warrant their own specific forum. While I primarily work with and have an interest in GtkD, I'm interested in posts with regards to all of the available GUI options (GtkD, DLangUI, etc) for D since I have general interest in desktop applications. I think grouping everything in one forum, similar to what is done for IDEs and Debuggers, would bring together posts and people that share a common interest. UP Can't we add forum for GUIs?
Re: Replace/Rename DWT forum with GUIs forum?
On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote: I would like to suggest that the existing DWT forum be renamed or replaced with a more generic GUIs forum. As far as I can tell, the DWT forum doesn't get much traffic these days and I don't believe any of the current GUI options for D are sufficiently popular to warrant their own specific forum. While I primarily work with and have an interest in GtkD, I'm interested in posts with regards to all of the available GUI options (GtkD, DLangUI, etc) for D since I have general interest in desktop applications. I think grouping everything in one forum, similar to what is done for IDEs and Debuggers, would bring together posts and people that share a common interest. +1
Re: Why D is not popular enough?
On Monday, 22 August 2016 at 07:05:01 UTC, Shachar Shemesh wrote: On 22/08/16 09:31, Vadim Lopatin wrote: On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh - No RAII support, despite the fact everybody here seems to think that D supports RAII. Shachar There IS RAII in D. I'm using it in DlangUI extensively for managing resources. Then, depending on your precise use, you might have leaks. To avoid leaks, it's necessary to prevent destructor calling from GC for objects which hold resources - they have to be called manually via destroy() or by some RAII technique. I'm using Reference Counting.
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote: I'll give some highlights, but those are, mostly, things that I've already listed in this forum and in my lightening talk. - No RAII support, despite the fact everybody here seems to think that D supports RAII. Shachar There IS RAII in D. I'm using it in DlangUI extensively for managing resources.
Re: Using electron for IDE development
On Monday, 4 July 2016 at 18:25:51 UTC, tcak wrote: As far as I known, and FEEL, one of the biggest problems of IDE development is cross platform user interface development. I'm working on cross-platform D IDE based on cross-platform GUI library. Works on Linux, Windows, OSX, and may be easy ported to other OS if necessary. Written in D, so I suppose contributing to it might be easy for D developers. (assuming it may be more attractive to program in D than in JS, Java or C#). My IDE has syntax highlight, debugging support, auto-completion, go-to-definition, DUB support and many other features. Current state is almost usable. But only a few people were interested in contributing to this project.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 08:21:22 UTC, ketmar wrote: On Monday, 6 June 2016 at 08:15:42 UTC, Russel Winder wrote: 3. Have one lightweight D realized cross platform IDE. by the way, Buggins has dlangIDE written with his dlangUI package. it is cross-platform, has debugger support, and written in D! As well, it's only a few megabytes in size. On Windows it can be bundled with mago-mi debugger to avoid Visual Studio dependencies.
Re: the most D-ish GUI library
On Wednesday, 16 March 2016 at 19:56:42 UTC, Saša Janiška wrote: What about integration with Mac OS, iirc, it has some (strange to me) habit of stealing app's functions and display them as system function or something (I recall trying to finish some video work on friend's laptop using Premiere and it was unforgettable experience which lead me to think what do the people really fond of with that OS... Currently DlangUI uses libSDL2 as a backend for OSX. Most wanted feature for OSX is not a look & feel, but support of native OSX menu. (Same for Gnome and other DEs with common menu bar) Not sure if it's easy to use OSX system theme resources in DlangUI. Best regards, Vadim
Re: the most D-ish GUI library
On Tuesday, 15 March 2016 at 22:26:15 UTC, Karabuta wrote: DlangUI has a nice API design but still need serious design and art work to catch up with Gtk 3.18 - 2.0 in terms of UI look and feel. I also find that it just have basic widgets. With Gtk you have Switch, Stack, Notebook, HeaderBar, and many modern input widgets for a modern GUI toolkit. Some of such widgets are easy to implement. Switch - just need to add new style for button to theme. Switch, Stack, Notebook, HeaderBar - new styles for TabHeader, TabHost, TabWidget Can be implemented in one day. Some other controls like Rich Edit or HTML view are much harder to implement, and require a lot of development time. Making of OSX native looking controls seems easy - new theme based on OSX screenshots is to be created.
Re: the most D-ish GUI library
On Sunday, 13 March 2016 at 22:49:30 UTC, Chris Wright wrote: dlangui will be consistent on different platforms. However, what I've seen in it doesn't support antialiasing, so it's kind of ugly. DlangUI does support antialiasing for font rendering and as well provides some enhancements like Gamma setting for fonts. Although, subpixel antialiasing (aka Clear Type) is supported only for software rendering. (I've not managed to implement it using OpenGL shader).
Re: What are the real GUI toolkits for D?
On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote: Except for GtkD and DWT, D does not seem to be supported by a really nice GUI toolkit. Anyway, a serious programming language nowadays should have a lot more support in that area. I have not tried GtkD yet, but it seems the most promising. Many projects have started to create a GUI toolkit (or wrapper), but now they are abandoned. Are there any plans to really support the development of standard GUI toolkit? What kind of GUI app are you going to make? For some cases, DlangUI could be good choice https://github.com/buggins/dlangui * Native D implementation (not a wrapper) * Cross platform Windows/Linux/OSX * Customizable look&feel using themes * OpenGL accelerated drawing (optional) * If necessary, custom OpenGL drawing may be mixed with widgets Sample big project which utilizes DlangUI is DlangIDE - D language IDE written in D. https://github.com/buggins/dlangide Some screenshots (outdated): http://buggins.github.io/dlangui/screenshots.html
Re: D is on his way to Top 20 in Tiobe
On Friday, 11 December 2015 at 15:29:52 UTC, Ola Fosheim Grøstad wrote: D/PowerNex 29 stars D/DMD 27 stars D/dlangui 13 stars Surprised to see dlangui in top.
Re: Is dlangui dead?
On Wednesday, 11 November 2015 at 08:21:48 UTC, ponce wrote: On Wednesday, 11 November 2015 at 07:18:21 UTC, Vadim Lopatin wrote: On Wednesday, 11 November 2015 at 06:56:10 UTC, Vadim Lopatin wrote: [...] UPD: found interesting library - https://github.com/p0nce/DerelictCocoa I hope it would help It was used to implement the Cocoa windowing for dplug: https://github.com/p0nce/dplug/blob/master/window/dplug/window/cocoawindow.d It's likely you will miss some stuff, use PRs. Great! I'll send PRs if would add some missing functionality.
Re: Is dlangui dead?
On Wednesday, 11 November 2015 at 06:56:10 UTC, Vadim Lopatin wrote: On Wednesday, 11 November 2015 at 06:25:35 UTC, Suliman wrote: [...] I'm not going to use native controls, only native way to create window, draw bitmap on it (or draw using OpenGL). Look and feel may be changed by correction of theme and resource files. [...] I don't see native OSX window implementation here. Implementation of OSX API accessors may be shared between different projects, and put to separate library in DUB registry. [...] It looks like DQuick uses SDL, as DlangUI does currently. I'm looking for native Cocoa based implementation. UPD: found interesting library - https://github.com/p0nce/DerelictCocoa I hope it would help
Re: Is dlangui dead?
On Wednesday, 11 November 2015 at 06:25:35 UTC, Suliman wrote: On Wednesday, 11 November 2015 at 06:19:05 UTC, Vadim Lopatin wrote: On Thursday, 5 November 2015 at 08:25:52 UTC, FreeSlave wrote: On Thursday, 5 November 2015 at 06:36:13 UTC, Vadim Lopatin wrote: Hi! I'm back on DlangUI project. Fixed some issues recently, and got it working with recent DMD beta and latest versions of dependency libraries. That's good news! I'm working on native OSX backend for DlangUI - to avoid SDL usage. Could someone point at sample D apps which can create window, draw, process mouse/keyboard event using Cocoa from D code? Best regards, Vadim To be honestly, I'd prefer native toolkit and for Windows too. OpenGL look ugly. I'm not going to use native controls, only native way to create window, draw bitmap on it (or draw using OpenGL). Look and feel may be changed by correction of theme and resource files. Maybe you should talk with Rikki https://github.com/rikkimax/alphaPhobos ? He are working on parts related with GUI stuff. I don't see native OSX window implementation here. Implementation of OSX API accessors may be shared between different projects, and put to separate library in DUB registry. Also there was good, but now dead attempted with GUI here https://github.com/D-Quick/DQuick It looks like DQuick uses SDL, as DlangUI does currently. I'm looking for native Cocoa based implementation.
Re: Is dlangui dead?
On Thursday, 5 November 2015 at 08:25:52 UTC, FreeSlave wrote: On Thursday, 5 November 2015 at 06:36:13 UTC, Vadim Lopatin wrote: Hi! I'm back on DlangUI project. Fixed some issues recently, and got it working with recent DMD beta and latest versions of dependency libraries. That's good news! I'm working on native OSX backend for DlangUI - to avoid SDL usage. Could someone point at sample D apps which can create window, draw, process mouse/keyboard event using Cocoa from D code? Best regards, Vadim
Re: Is dlangui dead?
On Thursday, 5 November 2015 at 08:25:52 UTC, FreeSlave wrote: On Thursday, 5 November 2015 at 06:36:13 UTC, Vadim Lopatin wrote: Hi! I'm back on DlangUI project. Fixed some issues recently, and got it working with recent DMD beta and latest versions of dependency libraries. That's good news! Feel free to submit feature requests, bugs, pull requests.
Re: Is dlangui dead?
On Sunday, 25 October 2015 at 20:56:22 UTC, thedeemon wrote: On Tuesday, 20 October 2015 at 17:01:19 UTC, karabuta wrote: I hope I am wrong, but dlangui seems to be abandoned for some time after all the hard work that went into it. I really like it since it was easy to setup and get things working. Maybe the author decided it's "done and ready"? In fact, I consider it the best option. Yep, I'm using it in one important project and several small ones. So with Vadim or without, DlangUI will live. Hi! I'm back on DlangUI project. Fixed some issues recently, and got it working with recent DMD beta and latest versions of dependency libraries.
Re: std.database
On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole wrote:
On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
Shouldn't the statement be reusable?
Yes it should. I added this use case:
auto stmt = con.statement("insert into table values(?,?)");
stmt.execute("a",1);
stmt.execute("b",2);
stmt.execute("c",3);
struct Table;
Table a, b, c;
con.insert!Table(a);
...
if you use CTFE to create the statement string there is no
reason to
reuse it.
it will be string literal, that's even better! Think Big.
Think D
the other code is Java not D
Then you open up table names, property serialization ext. ext.
Please no.
That is an ORM's job. I'm saying this from experience.
Similar project: DDBC https://github.com/buggins/ddbc
Inspired by Java JDBC API.
Currently supports MySQL, PostreSQL, SQLite.
Re: D for Android
On Thursday, 7 May 2015 at 15:58:01 UTC, Joakim wrote: On Sunday, 17 August 2014 at 18:19:29 UTC, Joakim wrote: I'll keep updating the wiki with more info, how to build for the command-line and run the druntime/phobos unit tests, along with directions for future work. An update: I tinkered with ldc and Android/ARM for the hackathon. Didn't get that working yet, but I took Dan Olson's advice to reuse the existing llvm TLS function calls and got ldc to work with Android/x86 a couple days ago. 41 of 42 druntime modules' tests pass: only core.internal convert doesn't, but that module's tests aren't normally run by ldc anyway. Around 15 of 71 phobos modules' tests fail somewhere, most likely related to "long double" issues that either need to be backported, as git master for ldc is still using a year-old druntime/phobos that doesn't have some subsequent Android PRs, or fixed, but I haven't looked into those much yet. Obviously, I can reuse some of this work for Android/ARM, so it should help. I'm putting these in-progress patches online, in case my ultrabook gets run over by a bus or someone else would like to tinker with them. All it required was a small patch to llvm: https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a and these patches for ldc, druntime, and phobos: https://gist.github.com/joakim-noah/bb0b04965470332d10e4 https://gist.github.com/joakim-noah/c27a0c7f2b5b65cdc268 https://gist.github.com/joakim-noah/07ed7ab1e5732ab91126 Most of the druntime and phobos patches were backported from PRs already committed in their respective master branches. The only real new work is in druntime's rt.sections_ldc. It's all a bit hacky right now, but I'll clean it up and submit PRs eventually. I tried the same approach that worked on x86 on ARM, with the similar ARM GOT relocation as can be seen in the llvm patch above, but it didn't work. I'm reading up on the relevant ELF relocation info and looking at the ARM assembly. If anybody better versed with those low-level linker details would like to chip in, that should be the last remaining piece to get much of Android/ARM working. Good news! Thank you for your work! Once Android support become working, I'm planning to add Android support to DlangUI library. It's actually a port of C++ UI library I'm using on Android for Cool Reader GL app. So it should not be hard to port it back to Android. Best regards, Vadim
Re: Standard GUI framework inspired by Qt
On Friday, 6 March 2015 at 09:09:43 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. The only reasonable approaches these days are either: ... 3. A very efficient OpenGL based composite engine that do 60hz redraws and that can be integrated in a fullscreen OpenGL app/game. This is really the best approach now that mainstream GPUs can do 60hz refresh without hickups. But it is not easy to get right. ... DlangUI does it if built with version=USE_OPENGL Can draw UI on top of OpenGL scene.
Re: Standard GUI framework inspired by Qt
On Thursday, 5 March 2015 at 15:09:55 UTC, Aram wrote: On Thursday, 5 March 2015 at 13:38:58 UTC, Vadim Lopatin wrote: Probably DlangUI fits your requirements. https://github.com/buggins/dlangui It's written in D, so can be easy extended. Cross platform - backend part is separated, and new platforms support can be added. So far, win32 and SDL2 backends are implemented. There is as well X (XCB) backend, but now it's abandoned. Look and feel can be customized using themes and styles. Unfortunately, if it doesn't cover all major PC platforms, it doesn't suit me (Mac OS is not supported). I would like to have all backends working on all platforms, as I lack knowledge to implement my own backends for X and Mac OS. Why not? SLD2 backend works ok on Mac (as well as on linux and windows). But on mac native menus are not supported. Instead, menu is show at the top of window.
Re: Standard GUI framework inspired by Qt
On Tuesday, 3 March 2015 at 18:43:50 UTC, Aram wrote: Hi all I've been thinking over a GUI framework for D for some time, and ended up with idea expressed by Andrew Fedoniouk here: http://www.digitalmars.com/d/archives/digitalmars/D/32633.html. That is, having a separate drawing layer, and widgets built on top of it. But since it has already been discussed 9 years ago, I wonder if such a framework has ever been implemented. In that duscussion many participants agreed that Qt would be a good foundation, but had very restrictive license. Things have changed since then, and Qt now is available under LGPL, which, to my undestanding, makes it suitable for the purpose of standard GUI library (please correct me if I am wrong on this). The license, of course, may change in the future, preventing us from using their updates for our drawing engine. But if we are able to start using the engine now, in the future we can maintain the updates ourselves. Now, how I envision the library's design: The library will be mostly implemented in D, except for drawing engine and event loop, which are system-dependent. Those two parts will be extracted from Qt into a separate library which will be linked to by the rest of framework either statically or dynamically. There will be bindings for sending drawing instructions to drawing engine, as well as for retrieving system and GUI events from event loop. The system-independent part will mimic architecture of Qt. However, for maximum flexibility and customizability, GUI will utilize QML+CSS approach, and Qt's layout manager classes will be dropped completely. Also there is no need to port classes that are available in D, such as collections and strings. If there is no standard GUI for D yet, and if LGPL license fits our purpose, then I am looking for 2-3 Qt experts to join me and build the framework. Thanks, Aram Probably DlangUI fits your requirements. https://github.com/buggins/dlangui It's written in D, so can be easy extended. Cross platform - backend part is separated, and new platforms support can be added. So far, win32 and SDL2 backends are implemented. There is as well X (XCB) backend, but now it's abandoned. Look and feel can be customized using themes and styles.
Re: H1 2015 - db access support in Phobos
On Wednesday, 4 February 2015 at 16:46:19 UTC, Andrei Alexandrescu wrote: On 2/1/15 8:00 PM, Vadim Lopatin wrote: I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). [snip] I think we should use ODBC as the foundation and build neat D-ish stuff on top of it. It's a mature technology with tried and tested drivers available on all major OSs. Mark Isaacson built an ODBC driver for Presto in D while an intern at Facebook: https://github.com/prestodb/presto-odbc. We should write the corresponding ODBC client part and create D abstractions on top of it. Andrei IMHO, ODBC support may be implemented as a driver, as it's done in other DB access libraries. E.g. we have native mysql client written in D - mysqln. It allows to access MySQL w/o external dependencies. As well, accessing of SQLite DBs via ODBC seems weird.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 15:20:41 UTC, Vadim Lopatin wrote:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
IMO writing:
foreach(it; db.select("...")) {
}
is epic. you have entered std.(range|algorithm) land.
Implemented in v0.2.17 for select.
test:
auto ds = new ConnectionPoolDataSourceImpl(new
SQLITEDriver(), "ddbctest.sqlite");
auto conn = ds.getConnection();
scope(exit) conn.close();
Statement stmt = conn.createStatement();
scope(exit) stmt.close();
// test data preparation
stmt.executeUpdate("DROP TABLE IF EXISTS user");
stmt.executeUpdate("CREATE TABLE user (id INTEGER PRIMARY
KEY, name VARCHAR(255) NOT NULL, flags int null)");
stmt.executeUpdate(`INSERT INTO user (id, name, flags)
VALUES (1, "John", 5), (2, "Andrei", 2), (3, "Walter", 2), (4,
"Rikki", 3), (5, "Iain", 0), (6, "Robert", 1)`);
// our POD struct
struct User {
long id;
string name;
int flags;
}
// let's execute select and nump query result
foreach(user; stmt.select!User.where("id <
6").orderBy("name desc")) {
writeln("id:", user.id, " name:", user.name, " flags:",
user.flags);
}
Output is:
--
id:3 name:Walter flags:2
id:4 name:Rikki flags:3
id:1 name:John flags:5
id:5 name:Iain flags:0
id:2 name:Andrei flags:2
--
Where and orderBy are optional - without them always reads all
rows in default order.
Possible improvements: ability to specify field list to read
only necessary fields.
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only id
and name (you will see default value 0 in flags field)");
foreach(ref e; stmt.select!(User, "id", "name")) {
writeln("id:", e.id, " name:", e.name, " flags:",
e.flags);
}
output:
reading all user table rows, but fetching only id and name (you
will see default value 0 in flags field)
id:1 name:John flags:0
id:2 name:Andrei flags:0
id:3 name:Walter flags:0
id:4 name:Rikki flags:0
id:5 name:Iain flags:0
id:6 name:Robert flags:0
Small addition for D-style selects:
// now it's possible to use vars as destination
long id;
string name;
foreach(e; stmt.select!()("SELECT id, name FROM user", id,
name)) {
writeln("id:", id, " name:", name);
}
Result:
id:1 name:John
id:2 name:Andrei
id:3 name:Walter
id:4 name:Rikki
id:5 name:Iain
id:6 name:Robert
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 15:30:42 UTC, Daniel Kozák wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d
napsáno:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
> On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
>> IMO writing:
>>
>> foreach(it; db.select("...")) {
>> }
>>
>> is epic. you have entered std.(range|algorithm) land.
>
> Implemented in v0.2.17 for select.
>
> test:
>
> auto ds = new ConnectionPoolDataSourceImpl(new
> SQLITEDriver(), "ddbctest.sqlite");
> auto conn = ds.getConnection();
> scope(exit) conn.close();
> Statement stmt = conn.createStatement();
> scope(exit) stmt.close();
> // test data preparation
> stmt.executeUpdate("DROP TABLE IF EXISTS user");
> stmt.executeUpdate("CREATE TABLE user (id INTEGER
> PRIMARY KEY, name VARCHAR(255) NOT NULL, flags int null)");
> stmt.executeUpdate(`INSERT INTO user (id, name, flags)
> VALUES (1, "John", 5), (2, "Andrei", 2), (3, "Walter", 2),
> (4, "Rikki", 3), (5, "Iain", 0), (6, "Robert", 1)`);
>
> // our POD struct
> struct User {
> long id;
> string name;
> int flags;
> }
>
> // let's execute select and nump query result
> foreach(user; stmt.select!User.where("id <
> 6").orderBy("name desc")) {
> writeln("id:", user.id, " name:", user.name, "
> flags:", user.flags);
> }
>
> Output is:
> --
> id:3 name:Walter flags:2
> id:4 name:Rikki flags:3
> id:1 name:John flags:5
> id:5 name:Iain flags:0
> id:2 name:Andrei flags:2
> --
> Where and orderBy are optional - without them always reads
> all rows in default order.
>
> Possible improvements: ability to specify field list to read
> only necessary fields.
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only
id and name (you will see default value 0 in flags field)");
foreach(ref e; stmt.select!(User, "id", "name")) {
writeln("id:", e.id, " name:", e.name, " flags:",
e.flags);
}
output:
reading all user table rows, but fetching only id and name
(you will see default value 0 in flags field)
id:1 name:John flags:0
id:2 name:Andrei flags:0
id:3 name:Walter flags:0
id:4 name:Rikki flags:0
id:5 name:Iain flags:0
id:6 name:Robert flags:0
This is dangerous zone, you shoud not do this ;-). In my work I
have
writen our ORM-like db layer which has this funcionality (mainly
performance reasons) but if I can go back in time. I will be
against
such a misfeature.
It's not considered as a main API. It's not madatory to import
this module.
It's a set of helpers to simplify getting field values from
ResultSet into struct or tuple, or write to prepared statement
parameters, a kind of syntax sugar.
For ORM purposes, real ORM must be used.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 14:03:22 UTC, Kagamin wrote: The database client library or the database itself in case of sqlite, i.e. code you link with. Dependency also means you should get it somewhere, possibly compiling with dmc. If only interfaces included into Phobos, it's not a problem of Phobos.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin wrote:
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
IMO writing:
foreach(it; db.select("...")) {
}
is epic. you have entered std.(range|algorithm) land.
Implemented in v0.2.17 for select.
test:
auto ds = new ConnectionPoolDataSourceImpl(new
SQLITEDriver(), "ddbctest.sqlite");
auto conn = ds.getConnection();
scope(exit) conn.close();
Statement stmt = conn.createStatement();
scope(exit) stmt.close();
// test data preparation
stmt.executeUpdate("DROP TABLE IF EXISTS user");
stmt.executeUpdate("CREATE TABLE user (id INTEGER PRIMARY
KEY, name VARCHAR(255) NOT NULL, flags int null)");
stmt.executeUpdate(`INSERT INTO user (id, name, flags)
VALUES (1, "John", 5), (2, "Andrei", 2), (3, "Walter", 2), (4,
"Rikki", 3), (5, "Iain", 0), (6, "Robert", 1)`);
// our POD struct
struct User {
long id;
string name;
int flags;
}
// let's execute select and nump query result
foreach(user; stmt.select!User.where("id <
6").orderBy("name desc")) {
writeln("id:", user.id, " name:", user.name, " flags:",
user.flags);
}
Output is:
--
id:3 name:Walter flags:2
id:4 name:Rikki flags:3
id:1 name:John flags:5
id:5 name:Iain flags:0
id:2 name:Andrei flags:2
--
Where and orderBy are optional - without them always reads all
rows in default order.
Possible improvements: ability to specify field list to read
only necessary fields.
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only id
and name (you will see default value 0 in flags field)");
foreach(ref e; stmt.select!(User, "id", "name")) {
writeln("id:", e.id, " name:", e.name, " flags:",
e.flags);
}
output:
reading all user table rows, but fetching only id and name (you
will see default value 0 in flags field)
id:1 name:John flags:0
id:2 name:Andrei flags:0
id:3 name:Walter flags:0
id:4 name:Rikki flags:0
id:5 name:Iain flags:0
id:6 name:Robert flags:0
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
Schadek wrote:
On Tuesday, 3 February 2015 at 10:33:25 UTC, Vadim Lopatin
wrote:
ORM operations are not a simple single query/statement.
They often use several queries to load dependent objects.
make it an output range
Of course, some CTFE/UDAs may be used for generation of field
list, but it is not very helpful IMO.
IMO writing:
foreach(it; db.select("...")) {
}
is epic. you have entered std.(range|algorithm) land.
Implemented in v0.2.17 for select.
test:
auto ds = new ConnectionPoolDataSourceImpl(new
SQLITEDriver(), "ddbctest.sqlite");
auto conn = ds.getConnection();
scope(exit) conn.close();
Statement stmt = conn.createStatement();
scope(exit) stmt.close();
// test data preparation
stmt.executeUpdate("DROP TABLE IF EXISTS user");
stmt.executeUpdate("CREATE TABLE user (id INTEGER PRIMARY
KEY, name VARCHAR(255) NOT NULL, flags int null)");
stmt.executeUpdate(`INSERT INTO user (id, name, flags) VALUES
(1, "John", 5), (2, "Andrei", 2), (3, "Walter", 2), (4, "Rikki",
3), (5, "Iain", 0), (6, "Robert", 1)`);
// our POD struct
struct User {
long id;
string name;
int flags;
}
// let's execute select and nump query result
foreach(user; stmt.select!User.where("id < 6").orderBy("name
desc")) {
writeln("id:", user.id, " name:", user.name, " flags:",
user.flags);
}
Output is:
--
id:3 name:Walter flags:2
id:4 name:Rikki flags:3
id:1 name:John flags:5
id:5 name:Iain flags:0
id:2 name:Andrei flags:2
--
Where and orderBy are optional - without them always reads all
rows in default order.
Possible improvements: ability to specify field list to read only
necessary fields.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 12:06:25 UTC, Kagamin wrote: I see problems with licensing and external dependencies. License on API? (like Sun sued Google for implementation of Java API?) Or on third party libraries used by DB drivers.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 09:16:14 UTC, Robert burner
Schadek wrote:
But for such high level DB library must be based on some lower
level DB API (connector).
Like JDBC for JPA or Hibernate in Java.
really, does it? there is no need for an abstraction layer. you
can have functions generate the correct source for mysql,
sqlite, you name it. e.g. just generate the mysql statement at
CT and pass the pointer to the sql c function. pass the
parameter. done. Dream big.
ORM operations are not a simple single query/statement.
They often use several queries to load dependent objects.
D may offer more convenient way for reading of field values ...
not used), but it doesn't know column types anyway.
I don't get your point
E.g. you can write template method for ResultSet for easy getting
column values into variables. E.g. read method can have variable
number of ref args to place read data to. Template will check
types of args, and do necessary conversions of data when reading.
// read into vars
long id;
string name;
int flags;
rs = statement.executeQuery("SELECT id, name, flags FROM user
WHERE flags = 5 ORDER BY name");
while (rs.next(id, name, flags)) {
writeln(id, " ", name, " ", flags);
}
or
// read into structure or class fields
struct User {
long id;
string name;
int flags;
}
User row;
rs = statement.executeQuery("SELECT id, name, flags FROM user
WHERE flags = 5 ORDER BY name");
while (rs.next(row)) {
writeln(row.id, " ", row.name, " ", row.flags);
}
Of course, some CTFE/UDAs may be used for generation of field
list, but it is not very helpful IMO.
// automatically generated SQL - based on type of struct/class
params
User row;
rs = statement.executeSelect(row, "WHERE flags = 5 ORDER BY
name");
// actually, sql "SELECT id, name, flags FROM user WHERE flags =
5 ORDER BY name" will be used
while (rs.next(row)) {
// every time row is read, struct fields will be updated with
new values
writeln(row.id, " ", row.name, " ", row.flags);
}
UDAs can be used to change mapping of class/struct name to table
name, field names to column names, mark some fields/properties as
non persistent.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 08:37:04 UTC, Robert burner Schadek wrote: IMO the java way is to uncreative. We have UDA, CTFE and string mixins anything short of perfect SQL generated at compile time without anything else than UDA annotation to my structs is an epic lose for D. I mean, who wants to write string statements when the lib can generate them for you. For every sql incarnation you can think of. What you are talking about is a bit different, higher level thing, ORM. It's what done in my project hibernated or in project of Daniel Kozak he mentioned above. E.g. hibernated uses CTFE and mixins to collect metadata, and prepare parts of SQL queries. But for such high level DB library must be based on some lower level DB API (connector). Like JDBC for JPA or Hibernate in Java. D may offer more convenient way for reading of field values from result set, and for setting of parameters - using templates, and other cool D features. Parsing of SQL doesn't make sense in low level. It can determine number of fields expected in query result (if * is not used), but it doesn't know column types anyway.
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 08:23:56 UTC, Daniel Kozak wrote:
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Standard library must contain only
* set of interfaces for uniform DB access
* Connection - can create Statement or PreparedStatement,
control transactions
* Statement - can run update or query
* PreparedStatement - same as Statement, but with parameters
* ResultSet - DB query result row access
* DataSource - can create connections, w/o parameters
* Driver - interface which implements connection factory
for particular DB types
* Some useful classes like ConnectionPool
* factory method to create connection by URL and parameter set
* some method to register DB driver for factory - e.g. when
called from driver's module __gshared static this()
Drivers may be placed in separate packages in standard library
or in some DUB packages.
Look at https://github.com/buggins/ddbc
Currently it contains drivers for sqlite, MySQL and PostgreSQL.
If Andrey/Walter wish, I can prepare pool request based on
code from ddbc.
Best regards,
Vadim
Yep this is way to go, I have start implementing JPA for
Dlang(ddpa - dlang data persistence api):
@Entity
@(Table.name("nazev_tabulky").schema("nazev_schema"))
class C
{
@Id @(GeneratedValue.strategy(GenerationType.IDENTITY))
long id;
auto getId()
{
return this.id;
}
void setId(long id)
{
this.id = id;
}
}
void main() {
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("test");
EntityManager em = emf.createEntityManager();
C obj = em.find!C(1);
}
I did almost the same :) https://github.com/buggins/hibernated
// Annotations of entity classes
class User {
long id;
string name;
Customer customer;
@ManyToMany // cannot be inferred, requires annotation
LazyCollection!Role roles;
}
class Customer {
int id;
string name;
// Embedded is inferred from type of Address
Address address;
Lazy!AccountType accountType; // ManyToOne inferred
User[] users; // OneToMany inferred
this() {
address = new Address();
}
}
@Embeddable
class Address {
string zip;
string city;
string streetAddress;
}
class AccountType {
int id;
string name;
}
class Role {
int id;
string name;
@ManyToMany // w/o this annotation will be OneToMany by
convention
LazyCollection!User users;
}
Re: H1 2015 - db access support in Phobos
On Monday, 2 February 2015 at 18:00:28 UTC, AndyC wrote: On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote: I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). Standard library must contain only * set of interfaces for uniform DB access * Connection - can create Statement or PreparedStatement, control transactions * Statement - can run update or query * PreparedStatement - same as Statement, but with parameters * ResultSet - DB query result row access * DataSource - can create connections, w/o parameters * Driver - interface which implements connection factory for particular DB types * Some useful classes like ConnectionPool * factory method to create connection by URL and parameter set * some method to register DB driver for factory - e.g. when called from driver's module __gshared static this() Drivers may be placed in separate packages in standard library or in some DUB packages. Look at https://github.com/buggins/ddbc Currently it contains drivers for sqlite, MySQL and PostgreSQL. If Andrey/Walter wish, I can prepare pool request based on code from ddbc. Best regards, Vadim -1 on copy Java. It seems over complicated. We need a base Database Class, then derive PostgresDatabase from that. No need for Driver class. PostgresDatabase class contains all the knowledge to connect to the actual database so what's left for Driver? If we have Database class, why do we need Connection or DataSource? They don't offer anything Database shouldn't already have. Database (and children), ResultSet and Statement are all that's needed. Statement can have a prepare() function. No need to make an entire PreparedStatement class, seems overkill. I pray we never ever have factories. I like verbs, they make sense. -Andy Did you ever write complex DB applications? Connection is important part for DB access. Statements are always being executed on particular connection. E.g. sequence temporary table operations, transaction management, and other operations require to work on the same physical connection. Connection is a resource. It should be managed. It's mandatory to close physical connection when no more used. But reopening of physical connection to DB is high cost operation. Therefore usually connections are being reused using Connection Pools. Often application needs several connections to do operations in parallel. Some kind of factory is needed anyway, to allow application be independent from particular DB kind (e.g. to allow configuring DB type and parameters in some configuration file). Driver is just an abstraction which can be used for creation of DB connections (you just call it Database). PreparedStatement is important thing - it's not only ability to specify query parameters, but it is being compiled (prepared) on server side and can be reused and be executed several times with higher performance than usual query. Prepared statements are resources - and should have an ability to be closed when no longer needed. ResultSets are probably redundant and may be embedded into statements, but in this case it will not be possible to deal with multiple result sets from same query.
H1 2015 - db access support in Phobos
I would like to propose Java way for implementation of DB access (JDBC - Java DataBase Connectors). Standard library must contain only * set of interfaces for uniform DB access * Connection - can create Statement or PreparedStatement, control transactions * Statement - can run update or query * PreparedStatement - same as Statement, but with parameters * ResultSet - DB query result row access * DataSource - can create connections, w/o parameters * Driver - interface which implements connection factory for particular DB types * Some useful classes like ConnectionPool * factory method to create connection by URL and parameter set * some method to register DB driver for factory - e.g. when called from driver's module __gshared static this() Drivers may be placed in separate packages in standard library or in some DUB packages. Look at https://github.com/buggins/ddbc Currently it contains drivers for sqlite, MySQL and PostgreSQL. If Andrey/Walter wish, I can prepare pool request based on code from ddbc. Best regards, Vadim
Re: Lost a new commercial user this week :(
On Thursday, 18 December 2014 at 13:51:08 UTC, Vadim Lopatin wrote: git clone g...@github.com:buggins/dlangide.git cd dlang ide dub run Sorry, it should be git clone https://github.com/buggins/dlangide.git cd dlangide dub run
Re: Lost a new commercial user this week :(
On Thursday, 18 December 2014 at 13:43:15 UTC, Chris wrote: On Thursday, 18 December 2014 at 11:50:46 UTC, Vadim Lopatin wrote: On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote: Very good! I tried it and couldn't clone the repo (permission denied). Downloaded the master zip instead, ran the above command and got this message (dmd v2.066.0 64bit Linux): ... Error executing command run: dmd failed with exit code 1. I'd really love to test your gui toolkit, something I've been dreaming of for a long time! Sorry, 64bit build has been broken by recent changes. Fixed in v0.1.5 Https should be used instead of SSH to clone repository. git clone https://github.com/buggins/dlangui.git cd dlangui dub run dlangui:example1 This worked! Thanks. It's very good! Maybe we should think about writing a IDE based on dub and dlangui. What do you think? How did you guess? :) git clone g...@github.com:buggins/dlangide.git cd dlang ide dub run Recent changes are to be able writing IDE: - Tree view (usable) - FileOpen dialog (in progress) If you need any help with the artwork, maybe next year I'll have some time to design icons etc. UI theme itself now looks ugly - mix of resources from Android, gnome Oxygen, and hand drawn images. All of different styles and palette. It will be great if someone could help to make them better. (Mostly, editing on theme XML and PNGs is necessary).
Re: Lost a new commercial user this week :(
On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote: Very good! I tried it and couldn't clone the repo (permission denied). Downloaded the master zip instead, ran the above command and got this message (dmd v2.066.0 64bit Linux): ... Error executing command run: dmd failed with exit code 1. I'd really love to test your gui toolkit, something I've been dreaming of for a long time! Sorry, 64bit build has been broken by recent changes. Fixed in v0.1.5 Https should be used instead of SSH to clone repository. git clone https://github.com/buggins/dlangui.git cd dlangui dub run dlangui:example1
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 09:53:06 UTC, Rikki Cattermole wrote: Yeah they are great projects. But they won't ever be what I'm looking for. Personally? - I want a gui toolkit that is accelerated e.g. OpenGL. - That can be layered drawn on top of other OpenGL content. - Completely configurable at runtime e.g. change of shaders. - Centralized themeing. - That works on all major platforms without heartache. But here's the thing about guis in general. Gui toolkits are not really designed to work with OpenGL like this. Hello, I'm working on GUI toolkit DLangUI which meets almost all of your requirements https://github.com/buggins/dlangui Try demo app: git clone g...@github.com:buggins/dlangui.git dub run dlangui:example1 Native. Fully written in D. Widget set can be easy extended. Look and feel is based on themes / styles similar to Android. Scalable UI. Resources can be selected based on screen resolution. Layouts similar to Android UI allow to adjust UI to different window sizes. Cross platform. - I want a gui toolkit that is accelerated e.g. OpenGL. Build it with USE_OPENGL to have OpenGL acceleration. - That can be layered drawn on top of other OpenGL content. Additional development required. a) To use in some custom environment (e.g. draw GUI in some gamedev engine), you need to implement Platform and Window classes to pass Mouse / Key event to UI, and to draw UI above other content when necessary. b) Use DLangUI platform for event processing and context creation, just extend drawing functionality to draw custom content. (Easy to do). - Completely configurable at runtime e.g. change of shaders. Internally it uses only two shaders. For custom drawn GL scenes, just write your own code. - Centralized themeing. Styles and themes are being defined in XML resources. Partially compatible with ones from Android. State aware drawables. Nine-patch drawables. Theme can be switched in run time. - That works on all major platforms without heartache. For most platforms, SLD2 backend can be used (version USE_SDL). On Windows, you may use native Win32 backend (if not specified version USE_SDL). XCB(X11) backend is suspended for now. Didn't manage to get OpenGL working under it. For all platforms, OpenGL acceleration can be used (version USE_OPENGL). If OpenGL context creation is failed, app just falls back to software renderer. Development of the project is in progress. But it is getting more and more usable every day. Best regards, Vadim (aka Buggins)
Re: D's gui controls need a cool control for DataBase Programming
On Tuesday, 3 June 2014 at 09:31:26 UTC, Rikki Cattermole wrote: On 3/06/2014 9:11 p.m., FrankLike wrote: Now,D is very cool for System Programming,but it's not cool for Database Programming. It needs some controls such as Calendar,DataTimePicker, DataGrid,DataView etc. DataGrid can display a lot of data ,such as Chinese chars ,and filter them,DataGrid's 'Data Source' maybe the DataView,DataView is not be visible,and it can save a lot of data,and filter them.Now,only DWT can work,but it's not easy to use.So D need some cool control do it,DGui,DFL...,who can do that better ? Frank If somebody was to design (fully) how a set of controls for D would look and act like I may have a go at building an OpenGL based GUI toolkit. It was part of why I gave up on DOOGLE. Don't have that skill set. When I say design gui controls I mean, everything from buttons to list boxes. And every single pixel, color the lot. OpenGL based toolkit - see my project https://github.com/buggins/dlangui DB access (like JDBC or ODBC) - https://github.com/buggins/ddbc ORM (like Hibernate) - https://github.com/buggins/hibernated dlangui development is in progress. No Db controls yet, only in plans.
