View mode: basic / threaded / horizontal-split · Log in · Help
July 22, 2012
Re: OSCON 2012 notes
Am 22.07.2012 14:19, schrieb Michel Fortin:
> On 2012-07-21 19:51:37 +0000, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> said:
>
>> On Sat, 21 Jul 2012 09:47:06 -0400
>> Michel Fortin <michel.fortin@michelf.ca> wrote:
>>>
>>> And also, more and more it'd require ARM support to be competitive in
>>> the GUI area.
>>
>> Yes. But there's an even bigger reason for ARM: Mobile devices, like
>> iOS and Android. I'm not personally a fan of them, but nonetheless those
>> things are HUGE (no pun intended). And yet the ONLY real language
>> choices there are C++, Java and Objective-C (and Lua if you count
>> "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are
>> out of the question if you want cross platform, which any sane developer
>> should. So PERFECT fertile ground for D.
>>
>> I know I keep harping on that, but it's a big issue for me since I'm
>> deep into that stuff now and goddamn do I wish I could be doing
>> it in D, but D's support on those devices (or just outputting C/C++)
>> unfortunately just isn't mature enough ATM.
>
> For my part, in the last year I've been building a big codebase that had
> to be C++ just because of this, with countless hours spent figuring out
> things that would have been a lot easier to do in D.
>
> Here's the problem as I came to realize it: no single project is going
> to be enough to justify the investment required to make it happen.
> Nobody's project is by itself big enough to make D/Objective-C
> worthwhile to produce and maintain, because making it and then keeping
> it in sync with both D and Apple's Objective-C is a huge effort that'll
> in itself derail the project you were using to justify the investment.
> So D/Objective-C has to stand as a project of its own somehow.
>
> Also, making it a cross-platform thing would require a similar
> investment for WinRT and Android (through JNI?). While it surely is
> technically possible and would sure help a lot of developers move away
> from C++, I'm not so sure such a thing will happen at all.
>

Those are the reasons why, even though I follow a few new programming 
languages with interest, in the end I keep on coding in JVM/.NET/C++.

Unfortunely my time is limited and I have to use what works out of the box.

--
Paulo
July 22, 2012
Re: OSCON 2012 notes
Just curious, do you know if Alexander Stepanov uses D or not?
July 22, 2012
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 18:14:23 +0200
Paulo Pinto <pjmlp@progtools.org> wrote:
> 	y := &x[0]
> 	fmt.Println("Base adress ", y)
> 	size := unsafe.Sizeof(x[0])
> 	fmt.Println("Size per element ", size)
> 	for i := 0; i < len(x); i++ {
> 		cell := uint64(uintptr(unsafe.Pointer(y))) +
> (uint64(i) * uint64(size)) value :=
> (*byte)(unsafe.Pointer(uintptr(cell))) fmt.Printf("%d index is %d, at
> %p\n", i, *value, value) }
> }
> 

Eeew!! That's awful.
July 22, 2012
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 08:19:12 -0400
Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2012-07-21 19:51:37 +0000, Nick Sabalausky 
> <SeeWebsiteToContactMe@semitwist.com> said:
> 
> > On Sat, 21 Jul 2012 09:47:06 -0400
> > Michel Fortin <michel.fortin@michelf.ca> wrote:
> >> 
> >> And also, more and more it'd require ARM support to be competitive
> >> in the GUI area.
> > 
> > Yes. But there's an even bigger reason for ARM: Mobile devices, like
> > iOS and Android. I'm not personally a fan of them, but nonetheless
> > those things are HUGE (no pun intended). And yet the ONLY real
> > language choices there are C++, Java and Objective-C (and Lua if
> > you count "Son-of-Flash", ie Corona - which I don't count). And
> > half of THOSE are out of the question if you want cross platform,
> > which any sane developer should. So PERFECT fertile ground for D.
> > 
> > I know I keep harping on that, but it's a big issue for me since I'm
> > deep into that stuff now and goddamn do I wish I could be doing
> > it in D, but D's support on those devices (or just outputting C/C++)
> > unfortunately just isn't mature enough ATM.
> 
> For my part, in the last year I've been building a big codebase that 
> had to be C++ just because of this, with countless hours spent
> figuring out things that would have been a lot easier to do in D.
> 
> Here's the problem as I came to realize it: no single project is
> going to be enough to justify the investment required to make it
> happen. Nobody's project is by itself big enough to make
> D/Objective-C worthwhile to produce and maintain, because making it
> and then keeping it in sync with both D and Apple's Objective-C is a
> huge effort that'll in itself derail the project you were using to
> justify the investment. So D/Objective-C has to stand as a project of
> its own somehow.
> 
> Also, making it a cross-platform thing would require a similar 
> investment for WinRT and Android (through JNI?). While it surely is 
> technically possible and would sure help a lot of developers move
> away from C++, I'm not so sure such a thing will happen at all.
> 

FWIW, Marmalade ( www.madewithmarmalade.com ) has already done the
legwork to allow crossplatform natively-compiled C++ code that works on
iOS, Android and a bunch of other less "hip" stuff like Bada, WebOS,
Symbian, and some version of mobile windows (6, IIRC). I'm sure
they'll be doing WinRT at some point if not already working on it. They
do abstract away the underlying OS calls (including usage of
Objective-C), although they also provide a (somewhat roundabout) way to
access them directly if you need. Unfortunately, it's not open-source
and it's somewhat pricey, but point is, C++ across all those platforms
does at least exist.

Also, on the Android, you don't need to deal with the JVM (or whatever
Google's version of it is called). Apparently that used to
be the case, but now you can just use straight C++, even without third
party tools like Marmalade. There's a lot of about Google and Android I
don't like, but as usual: At least it's not *quite* as shitty as dealing
with Apple's inevitably putrid offering.
July 22, 2012
Re: OSCON 2012 notes
Am 22.07.2012 20:46, schrieb Nick Sabalausky:
> On Sun, 22 Jul 2012 18:14:23 +0200
> Paulo Pinto<pjmlp@progtools.org>  wrote:
>> 	y :=&x[0]
>> 	fmt.Println("Base adress ", y)
>> 	size := unsafe.Sizeof(x[0])
>> 	fmt.Println("Size per element ", size)
>> 	for i := 0; i<  len(x); i++ {
>> 		cell := uint64(uintptr(unsafe.Pointer(y))) +
>> (uint64(i) * uint64(size)) value :=
>> (*byte)(unsafe.Pointer(uintptr(cell))) fmt.Printf("%d index is %d, at
>> %p\n", i, *value, value) }
>> }
>>
>
> Eeew!! That's awful.
>

Pointer arithmetic as endless source for security exploits is to be used
*only* when no other solution exists.

But yes, the way to do it could be simpler.
July 22, 2012
Re: OSCON 2012 notes
On 2012-07-22 19:05:45 +0000, Nick Sabalausky 
<SeeWebsiteToContactMe@semitwist.com> said:

> On Sun, 22 Jul 2012 08:19:12 -0400
> Michel Fortin <michel.fortin@michelf.ca> wrote:
> 
>> On 2012-07-21 19:51:37 +0000, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> said:
>> 
>>> On Sat, 21 Jul 2012 09:47:06 -0400
>>> Michel Fortin <michel.fortin@michelf.ca> wrote:
>>>> 
>>>> And also, more and more it'd require ARM support to be competitive
>>>> in the GUI area.
>>> 
>>> Yes. But there's an even bigger reason for ARM: Mobile devices, like
>>> iOS and Android. I'm not personally a fan of them, but nonetheless
>>> those things are HUGE (no pun intended). And yet the ONLY real
>>> language choices there are C++, Java and Objective-C (and Lua if
>>> you count "Son-of-Flash", ie Corona - which I don't count). And
>>> half of THOSE are out of the question if you want cross platform,
>>> which any sane developer should. So PERFECT fertile ground for D.
>>> 
>>> I know I keep harping on that, but it's a big issue for me since I'm
>>> deep into that stuff now and goddamn do I wish I could be doing
>>> it in D, but D's support on those devices (or just outputting C/C++)
>>> unfortunately just isn't mature enough ATM.
>> 
>> For my part, in the last year I've been building a big codebase that
>> had to be C++ just because of this, with countless hours spent
>> figuring out things that would have been a lot easier to do in D.
>> 
>> Here's the problem as I came to realize it: no single project is
>> going to be enough to justify the investment required to make it
>> happen. Nobody's project is by itself big enough to make
>> D/Objective-C worthwhile to produce and maintain, because making it
>> and then keeping it in sync with both D and Apple's Objective-C is a
>> huge effort that'll in itself derail the project you were using to
>> justify the investment. So D/Objective-C has to stand as a project of
>> its own somehow.
>> 
>> Also, making it a cross-platform thing would require a similar
>> investment for WinRT and Android (through JNI?). While it surely is
>> technically possible and would sure help a lot of developers move
>> away from C++, I'm not so sure such a thing will happen at all.
>> 
> 
> FWIW, Marmalade ( www.madewithmarmalade.com ) has already done the
> legwork to allow crossplatform natively-compiled C++ code that works on
> iOS, Android and a bunch of other less "hip" stuff like Bada, WebOS,
> Symbian, and some version of mobile windows (6, IIRC). I'm sure
> they'll be doing WinRT at some point if not already working on it. They
> do abstract away the underlying OS calls (including usage of
> Objective-C), although they also provide a (somewhat roundabout) way to
> access them directly if you need. Unfortunately, it's not open-source
> and it's somewhat pricey, but point is, C++ across all those platforms
> does at least exist.

Marmalade, from what I see, is some sort of meta-platform you can use 
to write something that works everywhere. It adds a new layer of 
abstraction that can work on top of each platform. Good for them and 
their developers, but I generally try to avoid unnecessary layers like 
this. It often makes things harder to debug and fix, and will always 
lag behind the functionalities each of platform has to offer.

No, the idea is to make the D *language* work with each platform's 
object model. Just like D can call and define C functions with zero 
overhead, it should be capable of defining classes from other languages 
too and overriding their functions with zero overhead. That way you can 
talk directly with each platform's API with no middle man playing a 
complicated translation/abstraction process in the middle.


> Also, on the Android, you don't need to deal with the JVM (or whatever
> Google's version of it is called). Apparently that used to
> be the case, but now you can just use straight C++, even without third
> party tools like Marmalade.

But all the interface widgets are still in Java, no? If you're working 
on an OpenGL/ES game maybe you won,t need them, but if you're building 
any other kind of app, you'll have to play with JNI a lot. Or add 
Marmalade as an abstraction layer. Either way it's suboptimal compared 
to using directly the APIs you need.


> There's a lot of about Google and Android I
> don't like, but as usual: At least it's not *quite* as shitty as dealing
> with Apple's inevitably putrid offering.

With Apple's platform, integrating a C++ backend with an Objective-C 
frontend is quite a breeze: both object models mix very well together. 
It's pretty much the same thing as Microsoft did with WinRT: regular 
C++ classes mix with WinRT classes in the same source file pretty much 
in the same way. Try do that with Android's UI classes written in Java. 
But maybe I misunderstood what you're referring to.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/
July 23, 2012
Re: OSCON 2012 notes
On Sun, 22 Jul 2012 17:58:20 -0400
Michel Fortin <michel.fortin@michelf.ca> wrote:
> 
> Marmalade, from what I see, is some sort of meta-platform you can use 
> to write something that works everywhere. It adds a new layer of 
> abstraction that can work on top of each platform. Good for them and 
> their developers, but I generally try to avoid unnecessary layers
> like this. It often makes things harder to debug and fix, and will
> always lag behind the functionalities each of platform has to offer.
> 
> No, the idea is to make the D *language* work with each platform's 
> object model. Just like D can call and define C functions with zero 
> overhead, it should be capable of defining classes from other
> languages too and overriding their functions with zero overhead. That
> way you can talk directly with each platform's API with no middle man
> playing a complicated translation/abstraction process in the middle.
> 

Yea, I agree that's worth having. Just thought it was worth mentioning.

> 
> > Also, on the Android, you don't need to deal with the JVM (or
> > whatever Google's version of it is called). Apparently that used to
> > be the case, but now you can just use straight C++, even without
> > third party tools like Marmalade.
> 
> But all the interface widgets are still in Java, no? If you're
> working on an OpenGL/ES game maybe you won,t need them, but if you're
> building any other kind of app, you'll have to play with JNI a lot.
> Or add Marmalade as an abstraction layer. Either way it's suboptimal
> compared to using directly the APIs you need.
> 
[...]
> Try do that with Android's UI
> classes written in Java. But maybe I misunderstood what you're
> referring to.
> 

I wouldn't know. I haven't actually dealt with the android SDK
directly, only Marm. When I saw google saying you use either Java or
straight natively-compiled C++, I guess I assumed that meant an actual
C++ API.

Personally I like abstraction layers for GUI: it means you don't have to
deal with twenty different system-specific (and idiosyncratic) APIs.
For example, I hope I never have to touch Win32 directly again.
July 23, 2012
Re: OSCON 2012 notes
>"Nick Sabalausky"  wrote in message news:20120723010439.00006efc@unknown...
>I wouldn't know. I haven't actually dealt with the android SDK
>directly, only Marm. When I saw google saying you use either Java or
>straight natively-compiled C++, I guess I assumed that meant an actual
>C++ API.

No, actually you are still dealing with JNI. Google's position on native 
code, is that
you should use it just for code hotspots, gamming or to port "legacy" code.

[quote]In general, you should only use the NDK if it is essential to your 
app—
never because you simply prefer to program in C/C++.[/quote]

http://developer.android.com/tools/sdk/ndk/index.html

The native activity is actually a Java Activity with a specific set of 
methods defined
as native methods.

http://developer.android.com/reference/android/app/NativeActivity.html

You are only allowed to access these libraries:

- libc (C library) headers
- libm (math library) headers
- JNI interface headers
- libz (Zlib compression) headers
- liblog (Android logging) header
- OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
- libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
- A Minimal set of headers for C++ support
- OpenSL ES native audio libraries
- Android native application APIS

The Android native applications APIs are C wrappers around JNI calls, 
meaning you get a performance
hit when calling them due to marshling. This is described in the 
STABLE-APIS.html document delivered
as part of the NDK.

[quote]Starting from API level 9, it is possible to entirely write an 
Android
application with native code (i.e. without any Java). That does not mean
that your code does not run inside a VM though, and most of the features
of the platform will still need to be accessed through JNI.[/quote]

Java is the main language to develop standard applications on Android, 
everything else are just
workarounds, even if we don't like it.

Another example are the new low level Codec APIs in Jelly Bean, which are 
only  exposed directly via JNI to
Java.

http://developer.android.com/reference/android/media/MediaCodec.html

--
Paulo
July 23, 2012
Re: OSCON 2012 notes
On 2012-07-21 21:59, Alex Rønne Petersen wrote:
> On 21-07-2012 21:51, Nick Sabalausky wrote:

>> Yes. But there's an even bigger reason for ARM: Mobile devices, like
>> iOS and Android. I'm not personally a fan of them, but nonetheless those
>> things are HUGE (no pun intended). And yet the ONLY real language
>> choices there are C++, Java and Objective-C (and Lua if you count
>> "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are
>> out of the question if you want cross platform, which any sane developer
>> should. So PERFECT fertile ground for D.
>
> ... and C# ;)

... and Ruby :)

-- 
/Jacob Carlborg
July 23, 2012
Re: OSCON 2012 notes
On 2012-07-23 08:59, Paulo Pinto wrote:

> No, actually you are still dealing with JNI. Google's position on native
> code, is that
> you should use it just for code hotspots, gamming or to port "legacy" code.
>

> The Android native applications APIs are C wrappers around JNI calls,
> meaning you get a performance
> hit when calling them due to marshling. This is described in the
> STABLE-APIS.html document delivered
> as part of the NDK.
>
> [quote]Starting from API level 9, it is possible to entirely write an
> Android
> application with native code (i.e. without any Java). That does not mean
> that your code does not run inside a VM though, and most of the features
> of the platform will still need to be accessed through JNI.[/quote]

That is just so wrong.

-- 
/Jacob Carlborg
1 2 3 4 5
Top | Discussion index | About this forum | D home