Re: Dragging Gunroar into 2014
On Mon, Mar 24, 2014 at 21:42:13 +, Ben Boeckel wrote: This is beyond my scope right now, but it's nice to know that other arch support (namely ARM) is in the works. As incentive for this, I've implemented 3 new modes tonight (though they're all untested, they at least compile ;) ): - TOUCH: virtual thumbsticks; - DOUBLE_PLAY_TOUCH: move the two ships in DOUBLE_PLAY with your thumbs; and - TILT: accelerometer and virtual thumbstick Modes will be available if you have the appropriate hardware (though a keyboard is always assumed at the moment). How hard is getting D code running Android in general? It seems that there are GDC builds available for it; is that all that is needed? --Ben
Re: Dragging Gunroar into 2014
I've had problems with the old CMake extensions for D as well. Are you planning on posting what you've done to make it work? I think I used the old CMakeD project and had to edit and delete a few files to get it to work, but I'm not sure how much functionality I'm missing because of that. Atila On Monday, 24 March 2014 at 18:35:47 UTC, Ben Boeckel wrote: [ Originally posted to Reddit: https://pay.reddit.com/r/d_language/comments/217fas/dragging_gunroar_into_2014/. ] I got an itch recently and started to port my favorite game from ABA Games[1] to 2014: gunroar[1]. Currently, it has been ported to using Derelict3 rather than Kenta Cho's manual wrapping of SDL and OpenGL. It now uses SDL2 and D2 rather than the (apparently) very ancient dialect of D it used back in 2005. When first starting out, the first problem was getting the code to build. I'm a CMake guy, and after looking around, I was…unsatisfied with the D support files I found (for various reasons). They all seemed to copy the C++ support files too closely which seemed unnecessary since dmd, ldc, and gdc are much closer to each other than many of the C++ compilers. They also all seem to have come from the scream make era when commands were in all caps, copied things around without realizing what they're there for (e.g., CMakeCompilerId.d.in is copied by most of them, but used by none and CMakeDCompilerABI.d is useless since what CMake looks for (compiled-in strings) isn't in the file), and were missing support for things like DEPFILE and such for proper dependency resolution. In this process, two patches were made that should help: one for Ninja[3] if LDC is used and one for CMake[4] so that you get proper recompilation when files change (other generators are not supported yet since I don't think anything else reads the -deps file format of LDC; GDC will work as-is since it's GCC-compatible here). Even without these patches, one-off builds will be correct, but incremental builds are not guaranteed. After that was the fun of getting LDC to actually accept the code. Luckily its errors are helpful even for initiates to D (the only other time I've done things with D is poking the source of various ABA Games years ago also trying to get them to compile on Linux with mixed results). Other than issues with replacing the deprecated glu* function usages, (most) things work on my machine (Fedora x86_64). I'd be interested to know how things work on other platforms and setups. Ultimately, I'd like to get some of these games on my tablet, so Android support is on the table (though help would be appreciated!). I've opened some issues for things on the repository already. (The other ABA Games I'm interested in are Mu-cade and Torus Troopers, so those are on my list as well.) [1]http://www.asahi-net.or.jp/~cs8k-cyu/games/index.html#windows [2]https://github.com/mathstuf/abagames-gunroar [3]https://github.com/martine/ninja/pull/721 [4]https://github.com/mathstuf/CMake/commit/9523d2a55c99fb0910531ae7160b099faeab6638
Re: Dragging Gunroar into 2014
On Tue, Mar 25, 2014 at 12:53:11 +, Atila Neves wrote:
I've had problems with the old CMake extensions for D as well. Are
you planning on posting what you've done to make it work? I think I
used the old CMakeD project and had to edit and delete a few files to
get it to work, but I'm not sure how much functionality I'm missing
because of that.
The stuff I'm using is in the repo[1]. The things that it doesn't do
that it should so far:
- support for anything other than Linux/{ldc,gdc};
- cross-compiling support;
- detecting the compiler architecture; and
- compiler version detection.
Other than that, the things it has over the CMakeD* projects I saw:
- proper dependencies based on import statements;
- gdc support;
- more modern CMake style; and
- unused/unnecessary code removed.
The problem with the compiler version and architecture detection is that
the way CMake currently does it for C/C++ is to compile a source file
with preprocessor-built strings and then greps the resulting binary for
ASCII strings and regex matches them to extract the information. Since D
doesn't have a preprocessor and I didn't see a way to find out the
compiler version or target architecture through built-in variables, this
support won't work without either CMake just asking the compiler
(requires CMake to know how to run the compiler to ask it...which may
depend on knowing the version), or to have some way of guaranteeing a
single, unbroken string that depends on the compiler show up in a D
executable.
I do plan on splitting it out at some point, but without a project
attached to it, testing is hard, so it's living in gunroar for now.
--Ben
[1]https://github.com/mathstuf/abagames-gunroar/tree/master/cmake
CMake with D support early snapshot
Hello all, Given the recent chatter and movement on CMake D support, I've decided to go public with a project of mine earlier than I had intended. Before I go further, a request: do *not* post this to HN/reddit/etc just yet. It is still in early stages and an upstream CMake 3.0 release (without D support) is incoming. Announcing this far and wide will only yield confusion at this time. So, what is this? It's CMake, with various modifications to work toward making D a first-class citizen of the CMake world. While other projects exist that attempt to add D support, they all do so without touching CMake's C++ sources. This means that they will inevitably fall short of the mark. Additionally, when I first started toying with this several months ago, there were a lot of implementation/design issues in the existing projects, that went against the way CMake's internals expect things to be done. I'm not sure how the current scene is in that regard. Status * GDC is fully supported, as is DMD master * LDC and older DMD's will work for simpler projects, but won't handle linking external libraries at the moment. I had a hack workaround for this before, but recently removed it when restructuring things a bit. * 32-bit DMD on Windows can't really be used for a C/C++/D mixed project right now because of problems I'm having with Optlink * VisualD generation works (tested on VS 2010 and VS 2012) * Makefile generation (and similar generators) work * Works on Windows and Linux. OS X ought to work, but is untested, as I don't have my OS X dev environment set up at the moment * D is listed on the CMake Qt GUI, which is nice Github: https://github.com/trentforkert/cmake Wiki: https://github.com/trentforkert/cmake/wiki Binaries: https://drive.google.com/folderview?id=0B5vzzNch4TtET09HM0NLWURKV1Uusp=drive_web#list As is tradition here, destroy! - Trent
Re: CMake with D support early snapshot
On Tue, Mar 25, 2014 at 17:50:30 +, Trent Forkert wrote: It's CMake, with various modifications to work toward making D a first-class citizen of the CMake world. While other projects exist that attempt to add D support, they all do so without touching CMake's C++ sources. This means that they will inevitably fall short of the mark. For full-featured support, I agree. Additionally, when I first started toying with this several months ago, there were a lot of implementation/design issues in the existing projects, that went against the way CMake's internals expect things to be done. I'm not sure how the current scene is in that regard. The compiler detection and such hasn't changed in CMake much (AFAICT), so if they weren't working as expected before, nothing has changed. * GDC is fully supported, as is DMD master * LDC and older DMD's will work for simpler projects, but won't handle linking external libraries at the moment. I had a hack workaround for this before, but recently removed it when restructuring things a bit. * 32-bit DMD on Windows can't really be used for a C/C++/D mixed project right now because of problems I'm having with Optlink * VisualD generation works (tested on VS 2010 and VS 2012) * Makefile generation (and similar generators) work * Works on Windows and Linux. OS X ought to work, but is untested, as I don't have my OS X dev environment set up at the moment * D is listed on the CMake Qt GUI, which is nice Much more comprehensive than my attempts :) . The depfile support would be nice to add in so that dependencies are calculated properly. Make will be left out with DMD/LDC, but GDC will work with Ninja and Make already (LDC/DMD+Ninja has a pull request with Ninja). I'll try it out when I get a chance. --Ben
Re: Soon Nick will be $75 richer...
On Wednesday, 19 March 2014 at 05:40:22 UTC, Nick Sabalausky wrote: On 3/18/2014 4:28 PM, Andrei Alexandrescu wrote: ... pending Martin's approval. https://d.puremagic.com/issues/show_bug.cgi?id=3490 https://www.bountysource.com/issues/1327154-dmd-never-inlines-functions-that-could-throw Heh, cool, thanks all :) Speaking of, I learned a lot about DMD's inliner while doing that, so I've posted an explanation of it on the Wiki: http://wiki.dlang.org/DMD_Source_Guide#Inliner Since it's based mainly on what I sussed out from looking at the source, it could probably use a look-over by a DMD guru in case I've misunderstood anything. That is awesome ! I wish I knew this existed earlier !
Formal review of dtoh
See: http://forum.dlang.org/thread/lgspgg$2i8l$1...@digitalmars.com -- /Jacob Carlborg
Re: 1st draft of complete class-based std.random successor
On Tuesday, 25 March 2014 at 00:08:27 UTC, bearophile wrote: I don't mind, I am happy :-) Thank you for adding a sorely needed function. You are very kind, and far too modest. :-)
