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

> 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?

I was rather in the Swift code I would have like to use exceptions. It's easier to bail out by throwing an exception instead of a lot of nested if statements. It's possible to do some form of exception handling (and throwing) by wrapping try/catch/finally in a Objective-C method and call a block for each case, then use that from Swift.

-- 
/Jacob Carlborg

On Sun, May 31, 2015 at 7:28 PM, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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
>

Wouldn't this mean basically pulling all of Tango into my project and then having two copies of practically everything? That might be a practical solution but you can see why that doesn't feel like a good solution and still gives friction.

"Joakim" <dlang@joakim.fea.st> writes:

> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>> I often wonder if others share the importance of mobile cross-compilers?
>
> I wonder that sometimes too, considering it's only two people working on them.
>
>> They seem to be getting lots of love recently, which is very
>> exciting!
>> I'd like to encourage those working on the Android/iOS toolchains to
>> publish regular binary builds of the toolchains so we with little
>> allocated working time can grab the latest toolchains and try our
>> stuff from time to time.
>
> I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds. However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki:
>
> http://wiki.dlang.org/Build_DMD_for_Android

And for iOS - https://github.com/smolt/ldc-iphone-dev

I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far.  It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction.

Would putting up a binary build help?  I can do that.

In meantime I have been getting ready for upcoming LDC 0.16.0 with dmd frontend 2.067.  Also coming soon is support of iOS sim in addition to existing arm support.  Latest Xcode 6.3.1 apparently fixed something because now D dwarf debug kind of works.  Xcode crashes sometimes while navigating the stack, but way better than thumb instruction level debugging.

On 2015-06-01 01:04, Danni Coy via Digitalmars-d wrote:

> Wouldn't this mean basically pulling all of Tango into my project and
> then having two copies of practically everything?

Not exactly sure what you mean. The linker will only pull in the symbols you're actually using. A module in Tango, compared with Phobos, doesn't depend on the rest of the library. There are less inter-dependencies in the library.

I just had a quick look. The DOM parser depends only on the pull parser. The pull parser depends on two functions and one exception. Should be trivial to replace those with the corresponding functions in Phobos if you only want to extract the XML parsing.

> That might be a practical solution but you can see why that doesn't feel like a good
> solution and still gives friction.

I kind of understand that, but on the other hand, if it gets the job done what's the problem.

-- 
/Jacob Carlborg

On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Joakim" <dlang@joakim.fea.st> writes:
>
>> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>>> I often wonder if others share the importance of mobile cross-compilers?
>>
>> I wonder that sometimes too, considering it's only two people working on them.
>>
>>> They seem to be getting lots of love recently, which is very
>>> exciting!
>>> I'd like to encourage those working on the Android/iOS toolchains to
>>> publish regular binary builds of the toolchains so we with little
>>> allocated working time can grab the latest toolchains and try our
>>> stuff from time to time.
>>
>> I can't speak for Dan, who's been getting iOS working, but I just got Android/ARM running a week ago, so it's too early to put out builds. However, it wouldn't take much time to try out the Android/x86 support from source, since the build process is documented on the wiki:
>>
>> http://wiki.dlang.org/Build_DMD_for_Android
>
> And for iOS - https://github.com/smolt/ldc-iphone-dev
>
> I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far.  It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction.
>
> Would putting up a binary build help?  I can do that.

Yes. I basically won't look at anything without a binary build.
Call me whatever you like; I am a completely typical Windows developer
in this way. If there is no binary, the thought that I should build it
myself doesn't cross my mind ;)

It would be nice if it were easy to find; present among the other LDC downloads? Possible to work iOS toolchain build into the existing LDC CI solution?

I think all these missing cross-compilers need to find themselves into
regular build cycles, and maintained alongside the existing releases.
Much easier to take them seriously in that context, and gives better
visibility; it feels like these efforts are somewhat fragmented until
recently.
Having toolchain alpha-releases available, even without libraries in
working order, makes the bar much lower for people to get in and start
hacking on the libraries.

"Chris" <wendlec@tcd.ie> writes:
> 2. [high priority]
> Uncertainty regarding ARM (iOS/Android). Deal breaker, show
> stopper. Was worrying a few years ago, but is just bad now in 2015.
>

It is a little better now :-)

Maybe you can help Chris.  I don't develop for mobile so I don't know that dev environment and what is needed for D to be useful in that world.  So far for iOS we have armv7 support, all of phobos except libcurl.  What isn't there yet is iOS sim support (coming soon), arm64 support, and nice Xcode integration.

I though it might help if I added a demo app based on Allegro 5.

https://github.com/smolt/ldc-iphone-dev

There is a list of TODOs at the bottom of the project readme.  Want to add anything?  Also, issues can be filed, pull requests.
-- 
Dan

I'll add in my story.

My job is working as part of a team on a small-to-medium scale web application. Our application layer is implemented in Python and Django. This would be the place where D would fit in the most. So I think this comes down to an argument of why we would choose to use Python and Django instead of D and vibe.d. I can think of the following reasons.

1. Obviously, we have already written everything in Python, so we would have to justify the cost of moving to D quite strongly.
2. Django offers more features useful for developing a web application than vibe.d, like an excellent API for building SQL queries with an ORM. The South or first party migrations (ALTER TABLE, etc.) APIs in 1.7 are brilliant, and after you use them, you can't live without them. These APIs work well and save time.
3. Python has greater mind share, so switching to D would incur the cost of training everyone to use D. It's hard enough finding a decent Python programmer.
4. The third party libraries implement many things we need to use, like SSO support.
5. We use Celery a lot for task management, so to use D we would need similar software D could work with.
6. I must mention that the execution model makes the sites easier to develop. When you change a function and save the file, Django reloads the module, (when it doesn't break) so you can test the effects of your modification instantly.


I can't compare on testing web pages in Django against vibe.d, as I've never tried it on vibe.d. I will add that Django allows you to send fake HTTP requests to your 'views' for web pages, so you can write automated tests for the pages on your site. This level of testing does wonders for code quality, and catches website regressions quickly.

I hope that in the future some clever person could implement an API for generating SQL queries in an RDBMS indepent way for D, with support for creating ALTER TABLE statements automatically. I've thought about it, and it wouldn't even necessarily need to be ORM, as something like the "data mapper" pattern could work. Just something which lets you build queries for objects you can serialise, and generate queries needed to update the tables for the objects when you change them.

Manu via Digitalmars-d <digitalmars-d@puremagic.com> writes:
> On 1 June 2015 at 16:50, Dan Olson via Digitalmars-d
>> And for iOS - https://github.com/smolt/ldc-iphone-dev
>>
>> I was hoping others would try out this ldc for iOS and give feedback, suggest where to focus next, but nothing so far.  It does pretty well if all you need is to compile D code but don't need Objective-C interop or nice Xcode interaction.
>>
>> Would putting up a binary build help?  I can do that.
>
> Yes. I basically won't look at anything without a binary build.
> Call me whatever you like; I am a completely typical Windows developer
> in this way. If there is no binary, the thought that I should build it
> myself doesn't cross my mind ;)

In this case you'd have to be an OS X developer, as the binaries will be for a Mac.

> It would be nice if it were easy to find; present among the other LDC downloads?

When ready, I will add a link to the iOS section of http://wiki.dlang.org/LDC

> Possible to work iOS toolchain build into the existing LDC CI solution?
>
> I think all these missing cross-compilers need to find themselves into
> regular build cycles, and maintained alongside the existing releases.
> Much easier to take them seriously in that context, and gives better
> visibility; it feels like these efforts are somewhat fragmented until
> recently.
> Having toolchain alpha-releases available, even without libraries in
> working order, makes the bar much lower for people to get in and start
> hacking on the libraries.

Yeah, we need to work on getting iOS support into LDC main offering. For now there is a stumbling block (at least perceived by me) of requiring a patched LLVM to support TLS on iOS.

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I expect I'm not alone. Please share the absolute blockers preventing
> you from adopting D in your offices. I wonder if there will be common
> themes emerge?

In general, I'd say that the problems are mostly cultural or political. Even if D can do everything that we need, there's no way that we're moving a large existing codebase to it (the code is flaky enough as it is), and even if writing new pieces in D would technically work well, it would be adding yet another language to the mix for folks to learn. And most of the folks that I've worked with really don't care about learning new languages, or if they do, just plain getting the work done with what they currently have is already a big enough concern that they're not going to be in hurry to learn a new one. I'm more likely to get labeled as eccentric than to get folks to actually want to use D at work if I pushed it. I get labeled that way enough just from talking about it. And considering that we haven't even found the time yet to switch our codebase to 64-bit, I don't think that doing much with D is really on the table at this point.

The only technical barriers that I can think of at the moment that I might run into if I were to actually switch would relate to C/C++ interoperability and shared libraries, and AFAIK, those are currently good enough.

- Jonathan M Davis

On 2015-06-01 18:38, Dan Olson wrote:

> Yeah, we need to work on getting iOS support into LDC main offering. For
> now there is a stumbling block (at least perceived by me) of requiring a
> patched LLVM to support TLS on iOS.

How you tried contributing that back to LLVM? And in that case, what's the status?

-- 
/Jacob Carlborg