Re: Details of the inline import idiom
On Friday, 27 September 2019 at 03:37:53 UTC, TheGag96 wrote: I was looking back at the inline import idiom article[1]. One of the purported benefits of doing something like from!"std.datetime".SysTime was that doing so wouldn't go and import the entirety of the module into the namespace and slow down compile time / bloat the binary. But how is this so? When the template ends up doing import from = std.datetime, doesn't that go and import everything, not just SysTime? Or is there some detail I'm missing? Thanks! [1]: https://dlang.org/blog/2017/02/13/a-new-import-idiom/ If you write an import statement inside a template, that import isn't processed until the template is instantiated. For imports that are used inside the body of a template this is easy to do--you just put the import statement in the body of the struct/class/function/whatever. For imports used in template constraints or template function parameter lists, however, you can't do this; there's no place for the import to go. You end up having to put it at the top level of the module, and pay the cost for processing it even if the template that uses it is never instantiated. Of course, if you do end up instantiating the template, the import is processed regardless, and you don't gain anything. So this trick is really only worth it in modules that contain a bunch of different templates, only some of which will end up being used in any given program--in other words, modules like the ones in D's standard library.
Details of the inline import idiom
I was looking back at the inline import idiom article[1]. One of the purported benefits of doing something like from!"std.datetime".SysTime was that doing so wouldn't go and import the entirety of the module into the namespace and slow down compile time / bloat the binary. But how is this so? When the template ends up doing import from = std.datetime, doesn't that go and import everything, not just SysTime? Or is there some detail I'm missing? Thanks! [1]: https://dlang.org/blog/2017/02/13/a-new-import-idiom/
Help making a game with transparency
Hi guys, I am making a game but for some reason the sprites do not show with the transparent background that they were supposed to. I'm using the arsd library. Can anyone help me?
Re: Using D for Raspberry Pi expirements
On Thursday, 26 September 2019 at 00:10:40 UTC, aberba wrote: On Wednesday, 25 September 2019 at 23:56:45 UTC, aberba wrote: I'm looking for resources on using D for basic Raspberry Pi programming...stuff like turning on and off an LED light. I believe it requires being able to call the Raspberry OS core APIs from D as available in Python. Just found this package dating back from May 2016...let's see what it can do (https://github.com/fgheorghe/D-Lang-Raspbian-GPIO-Module) Anyone here tried something like that using D? I've been using https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ . It is a C library written by Bartosz Golaszewski. He is actively working on it. The latest update is a week old. It has the advantage that you don't have to use sudo to access the gpio pins. It comes with a set of tools written in C that I have been converting to D. Since my knowledge of both D and C is weak it has taken me some time to get things going. I have a hand written D bindings file that is incomplete and of amateur quality. So far I have converted 2 of the 6 command line tools that Bartosz Golaszewski provided to to work with the library. David Chapman
Re: Packaging and Distributing Dlang Applications with GtkD Dependency?
On Thursday, 26 September 2019 at 10:10:20 UTC, bioinfornatics wrote: I prefer to use meson a builder tool (same category tool as Make, CMake ...) doc: https://mesonbuild.com/Dlang-module.html Is better as it ease the packaging for fedora, debian, ubuntu and so on ... This is good to know. Thank you, bioinfornatics.
Re: Packaging and Distributing Dlang Applications with GtkD Dependency?
On Thursday, 26 September 2019 at 16:30:39 UTC, Andre Pany wrote: Dub is a tool for developers, I understand your requirements that you want target end customers of your applications. Therefore dub is the wrong tool for this job. To be more precise, gtkd is a wrapper for GTK. Gtkd is not interesting in this context, but the dependency on gtk. On windows you have the possibility to either publish your application with GTK dlls or to run gtk setup routine as part of your application setup routine or just say in your readme that the customer needs to run GTK setup on there own. On posix (linus, macos) of course you can also say in your readme that the customer should run apt-get ... to install gtk (here I do not have much knowledge on packaging). Kind regards Andre Excellent. That's exactly what I needed to know, Andre. Thanks very much.
Re: Packaging and Distributing Dlang Applications with GtkD Dependency?
On Wednesday, 25 September 2019 at 17:03:51 UTC, Ron Tarrant wrote: On Wednesday, 25 September 2019 at 13:52:48 UTC, bioinfornatics wrote: I think I misunderstood your need but are lo looking for dub tool with its repository https://code.dlang.org/ I don't think so, but I could be wrong. I tried reading up on dub, but got lost in the docs, so I really don't understand what all it can do. Dub is a tool for developers, I understand your requirements that you want target end customers of your applications. Therefore dub is the wrong tool for this job. To be more precise, gtkd is a wrapper for GTK. Gtkd is not interesting in this context, but the dependency on gtk. On windows you have the possibility to either publish your application with GTK dlls or to run gtk setup routine as part of your application setup routine or just say in your readme that the customer needs to run GTK setup on there own. On posix (linus, macos) of course you can also say in your readme that the customer should run apt-get ... to install gtk (here I do not have much knowledge on packaging). Kind regards Andre
Re: Inspecting __traits(isDeprecated) and deprecation warnings
On Wednesday, 25 September 2019 at 20:35:55 UTC, Boris Carvajal
wrote:
On Wednesday, 25 September 2019 at 14:20:00 UTC, Anonymouse
wrote:
I added some deprecations in my project and am going through
my templates trying to silence the warnings that suddenly
popped up. This template works, but it triggers deprecation
warnings when I am actively trying to avoid them.
This code seems to work for classes too and even with DMD "-de"
compiler switch.
template isMemberDeprecated(T, string name)
{
enum isMemberDeprecated = mixin(q{__traits(isDeprecated, },
T, ".", name, q{)});
}
https://run.dlang.io/is/iQbxOC
I think I can work with this, thanks!
Re: unable to link to python3.7m using pyd and conda
On Thursday, 26 September 2019 at 13:29:09 UTC, Cesar wrote: Hi, I am trying to get started using pyd with https://github.com/Superbelko/pyd-min as an example and I am getting an error from the linker: minpyd ~master: building configuration "application"... Linking... /usr/bin/ld: cannot find -lpython3.7m collect2: error: ld returned 1 exit status Error: linker exited with status 1 dmd failed with exit code 1. I did not modify anything from that sample code. This is a proof-of-concept and then I would move to a larger D project and Python library which uses a specific conda environment. If I take out the pyd subConfiguration from dub.json, the build succeeds but then it picks up my system-wide python 2.7. Does anyone know how I can indicate the linker where to look for python3.7m? How can I configure pyd to use python from my conda environment? As a small note, I am quite new to D, so I may have missed something obvious. Best regards Cesar I found what was wrong. The pyd subConfiguration of python37 was looking for my system-wide python37, which I did not have. To use the conda python, I ran the script from https://github.com/ariovistus/pyd/blob/master/setup/pyd_set_env_vars.sh: pyd_set_env_vars.sh And used subConfiguration "pyd": "env". When I did that, I got a runtime error about the libraries not being found, so then I added the flag LD_LIBRARY_PATH when running the executable: LD_LIBRARY_PATH=~/miniconda3/envs/MYENV/lib ./executable I still need to figure out how to move this flag into dub.son but for now it is working. Hope this helps out in case someone has the same problem. Cesar
unable to link to python3.7m using pyd and conda
Hi, I am trying to get started using pyd with https://github.com/Superbelko/pyd-min as an example and I am getting an error from the linker: minpyd ~master: building configuration "application"... Linking... /usr/bin/ld: cannot find -lpython3.7m collect2: error: ld returned 1 exit status Error: linker exited with status 1 dmd failed with exit code 1. I did not modify anything from that sample code. This is a proof-of-concept and then I would move to a larger D project and Python library which uses a specific conda environment. If I take out the pyd subConfiguration from dub.json, the build succeeds but then it picks up my system-wide python 2.7. Does anyone know how I can indicate the linker where to look for python3.7m? How can I configure pyd to use python from my conda environment? As a small note, I am quite new to D, so I may have missed something obvious. Best regards Cesar
Re: Packaging and Distributing Dlang Applications with GtkD Dependency?
On Thursday, 26 September 2019 at 10:07:34 UTC, bioinfornatics wrote: On Wednesday, 25 September 2019 at 17:03:51 UTC, Ron Tarrant wrote: On Wednesday, 25 September 2019 at 13:52:48 UTC, bioinfornatics wrote: I think I misunderstood your need but are lo looking for dub tool with its repository https://code.dlang.org/ I don't think so, but I could be wrong. I tried reading up on dub, but got lost in the docs, so I really don't understand what all it can do. dub is more or less like pip from python, npm from javascript and so on ... The code source is here: https://github.com/dlang/dub you can open an issue there or open a thread about how to write package file for dub doc: https://dub.pm/package-format-json) have a nice day I prefer to use meson a builder tool (same category tool as Make, CMake ...) doc: https://mesonbuild.com/Dlang-module.html Is better as it ease the packaging for fedora, debian, ubuntu and so on ...
Re: Packaging and Distributing Dlang Applications with GtkD Dependency?
On Wednesday, 25 September 2019 at 17:03:51 UTC, Ron Tarrant wrote: On Wednesday, 25 September 2019 at 13:52:48 UTC, bioinfornatics wrote: I think I misunderstood your need but are lo looking for dub tool with its repository https://code.dlang.org/ I don't think so, but I could be wrong. I tried reading up on dub, but got lost in the docs, so I really don't understand what all it can do. dub is more or less like pip from python, npm from javascript and so on ... The code source is here: https://github.com/dlang/dub you can open an issue there or open a thread about how to write package file for dub doc: https://dub.pm/package-format-json) have a nice day
Re: Inspecting __traits(isDeprecated) and deprecation warnings
On 9/25/19 11:35 PM, Boris Carvajal wrote:
On Wednesday, 25 September 2019 at 14:20:00 UTC, Anonymouse wrote:
I added some deprecations in my project and am going through my
templates trying to silence the warnings that suddenly popped up. This
template works, but it triggers deprecation warnings when I am
actively trying to avoid them.
This code seems to work for classes too and even with DMD "-de" compiler
switch.
template isMemberDeprecated(T, string name)
{
enum isMemberDeprecated = mixin(q{__traits(isDeprecated, }, T, ".",
name, q{)});
}
https://run.dlang.io/is/iQbxOC
It's really nice! Thank you.
