Re: Calypso progress report (+ updated MingW64 build)
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote: make Calypso an optional shared library Does it's mean, that Calypso can be work as plugin for Clang?
Re: Calypso progress report (+ updated MingW64 build)
On Wednesday, 21 October 2015 at 23:40:15 UTC, Elie Morisse wrote: It's been a while since the last update, so here's a quick one before making the jump to LDC 0.16. You should write a blog post explaining what you have done so far and what remains to be done, then submit it to the usual link sites. I bet a lot of people would be interested in reading about this approach.
Re: It's a class! It's a struct! It's ... SuperStruct!
On Wednesday, 21 October 2015 at 23:09:52 UTC, Timon Gehr wrote: "A call signature for a given member is 'compatible' * if, for an instance of any one of `SubTypes`, that member can be called with * the provided set of arguments _and_ all such calls have a common return type." Probably you could/should return your SuperStruct instead of the/when there is no common return type. Interesting idea! At first I thought you meant returning the original SuperStruct, but then I realized it could be a SuperStruct of the return types. That could be really nice for functions that return different types of ranges, as your return type would just be 'something' that has 'front, top, empty, ect.'. Come to think of it, SuperStruct actually sounds pretty similar to std.range.chooseAmong (which I just realized exists).
Re: Calypso progress report (+ updated MingW64 build)
On Thursday, 22 October 2015 at 01:19:19 UTC, Andrei Alexandrescu
wrote:
On 10/21/2015 07:40 PM, Elie Morisse wrote:
It's been a while since the last update, so here's a quick one
before
making the jump to LDC 0.16.
Great news! What's the story on exceptions? Does Calypso allow
D code to catch exceptions thrown from C++ code? -- Andrei
Hi Andrei,
Not yet but I've looked into it, the plan is to add:
catch (C++) (...) { }
statements and make Clang translate them into C++ landing pads
(as for imports the parser will query the language plugins when
encountering two pairs of (), so the C++-specific statement will
be part of Calypso, not DMD).
Then add a "C++ exception class" handler in LDC's personality
function:
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/eh/libunwind.d#L327
Easier said that done but Clang should make the std::type_info
matching doable.
So it's on the roadmap just after the merge of LDC 0.16.
Re: Calypso progress report (+ updated MingW64 build)
On 10/21/2015 07:40 PM, Elie Morisse wrote: It's been a while since the last update, so here's a quick one before making the jump to LDC 0.16. Great news! What's the story on exceptions? Does Calypso allow D code to catch exceptions thrown from C++ code? -- Andrei
Calypso progress report (+ updated MingW64 build)
It's been a while since the last update, so here's a quick one before making the jump to LDC 0.16. Kelly added a more complex Qt5 demo, I recently added an Ogre3D one: https://www.youtube.com/watch?v=eryhDOa9MV0 https://github.com/Syniurge/Calypso/blob/master/tests/calypso/ogre3d/demo.d Ogre3D is a much more "sophisticated" creature than Qt5, relies on some Boost libraries, so Calypso had to reach quite another level to support it. As a reminder Calypso (https://github.com/Syniurge/Calypso) is an experimental LDC fork which lets you use C/C++ libraries without having to write bindings. Its main additions: • Maps C++ functions, global variables, structs, classes, unions, enums, typedefs, templates • C++ class and function template instantiation (including global variables inside class templates with their proper initialization in the global ctor) • C++ class creation with the correct calls to ctors (destruction is still disabled) • Virtual function calls • Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • D classes inheriting from C++ classes, including the correct vtable generation for the C++ part of the class (except for MSVC which has a different ABI) • Debug info generation for any C++ symbol instantiated by D code The roadmap is: merge upstream LDC 0.16 into Calypso → C++ exception support → better C++11 support → MSVC support → extend magicport2 to convert Calypso to D (and Calypso could "bootstrap" itself to avoid writing bindings to Clang) → make Calypso an optional shared library On Linux Calypso should be in a state usable enough to start a project assuming the lack of C++ exceptions or class destruction isn't a blocker to start it (but I'm looking into the latter right now), it has held up quite well while expanding the Ogre and Qt5 demos, and my own project based on Qt5 and OpenCV. So far only Kelly Wilson has been testing Calypso with various libs and expanded the test cases (most of the libstdc++ samples are his), so more testing would be very helpful. Updated MingW build: http://www.homo-nebulus.fr/dlang/Calypso-Mingw64-i686-4.9.3-posix-dwarf-rt_v4-rev1.tar.xz
dfmt 0.4.1
dfmt is a formatter for D source code. Changes from 0.4.0: * #189: Better formatting for "in" expressions where the right side of the "in" operator is a function literal. * #190: Fix a bug where whitespace was removed from some ASM statements. * #191: Add "-i" as an alias for the "--inplace" option and document the existence of "-t" as an alias for the "indent_style" option. * #192: Fix a mistake in the README https://github.com/Hackerpilot/dfmt/releases/tag/v0.4.1
Re: It's a class! It's a struct! It's ... SuperStruct!
On 10/18/2015 09:00 PM, rcorre wrote:
SuperStruct is a struct that acts like a class:
---
struct Square {
float size;
float area() { return size * size; }
}
struct Circle {
float r;
float area() { return r * r * PI; }
}
alias Shape = SuperStruct!(Square, Circle);
// look! polymorphism!
Shape sqr = Square(2);
Shape cir = Circle(4);
Shape[] shapes = [ sqr, cir ];
// call functions that are shared between the source types!
assert(shapes.map!(x => x.area).sum.approxEqual(2 * 2 + 4 * 4 * PI));
---
SuperStruct is basically a Variant that exposes the common members of
its source
types. You can check it out here:
https://github.com/rcorre/superstruct
I'm not quite sure if this is a good idea (or if it already exists in some
form that I haven't seen), but it was fun to work on. There's a lot more
info on
the README if you're curious. Let me know what you think!
"A call signature for a given member is 'compatible'
* if, for an instance of any one of `SubTypes`, that member can be
called with
* the provided set of arguments _and_ all such calls have a common
return type."
Probably you could/should return your SuperStruct instead of the/when
there is no common return type.
Re: Fastest JSON parser in the world is a D project
On 10/21/2015 04:38 PM, Laeeth Isharc wrote: On Wednesday, 21 October 2015 at 19:03:56 UTC, Suliman wrote: Could anybody reddit this benchmark? done https://www.reddit.com/r/programming/comments/3pojrz/the_fastest_json_parser_in_the_world/ Getting good press. Congratulations! -- Andrei
Re: Fastest JSON parser in the world is a D project
On Wednesday, 21 October 2015 at 22:24:30 UTC, Marco Leise wrote: 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". The couple of gig were just Quandl metadata for one provider, but you're right I have that Reddit data too. And that's just a beginning. What some have been doing for a while, I'm beginning to do now, and many others will be doing in the next few years - just as soon as they have finished having meetings about what to do... I don't suppose they'll be using python, at least not for long. I am sure it could benefit - I kind of need to get some other parts going first. (For once it truly is a case of Knuth's 97%). But I'll be coming back to look at best way, for json, but text files more generally. 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. And actually if you have time, would you mind dropping me an email? laeeth at kaledicassociates.com Thanks. Laeeth.
Re: It's a class! It's a struct! It's ... SuperStruct!
On Tuesday, 20 October 2015 at 15:22:41 UTC, Vladimir Panteleev wrote: "This video is not available from your location". I haven't been able to find a mirror that's watchable from here either. Same here, though I finally googled out it's key phrase: "It's a floor wax and a dessert topping!" Pretty much explains Walter's suggestion :D
Re: Fastest JSON parser in the world is a D project
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
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
On Wednesday, 21 October 2015 at 19:03:56 UTC, Suliman wrote: Could anybody reddit this benchmark? done https://www.reddit.com/r/programming/comments/3pojrz/the_fastest_json_parser_in_the_world/
Re: Fastest JSON parser in the world is a D project
Could anybody reddit this benchmark?
Re: Fastest JSON parser in the world is a D project
On Wednesday, 21 October 2015 at 09:59:09 UTC, Kapps wrote: On Wednesday, 21 October 2015 at 04:17:19 UTC, Laeeth Isharc wrote: Seems like you now get 2.1 gigbytes/sec sequential read from a cheap consumer SSD today... Not many consumer drives give more than 500-600 MB/s (SATA3 limit) yet. There are only a couple that I know of that reach 2000 MB/s, like Samsung's SM951, and they're generally a fair bit more expensive than what most consumers tend to buy (but at about $1 / GB, still affordable for businesses certainly). Yes - that's the one I had in mind. It's not dirt cheap, but at GBP280 if you have some money and want speed, the price is hardly an important factor. I should have said consumer grade rather than consumer, but anyway you get my point. That's today, in 2015. Maybe one can do even better than that by striping data, although it sounds like it's not that easy, but still. "The future is here already; just unevenly distributed". Seems like if you're processing JSON, which is not the most difficult task one might reasonably want to be doing, then CPU+memory is the bottleneck more than the SSD. I don't know what outlook is for drive speeds (except they probably won't go down), but data sets are certainly not shrinking. So I am intrigued by the difference between what people say is typical and what seems to be the case, certainly in what I want to do.
Re: Fastest JSON parser in the world is a D project
> 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 :)
Re: Coedit 2 alpha 1 - now with dub
On Tuesday, 20 October 2015 at 12:46:51 UTC, BBasile wrote: On Monday, 19 October 2015 at 19:56:15 UTC, Jack Stouffer wrote: On Monday, 19 October 2015 at 15:03:52 UTC, BBasile wrote: On Saturday, 17 October 2015 at 16:31:38 UTC, DK wrote: Hi, this link https://github.com/BBasile/Coedit/ doesn't work for me (( Coedit is now (since three weeks to be more accurate) a private software. I've removed all what was deletable but obviously all the previous announces on the NG are going to remain. Any particular reason? Yes, I don't care anymore. The fact is that I always knew that I was losing my time but this was acceptable until a certain point. Anyway, you know, when you like no longer, negative critics take over. So, to continue would have been quite unhealthy. Why not just leave it up for someone else to take over in a fork?
Re: Fastest JSON parser in the world is a D project
On Wednesday, October 21, 2015 06:36:31 Suliman via Digitalmars-d-announce wrote: > On Monday, 19 October 2015 at 07:48:16 UTC, Sönke Ludwig wrote: > > Am 16.10.2015 um 18:04 schrieb Marco Leise: > >> 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. > >> > > > > 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 For it to get into Phobos, it has to get through the review process and be voted in. It was put up for formal review two or three months ago, but that didn't get to the point that it was voted on (I assume that there was more work that needed to be done on it first; I haven't really read through that thread though, so I don't know - I was too busy when the review started to get involved in it). So, whatever needs to be done for it to be ready for a formal vote needs to be done, and then it can be voted in, but all of that takes time, so if you want to use it soon, you might as well just grab it from code.dlang.org - and it will make it so that you're in a better position to give feedback on it as well so that it will be that much better if/when it makes it into Phobos. - Jonathan M Davis
O'Reily Software Architecture Call for Speakers
http://conferences.oreilly.com/software-architecture-ny/public/cfp/420 Warning though - the date is close to DConf :o). We plan to announce date and location of DConf 2016 soon. Andrei
Re: The D Language Foundation is now incorporated
On 2015-10-20 19:08, Andrei Alexandrescu wrote: Thanks for the inquiry. We've had our first organizational meeting during which we decided to proceed with creating an EIN (Employer Identification Number), which we have since acquired: 47-5352856. Also we decided to proceed with creating a bank account. I'm currently investigating choosing an appropriate bank, preferably United Bank of Do Not Rip Me Off. Suggestions welcome. We'll also proceed with inquiring for an accountant to deal with foundation's yearly taxes. To address your question: there are currently three officers: Walter Bright (President), Ali Çehreli (Secretary), and myself (Vice President and Treasurer). A member is a supporter and possibly sponsor of the Foundation. We're considering several membership kinds (e.g. honorific, student, individual, corporate) and levels, some that entail a sponsorship, and some that involve no monetary involvement. An officer is an administrator of the Foundation. We have been advised independently by our attorney and by a different foundation creator that we should keep officers to a minimum, three being the sweet spot. Please create a new thread with the above summary or something similar. More officers means more politics. So we're moving forward with three officers for the time being. Of course the foundation can have several employees that are not officers; we hope to get there soon. So currently there are 100% officers, that means 100% politics. Meaning nothing will get done :) Sorry, I couldn't help myself :) -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
On Wednesday, 21 October 2015 at 04:17:19 UTC, Laeeth Isharc wrote: Seems like you now get 2.1 gigbytes/sec sequential read from a cheap consumer SSD today... Not many consumer drives give more than 500-600 MB/s (SATA3 limit) yet. There are only a couple that I know of that reach 2000 MB/s, like Samsung's SM951, and they're generally a fair bit more expensive than what most consumers tend to buy (but at about $1 / GB, still affordable for businesses certainly).
