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

[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: Why think unit tests should be in their own source code hierarchy instead of side-by-side

[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: Beta 2.076.1

[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

[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: new cpuid is ready for comments

[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

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

[Marco Leise via Digitalmars-d-announce]

Very nice!

-- 
Marco

Re: LZ4 decompression at CTFE

[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: Blog post: PGO: Optimizing D's virtual calls

[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: Release D 2.071.0

[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: D Profile Viewer

[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: Graillon 1.0, VST effect fully made with D

[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: Tonight: Introduction to D at Codeaholics (HK)

[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: Fastest JSON parser in the world is a D project

[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: Fastest JSON parser in the world is a D project

[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

[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

[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: Beta D 2.069.0-b2

[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: Beta D 2.069.0-b2

[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: Beta D 2.069.0-b2

[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: Fastest JSON parser in the world is a D project

[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

[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

[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

[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

Fastest JSON parser in the world is a D project

[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

[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

[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

[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: Walter and I talk about D in Romania

[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

Re: Release D 2.068.1

[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: Beta D 2.068.2-b1

[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: Beta D 2.068.2-b1

[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: Arch Linux D package update

[Marco Leise via Digitalmars-d-announce]

Am Fri, 12 Jun 2015 06:26:10 +
schrieb Dicebot pub...@dicebot.lv:

 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: Arch Linux D package update

[Marco Leise via Digitalmars-d-announce]

Am Thu, 04 Jun 2015 14:46:38 +
schrieb Dicebot pub...@dicebot.lv:

  - 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: New D tool releases

[Marco Leise via Digitalmars-d-announce]

Am Mon, 08 Jun 2015 19:18:02 +
schrieb Brian Schott briancsch...@gmail.com:

 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

[Marco Leise via Digitalmars-d-announce]

Am Thu, 04 Jun 2015 14:46:38 +
schrieb Dicebot pub...@dicebot.lv:

  - 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: DUB 0.9.23 released

[Marco Leise via Digitalmars-d-announce]

Am Mon, 06 Apr 2015 10:21:45 +0200
schrieb Sönke Ludwig slud...@rejectedsoftware.com:

 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: Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Tue, 07 Apr 2015 11:58:58 +
schrieb Kagamin s...@here.lot:

 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

[Marco Leise via Digitalmars-d-announce]

Am Tue, 07 Apr 2015 17:27:34 +
schrieb FreeSlave freeslav...@gmail.com:

 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/app name/ (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: Standardpaths library

[Marco Leise via Digitalmars-d-announce]

Am Sun, 05 Apr 2015 12:31:23 +
schrieb FreeSlave freeslav...@gmail.com:

 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:
!-- the following element will be removed in the future --
dir~/.fonts/dir
  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 freeslav...@gmail.com:

 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

[Marco Leise via Digitalmars-d-announce]

Am Sun, 05 Apr 2015 09:08:12 +
schrieb FreeSlave freeslav...@gmail.com:

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

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:
  !-- the following element will be removed in the future --
  dir~/.fonts/dir
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: Devisualization.Image

[Marco Leise via Digitalmars-d-announce]

Am Tue, 18 Nov 2014 12:37:54 +0300
schrieb Timur Gafarov gecko0...@gmail.com:

 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

[Marco Leise via Digitalmars-d-announce]

Am Wed, 19 Nov 2014 00:35:09 +0100
schrieb Marco Leise marco.le...@gmx.de:

  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: Atmosphere GM - Statistical package

[Marco Leise via Digitalmars-d-announce]

Am Fri, 24 Oct 2014 17:54:26 +
schrieb Ilya Yaroshenko ilyayaroshe...@gmail.com:

 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: Digger 1.0

[Marco Leise via Digitalmars-d-announce]

Am Mon, 22 Sep 2014 18:59:12 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:

 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
  digitalmars-d-announce@puremagic.com 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: New Beta: 2.066.1-rc1 is Now Available

[Marco Leise via Digitalmars-d-announce]

Am Fri, 12 Sep 2014 01:51:33 +0900
schrieb Andrew Edwards rid...@yahoo.com:

 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

[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

[Marco Leise via Digitalmars-d-announce]

Am Fri, 12 Sep 2014 03:16:52 +0900
schrieb Andrew Edwards rid...@yahoo.com:

 Clear cache and try again.

Thx, try again now was enough.

-- 
Marco

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

[Marco Leise via Digitalmars-d-announce]

Am Tue, 09 Sep 2014 10:20:43 +
schrieb Don x...@nospam.com:

 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. g
 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: Dlang on Gentoo (update)

[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

Dlang on Gentoo (update)

[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