Re: DerelictSASS
Major update for DerelictSASS and Sassed due to C API change in libsass. DerelictSASS - v2.0.0 https://github.com/Lodin/DerelictSASS There are complete interface change: as I know, previous libsass C API does not work anymore, and new API was written. Sassed - v0.2.0 https://github.com/Lodin/sassed It is updated to new DerelictSASS version and has some new features such as sass compile error and success handlers. Also segfault bug was fixed.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 14:05:25 UTC, Chris wrote: Yeah, I was wondering, if you have to import std.json and use it as a basis for painlessjson, is it really so big an improvement? Especially since std.json might be replaced (sooner or later). I'd prefer an easy to use implementation that replaces std.json completely. Painlessjson in many ways abstracts away the std.json implementation, so using it you should rarely/never have to use std.json directly. It basically abstracts away most of the complexity and you should only ever have to use toJSON and fromJSON. This works with built-in types (double/int/string etc.) and also with ranges and associative arrays. On top of that Painlessjson also makes it easy to convert your own types/struct/classes to and from JSON by (de)serializing them automatically (as far as possible). If a better simpler std.json gets developed then we can rebase painlessjson on that and it might become a thinner wrapper, but I would expect the (de)serialization still to be useful in many cases.
Re: DlangUI
On Thursday, 29 January 2015 at 14:13:22 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 14:21:36 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 13:37:34 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 10:57:57 UTC, Vadim Lopatin wrote: BTW, could you try on mac https://github.com/buggins/dlangide.git as well? It's dlangui-based D language IDE I'm currently working on. That works OK. The text is all horrible looking. This is probably due to (lack of) scaling support for high-res screens (retina). Is graphics scaled too? If so, it's due to scaling. Otherwise possible it's due to bad implementation of subpixel antialiasing (aka ClearType). I've submitted fix to disable subpixel antialiasing. An example of what I see (with up-to-date git HEAD) https://www.dropbox.com/s/49n9m0b9uutzaa8/Screenshot%202015-01-29%2014.11.57.png?dl=0 I see no additional blur comparing with other platforms. It's bad font rendering. Trying to improve. P.S: DlangIDE is now able to open DUB based projects, build and run them, edit files. Good sample project is dlangide/workspaces/tetris :)
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 13:16:48 UTC, BlackEdder wrote:
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source it
seems to have a different goal though. dson looks like it is an
alternative to std.json. Painlessjson is meant to make it
easier to use json, by automatically (de)serializing
objects/structs and converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of std.json
as a basis for Painlessjson.
I believe we should continue using std.json, and instead push for
taking dson (or its lessons learned) into phobos if it's a better
implementation. The best general solution should be the one that
is available out of the box.
Re: This Week in D, Issue 3
On Monday, 26 January 2015 at 05:15:51 UTC, Adam D. Ruppe wrote: I've been out of town this week and also dealing with trying to remotely find my lost dog (she got away from the sitter... and no luck yet :( ) so I haven't been as active as I often am in the D community, but I still made time to compile another issue! http://arsdnet.net/this-week-in-d/jan-25.html Also available via RSS: http://arsdnet.net/this-week-in-d/twid.rss This week's tip goes into the import statement which many people use but not everyone realizes what all it can do. D.announce seemed a bit less active this week too (my criteria for inclusion there is simply a new thread made since last time, so new posts in an existing thread don't count), but there were a lot of bug and pull request action this week (mostly related to the style tweaks)! Hi Adam, enjoy reading your articles but it was/is kind of difficult to find them. I browse dlang.org frequently but irregularly and Issue 3 popped accidentally into my eye. I could not find any obvious link to Issues 1 and 2 (searching the announce forum does not count as obvious) and had to guess the URLs based on weekly. I would suggest to collect the links to all Issues on the URL: http://arsdnet.net/this-week-in-d What do you think? Regards, ParticlePeter
Re: Interfacing D to existing C++ code
Walter how far did you get to integrate with the STL ? I started writing std::vector and std::string (linux gcc libstdc++) but maybe someone already made progress on this. It's harder than I thought and will probably require a lot of work to maintain all implementations.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source it
seems to have a different goal though. dson looks like it is an
alternative to std.json. Painlessjson is meant to make it easier
to use json, by automatically (de)serializing objects/structs and
converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of std.json
as a basis for Painlessjson.
Re: DlangUI
On Wednesday, 28 January 2015 at 14:21:36 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 13:37:34 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 10:57:57 UTC, Vadim Lopatin wrote: BTW, could you try on mac https://github.com/buggins/dlangide.git as well? It's dlangui-based D language IDE I'm currently working on. That works OK. The text is all horrible looking. This is probably due to (lack of) scaling support for high-res screens (retina). Is graphics scaled too? If so, it's due to scaling. Otherwise possible it's due to bad implementation of subpixel antialiasing (aka ClearType). I've submitted fix to disable subpixel antialiasing. An example of what I see (with up-to-date git HEAD) https://www.dropbox.com/s/49n9m0b9uutzaa8/Screenshot%202015-01-29%2014.11.57.png?dl=0
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 13:44:04 UTC, Pierre Krafft wrote:
On Thursday, 29 January 2015 at 13:16:48 UTC, BlackEdder wrote:
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source
it seems to have a different goal though. dson looks like it
is an alternative to std.json. Painlessjson is meant to make
it easier to use json, by automatically (de)serializing
objects/structs and converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of
std.json as a basis for Painlessjson.
I believe we should continue using std.json, and instead push
for taking dson (or its lessons learned) into phobos if it's a
better implementation. The best general solution should be the
one that is available out of the box.
Yeah, I was wondering, if you have to import std.json and use it
as a basis for painlessjson, is it really so big an improvement?
Especially since std.json might be replaced (sooner or later).
I'd prefer an easy to use implementation that replaces std.json
completely.
(I don't want to slight the work done on painlessjson and it
might come in handy here and there. Maybe it could be added to
the std.json module?)
Re: Interfacing D to existing C++ code
On 1/29/15 4:30 AM, Guillaume Chatelet wrote: Walter how far did you get to integrate with the STL ? I started writing std::vector and std::string (linux gcc libstdc++) but maybe someone already made progress on this. It's harder than I thought and will probably require a lot of work to maintain all implementations. Go for it, what we have only proof of concept for now. I know it's difficult, at a point I'll get on to it as well. Maintenance is parallelizable and I trust the community can take care of it. -- Andrei
Re: painlessjson released, looking for improvement advice
:) I use jsvar for any JSON work in D. Javascript is the only thing I've used that is possibly easier to work with JSON values. https://github.com/adamdruppe/arsd/blob/master/jsvar.d On Thu, Jan 29, 2015 at 5:18 PM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 29 January 2015 at 14:05:25 UTC, Chris wrote: Yeah, I was wondering, if you have to import std.json and use it as a basis for painlessjson, is it really so big an improvement? Especially since std.json might be replaced (sooner or later). I'd prefer an easy to use implementation that replaces std.json completely. Painlessjson in many ways abstracts away the std.json implementation, so using it you should rarely/never have to use std.json directly. It basically abstracts away most of the complexity and you should only ever have to use toJSON and fromJSON. This works with built-in types (double/int/string etc.) and also with ranges and associative arrays. On top of that Painlessjson also makes it easy to convert your own types/struct/classes to and from JSON by (de)serializing them automatically (as far as possible). If a better simpler std.json gets developed then we can rebase painlessjson on that and it might become a thinner wrapper, but I would expect the (de)serialization still to be useful in many cases.
Re: Interfacing D to existing C++ code
I pushed some code for string here (nothing fancy yet) https://github.com/gchatelet/dlang_cpp_std/blob/master/cpp_std.d The linker complains about missing std::basic_stringchar, std::char_traitschar, std::allocatorchar ::__ctor() where it should be std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string() So constructors and destructors are mangled 'a la D' instead of the C++ way.
Re: Calypso: Direct and full interfacing to C++
On Saturday, 24 January 2015 at 00:51:49 UTC, Elie Morisse wrote: Nevermind it's just that CodeGen is ambiguous with clang::CodeGen although my compiler doesn't complain. Fixed. Hi Elie. We are really excited about your project, as it really opens up new possibilities and will certainly save many months of time. I have struggled with building Calypso and tried various different recent release versions of clang to no avail. (LDC/LLVM/clang build without problem). I will post build errors shortly Would there be any chance you could fork a version of clang that works with Calypso, and then link to it in the instructions? Later it might also be worth using the D port of the dlang update.sh tool that I wrote so one can automate the process of downloading and building the various different pieces. So many moving parts that it is easy for something to break. Laeeth.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 18:47:37 UTC, Rory McGuire wrote: :) I use jsvar for any JSON work in D. Javascript is the only thing I've used that is possibly easier to work with JSON values. https://github.com/adamdruppe/arsd/blob/master/jsvar.d On Thu, Jan 29, 2015 at 5:18 PM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 29 January 2015 at 14:05:25 UTC, Chris wrote: Yeah, I was wondering, if you have to import std.json and use it as a basis for painlessjson, is it really so big an improvement? Especially since std.json might be replaced (sooner or later). I'd prefer an easy to use implementation that replaces std.json completely. Painlessjson in many ways abstracts away the std.json implementation, so using it you should rarely/never have to use std.json directly. It basically abstracts away most of the complexity and you should only ever have to use toJSON and fromJSON. This works with built-in types (double/int/string etc.) and also with ranges and associative arrays. On top of that Painlessjson also makes it easy to convert your own types/struct/classes to and from JSON by (de)serializing them automatically (as far as possible). If a better simpler std.json gets developed then we can rebase painlessjson on that and it might become a thinner wrapper, but I would expect the (de)serialization still to be useful in many cases. It's fun to see that there are so many different solutions to working with JSON in D. jsvar seems to be for keeping your variables in JavaScript-land, something I think is a bad idea in most cases. The idea of painlessjson is to convert to native D as fast as possible. The goal is to get something like https://github.com/FasterXML/jackson for D. We are still looking for input on how inheritance and constructors should work.
Re: Interfacing D to existing C++ code
On 1/29/2015 1:58 PM, Guillaume Chatelet wrote: I pushed some code for string here (nothing fancy yet) https://github.com/gchatelet/dlang_cpp_std/blob/master/cpp_std.d The linker complains about missing std::basic_stringchar, std::char_traitschar, std::allocatorchar ::__ctor() where it should be std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string() So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla.
Re: Calypso: Direct and full interfacing to C++
Hi Laeeth, Could you post the errors and which compiler you are using? If you managed to build both LDC and Clang you should be pretty close to get Calypso working. Would there be any chance you could fork a version of clang that works with Calypso, and then link to it in the instructions? As said in the README the 3.5 branch of LLVM/Clang should work, it's stable and there hasn't been a single commit since December 8: https://github.com/llvm-mirror/clang/commits/release_35
Re: DStep - Bindings Generator 0.0.1
Please, compile for Win32.
Re: Interfacing D to existing C++ code
Walter Bright wrote in message news:maed4o$2da6$1...@digitalmars.com... So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla. The problems with constructors go beyond mangling, so the current forced D mangling is intentional to prevent wrong-code bugs. An approach that currently works is porting the code to D, being careful to exactly match the layout and functionality. When done right, this allows templated types to be constructed with any type in either language and passed back and forth without problems. This is what I've done for dmd's ArrayT in ddmd.
Re: DStep - Bindings Generator 0.0.1
On 2015-01-30 03:32, data man wrote: Please, compile for Win32. This issue has been libclang. Might be easier now that DMD supports Win32 COFF. -- /Jacob Carlborg
