Re: Discuss vulkan erupted, the other auto-generated vulkan binding
Test worked, now supporting dub packages xcb-d, xlib-d, wayland-client-d.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Friday, 20 May 2016 at 18:52:35 UTC, maik klein wrote:
On Thursday, 19 May 2016 at 15:44:27 UTC, ParticlePeter wrote:
I am a bit slow, how do I add xcb as a dependency?
/source/erupted/types.d(3335,16): Error: module xcb is in file
'xcb/xcb.d' which cannot be read
Can I add dependencies for dependencies in dub?
This is WIP and should be resolved within this week. Do you want
to use dub xcb-d, or do you have some other bindings?
In the former case I would need somebody to test the setup before
I publish a new version, I don't have access to posix.
If you want to test, please add this configuration to erupted
dub.json configurations (temporarily!), if it works I will add it:
{
"name" : "dub-platform-xcb",
"versions" : [ "VK_USE_PLATFORM_XCB_KHR" ],
"dependencies" : {
"xcb-d" : "~>2.1.0+1.11.1"
},
In your project dub.json add:
"subConfigurations" : {
"erupted" : "dub-platform-xcb",
},
This should add xcb-d dependencies to erupted.
In any case, feel free to open an issue at:
https://github.com/ParticlePeter/ErupteD
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:
Am Wed, 18 May 2016 18:57:48 +
schrieb ParticlePeter :
On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
> On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König
> wrote:
>
>> I think I will use glfw3 later. I don't know if the
>> original problem of using multiple configurations (xcb,
>> xlib, glfw3, ...) is possible with only dub's internal
>> logic. I tried putting this in my "vulkantest" packages'
>> dub.json
>>
>> "subConfigurations":
>> {
>>"erupted": "with-derelict-loader",
>>"erupted": "normal"
>> }
>>
>> just for testing, and dub told me
>>
>> Could not resolve configuration for package vulkantest
>>
>> So I thinnk multiple subconfigurations are not supported.
>
> The way to handle this is to make multiple configurations of
> vulkantest, one for each of the configurations of erupted
> you want to support. Then, when you build vulkantest, you
> specify the configuration you want to build on the command
> line (unless you're building the default).
This is a good point, the custom project platform
configuration would then be forwarded to erupted. Only
drawback would be that "with-derelict-loader" config is not
available in combination with a platform config, but in the
later case you would want to grab vkGetInstanceProcAddr anyway
in platform specific means.
Manuel, I could just skim over xcb-d. As far as I can see it
has the module xcb.xcb. Is this module sufficient to be
imported in erupted.types.d? In this case I would not have to
touch the erupt.py generator but instead just fix the
erupted.dub file. As you can test it, how about a pull request?
@ Peter: Yes, importing xcb.xcb is all you need, no patches
necessary. But I could patch erupteD's dub.json for an xcb
configuration, and maybe put in the readme how to use a
configuration, but probably not until sunday.
@Mike: Having multiple subconfigurations (xcb, xlib, glfw3,
...) to pick for the user is the solution Peter was going for,
as I understood him. The problem is when a user wants to
support both xcb and xlib, or any mix of them. But this is
probably just a pathetic use case not relevant in practice, I
just stumbled over the question if that is possible when I
wanted to add proper xcb, xlib, etc. support to erupteD.
As far as I understand Mike it is still possible. Suppose you
build an engine based on (d-)vulkan/erupted, lets call it
Turtle-Engine, you would also specify sub-configurations for xcb,
xlib, win, ... and you could support any of (d-)vulkans/erupted
sub-configs in your corresponding configs. When some dude (no
sexual prejudice meant) wants to write a Turtle-App, which is
based on your Turtle-Engine he decides how many of your configs
representing platforms he would like to support. Now you see, as
the language architect pointed out, its turtles all the way down.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Thursday, 19 May 2016 at 00:09:42 UTC, Alex Parrill wrote: Apparently GitHub didn't add my own repo to my list of watch repos, meaning no notifications for them... I'll look over the pull request. Let's not split this project. Depends on how far you want to catch up. Lets discuss this in the d-vulkan issues.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote:
I think I will use glfw3 later. I don't know if the original
problem of using multiple configurations (xcb, xlib, glfw3,
...) is possible with only dub's internal logic. I tried
putting this in my "vulkantest" packages' dub.json
"subConfigurations":
{
"erupted": "with-derelict-loader",
"erupted": "normal"
}
just for testing, and dub told me
Could not resolve configuration for package vulkantest
So I thinnk multiple subconfigurations are not supported.
The way to handle this is to make multiple configurations of
vulkantest, one for each of the configurations of erupted you
want to support. Then, when you build vulkantest, you specify
the configuration you want to build on the command line (unless
you're building the default).
This is a good point, the custom project platform configuration
would then be forwarded to erupted. Only drawback would be that
"with-derelict-loader" config is not available in combination
with a platform config, but in the later case you would want to
grab vkGetInstanceProcAddr anyway in platform specific means.
Manuel, I could just skim over xcb-d. As far as I can see it has
the module xcb.xcb. Is this module sufficient to be imported in
erupted.types.d? In this case I would not have to touch the
erupt.py generator but instead just fix the erupted.dub file. As
you can test it, how about a pull request?
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote: had to update the function loading names I chose differently. This bugged me a little, v1.1.0 has the EruptedLoader struct removed so that the loading functions are called without EruptedLoader. prefix and can be renamed at import. This is a BERAKING CHANGE.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Tuesday, 17 May 2016 at 20:34:17 UTC, Manuel König wrote:
> What I want to do is to tell dub that erupted should depend
> on xcb-d in my project's dub.json, is that possible?
I am not very confident with dub, but think that it would not
work. Maybe you ask in the dub forum?
[...]
Another way would be, and I think I'll go for it, that I add
dub
platform configurations. In your case it would be:
"subConfigurations": { "erupted": "dub_platform_xcb" }
which would add xcb-d as dependency and the relevant xcb-d
modules in erupted.types.d
Sounds reasonable, picking a subconfig is definitely easier to
use and implement. I was looking into that too, the only
nitpicking I have is that it sounded like you can't select
multiple subconfigurations. So for corner cases like having
your app support xcb and xlib, a new subconfig has to be added.
But I'll have to try that for myself.
Actually that's a good point, I had also some trouble with this
behavior as well already. Do you have any suggestions to solve
that?
One way would be using glfw3 or some other platform abstraction
layer and not using platform versions yourself.
On another note, while I like the creative package naming, it
may not
be very easy for search engines to pick up or recognize by
potential
users as vulkan bindings. The project is still new, but
gooogle and duckduckgo don't find erupteD when searching for
"dlang
vulkan", but they do find derelict-vulkan, d-vulkan and
vulkanizeD. I
hope I'm just overanalyzing, but I think having vulkan in the
name
would be good. But I see that we're getting out of naming
options
here...
I agree with all your arguments, in particular that last one :-)
but I think as long as google and duckduck show that something is
happening with vulkan in dland its O.K. Diving deeper and using
dub package search for vulkan does list erupted. Additionally I
asked vinjn/awesome-vulkan and jcoder58/VulkanResources to list
erupted as d binding.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote:
Hi, Kalua here :)
First, thanks again for fixing vulkanizeD, now I don't have to
use my locally patched version anymore ;)
Welcome :-)
Giving you some input for how your lib works on my posix sytem
(arch
linux):
My simple triangle drawing program works with your lib, I only
had to update the function loading names I chose differently.
That's nice to hear!
But I had to modify erupteD's dub.json to depend on xcb (dub
package xcb-d), because simply putting the xcb dependency in my
project's dub.json was not enough. But this should only be a
workaround, because not everyone uses/can use xcb, or they may
even want to use different xcb bindings.
That's right, but if the platform modules are available as dub
packages they should be supported somehow.
What I want to do is to tell dub that erupted should depend on
xcb-d in my project's dub.json, is that possible?
I am not very confident with dub, but think that it would not
work. Maybe you ask in the dub forum?
But I have one idea which might work:
Create a module xcb.xcb.d yourself and publicly import all
required sources from xcb-d into it. In your triangle vulkan
project add the path to xcb.xcb.d and xcb-d to "sourcePaths" and
"importPaths". Erupted might pick it up.
Another way would be, and I think I'll go for it, that I add dub
platform configurations. In your case it would be:
"subConfigurations": { "erupted": "dub_platform_xcb" }
which would add xcb-d as dependency and the relevant xcb-d
modules in erupted.types.d
Discuss vulkan erupted, the other auto-generated vulkan binding
This is in respect to announce thread: https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org Please let me know if you had the chance to test the functionality as requested in the announce thread. All other question are welcome here as well of course. Cheers, ParticlePeter
Re: What is the state of multiple alias this (DIP66) ?
On Sunday, 10 April 2016 at 14:34:17 UTC, hilop wrote: On Sunday, 10 April 2016 at 14:28:35 UTC, ParticlePeter wrote: Last modification was about one and a half years ago, is it going somewhere? read this: https://github.com/D-Programming-Language/dmd/pull/3998 tl;dr the state right now is: it was written before the bootstraping so it has to be converted. Thx, read it happily, it's going somewhere :-)
What is the state of multiple alias this (DIP66) ?
Last modification was about one and a half years ago, is it going somewhere?
Re: Vulkan bindings
On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! I think your usage of const pointer is wrong. E.g. c const char* maps to d const(char)* etc.
Re: Vulkan bindings
On Friday, 19 February 2016 at 01:49:12 UTC, Alex Parrill wrote: On Thursday, 18 February 2016 at 03:39:30 UTC, Kapps wrote: On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: This is what I did with OpenGL for my own bindings. It had some nice benefits like having the documentation be (mostly) accessible. Unfortunately, turns out the spec contains a lot of typos, including wrong arguments / function names. And I should clarify, ahead of time to generate a .d file, not at compile-time. :P Yea, by "directly", I meant using D templates and CTFE, not a script that generates a D file. For my own project, since I just need the function names, I'm using a Python script to generate a CSV file from the OpenGL spec, then importing/parsing that with D. It's neat, but slows down the build a lot. I haven't had any issues with typos, though. What about all the other layers (currently) found in the LunarG SDK? Without them its just toying around with Vulkan. Porting them manually seems a lot of work, how can this be tackled automatically?
Re: Will code for master title
On Tuesday, 20 October 2015 at 06:52:18 UTC, Ali Çehreli wrote: Two names come to mind: - Chuck Allison uses D when teaching functional programming at Utah Valley University: https://www.youtube.com/watch?v=ymoIx3klQ6M - Carl Sturtivant taught D during a summer course: http://forum.dlang.org/post/yutwxozxoqrfalzfs...@forum.dlang.org Ali Thanks Ali, I will contact them.
Re: Will code for master title
On Monday, 19 October 2015 at 23:36:19 UTC, Mathias Lang wrote: If you're in Magdeburg, and my German geography is not way off, you're about 2 hours away from Berlin, where we hold a meetup for D enthusiasts every 3rd friday of the month (http://www.meetup.com/Berlin-D-Programmers/). Also, I think one of the regular attendee works at an university (though I'm not 100% sure). I'll see if I can get in touch with him. That would be great, thanks a lot, please feel free to send me a pm if something comes up. Your geography is right and I am following the Berlin meetups since its first announcement, always wanted to participate, never managed. I hope I can attend DConf 2016, maybe even present some results of my thesis :-)
Re: Will code for master title
On Monday, 19 October 2015 at 21:47:33 UTC, qznc wrote: Supervisors like thesis work which fits into their ongoing research projects. Maybe you can find someone who has a long-term C/C++ project and building onto that with D is interesting? I agree and that is the problem. Its kind of tough to mix personal interests with faculty interests if they are nonconforming. To be honest I would not expect a long term C/C++ project to accept a D contribution if the supervisors are not aware of D as they will and should be worried about the maintainability? Anyway thanks. I'm professionally not a good fit, since we [0] work on compilers not visualization. Personally, I'm not a good fit, because I hope to be gone in five months. [0] http://pp.ipd.kit.edu/ Best of luck for your hopes :-)
Re: Will code for master title
On Monday, 19 October 2015 at 19:50:40 UTC, Mengu wrote: hi in the meanwhile gsoc ist hier und wir haben einige interessante Projekte. (my tarzan german) Even though I am not aware of the tarzan dialect I do understand it perfectly :-) see http://wiki.dlang.org/GSOC_2015_Ideas. Craig Dillabaugh will put up 2016 ideas soon. I wasn't aware of that wiki entry but I looked up GSoC before my request. These are cool opportunities, however, I would say that my request is less demanding financially (no stipend required) and supervision (don't expect much supervision, leave it up to the adviser) vise. Thanks!
Will code for master title
Hello Community, I am a master student of Computational Visualistics / Computer Science shortly before starting my master thesis. This means I could (and also would love to) spend about five month exclusively working on and writing about a D project. Unfortunately no professor at my university (OvGU in Magdeburg, Germany) can be found who is aware of dlang and would agree to supervise such a project. This led to an interesting idea: According to the European Credit Transfers System (ECTS) I have earned 270 CPs (30 per semester) as requirement for the master thesis, which is worth 30 additional CPs. Also according to ECTS it should be possible to transfer this amount of CPs to another University (with a ten semester bachelor and master system) and write the master thesis independently from the university where those credits were earned. Last ingredient I would need for such a plan is an academic primary adviser. My personal interest is the combination of cs and art, in particular I would like to write about and create a creative coding library similar to the auroragraphics announcement, processing, cinder or openFrameworks. I feel that D with its easy to read syntax and expressiveness is predestined to produce creative art and that dlang should have a modern, efficient and user-friendly art framework. If supervising such a thesis is an interesting, feasible and legal (university vise) option, please step up. Some more words in general. I don't know how many of you are in the lucky position to code on interesting D projects for a living but I guess that most contribute as hobbyists in their spare time. I also imagine that there are several students, like me, interested in contributing full-time (for a certain period) to the D ecosystem. If there are Academics interested in supervising such projects it might be worth to put up suggestions and request in the wiki similar to the new job openings. Cheers, ParticlePeter
Re: "More Libraries" - sub-forum request
On Saturday, 4 April 2015 at 20:34:47 UTC, Kapps wrote: On Saturday, 4 April 2015 at 16:43:45 UTC, ParticlePeter wrote: Hi, there is this nice new link to "More libraries" link, but there is no place to discuss usage, exchange experiences or ask questions regarding these libraries ( unless I am missing something ). A sub-forum here would be very nice. Or would this here be the right place ? I am trying out dimgui on win8, dmd 2.066.1 and now 2.067. Got 16 warnings, no error, BUT: "Building .dub\lib\imgui_d.lib failed!" How to debug this ? Regards, ParticlePeter If you're compiling with dub, I believe that warnings are by default treated as errors. I'm not sure if there's a switch to change that, but you could add wi to the compiler flags in dub.json. Thank you very much, a similar idea solved the problem: in dub.json add "buildRequirements": ["allowWarnings"]
Re: "More Libraries" - sub-forum request
On Saturday, 4 April 2015 at 16:51:44 UTC, Tobias Pankrath wrote: On Saturday, 4 April 2015 at 16:43:45 UTC, ParticlePeter wrote: Hi, there is this nice new link to "More libraries" link, but there is no place to discuss usage, exchange experiences or ask questions regarding these libraries ( unless I am missing something ). A sub-forum here would be very nice. Or would this here be the right place ? I am trying out dimgui on win8, dmd 2.066.1 and now 2.067. Got 16 warnings, no error, BUT: "Building .dub\lib\imgui_d.lib failed!" How to debug this ? Regards, ParticlePeter Tag your post with []. If threads with such tags get overboard we can consider a forum. See my reply above, especially about "digitalmars.D.dwt" and "digitalmars.D.dtl". Those should be combined in digitalmars.D.libraries, and inside of this forum I would use [dimgui] in my topic.
Re: "More Libraries" - sub-forum request
On Saturday, 4 April 2015 at 16:50:57 UTC, John Colvin wrote: On Saturday, 4 April 2015 at 16:43:45 UTC, ParticlePeter wrote: Hi, there is this nice new link to "More libraries" link, but there is no place to discuss usage, exchange experiences or ask questions regarding these libraries ( unless I am missing something ). A sub-forum here would be very nice. Or would this here be the right place ? digitalmars.D.learn would be more appropriate. A certain amount of discussion inevitably happens in response to release announcements in digitalmars.D.announce. I will post my "how to debug" question there, but I think that the lib is kind of broken and it does not make sense to point this out in d.learn. Moreover, last work was don 7 month ago, and I even don't know if it was announced at all. Some things would be appropriate as github (or bitbucket, or wherever) issues in the relevant project. Not thought of that, as I might be missing something and wanted to ask before filing a bug. Discussions here (digitalmars.D) should - in theory - be relevant to core language/libraries development. I agree, questions regarding libraries do not belong here. But there is lot of talk going on lately about d ecosystem, shouldn't be there a place to discuss parts of such ecosystem in the d forum ? Having "digitalmars.D.dwt" and "digitalmars.D.dtl" sub-forum ( have you tried googling or search the d wiki for "dtl" ? ;-) ), but no d libraries, feels kind of wired.
"More Libraries" - sub-forum request
Hi, there is this nice new link to "More libraries" link, but there is no place to discuss usage, exchange experiences or ask questions regarding these libraries ( unless I am missing something ). A sub-forum here would be very nice. Or would this here be the right place ? I am trying out dimgui on win8, dmd 2.066.1 and now 2.067. Got 16 warnings, no error, BUT: "Building .dub\lib\imgui_d.lib failed!" How to debug this ? Regards, ParticlePeter
