Re: Release D 2.069.0
On Monday, 9 November 2015 at 02:15:17 UTC, Andrei Alexandrescu wrote: On 11/8/15 2:58 PM, rsw0x wrote: Interestingly, GDC seems *very* popular - it has a 4:1 install rate of gccgo and only trailing slightly behind the golang-go package(reference compiler?) on Ubuntu's popcon. Link? -- Andrei debian: https://qa.debian.org/popcon-graph.php?packages=gdc%2Cgccgo%2Cgolang&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 ubuntu: http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gdc http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=golang-go http://ubuntu-popcon.43-1.org/cgi-bin/graph.pl?name=gccgo note that dmd is not redistributed on most linux distros due to licensing issues
Re: Release D 2.069.0
On 11/8/15 2:58 PM, rsw0x wrote: Interestingly, GDC seems *very* popular - it has a 4:1 install rate of gccgo and only trailing slightly behind the golang-go package(reference compiler?) on Ubuntu's popcon. Link? -- Andrei
Re: Release D 2.069.0
On 9/11/2015 10:25 AM, Jack Stouffer wrote: Is there any reason why this isn't currently used in the front end? Lack of testing, focus on matching c-dmd performance, it used to be blocked and nobody realized it wasn't any more etc.
Re: 2.069.0 Installation problem with .exe for Windows
On 11/04/2015 10:05 AM, Mike James wrote: > Copied here for extra visibility... > > Hi. > > There seems to be an install problem with the .exe version for > Windows. The installer removes the old DMD then doesn't install > the 2.069.0 version. In the task manager it's still running at > 50% CPU time. It fails on Windows Vista and Windows 7. Could some try and verify that this installer fixes the issue. I wasn't able to reproduce the issue myself. https://dlang.dawg.eu/downloads/dmd.2.069.0~fix15824/
Re: Release D 2.069.0
On Sunday, 8 November 2015 at 22:45:05 UTC, Daniel Murphy wrote: Actually I think it's fixed now, just disabled. It used to have problems with lib*/scan*, but those are in D now, and most of the allocations from the glue layer are being forwarded to the GC through rmem. If anyone wants to try it they just need to add -version=GC to the DMD build flags and insert this function in root/rmem.d's version(GC) block. extern (C) void* allocmemory(size_t m_size) { return GC.malloc(m_size); } Is there any reason why this isn't currently used in the front end?
Re: Release D 2.069.0
On 8/11/2015 1:41 AM, Dmitry Olshansky wrote: IMHO enabling D's GC in the frontend is better way to fix leaking in the CTFE, but there are some issues with that (it segfaults if we enable GC). Actually I think it's fixed now, just disabled. It used to have problems with lib*/scan*, but those are in D now, and most of the allocations from the glue layer are being forwarded to the GC through rmem. If anyone wants to try it they just need to add -version=GC to the DMD build flags and insert this function in root/rmem.d's version(GC) block. extern (C) void* allocmemory(size_t m_size) { return GC.malloc(m_size); }
Re: Release D 2.069.0
On Sunday, 8 November 2015 at 18:56:55 UTC, Andrei Alexandrescu wrote: On 11/03/2015 08:49 PM, Martin Nowak wrote: Glad to announce D 2.069.0. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/ This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements. See the changelog for more details. http://dlang.org/changelog/2.069.0.html -Martin This schedule seems to work well. Daily downloads on the rise - 28-days moving average almost 1400 as of today. Good work everyone and particularly thanks Martin for putting us on a schedule! http://erdani.com/d/downloads.daily.png Andrei This made me a bit interested on Linux package downloads, but the only sources seem to be self-reported so you can only compare it relatively. Interestingly, GDC seems *very* popular - it has a 4:1 install rate of gccgo and only trailing slightly behind the golang-go package(reference compiler?) on Ubuntu's popcon. Debian's shows nearly similar numbers. LDC is lagging severely behind on both - packaging issue?
Re: Release D 2.069.0
On 11/03/2015 08:49 PM, Martin Nowak wrote: Glad to announce D 2.069.0. http://dlang.org/download.html http://downloads.dlang.org/releases/2.x/2.069.0/ This is the first release with a self-hosted dmd compiler and comes with even more rangified phobos functions, std.experimental.allocator, and many other improvements. See the changelog for more details. http://dlang.org/changelog/2.069.0.html -Martin This schedule seems to work well. Daily downloads on the rise - 28-days moving average almost 1400 as of today. Good work everyone and particularly thanks Martin for putting us on a schedule! http://erdani.com/d/downloads.daily.png Andrei
Re: Release D 2.069.0
On Sunday, 8 November 2015 at 14:22:38 UTC, Dicebot wrote: On Sunday, 8 November 2015 at 14:14:23 UTC, Sebastiaan Koppe wrote: With a codebase like phobos, compiling in several steps isn't a bad solution. But I am building a parser using pegged, and splitting up the grammar into different modules feels like a no-no. It's an option though. Note that you can still used pegged in a stand-alone style with just saving generator output in a separate module and building it with project in a separate step. This means losing one of main advantages compared to using 3d party generators but if you hit the memory limit hard it may be the only option for now. You mean instead of mixin(grammer(`...`)) I write the output of grammer(`...`) to a file and include that into the final build? That might be a nice idea once I make a dub package out of it; to presupply the generated parser instead of eating up user's mem. Thanks.
Re: Release D 2.069.0
On Sunday, 8 November 2015 at 14:14:23 UTC, Sebastiaan Koppe wrote: With a codebase like phobos, compiling in several steps isn't a bad solution. But I am building a parser using pegged, and splitting up the grammar into different modules feels like a no-no. It's an option though. Note that you can still used pegged in a stand-alone style with just saving generator output in a separate module and building it with project in a separate step. This means losing one of main advantages compared to using 3d party generators but if you hit the memory limit hard it may be the only option for now.
Re: Release D 2.069.0
On Saturday, 7 November 2015 at 13:25:41 UTC, Jonathan M Davis wrote: What can we do when it eats up all 4 gigs? (Windows) With any program, if you're hitting the limit of the 32-bit address space (which is actually more like 3.6 GiB than 4), then you really only have two options - use less memory or go to 64-bit. In the case of dmd specifically, that means either reducing how much memory dmd consumes (which would mean improvements to the dmd codebase), have a 64-bit build of dmd (I have no idea what's involved with that, though it sounds like it's been done before), or you have to build your program in separate pieces that each require a low enough amount of memory when compiling that they don't run out of memory. Phobos has been built in pieces for quite a while now specifically because it requires too much memory to build it all at once (std.algorithm alone requires a lot of memory thanks to all of the template instantiations in its unit tests). - Jonathan M Davis With a codebase like phobos, compiling in several steps isn't a bad solution. But I am building a parser using pegged, and splitting up the grammar into different modules feels like a no-no. It's an option though. Right now I run compile with gdc in a virtual machine. Still eats about 7 gigs. The 64bit dmd would be nice. I waved the idea goodbye when I couldn't find a download link. Maybe need to look into it.
Re: Release D 2.069.0
On Saturday, November 07, 2015 17:41:20 Dmitry Olshansky via Digitalmars-d-announce wrote: > On 07-Nov-2015 16:25, Jonathan M Davis via Digitalmars-d-announce wrote: > > Phobos has been built in pieces for quite a while now > > specifically because it requires too much memory to build it all at once > > (std.algorithm alone requires a lot of memory thanks to all of the template > > instantiations in its unit tests). > > > > That's only true for unittests, it still builds the library in one go > (in about 7 seconds for me) on windows. Yes, but it's forced to do that with the unit test build, because it takes too much memory to compile them. Other programs may have the same problem (especially if they use templates and CTFE heavily). But dmd just does not do well with memory consumption when it comes to templates and CTFE, and it definitely will be a major improvement when we can reduce how much memory compiling them requires. - Jonathan M Davis
Re: Atrium - 3D game written in D
07.11.2015 21:17, Manuel König пишет: Am Fri, 6 Nov 2015 12:04:03 +0300 schrieb Timur Gafarov : Atrium (code name) is a work-in-progress science fiction game with physics based puzzles (gravity effects, force fields, etc) akin to Portal or Inverto. The game is fully written in D, it uses custom graphics engine based on OpenGL and SDL. Physics engine is also written from scratch. Source code: https://github.com/gecko0307/atrium IndieDB page: http://www.indiedb.com/games/atrium A precompiled demo for Windows: https://www.dropbox.com/s/qh8gai2n94qe8jj/atrium-testbuild-051115.zip?dl=0 This looks very nice, congrats! I'm especially interested in the physics and character controller part, because I'm currently developing a character controller myself, but just a sphere character in a static triangle world for now. Finding a robust and fast sliding algorithm for sliding a sphere along triangles in a given direction seems to be the hardest part. I'm investigating two approaches, which can be simplified to: 1) move until we hit any geometry, compute new slide direction, repeat 2) move first, then project the character out of the world geometry Both approaches work reasonably well, but there are scenarios where they don't work so well (mostly pathetic scenarios). I'll definitely look how you solved the problem and maybe tinker with your physics code :) I took rather idiomatic approach: move, detect collisions, generate contact points, then solve them iteratively. Sliding is obtained somewhat automatically.