Re: Sokol now has official D bindings
On Tuesday, 14 May 2024 at 12:36:27 UTC, ryuukk_ wrote: It'll be interesting to know what the experience was for the maintainer to play around with D (for the first time?) From what i could gather, problems encountered: - rvalue ref params (wich led to someone telling him to use -preview=all wich led to other issues) - attributes soup - float nan default - no warning on use of uninitialized floats I think it is time to decide what to do with all these -previews, rvalue ref params should be a feature already imo Yep, i think it was there long enough already so rvalue ref parameters should already be in. Also what's with this `in` const parameters transition, it just like umm hanging in there for years?
Re: Is D programming friendly for beginners?
On Monday, 4 March 2024 at 13:37:53 UTC, Fidele wrote: I want to start learning D programming language it looks interesting Answering thread question: It can be complicated, D has a lot of features and mastering it will take quite a lot of time. Since D is statically typed compiled system programming language it is still will be harder to grasp than say Python. The core language is pretty neat and shouldn't cause much trouble, by core here I mean basic templates, basic mixins, basic classes and operator overloading, version conditioning and such. Ranges and the standard library approach to "Design-by-Introspection" will definitely require some time to get used to, so expect to dive into std sources a lot for real world examples. Advanced templates is still not as hard as C++ though, and there is no some of the more quirks that C++ has. Few things to avoid until you absolutely know what you are doing is @nogc and betterC. There is also a "system" part in it that ultimately will require you to understand what is actually a executable file and what is a linker, knowing how to use debuggers, etc... Finally, D is flexible enough to delay touching some of those features until you are ready, and unlike practically any other language it doesn't forces any philosophy or zen or whatever ideology on you. Before you started though - note that D is not considered "enterprisey" enough language so don't expect your favorite JetBrains IDE or other fancy tooling, the debuggers are just minimally working, and generally any other ecosystem tools (if any) too. This means you have to understand more about how these things works and this may add extra complexity and make you think the whole language is not there yet.
Re: implicit-context v0.0.1
On Saturday, 30 September 2023 at 12:40:29 UTC, Guillaume Piolat wrote: On Friday, 29 September 2023 at 16:56:47 UTC, Imperatorn wrote: Sounds a bit like dependency injection but for state Possibly, I'm not familiar with dependency injection. When is it useful? Dependency injection is a principle of making your classes/functions self-contained and isolated, it means that when your code might need to create a resource (such as open a file to write data) it is instead up to the caller to provide that resource, but your code never does that by itself because a library can't possibly know the environment and restrictions of the target system/machine. Simply put, you can't possibly know how to open a file in that system, you can't possibly know what allocator is used in the caller environment (think about very low-level or bare metal program), and so on, so instead caller must provide everything that your function/method/class might need to do the work. In the most complex situations where the entire program graph is about to be created in the main function there is so called DI containers that configures all this stuff in one central place.
godot-dlang v0.2.0
# Release godot-dlang v0.2 This release includes support for Godot 4 RC ## What is godot-dlang? godot-dlang is a wrapper over Godot engine scripting API using new native extensions feature, simply put you can now extend engine using native code in a shared library form. ## What it can be used for? Games primarily, 2d games, 3d games, large-scale open world games... But wait, because Godot includes various multimedia features and has a very rich GUI toolkit you can use it to build any kind of multimedia apps, use it as a GUI for your programs, build simulation programs, and much more! ## What is Godot? Godot is a modular open source game engine with permissive license (MIT). Godot 4 is the latest version of Godot is now entered stabilization phase, it still might have some API changes before release but otherwise it is now a good time to start new projects, final 4.0 release can be expected within 1-2 months. ## Where to get Godot? (scroll down to downloads section, use standard build if you don't plan to mix godotscript/C#/D) https://godotengine.org/article/release-candidate-godot-4-0-rc-5/ ## Where to get godot-dlang? godot-dlang source code https://github.com/godot-dlang/godot-dlang also available in dub https://code.dlang.org/packages/godot-dlang
Godot 4 beta-4 released
Godot is an open source 2d/3d game engine has just released new beta version! https://godotengine.org/article/dev-snapshot-godot-4-0-beta-4 Godot-d is a bindings for Godot, latest official release is for Godot 3 only, however here is a WIP branch for Godot 4 latest beta-4. https://github.com/Superbelko/godot-d/tree/godot4 Original godot-d issue on GitHub about Godot 4 support https://github.com/godot-d/godot-d/issues/83 For getting started see this document https://github.com/Superbelko/godot-d/tree/godot4#godot-4-branch-getting-started-mini-guide Currently godot4 branch is purely experimental WIP project as stated in the document, so do not expect to ship real product with that, even more nor Godot 4, nor godot-d is not ready for that.
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 10:08:50 UTC, meta wrote: On Wednesday, 9 March 2022 at 09:04:03 UTC, Martin Nowak wrote: Glad to announce D 2.099.0, ♥ to the 100 contributors. This release comes with __traits(parameters), unittests only from root modules, throw expressions, and plenty of more changes. http://dlang.org/download.html http://dlang.org/changelog/2.099.0.html -Martin The download links doesn't work.. I get access denied, what is happening? Are CI/CD builds available somewhere? on GitHub? it seems like upload script error, download link is https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2021/dmd-2.099.0.exe but if you change it to (notice 2022 instead of 2021) https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.099.0.exe it now works
Re: DQt: Qt bindings using extern(C++)
On Saturday, 11 December 2021 at 00:47:56 UTC, LorenDB wrote: On Friday, 10 December 2021 at 17:38:56 UTC, Tim wrote: I have not released the converter yet. It is currently not very user friendly and needs many manual changes to the result, which I want to improve. It also has Qt specific parts. I will definitely be watching for the release of the converter code! For generic C++ code you can try my generator (yes it does code conversion, not just signatures), it handles like 80% of the job, the rest 20% is manual fixing signatures and code here and there, however newer C++ features is not yet covered. https://github.com/Superbelko/ohmygentool
Re: dmdtags 1.0.0: an accurate tag generator for D source code
On Friday, 27 August 2021 at 22:45:15 UTC, WebFreak001 wrote: I'm just worried about how the memory usage will grow with this, considering dmd never frees. Still not sure if it *should* be used in same process, but DMD definitely has -lowmem switch for turning on GC, and for DMD as a library there is initDMD() and deinitializeDMD() pair. Haven't tested it myself wrt. to memory usage, but it is used by DMD tests. Another concern would be code analysis time, even with skipping semantic passes every run is a new invocation - DMD simply wasn't designed to be a language server where it could just iteratively update compilation database. IIRC VisualD with DMD frontend enabled has noticable long pauses on showing completion (from 100ms to few seconds on larger projects), which renders it unusable for me. Could be that same reason, no idea.
Re: LDC 1.27.0-beta3
On Thursday, 15 July 2021 at 11:58:28 UTC, Guillaume Piolat wrote: On Thursday, 15 July 2021 at 02:54:14 UTC, rikki cattermole wrote: Will -fvisibility=public support be upstreamed into dmd? If yes, it might be worth it to get rid of export as a keyword Please, no. -fvisibility=public doesn't work in all cases in our experience. And there is also DLL export limit on Windows which 65k symbols, yay.
Re: [Semi-OT] Cross-Platform GitHub Action
On Wednesday, 9 June 2021 at 14:05:33 UTC, Steven Schveighoffer wrote: On 6/9/21 6:49 AM, Steven Schveighoffer wrote: On 6/9/21 4:17 AM, evilrat wrote: Just a note from terms of service: you get 2000 minutes available for Github Actions every month for free, however for using Windows hosts it takes 2x minutes and Mac hosts takes 5x minutes. I think this only applies to private repositories: Confirmed: https://github.community/t/for-public-repositories-is-there-a-monthly-limit-on-minutes/129017 -Steve Ok then, good to know. Must be overly paranoid ToS checking kicked in :(
Re: [Semi-OT] Cross-Platform GitHub Action
On Wednesday, 9 June 2021 at 05:20:14 UTC, Jacob Carlborg wrote: On Tuesday, 8 June 2021 at 19:40:01 UTC, kinke wrote: Thx for sharing! Interesting; I've recently worked on something similar, but on Linux hosts and using a kvm/qemu/libvirt stack for running CI jobs in Windows VMs. Yeah, this is running on macOS instead because the Linux and the Windows runners on GitHub actions don't support nested virtualization. Just a note from terms of service: you get 2000 minutes available for Github Actions every month for free, however for using Windows hosts it takes 2x minutes and Mac hosts takes 5x minutes.
Re: (Oh My) Gentool 0.4.0 released
On Monday, 7 June 2021 at 10:15:28 UTC, evilrat wrote: On Monday, 7 June 2021 at 09:45:53 UTC, Andrea Fontana wrote: On Sunday, 6 June 2021 at 10:03:11 UTC, evilrat wrote: ## (oh my) gentool v0.4 is now out. It is my fancy tool to generate extern(C++) stuff quicker, it takes regular compiler flags that you usually pass to clang and translates C/C++ code to D. This release has one new feature: support pragma mangle on aggregates (class, struct, etc...). Also a lot of work was put into template support, but it is still has lots of unhandled cases, so do not expect it will translate STL or Boost without need of manual fixes. Source https://github.com/Superbelko/ohmygentool Windows binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.4.0 Nice work. Is there a docker somewhere in order to test it? Added image to dockerhub https://hub.docker.com/r/superbelko/gentool Get it using `docker pull superbelko/gentool` How to use https://github.com/Superbelko/ohmygentool/wiki/Docker
Re: (Oh My) Gentool 0.4.0 released
On Monday, 7 June 2021 at 09:45:53 UTC, Andrea Fontana wrote: On Sunday, 6 June 2021 at 10:03:11 UTC, evilrat wrote: ## (oh my) gentool v0.4 is now out. It is my fancy tool to generate extern(C++) stuff quicker, it takes regular compiler flags that you usually pass to clang and translates C/C++ code to D. This release has one new feature: support pragma mangle on aggregates (class, struct, etc...). Also a lot of work was put into template support, but it is still has lots of unhandled cases, so do not expect it will translate STL or Boost without need of manual fixes. Source https://github.com/Superbelko/ohmygentool Windows binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.4.0 Nice work. Is there a docker somewhere in order to test it? It's got a dockerfile few days back, though I haven't tried it myself yet. (SSH port at end is for IDE's) https://github.com/Superbelko/ohmygentool/blob/master/Dockerfile.local-dev It detects standard library includes automatically, but if you're going to cross compile you'll have to tell it where to look, also probably need to pass proper target triple.
Re: (Oh My) Gentool 0.4.0 released
On Sunday, 6 June 2021 at 10:38:22 UTC, sighoya wrote: On Sunday, 6 June 2021 at 10:03:11 UTC, evilrat wrote: ## (oh my) gentool v0.4 is now out. It is my fancy tool to generate extern(C++) stuff quicker, it takes regular compiler flags that you usually pass to clang and translates C/C++ code to D. This release has one new feature: support pragma mangle on aggregates (class, struct, etc...). Also a lot of work was put into template support, but it is still has lots of unhandled cases, so do not expect it will translate STL or Boost without need of manual fixes. Source https://github.com/Superbelko/ohmygentool Windows binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.4.0 +1 How did you parse C++ code which seems overkill to do alone. Did you enact clang for? Yes, it's all clang under the hood. But it's not just clang tooling that uses pre-made Tool class that has to be invoked as part of clang itself using special flag. Instead it creates compiler instance and runs regular compilation pass in memory extracting declarations recursively (as part of older pipeline, can be done to some extent using C API with cursors), and then it converts C++ AST to D source code with minimal AST manipulation (can't be done with C API), though I'm looking into AST-to-AST translation instead and then using D compiler frontend to emit source code for better result.
(Oh My) Gentool 0.4.0 released
## (oh my) gentool v0.4 is now out. It is my fancy tool to generate extern(C++) stuff quicker, it takes regular compiler flags that you usually pass to clang and translates C/C++ code to D. This release has one new feature: support pragma mangle on aggregates (class, struct, etc...). Also a lot of work was put into template support, but it is still has lots of unhandled cases, so do not expect it will translate STL or Boost without need of manual fixes. Source https://github.com/Superbelko/ohmygentool Windows binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.4.0
Re: Release D 2.097.0
On Saturday, 5 June 2021 at 10:19:47 UTC, Martin Nowak wrote: Glad to announce D 2.097.0, ♥ to the 54 contributors. This release comes with a new `std.sumtype` packcage, support for `while (auto n = expression)`, an overhauled formatting package, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.097.0.html -Martin Windows installer is broken. I have install target path excluded from Windows Defender anti virus checks, yet after the installation it only contains .bat files, uninstaller.exe, dmd2/windows/lib64 and lib32mscoff, but no bin and sources.
Re: Release D 2.097.0
On Saturday, 5 June 2021 at 10:19:47 UTC, Martin Nowak wrote: Glad to announce D 2.097.0, ♥ to the 54 contributors. This release comes with a new `std.sumtype` packcage, support for `while (auto n = expression)`, an overhauled formatting package, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.097.0.html -Martin Nice release. https://dlang.org/changelog/2.097.0.html#pragma-mangle-aggregate Does this means we will get more STL goodies soon?
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? I think: "license": "proprietary" also doesn't sound very inviting It's a WIP tutorial project. It is not finished yet. It needs more details where needed and have everything re-checked. Any suggestions license-wise ? zlib, Boost, BSD/MIT, anything will do, its just the GPL itself. I don't think it is allowed to copy-paste any part of it at all. Licensing is pain and I usually avoid it, so please refer to special web sites that will help pick the license that suit your intentions. Or at least make it LGPL so it is possible to be used as a library without licensing headache.
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying configuration for build. See this https://github.com/Superbelko/android-sdl-d/blob/master/dub.json P.S. No idea why you choose GPL, I usually don't bother with GPL libraries because of license, and I think this is also the majority of people on this forum.
Re: (Oh My) Gentool 0.3.0 released
On Sunday, 9 May 2021 at 19:35:52 UTC, Gavin Ray wrote:
**However, I had an idea which I haven't seen tried yet, and
have been prototyping:**
- Using `cppyy` in Python (which uses `cling`) for runtime
bindings to C++ and ability to write raw C++ code in Python
strings and JIT compile it.
- Allow users to write "drivers"/"clients" in Python which do
the codegen. Since Python isn't compiled, this means you can
realtime tweak and visualize your output much faster than
manually recompiling a C++ based LibTooling application.
I am thinking of some kind of API where you can declare rules
using annotations for AST nodes above functions for handling
them. Something like:
```py
class DCodegen:
# "t" here is a LibTooling AST node and we can use all of
Clang/LibTooling's AST API
@rule(lambda t: t.is_pointer() or t.is_reference() and \
t.pointee().is_record_indirection())
def input(cls, t, args):
return f"{{interm}} = &{c_util.struct_cast(t,
'{inp}')};"
@rule(lambda t: t.is_pointer() or t.is_reference())
def input(cls, t, args):
raise ValueError("unsupported input pointer/reference
type {}".format(t))
```
This would allow people to contribute or tweak the codegen to
their liking very rapidly.
It's all libclang under the hood though. Never looked at the
sources of cppyy or cling, but very likely this works for them
because of libs such as pybind11 that wraps C++ stuff in C++,
while the other tools trying to rely on C API(very limited) or
keep fighting with C++ API, you've already seen that all that
tools from that list except gentool is using C API and what
capabilities each provides.
Can't say I hate that idea, but it has same issues as SWIG,
writing any non trivial rule becomes next to impossible as there
is practically zero examples and very poor documentation, the
whole process becomes trial and error marathon without chance to
win, and it is basically write-only code that is as worse as C++
templates. But it is definitely better than SWIG in that regard
as you can get type and functions information using dir() and
help() and your trusty IDE with debugger.
My current plan though is to provide predefined pre-generate and
post-generate rules that is applied declaratively in project
config,
for example
`ignoreDecls *::new[]`
that will ignore all new operator overloads in any namespace, or
one of any other existing rules that deals with specific
patterns, and at some point later allow users to write their own
rules like you described.
After all this is binding/translator tool, not an universal
one-for-all code generator.
For distribution, it could be done in an Ubuntu Docker
container that comes with LLVM and Python in it, and the
scripts, then mapped to local filesystem for read access + also
if you want to edit the `DCodegen` script or supply your own
Python file as the driver.
No way, Docker is too heavy and not very user friendly or even CI
friendly. It is ok to have builds optionally packed in container,
but not as the only way to distribute. It might work for
cppyy/cling because they rely on specific dynamic library
properties or fork process on *NIX that is not there on Windows.
Re: (Oh My) Gentool 0.3.0 released
On Friday, 7 May 2021 at 18:17:36 UTC, Jacob Carlborg wrote: On 2021-05-05 13:54, user1234 wrote: Thanks for the explanations. BTW I had the same question for LDC backend being c++, I guess the answer would be similar. If I understand correctly, the Zig compiler is implemented partially in Zig. It use the LLVM C API and some wrappers C around the C++ API where the C API is not sufficient. And it quickly becomes insufficient using only the C API as feature complexity increases. No idea if Zig has to deal with C++ compiler (clang) or all it needs is pure LLVM, because the latter should have more or less feature rich C API, unlike clang that deals with C++ and has ever "unstable" API. Making wrappers for missing parts still will be a PITA, as having to pass around smart pointers definitely does not makes it easier. Anyway like I said, for bootstrap goal it is probably easier to re-purpose the tool to make thin wrappers & stubs on C++ side, pretty much just like SWIG does. Side note: But all this does not compares to what potential D to nextgen-language bindings making process would look like, as D feature set makes it even harder to translate, esp. stuff like templates and CTFE, now add static if's to that and it becomes a real mess.
Re: (Oh My) Gentool 0.3.0 released
On Wednesday, 5 May 2021 at 10:35:23 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 5 May 2021 at 10:01:13 UTC, user1234 wrote: I have a technical question about the tool itself. It is mostly written in cpp. Oh dear! Isn't it possible to use it to translate itself into D? To answer both: clang has lots of templates, sometimes not so trivial ones, its code base filled with C++ constructs that does not have nice one to one translation(or simply a C++ specific detail like alignment), and the most annoying part - it has various 'tables' generated as a build step that is a mix of external tools and macros. Basically every template will need some care, likely it will be easier to just emit C++ stubs that will force compiler to emit actual code to link with than trying to translate them. So no, not currently possible. Definitely not an unpaid job, well I'll still reject it even if it is paid one. Maybe some time in future, but for now there is a lot more priority stuff to do before even attempting this.
(Oh My) Gentool 0.3.0 released
(Oh My) Gentool - Yet another C/C++ binding generator. It is a tool to convert C/C++ code to D usable form. It takes JSON config, basically all C++ compiler flags and switches, and outputs extern(C++) declarations, (hopefully) in usable form D! It can already process (dear) imgui library (immediate mode GUI popular in game development and various graphics related tools and demos) without manual fixes! It can process recastnavigation (navmesh generation and pathfinding library) with just a few manual edits. Please note that it is still in its early stage and may contain bugs and missing language features, as well as lack of conversion for certain language constructs. It is still hard to use it directly in the build process on a real libraries due to many syntax and semantics issues, however it is already a valuable tool for making thin wrappers on C++ side to quickly bring them to your D code, given that your wrapper headers does not contains complex bodies or templates, or direct inclusions of other libraries headers such as Boost(ok, no STL too). That's it, even if it produces incomplete translation this could reduce bindings making process from hours down to minutes! Who wants to spent 10 hours manually making bindings for entire PhysX when it can be reduced to just 30 minutes? Absolutely no one! Grab one today and stay ahead of your competitors with regular updates! How to start https://github.com/Superbelko/ohmygentool/wiki/QuickStart Source https://github.com/Superbelko/ohmygentool Windows build https://github.com/Superbelko/ohmygentool/releases/tag/v0.3.0
Re: (Oh My) Gentool 0.1.0
On Thursday, 15 April 2021 at 13:36:00 UTC, Imperatorn wrote: https://forum.dlang.org/post/kofkrulquprdedolc...@forum.dlang.org On Saturday, 2 February 2019 at 09:41:42 UTC, evilrat wrote: (Oh My) Gentool - Yet another C/C++ binding generator. This release has few changes and tweaks, the most important one is the ability to process templated functions/methods on Windows and reduction of missing linker symbols numbers. [...] Why haven't I heard of this? I haven't been that active for quite long time, and I didn't write announces that often. After first public release I estimated popularity, and it seems only 3-5 people have interest in such stuff, assuming 1k active forum users that reads it on every day basis it seems there isn't that much people who has any touch on making C++ bindings, D/C++ interop, or anything related. But I still do major release announcements anyway.
Re: I'm creating a game purely written in D with the arsd library
On Saturday, 2 January 2021 at 19:10:59 UTC, Murilo wrote: I also don't want anyone stealing my idea. Too late. You already posted it. Technically anyone could "steal" it from now.
Re: DLS deprecation
On Tuesday, 7 April 2020 at 19:12:49 UTC, Laurent Tréguier wrote: So today, I am deprecating DLS, along with its editor extensions. I've used it over a year, and unlike code-d it just works. Thank you for your hard work and good luck!
Re: Release D 2.091.0
On Tuesday, 10 March 2020 at 13:24:41 UTC, Martin Nowak wrote: This release comes with 64-bit Windows binaries, improvements on C++ integrations Wow, this is awesome, will check it out later. Thank you guys for hard work.
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 01:05:53 UTC, H. S. Teoh wrote: ... I hate SFINAE. But.. But D doesn't have it!11 NOOO!!1!
Re: Release D 2.084.1
On Sunday, 10 February 2019 at 19:21:10 UTC, Martin Nowak wrote: Glad to announce D 2.084.1, ♥ to the 6 contributors. For some reason Windows installer is not signed, UAC shows this warning screen and there is no publisher specified.
(Oh My) Gentool 0.1.0
(Oh My) Gentool - Yet another C/C++ binding generator. This release has few changes and tweaks, the most important one is the ability to process templated functions/methods on Windows and reduction of missing linker symbols numbers. Please note that it is still in its early stage and may contain bugs and many missing language constructs, as well as lack of conversion for certain language constructs. It is still hard to use it directly on a real libraries due to many syntax and semantics issues, however it is already a valuable tool for making thin wrappers on C++ side to quickly bring them to your D code, given that your wrapper headers does not contains complex bodies or templates, or direct inclusions of other libraries headers. How to start - https://github.com/Superbelko/ohmygentool/wiki/QuickStart Code https://github.com/Superbelko/ohmygentool Binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.1.0
(Oh My) Gentool 0.0.3
(Oh My) Gentool - Yet another C/C++ binding generator. I'm glad to announce the new release - version 0.0.3 is now live. Though I have to release it earlier than I would like to, and there is some features I haven't finished, overall I'm ok with how it did. This release will be the last point zero release. The last 3 months I was working on this project, it helped me to trial and error various approaches and helped to understand possible issues and workarounds. For next release I plan to do partial re-write, which should also address performance - right now it is single-threaded, and running the tool for example on clang will take hours! (don't try this at home, it will crash) How to start - https://github.com/Superbelko/ohmygentool/wiki/QuickStart Code https://github.com/Superbelko/ohmygentool Binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.0.3
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Wait, no word about ref parameters? No way! If you try to bind to typical C++ code they are *EVERYWHERE*, add to that inability to make ref variable(well, it can be mimick'd by wrapping in a helper function but it still sucks) and it completely destroys the usability. In its current form ref in D is PITA... When it comes to C++ interop unfortunatelly it is too much left to wish
(Oh My) Gentool 0.0.2 released
(Oh My) Gentool - Yet another C/C++ binding generator. Comparing to previous release there is a whole load of improvements in nearly all aspects, it is still in its early stage though. Much cleaner output with less garbage comparing to last release. If you used previous version and it was sucks, give it a second try, it should suck much less now! There is still lot of issues and quirks, some execution paths have hard-coded features, such as integer-to-poiter (0 to null) replacement works in parameters but not in inlined code. Some template heavy libs is not yet usable, such as FBX SDK. And so is Bullet3, it uses too much highly C++ specific stuff and optimizations, need more work to make it usable. Quick stats (library/generated lines): Bullet3 - 45k + 1.8k mangled names(wow) UNUSABLE FBX SDK 2017 - 32.5k UNUSABLE (dear) ImGui - 2.7k PhysX 3.3.4 - 15k (not tested, but seems valid after fixes) libuv - 3k recast/detours - 2k ultralight v0.9 - 2.3k (note though most of this is not tested so these stats are just random numbers of possibly broken garbage. And so one can draw the line, anything above 15k generated locs is unusable yet.) Only imgui is actually tried, works after a bunch of fixes, templates not tested though. How to start - https://github.com/Superbelko/ohmygentool/wiki/QuickStart Code https://github.com/Superbelko/ohmygentool Binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.0.2
Re: Oh My Gentool [v0.0.1] (Yet another binding generator)
On Saturday, 27 October 2018 at 16:55:23 UTC, Atila Neves wrote: On Tuesday, 23 October 2018 at 20:32:29 UTC, Andrea Fontana wrote: On Tuesday, 23 October 2018 at 20:03:42 UTC, Atila Neves wrote: We do - it's just very far from being complete. dpp can do some simple C++ and would have been able to do C-with-classes-style C++ ages ago. My focus is on templates though, since for me I can't see any useful C++ libraries that I'd actually want to call from D that don't use templates. And sometimes it's as silly as wanting to bind to an existing not-that-complicated library that happens to have a std::vector in its structs. For that, you need to be able to translate the standard library. Interesting. I'm using it for many different c libraries but I didn't think it worked for c++ already! The only problem I found with DPP is that simple consts declared with #define are not translated if not explicitly used. I think i can understand the reason (macro evaluation, I guess) but it would be useful to have a way to export them if they are simple consts... The whole idea of dpp is to be able to use headers as they are used in C and C++. Macros there don't exist unless they're expanded, so it's the same thing with dpp. Maybe it's good idea to add a runtime flag to translate non-function-like macros as enums... hmm. My tool already does simple value-macro extraction, I also thinking about replacing macro with shortcut-to-self(see below) so in AST it will look like a function call, then the user can convert the macro itself to a template or mixin, so this way the code can be preserved more or less as-is. Though I don't have exact date or plan. ``` #define REG_FN(A) gContext->reg(#A) ... // somewhere in code REG_FN(sum); ``` So in this trivial example REG_FN will be preserved in code as written. This way in more complex cases, such as whole class creation with macro, it should be possible to retain that information. But again this will require studying, it might sound useful in theory, however bindings is done for a specific conditions, and so whether it is really useful or not is an open question.
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 11:54:47 UTC, WebFreak001 wrote: fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message. I wouldn't be complaining if it's not the case. With normal code-d it does remove everything in %appdata%/code-d on start, re-setting config paths(even though for exapmle dub is in PATH), downloading git repo, fails to build, and repeat, while with beta there is no such issues. I would also suggest you to add explicit --compiler=dmd switch to build invocation since for example in my case dmd was in PATH env after ldc and so ldc used by default, which of course doesn't have x86_mscoff arch. I also think it is probably better to add --build=release too, since users usually don't do debug on that binaries. What about workspaces? Let for exapmle have main project (really just a dub project with single app.d for testing library) and library project in one workspace. I don't get any autocompletion from both projects. It also doesn't seems to work with dependency that has path property set, at least not when it's relative. Is this ok?
Re: DirectX bindings
On Friday, 23 June 2017 at 13:31:04 UTC, Petar Kirov [ZombineDev] wrote: Hi evilrat. That's unfortunate to hear. I would to suggest a way forward. What do you think about joining dlang-community [0] [1]? That way: * You remain an owner of your repo, so you can continue to develop it if/when you decide to do so. * Other members of the community would be able to merge PRs with fixes and enhancements. * Most importantly, we're going to ensure that library continues to compile with every new compiler release, even if you're not around to help with that. Since DirectX is one of the most widely used APIs for graphics and game development on Windows, I think it is important for D to have a set of well supported bindings. [0]: https://github.com/dlang-community [1]: http://forum.dlang.org/post/sgzxolfspoqnueebm...@forum.dlang.org I consider this as an option, if no other solution comes I'll try this in early July. However my message was due to reason, very specific one - the programming. I have enough of it! Thats it, I'm leaving. I'm now packing my stuff and will be unavailable for year or so. This means its a temporary solution, beacause sooner or later community will had to replace/configure my old dub package anyway.
Re: DirectX bindings
On Friday, 23 June 2017 at 11:34:34 UTC, John Burton wrote: Ah... Well thank you for your work on this up to now. I was just looking at these bindings a few days ago, considering if I should use C++ or D for a little hobby graphics projects I wanted to look at, and thought I'd maybe use this. I'm hoping there is an alternative if this is deleted. You still could use it, for example clone the repo to your project directory and set relative dub dependency path in the project, should work just fine.
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d I'm sorry to say that, but I have to quit the post of DirectX bindings maintainer. I haven't yet decided on what to do with dub package[1], but I'm in favor of completely deleting it so the next maintainer or D foundation can step in, that way there should be little to no code breakage occurs and most users won't even notice a change. My current estimate is to drop it till the end of month. I will probably continue to maintain github repository for few months for my personal needs though. [1] http://code.dlang.org/packages/directx-d
Re: two points
On Thursday, 9 February 2017 at 08:02:23 UTC, Walter Bright wrote: I do not understand using pseudonyms on github. It can hardly be a privacy issue, as github doesn't hide your name. But it definitely impedes your "brand", i.e. your reputation, as it becomes divided in two. Github does not provide a "reverse phone book" where I can search for a PR under your name, nor does it provide any sort of cross reference. Searching (via github) the dmd repository for your name turns up nothing. One of the reasons could be simply because one is known under a nickname on a bunch of other resources where he posts to, and that now working for the reputation too - because posting something with other name could get you banned or just people looking with suspicious for any code and links posted. Now, since we on D forum and that "other" world reputation doesn't matter here or any other reasons, some will prefer just using "real" name. Some people also avoid using their work-associated emails with personal/fan projects. Because of same thing with reputation/proffesionalism/etc., (unnecesary questions from employer too? just a guess, whatever) And more, and more... Things are complicated.
Re: Release D 2.073.0
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote: Glad to announce D 2.073.0. This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes. http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html -Martin Can we have some love for Windows COM and extern C++ ABI regarding return struct by value for next release, please? I mean there is already few bug reports[1,2] on that matter. For example when return struct with 2 floats first one goes to ECX, second to EDX, DMD got only the second one. In x64 it is even worse, in most cases it just crashes. And LDC crashes in both x86/x64, so... can't use D at all. It is a real blocker which prevents from using D in some areas, like DirectX (for example Direct2D is what used to make fast and effecient 2d rendering for UI, sure this is not the only way but it is native!) there was also a thread not so long ago - http://forum.dlang.org/post/tiyttpodenppvlfxi...@forum.dlang.org [1] https://issues.dlang.org/show_bug.cgi?id=16987 [2] https://issues.dlang.org/show_bug.cgi?id=16527
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d A long awaited update - v0.10.0 is out! Be wary there is still a lot of things untested, and one may encounter access violation or random crashes. It is great to see community expanding and the language growing up. Thanks everyone who contributed.
Re: DirectX bindings
On Saturday, 24 January 2015 at 20:35:23 UTC, Andrej Mitrovic wrote: On 5/27/14, evilrat via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d this is it. i think i can't continue on this one anymore, nor do i have time, nor passion. Hey, sorry you didn't find an audience for this, thanks for your work nevertheless! But do you by any chance know how up to date your bindings are compared to these other ones: https://github.com/auroragraphics/directx If you don't know I'll try to diff my way and find out. it is very sparse comparing to what i've done, but DirectX itself is stable so there shouldn't be any problems. though my version is targeted for same usage as if in C++, and contains most of helper functions, so one could easily rewrite C++ arrows as dots and thats all - everything should work(most times at least). This is very useful and convenient since there are very few learning resources about D and especially DirectX with D(if any). maybe i'll update it to DirectX 12 as soon it is released. but still i would merge peoples PR's if there be any commits.
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d this is it. i think i can't continue on this one anymore, nor do i have time, nor passion. i've made a lot of work and meet (almost) no interest. i will be stay in contact, so any pull request will not be lost, but i think this is my last commit to it. i have encountered lot of obstacles such as UFCS on classes, which makes impossible seamless migration of user code from C++ to D(no, that wasnt real purpose but for me it is important point). i may return later, let say in a year or two when D will be more complete and usable, but for now i take my leave. please take my apologies if one really used this bindings or have high hopes on it.
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d new additions: +Direct2D [DX9 state] (though still some helper functions missing) +DirectWrite [DX9 state] +DXGI [DX11.1, DX11.2] +Direct3D [DX11.1, DX11.2] examples: +Direct2D sample from MSDN ( a bit ugly at this moment )
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d little update: i'm currently looking at some other not yet converted stuff such as Direct2D, DirectWrite and DXVA(video decoding). can't say anything for now, i don't promise i will translate it but i'll looking forward to adding them in to repo. that's all i can say now. if i had enough time i'll put D2D later this week.
Re: OpenGL Examples in D and a birth of a New Initiative
On Saturday, 17 May 2014 at 19:00:12 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: Probably with a good D wrapper coding in DirectX could be fun, especially since the API is apparently stateless. Btw, I think Adam Wilson mentioned that your bindings are slightly out of date. He apparently hosts newer bindings here: https://github.com/auroragraphics/directx my bindings is for DirectX 11 mostly, a bit of d3d10 which is necessary, but there is no 2D or any other stuff from DirectX 9 at all. as for 'freshness', well, i probably need to clean up a bit and add recent features(which is anyway will not go mainstream). the question is do i really need this? no interest from community means waste of time and effort...
Re: OpenGL Examples in D and a birth of a New Initiative
On Thursday, 15 May 2014 at 05:01:14 UTC, Manu via Digitalmars-d-announce wrote: I tried to gather support for a community game project (FeedBack). Lots of interest, but nobody actually joined the party when I kicked it off. On 15 May 2014 05:04, Andrej Mitrovic via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I am starting an initiative for everyone interested in D game development by creating the github organization d-gamedev-team[1]. The first project hosted here is the the freshly created opengl-tutorials[2] project. This is a long-term project that aims to collect as many modern OpenGL examples ported to D or even provide new examples created from scratch in D. All the examples should be easy to build, provided you have a fresh D compiler and a recent version of the dub[3] dependency manager / builder tool. Currently the project contains an almost-complete port of the samples contained on the website opengl-tutorial.org[4] - which cover OpenGL v3.3x and were created by Sam Hocevar. The D examples are not straight ports, they have been D-ified and may contain more features than their original counterparts. They also use 3rd-party D OpenGL wrappers to avoid a lot of scaffolding work typical of OpenGL applications. Thanks to dub[3] you won't have to manually install the D dependencies. However you may have to install some C/C++ 3rd-party library dependencies, such as GLFW, SDL2, SDL2 Image, and potentially other libraries depending on the ones the samples require. The dependencies are documented in the project's readme[5]. Additional OpenGL example ports are planned and some are already in progress but have not yet been pushed upstream. See the opengl-tutorials[2] github repo for a list of ports which are in progress and a list of desired ports. If you wish to contribute with your own ports or with brand new D OpenGL examples don't hesitate to make a pull request. I want the d-gamedev-team organization to gradually grow and have it host as many useful projects, whether it be libraries, tools, tutorials, tips tricks, assets, or anything else related to D game development. I am strongly interested in game development in D, and although I'm at a starting stage I'm very much committed to working on this project to the best of my abilities. Hopefully in a few years we'll see some major titles made entirely in D. But before that can happen we have to make a collective push to bring D to a higher stage where it's acceptable and viable to game developers, whether it be through language support (@nogc/allocators) or library and tooling support. We'll see where this goes, but I'm very excited for the future! Cheers. :o) [1] : https://github.com/d-gamedev-team [2] : https://github.com/d-gamedev-team/opengl-tutorials [3] : http://code.dlang.org/download [4] : http://opengl-tutorial.org/ [5] : https://github.com/d-gamedev-team/opengl-tutorials/tree/master/ports/opengl-tutorial.org same with DirectX, more than half year passed since i published it and i only get single commit and one known user. nice, good and active community. i wish to say good luck with ur linuxez guyz i'm done here, but i always returns to see whats new, still hoping it's temporally... p.s. i admit that linux could give us some traction to have public approval, but it doesn't mean that there is only linux...
