DUB 0.9.23 released

[Sönke Ludwig via Digitalmars-d-announce]

The new version contains some important bug fixes for sub modules and 
overridden string imports, as well as some other major fixes. Apart from 
that, the major additions are:


 - "copyFiles" now get hard linked instead of copied and whole
   directories can be copied in addition to individual files
 - The "dub init" command has been extended to take an optional list of
   dependencies that is added to the generated dub.json
 - A new "deimos" template has been been implemented
   (dub init --type=deimos)
 - The default compiler is now chosen based on what is found in PATH
 - New project generators for Sublime Text and CMake
 - In single file build mode, "--parallel" can now be used to compile
   with multiple compiler instances at once

Find the full list of changes in the change log [1] and download at:

http://code.dlang.org/download

[1]: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Re: DUB 0.9.23 released

[Martin Nowak via Digitalmars-d-announce]

On Monday, 6 April 2015 at 08:21:46 UTC, Sönke Ludwig wrote:

Apart from that, the major additions are:


We also made dub a lot faster 
https://github.com/D-Programming-Language/dub/pull/388.

Re: DUB 0.9.23 released

[Vladimir Panteleev via Digitalmars-d-announce]

On Monday, 6 April 2015 at 08:21:46 UTC, Sönke Ludwig wrote:
The new version contains some important bug fixes for sub 
modules and overridden string imports, as well as some other 
major fixes.


Congratulations!

So, 2.068 will include Dub, right?

Re: DUB 0.9.23 released

[Sönke Ludwig via Digitalmars-d-announce]

Am 06.04.2015 um 11:03 schrieb Vladimir Panteleev:

On Monday, 6 April 2015 at 08:21:46 UTC, Sönke Ludwig wrote:

The new version contains some important bug fixes for sub modules and
overridden string imports, as well as some other major fixes.


Congratulations!

So, 2.068 will include Dub, right?


We'll need one additional intermediate release, because there are still 
a handful of release critical issues for 1.0.0 and the decision was to 
include it only when 1.0.0 is ready:


https://github.com/D-Programming-Language/dub/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0

Re: DUB 0.9.23 released

[Jordi Sayol via Digitalmars-d-announce]

El 06/04/15 a les 10:21, Sönke Ludwig via Digitalmars-d-announce ha escrit:
> The new version contains some important bug fixes for sub modules and 
> overridden string imports, as well as some other major fixes.

Congratulations for this new release!

Available for Debian/Ubuntu at 

Re: Reggae v0.0.5 super alpha: A build system in D

[Sergei Nosov via Digitalmars-d-announce]

On Sunday, 5 April 2015 at 00:22:35 UTC, Atila Neves wrote:
It seems to me that different projects might benefit from 
different compilation strategies. It might just be a case of 
unit tests alongside production code vs in separate files. As 
mentioned before, my experience with per-module compilation was 
usually faster, but I'm going to change the default to be per 
package.


I want to also share my experience in that regard.

When I was writing a vibe.d based application, I used dub as a 
build system, which sends everything in one go. My application 
was just a couple of files, so I was, practically, just building 
vibe every time.


I was developing the application on a desktop with 4 Gb RAM and 
everything was fine (albeit I was missing the "progress bar" of 
files in progress provided by ninja/make).


But then it was time to deploy the app, and I bought a 1 GB RAM 
virtual node from Linode. After executing dub it told me "Out of 
memory" and exited. And there was nothing I could do.


So I took the only option I saw - I switched to CMake (modified 
for working with D) to provide me a separate compilation build 
(ninja-based) and swore to never again.


I understand the reasoning behind both separate and "throw in 
everything" compilation strategies. And I also understand the 
pros of a middle-ground solution (like, per-package one), which 
is probably the way D will go. But this area seems kind of gray 
to me (like, in my case the "per-package" solution wouldn't work 
either, if I understand it correctly).


So, personally, I will probably stick to separate compilation, 
until I see that:


- The pros of "batch" compilation are clear and, desirably, 
obvious. At the moment it seems to me (seems to me), that faster 
compilation and attribute inference just don't have a significant 
impact.
- There's a way to fine tune between "separate" and "throw in 
everything" compilation if necessary.


Thanks!

DMD 2.067.0 Programming Language Specifications

[Jordi Sayol via Digitalmars-d-announce]

D Programming Language Specifications for dmd 2.067.0 in several formats, 
available at:



dlangspec-2.067.0.chm  --  (Microsoft Compiled HTML Help)

dlangspec-2.067.0.epub  --  (Electronic Publication for e-book readers)

dlangspec-2.067.0.mobi  --  (Mobipocket e-book for Kindle)

dlangspec-2.067.0.pdf  --  (Portable Document Format)

Re: DUB 0.9.23 released

[Sönke Ludwig via Digitalmars-d-announce]

Am 06.04.2015 um 10:33 schrieb Martin Nowak:

On Monday, 6 April 2015 at 08:21:46 UTC, Sönke Ludwig wrote:

Apart from that, the major additions are:


We also made dub a lot faster
https://github.com/D-Programming-Language/dub/pull/388.


Didn't realize that this didn't make it into the previous release. I'll 
add it to the change log.

This Week in D #12: mid-term vision review, library tip, GC profiling

[Adam D. Ruppe via Digitalmars-d-announce]

http://arsdnet.net/this-week-in-d/apr-05.html

http://www.reddit.com/r/d_language/comments/31mu0i/this_week_in_d_april_6_2015_gc_profiling_library/

Re: Standardpaths library

[Xavier Bigand via Digitalmars-d-announce]

Le 05/04/2015 11:08, FreeSlave a écrit :

I wrote small library for getting standard paths (like Pictures, Music)
Here's dub package http://code.dlang.org/packages/standardpaths
And github repo https://github.com/MyLittleRobo/standardpaths

You can see open issues on github. Please, participate in discussions if
you're interested. The biggest problem now is OS X support
https://github.com/MyLittleRobo/standardpaths/issues/4

You can generate documentation with dub build --build=docs.


Nice,

IMO it can have his place in phobos, cause at least all GUI applications 
have to retrieve one or more of those paths.


This kind of API are important to ease fast prototyping applications or 
scripts.

Re: Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Sun, 05 Apr 2015 12:31:23 +
schrieb "FreeSlave" :

> On Sunday, 5 April 2015 at 11:42:42 UTC, Marco Leise wrote:
> > On another note when I ran your 'printdirs' it didn't list a
> > user Fonts or Applications directory. The Applications
> > directory is ok, but I do have a ~/.fonts/ directory and
> > /etc/fonts/fonts.conf says:
> >   
> >   ~/.fonts
> > Fonts in ~/.fonts are listed in LibreOffice. It seems like you
> > do parse /etc/fonts/fonts.conf. Maybe there is a bug in the
> > parser?
> >
> > The whole Applications thing doesn't make much sense on Linux,
> > right? Is that a directory where applications are installed to
> > including their assets?
> 
> Probably you don't have local 
> $XDG_CONFIG_DIR/fontconfig/fonts.conf file.
> 
> I've opened issue 
> https://github.com/MyLittleRobo/standardpaths/issues/8
> 
> About Applications: on my Windows 7 it returns 
> C:/Users/Username/Application Data/Microsoft/Windows/Start 
> Menu/ProgramsC:/ProgramData/Microsoft/Windows/Start Menu/Programs 
> where .lnk files are stored (I believe these are used in the 
> start  menu). Since freedesktop systems use .desktop files it 
> would be sane to return paths which contain them 
> (~/.local/share/applications, /usr/local/share/applications and 
> /usr/share/applications). I just have not implemented it yet. 
> Though not sure it the whole thing can be useful, since things 
> are not the same on Windows and freedesktop: Windows uses 
> directories to make menu hierarchy, while freedesktop for the 
> same purpose use Categories field in .desktop files. Also .lnk 
> and .desktop are different things themselves.

You are right, the two are very different. One has to write OS
specific code to use them. The funny thing is, D as a systems
programming language could actually be used by someone to
write a Linux package manager or Windows installer. :p

Do as you see fit. Qt as an inspiration is a good thing I
believe. Some classes I had a look at were intuitive and well
thought out.

-- 
Marco

Re: Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Sun, 05 Apr 2015 12:39:04 +
schrieb "FreeSlave" :

> On Sunday, 5 April 2015 at 11:42:42 UTC, Marco Leise wrote:
> >is this Windows?
> > return executable_path
> 
> That depends on what do you understand by data.

The data I was referring to is the stuff that is installed with
the program executable. Files that are usually the same across
installations.

> Are game's saves data too? Or content downloaded while playing
> (server-specific assets or new levels).
> In the past it was ok to write configs and 
> data to the same path where the game (or application) originally 
> installed. But starting with Vista or Windows 7 it's not the case 
> since Program Files folder become write-protected by default.

I believe modern desktops offer enough granularity to cover
each of those. For example if I was playing a game on Linux
files would go here:

/usr/share/[games/] - read-only data files.
~/.cache/ - downloaded archives, precompiled scripts, browser
caches and other files that can be recreated or
fetched again if they were to be deleted
~/.config/ - the user's personal configuration; may be
 overriding something in a system directory if
 desired
~/.local/share/ - pretty much a catch all for save games,
  user created content that goes beyond the
  scope of config files, highscores,
  highlighting schemes in an IDE, Steam, ...

Or the other way around:

data   => /usr/share
save games => ~/.local/share
downloaded content => ~/.local/share (or ~/.cache)
configs=> ~/.config

Windows has the Local and Roaming directories, which
serve similar but different purposes. E.g. anything machine
specific or big must not be in Roaming.
So if I generally asked for the config dir, I'd probably expect
AppData/Local on Windows and ~/.config on Linux (because I
might write a configuration that only works for this machine.)
Roaming is interesting for users that have their profiles on
servers and might switch to another workstation. So if some
configuration is "portable" and you want to create something
really fine grained you could offer that directory as an
alternative "roaming config dir" (returning null or
"~/.config" on Linux).
In any case there will be multiple results for some
directories (/usr/share, /usr/local/share) and also
several standard paths mapping to the same physical directory
(user data and user cache both map to AppData/Local on
Windows). The user needs to be made aware of this so (s)he
doesn't overwrite files in one standard path with files in a
supposedly different one.

So much for my thoughts on standard paths extreme edition. ;)

-- 
Marco

Re: OpenVG bindings

[ddos via Digitalmars-d-announce]

On Saturday, 4 April 2015 at 02:47:46 UTC, Rikki Cattermole wrote:

On 4/04/2015 11:53 a.m., ddos wrote:

Hi folks,

today i've created my first dlang library ^_^ a binding to the 
OpenVG
library standard. The referenced implementation is ShivaVG 
which allows
to draw vector graphics within an OpenGL context (similar to 
cairo).
A small demo application is included, using derelict gl3 and 
glfw3


https://github.com/oggs91/OpenVG_D
http://code.dlang.org/packages/dopenvg


Could you please add an example using Devisualization.Window?
That way its one less external to D library that is a 
dependency.


https://github.com/Devisualization/window


I tried and failed so far, pls have a look here:
http://forum.dlang.org/thread/acfmrhyhpdrukkqlj...@forum.dlang.org

Re: OpenVG bindings

[ddos via Digitalmars-d-announce]

On Saturday, 4 April 2015 at 09:24:29 UTC, Baz wrote:

On Friday, 3 April 2015 at 22:53:51 UTC, ddos wrote:

Hi folks,

today i've created my first dlang library ^_^ a binding to the 
OpenVG library standard. The referenced implementation is 
ShivaVG which allows to draw vector graphics within an OpenGL 
context (similar to cairo).
A small demo application is included, using derelict gl3 and 
glfw3


https://github.com/oggs91/OpenVG_D
http://code.dlang.org/packages/dopenvg


Thx. I'll give it a try because it matches something i've 
started last week. I could use Cairo but a few years ago i've 
already gave up something similar because of the bad 
performances (Cairo is made and dedicated to inkscape, isn't it 
?). Are OpenVG perfs better?

This lib is quite unknown btw.


I think the reason for this is that vector graphics are mainly 
used for drawing userinterfaces and illustrations like pdf file, 
svg file, etc. Here performance isn't much of a problem so there 
isn't any need for change. Cairo is imho a quasi standard and 
didn't change much since long time.
Since I use OpenGL I recently looked into OpenVG and it has a 
really clean and easy to understand renderpipeline and api. 
Khronos created a specification for OpenVG, but there aren't many 
(open) implementations yet. Some mobilephone manufacturers have 
implementations for their devices, like nokia.


Since you are interested in performance i think going with any 
hardware accelerated vector graphics library should work out for 
you. ShivaVG or cairo with a opengl backend (there are lots of 
different backends)

Coedit - beta 1 released

[Baz via Digitalmars-d-announce]

I'm pleased to announce the first beta of Coedit, the small IDE 
for the D programming language, based on DMD.


This version introduces:
- the option editor.
- metad, a meta GIT repository composed of static libraries 
easily buildable with Coedit.

- DCD integration: call tips and DDoc comments as hints.
- symbol list based on libdparse (formerly called the _static 
explorer_)


Links:
- Change log and short intro to the new features: 
https://github.com/BBasile/Coedit/releases/tag/beta_1
- Binaries for win32: 
https://github.com/BBasile/Coedit/releases/download/beta_1/coedit.beta1.win32.zip
- Binaries for Nux64: 
https://github.com/BBasile/Coedit/releases/download/beta_1/coedit.beta1.linux64.zip