Dlang on Gentoo (update)

2014-06-01 Thread Marco Leise via Digitalmars-d-announce
I moved Dlang related ebuild to a new repository under the
Gentoo organization on GitHub a while ago. It is available
through "layman" as "dlang". (Not to be confused with the
outdated "d" overlay there.)

Information in the Gentoo Wiki:
https://wiki.gentoo.org/wiki/Dlang

Link to the repository on GitHub:
https://github.com/gentoo/dlang/

-- 
Marco



Re: Dlang on Gentoo (update)

2014-08-30 Thread Marco Leise via Digitalmars-d-announce
Added ebuild:

* dub 0.9.21

Updated ebuilds:

* GDC based on GCC 4.8.3 and DMD FE 2.065
* DMD 2.066.0 and tools

I wonder if I can switch to linking with libphobos2.so now
by default for dmd? Any outstanding issues/objections?

-- 
Marco



Re: 438-byte "Hello, world" Win32 EXE in D

2014-09-10 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 09 Sep 2014 10:20:43 +
schrieb "Don" :

> On Monday, 8 September 2014 at 08:18:32 UTC, Ola Fosheim Grøstad 
> wrote:
> > On Monday, 8 September 2014 at 08:08:23 UTC, Kagamin wrote:
> >> But that downloaded file is bloatware, because it has to 
> >> implement functionality, which is not provided by the system. 
> >> That tiny pe file doesn't download anything, it's completely 
> >> done by the system.
> >
> > Yeah…
> >
> > http://stackoverflow.com/questions/284797/hello-world-in-less-than-20-bytes
> 
> My personal best --
> 
> At my first job, a customer once made a request for a very simple 
> DOS utility. They did mention that they didn't have much disk 
> space on their machine, so they asked me to try to make the 
> program small.
> That was a once-in-a-lifetime opportunity. Naturally, I wrote it 
> in asm.
> The final executable size was 15 bytes. 
> The customer loved it.

Vladimir: Good job!
Don: Nice story. What did it do?

During my time at a vocation school I wrote some stuff like a
tiny Windows media player with some of the ASM in the DOS/PE
header area. And an animated GIF player in ASM as a .com
executable with the GIF included in it. (Easy since GIF
algorithms are 16-bit and they use 8-bit color palettes)

-- 
Marco



Re: New Beta: 2.066.1-rc1 is Now Available

2014-09-11 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 12 Sep 2014 01:51:33 +0900
schrieb Andrew Edwards :

> DMD 2.066.1-rc1 is now available for testing. Visit 
> http://wiki.dlang.org/Beta_Testing to download. Please submit all bugs 
> to bugzilla at https://issues.dlang.org/.
> 
> Happy testing

I followed the first LINUX link on
http://wiki.dlang.org/DMD_v2.066.1-rc1
and got this:

http://downloads.dlang.org/pre-releases/2014/dmd.2.066.1-rc1.linux.zip

  404 Not Found
  Code: NoSuchKey
  Message: The specified key does not exist.
  Key: pre-releases/2014/dmd.2.066.1-rc1.linux.zip
  RequestId: 041CB7ED85E79D22
  HostId: 77PqxexMbECV1cBnYfWlCZhxrKtBgH2VhFhP8v2tlG6kpALNX3JGPYXbzhmYIx7w

-- 
Marco



Re: New Beta: 2.066.1-rc1 is Now Available

2014-09-11 Thread Marco Leise via Digitalmars-d-announce
P.S. Is this supposed to contain all 2.066 regression
fixes pulled into master up to this point?
As far as I can tell at least
https://github.com/D-Programming-Language/dmd/pull/3961
from 4 days ago didn't get cherry picked yet.
Or are these RCs more of a preliminary version?

-- 
Marco



Re: New Beta: 2.066.1-rc1 is Now Available

2014-09-11 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 12 Sep 2014 03:16:52 +0900
schrieb Andrew Edwards :

> Clear cache and try again.

Thx, "try again now" was enough.

-- 
Marco



Re: Digger 1.0

2014-09-30 Thread Marco Leise via Digitalmars-d-announce
Am Mon, 22 Sep 2014 18:59:12 +
schrieb "Vladimir Panteleev" :

> On Monday, 22 September 2014 at 17:28:50 UTC, ketmar via 
> Digitalmars-d-announce wrote:
> > On Mon, 22 Sep 2014 15:24:55 +0200
> > simendsjo via Digitalmars-d-announce
> >  wrote:
> >
> >> My guess is the average for developers is ~8GB. 2GB RAM is 
> >> really not
> >> enough for pretty much anything these days - the browser alone 
> >> easily
> >> chews 3-4GB on moderate use. I recommend you just upgrade your
> >> computer (or compile on a better iron).
> > are your primary language is java? i'm asking just out of 
> > curiousity.
> 
> That was uncalled for.
> 
> Firefox requires 4GB of memory to build.
> Chromium requires 8GB of memory to build.
> Android requires 16GB of memory to build.

I've been compiling Firefox and Chromium with 4GB of RAM + 4GB
of swap on Linux 64-bit in the past. I don't know if I had to
close any applications for that.

> I think 4GB for a modern programming language's implementation is 
> not an unreasonable requirement, even if it could be brought down 
> in the future. Especially considering that you can't even buy a 
> new laptop today with less than 4GB of RAM, and 3GB is becoming 
> the norm for smartphones.

So why would Apple be able to get away with 1GB on its just
released iPhone 6? Maybe 1048576 kilobytes is enough for
everyone?

-- 
Marco



Re: Mono-D v2.5 - dub buildTypes

2014-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 16 Oct 2014 23:32:20 +
schrieb "Alexander Bothe" :

> Hi everyone,
> 
> just gave the second drop down box in Xamarin Studio a use: 
> Selection of build types for dub projects.
> 
> 
> Furthermore, please don't rage silently somewhere - tell me about 
> issues with Mono-D on github or in #d.mono-d on freenode!
> http://wiki.dlang.org/Mono-D
> https://github.com/aBothe/Mono-D/issues
> 
> 
> 
> Cheers & thanks to everyone,
> Alex

I see what you are doing there.

Furthermore, Carthage must me destroyed!

-- 
Marco



Re: Atmosphere GM - Statistical package

2014-10-24 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 24 Oct 2014 17:54:26 +
schrieb "Ilya Yaroshenko" :

> Hello!
> 
> link http://9il.github.io/atmosphere_gm
> 
> You are welcome to suggest required algorithms!
> 
> Best Regards,
> Ilya

Your English is a bit confusing :) What can I use this
package for? Let's say I measure some value over a period
of time where the distance between the samples is between
100 to 500 ms and there is an error of +/- 2%. Does Atmosphere
GM provide algorithms to filter the error so I can derive from
the graph without huge error spikes?
Or is it more for card games and dice rolls?

-- 
Marco



Re: Devisualization.Image

2014-11-18 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 18 Nov 2014 12:37:54 +0300
schrieb Timur Gafarov :

> 15.11.2014 07:48, Rikki Cattermole пишет:
> > To further Devisualization, I have got the start of an image library.
> > It should be fairly interface complete now.
> >
> > For this I really could use help from anyone with experience with PNG
> > especially with Adam7 interlacing and color correction such as gamma.
> > Currently missing an exporter. Only imports. Does not import grayscale
> > or palleted.
> >
> > Goal: to act as the image representation within memory (including colors).
> > Usage:
> > Devisualization.Window uses it for window icon's (untested for x11 can
> > somebody confirm this does indeed work?).
> > Devisualization.Font heavily uses it for glyphs and the output of its
> > rasterization.
> >
> > [0] https://github.com/Devisualization/image
> 
> I have working PNG export in my image processing package, part of dlib: 
> https://github.com/gecko0307/dlib
> There're also importers for BMP and TGA.

I also just wrote a TGA importer and found RLE and 16-bit in
particular badly supported on Linux. E.g. eye-of-gnome
(Gnome's picture viewer) doesn't correctly restore the last
pixel's color in an RLE image and most software doesn't handle
16-bit at all. Add to that, that the specs are not very
specific as to what allowed values are and you get all
sorts of funny implementations quirks.

-- 
Marco



Re: Devisualization.Image

2014-11-18 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 19 Nov 2014 00:35:09 +0100
schrieb Marco Leise :

> > I have working PNG export in my image processing package, part of dlib: 
> > https://github.com/gecko0307/dlib
> > There're also importers for BMP and TGA.
> 
> I also just wrote a TGA importer and found RLE and 16-bit in
> particular badly supported on Linux. E.g. eye-of-gnome
> (Gnome's picture viewer) doesn't correctly restore the last
> pixel's color in an RLE image and most software doesn't handle
> 16-bit at all. Add to that, that the specs are not very
> specific as to what allowed values are and you get all
> sorts of funny implementations quirks.
 
For example:
- the original Targa paint software TIPS used to store a
  palette even for TrueColor images, meaning you should
  actually calculate the data offset as header + id + palette
  even for 24- and 32-bit images.
- the number of channels for a TrueColor TGA is always 3, plus
  as many attribute bits as given in the descriptor.

If you only support 8-bits per color channel, you should check
if bitsPerPixel is >= 24. Otherwise, bitsPerPixel == 16 would
be interpreted as a two color channel image instead of three
channels à 5-bits. And bitsPerPixel == 15 would become a one
channel image. :p
The 15-/16-bit variants were used quite a bit in the early
days of 3D games, like in the menu graphics for "Trespasser".
They are the same except that 16-bit allows for an additional
attribute bit that could be used for a transparency mask.

-- 
Marco



Re: Beta 2.076.1

2017-10-01 Thread Marco Leise via Digitalmars-d-announce
Could you include the "default_ddoc_theme.ddoc" and
"config.sh" in the source releases? The sources cannot be
compiled without them.

-- 
Marco


Re: Beta 2.076.1

2017-10-01 Thread Marco Leise via Digitalmars-d-announce
P.S.: The directory layout could be improved as well.
Currently there is:

src\
   +-dmd
   +-druntime
   +-phobos

But druntime in posix.mak:10 expects a src directory inside
the dmd directory:

dmd\
   +-src

So effectively the directory names have to be swapped for
that to work. At that point the superfluous directories for
the other operating systems, containing only dmd.conf could be
removed as well.

Other than that I'm happy with the package, as it provides the
man pages, pre-built HTML documentation and a binary to
bootstrap dmd on systems that lack a D compiler. (The use case
being compilation from source for Gentoo Linux.)

-- 
Marco



Re: Beta 2.076.1

2017-11-04 Thread Marco Leise via Digitalmars-d-announce
Am Sat, 07 Oct 2017 12:45:30 +
schrieb Martin Nowak :

> On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote:
> > Other than that I'm happy with the package, as it provides the 
> > man pages, pre-built HTML documentation and a binary to 
> > bootstrap dmd on systems that lack a D compiler. (The use case 
> > being compilation from source for Gentoo Linux.)  
> 
> I won't reorganize the folder structure in a point release. But 
> thanks for pointing out that this needs a fix.
> Would getting the sources as a separate download (or just from 
> github) be a feasible alternative.

Yes, it is absolutely feasible to download several files.
Currently the URIs are computable from the release year and
version, so maintaining 2 or 3 URIs is ok. Also now that the
path issues are worked around on my side they have no running
maintenance cost. It is different with missing files, because
then you have to manually collect the version that matches the
release from GitHub.
If you thought of removing the sources from the archives
entirely and point to GitHub that's fine with me. The concern
Eugene brought up about checksum verification failures still
holds though. It then depends on how quickly the package
maintainers respond and fix their scripts.

-- 
Marco



Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

2018-03-22 Thread Marco Leise via Digitalmars-d-announce
I understand your opinion and I think it is all reasonable.
You talk about longer compile times since every D module is
like a C++ header. That touches one of my pet peeves with the
language or eco system as it stands and I wonder if you would
agree with me on the following:

Libraries should be tied into applications using interface
files (*.di) that are auto-generated by the compiler for the
_library author_ with inferred function attributes. If after
a code change, a declaration in the *.di file changes, the
library's interface changed and a new minor version must be
released. The language must allow to explicitly declare a
function or method as @gc, impure, etc. so the auto-inferred
attributes don't later become an issue when the implementation
changes from e.g. a pure to an impure one.
Opaque struct pointers as seen in most C APIs should also be
considered for *.di files to reduce the number of imports for
member fields.

That means:
* No more fuzzyness about whether a library function
  will remain @nogc, @safe, etc. in the next update.
* Explicit library boundaries that don't recursively import the
  world.

-- 
Marco



Re: Tilix 1.7.9 Released

2018-05-03 Thread Marco Leise via Digitalmars-d-announce
Am Mon, 30 Apr 2018 15:18:18 +
schrieb steven kladitis :

> On Sunday, 29 April 2018 at 14:49:09 UTC, Dgame wrote:
> > On Sunday, 29 April 2018 at 14:01:10 UTC, Gerald wrote:  
> >> [...]  
> >
> > Since I'm on Windows I sadly can't use it, but I suggested it 
> > to my colleagues - which are using Ubuntu - half a year ago and 
> > they use it since then and still love it. So keep up the good 
> > work! :)  
> 
> 
> I am on Windows also.  If you end up with one that works with 
> Windows. :):):):):):):)
> 
> Thanks

No no, the deal is, you Windows people switch to Linux if you 
suddenly feel like a terminal is a basic need. ;)

https://linuxmint.com/
https://manjaro.org/
https://www.ubuntu.com/
https://www.debian.org/
https://solus-project.com/
https://elementary.io/
https://antergos.com/
https://getfedora.org/
https://www.trueos.org/ (FreeBSD)
https://mxlinux.org/

-- 
Marco



Re: DConf 2018 Livestream

2018-05-03 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 03 May 2018 09:23:43 +
schrieb Mike Parker :

> On Thursday, 3 May 2018 at 07:14:51 UTC, Timoses wrote:
> 
> >
> > Will the videos of the talks etc. be available online later?  
> 
> That's the plan.
> 
> >
> > As Bastiaan Veelo wrote it appears that something went wrong 
> > with the youtube recordings. Hope this gets resolved and at 
> > least the upcoming talks, if not all, will be available.  
> 
> Yes, unfortunately some of the videos were lost. We should be 
> good from here on out.

Did the equipment only support live streaming OR recording or
what was going on? Because one gets these 128 GB SD cards for
40€ and they are reusable.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2018-07-31 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 13 Jul 2018 18:14:35 +
schrieb iris :

> Any idea about the performance of this json parser? 
> https://jsonformatter.org/json-parser ?

That one is implemented in client side JavaScript. I didn't
measure it, but the closest match in Kostya's benchmark could
be the Node JS entry that is an order of magnitude slower.

-- 
Marco



Re: Standardpaths library

2015-04-05 Thread Marco Leise via Digitalmars-d-announce
Am Sun, 05 Apr 2015 09:08:12 +
schrieb "FreeSlave" :

> 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.

This is indeed useful. I once had a specific use case where I
needed the default location for where the assets of my
application is stored. On Windows applications come with an
installer and install the assets right into the installation
directory (usually current directory). On Linux applications
store their data in /usr/share//. So with a
compile-time only template I accessed these as:

string asset1 = dirs!"myapp".staticData ~ "/image.png";

Now I realize this is a bit simplistic for several reasons:

* On Windows, one might still want to create a subdirectory to
  separate assets from program code, e.g. "data".

* On Linux, as your library shows, data directories are
  layered like this:
  ~/.local/share, /usr/local/share, /usr/share

* The _actual_ data directory is often passed into the
  configure script on Linux and no general algorithm could
  guess it.

* An application name would typically become lower-case on
  Linux while keeping its casing on Windows in e.g.
  AppData/.

Unsure if that's it, but that could make data file lookup for
application "SomeTool" go like this:

was the data directory explicitly overridden (e.g.
through ./configure or by the programmer)?
  return overridden_dir;  // note: relative directories expand
as based on executable directory
is this Linux?
  for (dir in
  ["${XDG_DATA_HOME}"/sometool, /usr/local/share/sometool, /usr/share/sometool])
is the file in dir ?
  return dir
is this Windows?
  return executable_path

This goes a bit into heuristics and best practices, so it
probably doesn't fit with your library that provides
clearly defined standard paths from the desktop environment.

Aside from that I think it is a common enough use case to
lookup assets that ship with your program in the "typical"
installation directories.


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?

-- 
Marco



Re: Standardpaths library

2015-04-06 Thread 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

2015-04-06 Thread 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: Standardpaths library

2015-04-08 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 07 Apr 2015 11:58:58 +
schrieb "Kagamin" :

> On Monday, 6 April 2015 at 21:40:28 UTC, Marco Leise wrote:
> > 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).
> 
> Though it's unusual for an average programmer to figure out the 
> correct usage of roaming profiles :)

All they need to know is that Roaming must only contain small
and machine independent files.

(Why? Because in environments where users profiles are stored
on servers, this is the part that gets synced with those
servers. So e.g. a browser cache should not end up there, nor
should configuration that makes sense only on the current
workstation.)

Frankly, I didn't know until FreeSlave's library brought it
up. :D
Anyways my idea of portable libraries is that they should not
implement the least common denominator, but the full width of
what is available or not across different systems and offer a
common API for that, so you have the option to write well
behaving applications while rewriting as little code as
possible.

Two examples:
There is an "application menu" in OS X and in
Gnome 3, but other desktops don't provide it. I would support
it, so applications integrate nicely with these desktops and
turn it into another main menu item or taskbar right-click
menu on other desktops.
POSIX doesn't close file handles for spawned child-processes
by default, which is now considered a bad default by most.
I think a portable library should try to provide the same
functionality across systems and open files in "close on exec"
mode by default on POSIX so it is similar to Windows.

-- 
Marco



Re: Standardpaths library

2015-04-08 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 07 Apr 2015 17:27:34 +
schrieb "FreeSlave" :

> On Monday, 6 April 2015 at 21:40:28 UTC, Marco Leise wrote:
> >
> > 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. ;)
> 
> Just found out, there's also special Saved Games directory on 
> Windows. But only starting with Vista, therefore it's not CSIDL, 
> but KNOWNFOLDERID (same as for Downloads). Still I did not find 
> fairly new winapi headers for D. Seems like the most use 
> translation of MinGW headers which stuck at, likely, Windows XP 
> era. Although we could just read some paths from registry 
> avoiding calling SHGetKnownFolderPath, it's way too hacky.

The druntime Windows headers are written on a "as needed"
basis. I don't think anyone would object if you added
something you need, except maybe if it stops druntime from
working in WinXP in general. Don't know about enums that
are only meaningful on Vista and later...

> Currently the only Roaming directories returned by standardpaths 
> library on Windows are Templates and Applications, which is fine. 
> The whole roaming thing is specific to Windows, but it would be 
> useful to add separate function probably.

What do you think about OS agnostic code?

  string configPath =
standardPath(StandardPath.config, appName);
  string roamingConfigPath =
standardPath(StandardPath.roamingConfig, appName);

If this worked on Linux it would return the same path for both
calls, but you would avoid introducing version(Windows) switches
in user code.
The appName is there for the common use-case to get the path in
the context of the calling application. If I write a program an
want to open some "images/splash.png" in the installation
directory, I'd expect just the executable directory on Windows,
but "/usr/share//" (or one of the overrides) on Linux.
Then again, maybe opening files is outside the scope of your
library. I could imagine it would become a full file system
abstraction layer just to support correct file lookup with all
these /usr/share, /usr/local/share, ~/.local/share and manual
overrides. :p

> The same directory for configs, data and cache locations is the 
> problem. I should mention it in documentation. Though for cache 
> directory it returns AppData/Local/cache the same way as Qt does.

-- 
Marco



Re: DUB 0.9.23 released

2015-04-08 Thread Marco Leise via Digitalmars-d-announce
Am Mon, 06 Apr 2015 10:21:45 +0200
schrieb Sönke Ludwig :

> 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

How does it resolve preferences when 3 comilers are on PATH ? =)
dmd first?

>   - 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

And one idea that recently came to my mind since I'm a fan of
shared libraries. Would it work in D to say compile a shared
library and generate a number of .di files required to use it?
Similar to druntime that provides only a hand full of its
modules as .di or where necessary as .d files.

I'm looking for a perspective out of the "compile the world"
model in Dlang, since as far as I understand it, the D
front-end will always parse all imported modules recursively.
Even in single-file compilation mode, when only "app.d"
changed it would parse the whole thing down to the last corner
of all used D libraries like GtkD or vibe.d.

With the minimum amount of required .di files for libraries,
further private imports inside their modules are hidden away
from the compiler, thereby short-circuiting the "import the
world" recursion.

-- 
Marco



Re: New D tool releases

2015-06-09 Thread Marco Leise via Digitalmars-d-announce
Am Mon, 08 Jun 2015 19:18:02 +
schrieb "Brian Schott" :

> Dfix 0.2.2:
> https://github.com/Hackerpilot/dfix/releases/tag/v0.2.2
> * Fixed a bug that caused the string concatenation fix to be 
> applied
>inside of "deprecated" attributes. I plan to revert this fix if
>dmd starts accepting `deprecated("string1" ~ "string2")`
> 
> Dfmt 0.4.0-beta1 and 0.3.6
> https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.6
> * Fix a spacing bug with function contracts
> 
> https://github.com/Hackerpilot/dfmt/releases/tag/v0.4.0-beta1
> * Introduced support for `// dfmt off` and `// dfmt on` comments
> * Added the ability to configure spacing around the `:` in 
> selective
>imports.
> * Added the ability to configure indentation of case statements.
> * Added the ability to configure indentation of attribute 
> declarations.
> * Added the ability to configure formatting of labeled loops.
> 
> D-Scanner 0.2.0-beta1
> https://github.com/Hackerpilot/Dscanner/releases/tag/0.2.0-beta1
> * Fixed several bugs in the lint checks.
> * Added support for generating Emacs etags files.
> * `--imports` option can now work on more than one file at a time
> * Added undocumented public declaration check.
> * Added unused label check.
> * Added check for variables with the same name as labels.
> * Added check for redundant parenthesis.
> * Added "line" field to ctags output to work with the Tagbar 
> plugin better.
> * Unused variable declaration check is now disabled inside of 
> __traits
>expressions.
> * Undocumented declaration check is disabled for things marked
>"deprecated" or "@disable".
> * Undocumented declaration check ignores @property functions.

Sounds like a big step forward! One question though, what's
the rationale behind @properties not needing documentation?

-- 
Marco



Re: Arch Linux D package update

2015-06-09 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 04 Jun 2015 14:46:38 +
schrieb "Dicebot" :

>  - provides systemd service : `sudo systemctl enable dcd.service` to 
> start automatically upon system startup
>  - provides default /etc/dcd.conf with stdlib paths for Arch Linux

Would you mind if I copy this idea?

-- 
Marco



Re: Arch Linux D package update

2015-06-11 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 04 Jun 2015 14:46:38 +
schrieb "Dicebot" :

>  - provides systemd service : `sudo systemctl enable dcd.service` to 
> start automatically upon system startup

Is it really a system-wide server? I can see how it might be
technically necessary due to how systemd works and how you
would need to pass a different IP port for every user.
On the other hand, every user can add imports at runtime and
shut the server down. They might even have to, if they want to
switch projects and clean up the import path list.

>  - provides default /etc/dcd.conf with stdlib paths for Arch Linux

Should work so long noone gives root a XDG_CONFIG_HOME or
writes to /root/.config/dcd/dcd.conf. Just contemplating if
when running as system wide service it should generally read
from /etc/[dcd/]dcd.conf instead of user directories. Maybe
via a --system option to dcd-server.

https://github.com/Hackerpilot/DCD/blob/master/src/server.d#L248

-- 
Marco



Re: Arch Linux D package update

2015-06-12 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 12 Jun 2015 06:26:10 +
schrieb "Dicebot" :

> I will look into making it user-local service 
> (https://wiki.archlinux.org/index.php/Systemd/User), that is 
> simply I currently don't know much about and didn't want to delay 
> update much longer.

I switched back to system wide for now. If dcd-server
evolves further and starts reading not only includes but also
the port number from a user local file (or uses per-user named
sockets like some other services), I'll look into it again.
Anyways, I learned a lot about systemd during this exercise,
that I should have learned earlier. The Arch Linux Wiki is a
great source of information. :)

-- 
Marco



Re: Beta D 2.068.2-b1

2015-09-11 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 10 Sep 2015 05:37:48 +0200
schrieb Martin Nowak :

> Due to a regression in 2.068.1 we'll directly follow up with an
> unplanned point release 2.068.2.
> This is the beta for that point release.
> 
> http://downloads.dlang.org/pre-releases/2.x/2.068.2/
> 
> Please test any of your code against this beta to help finding bugs.
> 
> https://issues.dlang.org/
> 
> -Martin

I tested some code with 2.068.x today and filed this one:

https://issues.dlang.org/show_bug.cgi?id=15042

Kudos to CyberShadow at this point for the excellent "digger"
tool.

-- 
Marco



Re: Beta D 2.068.2-b1

2015-09-13 Thread Marco Leise via Digitalmars-d-announce
And I found another regression in 2.068.1:
https://issues.dlang.org/show_bug.cgi?id=15056

-- 
Marco



Re: Release D 2.068.1

2015-09-16 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 15 Sep 2015 08:39:41 +
schrieb John Colvin :

> On Monday, 14 September 2015 at 23:53:16 UTC, Martin Nowak wrote:
> > On Monday, 14 September 2015 at 20:14:45 UTC, Jack Stouffer 
> > wrote:
> >> On Monday, 14 September 2015 at 17:51:59 UTC, Martin Nowak 
> >> wrote:
> >>> What platform are you on?
> >>
> >> I'm on OS X, using the homebrew version of DMD. And homebrew 
> >> is telling me that I have 2.068.1 installed
> >
> > Well I guess it's a bug in the homebrew script then.
> > Nobody is setting the VERSION file and there is no git repo to 
> > query.
> > https://github.com/Homebrew/homebrew/blob/f8b0ff3ef63e60a1da17ec8d8e68d949b1cebc27/Library/Formula/dmd.rb#L50
> 
> Where is the VERSION file documented? Why does it need manual 
> intervention only for patch releases and pre-releases?

I noticed this as well. There are different VERSION files
depending on where you download DMD source code from: The
releases on GitHub have 2.068 while the releases on dlang.org
have 2.068.1 in VERSION. That's easy to miss when you build
from source.
(Also the dlang.org downloads add to the DMD download
statistics, which is why I use those even though they
include extra binaries for all OSs.)

-- 
Marco



Re: Walter and I talk about D in Romania

2015-10-03 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 2 Oct 2015 07:25:44 -0400
schrieb Andrei Alexandrescu :

> Walter and I will travel to Brasov, Romania to hold an evening-long 
> event on the D language. There's been strong interest in the event with 
> over 300 registrants so far.
> 
> http://curiousminds.ro
> 
> Scott Meyers will guest star in a panel following the talks. We're all 
> looking forward to it!
> 
> 
> Andrei

That's a lot of people. You must be some kind of programming
national hero in Romania. Good luck and watch out for those
C++ moroi in the audience!

-- 
Marco



Fastest JSON parser in the world is a D project

2015-10-14 Thread Marco Leise via Digitalmars-d-announce
JSON parsing in D has come a long way, especially when you
look at it from the efficiency angle as a popular benchmark
does that has been forked by well known D contributers like
Martin Nowak or Sönke Ludwig.

The test is pretty simple: Parse a JSON object, containing an
array of 1_000_000 3D coordinates in the range [0..1) and
average them.

The performance of std.json in parsing those was horrible
still in the DMD 2.066 days*:

DMD : 41.44s,  934.9Mb
Gdc : 29.64s,  929.7Mb
Python  : 12.30s, 1410.2Mb
Ruby: 13.80s, 2101.2Mb

Then with 2.067 std.json got a major 3x speed improvement and
rivaled the popular dynamic languages Ruby and Python:

DMD : 13.02s, 1324.2Mb

In the mean time several other D JSON libraries appeared with
varying focus on performance or API:

Medea : 56.75s, 1753.6Mb  (GDC)
libdjson  : 24.47s, 1060.7Mb  (GDC)
stdx.data.json:  2.76s,  207.1Mb  (LDC)

Yep, that's right. stdx.data.json's pull parser finally beats
the dynamic languages with native efficiency. (I used the
default options here that provide you with an Exception and
line number on errors.)

A few days ago I decided to get some practical use out of my
pet project 'fast' by implementing a JSON parser myself, that
could rival even the by then fastest JSON parser, RapidJSON.
The result can be seen in the benchmark results right now:

https://github.com/kostya/benchmarks#json

fast:  0.34s, 226.7Mb (GDC)
RapidJSON: 0.79s, 687.1Mb (GCC)

(* Timings from my computer, Haswell CPU, Linux amd64.)

-- 
Marco



Fastest JSON parser in the world is a D project

2015-10-14 Thread Marco Leise via Digitalmars-d-announce
fast.json usage:

UTF-8 and JSON validation of used portions by default:

auto json = parseJSONFile("data.json");

Known good file input:

auto json = parseTrustedJSONFile("data.json");
auto json = parseTrustedJSON(`{"x":123}`);

Work with a single key from an object:

json.singleKey!"someKey"
json.someKey

Iteration:

foreach (key; json.byKey)  // object by key
foreach (idx; json)// array by index

Remap member names:

@JsonRemap(["clazz", "class"])
struct S { string clazz; }

@JsonRemap(["clazz", "class"])
enum E { clazz; }

Example:

double x = 0, y = 0, z = 0;
auto json = parseTrustedJSON(`{ "coordinates": [ { "x": 1, "y": 2, "z": 3 
}, … ] }`);

foreach (idx; json.coordinates)
{
// Provide one function for each key you are interested in
json.keySwitch!("x", "y", "z")(
{ x += json.read!double; },
{ y += json.read!double; },
{ z += json.read!double; }
);
}

Features:
  - Loads double values in compliance with IEEE round-to-nearest
(no precision loss in serialization->deserialization round trips)
  - UTF-8 validation of non-string input (file, ubyte[])
  - Currently fastest JSON parser money can buy
  - Reads strings, enums, integral types, double, bool, POD
structs consisting of those and pointers to such structs

Shortcomings:
  - Rejects numbers with exponents of huge magnitude (>=10^28)
  - Only works on Posix x86/amd64 systems
  - No write capabilities
  - Data size limited by available contiguous virtual memory

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-14 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 14 Oct 2015 07:55:18 +
schrieb Idan Arye :

> On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:
> > auto json = parseTrustedJSON(`{ "coordinates": [ { "x": 1, 
> > "y": 2, "z": 3 }, … ] }`);
> 
> I assume parseTrustedJSON is not validating? Did you use it in 
> the benchmark? And were the competitors non-validating as well?

That is correct. For the benchmark parseJSONFile was used
though, which validates UTF-8 and JSON in the used portions.
That probably renders your third question superfluous. I
wouldn't know anyways, but am inclined to think they all
validate the entire JSON and some may skip UTF-8 validation,
which is a low cost operation in this ASCII file anyways.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-14 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 14 Oct 2015 10:22:37 +0200
schrieb Rory McGuire via Digitalmars-d-announce
:

> Does this version handle real world JSON?
> 
> I've keep getting problems with vibe and JSON because web browsers will
> automatically make a "1" into a 1 which then causes exceptions in vibe.
> 
> Does yours do lossless conversions automatically? 

No I don't read numbers as strings. Could the client
JavaScript be fixed? I fail to see why the conversion would
happen automatically when the code could explicitly check for
strings before doing math with the value "1". What do I miss?

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-14 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 14 Oct 2015 08:19:52 +
schrieb Per Nordlöw :

> On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
> > https://github.com/kostya/benchmarks#json
> 
> I can't find fast.json here. Where is it?

»»» D Gdc Fast  0.34226.7 «««
C++ Rapid   0.79687.1

Granted if he wrote "D fast.json" it would have been easier to
identify.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 15 Oct 2015 18:17:07 +0200
schrieb Sönke Ludwig :

> Am 15.10.2015 um 13:06 schrieb Rory McGuire via Digitalmars-d-announce:
> > In browser JSON.serialize is the usual way to serialize JSON values.
> > The problem is that on D side if one does deserialization of an object
> > or struct. If the types inside the JSON don't match exactly then vibe
> > freaks out.
> 
> For float and double fields, the serialization code should actually 
> accept both, floating point and integer numbers:
> 
> https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1603
> https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1804
> 
> Do you have a test case for your error?
 
Well it is not an error. Rory originally wrote about
conversions between "1" and 1 happening on the browser side.
That would mean adding a quirks mode to any well-behaving JSON
parser. In this case: "read numbers as strings". Hence I was
asking if the data on the client could be fixed, e.g. the json
number be turned into a string first before serialization.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 15 Oct 2015 18:46:12 +0200
schrieb Sönke Ludwig :

> Am 14.10.2015 um 09:01 schrieb Marco Leise:
> > […]
> > stdx.data.json:  2.76s,  207.1Mb  (LDC)
> >
> > Yep, that's right. stdx.data.json's pull parser finally beats
> > the dynamic languages with native efficiency. (I used the
> > default options here that provide you with an Exception and
> > line number on errors.)
> 
>  From when are the numbers for stdx.data.json? The latest results for 
> the pull parser that I know of were faster than RapidJson:
> http://forum.dlang.org/post/wlczkjcawyteowjbb...@forum.dlang.org

You know, I'm not surprised at the "D new lazy Ldc" result,
which is in the ball park figure of what I measured without
exceptions & line-numbers, but the Rapid C++ result seems way
off compared to kostya's listing. Or maybe that Core i7 doesn't
work well with RapidJSON.

I used your fork of the benchmark, made some modifications
like adding taggedalgebraic and what else was needed to make
it compile with vanilla ldc2 0.16.0. Then I removed the flags
that disable exceptions and line numbers. Compilation options
are the same as for the existing gdc and ldc2 entries. I did
not add " -partial-inliner -boundscheck=off -singleobj ".

> Judging by the relative numbers, your "fast" result is still a bit 
> faster, but if that doesn't validate, it's hard to make an objective 
> comparison.

Every value that is read (as opposed to skipped) is validated
according to RFC 7159. That includes UTF-8 validation. Full
validation (i.e. readJSONFile!validateAll(…);) may add up to
14% overhead here.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 16 Oct 2015 11:09:37 +
schrieb Per Nordlöw :

> On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
> > https://github.com/kostya/benchmarks#json
> 
> Does fast.json use any non-standard memory allocation patterns or 
> plain simple GC-usage?

Plain GC.  I found no way in D to express something as
"borrowed", but the GC removes the ownership question from the
picture. That said the only thing that I allocate in this
benchmark is the dynamic array of coordinates (1_000_000 * 3 *
double.sizeof), which can be replaced by lazily iterating over
the array to remove all allocations.

Using these lazy techniques for objects too and
calling .borrow() instead of .read!string() (which .idups)
should allow GC free usage. (Well, except for the one in
parseJSON, where I append 16 zero bytes to the JSON string to
make it SSE safe.)

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Sat, 17 Oct 2015 09:27:46 +0200
schrieb Sönke Ludwig :

> Am 16.10.2015 um 17:11 schrieb Marco Leise:
> > Am Thu, 15 Oct 2015 18:17:07 +0200
> > schrieb Sönke Ludwig :
> >
> >> (...)
> >> Do you have a test case for your error?
> >
> > Well it is not an error. Rory originally wrote about
> > conversions between "1" and 1 happening on the browser side.
> > That would mean adding a quirks mode to any well-behaving JSON
> > parser. In this case: "read numbers as strings". Hence I was
> > asking if the data on the client could be fixed, e.g. the json
> > number be turned into a string first before serialization.
> >
> 
> Okay, I obviously misread that as a once familiar issue. Maybe it indeed 
> makes sense to add a "JavaScript" quirks mode that behaves exactly like 
> a JavaScript interpreter would.

Ok, but remember: https://www.youtube.com/watch?v=20BySC_6HyY
And then think again. :D

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Sat, 17 Oct 2015 08:29:24 +
schrieb Ola Fosheim Grøstad
:

> On Saturday, 17 October 2015 at 08:20:33 UTC, Daniel N wrote:
> > On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak 
> > wrote:
> >> On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise 
> >> wrote:
> >>>   - Data size limited by available contiguous virtual memory
> >>
> >> Mmaping files for sequential reading is a very debatable 
> >> choice, b/c the common use case is to read a file once. You 
> >> should at least compare the numbers w/ drop_caches between 
> >> each run.

The results are:
* The memory usage is then fixed at slightly more than the
  file size. (While it often stays below when using the disk
  cache.)
* It would still be faster than copying the whole
  thing to a separate memory block.
* Depending on whether the benchmark system uses a HDD or SSD,
  the numbers may be rendered meaningless by a 2 seconds wait
  on I/O.
* Common case yes, but it is possible that you read JSON that
  had just been saved.

> > It's a sensible choice together with appropriate madvise().

Obviously agreed :). Just that in practice (on my HDD system)
it never made a difference in I/O bound sequential reads. So I
removed posix_madvise.

> Mmap is very expensive, as it affects all cores, you need a 
> realistic multithreaded aync benchmark on smaller files to see 
> the effect.

That's valuable information. It is trivial to read into an
allocated block when the file size is below a threshold. I
would just need a rough file size. Are you talking about 4K
pages or mega-bytes? 64 KiB maybe?

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Sat, 17 Oct 2015 11:12:08 +
schrieb Ola Fosheim Grøstad
:

> […] you could try to construct a simple benchmark where you
> iterate over memory (M*cache 3 size) using a "realistic" pattern
> like brownian motion in N threads and also repeatedly/concurrently
> load JSON code for different file sizes so that the CPUs page table
> mechanisms are stressed by mmap, cache misses and (possibly) page
> faults.
 
O.O   Are you kidding me? Just give me the correct value
already.

-- 
Marco



Re: Beta D 2.069.0-b2

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 14 Oct 2015 15:52:57 +0200
schrieb Martin Nowak :

> Second beta for the 2.069.0 release.
> 
> http://dlang.org/download.html#dmd_beta
> http://dlang.org/changelog/2.069.0.html
> 
> Please report any bugs at https://issues.dlang.org
> 
> -Martin

When I use a specific host compiler, it still picks up the
dmd.conf provided in the package and doesn't find object.d.
Should I manually delete dmd.conf before building?

-- 
Marco



Re: Beta D 2.069.0-b2

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Oh wait, false alert. That was a relic from older days. My
build script placed a dummy dmd.conf there.

I do seem to get problems with ldc2-0.16.0:

  make -C druntime -f posix.mak MODEL=32 
  ../dmd/src/dmd -conf= -c -o- -Isrc -Iimport -Hfimport/core/sync/barrier.di 
src/core/sync/barrier.d
  core.exception.AssertError@expression.d(4369): Assertion failure

That is this line of code:
https://github.com/D-Programming-Language/dmd/blob/v2.069.0-b2/src/expression.d#L4369

Stack trace (with file + line numbers now, hey!):
#0  StringExp::compare(RootObject*) (this=0xb66e30, obj=0xb65c80) at 
expression.d:4341
#1  0x004fb6ed in StringExp::equals(RootObject*) (this=0xb66e30, 
o=0xb65c80) at expression.d:4175
#2  0x004c4fe9 in match(RootObject*, RootObject*) (o1=0xb66e30, 
o2=0xb65c80) at dtemplate.d:246
#3  0x004c51c6 in arrayObjectMatch(Array*, 
Array*) (oa1=0x764aca98, oa2=0x764ac898) at dtemplate.d:290
#4  0x004cddd7 in TemplateInstance::compare(RootObject*) 
(this=0x764aca00, o=0x764ac800) at dtemplate.d:6232
#5  0x004cdaf8 in 
TemplateDeclaration::findExistingInstance(TemplateInstance*, 
Array*) (this=0x764ac600, tithis=0x764aca00, fargs=0x0) at 
dtemplate.d:2039
#6  0x004d2f24 in TemplateInstance::semantic(Scope*, 
Array*) (this=0x764aca00, sc=0x765dfc00, fargs=0x0) at 
dtemplate.d:5583
#7  0x00406877 in TemplateInstance::semantic(Scope*) 
(this=0x764aca00, sc=0x765dfc00) at dtemplate.d:5967
#8  0x0057a03a in TypeInstance::resolve(Loc, Scope*, Expression**, 
Type**, Dsymbol**, bool) (this=0x764ae100, loc=..., sc=0x765dfc00, 
pe=0x7fffcec0, pt=0x7fffcec8, ps=0x7fffceb8, intypeid=false) at 
mtype.d:7412
#9  0x0057a327 in TypeInstance::toDsymbol(Scope*) (this=0x764ae100, 
sc=0x765dfc00) at mtype.d:7459
#10 0x0043c5d6 in AliasDeclaration::semantic(Scope*) 
(this=0x764ae200, sc=0x765dfc00) at .:598
#11 0x004897f9 in Module::semantic() (this=0x76378400) at 
dmodule.d:976
#12 0x00488e0f in Import::semantic(Scope*) (this=0x76a82800, 
sc=0x76aa9c00) at dimport.d:258
#13 0x0042759a in AttribDeclaration::semantic(Scope*) 
(this=0x76a82900, sc=0x76aa9600) at attrib.d:168
#14 0x004897f9 in Module::semantic() (this=0x76a7fe00) at 
dmodule.d:976
#15 0x00488e0f in Import::semantic(Scope*) (this=0x77eca100, 
sc=0x77ed2200) at dimport.d:258
#16 0x0042759a in AttribDeclaration::semantic(Scope*) 
(this=0x77eca200, sc=0x77ecee00) at attrib.d:168
#17 0x004897f9 in Module::semantic() (this=0x77ec9000) at 
dmodule.d:976
#18 0x00567de5 in tryMain(unsigned long, char const**) (argc=8, 
argv=0x7fffe978) at mars.d:1485
#19 0x0056a567 in D main () at mars.d:1695

`sz` is 0, `string` and `len` seem to be ok.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Marco Leise via Digitalmars-d-announce
Am Sat, 17 Oct 2015 16:27:06 +
schrieb Sean Kelly :

> On Saturday, 17 October 2015 at 16:14:01 UTC, Andrei Alexandrescu 
> wrote:
> > On 10/17/15 6:43 PM, Sean Kelly wrote:
> >> If this is the benchmark I'm remembering, the bulk of the time 
> >> is spent
> >> parsing the floating point numbers. So it isn't a test of JSON 
> >> parsing
> >> in general so much as the speed of scanf.
> >
> > In many cases the use of scanf can be replaced with drastically 
> > faster methods, as I discuss in my talks on optimization 
> > (including Brasov recently). I hope they'll release the videos 
> > soon. -- Andrei
> 
> Oh absolutely. My issue with the benchmark is just that it claims 
> to be a JSON parser benchmark but the bulk of CPU time is 
> actually spent parsing floats. I'm on my phone though so perhaps 
> this is a different benchmark--I can't easily check. The one I 
> recall came up a year or so ago and was discussed on D.general.

1/4 to 1/3 of the time is spent parsing numbers in highly
optimized code. You see that in a profiler the number parsing
shows up on top, but the benchmark also exercises the
structural parsing a lot. It is not a very broad benchmark
though, lacking serialization, UTF-8 decoding, validation of
results etc. I believe the author didn't realize how over time
it became the go-to performance test. The author of RapidJSON
has a very in-depth benchmark suite, but it would be a bit of
work to get something non-C++ integrated:
https://github.com/miloyip/nativejson-benchmark
It includes conformance tests as well.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-18 Thread Marco Leise via Digitalmars-d-announce
Am Sun, 18 Oct 2015 03:40:52 +
schrieb rsw0x :

> On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
> > JSON parsing in D has come a long way, especially when you look 
> > at it from the efficiency angle as a popular benchmark does 
> > that has been forked by well known D contributers like Martin 
> > Nowak or Sönke Ludwig.
> >
> > [...]
> 
> Slightly OT:
> You have a std.simd file in your repo, was this written by you or 
> is there a current std.simd proposal that I'm unaware of?

Manu wrote that back in the days with the idea that it would
help writing portable SIMD code on many architectures:
https://github.com/TurkeyMan/simd
Working in the 3D visualization business and having held at
least one talk about SIMD it was no coincidence that he was
interested in better vector math support. Inclusion into
Phobos was planned. DMD needs some upgrading of the somewhat
ad hoc SIMD intrinsic implementation though:
https://issues.dlang.org/buglist.cgi?keywords=SIMD&resolution=---
Many instructions cannot be expressed outside of inline
assembly which doesn't inline.

-- 
Marco



Re: Beta D 2.069.0-b2

2015-10-20 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 20 Oct 2015 19:26:13 +0200
schrieb Martin Nowak :

> On 10/17/2015 09:05 PM, Marco Leise wrote:
> > Oh wait, false alert. That was a relic from older days. My
> > build script placed a dummy dmd.conf there.
> > 
> > I do seem to get problems with ldc2-0.16.0:
> 
> Are you using something befor 0.16.0-beta2, b/c I thought the problem
> was resolved.
> https://github.com/D-Programming-Language/dmd/pull/5025#issuecomment-142143727

Indeed I should have checked that. I'm using 0.16.0_alpha4.
Alright then. Everything works as designed now. :)

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-21 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 21 Oct 2015 17:00:39 +
schrieb Suliman :

> >> > Nice! I see you are using bitmasking trickery in multiple 
> >> > places. stdx.data.json is mostly just the plain lexing 
> >> > algorithm, with the exception of whitespace skipping. It was 
> >> > already very encouraging to get those benchmark numbers that 
> >> > way. Good to see that it pays off to go further.
> >>
> >> Is there any chance that new json parser can be include in 
> >> next versions of vibed? And what need to including its to 
> >> Phobos?
> >
> > It's already available on code.dlang.org:
> > http://code.dlang.org/packages/std_data_json
> 
> 
> Jonatan, I mean https://github.com/mleise/fast :)

That's nice, but it has a different license and I don't think
Phobos devs would be happy to see all the inline assembly I
used and duplicate functionality like the number parsing and
UTF-8 validation and missing range support.

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-21 Thread Marco Leise via Digitalmars-d-announce
Am Wed, 21 Oct 2015 04:17:16 +
schrieb Laeeth Isharc :

> Very impressive.
> 
> Is this not quite interesting ?  Such a basic web back end 
> operation, and yet it's a very different picture from those who 
> say that one is I/O or network bound.  I already have JSON files 
> of a couple of gig, and they're only going to be bigger over 
> time, and this is a more generally interesting question.
> 
> Seems like you now get 2.1 gigbytes/sec sequential read from a 
> cheap consumer SSD today...

You have this huge amount of Reddit API JSON, right?
I wonder if your processing could benefit from the fast
skipping routines or even reading it as "trusted JSON".

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-22 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 22 Oct 2015 06:10:56 -0700
schrieb Walter Bright :

> On 10/21/2015 3:40 PM, Laeeth Isharc wrote:
> > Have you thought about writing up your experience with writing fast json?  
> > A bit
> > like Walter's Dr Dobbs's article on wielding a profiler to speed up dmd.
> 
> Yes, Marco, please. This would make an awesome article, and we need articles 
> like that!
> 
> You've already got this:
> 
>  https://github.com/kostya/benchmarks/pull/46#issuecomment-147932489
> 
> so most of it is already written.

There is at least one hurdle. I don't have a place to publish
articles, no personal blog or site I contribute articles to
and I don't feel like creating a one-shot one right now. :)

-- 
Marco



Re: Fastest JSON parser in the world is a D project

2015-10-28 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 27 Oct 2015 14:00:06 +
schrieb Martin Nowak :

> On Tuesday, 27 October 2015 at 13:14:36 UTC, wobbles wrote:
> >> How can `coordinates` member be known at compile-time when the 
> >> input argument is a run-time string?
> >
> > I suspect through the opDispatch operator overload.
> >
> > http://dlang.org/operatoroverloading.html#dispatch
> 
> Yikes, this is such an anti-pattern.
> https://github.com/rejectedsoftware/vibe.d/issues/634

For my defense I can say that the JSON parser is not a range
and thus less likely to be used in UFCS chains. It can be
replaced with .singleKey!"coordinates"()

-- 
Marco



Re: Tonight: Introduction to D at Codeaholics (HK)

2015-11-16 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 12 Nov 2015 01:30:06 +0800
schrieb Lionello Lunesu :

> * Why doesn't D explicitly specify the exceptions that can be thrown? 
> (To which I answered that I never saw the point in Java and only found 
> it tedious. This did not convince the person.)

Maybe that's your point of view or maybe you were just
undecided. When you write a library it is sometimes better to
be explicit about your interface and that includes any
exceptions. This not only enables users of the library to
selectively catch exceptions they can handle at layer X, but
facilitates static checks:

* Are any exceptions missing from DDoc/@throws that are
  thrown in the code? (Potential for auto-generating the DDoc.)
* A function is nothrow, but the user only catches, e.g.
  UtfException explicitly. Is that the only exception type
  that could occur?

There were some more nice points that I don't remember from
when I failed at implementing this many months ago. The
questioner has my sympathy in any case, but it's certainly not
a priority.

The way I wanted to implement it was by making attribute-less
functions map to @throws(Exception), which implicitly makes
the feature opt-in: It is always correct to state a super set
of the actual thrown exceptions in an API to have room for
extensions. Thrown exceptions would be collected much like
nothrow is deduced right now, but as a list with respect to the
hierarchical nature of Exceptions.

-- 
Marco



Re: Graillon 1.0, VST effect fully made with D

2015-11-27 Thread Marco Leise via Digitalmars-d-announce
We can probably agree that we don't know about the impact on a
large multimedia application written in D. What you can
communicate is: Create a @nogc thread routine and don't
register it with the GC to write real-time VSTs.

Guillaume did a good job, taking the GC out of the real-time
thread. It's D, it is a bit of a hack, it's the correct way to
do it and works. But I don't see it debunking any myths about
GC and real time...
A) It doesn't mix them to begin with.
B) "Realtime GCs" are a thing. D's GC is not optimized for
   such a use case.
C) With a small heap it doesn't matter. (We need more complex
   multimedia projects.)

What I've seen is a program, a non-linear video editor, called
PowerDirector that pauses for seconds every now and then.
These pauses reminded me a lot of GC pauses, but I can't be
sure. Although memory use is less after the pause, it could
also be a cleaning of caches. In any case quite a few of these
applications try to make "good use" of available RAM, causing
constant memory pressure.

Now there has been so much talk about the GC that I don't even
know what the filter does!

-- 
Marco



Re: D Profile Viewer

2016-03-24 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 24 Mar 2016 20:34:07 +
schrieb Andrew :

> Hi
> 
> I wrote a program to turn the non-human-readable trace.log into 
> an interactive HTML file that can be used to help profile a D 
> program.
> 
> Its here: https://bitbucket.org/andrewtrotman/d-profile-viewer
> 
> There's also a readme that (hopefully) explains how to use it.
> 
> Please let me know if you find any bugs.
> 
> Andrew.

Sexy pie charts! Although I'm using OProfile since it works
without instrumenting the code.

-- 
Marco



Re: Release D 2.071.0

2016-04-11 Thread Marco Leise via Digitalmars-d-announce
Am Thu, 07 Apr 2016 10:13:35 +
schrieb Dicebot :

> On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote:
> > Glad to announce D 2.071.0.
> >
> > http://dlang.org/download.html
> >
> > This release fixes many long-standing issues with imports and 
> > the module
> > system.
> > See the changelog for more details.
> >
> > http://dlang.org/changelog/2.071.0.html
> >
> > -Martin  
> 
> It is second time git tag for DMD release refers to commit with 
> VERSION file content which doesn't match the tag. May indicate 
> something is wrong in release procedure.

Or maybe something is wrong with source based Linux
distributions in this time and age. I don't know. But I'm glad
that you fire proof the source bundles first, before I move my
lazy ass to update DMD packages for Gentoo. I hope to start
from a good, clean 2.071.0/2.071.1 tar ball. :D

Nice work on the import bugs. There is so much less on the
attic now.

-- 
Marco



Re: Blog post: PGO: Optimizing D's virtual calls

2016-04-20 Thread Marco Leise via Digitalmars-d-announce
Am Fri, 15 Apr 2016 09:04:21 +
schrieb Johan Engelen :

> On Wednesday, 13 April 2016 at 11:34:26 UTC, Johan Engelen wrote:
> > Hi all,
> >   I've written an article about how I implemented 
> > profile-guided optimization (PGO) of virtual calls to direct 
> > calls (a micro-micro-optimization, expected performance gain of 
> > just a few percent if any!).  
> 
> I've updated the article with performance measurements of just 
> the D code of LDC: the improvement with PGO is about 7% !

Compilers are full of logic that makes some code 0.5% faster.
The sum of all these little bits is what makes up an
optimizing compiler and if today you still find an optimization
that's worth 1 or 2% you have a jackpot!

7% is quite a bit more than any other option like -cpu=native
could achieve. If feasible I'd enjoy if ldc2 shipped with a
pgo configuration option. If you use the compiler in a lot of
edit/compile cycles it will pay off.

-- 
Marco



Re: LZ4 decompression at CTFE

2016-04-27 Thread Marco Leise via Digitalmars-d-announce
Am Tue, 26 Apr 2016 23:55:46 -0700
schrieb Walter Bright :

> On 4/26/2016 3:05 PM, Stefan Koch wrote:
> > Hello,
> >
> > originally I want to wait with this announcement until DConf.
> > But since I working on another toy. I can release this info early.
> >
> > So as per title. you can decompress .lz4 flies created by the standard lz4hc
> > commnadline tool at compile time.
> >
> > No github link yet as there is a little bit of cleanup todo :)
> >
> > Please comment.  
> 
> Sounds nice. I'm curious how it would compare to:
> 
> https://www.digitalmars.com/sargon/lz77.html
> 
> https://github.com/DigitalMars/sargon/blob/master/src/sargon/lz77.d

There exist some comparisons for the C++ implementations
(zlib's DEFLATE being a variation of lz77):
http://catchchallenger.first-world.info//wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO
https://pdfs.semanticscholar.org/9b69/86f2fff8db7e080ef8b02aa19f3941a61a91.pdf 
(pg.9)

The high compression variant of lz4 basically like gzip with
9x faster decompression. That makes it well suited for use
cases where you compress once, decompress often and I/O
sequential reads are fast e.g. 200 MB/s or the program does
other computations meanwhile and one doesn't want
decompression to use a lot of CPU time.

-- 
Marco



Re: QtE5 - is a wrapping of Qt-5 for D

2016-06-20 Thread Marco Leise via Digitalmars-d-announce
Very nice!

-- 
Marco



Re: new cpuid is ready for comments

2016-07-14 Thread Marco Leise via Digitalmars-d-announce
Am Mon, 11 Jul 2016 16:30:44 +
schrieb Ilya Yaroshenko :

> Please report your CPU (GitHub/Gist):

Instead of yet another Haswell/Broadwell, here is an oldie but
goldie: A 16 year old Pentium-III-M from an IBM T23 notebook:

https://gist.github.com/mleise/4ed5637371ca5cea07bef8241adc7d80

I repost this in your bug tracker momentarily.

-- 
Marco