On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote:
> On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:
[...]
> >The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language.
> >
> 
> 
> Ahh std.xml, it's been that way for years.
> We NEED to get that replaced. Although don't hold your breath :/

What we *really* need, like almost everything else in D, is for somebody to get sufficiently provoked by the sorry state of the current std.xml to write something better and push it through the review process. Until then, further discussion is unlikely to make any difference.


T

-- 
Famous last words: I *think* this will work...

On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:
> On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote:
>> On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:
> [...]
>>> The Standard Library. I want to use D so I can do more with less
>>> hours writing code and less hours debugging code. Having a high
>>> quality standard library really helps this - unfortunately for me the
>>> first thing I needed from the standard library was xml parsing, which
>>> the documentation tells me is sub par and will be replaced in the
>>> near future, There is no indication of what I might like to use
>>> instead. Do I now use one of the other xml libraries floating around,
>>> bind a C based one or roll my own. All this eats into the efficiency
>>> that I am gaining by virtue of D being a really nice language.
>>>
>>
>>
>> Ahh std.xml, it's been that way for years.
>> We NEED to get that replaced. Although don't hold your breath :/
>
> What we *really* need, like almost everything else in D, is for somebody
> to get sufficiently provoked by the sorry state of the current std.xml
> to write something better and push it through the review process. Until
> then, further discussion is unlikely to make any difference.
>
>
> T
>

That's a given at this stage.
I've read the XML spec, its almost as bad as x86. Okay not quite but still. That's how far I got.

so is std.xml the exception? How many other parts of the standard library are like that?

On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:
>>
>> On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via Digitalmars-d wrote:
>>>
>>> On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:
>>
>> [...]
>>>>
>>>> The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language.
>>>>
>>>
>>>
>>> Ahh std.xml, it's been that way for years.
>>> We NEED to get that replaced. Although don't hold your breath :/
>>
>>
>> What we *really* need, like almost everything else in D, is for somebody to get sufficiently provoked by the sorry state of the current std.xml to write something better and push it through the review process. Until then, further discussion is unlikely to make any difference.
>>
>>
>> T
>>
>
> That's a given at this stage.
> I've read the XML spec, its almost as bad as x86. Okay not quite but still.
> That's how far I got.

On 31/05/2015 3:03 p.m., Danni Coy via Digitalmars-d wrote:
> so is std.xml the exception? How many other parts of the standard
> library are like that?
>
> On Sun, May 31, 2015 at 12:37 PM, Rikki Cattermole via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 31/05/2015 2:27 p.m., H. S. Teoh via Digitalmars-d wrote:
>>>
>>> On Sun, May 31, 2015 at 02:17:59PM +1200, Rikki Cattermole via
>>> Digitalmars-d wrote:
>>>>
>>>> On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:
>>>
>>> [...]
>>>>>
>>>>> The Standard Library. I want to use D so I can do more with less
>>>>> hours writing code and less hours debugging code. Having a high
>>>>> quality standard library really helps this - unfortunately for me the
>>>>> first thing I needed from the standard library was xml parsing, which
>>>>> the documentation tells me is sub par and will be replaced in the
>>>>> near future, There is no indication of what I might like to use
>>>>> instead. Do I now use one of the other xml libraries floating around,
>>>>> bind a C based one or roll my own. All this eats into the efficiency
>>>>> that I am gaining by virtue of D being a really nice language.
>>>>>
>>>>
>>>>
>>>> Ahh std.xml, it's been that way for years.
>>>> We NEED to get that replaced. Although don't hold your breath :/
>>>
>>>
>>> What we *really* need, like almost everything else in D, is for somebody
>>> to get sufficiently provoked by the sorry state of the current std.xml
>>> to write something better and push it through the review process. Until
>>> then, further discussion is unlikely to make any difference.
>>>
>>>
>>> T
>>>
>>
>> That's a given at this stage.
>> I've read the XML spec, its almost as bad as x86. Okay not quite but still.
>> That's how far I got.

std.json I believe and maybe one or two others. But std.xml is the one without a real clear alternative in the D ecosystem.

On 31 May 2015 at 13:03, Danni Coy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> so is std.xml the exception? How many other parts of the standard library are like that?

Lots. Check out std.json ;)

On Saturday, 30 May 2015 at 10:25:19 UTC, Jacob Carlborg wrote:
> For Swift interfacing with C++ you would need a C or Objective-C layer. With the Objective-C support in D (if it will ever be merged) you could have a more direct interface, but it would be limited to the Objective-C subset.

If D is as easier to integrate than Objective-C++ (which basically is C+14 with Objective-C tacked on) and with the same level of ARM support then that could be a real selling point. You would also need Android support though. (Since writing in C/C++ is a stepping stone to porting iOS apps to Android).

On 2015-05-31 08:01, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> If D is as easier to integrate than Objective-C++ (which basically is
> C+14 with Objective-C tacked on) and with the same level of ARM support
> then that could be a real selling point. You would also need Android
> support though. (Since writing in C/C++ is a stepping stone to porting
> iOS apps to Android).

I've been trying to write a plugin for TextMate in Swift. TextMate is written in C++ with the GUI code in Objective-C. It's quite difficult and currently it's probably 50% Objective-C++ code and 50% Swift. Not taking in to account the C++ declarations for the TextMate code I need to interface with.

That Swift doesn't support exceptions is annoying too, make it even more difficult.

-- 
/Jacob Carlborg

On 2015-05-31 01:37, Danni Coy via Digitalmars-d wrote:

> The Standard Library. I want to use D so I can do more with less hours
> writing code and less hours debugging code. Having a high quality
> standard library really helps this - unfortunately for me the first
> thing I needed from the standard library was xml parsing, which the
> documentation tells me is sub par and will be replaced in the near
> future, There is no indication of what I might like to use instead. Do
> I now use one of the other xml libraries floating around, bind a C
> based one or roll my own.

Use the one in Tango [1] [2]. It's really fast, at least back in the D1 days. Supports both DOM parser, SAX parser and a pull parser

[1] https://github.com/SiegeLord/Tango-D2
[2] http://siegelord.github.io/Tango-D2/ (search for XML)

-- 
/Jacob Carlborg

On Sunday, 31 May 2015 at 09:24:29 UTC, Jacob Carlborg wrote:
> I've been trying to write a plugin for TextMate in Swift. TextMate is written in C++ with the GUI code in Objective-C. It's quite difficult and currently it's probably 50% Objective-C++ code and 50% Swift. Not taking in to account the C++ declarations for the TextMate code I need to interface with.

Interesting, I haven't tried to interface with C++ from Swift yet. Sounds like you have gained some insights that could be valuable for Swift/D integration.

> That Swift doesn't support exceptions is annoying too, make it even more difficult.

Yes, if your C++ code base/libraries throws, that could be a problem.
But it should be ok if you write your own engine that don't use exceptions?

On Sunday, 31 May 2015 at 09:24:29 UTC, Jacob Carlborg wrote:
> I've been trying to write a plugin for TextMate in Swift. TextMate is written in C++ with the GUI code in Objective-C. It's quite difficult and currently it's probably 50% Objective-C++ code and 50% Swift. Not taking in to account the C++ declarations for the TextMate code I need to interface with.

I've read a little bit about FFI and Swift now. Since Swift can call C using the native Objective-C type aliases (Int32, Int64 etc) it seems that direction is not so problematic. The ideal would be for the D compiler to generate Swift stubs that wrap up D-calls as C-interfacing calls, with the necessary type conversions specified as UDAs?

Smaller functions could even be translated into pure Swift. You probably also could create some kind of standardized wrapper that catch exceptions and turn them into something that won't be too ugly on the Swift side.

Then you have the other direction, which probably is where your Objective-C work is most important. Where you kinda will need a Swift parser to generate D stubs, but in that direction you do at least not have to deal with exceptions.

Do the same for JNI et al, add ARM support and tune D for performant GC… then you have something that could become popular. But to get there takes a lot of focused effort…