Re: How to implement this?
On Friday, 8 April 2022 at 09:08:07 UTC, Stanislav Blinov wrote:
On Friday, 8 April 2022 at 05:53:03 UTC, Elvis Zhou wrote:
assumeNoEscapeOrWhatever!DynamicArray structs;
structs ~= cast(A*)
is it possible?
That's what `@trusted` is for. And that's also why it should be
used with care, and on the smallest code possible.
```d
struct A {}
struct B { A a; }
struct C { A a; }
void main()
{
A*[] structs;
B b;
C c;
() @trusted {
structs ~= cast(A*)
structs ~= cast(A*)
} ();
}
```
Thank you, this is exactly what I'm looking for!
But why this doesn't work?
void func() @trusted
{
A*[] structs;
B b;
structs ~= cast(A*) // still error
}
Re: How to implement this?
On Friday, 8 April 2022 at 05:46:56 UTC, Elvis Zhou wrote: On Friday, 8 April 2022 at 04:31:45 UTC, Elvis Zhou wrote: [...] I know where the issue comes from, dynamic array is GCed and save the reference of a local variable in GCed memory is not allowed, but here structs is assumed to not escape, it can be simply achieved by using a fixed-size array instead, ie A*[32] structs; int i = 0; structs[i++] = cast(A*) However I wonder if there be a stack allocated array with max capacity limits, which can be concated like with normal dynamic one. like, assumeNoEscapeOrWhatever!DynamicArray structs; structs ~= cast(A*) is it possible?
Re: How to implement this?
On Friday, 8 April 2022 at 04:31:45 UTC, Elvis Zhou wrote:
struct A {}
struct B { A a; }
struct C { A a; }
A*[] structs;
B b;
init();
structs ~= cast(A*)
//Error: copying `cast(A*)& b` into allocated memory escapes a
reference to local variable `b`
C c;
init();
structs ~= cast(A*)
//Error: copying `cast(A*)& c` into allocated memory escapes a
reference to local variable `c`
batch_process(structs);
I know where the issue comes from, dynamic array is GCed and save
the reference of a local variable in GCed memory is not allowed,
but here structs is assumed to not escape, it can be simply
achieved by using a fixed-size array instead, ie A*[32] structs;
int i = 0; structs[i++] = cast(A*) However I wonder if there
be a stack allocated array with max capacity limits, which can be
concated like with normal dynamic one.
How to implement this?
struct A {}
struct B { A a; }
struct C { A a; }
A*[] structs;
B b;
init();
structs ~= cast(A*)
//Error: copying `cast(A*)& b` into allocated memory escapes a
reference to local variable `b`
C c;
init();
structs ~= cast(A*)
//Error: copying `cast(A*)& c` into allocated memory escapes a
reference to local variable `c`
batch_process(structs);
Re: vibe.d on Web Framework Benchmarks
On Thursday, 8 June 2017 at 15:40:37 UTC, Ali Çehreli wrote: On 06/08/2017 05:09 AM, Dominikus Dittes Scherkl wrote: > Wow. Answer was actually visible before the OP. THAT is what I would > call fast. Did you use vibe.d? Your answer hasn't arrived yet. Using something other than vibe.d? :p Ali lol, your answer did arrive before OP.
Re: Calypso: Direct and full interfacing to C++
Seems this is abandoned? And why?
Re: Calypso: Direct and full interfacing to C++
Any update ? Hope things are going well!
Re: Andrei's Quora comments on Reddit: "D has no vision. Go is out of its depth. Rust skipped leg day."
On Thursday, 12 November 2015 at 11:55:18 UTC, Namal wrote: On Wednesday, 11 November 2015 at 19:51:45 UTC, Ali Çehreli wrote: On 11/11/2015 06:42 AM, Namal wrote: someone was saying that it is possible to call c++ standard library from D. Is there an example how to do this? Here is the spec e.g. saying 'extern (C++, std)': http://dlang.org/attribute.html#linkage The following page is about interfacing with C++, which may not be up to date: http://dlang.org/cpp_interface.html Others: is it up to date? Ali Ok than this is not what I have been thinking off. I thought I just can import the standard library of C++ and compile it with D compiler...oh well... Refer to this thread - http://forum.dlang.org/thread/gjivyaolrxagueffs...@forum.dlang.org
Re: D for Android
On Thursday, 30 July 2015 at 19:38:12 UTC, Joakim wrote: On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote: [...] Some good news, I've made progress on the port to Android/ARM, using ldc's 2.067 branch. Currently, all 46 modules in druntime and 85 of 88 modules in phobos pass their tests (I had to comment out a few tests across four modules) when run on the command-line. There is a GC issue that causes 2-3 other modules to hang only when the tests are run as part of an Android app/apk, ie a D shared library that's invoked by the Java runtime. [...] Would those patches for ldc/druntime/phobos be applied merged into LDC eventually?
Re: D for Android
On Thursday, 30 July 2015 at 19:38:12 UTC, Joakim wrote: On Monday, 25 May 2015 at 20:08:48 UTC, Joakim wrote: [...] Some good news, I've made progress on the port to Android/ARM, using ldc's 2.067 branch. Currently, all 46 modules in druntime and 85 of 88 modules in phobos pass their tests (I had to comment out a few tests across four modules) when run on the command-line. There is a GC issue that causes 2-3 other modules to hang only when the tests are run as part of an Android app/apk, ie a D shared library that's invoked by the Java runtime. [...] Really exciting news, I'll give it a try today, your great effort is much appreciated!
Re: Last call for AliasSeq
On Tuesday, 28 July 2015 at 11:55:01 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 28 July 2015 at 11:23:07 UTC, Elvis Zhou wrote: WTF does 'Seq' means? AliasSequence is much better! Seq is a function that maps natural numbers to values in the set X. «A finite sequence is a finite indexed set of values of the same type, whose domain is a contiguous set of positive integers starting at 1.» In Z-notation: «seq X is the set of all finite sequences of values of X , that is, of finite functions from the set 1 . . n, for some n, to elements of X .» «seq1 X is the set of all non-empty finite sequences of values of X .» «iseq X is the set of injective finite sequences over X : these are precisely the finite sequences over X which contain no repetitions.» Good to know, thanks. However, isn't AliasSequence more clear and does eliminate ambiguity? Moreover, as a nonnative English speaker, I've no idea how to pronounce Seq :(
Re: Last call for AliasSeq
On Tuesday, 28 July 2015 at 07:23:07 UTC, Sean Campbell wrote: On Friday, 24 July 2015 at 08:51:04 UTC, Marc Schütz wrote: Martin has just merged the rename of `TypeTuple` to `AliasSeq` into the stable branch, which will be released soon. If anyone wants to change the name again, please open a PR immediately, this is the last chance. Personally I like Arity. But if we are going with AliasSeq can we at least use the full word AliasSequence. IMOA: AliasSeq on it's own seems an obscure word to describe what it is +10086 WTF does 'Seq' means? AliasSequence is much better!
Re: LDC for iOS prebuilt binaries
On Friday, 10 July 2015 at 05:38:47 UTC, Dan Olson wrote: Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com writes: [...] [...] http://www.itoolchain.com/ or iPhone toolchain on cygwin
Re: Martin Nowak is officially MIA
On Wednesday, 17 June 2015 at 23:47:26 UTC, deadalnix wrote: On Wednesday, 17 June 2015 at 18:35:48 UTC, Andrei Alexandrescu wrote: [...] There is a very important difference with an actual job: an actual job with a salary. You just can't expect the same level of commitment from a volunteer than an employee. I understand the feeling, but that seems unnecessarily harsh to demote Martin, since he is the one that have done the most for release, and it yielded actual results. +1
Re: std.container: fork in the road
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu wrote: Took a fresh look at std.container from a Design by Introspection perspective, and my assessment is as follows: [...] (3)
Re: Calypso: Direct and full interfacing to C++
On Sunday, 8 February 2015 at 22:45:14 UTC, Elie Morisse wrote: On Sunday, 8 February 2015 at 20:56:31 UTC, Syro wrote: That is really cool. Thanks, just got that tangled mess of templates that is std::string working too: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/string.d Congrats! This is definitely an exciting news!!
Re: How's the new allocator module going and where to get it?
On Tuesday, 20 January 2015 at 16:37:30 UTC, Vladimir Panteleev wrote: On Tuesday, 20 January 2015 at 15:56:12 UTC, Elvis Zhou wrote: I can't find it in official repos. I believe the development is on Andrei's Phobos fork, branch allocator: https://github.com/andralex/phobos/blob/allocator/std/allocator.d Documentation (not sure how up-to-date it is, though): http://erdani.com/d/phobos-prerelease/std_allocator.html Thank you. But what's going on with the module, the last commit is 8 months ago,is it abandoned? I'm waiting for it to be officially released!
How's the new allocator module going and where to get it?
I can't find it in official repos.
Re: cross post hn: (Rust) _ _ without GC
On Tuesday, 23 December 2014 at 03:32:12 UTC, Vic wrote: On Tuesday, 23 December 2014 at 00:49:57 UTC, anonymous wrote: On Monday, 22 December 2014 at 23:21:17 UTC, Vic wrote: I am not saying no GC; I am saying: a) something needs to be moved out of core. And many don't agree. snip Dear Anonymous, IMO D needs to be more stable, the alternative is more and more features and less and less commercial users and followed by less maintainers that don't want a dead project to work on. D 'marketing' brings people in, who then leave. So I proposed: Do like GO does w/ Exceptions ( I can send link again if need) *What* would be another way to get stability that is not fantasy? I consider the surface area of features vs available volunteer maintainers at hand. If you are not sold, look at CLR and JRE features relative to D features. Now look at the size of their maintenance teams as relative FTE. Does that look as sustainable? Hence a prediction: major things will be moved out of core to 3rd party plugins to slim down the lang, because now it's more than a lang: it is a platform. Vic +1
Re: D for Android
On Thursday, 24 July 2014 at 01:17:44 UTC, Joakim wrote: On Thursday, 8 May 2014 at 16:16:22 UTC, Joakim wrote: Well, Android/x86 for now. I've been plugging away at getting D running on Android/x86 and got all of the druntime modules' unit tests and 37 of 50 phobos modules' unit tests to pass. I had to hack dmd into producing something like packed TLS for ELF, my patch is online here: http://164.138.25.188/dmd/packed_tls_for_elf.patch I simply turned off all TLS flags for ELF and spliced in the el_picvar patch from OS X to call ___tls_get_addr. Somebody who knows dmd better than me should verify to make sure this is right. I've also put online preliminary pulls for druntime and phobos: https://github.com/D-Programming-Language/druntime/pull/784 https://github.com/D-Programming-Language/phobos/pull/2150 Now that a significant chunk of D is working on Android/x86, I'm looking for others to pitch in. We really need to get D on mobile, and Android/x86 is an ideal place to start. Dan Olson has done some nice work getting D on iOS using ldc, I'm sure he could use help too: http://forum.dlang.org/thread/m2txc2kqxv@comcast.net http://forum.dlang.org/thread/m2d2h15ao3@comcast.net Stuff remaining to be done: 1. Fix all phobos unit tests. Those who know the failing modules better would be best equipped to get them to work. 2. I tried creating an Android app, ie an apk, which is really just a shared library called from the Dalvik JVM, as opposed to the standalone executables I've been running from the Android command line so far. The apk enters the D code and then segfaults in the new TLS support, I'll debug that next. 3. Use ldc/gdc to build for Android/ARM. 4. Start translating various headers on Android so they can be called from D, ie EGL, OpenGL ES, sensors, etc. 5. Integrate the D compilers into the existing Makefile-based build system of the Android NDK. Right now, I extract the necessary compiler and linker commands and run them by hand when necessary. All you need to get going is to download the latest Android NDK (http://developer.android.com/tools/sdk/ndk/index.html) and run Android/x86 (http://www.android-x86.org/, I recommend the 4.3 build) in a VM. I'll put up some basic setup and build instructions if someone is interested. An update on the porting effort: I just got most modules' unit tests to pass as part of an Android/x86 app, a native apk, ie a D shared library called from a small C wrapper, no Java required. :) All druntime/phobos modules but one, std.datetime, passed their tests on the Android/x86 command-line a couple months ago. Three of those modules segfault when run as part of the tests in an apk- core.thread, std.parallelism, and std.socket- going to look at those next. I'm guessing the first two might be related to the C wrapper also calling pthreads, as they passed on the command-line. This means most of 1. and 2. above can be crossed off the list. I'll start cleaning up my fairly simple build process and document it on the wiki, so that others can easily play with D on Android/x86. Most of the patches so far have been merged into git master, with the dmd patch above now a PR: https://github.com/D-Programming-Language/dmd/pull/3643 Only small tweaks were needed beyond that, which I'll submit as PRs in the coming days. Looking forward to help on 3., 4., and 5. above, and to seeing what others do with this new platform. Congratulations! I'll definitely give it a try when Android/Arm get ready and I think your great efforts will give D a new life as the best programming language for mobile platform.D may be another ObjC once it runs on Android/iOS stably.
Re: [OT] Lifetime elision proposal in Rust ( regex macro)
On Monday, 30 June 2014 at 17:47:11 UTC, Brian Rogoff wrote: On Monday, 30 June 2014 at 17:28:06 UTC, Ary Borenszweig wrote: On 6/30/14, 1:50 PM, Nick Treleaven wrote: Hi, This recent proposal looks like it might clean up typical Rust function What are those 'a all over the place? I never understood them :-( Those are lifetimes, which are a part of the Rust type annotation machinery. The syntax is borrowed (pun intended ;-) from ML family languages, which use type variables like 'a, 'b, 'c (pronounced alpha, beta, gamma, or tick a, tick b, tick c) to express parametric polymorphism. Rather than try to explain Rust's lifetimes, I'll point you here http://rustbyexample.com/lifetime.html Rust is still undergoing development, and the lifetime syntax is a bit noisy, so it may change, but the rustbyexample page has been following the Rust nightly builds closely. It's an interesting language, and the Mozilla backing really helps it, but I find D and Nimrod easier to use right now. I like this rustbyexample.com, is there a dbyexample.com?
