Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 06:36:49 UTC, Dmitri Makarov wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html No, but I'm building an embedded dsl that will allow to generate opencl kernels and supporting boilerplate opencl api calls at compile-time. it's called clop (openCL OPtimizer). It uses derelict.opencl bindings. How would it be used? At the client level, I mean.
Re: Reggae v0.0.5 super alpha: A build system in D
On Friday, 3 April 2015 at 19:54:09 UTC, Dicebot wrote: On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote: I just tried compiling one of my project. It has a makefile that does separate compilation and a shell script I use for unit testing which compiles everything in one go. The makefile takes 5.3 seconds, does not including linking since it builds a library. The shell script takes 1.3 seconds which include compiling unit tests and linking as well. change one file and see which one is faster with an incremental build. I don't care if incremental build is 10x faster if full build still stays at ~1 second. However I do care (and consider unacceptable) if support for incremental builds makes full build 10 seconds long. I'm of the opposite opinion. I don't care if full builds take 1h as long as incremental builds are as fast as possible. Why would I keep doing full builds? That's like git cloning multiple times. What for? What's clear is that I need to try Andrei's per-package idea, at least as an option, if not the default. Having a large D codebase to test it on would be nice as well, but I don't know of anything bigger than Phobos. Atila
Re: Reggae v0.0.5 super alpha: A build system in D
On 2015-04-03 19:54, Dicebot wrote: 2) Ironically, it is just very slow. Those who come from C world got used to using separate compilation to speed up rebuilds but it doesn't work that way in D. It may look better if you change only 1 or 2 module but as amount of modified modules grows, incremental rebuild quickly becomes _slower_ than full program build with all files processed in one go. It can sometimes result in order of magnitude slowdown (personal experience). BTW, are all the issues with incremental rebuilds solved? I.e. templates not outputted to all object files and other problems I can't remember right now. -- /Jacob Carlborg
[Issue 14404] Class nested within function cannot be created
https://issues.dlang.org/show_bug.cgi?id=14404 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- TypeInfo_Create.create() takes no parameter, so it cannot create nested classes with valid context pointer. Today it's filled by null, and any accesses to the enclosing context will cause Access Violation. I'm not sure what's expected 'fix' for the issue. The class Foo is declared inside main(), so constructing Foo instance by using TypeInfo_Create.create() in main() is definitely redundant. Are you requiring the create() call should throw a runtime exception for the impossible nested class construction? --
Re: Reggae v0.0.5 super alpha: A build system in D
On 4/4/15 1:30 AM, Atila Neves wrote: On Friday, 3 April 2015 at 19:49:04 UTC, Andrei Alexandrescu wrote: On 4/3/15 11:06 AM, Atila Neves wrote: It's true that it's not always faster to compile each module separately, I already knew that. It seems to me, however, that when that's actually the case, the practical difference is negligible. Even if 10x slower, the linker will take longer anyway. Because it'll all still be under a second. That's been my experience anyway. i.e. It's either faster or it doesn't make much of a difference. Whoa. The difference is much larger (= day and night) on at least a couple of projects at work. Even when only one file has changed? Yes; due to interdependencies, it's rare that only one file gets compiled. -- Andrei
Re: Dgame RC #1
On Saturday, 4 April 2015 at 02:34:59 UTC, Craig Dillabaugh wrote: One small note about the tutorials. In the tutorial on Game Loop and Event handling: http://rswhite.de/dgame5/?page=tutorialtut=handle_events In the first example, I believe you are missing an import for Dgame.Window.Event. It shows up int the second example, so no big deal, but I figured I should let you know. Are the tutorials on GitHub too? Craig Hey thanks for the note, but Dgame.Window is a package import: https://github.com/Dgame/Dgame/blob/master/source/Dgame/Window/package.d As you can see, the Event is public imported. And yes, the tutorials (the source codes) are on Github: https://github.com/Dgame/Dgame-Tutorial With an click on Show Raw on the tutorial page you can get the snippet also. :)
Re: Has anyone used D with Nvidia's Cuda?
Also consider costs: NVIDIA will artificially limit the speed of pinned memory transferts to push you to buy expensive $3000 discrete GPUs. They have segmented the market to make the most of people performance-starved. It goes to the point that you are left with $3000 GPUs that are slower than $300 ones, just to get the right driver. Hopefully the market will correct them after so much milking.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html No, but I'm building an embedded dsl that will allow to generate opencl kernels and supporting boilerplate opencl api calls at compile-time. it's called clop (openCL OPtimizer). It uses derelict.opencl bindings.
Re: Reggae v0.0.5 super alpha: A build system in D
On Friday, 3 April 2015 at 19:49:04 UTC, Andrei Alexandrescu wrote: On 4/3/15 11:06 AM, Atila Neves wrote: It's true that it's not always faster to compile each module separately, I already knew that. It seems to me, however, that when that's actually the case, the practical difference is negligible. Even if 10x slower, the linker will take longer anyway. Because it'll all still be under a second. That's been my experience anyway. i.e. It's either faster or it doesn't make much of a difference. Whoa. The difference is much larger (= day and night) on at least a couple of projects at work. Even when only one file has changed? Atila
Re: Issue with free() for linked list implementation
Namespace: I've written a straight forward linked list implementation here: https://github.com/nomad-software/etcetera/blob/master/source/etcetera/collection/linkedlist.d Even though I'm using the GC to manage memory, maybe it will help you. Good idea to link to some existing code. Here is mine: https://github.com/Dgame/m3/blob/master/source/m3/List.d In 99%+ of cases it's a bad idea to use a linked list. Bye, bearophile
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 2:34 AM, weaselcat wrote: On Saturday, 4 April 2015 at 09:24:07 UTC, Walter Bright wrote: If the latter is obsolete, it should perhaps be updated to point to the newer one. The svn one is the first google hit for Derelict. Top 3 results for me for `dlang derelict` are all his github page/projects, did you just google `derelict` or? `D programming language derelict` In any case, the dsource.org page should be fixed or removed. The github page also has problems, * the Using Derelict link is dead * DerelictUtil for Users has zero information about using D with CUDA, and seems completely irrelevant * no link for DerelictUtil Wiki * the example shown is useless * there are no examples of actually running code on a GPU It looks like nothing more than a couple header files (which is a great start, but that's all). In contrast, there's a package to use CUDA with Go: https://archive.fosdem.org/2014/schedule/event/hpc_devroom_go/ which is still pretty thin, but much further along.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 10:03:56 UTC, Walter Bright wrote: On 4/4/2015 2:35 AM, ponce wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html I wrote the Driver and Runtime API bindings for https://github.com/DerelictOrg/DerelictCUDA And the one thing I've done with them is loading the functions, create a context and destroy it. So yeah I think using CUDA with D is possible. Thank you. How far are you interested in going with it? Not far. I'm currently trying to bootstrap a business solo (hopefully with the help of D) and available time has became significantly sparser. I'd much prefer pass time on Derelict OpenCL bindings (brought to you by MeinMein) if time was an option. OpenCL 2.x is much more interesting though. It's slower: Furthermore, in studies of straightforward translation of CUDA programs to OpenCL C programs, CUDA has been found to outperform OpenCL;[83][86] but the performance differences can mostly be attributed to differences in the programming model (especially the memory model) and in the optimizations that OpenCL C compilers performed as compared to those in the CUDA compiler. -- http://en.wikipedia.org/wiki/OpenCL#Portability.2C_performance_and_alternatives It used to be that CUDA had warps and pinned memory and OpenCL didn't. Now OpenCL 2.0 has several driver providers and also has warps (sub-groups) and associated warp operations which are super useful for performance. To the extent that I wouldn't recommend building anything new in CUDA. I don't really see what could make OpenCL it slower. But I see really well what is dangerous in making new projects in CUDA nowadays. I was certainly burned by it to some extent. The newest CUDA features don't improve performance (Unified Memory Addressing, Peer copy, and friends). OpenCL compiles to FPGAs, CPUs, GPUs, and has no missing features anymore. We must now forget what was once true about it. With Intel OpenCL SDK even tooling is on par with NVIDIA. No reason not to support both, however. Yep.
Re: Allegro 5.1 + LDC + iOS Breath Of Life
On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote: Seemed worth mentioning before I snooze. My daughter and I just got a little touch app running on an iPad using D and Allegro 5.1. Really nothing major, but it does work. Just dragging some text around the screen with my finger and displaying time via std.datetime. Using latest allegro5 at sourceforge and these: https://github.com/SiegeLord/DAllegro5 5.1 branch https://github.com/smolt/ldc-iphone-dev I'll put something up on github in a week or so when the recipe is cleaned up. My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). -- Dan Fantastic news! Will try it this weekend.
Allegro 5.1 + LDC + iOS Breath Of Life
Seemed worth mentioning before I snooze. My daughter and I just got a little touch app running on an iPad using D and Allegro 5.1. Really nothing major, but it does work. Just dragging some text around the screen with my finger and displaying time via std.datetime. Using latest allegro5 at sourceforge and these: https://github.com/SiegeLord/DAllegro5 5.1 branch https://github.com/smolt/ldc-iphone-dev I'll put something up on github in a week or so when the recipe is cleaned up. My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). -- Dan
Re: Mid-term vision review
On 2015-04-04 01:00, Iain Buclaw via Digitalmars-d wrote: Summary of sources in first link, those familiar with DMD internals will understand what the glue methods more or less do. It's not like there's a lot of documentation for the DMD internals ;) -- /Jacob Carlborg
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 09:24:07 UTC, Walter Bright wrote: If the latter is obsolete, it should perhaps be updated to point to the newer one. The svn one is the first google hit for Derelict. Top 3 results for me for `dlang derelict` are all his github page/projects, did you just google `derelict` or?
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 2:16 AM, John Colvin wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html http://code.dlang.org/packages/derelict-cuda I know you have interest in CUDA, have you gotten any D code to work with it?
Re: Has anyone used D with Nvidia's Cuda?
On 4/04/2015 11:26 p.m., Walter Bright wrote: On 4/4/2015 3:04 AM, weaselcat wrote: PR? Exactly! The idea is that GPUs can greatly accelerate code (2x to 1000x), and if D wants to appeal to high performance computing programmers, we need to have a workable way to program the GPU. At this point, it doesn't have to be slick or great, but it has to be doable. Nvidia appears to have put a lot of effort into CUDA, and it shouldn't be hard to work with CUDA given the Derelict D headers, and will give us an answer to D users who want to leverage the GPU. It would also be dazz if someone were to look at std.algorithm and see what could be accelerated with GPU code. On that idea, just a thought. But DMD-FE is using the visitor pattern quite a lot to allow the backend to hook into it easily. What if we exposed a set block of code, to CTFE that acted like a backend, but only transformed for the real backend. In other words, allow CTFE to extend the compiler a little like the backend does. To add language features such as transform x code into OpenCL code and have it wrapped nicely into D code. Theoretically if this was done, we could move the iasm into library. Because of CTFE, surely this wouldn't add much code to the front end?
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 10:26:27 UTC, Walter Bright wrote: On 4/4/2015 3:04 AM, weaselcat wrote: PR? Exactly! The idea is that GPUs can greatly accelerate code (2x to 1000x), and if D wants to appeal to high performance computing programmers, we need to have a workable way to program the GPU. At this point, it doesn't have to be slick or great, but it has to be doable. Nvidia appears to have put a lot of effort into CUDA, and it shouldn't be hard to work with CUDA given the Derelict D headers, and will give us an answer to D users who want to leverage the GPU. It would also be dazz if someone were to look at std.algorithm and see what could be accelerated with GPU code. A good OpenCL wrapper library like cl4d would do wonders.
Re: Trouble with Cortex-M Hello World
On 4 April 2015 at 01:17, Kai Nacke via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 3 April 2015 at 15:39:33 UTC, Iain Buclaw wrote: That's a bit greedy of them to not upstream fixes. :-) I don't know why this change was not upstreamed - it's from 2012! BTW: There are some places in constfold.c and ctfeexpr.c which are also not endian-clean. And also not upstream... Just search LDC source for __LITTLE_ENDIAN__. Regards, Kai I had a look, you should definitely raise PRs for those. Iain.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 09:50:09 UTC, Walter Bright wrote: On 4/4/2015 2:34 AM, weaselcat wrote: On Saturday, 4 April 2015 at 09:24:07 UTC, Walter Bright wrote: If the latter is obsolete, it should perhaps be updated to point to the newer one. The svn one is the first google hit for Derelict. Top 3 results for me for `dlang derelict` are all his github page/projects, did you just google `derelict` or? `D programming language derelict` In any case, the dsource.org page should be fixed or removed. The github page also has problems, * the Using Derelict link is dead * DerelictUtil for Users has zero information about using D with CUDA, and seems completely irrelevant * no link for DerelictUtil Wiki * the example shown is useless * there are no examples of actually running code on a GPU PR? It looks like nothing more than a couple header files (which is a great start, but that's all). In contrast, there's a package to use CUDA with Go: https://archive.fosdem.org/2014/schedule/event/hpc_devroom_go/ which is still pretty thin, but much further along. AFAIK almost all derelict repos are maintained almost solely by aldacron, and he maintains a _lot_ of them. https://github.com/DerelictOrg p.s., googling golang cuda comes up with almost nothing useful at the top - 4-5 links to the FOSDEM video and some pdfs. I'm not being biased, I seriously can't figure out anything beyond the fosdem video for cuda with go. First result for dlang cuda for me is the dub repo for derelict cuda.
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 2:35 AM, ponce wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html I wrote the Driver and Runtime API bindings for https://github.com/DerelictOrg/DerelictCUDA And the one thing I've done with them is loading the functions, create a context and destroy it. So yeah I think using CUDA with D is possible. Thank you. How far are you interested in going with it? OpenCL 2.x is much more interesting though. It's slower: Furthermore, in studies of straightforward translation of CUDA programs to OpenCL C programs, CUDA has been found to outperform OpenCL;[83][86] but the performance differences can mostly be attributed to differences in the programming model (especially the memory model) and in the optimizations that OpenCL C compilers performed as compared to those in the CUDA compiler. -- http://en.wikipedia.org/wiki/OpenCL#Portability.2C_performance_and_alternatives No reason not to support both, however.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 10:07:16 UTC, Walter Bright wrote: On 4/4/2015 2:16 AM, John Colvin wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html http://code.dlang.org/packages/derelict-cuda I know you have interest in CUDA, have you gotten any D code to work with it? I use OpenCL as I don't want to be locked to one vendor's hardware. It's hard enough to write portable, efficient GPGPU code without swapping frameworks as well.
Re: Has anyone used D with Nvidia's Cuda?
The programmer describes the computations to be done on a device,
invokes the clop compiler via mixin expression passing the string
describing the computations in an OpenCL-like syntax. The compiler
returns D code that includes the generated OpenCL kernel and all the
boiler plate code. The computations can refer to variables declared in
the host application, CLOP will generate the necessary CL buffers and
kernel arguments. Here's an example:
// use CLOP DSL to generate OpenCL kernel and API calls.
mixin( compile(
q{
int max3( int a, int b, int c )
{
int k = a b ? a : b;
return k c ? k : c;
}
Antidiagonal NDRange( c : 1 .. cols, r : 1 .. rows ) {
F[c, r] = max3( F[c - 1, r - 1] + S[c + cols * r], F[c - 1, r] -
penalty, F[c, r - 1] - penalty );
} apply( rectangular_blocking( 8, 8 ) )
} ) );
This implements Needleman-Wunsch algorithm in CLOP. It says that the
computation to be done over 2D index space 1..cols by 1..rows. It
requires anti-diagonal synchronization pattern, meaning that the
elements on every anti-diagonal of the index space can be processed in
parallel, but there is global synchronization point between the
diagonals. Also the user requests to optimize this using rectangular
blocking. The variables: cols, rows, S, F, penalty are normal D
variables declared and defined in the application that contains the
above mixin statement.
You can look at my github repository for more examples
https://github.com/dmakarov/clop but the project is in very early
stage and not yet usable.
Regards,
Dmitri
On Sat, Apr 4, 2015 at 9:00 AM, Vlad Levenfeld via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 4 April 2015 at 06:36:49 UTC, Dmitri Makarov wrote:
On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote:
http://www.nvidia.com/object/cuda_home_new.html
No, but I'm building an embedded dsl that will allow to generate
opencl kernels and supporting boilerplate opencl api calls at
compile-time. it's called clop (openCL OPtimizer). It uses
derelict.opencl bindings.
How would it be used? At the client level, I mean.
Re: Reggae v0.0.5 super alpha: A build system in D
On Friday, 3 April 2015 at 19:45:38 UTC, Andrei Alexandrescu wrote: On 4/3/15 10:10 AM, Dicebot wrote: On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote: . Separate compilation. One file changes, only one file gets rebuilt This immediately has caught my eye as huge no in the description. We must ban C style separate compilation, there is simply no way to move forward otherwise. At the very least not endorse it in any way. Agreed. D build style should be one invocation per package. -- Andrei Just to clarify, reggae has: 1. Low-level building blocks that can be used for pretty much anything 2. High-level convenience rules There's nothing about #1 that forces per-module compilation. It doesn't force anything, it's just data definition. The current implementations of #2, namely dExe and the dub integration spit out build systems that compiler per module but that can be easily changed or even configured. Even now it's perfectly possible to define a build system for a D project with per package compilation, it'll just take more typing. Atila
Re: OpenVG bindings
On Friday, 3 April 2015 at 22:53:51 UTC, ddos wrote: Hi folks, today i've created my first dlang library ^_^ a binding to the OpenVG library standard. The referenced implementation is ShivaVG which allows to draw vector graphics within an OpenGL context (similar to cairo). A small demo application is included, using derelict gl3 and glfw3 https://github.com/oggs91/OpenVG_D http://code.dlang.org/packages/dopenvg Thx. I'll give it a try because it matches something i've started last week. I could use Cairo but a few years ago i've already gave up something similar because of the bad performances (Cairo is made and dedicated to inkscape, isn't it ?). Are OpenVG perfs better? This lib is quite unknown btw.
Re: Has anyone used D with Nvidia's Cuda?
On 4/3/2015 11:12 PM, weaselcat wrote: On Saturday, 4 April 2015 at 02:59:46 UTC, Rikki Cattermole wrote: On 4/04/2015 3:49 p.m., Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html Honestly, I don't think anyone has even tried to create bindings. Let alone use it. Although I think there are OpenCL bindings floating around which has a similar purpose. Derelict offers cuda bindings. Ahh, I see: https://github.com/DerelictOrg/DerelictCUDA I don't see it here: http://svn.dsource.org/projects/derelict/branches/Derelict2/doc/index.html If the latter is obsolete, it should perhaps be updated to point to the newer one. The svn one is the first google hit for Derelict.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 10:03:56 UTC, Walter Bright wrote: It's slower: However, it's an open standard, will improve, and will be available on devices of any vendor interested in implementing the compiler and the runtime API, which is essentially every vendor of compute devices (CPU, GPU, FPGA, or other accelerators). CUDA will be for Nvidia hardware only. (Not that I am against providing CUDA support for D programmers).
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 09:50:09 UTC, Walter Bright wrote: * there are no examples of actually running code on a GPU I can contribute at least three examples running code on a GPU (the domains are neural networks, bioinformatics, and grid traversal -- these are my ports to D/OpenCL of Rodinia benchmarks http://www.cs.virginia.edu/~skadron/wiki/rodinia/index.php/Rodinia:Accelerating_Compute-Intensive_Applications_with_Accelerators), but these examples using OpenCL, not in CUDA.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 10:26:27 UTC, Walter Bright wrote: On 4/4/2015 3:04 AM, weaselcat wrote: PR? Exactly! The idea is that GPUs can greatly accelerate code (2x to 1000x), and if D wants to appeal to high performance computing programmers, we need to have a workable way to program the GPU. At this point, it doesn't have to be slick or great, but it has to be doable. Nvidia appears to have put a lot of effort into CUDA, and it shouldn't be hard to work with CUDA given the Derelict D headers, and will give us an answer to D users who want to leverage the GPU. It would also be dazz if someone were to look at std.algorithm and see what could be accelerated with GPU code. I really think you're barking up the wrong tree here - cuda is a closed proprietary solution only implemented by one vendor effectively cutting off anyone that doesn't work with nvidia hardware. also, the std.algorithm thing sounds a lot like the C++ library Bolt/Thrust https://github.com/HSA-Libraries/Bolt
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 02:59:46 UTC, Rikki Cattermole wrote: On 4/04/2015 3:49 p.m., Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html Honestly, I don't think anyone has even tried to create bindings. Let alone use it. Although I think there are OpenCL bindings floating around which has a similar purpose. Derelict offers cuda bindings.
[Issue 14327] Unhandled exception from writeln() in C++/D application
https://issues.dlang.org/show_bug.cgi?id=14327 --- Comment #9 from Szymon Gatner szymon.gat...@gmail.com --- I assume that was agnerated by VisualD: set PATH=D:\devel\D\dmd2\windows\\bin;C:\Program Files (x86)\Windows Kits\8.1\\\bin;%PATH% set DMD_LIB=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\\lib\amd64;C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64 set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.1\ set VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\ C:\Program Files (x86)\VisualD\pipedmd.exe dmd -lib -m64 -g -debug -X -XfDebug\dlib.json -deps=Debug\dlib.dep -ofDebug\dlib.lib -map Debug\dlib.map lib.d if errorlevel 1 goto reportError if not exist Debug\dlib.lib (echo Debug\dlib.lib not created! goto reportError) goto noError :reportError echo Building Debug\dlib.lib failed! :noError --
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html http://code.dlang.org/packages/derelict-cuda
Re: Issue with free() for linked list implementation
On Saturday, 4 April 2015 at 09:05:03 UTC, bearophile wrote: Namespace: I've written a straight forward linked list implementation here: https://github.com/nomad-software/etcetera/blob/master/source/etcetera/collection/linkedlist.d Even though I'm using the GC to manage memory, maybe it will help you. Good idea to link to some existing code. Here is mine: https://github.com/Dgame/m3/blob/master/source/m3/List.d In 99%+ of cases it's a bad idea to use a linked list. Bye, bearophile The thread creator wanted to use it.
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html I wrote the Driver and Runtime API bindings for https://github.com/DerelictOrg/DerelictCUDA And the one thing I've done with them is loading the functions, create a context and destroy it. So yeah I think using CUDA with D is possible. OpenCL 2.x is much more interesting though.
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 3:04 AM, weaselcat wrote: PR? Exactly! The idea is that GPUs can greatly accelerate code (2x to 1000x), and if D wants to appeal to high performance computing programmers, we need to have a workable way to program the GPU. At this point, it doesn't have to be slick or great, but it has to be doable. Nvidia appears to have put a lot of effort into CUDA, and it shouldn't be hard to work with CUDA given the Derelict D headers, and will give us an answer to D users who want to leverage the GPU. It would also be dazz if someone were to look at std.algorithm and see what could be accelerated with GPU code.
Re: Placing variable/array in a particular section
On Saturday, 4 April 2015 at 02:57:22 UTC, Rikki Cattermole wrote: On 4/04/2015 3:08 a.m., Jens Bauer wrote: src/start.d:7:10: error: module attribute is in file 'gcc/attribute.d' which cannot be read import gcc.attribute; ^ Uhm, it seems that druntime is required for that; unfortunately it's not ported to the Cortex-M platform. I found the attribute.d file and tried a quick copy-and-paste, but no luck there. Correction: minlibd *is* a druntime port; just a minimal one. However, I'm not sure this feature is supported yet. Timo Sintonen did a lot of great work; perhaps getting this detail supported might not require much sweat. ;) Yeah, contact the GDC guys, they should be able to help you. Either the GDC newsgroup or as an issue on the compiler's project. A-ha! I just discovered this page... http://www.digitalmars.com/NewsGroup.html Atleast at this point, keep an open mind. Think of what you are doing as testing the current state :) I will, though my impression until now, is that the compiler is quite mature. (I accept that there will always be some minor issues when moving to a new system, but that does not drag down the quality of the compiler).
Re: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 09:50:09 UTC, Walter Bright wrote: * the example shown is useless The problem with example is that someone have to maintain them. For DerelictBgfx we removed all translated examples. So the Derelict policy is to remove example to avoid them becoming out of date. For the record Aldacron maintains approx. 22 Derelict bindings and I maintain 7 of them, in our free time. Keeping up with all library change is impossible if everyone excpect everything to be up-to-date and with examples. * there are no examples of actually running code on a GPU Because it's similar to using the Driver/Runtime API in C++, you have to read CUDA documentation. It looks like nothing more than a couple header files (which is a great start, but that's all). Maybe we can delete them so that it's not too embarrassing? Serious proposal. In my opinion, the couple header files provide all you need to use CUDA, if you know what you are doing. If you don't, don't do GPGPU.
[Issue 14405] New: Private class std.typecons.Foo conflicts with local class
https://issues.dlang.org/show_bug.cgi?id=14405
Issue ID: 14405
Summary: Private class std.typecons.Foo conflicts with local
class
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: r...@rcorre.net
There is a private class named Foo defined in std.typecons (currently line
3091) that can conflict with a user-defined class when unittest is enabled.
--- file foo.d
module foo;
class Foo { }
---
--- file fail.d
import std.typecons;
import foo;
unittest { auto f = new Foo; }
---
rdmd -unittest -main fail.d
fail.d(5): Error: std.typecons.Foo at
/usr/include/dlang/dmd/std/typecons.d(2892) conflicts with foo.Foo at foo.d(2)
fail.d(5): Error: module fail class std.typecons.Foo is private
--
Re: Allegro 5.1 + LDC + iOS Breath Of Life
On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote: Seemed worth mentioning before I snooze. My daughter and I just got a little touch app running on an iPad using D and Allegro 5.1. Really nothing major, but it does work. Just dragging some text around the screen with my finger and displaying time via std.datetime. Using latest allegro5 at sourceforge and these: https://github.com/SiegeLord/DAllegro5 5.1 branch https://github.com/smolt/ldc-iphone-dev I'll put something up on github in a week or so when the recipe is cleaned up. My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). -- Dan Awesome! Been waiting for this.
Port of Maxon C4D API from C++ to D.
Hello, To learn D a bit more I have partially ported C4D API from C++ to D language. Second purpose of this project was to look how well D can be conned to C++. For the case that some one is curious about this, here is the Github repository. https://github.com/Remotion/DforC4D thanks, Remo
Re: Benchmark of D against other languages
On 4/2/15 11:20 PM, Laeeth Isharc wrote: On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote: I found this repository (reddit!) that hosts common benchmarks for many languages such as D, Nim, Go, python, C, etc... It uses only standard structures not to influence the benchmark. https://github.com/kostya/benchmarks Thanks for this. BTW, some of these benchmarks were taken from attractivechaos here. He seems to be working in bioinformatics and does not consider himself a programmer by profession. But has written some libraries others use, and is clearly bright and thoughtful. He is pro-D and sad people have not recognized its qualities. https://attractivechaos.wordpress.com/ He contributed some samples and pull requests to the Crystal repository and he's always very humble and does good observations and suggestions. I don't recall seeing him say anything bad about any language: just some benchmarks and how they behave, let the benchmarks (and code) speak for him :-)
Re: std.reflection prototype
On Thursday, 2 April 2015 at 06:57:25 UTC, Jacob Carlborg wrote: On 2015-04-02 02:28, bitwise wrote: If I'm understanding correctly, doing it this way is to avoid making changes to the compiler, right? I don't understand this decision because it seems that most of the needed infrastructure is already built into ModuleInfo, and that it just needs to be completed. It would eliminate the problem of template/code bloat from a library like mine, and at the same time, would not require the user to register any types. As I said, the reason for implementing RTInfo for modules was to _not_ have to register anything. There are other good use cases for both RTInfo and RMInfo (runtime module info), they are a more generic solution. Two other threads about unit testing [1], [2] is a good use case. RMInfo can be used to collect all unit test functions and create a custom runner. Here's [3] one example where a unit test runner makes it possible to have CTFE unit tests. This proof of concept only scans the current module, here RMInfo would be really handy to scan all modules. Here's [4] one example where RTInfo is used to check virtual methods. All virtual methods are required to be marked with @virtual. There's a lot of missing info in ModuleInfo and TypeInfo. For example MemberInfo_function contains no information about parameters, return types, attributes and so on. [1] http://forum.dlang.org/thread/mfcgj3$12a0$1...@digitalmars.com [2] http://forum.dlang.org/thread/mfci6o$13oa$1...@digitalmars.com [3] http://forum.dlang.org/thread/ks1brj$1l6c$1...@digitalmars.com [4] http://forum.dlang.org/thread/kok86c$126l$1...@digitalmars.com Ok, I think I understand what you're suggesting now, which is that you want a library to be able to override RTInfo in order to add it's own metadata to all types, which raises the question, what if more than one library wants to add metadata? And I think this question was addressed by the suggestion of the AA for RTInfo where the module's fully qualified name was the key, which won't work because of separate compilation... right? So in my case I could just update my RTInfo to generate a reflection for each type, and make it accessible using a UFC or something. If I understand correctly though, the idea has been dismissed as being impossible due to separate compilation, right? Is there any leads on this at this point?
[Issue 11438] Internal error: ..\ztc\cod4.c 358 from alias this and a cast
https://issues.dlang.org/show_bug.cgi?id=11438 Lukasz Wrzosek luk.wrzo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||luk.wrzo...@gmail.com Resolution|--- |FIXED --- Comment #1 from Lukasz Wrzosek luk.wrzo...@gmail.com --- DMD 2.67 works with the test case: bug.d(10): Error: cannot cast expression irrelevant of type int* to blah_ptr --
Re: I submitted my container library to code.dlang.org
On Friday, 3 April 2015 at 20:41:26 UTC, Martin Nowak wrote: A global random hash seed would work, but it needs to be accessible for reproducing test cases (druntime DRT option or in core.runtime). I think, leave the seed zero and only provide a function to change it: extern(C) void _d_setHashSeed(int seed); Then applications will set it to whatever value they want. The function shouldn't be broadly exposed as only server frameworks will need it.
Re: D, Python, and Chapel
On Fri, 2015-04-03 at 15:34 +, John Colvin via Digitalmars-d wrote: […] I've had a look at Chapel and I don't get what the big deal is. It's PGAS programming, so you control the whole parallel computation in a single program. Though for clustering you may have to suffer MPI and hence an element of SPMD nastiness. Also there can be problems distinguishing cores, processors, and computers – the hardware has three levels of parallelism, PGAS only two. There's some nice syntax and good thinking about parallelism in there*, but I don't see what's exciting after that... Maybe D has spoiled me for seeing power in a language. I believe it would be most useful to unpack this to try and decide what D has right, what Chapel has right, what D has wrong and what Chapel has wrong. My thinking here is that Chapel seems to have everything needed for the practicing (not practising, though maybe that as well) HPC programmer. D has lots but the core parallelism story is classic single bus and so cannot handle the core/processor/computer split that is easy with Chapel. I guess what I'm saying is I can see that they've put a lot of thought in to good abstractions for parallelism in HPC, we should steal a bunch of it because D is eminently capable of supporting similar abstractions, while being a much more rounded language in other regards. But what does D have that people using Chapel should be demanding? This is not to tell Brad et al. what they need to look at, but that as well, more to say, why would these people consider D if the parallelism message of D was stronger. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D, Python, and Chapel
On Fri, 2015-04-03 at 17:11 +, Paulo Pinto via Digitalmars-d wrote: […] The big deal is that is being developed in open collaboration with most companies and research labs that matter in HPC. As is X10. Cray and Washington University (Chapel) vs. IBM (X10) It's sad that Fortress got canned, that was a really interesting player in the PGAS language game. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.reflection prototype
On 5/04/2015 4:41 a.m., bitwise wrote: I love the idea of it. But first we need to finish off what support we damn well have in druntime. m_offTi for TypeInfo_Class currently is not being generated. We also need some form of RTInfo for modules. Not just for symbols. This alone will open up quite a few doors! Ok, I'm starting to understand this idea a little better. Is anyone currently working on generating m_offTi? I don't think so. I looked into it, and it looks to be pretty low hanging and easy to do. I'm just not setup *grumbles*.
What's the current status of GC in phobos?
Hi! Today I met one guy on the internet, he said that he will use D only if standard library will not require Garbage Collector (in case of total GC disabling). So what's the current status of GC in Phobos? :^) I've heard there has been some work on it. Regards, Alex
Re: Mid-term vision review
On Saturday, 4 April 2015 at 22:05:33 UTC, H. S. Teoh wrote: On Sat, Apr 04, 2015 at 09:15:01PM +, weaselcat via Digitalmars-d wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team? I thought it was public knowledge for a while now that eventually we're gonna do this switch? It was just a matter of time. I mean, Daniel Murphy hasn't exactly been keeping hush-hush about progress on ddmd all this time. T I was just curious, didn't mean it to come off any other way : )
[Issue 14407] New: No protection and attributes check for class/struct allocator in NewExp
https://issues.dlang.org/show_bug.cgi?id=14407
Issue ID: 14407
Summary: No protection and attributes check for class/struct
allocator in NewExp
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Test case:
a.d:
deprecated class C
{
private deprecated new (size_t, string)
{
return null;
}
private this(int) {}
}
deprecated struct S
{
private deprecated new (size_t, string)
{
return null;
}
private this(int) {}
}
b.d:
import a;
void main() pure nothrow @safe @nogc
{
//auto c = new(arg) C(0);
// Deprecation: class a.C is deprecated
// Deprecation: class a.C is deprecated -- duplicated message
// -- no attribute errors for allocator
// -- no access error for allocator
// Error: pure function 'D main' cannot call impure function 'a.C.this'
// Error: safe function 'D main' cannot call system function 'a.C.this'
// Error: @nogc function 'D main' cannot call non-@nogc function 'a.C.this'
// Error: class a.C member this is not accessible
// Deprecation: class a.C is deprecated
// Error: constructor this is not nothrow
// Error: function 'D main' is nothrow yet may throw
auto s = new(arg) S(0);
// Same with class new
}
--
Re: Order of evaluation of a += a++;
On Tuesday, 31 March 2015 at 08:17:31 UTC, Andrei Alexandrescu
wrote:
On 3/31/15 12:18 AM, Orvid King wrote:
I might be a bit confused here, but from what you're saying:
b += a++;
and
b += ++a;
Are doing the same thing in DMD?
No. Lowering of e1 += e2++ is:
e1 += e2++
-\
(ref a, b) { a = (cast(typeof(a)) (a + b); }(
e1,
(ref a) { auto x = a; ++a; return x; }(e2)
)
whereas lowering of e1 += ++e2 is:
e1 += ++e2
-\
(ref a, b) { a = (cast(typeof(a)) (a + b); }(
e1,
(ref a) { ++a; return a; }(e2)
)
Andrei
Fixed in SDC.
Re: What's the current status of GC in phobos?
On Sunday, 5 April 2015 at 02:23:47 UTC, MarisaLovesUsAll wrote: Hi! Today I met one guy on the internet, he said that he will use D only if standard library will not require Garbage Collector (in case of total GC disabling). So what's the current status of GC in Phobos? :^) I've heard there has been some work on it. Regards, Alex BTW, there is some people that dislikes D because of GC. If it's possible to write GC-free code, people should know about GC disabling. We aim to make the standard library usable in its entirety without a garbage collector. Maybe phobos no-GC update will be a good opportunity. And thanks for the D, it's awesome. :^) Regards, Alex
[Issue 14406] GIT HEAD ignores forward reference and generates wrong code
https://issues.dlang.org/show_bug.cgi?id=14406
--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
This is an accepts-invalid bug. Slightly reduced:
class Foo {}
string str_mixin(T)()
{
static if (T.tupleof.length) {} // Fix instance size of T (== Frop)
return Bar bar_obj; static class Bar { Foo foo; };
}
class Frop
{
mixin(str_mixin!(typeof(this))); // adding more field after Frop fields
fixed.
}
void main()
{
Frop simple = new Frop;
}
In str_mixin() function, testing Frop.tupleof fix the class fields and instance
size. Therefore adding one more field `bar_obj` should be rejected because it
will change the Frop instance size.
--
[Issue 14392] Operator overload is shadowed by alias this
https://issues.dlang.org/show_bug.cgi?id=14392 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- FWIW this code fails to compile before 2.064 (specifically, before this PR: https://github.com/D-Programming-Language/dmd/pull/1409) --
[Issue 14405] Private class std.typecons.Foo conflicts with local class
https://issues.dlang.org/show_bug.cgi?id=14405 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- The Foo class was introduced here: https://github.com/D-Programming-Language/phobos/pull/1414 --
Re: Reggae v0.0.5 super alpha: A build system in D
On Saturday, 4 April 2015 at 19:56:28 UTC, Dicebot wrote: On Saturday, 4 April 2015 at 07:44:12 UTC, Atila Neves wrote: On Friday, 3 April 2015 at 19:54:09 UTC, Dicebot wrote: On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote: I just tried compiling one of my project. It has a makefile that does separate compilation and a shell script I use for unit testing which compiles everything in one go. The makefile takes 5.3 seconds, does not including linking since it builds a library. The shell script takes 1.3 seconds which include compiling unit tests and linking as well. change one file and see which one is faster with an incremental build. I don't care if incremental build is 10x faster if full build still stays at ~1 second. However I do care (and consider unacceptable) if support for incremental builds makes full build 10 seconds long. I'm of the opposite opinion. I don't care if full builds take 1h as long as incremental builds are as fast as possible. Why would I keep doing full builds? That's like git cloning multiple times. What for? What's clear is that I need to try Andrei's per-package idea, at least as an option, if not the default. Having a large D codebase to test it on would be nice as well, but I don't know of anything bigger than Phobos. At work I often switch between dozen of different projects a day with small chunk of changes for each. That means that incremental builds are never of any value. Even if you consistently work with the same project it is incredibly rare to have a changeset contained in a single module. And if there are at least 5 changed modules (including inter-dependencies) it becomes long enough already. As for test codebase - I know that Martin has been testing his GC improvements on Higgs (https://github.com/higgsjs/Higgs), could be a suitable test subject for you too. It seems our workflows are very different. Half of the time I make changes to a file that only contains unit tests. That's always self contained, and doing anything else except for recompiling that one file and relinking is going to be slower. It seems to me that different projects might benefit from different compilation strategies. It might just be a case of unit tests alongside production code vs in separate files. As mentioned before, my experience with per-module compilation was usually faster, but I'm going to change the default to be per package. Another cool thing about using reggae to build itself was building the unit test and production binaries at the same time. I couldn't really do that with dub alone.
[Issue 14406] New: GIT HEAD ignores forward reference and generates wrong code
https://issues.dlang.org/show_bug.cgi?id=14406
Issue ID: 14406
Summary: GIT HEAD ignores forward reference and generates wrong
code
Product: D
Version: unspecified
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
Reduced test.
// assertion fails -- both bar_obj and foo should be null though
class Foo {}
string str_mixin(T)() {
alias P = Poo!T;
return Bar bar_obj;
static class Bar { Foo foo; };
}
template Poo(T) {
static if(T.tupleof.length) {};
}
class Frop {
mixin(str_mixin!(typeof(this)));
}
void main() {
Frop simple = new Frop;
assert(simple.bar_obj.foo is null, foo is not null);
}
--
[Issue 14407] No protection and attributes check for class/struct allocator in NewExp
https://issues.dlang.org/show_bug.cgi?id=14407 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4555 --
[Issue 14406] [REG2.068a] GIT HEAD ignores forward reference and generates wrong code
https://issues.dlang.org/show_bug.cgi?id=14406 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||accepts-invalid, pull, ||wrong-code Hardware|x86_64 |All Version|unspecified |D2 Summary|GIT HEAD ignores forward|[REG2.068a] GIT HEAD |reference and generates |ignores forward reference |wrong code |and generates wrong code OS|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4556 --
Vibe.d json to csv
So I am using vibe.d json module to parse some array data with
homogeneous objects, and I want to convert it to CSV.
Aside from encoding double-qoutes, this is want I came up with to
generate the header:
```
void csvHeader(const Json jsonObject)
{
return keys(jsonObject.get!(Json[string])).stdMap!(a
=``~a~``).joiner(,);
}
```
I can probably use zip to get the quotes around the names, to
avoid concatenation. But it works fine the way it is. The problem
is, the following doesn't:
```
void csvRow(const Json jsonObject)
{
return values(jsonObject.get!(Json[string])).stdMap!(a
=``~a~``).joiner(,);
}
```
source\app.d(84): Error: template std.algorithm.joiner cannot
deduce function from argument types !()(MapResult!(__lambda3,
const(Json)[]), string), candidates are:
std\algorithm.d(3403): std.algorithm.joiner(RoR, Separator)(RoR
r, Separator sep) if (isInputRange!RoR
isInputRange!(ElementType!RoR) isForwardRange!Separator
is(ElementType!Separator : ElementType!(ElementType!RoR)))
std\algorithm.d(3670): std.algorithm.joiner(RoR)(RoR r) if
(isInputRange!RoR isInputRange!(ElementType!RoR))
[Issue 14406] GIT HEAD ignores forward reference and generates wrong code
https://issues.dlang.org/show_bug.cgi?id=14406 --- Comment #1 from Puneet Goel pun...@coverify.org --- 2.067-rc1 does not compile the code. Regression only for GIT HEAD. --
Yes, you can help std.allocator!
Following up on Brian's nice offer:
What's going on with std.allocator? I have a few projects (some on
Github, some at EMSI) that use it because it seemed like it was on
its way to being in Phobos. What can I do to help with this?
Things are going well with std.allocator. I broke the code into a
package with modules, which makes it quite nice to deal with. Also I
just implemented a simple heterogeneous freelist allocator akin to the
Kernighan-Ritchie one:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_kernighan_ritchie.html
I did so more for demo/historical perspective purposes. I plan to add
the part that adds new chunks on a need basis as a separate artifact.
Now there _is_ something I could help with.
Right now the allocator design works well as a flexible malloc/free
implementation, but has no support for tracing-based garbage collection.
I am evaluating whether I should add tracing capabilities to
std.allocator, or stop here. Tracing would most definitely require new
primitives such as embedding some sort of type information and resolving
internal pointers.
What would really help this evaluation and any other work on garbage
collection would be a modularization of the tracing process.
I'm envisioning a simple API that separates the system-dependent part of
the tracer (stopping all threads, finding the roots in the globals, TLS,
and stack) from what the collector is supposed to proceed with the tracing.
So I'm thinking e.g. of a range that would iterate through all untyped
words on all stacks as void* data.
foreach (void* p; GC.traceAllStacks)
{
...
}
Then we'd have typed data in TLS and globals. I guess those would come
as ranges of Tuple!(void[], Typeinfo) or something similar.
I'm sure I'm glossing over a number of details, so I'd need an expert in
the GC workings to help me connect std.allocator with it. Once the GC
has a low-level tracing API, I can figure what primitives I need to add
to std.allocator to accommodate tracing.
Thanks!
Andrei
Re: Yes, you can help std.allocator!
On 5/04/2015 3:16 p.m., Andrei Alexandrescu wrote:
Following up on Brian's nice offer:
What's going on with std.allocator? I have a few projects (some on
Github, some at EMSI) that use it because it seemed like it was on
its way to being in Phobos. What can I do to help with this?
Things are going well with std.allocator. I broke the code into a
package with modules, which makes it quite nice to deal with. Also I
just implemented a simple heterogeneous freelist allocator akin to the
Kernighan-Ritchie one:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_kernighan_ritchie.html
I did so more for demo/historical perspective purposes. I plan to add
the part that adds new chunks on a need basis as a separate artifact.
Now there _is_ something I could help with.
Right now the allocator design works well as a flexible malloc/free
implementation, but has no support for tracing-based garbage collection.
I am evaluating whether I should add tracing capabilities to
std.allocator, or stop here. Tracing would most definitely require new
primitives such as embedding some sort of type information and resolving
internal pointers.
What would really help this evaluation and any other work on garbage
collection would be a modularization of the tracing process.
I'm envisioning a simple API that separates the system-dependent part of
the tracer (stopping all threads, finding the roots in the globals, TLS,
and stack) from what the collector is supposed to proceed with the tracing.
So I'm thinking e.g. of a range that would iterate through all untyped
words on all stacks as void* data.
foreach (void* p; GC.traceAllStacks)
{
...
}
Then we'd have typed data in TLS and globals. I guess those would come
as ranges of Tuple!(void[], Typeinfo) or something similar.
I'm sure I'm glossing over a number of details, so I'd need an expert in
the GC workings to help me connect std.allocator with it. Once the GC
has a low-level tracing API, I can figure what primitives I need to add
to std.allocator to accommodate tracing.
Thanks!
Andrei
Moving the GC out of druntime, might be an interesting proposition.
Pro:
- D is no longer garbage collected
- Easier to swap implementations
Cons:
- Technically none for the embedded guys
- Quite a lot of work to get the current GC refactored into new design
- Good bit of changes to phobos/druntime
But this would most likely go a long way towards the goal of @nogc I think.
[Issue 14387] Disallow string literals as assert conditions
https://issues.dlang.org/show_bug.cgi?id=14387 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Don from comment #1) IMHO it's also pretty weird that string literals are implicitly convertable to bool. Note that they weren't convertable in D1: assert(abc); and if(abc) both generated compile-time errors. I don't think that was an intentional change, but I could be wrong. For non-static assert, D1 and D2 pre 2.023 say: test.d(4): Error: expression test of type invariant(char[4u]) does not have a boolean value From 2.023 changelog: the type of a string literal is now invariant(char)[] rather than invariant(char)[length_of_string]. It is still implicitly convertible to the latter. This is intended to reduce template instantiation bloat. This is a case of dynamic arrays implicitly converting to bool whether they're null or non-null. So, this will automatically be fixed when implicit array-to-bool conversion is deprecated ( https://github.com/D-Programming-Language/dmd/pull/2885 ). --
[Issue 14405] Private class std.typecons.Foo conflicts with local class
https://issues.dlang.org/show_bug.cgi?id=14405 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Underlying cause is issue 1238 --
Re: Mid-term vision review
weaselcat wrote in message news:rspoyryeklgjychqf...@forum.dlang.org... Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team? The ldc and gdc teams have been involved since the first discussions at dconf13.
Re: Order of evaluation of a += a++;
On 4/4/15 7:54 PM, deadalnix wrote:
On Tuesday, 31 March 2015 at 08:17:31 UTC, Andrei Alexandrescu wrote:
On 3/31/15 12:18 AM, Orvid King wrote:
I might be a bit confused here, but from what you're saying:
b += a++;
and
b += ++a;
Are doing the same thing in DMD?
No. Lowering of e1 += e2++ is:
e1 += e2++
-\
(ref a, b) { a = (cast(typeof(a)) (a + b); }(
e1,
(ref a) { auto x = a; ++a; return x; }(e2)
)
whereas lowering of e1 += ++e2 is:
e1 += ++e2
-\
(ref a, b) { a = (cast(typeof(a)) (a + b); }(
e1,
(ref a) { ++a; return a; }(e2)
)
Andrei
Fixed in SDC.
Awesome, thanks! -- Andrei
Re: Mid-term vision review
On Sat, Apr 04, 2015 at 04:31:06PM -0700, Walter Bright via Digitalmars-d wrote: On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote: Besides, even if you could, you're just one person, whereas gdc/ldc have a much larger number of contributors, some of whose specialty is optimization. Do you realistically think you can singlehandedly outdo all of them? I did for decades, until the early 2000's or so when I began spending all my time on the front end. [...] Well, yes, that's because we need you more on DMDFE than on the backend, and that's why there will probably never be enough time for you to do everything you need to do with the backend. And that's why the backend will probably never be as good as gdc/ldc. T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
Re: What's the current status of GC in phobos?
On 4/4/15 7:23 PM, MarisaLovesUsAll wrote: Hi! Today I met one guy on the internet, he said that he will use D only if standard library will not require Garbage Collector (in case of total GC disabling). So what's the current status of GC in Phobos? :^) I've heard there has been some work on it. Regards, Alex The short answer is there's progress on that, which I expect to accelerate soon. But we're not there yet. -- Andrei
Re: What's the current status of GC in phobos?
On Sunday, 5 April 2015 at 02:23:47 UTC, MarisaLovesUsAll wrote: Hi! Today I met one guy on the internet, he said that he will use D only if standard library will not require Garbage Collector (in case of total GC disabling). So what's the current status of GC in Phobos? :^) I've heard there has been some work on it. Regards, Alex I expect 2.068 to be the first version of D really usable without the GC if we get std.allocator/@nogc smartpointers/etc, but I might just be sticking my foot in my mouth right now. : )
[Issue 14408] New: std.process: Can't start interactive process from Windows GUI application
https://issues.dlang.org/show_bug.cgi?id=14408 Issue ID: 14408 Summary: std.process: Can't start interactive process from Windows GUI application Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com If a Windows GUI application (dmd -L/SUBSYSTEM:WINDOWS) tries to spawn cmd.exe, bash.exe etc., the latter will exit immediately. This is because it is created with the GUI application's standard input/output streams, which will be invalid, and cmd/bash will immediately encounter an EOF or read error and exit. --
[Issue 14409] New: false positive Error: one path skips constructor
https://issues.dlang.org/show_bug.cgi?id=14409
Issue ID: 14409
Summary: false positive Error: one path skips constructor
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Test case:
class B { this(int) {} }
class C : B
{
this(int n)
{
if (true)// line 6
super(n);
else
assert(0);
}
}
Output:
test.d(6): Error: one path skips constructor
test.d(4): Error: return without calling constructor
--
[Issue 14409] false positive Error: one path skips constructor
https://issues.dlang.org/show_bug.cgi?id=14409 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Issue 14376? --
[Issue 14376] [REG2.064] false positive Error: one path skips field
https://issues.dlang.org/show_bug.cgi?id=14376 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All Version|unspecified |D2 OS|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4557 The field initialization check and this/super call check are implemented by using same logic. So there's a similar issue 14409. --
[Issue 14409] false positive Error: one path skips constructor
https://issues.dlang.org/show_bug.cgi?id=14409 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4557 (In reply to Vladimir Panteleev from comment #1) Issue 14376? Yes, it's related. --
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 3:45 AM, weaselcat wrote: I really think you're barking up the wrong tree here - cuda is a closed proprietary solution only implemented by one vendor effectively cutting off anyone that doesn't work with nvidia hardware. That's right. On the other hand, 1. Nvidia hardware is pervasive, and CUDA has been around for many years. I doubt it is going away anytime soon. 2. It is little effort on our part to support it. 3. We'd have some co-marketing opportunities with Nvidia if we support it. 4. Supporting CUDA doesn't impede supporting OpenCL. also, the std.algorithm thing sounds a lot like the C++ library Bolt/Thrust https://github.com/HSA-Libraries/Bolt Yup.
[dimgui] building results in 16 warnings, no error BUT: Building .dub\lib\imgui_d.lib failed!
Hi, am still searching for the right place to ask library related questions, and was advised to ask them here. The dimgui library looks interesting for my projects ( https://github.com/d-gamedev-team/dimgui ), but I don't manage to get it built or run the examples. I have no clue what's going wrong, as I just get a FAIL message. I use Win 8.1, dmd 2.067 ( and 2.066.1 before that ). I tried to build with dub: FAIL .dub\build\library-debug-windows-x86-dmd_2067-C976DEDDFC09960A5E012C28B5036DF0\ imgui staticLibrary Error executing command run: dmd failed with exit code 1. as well as created visualD project files and build with VS2013: Building .dub\lib\imgui_d.lib failed! How to debug this ? Or anyone with dimgui experience ? Regards, ParticlePeter
Re: Allegro 5.1 + LDC + iOS Breath Of Life
On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote: My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). Best of luck to her.
[Issue 13906] etc.c.zlib is out of date
https://issues.dlang.org/show_bug.cgi?id=13906 e10s electrolysis.j...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from e10s electrolysis.j...@gmail.com --- It has been successfully updated to 1.2.8 on the latest D release, 2.067.0. https://github.com/D-Programming-Language/phobos/pull/2900 --
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 3:58 AM, John Colvin wrote: On Saturday, 4 April 2015 at 10:07:16 UTC, Walter Bright wrote: On 4/4/2015 2:16 AM, John Colvin wrote: On Saturday, 4 April 2015 at 02:49:16 UTC, Walter Bright wrote: http://www.nvidia.com/object/cuda_home_new.html http://code.dlang.org/packages/derelict-cuda I know you have interest in CUDA, have you gotten any D code to work with it? I use OpenCL as I don't want to be locked to one vendor's hardware. It's hard enough to write portable, efficient GPGPU code without swapping frameworks as well. A reasonable viewpoint.
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 4:16 AM, ponce wrote: Also consider costs: NVIDIA will artificially limit the speed of pinned memory transferts to push you to buy expensive $3000 discrete GPUs. They have segmented the market to make the most of people performance-starved. It goes to the point that you are left with $3000 GPUs that are slower than $300 ones, just to get the right driver. Hopefully the market will correct them after so much milking. The only thing I can add to that is the people who really want performance will be more than willing to buy the GPU to do it and the $3000 means nothing to them. I.e. people to whom microseconds means money, such as trading software. I don't want to leave any tern unstoned. Also, it seems that we are 95% there in supporting CUDA already. thanks to your header work. Just need to write some examples to make sure it works, and write a few pages of how to do it. Once that is done, we can approach Nvidia and get them to mention on their site that D supports CUDA. Nvidia is really pushing CUDA, and it will be of mutual benefit for them to promote D and us to support CUDA.
Re: Reggae v0.0.5 super alpha: A build system in D
On Saturday, 4 April 2015 at 07:44:12 UTC, Atila Neves wrote: I'm of the opposite opinion. I don't care if full builds take 1h as long as incremental builds are as fast as possible. Why would I keep doing full builds? That's like git cloning multiple times. What for? Full build is important when you do it only once, e.g. if you want to try new version of a program and it's not precompiled, you'll need to compile it from source and never recompile.
Re: unittests are really part of the build, not a special run
On 4/4/15 10:38 AM, Nordlöw wrote: Please also think about how such a builtin feature would promote establishment and usage of D from a robustness and productivity point of view. I do think it's a great idea. Sadly I also think how I have negative staff to put to work on it. -- Andrei
Re: Allegro 5.1 + LDC + iOS Breath Of Life
Szymon Gatner noem...@gmail.com writes: On Saturday, 4 April 2015 at 08:14:13 UTC, Dan Olson wrote: Seemed worth mentioning before I snooze. My daughter and I just got a little touch app running on an iPad using D and Allegro 5.1. Really nothing major, but it does work. Just dragging some text around the screen with my finger and displaying time via std.datetime. Using latest allegro5 at sourceforge and these: https://github.com/SiegeLord/DAllegro5 5.1 branch https://github.com/smolt/ldc-iphone-dev I'll put something up on github in a week or so when the recipe is cleaned up. My daughter heads off to college this fall to work towards a video game design degree, so I've enlisted her to build an interesting demo as a summer project (my own summer of code). -- Dan Fantastic news! Will try it this weekend. Szymon, you will have to tinker some because the allegro iphone xcode project to build the static lib does not work as is (some relative paths are wrong), and DAllegro has ALLEGRO_WIP_VERSION = 8, but latest allegro source on 5.1 branch is WIP 10. This makes al_init() fail (actually al_install_system()), because the versions don't match. I just modifed DAlllegro ALLEGRO_WIP_VERSION = 10 to see what would happen, and ok so far. Might be fine to back off to allegro source with 5.1.8 tag, but I did not do that. The other thing is that main entry is different for iOS. You need to define a _al_mangled_main() that initializes the D runtime. I'll put up some hints on gist until I can make a proper repo: https://gist.github.com/smolt/7fa1ecfd295a6baaa8b3
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
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 22:50:29 UTC, Sönke Ludwig wrote: Am 24.03.2015 um 23:14 schrieb John Colvin: On Tuesday, 24 March 2015 at 21:31:42 UTC, Martin Nowak wrote: On 03/24/2015 10:11 PM, John Colvin wrote: This cannot be added to homebrew until there is a new stable release of dub. Why is that? Anyhow dub is in beta and ready soon. Current stable dub fails to build with 2.067.0, so it would break the homebrew dub package. You mean 2.067.0 fails to build DUB, right? I just had a hard time remembering anything that DUB would have to do differently when building something with 2.067.0 ;) I think we can tag an RC in the current state, all important fixes are done, AFAIK. How's the RC going?
Re: std.reflection prototype
I love the idea of it. But first we need to finish off what support we damn well have in druntime. m_offTi for TypeInfo_Class currently is not being generated. We also need some form of RTInfo for modules. Not just for symbols. This alone will open up quite a few doors! Ok, I'm starting to understand this idea a little better. Is anyone currently working on generating m_offTi?
Re: More Libraries - sub-forum request
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. Some things would be appropriate as github (or bitbucket, or wherever) issues in the relevant project. Discussions here (digitalmars.D) should - in theory - be relevant to core language/libraries development.
Re: More Libraries - sub-forum request
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 [library name]. If threads with such tags get overboard we can consider a forum.
Re: Has anyone used D with Nvidia's Cuda?
On 4/4/2015 4:29 AM, ponce wrote: On Saturday, 4 April 2015 at 09:50:09 UTC, Walter Bright wrote: * the example shown is useless The problem with example is that someone have to maintain them. For DerelictBgfx we removed all translated examples. So the Derelict policy is to remove example to avoid them becoming out of date. For the record Aldacron maintains approx. 22 Derelict bindings and I maintain 7 of them, in our free time. Keeping up with all library change is impossible if everyone excpect everything to be up-to-date and with examples. Oh, I understand that keeping things up to date is always a problem with every third party tool. On the plus side, however, Nvidia seems very good with backwards compatiblity, meaning that when the D bindings get out of date, they will still work. They just won't work with new features. * there are no examples of actually running code on a GPU Because it's similar to using the Driver/Runtime API in C++, you have to read CUDA documentation. Of course. But having a couple examples to show it really does work will go a long way. I am not suggesting making any attempt to duplicate Nvidia's documentation in D. It looks like nothing more than a couple header files (which is a great start, but that's all). Maybe we can delete them so that it's not too embarrassing? Serious proposal. If that's the state of things, I'd be happy to take them over and put them in Deimos. In my opinion, the couple header files provide all you need to use CUDA, if you know what you are doing. If you don't, don't do GPGPU. That does work for someone who really wants to use CUDA, but not much for someone who is evaluating using D and wants to use the GPU with CUDA.
Re: Allegro 5.1 + LDC + iOS Breath Of Life
There is a lot of low hanging fruit to snatch. I think someone looking for fun could do something similar with SDL (it support iOS too), then adapt Dgame. -- Dan
Re: unittests are really part of the build, not a special run
On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu wrote: In brief: I'd like to transition to a model in which unittesting is organically part of the build. After all, you wouldn't want to deploy an application that's failing its unittests. Overall a good idea, Andrei. I take the opportunity to share a reoccurring dream of mine which is highly related to your proposal, Andrei: I would like to have a compiler option for *automatic persistent memoization* of unittests that are inferred to be strongly pure. Please take a moment to think about how your usage of unittests would change if this was available. Eventhough D compiles faster than all other languages, big projects (including my single-developer ones) will eventually grow so large that always waiting for all unittests to compile and run will not be bearable to a developer. The idea of persistent memoziation is not new (SCons does it an elegant with build artifacts). They just haven't been applied in as many cases as they could be. In theory it's just a matter of hashing all the code and data the a unittest depends upon and using this hash as a memoization key for remembering if the unittest failed (and perhaps also how) or now. However, I'm not sure how the memoization keys should be calculated in practise. I do however know that the ELF file format contains a BuildID attribute calculated as a SHA-1. Is there any builtin support in ELF for hashing individual functions and data (sections)? Is there at all possible to figure out what code a unittest depends upon? Please also think about how such a builtin feature would promote establishment and usage of D from a robustness and productivity point of view.
Re: unittests are really part of the build, not a special run
On Monday, 30 March 2015 at 23:51:17 UTC, Walter Bright wrote: I'd rather see DMD automatically pass the expression that triggered the error (as it is done in C) to replace this useless Unittest failure that forces me to look through the code. You have to look at the code anyway. My experience is that having the failing expression available speeds up the processing of figuring out what's wrong with my failing code. That's why I'm using https://github.com/nordlow/justd/blob/master/assert_ex.d
Re: Release D 2.067.0
Am 04.04.2015 um 18:43 schrieb John Colvin: On Tuesday, 24 March 2015 at 22:50:29 UTC, Sönke Ludwig wrote: Am 24.03.2015 um 23:14 schrieb John Colvin: On Tuesday, 24 March 2015 at 21:31:42 UTC, Martin Nowak wrote: On 03/24/2015 10:11 PM, John Colvin wrote: This cannot be added to homebrew until there is a new stable release of dub. Why is that? Anyhow dub is in beta and ready soon. Current stable dub fails to build with 2.067.0, so it would break the homebrew dub package. You mean 2.067.0 fails to build DUB, right? I just had a hard time remembering anything that DUB would have to do differently when building something with 2.067.0 ;) I think we can tag an RC in the current state, all important fixes are done, AFAIK. How's the RC going? Going well so far, there are some additional fixes in the current RC2. I'll tag the final release tomorrow or on Monday.
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.
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 [library name]. 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: Has anyone used D with Nvidia's Cuda?
On Saturday, 4 April 2015 at 17:16:19 UTC, Walter Bright wrote: On 4/4/2015 4:29 AM, ponce wrote: On Saturday, 4 April 2015 at 09:50:09 UTC, Walter Bright wrote: * the example shown is useless The problem with example is that someone have to maintain them. For DerelictBgfx we removed all translated examples. So the Derelict policy is to remove example to avoid them becoming out of date. For the record Aldacron maintains approx. 22 Derelict bindings and I maintain 7 of them, in our free time. Keeping up with all library change is impossible if everyone excpect everything to be up-to-date and with examples. Oh, I understand that keeping things up to date is always a problem with every third party tool. On the plus side, however, Nvidia seems very good with backwards compatiblity, meaning that when the D bindings get out of date, they will still work. They just won't work with new features. They doesn't seem to have deprecated any function indeed. That could make examples practical. * there are no examples of actually running code on a GPU Because it's similar to using the Driver/Runtime API in C++, you have to read CUDA documentation. Of course. But having a couple examples to show it really does work will go a long way. I am not suggesting making any attempt to duplicate Nvidia's documentation in D. It looks like nothing more than a couple header files (which is a great start, but that's all). Maybe we can delete them so that it's not too embarrassing? Serious proposal. If that's the state of things, I'd be happy to take them over and put them in Deimos. Sure, the licensing of Derelict probably allows it, and deimos and Derelict are complimentary anyway.
[Issue 12971] Missing REX prefix for 8 bit register access
https://issues.dlang.org/show_bug.cgi?id=12971 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=9965 --
[Issue 9965] Wrong Assembly For DIL, SIL Registers
https://issues.dlang.org/show_bug.cgi?id=9965 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=12971 --
