Re: `static` on module-level functions
Yes, static on a free-function does not do anything.
```
; [#uses = 0]
; Function Attrs: uwtable
define void @void onlineapp.func()() #0 {
ret void
}
```
```
; [#uses = 0]
; Function Attrs: uwtable
define void @void onlineapp.func()() #0 {
ret void
}
```
Looks identical to me (LDC, LLVM IR).
As for inlining, backends like LLVM will freely inline if they feel it
is a good idea. You don't need to use the pragma, it only overrides the
logic.
`static` on module-level functions
Can anyone point me to a part of the D spec that says what `static` means when applied to functions that are declared at module scope? (Other than module constructors, obviously) I used to assume the property would do something, so I actually used it in a lot of my code when I was first learning D. Now someone I work with who’s newer to the language is now also going through this phase. The assumption of both me and them was that a static module-level function would more-or-less work like a function with `pragma(inline, true)`, which makes more sense if you overlook how `static` usually applies to *functions* and you instead look at how `static` applies to almost everything else: variables (their initialisation is compile-time), `if`, `foreach`, and `assert`. However, I haven’t seen *anything* to suggest that `static` even does anything at all in this case; it also doesn’t give you a compiler error or even a warning, is it like this to make automatic code generation easier, or does it actually do something? Maybe D’s spec could be tweaked to make this a bit clearer? On quite a few occasions I’ve searched for info about this and found nothing relevant. P.S. If it doesn’t actually do anything, I wonder if something like the behaviour of “static import” would be desirable?
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 19:53:39 UTC, Chris Katko wrote: On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote: My program is instrumented with a load of writeflns. At one point it looks as though it suddenly quits prematurely because the expected writeflns are not seen in the output. It could be that I am just reading the flow of control wrong as it goes ret, ret etc. I’m wondering if it is throwing an exception, or has a fault initiating a crash, perhaps even due to the fetching of arguments of one of the writeflns. In my limited experience, exceptions produce an error message though, and I’m not seeing anything. Any advice on how to debug this, silent termination ? I don’t have a debugger on this machine, but on an x86-64 box I could use gdb if I first take the time to work out how. one thing I do is have gdb/lldb break on d assert, before it destroys the stack. That helped me catch a class of bugs. ```sh # in the gdb interface before running break _d_assertp break _d_assert break _d_assert_msg # or to combine it into the commandline: gdb -ex "break _d_assert" -ex "break _d_assert_msg" -ex "run $1" ./main # can also add it to your .gdbinit startup code. This is brilliant advice. I’m building with LDC and in debug mode with -g, however gdb says it can’t find any symbol table or debug info, can’t even set breakpoints by line numbers. The Matt Godbolt Compiler Explorer can go to source line numbers in the asm. So I’m just missing something.
Re: gdc 12.1: undefined references when linking separately compiled files
On Thursday, 6 July 2023 at 22:44:27 UTC, Alexibu wrote:
I just encountered this problem in recently released debian
bookworm (gdc 12.2.0), I was able to fix these undefined
lambdas inside std library with -fall-instantiations, and a
bunch of other undefined lambdas in my own code by changing
template arguments of the form
alias e = (a => a)
to a separate definition
auto (T)default_e(T a)
{
return a;
}
and
alias e = default_e
Using GDC may require rewrite?
I have thought GDC use the same front-end as DMD & LDC?
Re: gdc 12.1: undefined references when linking separately compiled files
On Saturday, 28 May 2022 at 14:44:56 UTC, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you
want most the time.
But I know what's going on now, it is the template emission
thing, the compiler thinks, since it is from std, it was
already compiled somewhere else and skips it but it isn't
actually there so the linker errors.
Using
gdc -fall-instantiations -c parser.d
Might generate it in that parser.o getting it to link. Might
need to be used in all builds but I *think* just here, hard to
say without a test.
I just encountered this problem in recently released debian
bookworm (gdc 12.2.0), I was able to fix these undefined lambdas
inside std library with -fall-instantiations, and a bunch of
other undefined lambdas in my own code by changing template
arguments of the form
alias e = (a => a)
to a separate definition
auto (T)default_e(T a)
{
return a;
}
and
alias e = default_e
First module
I’ve written my first non-trivial module in D. See other thread. https://forum.dlang.org/thread/pfjpqcywxrmxwsncy...@forum.dlang.org I’d like to set up something to call it from other modules, and specifically I’d like to see if inlining works across module boundaries - I have no idea whether it does or not as I don’t understand fully in detail how module imports work. How do I go about setting up such a test harness with LDC (or GDC) on either OSX/ARM or Linux Debian x86-64? I’m not sure what tools I need. Note that I cannot use DMD, this code is LDC/GDC-specific. LDC would be my preference as that is what it is ultimately aimed at.
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote: My program is instrumented with a load of writeflns. At one point it looks as though it suddenly quits prematurely because the expected writeflns are not seen in the output. It could be that I am just reading the flow of control wrong as it goes ret, ret etc. I’m wondering if it is throwing an exception, or has a fault initiating a crash, perhaps even due to the fetching of arguments of one of the writeflns. In my limited experience, exceptions produce an error message though, and I’m not seeing anything. Any advice on how to debug this, silent termination ? I don’t have a debugger on this machine, but on an x86-64 box I could use gdb if I first take the time to work out how. one thing I do is have gdb/lldb break on d assert, before it destroys the stack. That helped me catch a class of bugs. ```sh # in the gdb interface before running break _d_assertp break _d_assert break _d_assert_msg # or to combine it into the commandline: gdb -ex "break _d_assert" -ex "break _d_assert_msg" -ex "run $1" ./main # can also add it to your .gdbinit startup code. ```
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote: In my limited experience, exceptions produce an error message though, and I’m not seeing anything. Any advice on how to debug this, silent termination ? If unsure on cases like this, test. Intentionally throw an exception and don't catch it, what happens? Same for any other way of termination you're suspecting.
Re: Compiling to RiscV32
On Wednesday, 5 July 2023 at 17:00:53 UTC, HuskyNator wrote: Using a simple single '.d' file with no imports: `Error: cannot find program 'cc'` I haven't tried to compile to RiscV32, nor do know how it works. But this reads like LDC is not finding the C compiler it's trying to use. LDC uses a C compiler to call the linker, instead to calling the linker directly.
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 07:09:11 UTC, Richard (Rikki) Andrew Cattermole wrote: On 06/07/2023 7:07 PM, Cecil Ward wrote: On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) Andrew Cattermole wrote: 2 Recommendations: 1. Attach a debugger 2. Make sure to flush stdout whenever you write I assumed that buffering was to blame. How do I flush stdout? stdout.flush; https://dlang.org/phobos/std_stdio.html#.stdout Many, many thanks once again.
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. To be honest, I'm accepting anyone on Hipreme Engine that is willing to help adding a shader transpiler or cross compiler. Right now I got an abstraction over opengl, direct3d and metal, for almost every basic stuff out there, which is really simple. Having the shaders being written once is pretty much the next step but I can't focus on that. You'll have a better experience with Hipreme Engine than mostly of the options you get here since you'll have a complete cross compilation env for you requiring no configuration at all.
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. There is a Hipreme Engine (written in D): Check it out on the GitHub: https://github.com/MrcSnm/HipremeEngine
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) Andrew Cattermole wrote: 2 Recommendations: 1. Attach a debugger 2. Make sure to flush stdout whenever you write I assumed that buffering was to blame. How do I flush stdout? I moved to an x86-64 box. I was using my ARM M2 Mac for which I have no debugger. There must be one somewhere though. I got a visible crash on the x86 machine, array index off the end by one, so I attached gdb and saw the bug. Yay! I’m not sure why there was no crash error message on the ARM Mac though. I had the array length wildly wrong. I then fixed the offending code that was doing the accounting wrongly.
Re: Advice on debugging possible exception or crash
On 06/07/2023 7:07 PM, Cecil Ward wrote: On Thursday, 6 July 2023 at 06:17:34 UTC, Richard (Rikki) Andrew Cattermole wrote: 2 Recommendations: 1. Attach a debugger 2. Make sure to flush stdout whenever you write I assumed that buffering was to blame. How do I flush stdout? stdout.flush; https://dlang.org/phobos/std_stdio.html#.stdout
Re: Advice on debugging possible exception or crash
On Thursday, 6 July 2023 at 06:00:04 UTC, Cecil Ward wrote: My program is instrumented with a load of writeflns. At one point it looks as though it suddenly quits prematurely because the expected writeflns are not seen in the output. It could be that I am just reading the flow of control wrong as it goes ret, ret etc. I’m wondering if it is throwing an exception, or has a fault initiating a crash, perhaps even due to the fetching of arguments of one of the writeflns. In my limited experience, exceptions produce an error message though, and I’m not seeing anything. Any advice on how to debug this, silent termination ? I don’t have a debugger on this machine, but on an x86-64 box I could use gdb if I first take the time to work out how. Just some advice on if you're spawning threads, you should try and catch exceptions and errors at the top-most level and log them, otherwise they'll just vanish as the thread dies.
Re: Options for Cross-Platform 3D Game Development
On Wednesday, 5 July 2023 at 22:27:46 UTC, Andrew wrote: So, I've gotten the itch to have a go at game development in D, after doing a bit of it in Java last year. I've previously used LWJGL, which is a java wrapper for OpenGL, OpenAL, GLFW, and some other useful libs. The problem is, apparently OpenGL is deprecated for apple devices, so I don't really want to use that unless there are no decent alternatives. So far, the most promising I've seen is [bindbc-bgfx](https://code.dlang.org/packages/bindbc-bgfx), but it's been a pain to set up due to having to build the bgfx codebase, which requires a specific version of glibc that my distro (Linux Mint) doesn't offer yet. Are there any other recommendations for cross-platform rendering libraries? Of course I could use a pre-made game engine like Unity or Godot, but for me, most of the fun is in making the engine. Are you trying to make a PC game, or a mobile game? Because in 99% of cases I would pick a different toolchain for mobile than PC. OpenGL being depreciated on a single, walled-garden platform, does not rule it out for the entire rest of installed systems. Only if I absolutely needed, cross-platform out-of-the-box with mobiles and PC, would I pick a package like, Xamarin. Which now forces me to use C#, and the size bloat of including a mono framework with all my apps. I would not pick Xamarin just because I wanted to keep my options open, I would d pick it because I have a planned application that needed to be 1:1 synced across iPhone, Android (and possibly PC). There's also other options. Such as using a OpenGL -> Metal conversion layer, like MetalAngle: https://github.com/kakashidinho/metalangle https://chromium.googlesource.com/angle/angle So be sure exactly what you want as the best tools for the job will depend greatly on the requirements of the project.
Re: Advice on debugging possible exception or crash
2 Recommendations: 1. Attach a debugger 2. Make sure to flush stdout whenever you write
Advice on debugging possible exception or crash
My program is instrumented with a load of writeflns. At one point it looks as though it suddenly quits prematurely because the expected writeflns are not seen in the output. It could be that I am just reading the flow of control wrong as it goes ret, ret etc. I’m wondering if it is throwing an exception, or has a fault initiating a crash, perhaps even due to the fetching of arguments of one of the writeflns. In my limited experience, exceptions produce an error message though, and I’m not seeing anything. Any advice on how to debug this, silent termination ? I don’t have a debugger on this machine, but on an x86-64 box I could use gdb if I first take the time to work out how.
