Re: real beginner question about D's web site?
On Sunday, 24 January 2021 at 20:05:47 UTC, WhatMeWorry wrote: mentions the $ signs, as well as the $1 and $3. See point 4 here: https://dlang.org/spec/ddoc.html#macros $(THING ...) is a macro invocation. Inside the macro definition, $0 is the full text represented by "..." here. Then $1 is the text up to the first comma, $2 text from first to second comma, etc.
real beginner question about D's web site?
https://github.com/dlang/dlang.org/blob/ff235feedcb2bcb73ba348dcd1763542a43c7778/doc.ddoc D_S = $(LAYOUT ,$1,$(ARGS $+)) SPEC_S = $(LAYOUT ,$1,$(ARGS $+)) COMMUNITY= $(LAYOUT ,$1,$(ARGS $+)) _= LAYOUT=$3 _= I realize that D_S and LAYOUT, etc are macros. I've read the DDoc documentation and HTML, CSS, etc. but none of my research mentions the $ signs, as well as the $1 and $3. Am I missing something obvious?
Re: std.expreimantal.allocator deallocate
On Sunday, 24 January 2021 at 14:56:25 UTC, Paul Backus wrote: On Sunday, 24 January 2021 at 11:00:17 UTC, vitamin wrote: It is Ok when I call deallocate with smaller slice or I need track exact lengtht? It depends on the specific allocator, but in general, it is only guaranteed to work correctly if the slice you pass to deallocate is exactly the same as the one you got from allocate. To add to that, if an allocator defines `resolveInternalPointer` [0][1] you could be able to get the original slice that was allocated (and then pass that to `deallocate`, but not all allocators define `resolveInternalPointer` and also even if they do define it, they're not required to maintain complete book-keeping as doing so could have bad performance implications (i.e. calling say `a.resolveInternalPointer(a.allocate(10)[3 .. 6].ptr, result)` can return `Ternary.unknown`. [0]: https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.resolveInternalPointer [1]: https://dlang.org/phobos/std_experimental_allocator_building_blocks.html
Re: std.expreimantal.allocator deallocate
On Sunday, 24 January 2021 at 16:16:12 UTC, vitamin wrote: On Sunday, 24 January 2021 at 14:56:25 UTC, Paul Backus wrote: On Sunday, 24 January 2021 at 11:00:17 UTC, vitamin wrote: It is Ok when I call deallocate with smaller slice or I need track exact lengtht? It depends on the specific allocator, but in general, it is only guaranteed to work correctly if the slice you pass to deallocate is exactly the same as the one you got from allocate. thanks, is guaranteed this: void[] data = Allocator.allocate(data_size); assert(data.length == data_size) or can be data.length >= data_size ? Yes, it is guaranteed [0]. Even though some allocator implementations will allocate a larger block internally to back your requested allocation size, `allocate` [1] must return the same number of bytes as you requested, or a `null` slice. If an allocator has a non-trivial `goodAllocSize(s)` [2] function (i.e. one that is not the identity function `s => s`) and you you allocate say N bytes, while allocator.goodAllocSize(N) returns M, M > N, it means that most likely calling `expand` [3] will succeed - meaning it will give you the excess memory that it has internally for free. I say "most likely", because this is the intention of the allocator building blocks spec, even though it's not specified. In theory, `expand` could fail in such situation either because of an allocator implementation deficiency (which would technically not be a bug), or because `allocate` was called concurrently by another thread and the allocator decided to give the excess space to someone else. [0]: https://dlang.org/phobos/std_experimental_allocator_building_blocks.html [1]: https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.allocate [2]: https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.goodAllocSize [3]: https://dlang.org/phobos/std_experimental_allocator.html#.IAllocator.expand
Re: std.expreimantal.allocator deallocate
On Sunday, 24 January 2021 at 14:56:25 UTC, Paul Backus wrote: On Sunday, 24 January 2021 at 11:00:17 UTC, vitamin wrote: It is Ok when I call deallocate with smaller slice or I need track exact lengtht? It depends on the specific allocator, but in general, it is only guaranteed to work correctly if the slice you pass to deallocate is exactly the same as the one you got from allocate. thanks, is guaranteed this: void[] data = Allocator.allocate(data_size); assert(data.length == data_size) or can be data.length >= data_size ?
Re: std.expreimantal.allocator deallocate
On Sunday, 24 January 2021 at 11:00:17 UTC, vitamin wrote: It is Ok when I call deallocate with smaller slice or I need track exact lengtht? It depends on the specific allocator, but in general, it is only guaranteed to work correctly if the slice you pass to deallocate is exactly the same as the one you got from allocate.
Re: How can I create a Standalone Bundle Portable file application using Dlang?
On Sunday, 24 January 2021 at 11:44:04 UTC, Marcone wrote: On Saturday, 23 January 2021 at 21:26:28 UTC, James Blachly wrote: On 1/20/21 6:50 AM, Marcone wrote: On Tuesday, 19 January 2021 at 14:20:06 UTC, Imperatorn wrote: [...] I do not mean resources .res, except if is possible use files inside resources without copy to hard disc and make accessible as it is in local path. I am afraid we are not speaking the same language. Because it sounds like you may not be using "dependencies" as it is conventionally understood in most programming communities, you'll need to give examples. For the record, dependencies are typically either compile-time dependencies or run-time dependencies, and in both cases I think the commonest example would be a library. Qt5 dlls Just use the dlls, redist
Re: How can I create a Standalone Bundle Portable file application using Dlang?
On Sunday, 24 January 2021 at 11:44:04 UTC, Marcone wrote: Qt5 dlls Well, you are out of luck. It is doable, but... Normally you would likely want to use static libraries and link them into your executable, with Qt license however it becomes problematic in pretty much any case, you still can embed them using import() and unpack to a temporary directory for manual loading without violating the license. Another problem mentioned before is implicit dynamic loading where you link with special stub .lib file for automatic loading, which is more common in C++ due to symbol name mangling, that will not work because your code won't have a chance to run main().
Re: How can I create a Standalone Bundle Portable file application using Dlang?
On Saturday, 23 January 2021 at 21:26:28 UTC, James Blachly wrote: On 1/20/21 6:50 AM, Marcone wrote: On Tuesday, 19 January 2021 at 14:20:06 UTC, Imperatorn wrote: On Tuesday, 19 January 2021 at 11:10:25 UTC, Marcone wrote: On Tuesday, 19 January 2021 at 06:25:31 UTC, Imperatorn wrote: On Monday, 18 January 2021 at 19:42:22 UTC, Marcone wrote: How can I create a Standalone Bundle Portable file application using Dlang? Could you describe what you mean with "Bundle portable file application"? All dependencies inside an exe file. Like Python Pyinstaller. Do you with "dependencies" mean "resources"? In that case, yeah import is an option someone mentioned. I do not mean resources .res, except if is possible use files inside resources without copy to hard disc and make accessible as it is in local path. I am afraid we are not speaking the same language. Because it sounds like you may not be using "dependencies" as it is conventionally understood in most programming communities, you'll need to give examples. For the record, dependencies are typically either compile-time dependencies or run-time dependencies, and in both cases I think the commonest example would be a library. Qt5 dlls
Re: How can I create a Standalone Bundle Portable file application using Dlang?
On Sunday, 24 January 2021 at 02:34:15 UTC, Jack wrote: On Monday, 18 January 2021 at 19:42:22 UTC, Marcone wrote: How can I create a Standalone Bundle Portable file application using Dlang? What are the dependencies that you would like to merge into executable? dlls? resources? Qt5 Dll's or Tk dlls.
std.expreimantal.allocator deallocate
Allocators from std.expreimantal.allocator allocate memory and
return slice void[] to allocated memory.
Method deallocate has as parameter void[] slice to allocated
memory.
It is Ok when I call deallocate with smaller slice or I need
track exact lengtht?
Example:
import std.experimental.allocator : theAllocator;
import core.lifetime : emplace;
import std.stdio;
class Base{
int i;
}
class Derived : Base{
int j;
}
Base make(){
void[] x = theAllocator.allocate(__traits(classInstanceSize,
Derived));
writeln("allocate: ", x.length);
emplace!Derived(x);
return cast(Derived)x.ptr;
}
void destruct(Base base){
void[] x = (cast(void*)base)[0 .. __traits(classInstanceSize,
Base)];
writeln("deallocate: ", x.length);
theAllocator.deallocate(x);
}
void main(){
Base x = make;
scope(exit)destruct(x);
///some code...
}
//print:
//allocate: 24
//deallocate: 20
Re: Initializing D runtime and executing module and TLS ctors for D libraries
On Sunday, 24 January 2021 at 03:59:26 UTC, Ali Çehreli wrote: That must be the case for threads started by D runtime, right? It sounds like I must call rt_moduleTlsCtor explicitly for foreign threads. It's still not clear to me which modules' TLS variables are initialized (copied over). Only this module's or all modules that are in the program? I don't know whether it's possible to initialize one module; rt_moduleTlsCtor does not take any parameter. Any threads started by druntime has proper initialization of course. Any thread started by any module written in another language will not do D the thread initialization. All TLS variables in all loaded modules are being initialized (only copying and zeoring) by the OS system code for each thread that the OS system knows about. After that it is up to each library for each language to do further initialization. Next time __tls_get_addr is being called after loading a library, the TLS variables of any new module will be found and initialized. It is a mystery to me why the TLS standard never included a ctor/dtor vector for TLS variables. It is in practice possible but they didn't do it. The whole TLS design is like a swiss scheese. Did you mean a generic API, which makes calls to D? That's how I have it: an extern(C) API function calling proper D code. I have a lot of system code written in C++ which also include callbacks from that code. In order to support D a layer is necessary to catch all callbacks in a trampoline and invoke D delegates. Calling D code directly with extern(C) should be avoided because 1. D delegates are so much more versatile. 2. You must use a trampoline in order to do D specific thread initialization anyway. Since std::function cannot be used in a generic interface I actually use something like this, http://blog.coldflake.com/posts/C++-delegates-on-steroids/. Which is more versatile than plain extern(C) but simple enough so that it can be used by any language. In the case of D the "this pointer" can be used to a pointer of a D delegate. Creating language agnostic interfaces require more attention than usual as I have experienced. Strings for example complicates things further as they are different for every language.
