Re: WildCAD - a simple 2D drawing application
On Thursday, 26 January 2023 at 14:31:55 UTC, Adam D Ruppe wrote: I did see the menus popped up in the wrong place though That at least should be fixed now.
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 22:46:51 UTC, Ali Çehreli wrote:
https://forum.dlang.org/thread/qwixdanceeupdefyq...@forum.dlang.org
I still agree with myself :) in that discussion here:
https://forum.dlang.org/post/tlqcjq$usk$1...@digitalmars.com
BTW, check out another case of D violating the "if in an invalid
state, die" precept. The following code not only runs the
upstream destructor (which depends on successful completion of
the downstream one), but does that in an infinite loop:
struct TransactionFactory
{
Transaction spawnTransaction()
{
return Transaction(0);
}
// depends on all Transactions having been destroyed
~this()
{
assert(Transaction.count == 0);
}
}
struct Transaction
{
static int count;
// the usual "fake nullary constructor" fiddlesticks
this() @disable;
this(int dummy)
{
count++;
}
~this()
{
assert(false); // a failure that leaves the system in an
invalid state
count--;
}
}
void main()
{
TransactionFactory tf;
Transaction t = tf.spawnTransaction;
}
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote: Glad to announce D 2.102.0, ♥ to the 40 contributors. This release comes with support for multiple message arguments in `static assert()`, stack allocated `scope` array literals, a new preview switch to add support for `@system` variables, and many more. Downloads and full changelog are available from the dlang site. http://dlang.org/download.html http://dlang.org/changelog/2.102.0.html -Iain on behalf of the Dlang Core Team Dub changes Binary output will now be in a central cache A welcome change, thanks! Bugzilla 21301: Wrong values being passed in long parameter list Finally fixed, thanks!!
Hipreme Engine is fully ported to WebAssembly
This has been finished for quite a time but I was polishing some features. I'll save this post to 4 things: **Advertise that [Hipreme Engine](https://github.com/MrcSnm/HipremeEngine) is now supporting 5 platforms**, being those: - Xbox Series - Windows - Linux - Android - Browser **1. D development workflow for web**: - The server: The server being employed is **arsd:cgi**, made by Adam D. Ruppe. CGI.d doesn't bring much bloat as vibe.d, specially for its requirements, it was chosen over python for not needing to install anything beyond `dub`. - Debugging: The debug is currently done by using another dub project: **wasm-sourcemaps**, made by Sebastian Koppe. It currently works really well and now it is correctly configured with D. Using the sourcemaps, we can get strack traces when assertions fails, when you access a null pointer, or when some exception is thrown. - Additional tooling? My engine employed some additional tooling for working with filesystem directories as it would greatly simplify the user experience, it is a simple code which generates a JSON representation of your game assets folder. - "Can my PC without any configuration build it?": Yes. Actually the browser is the less strict platform as you don't need any specific SDK. If a full runtime is done one day, it will be one of the easiest platforms to support along windows and linux. **2. D performance on web**: Incredible. This game runs with 5% CPU usage on web, and it still has many optimization opportunities that I didn't run for, such as: - I'm using WebGL 1.0 instead of WebGL 2. You can ask me "but why": more support. The engine itself is prepared enough to support WebGL 2 out of the box, and it could increase the performance by another set of batched calls on the GL site. - What is the slowest part of D? The JS bridge. The bloat is all over there, executing code from the bridge is by a magnitude of 10x slower than a single side code. Thankfully my engine has already dealt with that by every OpenGL call being batched. - Is there collection happening? Nope. The custom runtime in an effort to extend Arsd Webassembly doesn't implements the collection aspect. Although that happens, Hipreme Engine doesn't allocate anything inside the game loop. Which means 0 allocations is actually happening during the game. Although there is still the GC calls made by the game you're doing. But futurely the engine will support scene graphs which can greatly enhance the engine memory control. That means any simple game can be built on it and there are some ways to implement a temporary solution against any kind out of memory for bigger games such as doing timely game saves into browser's local storage and game reloading after some time. **3. How it was to port the game engine**: - If you're checking those errors on the right of the console, they were implemented before web was a thing for my engine. They were using synchronous functions and checking their return value. For Web, my take wasn't using D decoding libraries such as audioformats or arsd:image. For reducing bloat and porting code need, I'm using directly the browser decoding capabilities, which means it is impossible to use sync image decoding with my engine on web. - "How did you solve that then"? I sent to JS code D delegates which would be executed when the web promise was fulfilled. The way I done async loading in my engine was via Threads executing sync code and then returning. So, the user facing API basically didn't change anything, only the engine internals. - "Will I need to change my code between platforms?": Depends. It depends on your game assets loading strategy. The `await` for loading asset functionality does not work on web and it will fail on an assertion. But the game that I show here, uses the same code to run on all platforms. By using the AssetLoadStrategy.loadAll. The Game Engine will use reflection on all modules used by your game to know which assets needs to be loaded before starting the game's entry point. So, you won't need to worry about anything. **4. I want to make a web project without Hipreme Engine, what its custom runtime does not support?**: - Collection - Try/Catch: partial support. Undefined behavior if a throw code is being catched. - static this/~this Excluding static this (which I found no usage within my project), those 2 features are the hardest to support so I didn't get this far. Try/Catch is not being fully supported, but you don't need to remove that syntax from your code. Which means the entire D is being supported to build a project! Here's a sample image of the latest game done by Hipreme Engine running on web: 
Re: LDC 1.31.0-beta1
On Friday, 27 January 2023 at 20:35:01 UTC, kinke wrote: Glad to announce the first beta for LDC 1.31. Major changes: * Based on D 2.101.2. * ImportC: The C preprocessor isn't invoked yet. * mac/iOS arm64: Linking with `-g` is working again without unaligned pointer warnings/errors. * *Preliminary* support for LLVM 15. Thanks @jamesragray for helping out! * Initial ABI support for 64-bit RISC-V. Thanks @Ast-x64! Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.31.0-beta1 Please help test, and thanks to all contributors & sponsors! Nice! Can we have a build for linux-arm (rpi)? The last one is oold :) Andrea
Re: Release D 2.102.0
On Friday, 3 February 2023 at 08:33:26 UTC, Max Samukha wrote: BTW, check out another case of D violating the "if in an invalid state, die" precept. The following code not only runs the upstream destructor (which depends on successful completion of the downstream one), but does that in an infinite loop: [...] Yep, it's a regression: https://issues.dlang.org/show_bug.cgi?id=23164
Re: Hipreme Engine is fully ported to WebAssembly
Congrats! This shows D capabilities, system language that is able to scale from as little as micro controllers to full blown cross platform games including the Web with WASM! That's why it's always important to keep runtime as simple as possible, and the std as minimal as possible, lets you target new platforms with ease! I also ported my engine to WASM, i'll have something interesting to show in the coming months, stay tuned! D playing nice with WASM, that's a strength not many languages have! Let's do more with it!
Re: Hipreme Engine is fully ported to WebAssembly
On Friday, 3 February 2023 at 13:41:35 UTC, Hipreme wrote: This has been finished for quite a time but I was polishing some features. [...] Very cool, thanks for sharing and congratulations on this achievement! Would be curious to learn more about the challenges in supporting Mobile, Desktop, and XBox and now the web.
Re: WildCAD - a simple 2D drawing application
On Friday, 3 February 2023 at 08:30:55 UTC, Johann Lermer wrote: That at least should be fixed now. Confirmed, works here now! BTW I did `time make -j6` this time and it said 10 seconds, so still think the dmd -i approach better but if your incremental builds are smaller it might be better, I did git pull so of course that meant a lot of things were changed anyway.
Re: WildCAD - a simple 2D drawing application
On Friday, 3 February 2023 at 21:05:36 UTC, Adam D Ruppe wrote: BTW I did `time make -j6` this time and it said 10 seconds, so still think the dmd -i approach better but if your incremental builds are smaller it might be better, I did git pull so of course that meant a lot of things were changed anyway. I tried -i as well but ran into a problem with X11 functions that are not defined (I didn't convert every X11 header to D and obviously some dependency is missing - maybe I converted too much for my purpose. I just wonder that you did't run into the same problem. Mysterious...) so for the time being I'd like to focus more on the program than on the build system. But it's only delayed, not forgotten. Btw. about the C libraries, I also tried using the new C header import but failed quite miserably - too many errors with macros and so on. So that is delayed as well.
