karabuta via Digitalmars-d | 30 Jul 15:43 2015

D for Game Development

D is really cool and makes a good candidate for developing a 
game. Are there any guys out there using D for indie games?

For some time I have been seeing some cool game engine being 
developed in the DUB repo. What more is happening? I don't see 
derelictSDl and derelictSFML activities much. Whatup?

Kingsley via Digitalmars-d | 30 Jul 13:19 2015

Working with pdf

Hi

Can anyone recommend any ways of pdf creation using D.

I am generating an HTML and JavaScript page but I would like it 
in pdf format as well.

Max Klyga via Digitalmars-d | 30 Jul 12:40 2015

Dependent types in half of D

Just noticed a nice blog post about mapping dependent type 
applications to D.
http://www.infognition.com/blog/2015/dependent_types_in_d.html

reddit: 
https://www.reddit.com/r/programming/comments/3f59f4/dependent_types_in_half_of_d/

Suliman via Digitalmars-d | 30 Jul 10:04 2015

Implement Parse implementation like in Red

Red have very nice future called Parse 
http://www.red-lang.org/2013/11/041-introducing-parse.html

Is it's possible to implement something like it in D/Phobos?

Re: std.data.json formal review

W dniu 2015-07-29 o 00:37, H. S. Teoh via Digitalmars-d pisze:
> On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
> [...]
>> 3. Stepping back a bit, when I think of parsing JSON data, I think:
>>
>>      auto ast = inputrange.toJSON();
>>
>> where toJSON() accepts an input range and produces a container, the
>> ast. The ast is just a JSON value. Then, I can just query the ast to
>> see what kind of value it is (using overloading), and walk it as
>> necessary.
>
> +1. The API should be as simple as possible.
>
> Ideally, I'd say hook it up to std.conv.to for maximum flexibility. Then
> you can just use to() to convert between a JSON container and the value
> that it represents (assuming the types are compatible).
>
> OTOH, some people might want the option of parser-driven data processing
> instead (e.g. the JSON data is very large and we don't want to store the
> whole thing in memory at once). I'm not sure what a good API for that
> would be, though.

Here's mine range based parser, you can parse 1 TB json file without a 
single allocation. It needs heavy polishing, but I didnt have time/need 
to do it. Basically a WIP, but maybe someone will find it useful.

https://github.com/pszturmaj/json-streaming-parser

(Continue reading)

Re: Read text file fast, how?

On 2015-07-29 19:02, Johan Holmberg via Digitalmars-d wrote:

> Is there a LDC that incorporates the changes coming in DMD 2.068 that
> made my code run 10x faster compared with 2.067?

I would guess that there isn't.

--

-- 
/Jacob Carlborg

Re: std.data.json formal review

On 7/28/2015 10:49 PM, H. S. Teoh via Digitalmars-d wrote:
> How does a linear range of nodes convey a nested structure?

You'd need to add a special node type, 'end'. So an array [1,true] would look like:

     array number true end

Re: std.data.json formal review

Am 29.07.2015 um 18:47 schrieb H. S. Teoh via Digitalmars-d:
> On Wed, Jul 29, 2015 at 03:22:05PM +0000, Don via Digitalmars-d wrote:
>> On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
> [...]
>>> The possible JSON values are:
>>>     string
>>>     number
>>>     object (associative arrays)
>>>     array
>>>     true
>>>     false
>>>     null
>>>
>>> Since these are D builtin types, they can actually be a simple union
>>> of D builtin types.
>>
>> Related to this: it should not be importing std.bigint. Note that if
>> std.bigint were fully implemented, it would be very heavyweight
>> (optimal multiplication of enormous integers involves fast fourier
>> transforms and all kinds of odd stuff, that's really bizarre to pull
>> in if you're just parsing a trivial little JSON config file).
>>
>> Although it is possible for JSON to contain numbers which are larger
>> than can fit into long or ulong, it's an abnormal case. Many apps
>> (probably, almost all) will want to reject such numbers immediately.
>> BigInt should be opt-in.
>>
>> And, it is also possible to have floating point numbers that are not
>> representable in double or real. BigInt doesn't solve that case.
>>
(Continue reading)

Re: std.data.json formal review

> Here's a thought: what about always storing JSON numbers as 
> strings (albeit tagged with the "number" type, to differentiate 
> them from actual strings in the input), and the user specifies 
> what type to convert it to?  The default type can be something 
> handy, like int, but the user has the option to ask for size_t, 
> or double, or even BigInt if they want (IIRC, the BigInt ctor 
> can initialize an instance from a digit string, so if we adopt 
> the convention that non-built-in number-like types can be 
> initialized from digit strings, then std.json can simply take a 
> template parameter for the output type, and hand it the digit 
> string. This way, we can get rid of the std.bigint dependency, 
> except where the user actually wants to use BigInt.)

Some JSON files can be quite large...

For example, I have a compressed 175 Gig of Reddit comments (one 
file per month) I would like to work with using D, and time + 
memory demands = money.

Wouldn't it be a pain not to store numbers directly when parsing 
in those cases (if I understood you correctly)?

Re: Points of Failure

On Wednesday, 29 July 2015 at 15:21:43 UTC, H. S. Teoh wrote:
>
> Hmm. I would've thought things couldn't possibly get easier 
> than `git clone $url; vim $pathname`...

`git clone` can take awhile with large repositories, like mono.

Kagamin via Digitalmars-d | 29 Jul 17:32 2015

Re: Points of Failure

On Wednesday, 29 July 2015 at 15:21:43 UTC, H. S. Teoh wrote:
> git

You don't only do things differently from everybody else, you do 
them as if nobody else even exists.


Gmane