Re: DIP 1024---Shared Atomics---Accepted
On Thursday, 2 January 2020 at 09:41:02 UTC, Walter Bright wrote: On 1/2/2020 12:01 AM, Manu wrote: Quick quick, we need a PR to issue deprecation messages for those invalid read/writes! :) It's already been merged! https://github.com/dlang/dmd/pull/10209 Some really fast work there :-) Nice. There was some initial work on shared a long while back: https://github.com/dlang/dmd/commit/276a69327652be8d95607cec142790baae110d0c It's interesting it took this long to push it to the end. :)
Re: DIP 1024---Shared Atomics---Accepted
On Sat, Jan 4, 2020 at 2:15 PM Walter Bright via Digitalmars-d-announce wrote: > > On 1/3/2020 3:41 AM, Manu wrote: > > We've already had this -preview for quite a while; I have enabled it > > in an experimental context, but I don't tend to write and deploy code > > that depends on future-features. I stick to the current language when > > writing code I intend to share. > > Do you have some sense of when we will make this part of the language? > > The DIP is accepted, but it didn't describe that it would be enabled > > at some future time...? > > You shouldn't be reluctant to use preview switches. It's only that way to ease > the transition for people, not because we're going to withdraw it. Well it was a preview for an unaccepted DIP, so it could have been withdrawn. I guess I have increased confidence now, but it still seems unnecessary to delay. > Don't really have a schedule at the moment. It'll likely be at least a year. A year? That's disappointing. What is the reason to delay this? It doesn't break anything, and it likely fixes bugs on contact.
Re: My Android project nearing beta
On Monday, 6 January 2020 at 17:40:47 UTC, Laeeth Isharc wrote: I haven't tried, but: https://github.com/linkedin/dexmaker Yes, indeed, that is a possibility. I might work on this... honestly probably after several months given the length of my to do list right now.
Re: My Android project nearing beta
On Monday, 6 January 2020 at 14:37:54 UTC, Adam D. Ruppe wrote: On Sunday, 5 January 2020 at 03:56:37 UTC, visitor wrote: Not a single line of java! so i got kinda excited for creating a class 100% in D as well, but. https://developer.android.com/training/articles/perf-jni.html "DefineClass is not implemented. Android does not use Java bytecodes or class files, so passing in binary class data doesn't work." I haven't tried, but: https://github.com/linkedin/dexmaker
Re: My Android project nearing beta
On Monday, 6 January 2020 at 17:18:46 UTC, visitor wrote: hum ... indeed most of the native samples in android are using java helper classes Yeah, the NativeActivity is I think the only one that doesn't (and that's just because Google provides a pre-built helper java class). But I'm personally OK with that; reusing the platform as much as we can is a strength of D, it doesn't have to be all one thing. A little bit of Java gives you hooks into the IDE and stuff and isn't that much work; you can still reuse the majority of a D core. do you still plan to add the ability to create java classes in D for non-android projects ? yes. I might not get around to it for a little while and it will very possibly be opt-in with a -version thing (right now I call it WithClassLoadSupport - creating a class would use the same code to work with the binary format). But I do want to do it. Another challenge would be syntax. D does lambdas and anonymous inner classes... but they probably won't get the magic on them. It may end up being a helper template, so you'd be like JavaLambda!InterfaceName( a => whatever ); or something like that. I still need to think more about it. also in this project i made "GlobalRef"s to reuse java objects / classes - thanks for warmly warning about the possible I plan to address this later too. Probably all return values will conservatively get the global ref unless you declare it as like `Manual!T` instead, which then wraps it for you and uses the type system to determine what needs to be it. (if you look at the comments of jni.d you can see a lot of my notes to self about problems and possible future directions. Not all of them actually work out, but it gives you some view into what's in my brain.) (btw, though good to know the trick, in fact i don't need the sourceSets instruction for the jniLibs, i forgot to put the library in the right subfolder ... "x86" or "armeabi-v7a", etc...) excellent.
Re: My Android project nearing beta
On Monday, 6 January 2020 at 14:37:54 UTC, Adam D. Ruppe wrote: gah, there goes that idea. So I guess that means the lambda callbacks for ui classes must be implemented in Java too. alas. but still most things work anyway so still fun. hum ... indeed most of the native samples in android are using java helper classes do you still plan to add the ability to create java classes in D for non-android projects ? (ui callbacks, that's where i paused in my non-Android test, also in this project i made "GlobalRef"s to reuse java objects / classes - thanks for warmly warning about the possible wreckage) (btw, though good to know the trick, in fact i don't need the sourceSets instruction for the jniLibs, i forgot to put the library in the right subfolder ... "x86" or "armeabi-v7a", etc...)
Re: My Android project nearing beta
On Sunday, 5 January 2020 at 03:56:37 UTC, visitor wrote: Not a single line of java! so i got kinda excited for creating a class 100% in D as well, but. https://developer.android.com/training/articles/perf-jni.html "DefineClass is not implemented. Android does not use Java bytecodes or class files, so passing in binary class data doesn't work." gah, there goes that idea. So I guess that means the lambda callbacks for ui classes must be implemented in Java too. alas. but still most things work anyway so still fun. I need to make one of those NativeActivity ndk programs as a sample though, to show people how to do all that stuff.
Re: ssll - simple shared library loader
Am 06.01.2020 um 00:23 schrieb Oleg B:
It's analog of bindbc, but without need write boilerplate code.
May be bindbc is designed for another cases, but I don't understand need
writing triple definition for one function (pointer, loading,
wrap-function).
ssll betterC compatible too, and tested on windows (x86) and linux (x86,
ARM).
package: http://code.dlang.org/packages/ssll
github: https://github.com/deviator/ssll
Example usage:
Mosquitto binding and wrapper
https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d
libsystemd binding
https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d
I think somebody can find it handy.
Just throwing this in as a possible API alternative/addition - I've
written something similar with the goal to make it work transparently
with existing static bindings: https://code.dlang.org/packages/dynamic
It uses a mixin to specify the module(s) containing the declarations
instead of a UDA:
mixin dynamicBinding!(somelib) _somelib;
void main()
{
_somelib.loadBinding(["somelib.so"]);
import somelib : foo;
foo();
}
Re: ssll - simple shared library loader
On Sunday, 5 January 2020 at 23:23:48 UTC, Oleg B wrote: It's analog of bindbc, but without need write boilerplate code. May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function). ssll betterC compatible too, and tested on windows (x86) and linux (x86, ARM). package: http://code.dlang.org/packages/ssll github: https://github.com/deviator/ssll Example usage: Mosquitto binding and wrapper https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d libsystemd binding https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d I think somebody can find it handy. Nice, I like this project and how it solves the problem stated, i.e the 3 versions.
