On Thursday, 3 October 2019 at 17:50:09 UTC, mipri wrote:
> views"? What part of that didn't you think wouldn't lead to more
> posts about the thing you're wanting to go away?

I really don't care and it isn't about you, I was pointing out a community symptom.

The reality is that there have been enough people in the D community in the past 10 years that had the skillset and the knowhow to move D forward in most difficult theoretical areas. But they don't stick around. And getting those things right does take hard work.

On Thursday, 3 October 2019 at 09:36:17 UTC, LocoDelPueblo wrote:
>
> Problem is also that people using python don't want to be programmers... they just do stuff in python, and sometimes these stuff become mainstream. So if the idea is to say "use Nim instead of python" you basically kill the "why" the python stuff started being widely used and developed. You fallback in the "no-way" again.
>
> I've observed this again two days ago where the UI of for a command line app required python-qt. The application could have been made in cpp, easily, but you know the authors just wanted to make their stuff...but now this ui is available on most linux distribs, no matter the way it's made.

Actually, I had some time to play around with Nim and it really "feels" like Python. I was thinking if they had an automatic Python to Nim converter (like Kotlin has a Java to Kotlin converter), it'd be much easier to make the transition. It'd be great to be able to do something like this: `nim pyToNim file.py file.nim`.

On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
> How will it work once it's finished?

That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library.

Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left.

The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.

> Are there any plans for auto generated bridges, e.g. JNI calling rt_init() or something?

I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.

On Thursday, 3 October 2019 at 18:09:06 UTC, Chris wrote:
> You do realize that it was you who hijacked this thread about
> Nim and tried to turn it into a flamewar with ad hominems
> galore.

No, I don't realize that. I very kindly wrote my exact interpretation
of what happened here in the timeline that you quoted, in the reply
that you're replying to. You offered some remarks about D in this
thread about Nim and I asked about them. Suppose you'd just answered
the question?  Suppose you'd even just said "eh I can't be arsed,
just search the forum." All of my replies, past the first one, have
been to your insults.

Do you not wonder if you might be hijacking the thread with your own
insults? Please, wonder a little bit about it.

> Also, if you find Ola's reply "offensive", seriously,

What do you mean 'if'? I wasn't subtle about why I found it
offensive.  I emphasized that though as it seems to have not even
occurred to him that I might've gotten annoyed with you for any
reason other than "you are still not sugarcoating your views as I'd
wanted". That's all.

> Again, I wish you good luck.

Twice while preparing this reply it was clear to me that you'd just
not bothered to read what I'd said earlier, or to take it seriously.
Over the course of a very short conversation, that's three strikes. I
probably won't remember not to waste further words on you, so if you
mean any kindness with these wishes, please keep the luck and just
read my actual words next time.

On Thu, Oct 03, 2019 at 06:27:46PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]
> That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library.

BTW, I do have an android project that involves a combination of D code and Java code.  It's cross-compiled from PC to the Android platform. Although it's not your typical Android project (I eschewed Android Studio in favor of my own SCons-based build script, mainly because I need to compile helper D programs that in turn generate D code for certain repetitive modules, but also because I can't be bothered with a resource-intensive IDE when a text editor works just as well), I'll be happy to provide details on the steps that worked for me.

Basically, an APK can include Java bytecode, resources (XML, media, etc.), and, most importantly, a lib/ subdirectory for precompiled .so files. I took the route of using Java to interface with Android OS: there's a C API available that I *could* use if I wanted to, but I didn't want to have to reinvent the Java GUI bindings already available to Java code, so I just have the Java code declare native methods that are implemented by the .so (containing D code) via JNI.

Compilation essentially amounts to running ldc on the D code to produce a .so that the build system inserts into the correct location in the APK, and the usual Java compilation and assembly into classes.dex, as required by Android, along with packing up the standard APK resources. Then run the tools in the Android SDK/NDK to process the APK, sign it, and what-not, then it's ready to be uploaded to your device for installation.


> Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left.

Yes, my project got off the ground only because of the work Joakim did to make transcompilation to Android possible with LDC. There are some pretty specific details that you have to get right, otherwise your APK won't work.


[...]
> > Are there any plans for auto generated bridges, e.g. JNI calling
> > rt_init() or something?
> 
> I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.

That would be VERY nice. Currently, in my code, I have to take extra care to call rt_init() and rt_cleanup() at the right junctures -- and this stuff is pretty delicate; get it wrong and it will crash at runtime, usually with no useful indication of what went wrong (you just get the "sorry, application crashed" message).

I also have the beginnings of a JNI boilerplate auto-generator in my project, basically a template function that lets D code invoke a named Java method on a JNI-wrapped Java object. If you like, I can send you a copy for reference.  Though keep in mind it's *very* crude, and I wrote just enough for my own needs, so it will need more work to be suitable for general consumption.  But at the very least, it lets me call Java methods like this:

	// Equivalent to Java:
	//	int ret = classObj.myMethod(123, "abc", 1.0);
	int ret = callJavaMethod!(int, "myMethod")(jniHandle, classObj,
		123, "abc", 1.0);

which, if you were to write it manually in terms of JNI calls, would be like a 25-50 line function in itself. (JNI is *very* boilerplate-y.)

In theory, this could be expanded upon by wrapping Java class objects received over JNI in a JavaObject wrapper that contains an implicit JNI handle, so that you could actually write the above as:

	int ret = classObjWrapper.myMethod(123, "abc", 1.0);

This can probably be done with good ole opDispatch.  But so far, I haven't found the need for it yet, since my focus is mainly on the D code, and calling Java methods from D isn't really a priority except for some unavoidable calls to interact with the Android GUI API.

One gotcha to watch out for, if you ever decide to go that route, is that the JNI handle handed to the D code by JNI is NOT guaranteed to be valid across different JNI calls; so if you do wrap your class objects like above, you have to be careful that you don't reuse stale JNI handles you obtained from previous JNI calls. Otherwise you may get random unexplained crashes at runtime. This is one of the reasons I haven't bothered to write such a wrapper just yet -- it's too much trouble to write code to handle the JNI handle correctly at the moment.

Another challenge is that you can't deduce the Java return type of a method at D compile-time -- this is why callJavaMethod above requires a compile-time argument to specify the return type -- so you may have to resort to some heavy hackery if you want to be able to just assign the return value to a target variable without needing the user to explicitly specify the type.  One approach that comes to mind is a tool that parses Java source code and emits equivalent D declarations that are then introspected by the Java class wrapper to obtain the correct method signatures. But again, a lot of work for something that I don't presently feel an urgent need for right now.

(And, to dream on, in the future we could potentially have built-in Java support in D, in a similar style that we interface with C/C++ today: declare Java classes/methods using D equivalents, and have the compiler or a library auto-generate the JNI code for it.  Or potentially just ditch JNI and use JNA instead, which is far less boilerplate-y. But as far as Android is concerned, JNA may not be available yet, so for the near future JNI seems to the way to go.)


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On Thu, 2019-10-03 at 12:13 +0000, Ola Fosheim Grøstad via Digitalmars-d
wrote:
[…]
> 
> IMO a package manager is only needed for scripty throw-away programming. I sincerely doubt it has a big effect on serious application development.

It seems that Python, Ruby, Rust, Go, and D disagree with this position, all being based on source code packages. Indeed C++ is catching up and doing something very package like.

> If you build something with a long horizon you don't need a package manager. The time it takes to download and build libraries from github is negligible compared to the overall development time. Besides, if you build something big you also ought to understand the code you are using and the build process, even if it is a library. You have to be able to maintain the library in case it is abandoned...

I think Cargo, Go, and Dub prove this to be wrong.

If you end up using a library that was third-party maintained but gets abandoned, do not take the time to take over maintenance, change to another library. There is generally a very good reason the library got abandoned, and there are invariably very good newer replacements.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 3 October 2019 at 19:33:37 UTC, H. S. Teoh wrote:
> BTW, I do have an android project that involves a combination of D code and Java code.

ooo i'll take any help i can get. email me later.

On Thursday, 3 October 2019 at 19:54:32 UTC, Russel Winder wrote:
> It seems that Python, Ruby, Rust, Go, and D disagree with this position, all being based on source code packages.

Python have enough libraries that have been maintained for a long time to be reliable, also the language is stable, does not change much and the environment is essentially a VM. So, even if it is not maintained, you can basically keep using it.

Sure Go has many packages, but very few I would dare to rely on. The language is still changing, and I also don't want to use libraries on a server from a source I cannot trust.

There are so many unmaintained libraries for these new languages that it doesn't look good for people who want to write software that has to be maintained for 15+ years.


> Indeed C++  is catching up and doing something very package like.

Maybe, but if the libraries you use have strong ties to the OS/CPU architecture, then it has to be maintained at a higher frequency (which is more typical for low level programming than high level).

What I believe is typical for C++ is to either include C-libraries that have a long track record of reliability, or depend on a small number of solid (commercial grade) C++frameworks, or use very small header libraries (preferably libraries that can be imported as independent single file headers).

You really need to be careful with what you pull in when programming in C++ both in terms of being able to debug and build times.


> If you end up using a library that was third-party maintained but gets abandoned, do not take the time to take over maintenance, change to another library. There is generally a very good reason the library got abandoned, and there are invariably very good newer replacements.

That's not really possible in a larger project that has been deployed. That would incur large costs. Besides there might not be another PDF-generating library for you to use, or sound synthesis package that is anywhere near compatible. Even in Python, if I cannot use the PDF library I am using now, I would most likely set up an additional Java service rather than trying to pull in another PDF library written in Python.

Besides, in reality you often end up maintaining your own fork anyway, since you usually have to make modifications to the library over time if it is doing something significant and special that you cannot roll on your own.

Another reason to not use packages in larger projects is that it makes no sense to import an entire package when you only want one function. Increased build times, harder to read the codebase, and so on.

What I find repulsive about the node.js world that use packages at crazy levels of pervasiveness is the security aspect of it.

On Thu, Oct 03, 2019 at 08:50:53PM +0000, Ola Fosheim Grøstad via Digitalmars-d wrote:
> On Thursday, 3 October 2019 at 19:54:32 UTC, Russel Winder wrote:
[...]
> > If you end up using a library that was third-party maintained but gets abandoned, do not take the time to take over maintenance, change to another library. There is generally a very good reason the library got abandoned, and there are invariably very good newer replacements.

That sounds good in theory, but in practice it will usually involve changing to a different API, and translating the old code to the new API (or writing a proxy wrapper) may be non-trivial (if even possible -- some may involve changing the entire operational paradigm that makes it infeasible to rewire). If that library is mission-critical I would not want to take the risk of leaving it up to the whim of whomever is hosting the source code online to remain online when I need it to be.

Just imagine the hypothetical case that you have a massive vibe.d project, and suddenly one day for whatever reason vibe.d becomes unmaintained / the repo goes offline or whatever. Well, no problem, there's Adam Ruppe's arsd library with web handling, right? Just change a few lines in dub.json and off you go?

The difference in API alone will probably entail rewriting the entire darned codebase before you could even get the thing to compile, let alone fixing all the bugs that were introduced in the process.

Drop-in replacement is a pipe dream.


> That's not really possible in a larger project that has been deployed. That would incur large costs. Besides there might not be another PDF-generating library for you to use, or sound synthesis package that is anywhere near compatible. Even in Python, if I cannot use the PDF library I am using now, I would most likely set up an additional Java service rather than trying to pull in another PDF library written in Python.
[...]

Exactly. Most non-trivial libraries of equivalent functionality tends to have drastically different APIs. It is not as easy as it sounds, that you just drop in a different library in place of the one that got abandoned.  In a large, non-trivial project switching components like that is a big no-no unless there's a very compelling reason to, *and* you have the time and resources to pull it off (and clean up the resulting mess afterwards).


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On Thursday, 3 October 2019 at 18:27:46 UTC, Adam D. Ruppe wrote:
> On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
>> How will it work once it's finished?
>
> That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library.
>
> Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left.
>
> The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.
>
>> Are there any plans for auto generated bridges, e.g. JNI calling rt_init() or something?
>
> I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.

That all sounds very good. As you probably know, Android Studio uses CMake for the C/C++ libs [1], it's not hard to set up and pretty handy, all my C code is compiled for whatever architecture and version of Android automagically. I realize that it would not be quite as "simple" for D. But something like that, an automatic D build script would be desirable. Also, you might want to have a look at how Kotlin handles multiplatform stuff, especially Android and iOS [2][3].

[1] https://developer.android.com/studio/projects/configure-cmake
[2] https://kotlinlang.org/docs/reference/native-overview.html
[3] https://play.kotlinlang.org/hands-on/Targeting%20iOS%20and%20Android%20with%20Kotlin%20Multiplatform/01_Introduction