Re: Since dmd 2.096.0: import `x.t` is used as a type
On 5/2/21 4:32 PM, kdevel wrote:
On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:
[...]
BTW during the PR review the problem you encounter [was
anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263)
si I guess you're stuck with [the author
answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749),
i.e "this worked because of a special case".
Sure.
Again you can still try to get the change turn into a deprecation
first, that'd be legit.
It only broke the compilation which I already have fixed. Kind of. I
would have filed a bug if the runtime went kaput.
After reading https://dlang.org/spec/module.html#module_declaration
again I wonder why there is no advice to avoid module (file) names which
equate symbol names defined in the module. I also wonder how I get a
module file named ``foo-bar.d`` referenced from another module.
Following the advice in the documentation
```
// foo-bar.d
module foo_bar;
void foo ()
{
}
// main.d
import foo_bar;
void main ()
{
foo;
}
```
it does not compile:
```
$ dmd -i main.d
main.d(1): Error: module `foo_bar` is in file 'foo_bar.d' which cannot
be read
```
In order for that to work, you need to pass the file that contains the
module to the compiler.
Otherwise, the compiler must assume that the module lives in the file
named after itself.
-Steve
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Sunday, 2 May 2021 at 18:36:25 UTC, Basile B. wrote:
[...]
BTW during the PR review the problem you encounter [was
anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si I guess you're stuck with [the author answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e "this worked because of a special case".
Sure.
Again you can still try to get the change turn into a
deprecation first, that'd be legit.
It only broke the compilation which I already have fixed. Kind
of. I would have filed a bug if the runtime went kaput.
After reading
https://dlang.org/spec/module.html#module_declaration again I
wonder why there is no advice to avoid module (file) names which
equate symbol names defined in the module. I also wonder how I
get a module file named ``foo-bar.d`` referenced from another
module. Following the advice in the documentation
```
// foo-bar.d
module foo_bar;
void foo ()
{
}
// main.d
import foo_bar;
void main ()
{
foo;
}
```
it does not compile:
```
$ dmd -i main.d
main.d(1): Error: module `foo_bar` is in file 'foo_bar.d' which
cannot be read
```
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Sunday, 2 May 2021 at 15:41:13 UTC, kdevel wrote:
On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:
Hard breakage is not acceptable, even if the goal is to
introduce a more correct behavior.
I still wonder why module names are taken as a candidates for
types and functions in the first place. Isn't there a symbol
table for module names separate from that for type and function
names?
I dont think so. That would lead to special cases in fully
qualified lookups.
Lookups must follow the reverse lexical order of declarations so
an import adds a symbols in the current scope.
BTW during the PR review the problem you encounter [was
anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si I guess you're stuck with [the author answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e "this worked because of a special case".
Again you can still try to get the change turn into a deprecation
first, that'd be legit.
Just checked how things are done in another language where
modules are called “packages”:
I have checked in styx too. This does not work either but for
another reason that D, that is that overloads are explicit,
meaning all names unique in a given scope, so
```styx
§s.sx
unit s;
§u.sx
unit v;
struct s {}
import s;
var s s1;
```
gives
u.sx:8:8: error, symbol `s` already declared line 6
same when the import and the var decls positions are exchanged.
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 16:42:07 UTC, evilrat wrote: On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: As for SDL2, are you sure it was built with Vulkan support? That's the thing I worry about, since the SDL2 libraries are locally build using android studio and I'm kind of a noob in that. Ok, since this is potentially the case, just to clarify, building C/C++ with CMake for Android these days is basically one extra parameter pointing to CMake toolchain file in your local NDK location when configuring your build. https://developer.android.com/ndk/guides/cmake#file (from the docs) ``` $ cmake \ -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABI=$ABI \ -DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \ $OTHER_ARGS ``` Then I would probably use gradle for the rest of the process to produce apk, including copy libraries step. Thanks, but the APK builds fine, and installs. OpenGLES and SDL work like a charm, it's just the SDL_Vulkan_LoadLibrary call crashing. I think it might have to do with the bindbc-sdl dependency compiling with SDL_201 support, while Vulkan needs SDL_206 minimum. Even though I set SDL_2014 in DUB, it seems not to get picked up in some way. I also found this: https://developer.android.com/guide/topics/manifest/uses-feature-element So it might be the manifest needs to be updated as well. A real puzzle, Danny
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: As for SDL2, are you sure it was built with Vulkan support? That's the thing I worry about, since the SDL2 libraries are locally build using android studio and I'm kind of a noob in that. Ok, since this is potentially the case, just to clarify, building C/C++ with CMake for Android these days is basically one extra parameter pointing to CMake toolchain file in your local NDK location when configuring your build. https://developer.android.com/ndk/guides/cmake#file (from the docs) ``` $ cmake \ -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \ -DANDROID_ABI=$ABI \ -DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \ $OTHER_ARGS ``` Then I would probably use gradle for the rest of the process to produce apk, including copy libraries step.
Re: How do you compile DMD on Windows?
On Sunday, 2 May 2021 at 14:19:09 UTC, Imperatorn wrote: I opened the VS solution provided and pressed "build". Ta-daa! Haha yea, but wait until you try to build the runtime or phobos ;) I hope you don't have to/want to. But I can try to help if you do.
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 13:43:11 UTC, evilrat wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few tips. GC "crashes" since you have custom main, D default main has runtime initialization code so it "just works", in you custom main function try to do this before any call to D code. Oops, nevermind. I thought you've missed runtime initialization at all but you have rt_init. In that case you can try disable parallel collection, or it could be a bug. https://dlang.org/spec/garbage.html#gc_config https://dlang.org/spec/garbage.html#gc_parallel As for SDL2, are you sure it was built with Vulkan support? Do you have any other Vulkan apps to test if it actually supported by your device? SDL2 docs also says vulkan load library should be called only after you created window surface. It is hard to say from provided code if you have that too. Yeah, it's tricky to create an SDL window sometimes, like on android SDL_CreateWindow not being allowed to have it SDL_WINDOWPOS_CENTERED I thought they meant use it like after SDL_Init(), but before you create the window. I think the function pointer might not be loaded since the SDL_Init returns a which means 2.0.1 for some reason. I think something is going wrong and nothing is doing a dlopen() on vulkan.so Anyway, I might try to look at this next weekend. Do you have this project available on github/google drive? well it's just a bunch of files atm, but with a serious dependency chain, I'll try to minimize it. Guess for now the deprecated openGL has to be the fallback
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:
On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:
Any thoughts on why loading the Vulkan library using SDL2
would not work ?
thoughts in general about the process ?
Just few tips.
GC "crashes" since you have custom main, D default main has
runtime initialization code so it "just works", in you custom
main function try to do this before any call to D code.
https://dlang.org/phobos/core_runtime.html#.Runtime.initialize
```d
extern(C) main()
{
import core.runtime;
Runtime.initialize();
scope(exit)
Runtime.terminate();
}
```
Yeah, I just use the rt_init() and disable it, no real issue.
Most of the code is @nogc code anyway.
As for SDL2, are you sure it was built with Vulkan support?
That's the thing I worry about, since the SDL2 libraries are
locally build using android studio and I'm kind of a noob in that.
I use the provided android_project (from the sdl zip) and make
symbolic links in the app/jni folder to:
SDL, SDL2_Image, SDL2_Mixer, Etc
I delete the creation of the libmain.so by removing the src/
folder
Do you have any other Vulkan apps to test if it actually
supported by your device?
It's android 10 so it should be, but I could try creating a c
minimal example in vulkan, although that's gonna be 500 LoC as
well.
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:
Hard breakage is not acceptable, even if the goal is to
introduce a more correct behavior.
I still wonder why module names are taken as a candidates for
types and functions in the first place. Isn't there a symbol
table for module names separate from that for type and function
names?
Just checked how things are done in another language where
modules are called “packages”:
```
// Foo.go
package Foo
import "fmt"
func Foo () {
fmt.Println ("this is Foo.Foo ()");
}
// Soo.go
package Soo
type Soo struct {
Name string
}
// main.go
package main
import "fmt"
import . "Foo"
import . "Soo"
func main () {
fmt.Println ("main package")
Foo ()
s := Soo {Name: "xx"}
fmt.Println (s.Name)
}
```
Besides the hard to remember syntax that only those symbols are
exported which start with an uppercase letter it works as
expected.
Re: How do you compile DMD on Windows?
On Saturday, 1 May 2021 at 22:44:34 UTC, Blatnik wrote: I wanna hack on the compiler, but I've spend 3 hours and I can't get the damned thing to compile! [...] For me it took 3 minutes. I opened the VS solution provided and pressed "build". Ta-daa!
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few tips. GC "crashes" since you have custom main, D default main has runtime initialization code so it "just works", in you custom main function try to do this before any call to D code. Oops, nevermind. I thought you've missed runtime initialization at all but you have rt_init. In that case you can try disable parallel collection, or it could be a bug. https://dlang.org/spec/garbage.html#gc_config https://dlang.org/spec/garbage.html#gc_parallel As for SDL2, are you sure it was built with Vulkan support? Do you have any other Vulkan apps to test if it actually supported by your device? SDL2 docs also says vulkan load library should be called only after you created window surface. It is hard to say from provided code if you have that too. Anyway, I might try to look at this next weekend. Do you have this project available on github/google drive?
Re: SDL2 Android vulkan question
On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:
Any thoughts on why loading the Vulkan library using SDL2 would
not work ?
thoughts in general about the process ?
Just few tips.
GC "crashes" since you have custom main, D default main has
runtime initialization code so it "just works", in you custom
main function try to do this before any call to D code.
https://dlang.org/phobos/core_runtime.html#.Runtime.initialize
```d
extern(C) main()
{
import core.runtime;
Runtime.initialize();
scope(exit)
Runtime.terminate();
}
```
As for SDL2, are you sure it was built with Vulkan support?
Do you have any other Vulkan apps to test if it actually
supported by your device?
Re: How do you compile DMD on Windows?
On Sunday, 2 May 2021 at 00:53:42 UTC, MoonlightSentinel wrote: DM make is included in DMC which is available on this site, see the "other downloads". Yea thanks, I couldn't find it anywhere separately before. So in the end even though digger just worked, I didn't realize that it just installs an old version of visual studio. And of course I wanted to build everything with my version. So back to broken make it is. I managed to make DM make work. But this build "experience" was terrible..
Re: EMSI Containers and HashMap of HashMaps
On Sunday, 2 May 2021 at 08:59:15 UTC, Imperatorn wrote: ```d HashMap!(int, RefCounted!Map) mapOfMaps = HashMap!(int, RefCounted!Map)(1024); ``` That only fixes it, because you are avoiding the rehash with the initial size.
Re: EMSI Containers and HashMap of HashMaps
On Sunday, 2 May 2021 at 08:59:15 UTC, Imperatorn wrote: On Sunday, 2 May 2021 at 07:38:03 UTC, Tobias Pankrath wrote: ```d HashMap!(int, RefCounted!Map) mapOfMaps = HashMap!(int, RefCounted!Map)(1024); ``` Is HashMap.init a broken state? That makes using them hard as struct members :/
Re: EMSI Containers and HashMap of HashMaps
On Sunday, 2 May 2021 at 07:38:03 UTC, Tobias Pankrath wrote:
The following code segfaults, when the outer hashmap rehashes,
and I am not yet sure why.
```d
module tests.refcounted_hashmap_test;
import containers;
import std.typecons;
struct Map
{
HashMap!(int, int) theMap;
}
unittest
{
HashMap!(int, RefCounted!Map) mapOfMaps;
foreach (i; 0 .. 1000)
{
RefCounted!Map val;
if (i == 0) val.theMap.getOrAdd(i, i);
mapOfMaps.getOrAdd(i, val);
}
}
```
For your convenience: https://run.dlang.io/is/gHSlu1
I am using Refcounted() because HashMap itself is not
copy-able. Is there another way to have HashMaps as values of
HashMaps?
```d
HashMap!(int, RefCounted!Map) mapOfMaps = HashMap!(int,
RefCounted!Map)(1024);
```
SDL2 Android vulkan question
Dear all,
I've written a 2D/3D engine in D before which runs on windows,
linux and android using SDL2 as the window manager and uses
Modern OpenGL /OpenGLES for rendering. It compiles fine for
android using ldc and works like a charm, although the garbage
collection under android has multi-threading issues.
Since OpenGL is abandoned, I am currently adding Vulkan support
to future proof it.
I have done this in D with the help of the bindbc-sdl and erupted
packages and managed to get the whole vulkan-tutorial.com example
working under windows without much hassle. (I bet it would run on
linux without much issues as well)
So I have now been stuck for a week on getting the tutorial
example to successfully run on android. To do this I get a DLL
compiled with ldc, I have setup the SDL2 toolchain for android,
with symlinks to SDL2/IMAGE/TTF/etc, I hook the call to SDL_main
from the JNI:
```D
/* Main entry point to the program */
version (Android) {
import core.memory;
import core.runtime : rt_init;
extern(C) int SDL_main(int argc, char* argv) { // Hijack the
SDL main
rt_init();
GC.disable(); // The GC crashes on android
run(["android"]);
return(0);
}
// Other OS can just call run() directly (No known issues with
garbage collection)
} else { void main (string[] args) { run(args); } }
```
I create my APK using Android Studio, and load it onto my phone.
The hook succeeds, I can do:
```D
loadSDL();
SDL_Log("SDL loaded");
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO);
SDL_Log("SDL init");
SDL_Vulkan_LoadLibrary();
SDL_Log("SDL_Vulkan_LoadLibrary");
```
I see SDL being loaded and initialized (successfully) on my
phone. However, the SDL_Vulkan_LoadLibrary call just crashes the
whole thing dead, with a:
```cmd
I/SDL/APP: SDL loaded
I/SDL/APP: SDL init
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault
addr 0x0 in tid 25878 (SDLThread), pid 25794 (SDLActivity)
```
I was wondering if I am missing something obvious. Since it works
for SDL2 and opengles
Any thoughts on why loading the Vulkan library using SDL2 would
not work ?
thoughts in general about the process ?
Danny
EMSI Containers and HashMap of HashMaps
The following code segfaults, when the outer hashmap rehashes,
and I am not yet sure why.
```d
module tests.refcounted_hashmap_test;
import containers;
import std.typecons;
struct Map
{
HashMap!(int, int) theMap;
}
unittest
{
HashMap!(int, RefCounted!Map) mapOfMaps;
foreach (i; 0 .. 1000)
{
RefCounted!Map val;
if (i == 0) val.theMap.getOrAdd(i, i);
mapOfMaps.getOrAdd(i, val);
}
}
```
For your convenience: https://run.dlang.io/is/gHSlu1
I am using Refcounted() because HashMap itself is not copy-able.
Is there another way to have HashMaps as values of HashMaps?
Re: Import static library by DUB (linking)
On Sunday, 2 May 2021 at 04:42:42 UTC, Mike Parker wrote: On Saturday, 1 May 2021 at 18:30:26 UTC, Wusiki wrote: FYI, `static` has no meaning at module scope. Ok, I replaced abc to abc() string function; Did you compile `testlib.d` into a library? I only ask because you didn't show a command line for it. Yes. My tree: - Root - libs - testlib.a - source - app.d - dub.json testlib.a was build also with DUB where targetType was "library";
Re: OutOfMemoryError in D DLL appending to module-level array
On Sunday, 2 May 2021 at 02:42:46 UTC, Adam D. Ruppe wrote: On Sunday, 2 May 2021 at 02:34:41 UTC, cc wrote: which seems to fix it, but I'm not entirely sure what's going on, if this is expected behavior, if that's the correct way to handle it, and so on. Oh I've been working on this the last couple weeks and having a hard time reproducing outside the work application. In the work app, the GC wasn't scanning the dll's TLS variables and freeing them prematurely. In a sample test program, I used a thing kinda like yours, if a dll creates a thread and calls back into the exe you get a separate problem of partially initialize data. D dlls on Windows work in simple cases right now but break down in more advanced cases. The good news is there's major fixes coming soon - my druntime hack might be coming, gdc is getting full dll support very soon from mingw, there's a good chance ldc is going to in a release or two as well outside mingw. But the bad news is none of that is actually out right now, so dll + tls variables (which includes the top-level things on modules) are potentially buggy among other things like duplicated symbols. You might find some improvement making your variable __gshared there. But if you can do any reduced test case I'd really appreciate it. More tests that we can do in public is better! Cool, thanks for the update. Setting it as __gshared does seem to work. I put together some test cases here: https://gitlab.com/-/snippets/2114152 It's got the DLL written in D, and test programs for loading it in D, C#, and C++. I haven't done much .NET interop stuff but it seems to work. I'd welcome any recommendations on how to improve the interfaces if there are any, I made a little mixin to create C wrappers for the member functions since that seems to be the suggested solution for calling class methods.
