Re: D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
On Wednesday, 6 August 2014 at 17:09:50 UTC, Kiith-Sa wrote: ## D:YAML 0.4.5 ## For compatibility with DMD 2.065, I also made a "release" out of the last state of git master before 2.066 was required. See the release at GitHub: https://github.com/kiith-sa/D-YAML/releases/tag/v0.4.5 Great thanks. One tiny issue however is that v0.4.5 is not available via the dub registry. It looks like the registry has only picked up v0.5.0.
Re: D Cookbook on reddit
On Wednesday, 6 August 2014 at 15:33:51 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2cpkz3/d_cookbook_review_win_an_ebook/ Andrei Really cool to see growing interest in D among fellow countrymen. Very nice blog note!
Re: D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
On Wednesday, 6 August 2014 at 17:09:50 UTC, Kiith-Sa wrote: D:YAML is a YAML parser and emitter for D. Thanks a lot for working on this. I actually really hate YAML, but I'm forced to work with it sometimes, and this library saved me from having to write a parser for it myself. - Jonathan M Davis
D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
D:YAML is a YAML parser and emitter for D. It's been a while since the last release and many small features have been added to the Git master over time, so I finally forced myself to do an official release. D:YAML at GitHub: https://github.com/kiith-sa/D-YAML ## Highlights ## Some breaking changes: YAML loading API using std.stream is now obsolete. D:YAML 0.5 requires DMD 2.066 (yes, the one that is not yet released - see 0.4.5 below for compatibility). DUB by default: Stopped using my own build script, updated examples to use DUB, etc. Significantly less memory allocations, both GC and malloc: D:YAML scanner now uses slices to avoid any allocations. UTF-8 is now used internally instead of decoding into UTF-32. Better performance: I've spent some time profiling and optimizing, mainly for the use case of 'parsing few-kiB mostly ASCII files not using crazy advanced YAML features' (I use YAML for game-related stuff). Performance for the above use case is up about 80% (or, time spent is down to about 55%). For mostly-unicode (that is, mostly non-ASCII unicode) files, performance is down slightly (~10-15%). I don't have any thorough measurements to release, just did various tests as I went. Retired the dyaml.alwaysdata.net site, moved API docs/tutorials to my new site: http://defenestrate.eu/docs/dyaml/ And various small features/fixes/improvements. See the full changelog for details: https://github.com/kiith-sa/D-YAML/releases/tag/v0.5.0 ## D:YAML 0.4.5 ## For compatibility with DMD 2.065, I also made a "release" out of the last state of git master before 2.066 was required. See the release at GitHub: https://github.com/kiith-sa/D-YAML/releases/tag/v0.4.5 ## TinyEndian ## This is just a single module with two functions that I separated into a DUB package as I think it may be useful. When removing the std.stream dependency from D:YAML I had to replace EndianStream with my own code (based on EndianStream but mostly rewritten). The result are two pure nothrow @nogc functions to detect UTF byte order marks and swap endianness https://github.com/kiith-sa/tinyendian
Re: DMD v2.066.0-rc1
On Wednesday, 6 August 2014 at 05:20:27 UTC, Walter Bright wrote: On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote: This windiows installer went wrong on me. First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD install is 'C:\dev\D'... The path was presented in a greyed out textbox that I couldn't type in to correct it, and no button to select the true install location. The uninstall step failed. Then when reinstalling I was given the option where to install, I chose 'C:\dev\D' and it installed over the top of my existing install, and wiped my sc.ini file. So I need to configure the DirectX SDK paths again. Please file these on bugzilla as 2 bug reports. https://issues.dlang.org/enter_bug.cgi Side note: I still think the installer really should detect the DXSDK; it's a Microsoft library, and virtually any multimedia software developed with VS2010 or prior will depend on it (It's merged into the WinSDK since DX2012). The DXSDK install paths are: Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64 The "(June 2010)" part is a safe assumption, it's the last released one, and it will remain so since it's now bundled with the WinSDK for more recent visual studio releases. It's the only one available on the Microsoft website. As I see it, if we profess to support VS2010 and prior, then we should detect the DXSDK paths in the installer, otherwise software that builds fine in VS2012+ won't work with VS2010 without user intervention, and that will almost certainly lead to posts on this forum. One of the reasons I delayed so long in supporting VS is because Microsoft changes things around with every release, making trying to support whatever version the customer has is a constant configuration/testing nightmare, consuming a great deal of time and effort with little payback. With dmc, this is not a problem. As an aside, one thing I find difficult to understand is why experienced C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are. I don't think it's difficult for them, I think they often just don't know they can. Environment variables just aren't as well known on Windows these days. If you are an 18 year old getting into programming you likely have never even heard of environment variables or batch files and may not even know how to use the command prompt (or open it for that matter). Windows Vista came out when they were 10 years old and the days of having to know and use the command prompt for typical users were long gone by this point. I'm thirty so I knew and used MS-DOS as a kid (I had to) but if you've never used these things how would you know you could? Even if you are an experienced programmer having used Visual Studio or some other IDE for years you'd likely not have had to adjust environment variables to get anything to work. Manu knows these things, of course, but his it-should-just-work complaints probably go a long way to helping people who don't know these things. Heck, I just cribbed them from where Microsoft set them in its own command prompt shortcut "Visual Studio x64 Win64 Command Prompt (2010)". For example, clicking on the shortcut and typing "set" gives: [...] I added the same style of command prompt for DMD to the installer a couple years ago. One for 64-bit and one for 32-bit.
D Cookbook on reddit
http://www.reddit.com/r/programming/comments/2cpkz3/d_cookbook_review_win_an_ebook/ Andrei
Re: DMD v2.066.0-rc1
On 6 August 2014 15:20, Walter Bright via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote: > >> This windiows installer went wrong on me. >> First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD >> install is 'C:\dev\D'... The path was presented in a greyed out textbox >> that I >> couldn't type in to correct it, and no button to select the true install >> location. >> The uninstall step failed. >> >> Then when reinstalling I was given the option where to install, I chose >> 'C:\dev\D' and it installed over the top of my existing install, and >> wiped my >> sc.ini file. So I need to configure the DirectX SDK paths again. >> > > Please file these on bugzilla as 2 bug reports. > > https://issues.dlang.org/enter_bug.cgi Yup, there's already been listings and related discussions. As an aside, one thing I find difficult to understand is why experienced > C++ developers find it so hard to set an environment variable (or one in > the sc.ini) pointing to where the right .h files are and the right .lib > files are. > There is %DXSDK_DIR%, which is fine to use. I've been discussing it with Brad on the bug tracker.
Re: GtkD 2.4.0 released, GTK+ with D.
On Tue, 05 Aug 2014 23:12:43 +0200 Mike Wey via Digitalmars-d-announce wrote: > GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL > license. > > The most notable changes in this release are the discontinuation of > the support for D1, and better support for installing more than one > version of GTK+ on Windows. > A full list of changes is available in the change log: > http://gtkd.org/changelog.html > > GtkD 2.4.0 is now available on gtkd.org: > http://gtkd.org/download.html > > Unlike previous releases this one doesn't come with an update to the > latest release of GTK+. This is being worked on but changes in the > gtk documentation means we need to switch to the gir files for > generating the code. good news, everyone! ;-) it's sad that gtk+2 version is not in active developement anymore. gtk+3 is abomination. signature.asc Description: PGP signature
Re: New GDC site now live
On 6 August 2014 11:56, Robert M. Münch via Digitalmars-d-announce wrote: > On 2014-07-31 17:34:06 +, Iain Buclaw said: > >> GDC's revamped site is now live! >> >> http://gdcproject.org >> >> Techy details for those who are interested: >> - Uses vibe.d as the web engine. >> - Pages are written in markdown and compiled at runtime (separate thread >> that watches for file changes). >> - Redis memstore backend for caching compiled pages. >> - Uses bootstrap for UI. > > > The tech backend sounds cool. Any chance to get some more information > (setup, complete stack, etc.) about it? > Stack is kept as simple as possible. Only notable things I can say is: - Apache used as a proxy *:80 <-> localhost:xxx - Redis is configured to never write any data to disk. - The application running the site itself is self-contained (https://github.com/D-Programming-GDC/gdcproject) - I have a separate (unprivileged) system account on the server to run the application. - Server is a Linode 2GB VM (https://www.linode.com/pricing) Regards Iain.
Re: SDC-32bit
On Friday, 1 August 2014 at 23:16:45 UTC, Stefan Koch wrote: jsonRunner really runs fast ... io overhead really makes a diffrence Correction I just checked the old runner and I found out the following: sdc runs 7.5 times faster if all sourceFiles are compiled together. (as dub does) the slowdown is only visible if one compiles each file into an objectfile and then links it together. (as the makefile does)
Re: New GDC site now live
On 2014-07-31 17:34:06 +, Iain Buclaw said: GDC's revamped site is now live! http://gdcproject.org Techy details for those who are interested: - Uses vibe.d as the web engine. - Pages are written in markdown and compiled at runtime (separate thread that watches for file changes). - Redis memstore backend for caching compiled pages. - Uses bootstrap for UI. The tech backend sounds cool. Any chance to get some more information (setup, complete stack, etc.) about it? -- Robert M. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: GtkD 2.4.0 released, GTK+ with D.
On Tuesday, 5 August 2014 at 22:42:39 UTC, uri wrote: Thanks heaps for this, GtkD is terrific! I agree. I just started a project that uses it and it is quite wonderful.
