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...
Re: Visual D 0.3.38 released
On Monday, 14 April 2014 at 23:25:54 UTC, Meta wrote: Now when trying to debug with Mago, I get the error message: Cannot launch debugger on filepath hr = 8910016 x64 build? mago is only x86 debugger
Re: Mono-D v1.6 - method override completion
On Friday, 14 February 2014 at 01:26:18 UTC, Alexander Bothe wrote: Okay, just implemented a completion mode for method overrides. I won't explain this over here, as there are screenshots depicting everything properly already :-) http://mono-d.alexanderbothe.com/method-override-completion-v1-6/ new version is cool, but i have found one bug already. when using autocompletion with symbol having trailing numbers in name it matches only last trailing char, for example trying to get completion for ID3D1 will match ID3D10(properly) stuff and also ID3D(1)1 with (1) grayed out, making it impossible to get completion for ID3D11 string. i'm still can't figure exact cases when it happens.
Re: DirectX bindings
it has been for a long time since i released this bindings, so i wonder if anyone uses this in their projects? it would be nice to see some results of projects using this bindings :)
Re: dmd 2.065 beta 2
On Sunday, 26 January 2014 at 23:38:56 UTC, Andrew Edwards wrote: We've made a lot of progress towards the 2.065 stable release. Available binaries are as follows: Windows http://ftp.digitalmars.com/dmd.2.065.0-b2.exe http://ftp.digitalmars.com/dmd.2.065.0-b2.windows.zip for some reason there is nothing downloaded by installer(have installed zip manually), also installer seems not able to detect and add VC and WinSDK paths (Win 8.1 x64, winsdk 8.1, visual studio 2013) am i doing something wrong?
Re: dmd 2.065 beta 3
i have some strange behaviour when building with -O, if in short it reports taking address of interface as dereferencing null. error reported with 2.065 beta2 and beta3, but i don't remember if i had this on 2.064. any advices? here is repro case(for simplicity use dub) https://gist.github.com/evilrat666/151adaf4ce94ee1a1c68
Re: New debugger for D!!!
On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote: On 2014-01-28 04:00, Sarath Kodali wrote: Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. I'm waiting for the OS X version :) not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as optimized out values. i think it may be related to TLS because __gshared variables CAN be debugged.
Re: New debugger for D!!!
On Tuesday, 28 January 2014 at 13:59:48 UTC, Iain Buclaw wrote: On 28 January 2014 13:24, evilrat evilrat...@gmail.com wrote: On Tuesday, 28 January 2014 at 10:03:03 UTC, Jacob Carlborg wrote: On 2014-01-28 04:00, Sarath Kodali wrote: Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. I'm waiting for the OS X version :) not going happen until dmd gets fixed. i'm not tested GDC yet, but others compilers don't emit variable address info for debug or it shown as optimized out values. i think it may be related to TLS because __gshared variables CAN be debugged. 1) If it's optimised out then I suggest not running a debugger with -O generated code. it is optimized out with LDC compiled program, and simply not present with DMD. 2) What debugger are you using? I am aware that gdb does not evaluate D programs correctly in certain situations. both gdb and llvm. results are same.
Re: D bindings for Shapefile C Library
On Wednesday, 29 January 2014 at 05:12:45 UTC, Rikki Cattermole wrote: For simple static bindings, it looks fine. You'll probably have fun getting it to work on Windows 32 bit though. Thank you OMF. what fun? using (coff)implib once? come on, that's not that hard at all... the only fun is when lib export only constants which is rare.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 08:07:57 UTC, Jacob Carlborg wrote: On 2014-01-14 05:10, evilrat wrote: running gdb --interpreter=mi2 launches it without any warnings and errors. (my gdb version is 7.6) I have GNU gdb 6.3.50-20050815 (Apple version gdb-1824). And when I launch it with --interpreter=mi2 I get some extra symbols in the output, like this: ~GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)\n i have that too, plus additional info and license info
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 13:16:12 UTC, Alexander Bothe wrote: On Tuesday, 14 January 2014 at 13:06:05 UTC, evilrat wrote: gdb plugin version 0.2.5 still gives the same error. Ah, sorry, I should've mentioned it: There's an option panel called Gdb.D now where you can put in a custom gdb command. it now starts, but in terminal started by xamarin studio it prints: warning: GDB: Failed to set controlling terminal: Operation not permitted\n Hello World! --- in output panel: Couldn't inject exception handler breakpoint - no finddata symbol found! and after clicking step through it adds: Single stepping until exit from function _Dmain,\nwhich has no line number information. i have tried compiling with both -g and -gc any suggestions?
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 14:12:54 UTC, Alexander Bothe wrote: Could you locate the binary libphobos file, open it e.g. with SciTE and look for some mangled string that contains 'finddata', such as _D2rt15deh_win64_posix13__eh_finddataFPvZPyS2rt15deh_win64_posix9FuncTable - something like this is required to have proper exception hooking :) it's in there
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 14:12:54 UTC, Alexander Bothe wrote: If you tried running your D programw with gdb, made a breakpoint at _Dmain and stepped through the method's code ... gdb test run (idk why i run with mi2 :( ) http://pastebin.com/U7UTNfxM lldb just to compare =0 http://pastebin.com/AxLUTuwy
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 14:43:26 UTC, Alexander Bothe wrote: On Tuesday, 14 January 2014 at 14:25:31 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 14:12:54 UTC, Alexander Bothe wrote: If you tried running your D programw with gdb, made a breakpoint at _Dmain and stepped through the method's code ... gdb test run (idk why i run with mi2 :( ) No need for having the weird mi2 interface :D http://pastebin.com/U7UTNfxM Okay, so it actually is working - but only partwise. As I just executed that program, I was able to jump into stdin.readln(); as well. Dunno what reason this could have. stepping through stops on lots of functions down to main(), but no sources and lines. maybe i forgot something. Could try to extend the sample application to see whether it's skipping everything else either? Btw, could we meet in the irc #d or #d.mono-d ? I'm alex|D-Guy over there, it would be nice to see you there and have little more direct conversation than 'chatting' via the NG/Forum sure, just not today, too busy at this moment.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 11:03:45 UTC, Alexander Bothe wrote: On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote: after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... I've got no OSX but erm, what tool is required to have lldb information generated? ldc2? On the other side, which tool is then required to get gdb debug info? i don't know about other tools, so basically i just build with dmd files.d -gc and debug using console lldb, of course it was mangled but it is better than nothing.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 14:50:05 UTC, Alexander Bothe wrote: So according to Jacob's comment it's actually possible to get gdb on OSX - but probably just with a wrong build configuration, i.e. the mi2 interface for gdb is not available - or is it? Just try executing gdb --interpreter=mi2 to see whether Mono-D is able to handle its output properly. running gdb --interpreter=mi2 launches it without any warnings and errors. (my gdb version is 7.6)
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 04:10:03 UTC, evilrat wrote: On Monday, 13 January 2014 at 14:50:05 UTC, Alexander Bothe wrote: So according to Jacob's comment it's actually possible to get gdb on OSX - but probably just with a wrong build configuration, i.e. the mi2 interface for gdb is not available - or is it? Just try executing gdb --interpreter=mi2 to see whether Mono-D is able to handle its output properly. running gdb --interpreter=mi2 launches it without any warnings and errors. (my gdb version is 7.6) but running mono-d debug gives following error message ApplicationName='gdb', CommandLine=-quiet -fullname -i=mi2', CurrentDirectory=, NativeError= Cannot find the specified file
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Tuesday, 14 January 2014 at 05:04:42 UTC, Alexander Bothe wrote: On Tuesday, 14 January 2014 at 04:15:50 UTC, evilrat wrote: ApplicationName='gdb', CommandLine=-quiet -fullname -i=mi2', CurrentDirectory=, NativeError= Cannot find the specified file Okay, I think I'm gonna make a separate option panel then for setting up the path to gdb. ok, thanks.
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Sunday, 12 January 2014 at 23:40:33 UTC, Alexander Bothe wrote: Hi everyone, Just wrote annotated v1.2.7 of Mono-D: http://mono-d.alexanderbothe.com/completion-ldc2-compatibility-dub-fix-v1-2-7 I'm too lazy to mention every part of it again over here - if there are questions: Here, in #d.mono-d, on the blog, on github - you know the usual places where to find me :) Cheers mates, Alex after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... p.s. also, why at first launch it can't just fetch default phobos location for DMD? it's quite annoying adding this paths in settings and it may revolve unaware users from using it(like it was for me about year ago).
Re: Call D code from C#
On Friday, 10 January 2014 at 09:54:27 UTC, anthony wrote: Hi Dejan, GTK is not an option for me mainly because I do not like the way programs written with appears on the screen. It is a little...ugly! Qt does a lot better in that field, it also has (QT) better documentation, better tools etc etc. This is why I first looked for Qt binding for D. isn't they actually has same method for building ui visuals? i mean by using CSS-like styles, so it is just style, not the Gtk or Qt itself...
Re: Call D code from C#
On Thursday, 9 January 2014 at 16:09:11 UTC, anthony wrote: Thanks for the (ultra fast) reply! I has that coming that P/Invoke is the only way, unfortunately. Are you aware of any other problems using this technique ? why unfortunately? using this in visual studio allows me debug both C#/D code. all fine, but i never used it for anything complex than testing stuff though.
Re: DVM - D Version Manager 0.4.2
On Friday, 3 January 2014 at 12:04:33 UTC, Jacob Carlborg wrote: I just released a new version of DVM, 0.4.2. The biggest news for this release is that the source code has been ported to D2 and I'm bringing back support for 64bit platforms. Except from this it's mostly a minor release. For pre-compiled binaries and changelog (or below) see: https://github.com/jacob-carlborg/dvm/releases/tag/v0.4.2 For those not familiar with DVM: DVM allows you to easily download and install D compilers and manage different versions of the compilers. Changelog: Version 0.4.2 New/Changed Features * Ported to D2 * Add support for fetching the latest version of the compiler * Bring back support for 64bit Bugs Fixed * Fails to get the latest version of the compiler so this is a tool which could build dmd phobos from git master branch(or any else) and later switch between that newly build version and 2.064 release?
Re: DVM - D Version Manager 0.4.2
On Saturday, 4 January 2014 at 14:41:02 UTC, Jacob Carlborg wrote: On 2014-01-04 13:21, evilrat wrote: so this is a tool which could build dmd phobos from git master branch(or any else) and later switch between that newly build version and 2.064 release? Unfortunately no. It can build DMD and Phobos from git master but you cannot currently install that. It's mostly focused on installing releases of DMD. But you can install the build from git master manually. Have a look in ~/.dvm. What you need is ~/.dvm/compiler/dmd-name and ~/.dvm/env/dmd-name where name is a name or version number for the specific compiler. ok, thanks. will try later.
Re: DSFML
On Sunday, 22 December 2013 at 01:24:50 UTC, Kelet wrote: Thanks for all of the hard work, Jeremy. DSFML is definitely one of the libraries helping D move forward as a first class game development platform. Regards, Kelet oh and i guess no one use DirectX in AAA titles now, such a shame...
Re: DirectX bindings
On Friday, 8 November 2013 at 02:57:25 UTC, Andrej Mitrovic wrote: On 11/3/13, evilrat evilrat...@gmail.com wrote: https://github.com/evilrat666/directx-d Nice! I tried porting one of the samples from the SDK but it uses D3DX11CompileFromFile which is missing in the bindings. MSDN says they recommend not using it (well.. why are they using it in the samples then?: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476261%28v=vs.85%29.aspx So maybe it's not worth binding it? No idea. :) indeed this is not recommended to use, and there are no more such function on windows 8. i'm also need to fix xaudio example too :(
Re: Visual D 0.3.37 released
On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote: ok i forgot about output pane. so what i see here... ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL so the problem with debug server formats? i wish it would work with visual studio 2013 soon, but at least x64 debug works so i can continue using it for now \0/
Re: Visual D 0.3.37 released
On Sunday, 10 November 2013 at 07:13:26 UTC, Nicholas Londey wrote: Have a look at this and see if that helps. I think I got it working in vs2013 because it was the announcement that it should be working that prompted me to find out why it wasn't. http://d.puremagic.com/issues/show_bug.cgi?id=11457 i see sc.ini points to x64 vc\bin path, replaced with path to x86 bin and still not works. p.s. also please fix custom type coloring depending on visual studio style, with dark color scheme custom types(string, object, etc.) is unreadable even on good ips display. i think it would be better to set it to something like light blue as VC does with basic types.
Re: Visual D 0.3.37 released
ok i forgot about output pane. so what i see here... ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL
Re: dmd 2.064.2
On Thursday, 7 November 2013 at 16:25:47 UTC, Brad Anderson wrote: On Thursday, 7 November 2013 at 08:58:50 UTC, tester wrote: how do make that comiler work? [Issue 11457] New: Cannot compile 64bit apps with Visual Studio 2013 this is a desaster for me. was that release tested? if i amand the pathes and run as admin or not - it will not find the libs (user32) windoes8.1, visual studio2013, 64bit This never worked automatically before so I don't know how this could suddenly be a disaster. In this release the installer makes an attempt to detect your VC++ and SDK installation and fix up sc.ini to point to them. It's brand new and only a few people responded to my call for help testing it. Post your sc.ini and the paths to your Windows 8.1 SDK and Visual C++ 2013 installation. i have tested windows 8.1/vc 2013/sdk 8.1, here are my paths: mspdb120 path: --- %VCINSTALLDIR%\..\VC\bin --- (full: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin) libs path: --- %WindowsSdkDir%\Lib\winv6.3\um\x64 --- (full: C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64) adding this stuff to sc.ini allows to build with dmd 2.064.2 with -m64
Re: code.dlang.org now supports categories and search
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote: Is it possible to add a feature to sort the view by the added date of a package (rather than just updated/name sorting)? Sometimes I'd like to see which packages are new in the registry. that would be really useful. who knows when something interresting added to dub, this would allow to see...
Re: Visual D 0.3.37 released
On Saturday, 2 November 2013 at 14:40:56 UTC, Rainer Schuetze wrote: * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8, fixes x64 debugger in VS 2012 Shell unfortuantely it doesn't works with VS 2013, it installs and registers with visual studio, but whenever i hit the build or debug it instantly reports build error with no info.
Re: DirectX bindings
On Friday, 8 November 2013 at 11:37:38 UTC, liyu wrote: On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: Greetings, many of you may notice lack of (up-to-date and working) DirectX bindings, one may also seen my activity on d.learn sub forum. so let me announce yet another bindings for DirectX which one may fork right now from github! https://github.com/evilrat666/directx-d please be careful though, as it is only in alpha stage and missing some stuff. current version is June 2010 SDK, but i update it(to win8 sdk version) once i had win8 machine(i'm still don't have a PC at home). also, there is no d3d9 and d3d10 stuff as i consider it outdated now, but i would appreciate pull requests for them anyway :) great, however it seems has a little problem, the arg of ID3D11DeviceContext.Unmap should be ID3D11Resource not ID3D11Resource*, arg of IASetIndexBuffer should be ID3D11Buffer not ID3D11Buffer* uh, yes, it has some problems, this is semi-automatic coversion bindings, and i have missed some stuff. thanks for pointing out.
Re: dmd 2.064.2
On Thursday, 7 November 2013 at 08:58:50 UTC, tester wrote: how do make that comiler work? [Issue 11457] New: Cannot compile 64bit apps with Visual Studio 2013 this is a desaster for me. was that release tested? if i amand the pathes and run as admin or not - it will not find the libs (user32) windoes8.1, visual studio2013, 64bit if it compiles with -m32 and fails with -m64 then i think you need manually edit ur sc.ini to add correct paths for windows sdk/kits and visual studio.
Re: DirectX bindings
i have finished dub transition, git repo should pop up on dub registry soon.
Re: dmd 2.064.2
On Thursday, 7 November 2013 at 11:42:25 UTC, tester wrote: does not work with the installer either. that really sucks well, this is because most people stick with linux, and i think there few to noone win8 users. so here is the result ...
Re: DirectX bindings
On Friday, 8 November 2013 at 02:57:25 UTC, Andrej Mitrovic wrote: On 11/3/13, evilrat evilrat...@gmail.com wrote: https://github.com/evilrat666/directx-d Nice! I tried porting one of the samples from the SDK but it uses D3DX11CompileFromFile which is missing in the bindings. MSDN says they recommend not using it (well.. why are they using it in the samples then?: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476261%28v=vs.85%29.aspx So maybe it's not worth binding it? No idea. :) its already in the bindings https://github.com/evilrat666/directx-d/blob/master/src/directx/d3dx11async.d#L79 however i may forgot to add public import this module in d3dx11.
Re: DirectX bindings
i have added dub package to this bindings, need testing. i don't have an idea how it works since dub lacks documentation.
Re: DirectX bindings
On Wednesday, 6 November 2013 at 14:25:46 UTC, Mike Parker wrote: On 11/6/2013 6:29 PM, evilrat wrote: i have added dub package to this bindings, need testing. i don't have an idea how it works since dub lacks documentation. http://code.dlang.org/about http://code.dlang.org/package-format i know about this, i mean there is no such info like dub .lib search paths for testing - i don't want to modify sc.ini every time. there was some other things too, but i can't remember anything else atm. also if you look at my repo u can see it has examples subfolder, should i put package.json there too or it would be simpler to add custom build script for building all this examples?
Re: DirectX bindings
On Wednesday, 6 November 2013 at 14:44:59 UTC, Dicebot wrote: On Wednesday, 6 November 2013 at 14:35:07 UTC, evilrat wrote: also if you look at my repo u can see it has examples subfolder, should i put package.json there too or it would be simpler to add custom build script for building all this examples? I think former is expected as it is how Sonke (dub author) does it for vibe.d : https://github.com/rejectedsoftware/vibe.d/tree/master/examples ah ok, thats fine, thanks.
Re: DirectX bindings
On Sunday, 3 November 2013 at 08:42:52 UTC, ponce wrote:
Hi,
Good work.
While porting header to D you can use:
alias int _D3D_SHADER_INPUT_FLAGS
enum : _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
instead of:
enum _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
That way using the enum won't force to use a namespace.
thanks for notice, i'll need to try it first on something bigger
than simple example first.
most likely i had been doing this by default if i were work with
real C++ DirectX projects, unfortunately i only used OpenGL until
now :(
DirectX bindings
Greetings, many of you may notice lack of (up-to-date and working) DirectX bindings, one may also seen my activity on d.learn sub forum. so let me announce yet another bindings for DirectX which one may fork right now from github! https://github.com/evilrat666/directx-d please be careful though, as it is only in alpha stage and missing some stuff. current version is June 2010 SDK, but i update it(to win8 sdk version) once i had win8 machine(i'm still don't have a PC at home). also, there is no d3d9 and d3d10 stuff as i consider it outdated now, but i would appreciate pull requests for them anyway :)
Re: glad OpenGL loader generator
On Tuesday, 13 August 2013 at 10:41:49 UTC, David wrote: This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem. ok thanks, i'll try later.
Re: glad OpenGL loader generator
On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :(
Re: glad OpenGL loader generator
On Monday, 5 August 2013 at 21:42:59 UTC, David wrote: glad - is an OpenGL loader (with experimental gles support, --api=gles2) ... i looked at this on github and see an option to build with gl3n, then i see what it is, and looks like gl3n is a 'must have' for my simple tasks. but for some reason it only builds with -m32 on OS X, i can't see where it puts this flag in makefile and why do the hell it inserts this. can you help explain how to get rid off this?
Re: Guigle openGL GUI on GIT
On Monday, 22 April 2013 at 04:13:02 UTC, Alexandr Druzhinin wrote: your job is very useful, but building failed with the error: Guigle\FileSaver.d(144): Error: undefined identifier listDir the same error appear in every file using listDir symbol of course. How to fix that? And also I'm curious how is it hard to port Guigle from Derelict3 to the second one? I need to work with OpengGL 2.0. have you looked at or ever tryed derelict3? it has all opengl 2(all up to the latest opengl version actually) declaration, that 3 in the name means it for D2, as far i remember derelict2 was initially for D1 or D2 tango+phobos , where derelict3 rewriten purely for D2/Phobos. please don't blame me if i'm wrong, really can't remember what it exactly is.
Re: Build Script in D
On Saturday, 19 January 2013 at 15:32:46 UTC, David wrote: I compile pre-compile glfw for windows, but on Linux/OSX etc. I have it as submodule and it works fine! :) works for me too, but this is sad that i need to use 3rd party libs just to create render window and handling input(well, it's possible to create cocoa window using plain c, but that would require some time which i don't have right now) :(
Re: Build Script in D
On Saturday, 12 January 2013 at 16:34:12 UTC, David wrote: Using make with D works great, also there is cmake for D. But try to use two tools (d buildscript and let's say cmake) on windows. You have to force the user to either install mingw/cygwin or cmake/make and VS (cmake can only generate for mingw-make and VS not dmc). Users will end up not using it. stb_image e.g. is in no OS-Package (which also don't exist for windows) of course makefiles work, it's just hated by so many programmers... for windows there is 99% chance that already compiled executables/libraries exists. and if some project doesn't have binaries for windows, it's maintainers fault, not windows. just imagine yourself compiling for example Qt or chrome on single core 2Ghz machine with 1gb ram because there is no compiled binaries, would you be happy after that? but... we already going to OT, i don't want to start holy wars about build systems.
Re: Build Script in D
On Friday, 11 January 2013 at 14:01:48 UTC, David wrote: also something like this for custom target: auto builder = Builder( homepath!./, arch!x86, mode!debug ) Doesn't work, these are compiler flags, which differ from compiler to compiler. You could make the builder call the compiler to set the flag, but I would move that directly to the compiler. // assuming all methods returns ref to self so it could be just simple calls builder.addSrcPath(path_to_src_folder_1); // or can be chained builder.addSrcPath(path_to_src_folder_2). addSrcPath(path_to_src_folder3); And how does chaining help? That makes everything just uglier. builder.addImportPath(path_to_imports); builder.addLinkLib(somelib.a); Need to be set for the compiler, A C compiler doesn't need the flags of a D compiler // compiler log string log = builder.build(); The log should be in realtime to see where compilation takes longest etc. also to all above it would be good if there be some concept of multiple targets or jobs and ordering, to allow build stuff dependent on other stuff in one run Everything is compiled without beeing linked, order doesn't mean anything, because everything will be linked together. well the topic says script in D, so i assume this is for D and not C(there is already cmake, make and so on), and this is possible to get compiler info in D ugly chaining is not so ugly, and is just an option, there is anyway with (...) construct in D log is was an example and not requirement, i just say that such class when used with CTFE somehow would be helpful to do easy compile with all dependencies, i.e. you only compile one target and using CTFE it compiles other, possibly messy stuff but maybe anyone need this... anyway that's just a wishlist, not a must have list =3
Re: Awesomium D wrappers/bindings
i'm figured out why awesomium doesn't load on osx, they have wrong instruction on their wiki. i'll try to do D app project for xcode later. i wish there be already existing template for this :( On Sunday, 30 December 2012 at 10:41:22 UTC, David wrote: And don't forget to set the wchar16 array to cast(wchar)0 otherwise it will display garbage (it needs a terminator) arrays initialized with nulls right? anyway just setting only first symbol in text field(it's wchar[4]) is enough.
Re: Awesomium D wrappers/bindings
doh.. now it inputs 2 char in a row, this is really stupid because i'm not sending anything but single char event
Re: Awesomium D wrappers/bindings
i hate myself sometimes. figured out what the stuck is wrong. it was my raw input problems. so awesomium just need key down without text, and for text input one would need just set type and text fields.
Re: Awesomium D wrappers/bindings
i can't make that damn raw input spit out unicode chars, and by some reason awesomium internal func don't eat key codes too(well it eat, but no chars in input), this is the only problem left before wrapper become somehow useful...
Re: Awesomium D wrappers/bindings
On Thursday, 27 December 2012 at 10:35:20 UTC, David wrote: There is no drawing func callback, we are probably speaking of two different glfw version (even though I don't know of such a callback even in glfw 2.7) well ok i must be forgot something, but i clearly remember that bug(or 'feature'?)
Re: Awesomium D wrappers/bindings
On Thursday, 27 December 2012 at 13:16:33 UTC, David wrote: I started with an abstraction: https://github.com/Dav1dde/wonne Currently I've done only strings, I think I can add the rest today just to mention, last time i tried D wchar with awesomium wchar it was pure fail, but may be i've just a bit messed up somewhere
Re: Awesomium D wrappers/bindings
On Thursday, 27 December 2012 at 17:31:58 UTC, David wrote: Webcore, done Webview, done (except the callbacks) Renderbuffer, done And bindings are waiting to get into deimos: https://github.com/D-Programming-Deimos/awesomium/pull/1 will there be OOP wrapper in deimos? or deimos is purely for C header translation?
