Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On Thursday, 12 February 2015 at 15:27:14 UTC, Andrej Mitrovic wrote: On 2/10/15, Kiith-Sa via Digitalmars-d-announce wrote: DDocs.org (http://ddocs.org) It would be nice to be able to jump to the project's hosted repository in the docs page (maybe generate a github icon with a link somewhere?) E.g. I'm here: http://ddocs.org/bloom/latest/dawg/bloom.html But want to get the link to the github repository. I'd have to go to the homepage and search for the package. Good idea, added the feature.
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
Great work. I noticed a few mistakes in the layout:
div.main-description
{
width: 160%;
should be 100%
The e-o , p-z links are overlapping the arrow symbols.
http://ddocs.org/favicon.ico is a 404
The CSS is actually correct, I'm using display: flex for the
intro/developer info.
I added prefixes so it works in browsers like Safari that don't
yet support the official syntax. It'll still look ugly in IE9 and
older (and frankly, I don't see that as an issue). Same with the
arrows/links, where I'm using transform: rotate().
Browser support for these features:
http://caniuse.com/#feat=flexbox
http://caniuse.com/#feat=transforms2d
Also, added a favicon (just a png of the dlang.org favicon).
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On Wednesday, 11 February 2015 at 08:41:26 UTC, Mathias LANG wrote: On Tuesday, 10 February 2015 at 22:40:18 UTC, Kiith-Sa wrote: DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects. Awesome ! I've wanted to do it for quite some time, I think it's really important we get that as a part of code.dlang.org (as well as compatibility badges, but that's another story. Regarding the macros: I recently completed the set of definitions in libddoc ( https://github.com/economicmodeling/libddoc/commit/82fcd8fdcdfe0809437f2415361ef92ee21a5c12 ), so if you're based on Harbored, you should have everything you need. I'm currently working on a fully compliant macro parser in libddoc. The macro WEB is not part of the standard definition, it's part of dlang.org's definitions, which you can find on Github (.ddoc files). More precisely, it's defined in html.ddoc ( https://github.com/D-Programming-Language/dlang.org/blob/master/html.ddoc ). I guess it can make sense to had that file included by default, but at the same time I'd like to avoid projects documentation to rely on non-standard behavior. Yes, I'm using libddoc (not current harbored directly - using a fork) so those builtin macros already work. I don't want to include all the phobos/dlang.org macros, but I will add them on case-by-case basis when people use them in their projects' docs so the docs still work.
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On Tuesday, 10 February 2015 at 23:53:19 UTC, MrSmith wrote: On Tuesday, 10 February 2015 at 22:40:18 UTC, Kiith-Sa wrote: DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects. That is pretty cool! I will put a link to it in all my project readmes. I've noticed that License: "a$(WEB boost.org/LICENSE_1_0.txt, Boost License 1.0)." gets rendered as "a". Am I doing it wrong? There's a bunch of macros used in many D projects not documented in the language reference. They seem to be defined somewhere in Phobos/Druntime (? - not sure), not really built in, but I add them as I find them so compatibility is kept. Added $WEB to harbored-mod now. There already also is LINK, LINK2, and HTTP... and of course Markdown [link](http://link.org) - but that doesn't work with plain DDoc generators. The change can take a while to propagate to your packages as ddocs.org waits a few days before regenerating docs for releases that already have docs generated and <2 days for known branches (~master) so it doesn't constantly regenerate docs for everything - it is feasible now but won't be if the DUB registry gets bigger as fast as I expect.
DDocs.org: auto-generated documentation for all DUB projects (WIP)
DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects.
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On Sunday, 1 February 2015 at 13:40:29 UTC, Rikki Cattermole wrote: On 2/02/2015 2:36 a.m., Kiith-Sa wrote: Atleast on chrome win7 the font is absolutely awful. Could you post a screenshot? I mostly just use the default "sans" which can result in any font being used based on the OS, http://imgur.com/JvbjN9o Not sure why Windows interprets 'sans' as 'serif', but it should at least use sans (Verdana on Windows) now.
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
Atleast on chrome win7 the font is absolutely awful. Could you post a screenshot? I mostly just use the default "sans" which can result in any font being used based on the OS, Also any chance that it could output json to represent modules instead of html? Very unlikely in near future, I've refactored *most* HTML writing code but the rest would still need a lot of work, and then there'd be a non-trivial chunk of "HTMLWriter" code to rewrite (1k lines), which would likely result in finding finding more deficencies in separation of HTML writing from the rest of the code.
Re: Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
On Saturday, 31 January 2015 at 17:43:49 UTC, jklp wrote: On Saturday, 31 January 2015 at 15:31:37 UTC, Kiith-Sa wrote: Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: "aggregated" HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0 Hello i get an error while trying to compile it on Win32, with dmd 2066.1: Error 42: Symbol Undefined _D3std5array40__T5emptyTE14symboldatabase10SymbolTypeZ5emptyFNaNbNdNiNfxAE14symboldatabase10SymbolTypeZb demangled: pure nothrow @property @nogc @safe bool std.array.empty!(symboldatabase.SymbolType).empty(const(symboldatabase.SymbolType[])) the error only happend since commit 05ab80052d1b7d1dc3b1ff38c30addd9df7f3db4 otherwise thx for this nice software. Thanks for detecting the error/commit. Unfortunately I have no way to test on Win32 currently, and on Linux (32 or 64) I couldn't reproduce this (and AFAIK Mac build works as well), but based on the demangled name I tried to blindly fix a possible cause. That said, there is no "obvious" cause; I suspect this may be a Win32-specific linker error. Could you clone the current git master (https://github.com/kiith-sa/harbored-mod.git) and try if it works?
Harbored-mod (doc generator) 0.2: Cross-referencing, methods/fields no longer in separate files
Harbored-mod (https://github.com/kiith-sa/harbored-mod) is a documentation generator based on Brian Schott's Harbored that supports both DDoc and Markdown in documentation comments. -- Examples of generated docs -- * Public imports in a package.d: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity.html * Class with a template parameter, member functions and aliases: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html * Simple DDoc See_Also: section: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html * Note: DDoc section with some markdown: http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo.html#prioritizeProcessOverloads -- Release highlights -- * Automatic cross-referencing in code blocks and inline code * New (and now default) output format: "aggregated" HTML; generate documentation files only for aggregates (modules, structs, classes, etc.) and document non-aggregate members (functions, variables, etc.) in these files. The previous, DDox compatible format, where a separate file is generated for every symbol, is still supported through the `--format=html-simple` option. * Various style and usability improvements * Major refactoring * Many bugfixes Full changelog: https://github.com/kiith-sa/harbored-mod/releases/tag/v0.2.0
Re: Calypso: Direct and full interfacing to C++
Just in case you don't follow digitalmars.D: http://forum.dlang.org/thread/m9s4cd$2s1v$1...@digitalmars.com#post-m9s4cd:242s1v:241:40digitalmars.com
Re: This Week in D, issue 2
On Monday, 19 January 2015 at 17:05:54 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jan-18.html http://www.reddit.com/r/programming/comments/2sy7lg/this_week_in_d_january_18_2015/ For those of you who saw the draft earlier, hit refresh to ensure you aren't seeing a cached version. RSS feed: http://arsdnet.net/this-week-in-d/twid.rss This week, we got new web style thanks to the folks in the other forum. Tech speaking, it now serves gzipped files as a test of what I want to see about putting on dlang.org too. Email list will be coming next week and hopefully a move to dlang.org too. Fixed a few bugs in my stats gathering too, hopefully we'll have all the kinks worked out and on-time release next week! The 'dividend / dividend' error is still there (in divideBy).
Re: Binutils 2.25 Released - New D demangling support
On Tuesday, 13 January 2015 at 21:31:15 UTC, Iain Buclaw wrote: Hi, I'm not sure when it was announced, but binutils 2.25 has been released! There's a small reason for excitement as it is the first to come with D demangling support in the GNU toolchain. Unfortunately, I forgot to send in patches that actually document it! So for the moment, it's a little secret feature shared between all who may read this. :o) How do you use it? --- By default, binutils programs will treat all mangled symbols as C++, however you can override this by using --demangle=dlang, eg: objdump -d --demangle=dlang prog.o nm --demangle=dlang ddmd You can also kickstart your usage by putting -L--demangle=dlang in your dmd.conf, and watch your obscure linker errors turn into pretty function signatures. Could you add this note somewhere visible into the wiki so it doesn't get lost? Also, could DMD do this by default if available so it works out of the box?
Re: DMD's lexer available on code.dlang.org
On Sunday, 4 January 2015 at 17:27:57 UTC, Daniel Murphy wrote: "Kiith-Sa" wrote in message news:nffxogzwpmayydyom...@forum.dlang.org... (sorry if you get this question too often) How is DDMD as a whole going? Is it getting closer or are ongoing DMD changes slowing it down too much? It's been sitting still for 8 nearly months because of https://github.com/braddr/d-tester/issues/39 and https://github.com/braddr/d-tester/issues/40 I don't mind getting asked, I just wish the answer would change. Anyway, great to have the lexer on DUB, not going to use if for now because I expect there to be changes, but I guess it may eventually be useful for writing tools. Hopefully lots of changes. I can't really help with those, but FWIW I bumped the issues.
Re: DMD's lexer available on code.dlang.org
On Sunday, 4 January 2015 at 13:07:34 UTC, Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer,
generated automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
There are a few annoying limitations, such that it uses dmd's
error printing and allocation functions, and requires
configuration through 'global'.
Here is an example program that uses the lexer:
==
import std.stdio;
import std.file;
import ddmd.tokens;
import ddmd.lexer;
/
void main()
{
Lexer.initLexer();
string data = "void blah() {} // stuff";
auto l = new Lexer("myfile", data.ptr, 0, data.length, 0, 0);
l.nextToken();
do
{
printf("token: %s\n", l.token.toChars());
}
while (l.nextToken() != TOKeof);
}
==
Prints:
token: void
token: blah
token: (
token: )
token: {
token: }
(sorry if you get this question too often)
How is DDMD as a whole going? Is it getting closer or are ongoing
DMD changes slowing it down too much?
Anyway, great to have the lexer on DUB, not going to use if for
now because I expect there to be changes, but I guess it may
eventually be useful for writing tools.
Harbored-mod 0.1: A documentation generator with DDoc and Markdown support based on Harbored
Harbored-mod is a documentation generator based on Brian Schott's Harbored. Features It supports (a non-conflicting subset of) Markdown besides DDoc, so Markdown can be used together with DDoc in documentation comments. Some other features: * Decent defaults. `hmod source` will generate rather usable documentation very similar to this one: * CSS and main page content can be overridden. Extra content can be added to the table of contents (e.g. links to non-DDoc generated documentation, I use it to link to tutorials/articles written in ReStructuredText) * Documented config file you can write all command-line options to, so just typing `hmod` will regenerate the docs. * Generated file paths are same as those generated by DDox, so links will not break if moving from one to the other. -- Examples of generated docs (work-in-progress Tharsis docs) -- http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/entitymanager/EntityManager.html http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/componenttypeinfo/ImmutableRawComponent.html http://defenestrate.eu/docs/tharsis-core/api/tharsis/entity/processtypeinfo/prioritizeProcessOverloads.html - Links - * GitHub: https://github.com/kiith-sa/harbored-mod * Original Harbored: https://github.com/economicmodeling/harbored -- Background -- Harbored-mod started as an attempt to remove things I didn't want from Harbored (inability to work without JS, frames, etc.) but I ended up with more changes than I originally intended, and I think at this point it might be useful for other people as well. I pushed it into a separate repository because I don't think at this point it can be sanely merged into harbored (plus there are those features I removed).
Re: C# to D Compiler :)
On Sunday, 21 December 2014 at 15:12:26 UTC, ZombineDev wrote: One example of a somewhat large performance oriented C# application is OpenRA[1]. (An open-source implementation of the Command & Conquer: Red Alert engine using .NET/Mono and OpenGL. Runs on Windows, Linux and Mac OS X) It is interesting to see how far it can be translated from C# to D and what the performance would be. I'll give it a shot when I have the time, though you may also find it useful as a way to benchmark your compiler ;) [1]: https://github.com/OpenRA/OpenRA Last time (long ago) I looked at OpenRA code it didn't look like its source would (directly) translate well to high-performance D/C++/whatever. You'd end up needing to turn some structs to classes, limit GC usage (.NET has a much better GC, yet non-GC code is simpler in D), etc. (I'm planning to work on a project with similar goals to OpenRA, although for academic reasons I'm still only working on its entity system (https://github.com/kiith-sa/tharsis-core).
Re: 2D game engine written in D is in progress
On Wednesday, 17 December 2014 at 19:06:24 UTC, solidstate1991 wrote: I started to work on an engine, which emulates the features and limitations of older graphics systems, mainly for retro-styled indie games. Features: -Support for parallax scrolling, and multiple sprite and tile layers -Support for sprite scaling and rotation -Max. 65536 colors on screen from a palette -Variable sprite sizes for easier development, tile layers can work with any size of tiles as long as all of the tiles are the same size on one layer -Collision detection -Support for modding -Sprite editor, tile map editor It's not a dethroner for the Unreal Engine 4, but I try my best to get it into work. It's current name is VDP engine, but if you can come up with a better name I might change it. I still haven't decided to make it open or closed source (if it'll be ever used by any game that makes profit, I'd like to get some share from it). Noticed there's a question at Reddit (a bot submits all announce threads to Reddit): https://www.reddit.com/r/d_language/comments/2pm2ba/2d_game_engine_written_in_d_is_in_progress/
Re: dsource.org moved
On Wednesday, 3 December 2014 at 06:39:34 UTC, Vladimir Panteleev wrote: On Tuesday, 2 December 2014 at 23:02:32 UTC, Kiith-Sa wrote: On Tuesday, 2 December 2014 at 22:20:29 UTC, Vladimir Panteleev wrote: DSource in the headlines? In 2014? Shocking, I know. Since Brad is no longer an active D user, and the website has had spotty uptime lately, I've offered to take over the hosting and any maintenance. Although opinions exist that the site should simply be shut down, I think archiving it would be a better approach. The website has historical relevance to the D community, and might be required to get ancient D code running again. For example, we could make things read-only and make it obvious on every project page that "we don't go to DSource any more". I can't exactly undertake a large redesign, but we can discuss our options. Planet D (planet.dsource.org) is moved as well, and should continue to operate merrily. If your D blog's not there, let me know! My blog is not there, but it's not pure D blog: defenestrate.eu defenestrate.eu/rss.html Any way you can provide an RSS or ATOM feed for just the posts tagged D? Don't know any way other than maybe modifying the generator I'm using, but I don't have the time to do that in near future (I know little about how RSS works/web dev in general so I'd have to spend some time learning that too). I'm using a static site generator (Tinkerer) based on Sphinx/ReStructuredText (think Markdown on steroids), so the blog is actually a static site.
Re: dsource.org moved
On Tuesday, 2 December 2014 at 22:20:29 UTC, Vladimir Panteleev wrote: DSource in the headlines? In 2014? Shocking, I know. Since Brad is no longer an active D user, and the website has had spotty uptime lately, I've offered to take over the hosting and any maintenance. Although opinions exist that the site should simply be shut down, I think archiving it would be a better approach. The website has historical relevance to the D community, and might be required to get ancient D code running again. For example, we could make things read-only and make it obvious on every project page that "we don't go to DSource any more". I can't exactly undertake a large redesign, but we can discuss our options. Planet D (planet.dsource.org) is moved as well, and should continue to operate merrily. If your D blog's not there, let me know! My blog is not there, but it's not pure D blog: defenestrate.eu defenestrate.eu/rss.html
Re: Despiker 0.1: a GUI real-time profiler for game development
On Monday, 13 October 2014 at 11:09:14 UTC, Szymon Gatner wrote: On Monday, 13 October 2014 at 10:32:54 UTC, Szymon Gatner wrote: On Sunday, 12 October 2014 at 01:36:15 UTC, Brad Anderson wrote: On Friday, 10 October 2014 at 23:55:03 UTC, Kiith-Sa wrote: -- Announcing Despiker, a GUI real time profiler for game development -- Very cool. Tharsis looks very interesting too. Also, it appears you have a great blog about this and other stuff I'm surprised I've never seen before. Very cool indeed! Will take closer look at it for sure. This happens after just adding "tharsis-prof": "~>0.4.0" to the dependancies and running 'dub' in project directory: C:\Users\bravo\AppData\Roaming\dub\packages\tharsis-prof-0.4.1\source\tharsis\pr of\despikersender.d(309): Error: cannot implicitly convert expression (this.byte sSentPerProfiler_[threadIdx]) of type ulong to uint FAIL C:\Users\bravo\AppData\Roaming\dub\packages\tharsis-prof-0.4.1\.dub\build\l ibrary-debug-windows-x86-dmd_2066-5F4CDB1FE63BE3C80C818C14E6D175D5\ tharsis-prof staticLibrary Error executing command run: dmd failed with exit code 1. I made new releases of despiker/tharsis.prof (0.1.1/0.4.2) that fix 32-bit compilation. Couldn't test despiker yet, though.
Despiker 0.1: a GUI real-time profiler for game development
-- Announcing Despiker, a GUI real time profiler for game development -- This is is a visualizer for the Tharsis.prof frame-based profiler library. Profiling with writeln turned out to be unintuitive, so I ended up making a GUI. * Shows a graph of overhead in a frame * Updates in real time as the profiled program (game) runs * Can pause to look at the current frame * Can browse/jump frames, jump to the worst frame. The GUI is still a bit inconvenient (need slow-motion replay and minimap to efficiently browse), but it got to the point where it's usable. Note: this is still unstable and I'm not likely to spend much time on it in the following months (as I need to work on the project I wrote this for in the first place.) GitHub: https://github.com/kiith-sa/despiker/issues/16 Video (WebM): http://defenestrate.eu/docs/despiker/_static/despiker.webm Tutorial: http://defenestrate.eu/docs/despiker/tutorials/getting_started.html Tharsis.prof: https://github.com/kiith-sa/tharsis.prof
Re: D2 port of Sociomantic CDGC available for early experiments
On Monday, 6 October 2014 at 16:51:07 UTC, Dicebot wrote: https://github.com/D-Programming-Language/druntime/pull/985 Here is initial port result available for early experiments. It can be compiled with make -f posix.mak GC_TYPE=concurrent and passes the test suite with only shared library tests disabled (ef20b7a). There are still many issues to be aware of: 1) Documentation is largely missing. Working on it, reading @leandro-lucarella-sociomantic old posts (http://www.llucax.com.ar/blog/blog/tag/understanding%20the%20current%20gc) may help in the meanwhile 2) Code style differs from Phobos standards. To be fixed soon. 3) Shared library support is completely missing. Proxy infrastructure similar to one in existing gc needs to be added and I don't know if actual implementation will work in such environments or more changes will be needed. 4) Deadlock issue (http://www.dsource.org/projects/tango/ticket/2087) still remains. It is not critical to our code because it almost never uses threads so no big effort was put into it but this can be huge problem for any other project. In general this is very far from something that can be merged upstream straight away and replace default GC on linux. It can be interesting for other projects with similar architecture and requirements and probably helpful for anyone else working on better D GC. And contributions are welcome via pull requests towards this PR base branch (https://github.com/mihails-strasuns-sociomantic/druntime-1/tree/sociomantic-cdgc-wip) or as e-mail patches (pub...@dicebot.lv) Can't really test this right now, just want to say that it's awesome that someone is working on this and I really hope this can (eventually) get merged.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Monday, 6 October 2014 at 15:06:04 UTC, Steven Schveighoffer wrote: On 10/2/14 3:42 AM, Kagamin wrote: On Thursday, 2 October 2014 at 07:14:35 UTC, Iain Buclaw via Digitalmars-d-announce wrote: Doesn't Linux Mint provide an upgrade facility for you? No idea. I use Linux Mint, I believe I upgraded once *. I don't think it was complex, just an upgrade through the standard UI for updates. * Note: I have a bad memory when it comes to things like this :) -Steve Mint always supported upgrades between LTS releases. There were no upgrades between non-LTS releases, which were basically just bit-more-stable betas. That's changed now as posted above, Mint 14.04 to 15.10 (and possibly longer) will be seamlessly upgradable release to release as Mint gradually diverges away from its Ubuntu base. 16.04 may be a reset, or they may continue to diverge further, or they may move fully to Debian; but they'll probably still have an upgrade path as it will be an LTS.
Re: Tharsis.prof 0.1: a frame-based profiler for game development
On Sunday, 7 September 2014 at 02:41:53 UTC, Andrei Alexandrescu wrote: This looks like solid work, congratulations! Could someone please announce this on reddit and hackernews on Monday morning? We'd need one of the blog posts to be the entry point leading to the others and to the code examples. Which one would be it? Andrei On 9/5/14, 4:06 AM, Kiith-Sa wrote: Announcing Tharsis.prof, a frame-based profiler in D. A profiler as-a-library that keeps track of overhead of every individual frame RAII-style API for recording profile data, and range-style API for processing the results (with std.algorithm and the like - no graphics interface yet). No GC allocations (and no heap allocations either - user must provide memory). See example at: https://github.com/kiith-sa/tharsis.prof Use case: my game has a rare lag that occurs once per minute. Profiler is useless because the lag is averaged out. To solve with Tharsis.prof: * Instrument code (add Zones, say, for rendering batches, physics, etc) * Profile till the lag occurs. * Get a range of frames (e.g. by filtering zones to get those named "frame") * Sort the range * Get the longest frame * Filter a range of all zones to get only those with start/end time within the longest frame. * Find the offending zone * Done Blog posts explaining what this is in detail (should be one post, but it ended up being too long): http://defenestrate.eu/2014/09/05/frame_based_game_profiling.html http://defenestrate.eu/2014/09/05/optimizing_memory_usage_of_a_frame_based_profiler.html http://defenestrate.eu/2014/09/05/frame_based_profiling_with_d_ranges.html GitHub: https://github.com/kiith-sa/tharsis.prof Dub: http://code.dlang.org/packages/tharsis-prof API docs (with examples): http://defenestrate.eu/docs/tharsis.prof/index.html Actually, it's already on Reddit, but on r/gamedev: http://www.reddit.com/r/gamedev/comments/2fjgcu/framebased_game_profiling/ The first post contains easily visible links to the other two, but it's not particularly D-focused (neither is the second). The third post is D-focused, and it contains links to the previous two, some code examples as well as a link to the GitHub project with the introductory example, but these links are inline in the text, not separate.
Tharsis.prof 0.1: a frame-based profiler for game development
Announcing Tharsis.prof, a frame-based profiler in D. A profiler as-a-library that keeps track of overhead of every individual frame RAII-style API for recording profile data, and range-style API for processing the results (with std.algorithm and the like - no graphics interface yet). No GC allocations (and no heap allocations either - user must provide memory). See example at: https://github.com/kiith-sa/tharsis.prof Use case: my game has a rare lag that occurs once per minute. Profiler is useless because the lag is averaged out. To solve with Tharsis.prof: * Instrument code (add Zones, say, for rendering batches, physics, etc) * Profile till the lag occurs. * Get a range of frames (e.g. by filtering zones to get those named "frame") * Sort the range * Get the longest frame * Filter a range of all zones to get only those with start/end time within the longest frame. * Find the offending zone * Done Blog posts explaining what this is in detail (should be one post, but it ended up being too long): http://defenestrate.eu/2014/09/05/frame_based_game_profiling.html http://defenestrate.eu/2014/09/05/optimizing_memory_usage_of_a_frame_based_profiler.html http://defenestrate.eu/2014/09/05/frame_based_profiling_with_d_ranges.html GitHub: https://github.com/kiith-sa/tharsis.prof Dub: http://code.dlang.org/packages/tharsis-prof API docs (with examples): http://defenestrate.eu/docs/tharsis.prof/index.html
Re: D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
Should be fixed now with 0.4.6: http://code.dlang.org/packages/dyaml/0.4.6
D:GameVFS 0.2
D:GameVFS is a (very) minimal virtual file system library for game development. https://github.com/kiith-sa/D-GameVFS I updated D:GameVFS to work with DMD 2.066 and put it on DUB. There are no major changes, just a bunch of small features I added over time as I use it. Note that at this point this isn't hugely useful. The only VFS backend that is implemented is... plain FS (I expect to implement a zip backend once I need it), the main useful feature is directory stacking (i.e. treating files in multiple directories as if they were one directory, where files from directories up the stack override those from directories below). As always, the API is not stable. GitHub release with changelog: https://github.com/kiith-sa/D-GameVFS/releases/tag/v0.2.0 API docs: http://defenestrate.eu/docs/dgamevfs/index.html DUB registry: http://code.dlang.org/packages/dgamevfs
Re: D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
On Wednesday, 6 August 2014 at 21:18:00 UTC, Gary Willoughby wrote: On Wednesday, 6 August 2014 at 17:09:50 UTC, Kiith-Sa wrote: ## D:YAML 0.4.5 ## For compatibility with DMD 2.065, I also made a "release" out of the last state of git master before 2.066 was required. See the release at GitHub: https://github.com/kiith-sa/D-YAML/releases/tag/v0.4.5 Great thanks. One tiny issue however is that v0.4.5 is not available via the dub registry. It looks like the registry has only picked up v0.5.0. Is there any way to work this around? (I'm not in charge of the dub package, and even if I were I don't see how I could force it to detect the older tag) - the only thing I can think of right now is putting it into a separate repo and registering it as a separate package, which is rather unwieldy.
D:YAML 0.5 (also, D:YAML 0.4.5, TinyEndian 0.1)
D:YAML is a YAML parser and emitter for D. It's been a while since the last release and many small features have been added to the Git master over time, so I finally forced myself to do an official release. D:YAML at GitHub: https://github.com/kiith-sa/D-YAML ## Highlights ## Some breaking changes: YAML loading API using std.stream is now obsolete. D:YAML 0.5 requires DMD 2.066 (yes, the one that is not yet released - see 0.4.5 below for compatibility). DUB by default: Stopped using my own build script, updated examples to use DUB, etc. Significantly less memory allocations, both GC and malloc: D:YAML scanner now uses slices to avoid any allocations. UTF-8 is now used internally instead of decoding into UTF-32. Better performance: I've spent some time profiling and optimizing, mainly for the use case of 'parsing few-kiB mostly ASCII files not using crazy advanced YAML features' (I use YAML for game-related stuff). Performance for the above use case is up about 80% (or, time spent is down to about 55%). For mostly-unicode (that is, mostly non-ASCII unicode) files, performance is down slightly (~10-15%). I don't have any thorough measurements to release, just did various tests as I went. Retired the dyaml.alwaysdata.net site, moved API docs/tutorials to my new site: http://defenestrate.eu/docs/dyaml/ And various small features/fixes/improvements. See the full changelog for details: https://github.com/kiith-sa/D-YAML/releases/tag/v0.5.0 ## D:YAML 0.4.5 ## For compatibility with DMD 2.065, I also made a "release" out of the last state of git master before 2.066 was required. See the release at GitHub: https://github.com/kiith-sa/D-YAML/releases/tag/v0.4.5 ## TinyEndian ## This is just a single module with two functions that I separated into a DUB package as I think it may be useful. When removing the std.stream dependency from D:YAML I had to replace EndianStream with my own code (based on EndianStream but mostly rewritten). The result are two pure nothrow @nogc functions to detect UTF byte order marks and swap endianness https://github.com/kiith-sa/tinyendian
Re: "Programming in D" book is 100% translated
On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali On reddit: http://www.reddit.com/r/programming/comments/2bl51j/programming_in_d_a_great_online_book_for_learning/
Re: "Programming in D" book is 100% translated
On Thursday, 24 July 2014 at 08:11:01 UTC, Ali Çehreli wrote: I have completed the translation of the book. Phew... :) However, there is still more work, like adding a UDA chapter and working on many little TODO items. The following was the final chapter, which actually only scratches the surface of the very broad topic: * Memory Management As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Awesome. This needs to be one of the first things a visitor notices on the D site.
Re: DSnips - making D coding awesome in Vim (with GIFs!)
On Friday, 18 July 2014 at 00:44:15 UTC, uri wrote: On Thursday, 17 July 2014 at 20:57:10 UTC, Kiith-Sa wrote: DSnips is a set of UltiSnips snippets for D (now with GIFs showing each snippet in action (image-heavy)) https://github.com/kiith-sa/DSnips This is an attempt to overhaul the D snippets I got merged to UltiSnips (now a separate "vim-snippets" repository), as the previous snippets had quite a few bugs. The snippets should now be easy to use together/chain (e.g. an "imp" (import) snippet places the cursor on the beginning of the next line so "imp" can be used for another import, "wrap in try/catch" places the cursor to be ready to add more catch blocks, "module" license can be replaced by using another snippet inside it, etc. There are some rather "intelligent" snippets, e.g. an operator builder for opBinary/opUnary/opOpAssign that will generate the skeleton for all operators typed in by the user, automatic DDoc Params: generation from function parameters, etc. I want to eventually try to merge this back to the default repository, but I'd like some comments/criticism/ideas first. Should any snippets be removed? Added? Any problems with the current snippets? (the wrap in try/catch in the previous version had issues with wrapping indented text, for example) Trying this out now. It's very good so far, nice work! /uri I made a blog post about DSnips, what to consider when designing snippets, etc: http://www.reddit.com/r/vim/comments/2b2609/ultisnips_snippet_design_and_gifs/
DSnips - making D coding awesome in Vim (with GIFs!)
DSnips is a set of UltiSnips snippets for D (now with GIFs showing each snippet in action (image-heavy)) https://github.com/kiith-sa/DSnips This is an attempt to overhaul the D snippets I got merged to UltiSnips (now a separate "vim-snippets" repository), as the previous snippets had quite a few bugs. The snippets should now be easy to use together/chain (e.g. an "imp" (import) snippet places the cursor on the beginning of the next line so "imp" can be used for another import, "wrap in try/catch" places the cursor to be ready to add more catch blocks, "module" license can be replaced by using another snippet inside it, etc. There are some rather "intelligent" snippets, e.g. an operator builder for opBinary/opUnary/opOpAssign that will generate the skeleton for all operators typed in by the user, automatic DDoc Params: generation from function parameters, etc. I want to eventually try to merge this back to the default repository, but I'd like some comments/criticism/ideas first. Should any snippets be removed? Added? Any problems with the current snippets? (the wrap in try/catch in the previous version had issues with wrapping indented text, for example)
Re: dimgui - A port of imgui, the immediate-mode OpenGL GUI library
On Thursday, 22 May 2014 at 15:20:42 UTC, Andrej Mitrovic via
Digitalmars-d-announce wrote:
If you need a very minimal but usable GUI library for your
OpenGL
applications, then an immediate-mode GUI such as IMGUI could be
just
the trick. IMGUI has been ported to D and can be found at the
following links:
https://github.com/d-gamedev-team/dimgui
http://code.dlang.org/packages/dimgui
dimgui is zlib-licensed.
I'm starting work on a (very) small tool using dimgui.
When building an example ("demo"), I had to explicitly tell DUB
to link the GLFW library - shouldn't this already be handled by
the GLFW bindings?
(Also, on Linux you have to tell it to link dl...)
I.e. I added the following to dub.json of the example:
"libs": [
"dl",
"glfw"
],
I assume it works on Windows without this? (if so, how to change
it so it works on both?)
I'm on Linux (Mint 17 x64, similar to Ubuntu 14.04)
- btw, Mint17/Ubuntu14.04 only has GLFW2 in the repo, which
confused me when I had GLFW but still saw unresolved symbols -
but the next release will probably have GLFW3.
Also: it would be nice to have example/s that is completely
standalone, can be copied by itself and works (currently examples
depend on the DroidSans.ttf file higher up the directory tree) -
maybe even in a separate repo.
Re: QtE - D small binding for Qt.
On Wednesday, 11 June 2014 at 10:20:39 UTC, MGW wrote: Example of D (dmd 2.065 64) with Qt 64 Windows64/Linux64. Running programs *.EXE with key "--debug". http://yadi.sk/d/qLE7Kgz9SpKEX This looks pretty good. How much of Qt is usable through this? E.g. I assume nothing templated is usable?
Re: Chuck Allison's talk is up
On Thursday, 5 June 2014 at 21:15:40 UTC, Olivier Henley wrote: On Thursday, 5 June 2014 at 16:33:49 UTC, Andrei Alexandrescu wrote: https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/27e5d7/dconf_day_1_talk_3_a_real_d_in_programming/ https://www.facebook.com/dlang.org/posts/860528800627469 https://twitter.com/D_Programming/status/474587858812948480 Andrei Hi, I would love to spam my colleges here at Ubisoft Montreal with DConf 2014 talks ... but UStream is blocked studio wide. Is there any plans to mirror the talks somewhere else? We can stream from Vimeo and Youtube. I won't force feed every programmer here ... but we are at least 500 mainly coding C++ and C#. IMHO we are first class potential victims for D. Thx, Olivier p.s: My boss already agreed that I code my next tool in D. I'll let you know in due time... As mentioned above, downloading the video with VideoDownloadHelper (FF) or a Chrome equivalent works.
Re: Video of my LDC talk @ FOSDEM'14
On Monday, 26 May 2014 at 18:09:46 UTC, Walter Bright wrote: On 5/26/2014 10:30 AM, w0rp wrote: On Monday, 26 May 2014 at 17:06:27 UTC, Walter Bright wrote: Youtube has solved all these problems - why not use it? You can view .webm directly in recent Firefox or Chrome versions on Windows, you an also view .webm in IE9 and above provided you have the right codecs installed. It's a perfectly acceptable format. It doesn't work on the browser that comes with Windows. That makes it undesirable if you wish to reach the largest audience with the least friction. Why restrict the audience if you don't have to? What is gained by using .webm that would offset the reduced audience? It is gradually becoming the de facto standard for video on web. It can already be viewed directly in all modern browsers even outside of YouTube. It is usable on platforms where flash is now dead (the number of which is increasing). Vast (vast! even on Windows) majority of the audience don't use IE. It doesn't have patent issues. YouTube is (very slowly) moving to .webm too, after all they were the main reason for it. I for one like videos that are don't all depend on a single platform and that I can download without resorting to hacks. And that I can view in my browser more seamlessly than what YouTube's flash interface can do. With this kind of thinking we'd still be using $FORMAT where $FORMAT is the first format that became the de-facto standard in a particular area.
Re: dbox is a complete D2 port of the Box2D game physics library
On Friday, 23 May 2014 at 22:52:53 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/24/14, Piotrek via Digitalmars-d-announce wrote: nice one. How does it compare to C++ version in terms of performance? I haven't tested the performance yet! I'm definitely interested, but as usual I assume LDC will probably beat DMD in this area. Do you intend to keep this a straight port or will it be open to modifications? From a brief look at the source, it's possible I'll end up needing turning shapes from classes to structs and/or hooking it up with a custom allocator. I expect to need to spawn/destroy objects of varying shapes very often. (I do plan to try the current version first, though; it may be good enough) If I make such changes (which may affect the API, although the changes can probably be kept somewhat small), should I open a pull request or start a fork (ddbox? ;p)? (Same question applies to other of your ports)
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote:
Hello!
I would like to announce my project, DlangUI library -
cross-platform GUI for D.
https://github.com/buggins/dlangui
License: Boost License 1.0
Native library written in D (not a wrapper to other GUI
library) - easy to extend.
As a backend, uses SDL2 on any platform, Win32 API on Windows,
XCB on Linux. Other backends can be added easy.
Tested on Windows and Linux.
Supports hardware acceleration - drawing using OpenGL when
built with version=USE_OPENGL.
Unicode support.
Internationalization support.
Uses Win32 API fonts on Windows, and FreeType on other
platforms.
Same look and feel can be achieved on all platforms.
Flexible look and feel - themes and styles.
API is a bit similar to Android UI.
Flexible layout, support of different screen DPI, scaling.
Uses two phase layout like in Android.
Supports drawable resources in .png and .jpeg, nine-patch pngs
and state drawables like in Android.
Single threaded. Use other threads for performing slow tasks.
Mouse oriented.
Actually, it's a port (with major redesign) of my library used
for cross-platform version of my application CoolReader from
C++.
State of project: alpha. But, already can be used for simple 2D
games and simple GUI apps.
I'm keeping in mind a goal to write D language IDE based on
dlangui. :)
Adding support of 3D graphics is planned.
Currently implemented widgets:
TextWidget - simple static text (TODO: implement multiline
formatting)
ImageWidget - static image
Button - simple button with text label
ImageButton - image only button
TextImageButton - button with icon and label
CheckBox - check button with label
RadioButton - radio button with label
EditLine - single line edit
EditBox - multiline editor
VSpacer - vertical spacer - just an empty widget with
layoutHeight == FILL_PARENT, to fill vertical space in layouts
HSpacer - horizontal spacer - just an empty widget with
layoutWidth == FILL_PARENT, to fill horizontal space in layouts
ScrollBar - scroll bar
TabControl - tabs widget, allows to select one of tabs
TabHost - container for pages controlled by TabControl
TabWidget - combination of TabControl and TabHost
Layouts - Similar to layouts in Android
LinearLayout - layout children horizontally or vertically
depending on orientation
VerticalLayout - just a LinearLayout with vertical orientation
HorizontalLayout - just a LinearLayout with vertical orientation
FrameLayout - all children occupy the same place; usually onle
one of them is visible
TableLayout - children are aligned into rows and columns of
table
List Views - similar to lists in Android UI API.
ListWidget - layout dynamic items horizontally or vertically
(one in row/column) with automatic scrollbar; can reuse widgets
for similar items
ListAdapter - interface to provide data and widgets for
ListWidget
WidgetListAdapter - simple implementation of ListAdapter
interface - just a list of widgets (one per list item) to show
Sample project, example1 contains demo code for most of dlangui
API.
Try it using DUB:
git clone https://github.com/buggins/dlangui.git
cd dlangui
dub run dlangui:example1
Fonts note: on Linux, several .TTFs are loaded from hardcoded
paths (suitable for Ubuntu).
TODO: add fontconfig support to access all available system
fonts.
Helloworld:
// main.d
import dlangui.all;
mixin DLANGUI_ENTRY_POINT;
/// entry point for dlangui based application
extern (C) int UIAppMain(string[] args) {
// resource directory search paths
string[] resourceDirs = [
appendPath(exePath, "../res/"), // for Visual D and
DUB builds
appendPath(exePath, "../../res/") // for Mono-D builds
];
// setup resource directories - will use only existing
directories
Platform.instance.resourceDirs = resourceDirs;
// select translation file - for english language
Platform.instance.uiLanguage = "en";
// load theme from file "theme_default.xml"
Platform.instance.uiTheme = "theme_default";
// create window
Window window = Platform.instance.createWindow("My Window",
null);
// create some widget to show in window
window.mainWidget = (new Button()).text("Hello
world"d).textColor(0xFF); // red text
// show window
window.show();
// run message loop
return Platform.instance.enterMessageLoop();
}
DDOC generated documentation can be found there:
https://github.com/buggins/dlangui/tree/master/docs
For more info see readme and example1 code.
I would be glad to see any feedback.
Can this project be useful for someone? What features/widgets
are must have for you?
Best regards,
Vadim
Awesome.
Does this work like a conventional GUI toolkit (Gtk/Qt) or could
I integrate this in an OpenGL game? (or would I have to integrate
the game in it?)
Re: OpenGL Examples in D and a birth of a New Initiative
On Monday, 19 May 2014 at 21:10:02 UTC, Colden Cullen wrote: On Monday, 19 May 2014 at 21:08:25 UTC, Kiith-Sa wrote: Box2D would be awesome. I'm about to start a project that would greatly benefit from good 2D physics (I used simple AABB till now simply because physics is too much of a PITA) How do you port 20kloc in 2 days? D:YAML took me months (although it was python w/ some dynamic classes) Oh you made D:YAML? I personally would like to thank you for providing us with an awesome library which we use for all non-art data loading. It's been really good to us. Is performance not a problem so far? I did avoid unnecessary allocations but it still does use the GC quite a bit (I plan to eventually change that and add some other optimizations but I'd like std.allocator to be in phobos first and I didn't find it too slow for my own projects yet).
Re: OpenGL Examples in D and a birth of a New Initiative
On Monday, 19 May 2014 at 20:44:59 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/19/14, Colden Cullen via Digitalmars-d-announce wrote: This is such a great effort to see! I'm liking the enthusiasm! Btw, I'm currently porting the Box2D physics engine to D. I've already ported Chipmunk a while ago, but Box2D has its own benefits. E.g. it has continuous collision detection which allows bullet-style physics without worry about physical shapes "disappearing from the screen". Box2D is also a C++ library, whereas Chipmunk is a C library. I'm close to being done. I have some debugging to do and the complete test-suite is almost entirely ported. Box2D would be awesome. I'm about to start a project that would greatly benefit from good 2D physics (I used simple AABB till now simply because physics is too much of a PITA) How do you port 20kloc in 2 days? D:YAML took me months (although it was python w/ some dynamic classes)
Re: Dash: An Open Source Game Engine in D
On Monday, 19 May 2014 at 19:50:37 UTC, Colden Cullen wrote: Hi everyone, I’m super excited to be able to announce that the Dash game engine[1] is finally stable and ready for public use! I’m currently the Lead Engine Programmer at Circular Studios[2] (the group behind Dash). We had 14 people working on the team, 6 engine programmers and 8 game developers creating Spectral Robot Task Force, a turn-based strategy game built with Dash. Dash is an OpenGL engine written in the D language that runs on both Windows and Linux. We use a deferred-rendering model in the current pipeline, and a component model for game development and logic. Other major features at the moment include networking, skeletal-animation support, content and configuration loading via YAML, and UI support through Awesomium[3] (though we are in the process of moving over to using CEF[4] itself). Our vision for Dash is to have the programmer-facing model of XNA/Monogame combined with the designer-friendliness of Unity in a fully free and open source engine. We also hope that Dash can help to prove the power and maturity of D as a language, as well as push D to continue improving. We’re open to any feedback you may have, or better yet, we’d love to see pull requests for improvements. [1] https://github.com/Circular-Studios/Dash [2] http://circularstudios.com/ [3] http://awesomium.com/ [4] https://code.google.com/p/chromiumembedded/ Looks awesome. Don't have time now (finals) but will check it out later. (I'm developing my own gamedev related... stuff so I'm unlikely to be a user but looks like it might finally be something a new user can pick up right away and just start making a game in D) For now all criticism I can give is that http://dash.circularstudios.com/v1.0/docs is completely useless with NoScript. At least put a warning for NoScript users.
Re: OpenGL Examples in D and a birth of a New Initiative
On Friday, 16 May 2014 at 13:53:07 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 5/14/14, Andrej Mitrovic wrote: I am starting an initiative for everyone interested in D game development by creating the github organization d-gamedev-team[1]. Just ported the imgui library to D. It's a minimal OpenGL GUI library, useful for things like tweaking parameters. Have a look here (screenshot included): https://github.com/d-gamedev-team/dimgui http://code.dlang.org/packages/dimgui This is pretty awesome - don't need to write my own anymore. How does it handle fonts? Does it depend on FreeType or something like that?
Re: 10 Years of Derelict
On Friday, 16 May 2014 at 07:43:06 UTC, ponce wrote: On Thursday, 15 May 2014 at 15:02:33 UTC, Mike Parker wrote: I managed to let this little anniversary slip by me. My first post in the old Derelict forum at DSource[1] is dated May 6, 2004, my initial commit to svn[2] was May 7, and my announcement in the newsgroup[3] was on May 8. My attention to the project has waxed and waned, but I'm still puttering along. I expect to continue for the forseeable future. There have been a number of contributors over the years who have helped out in porting to Linux and Mac, fixing bugs, and keeping the bindings up to date. It's been very much a community project, which has made it more enjoyable to work on. It helps that it isn't difficult to maintain :) Maybe before the next decade goes by I'll actually finish a game in D, which is the reason I started Derelict in the first place. For those who don't know, the current iteration of Derelict can be found at the DerelictOrg group at github[4]. I've still got work to do on it (ahem, documentation), but it's coming along. [1] http://www.dsource.org/forums/viewtopic.php?t=105 [2] http://www.dsource.org/projects/derelict/changeset/5/ [3] http://forum.dlang.org/thread/c7hl51$2k4u$1...@digitaldaemon.com [4] https://github.com/DerelictOrg Thanks for that long dedication! Using it since 7 years :) I probably wouldn't have stucked with D if it weren't for Derelict, and I know other people who wouldn't have either. Same here. It'd just be good for it to stabilize so we can write tutorials for it without them getting out of date (yeah, the APIs are the same, but Derelict itself keeps changing).
Re: Livestreaming DConf?
On Friday, 9 May 2014 at 19:48:20 UTC, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei Definitely support the idea and would watch.
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Monday, 5 May 2014 at 08:58:34 UTC, Gary Willoughby wrote: On Sunday, 4 May 2014 at 19:19:57 UTC, Nick Sabalausky wrote: -Jsource/example/media: Use "stringImportPaths" to specify import paths in a compiler independent way Error: multiple definition of tcl_38_307: _Tcl_Main and Tcl_Main: _Tcl_Main These errors should now be fixed in Tkd v1.0.1-beta. I don't have the time to use this right now, but I will need a working _portable_ GUI framework in a near-future project, so I just want to say that this is awesome. BTW, this is probably not a good idea in near future but it I think it would be good to have a builtin Tkinter equivalent for D. Even if it's not completely phobos-like (Tkinter is not entirely pythonic either), having a basic GUI framework ready to go without any extra setup is a huge advantage.
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
A component-entity architecture has two main advantages; one of them is efficiency/cache locality (which this project doesn't have at all). Another is the ability to quickly define new types without the clusterfuck that happens if you try to use OOP to design game entities (and also to define them in plain data types). This thing is ported from Java where performance didn't seem to be a concern (even though they're calling it 'lightweight' for some reason). There are even component-entity frameworks for Ruby, Actionscript, etc, where there is no way at all to utilize cache locality. I think this might be useful if you're creating a game that doesn't need the best graphics and when a little latency isn't a problem (e.g. turn-based strategy, adventure, etc.). (I'm not the developer of artemisd, but I'm working on a similar design, although with a bit more compile time, cache-aware and hopefully auto-threadable; but also much less flexible, more 'purist' (not likely to be released as a separate library, either))
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
On Tuesday, 8 October 2013 at 05:24:13 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 17:06:40 UTC, Kiith-Sa wrote:
On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote:
On 10/07/2013 02:18 AM, Elvis Zhou wrote:
ArtemisD:
https://github.com/elvisxzhou/artemisd
Just a little note: As it's more readable, you may want to
use 1000.msecs instead of dur!("msecs")(1000) in the example
program. 1000.msecs is the equivalent of the msecs(1000)
function call, which returns dur!("msecs")(1000).
Ali
Done, thank you!
I'm implementing pretty much the same thing in my project,
although I'm probably
more in line with the original blog post (e.g. every system
can only access
specific components of an entity, which are statically
determined, entities are more lightweight, etc.). I'm using
much less OOP and more of a generic/metaprogramming approach.
Currently I'm trying to rewrite the code to add a concept of
"past" and "future" state; a System processes past Components
and outputs a future Component, past Components are const, and
no two systems may write to the same future Component. This
should allow very simple threading
with little synchronization.
I'll look at your code if there are interesting ideas.
The previous version of my entity system is used in my ICE
game:
https://github.com/kiith-sa/ICE
It's quite messy, though; which is why I'm rewriting it.
The new version doesn't even compile at the moment, I'm
working on it slowly as I'm studying and working at the same
time right now.
I'll look over the comment and post if I have any further
feedback. The only thing I can say right now is that there is
inconsistent tab-space indentation in some parts of the code
(e.g.
https://github.com/elvisxzhou/artemisd/blob/master/source/artemisd/entity.d
)
I'll give it a try, thank you!
My main concern in the D port is, since getComponent is the
most important and most used function, often in every frame,
but caching it is not a good idea cause any component may
be removed or added at any time, with an additional
mixin TypeId in component definition, component then can be
get with its TypeId(index of component list) in zero cost.
In other ports, like Java or C#, even in C++, a ComponentMapper
like stuff is used to hash a component type to find a registered
index before you can get it efficiently.
What do you think?
In my implementation I don't even use a getComponent equivalent;
a process()
(or opApply() in the older version I linked) function directly
takes component
references, and all components are in plain arrays. Processing of
a System
is done (in generated code) by iterating over the components the
System specifies in its signature, which is cache-friendly, and
means the components needed are always available directly to the
process() function without any lookup. However, this is a less
flexible approach than what you're doing (although intentional,
again, to eventually enable very easy threading).
That said, in my code, entities can only be added/removed between
frames
(a System might create a new entity but it will only start to
exist with the next frame), and components cannot be changed once
the entity is created (although the new past/future design I'm
working on now might enable that).
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
On Monday, 7 October 2013 at 17:06:40 UTC, Kiith-Sa wrote:
On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote:
On 10/07/2013 02:18 AM, Elvis Zhou wrote:
ArtemisD:
https://github.com/elvisxzhou/artemisd
Just a little note: As it's more readable, you may want to
use 1000.msecs instead of dur!("msecs")(1000) in the example
program. 1000.msecs is the equivalent of the msecs(1000)
function call, which returns dur!("msecs")(1000).
Ali
Done, thank you!
I'm implementing pretty much the same thing in my project,
although I'm probably
more in line with the original blog post (e.g. every system can
only access
specific components of an entity, which are statically
determined, entities are more lightweight, etc.). I'm using
much less OOP and more of a generic/metaprogramming approach.
Currently I'm trying to rewrite the code to add a concept of
"past" and "future" state; a System processes past Components
and outputs a future Component, past Components are const, and
no two systems may write to the same future Component. This
should allow very simple threading
with little synchronization.
I'll look at your code if there are interesting ideas.
The previous version of my entity system is used in my ICE game:
https://github.com/kiith-sa/ICE
It's quite messy, though; which is why I'm rewriting it.
The new version doesn't even compile at the moment, I'm working
on it slowly as I'm studying and working at the same time right
now.
I'll look over the comment and post if I have any further
feedback. The only thing I can say right now is that there is
inconsistent tab-space indentation in some parts of the code
(e.g.
https://github.com/elvisxzhou/artemisd/blob/master/source/artemisd/entity.d
)
*look over the code, not comment
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote:
On 10/07/2013 02:18 AM, Elvis Zhou wrote:
ArtemisD:
https://github.com/elvisxzhou/artemisd
Just a little note: As it's more readable, you may want to use
1000.msecs instead of dur!("msecs")(1000) in the example
program. 1000.msecs is the equivalent of the msecs(1000)
function call, which returns dur!("msecs")(1000).
Ali
Done, thank you!
I'm implementing pretty much the same thing in my project,
although I'm probably
more in line with the original blog post (e.g. every system can
only access
specific components of an entity, which are statically
determined, entities are more lightweight, etc.). I'm using much
less OOP and more of a generic/metaprogramming approach.
Currently I'm trying to rewrite the code to add a concept of
"past" and "future" state; a System processes past Components and
outputs a future Component, past Components are const, and no two
systems may write to the same future Component. This should allow
very simple threading
with little synchronization.
I'll look at your code if there are interesting ideas.
The previous version of my entity system is used in my ICE game:
https://github.com/kiith-sa/ICE
It's quite messy, though; which is why I'm rewriting it.
The new version doesn't even compile at the moment, I'm working
on it slowly as I'm studying and working at the same time right
now.
I'll look over the comment and post if I have any further
feedback. The only thing I can say right now is that there is
inconsistent tab-space indentation in some parts of the code
(e.g.
https://github.com/elvisxzhou/artemisd/blob/master/source/artemisd/entity.d
)
Re: DCD: Autocomplete without the IDE
On Tuesday, 10 September 2013 at 16:15:55 UTC, André wrote: I just tried it with the Kate and it's working like a charm! All contributors keep up the good work :-) I really like the client/server approach because it enables everyone to use his or hers favourite editor. Is there a blog or changelog which allows to follow the further progress? Cheers André On Sunday, 1 September 2013 at 10:58:28 UTC, Brian Schott wrote: * What is it? DCD is a client and server program that work together to provide autocomplete suggestions and function call tips to almost any text editor that supports scripting or plugins. * Who is it for? People who would like autocomplete, but don't want to give up their favorite editor for an IDE. * Where is it? GitHub! https://github.com/Hackerpilot/DCD * What does it look like? There's a short demo video on Youtube: http://www.youtube.com/watch?v=Vo2POmn2_9U * What editors does it work with? Textadept, Kate/KDevelop, Vim, and Emacs. The Textadept integration script is the reference implementation. * This sounds a lot like GoCode It does, doesn't it? * Does it work? Yes and no. DCD is fairly new, and not all of the features you'd expect from a D autocompletion engine are present. I do feel that it's enough of an improvement over not having autocomplete to make this alpha announcement. * Should I file bug reports in this announcement thread? No. Add them here: https://github.com/Hackerpilot/DCD/issues?state=open https://github.com/Hackerpilot/DCD/commits/master
Re: Lumen - KTextEditor/Kate/KDevelop Autocompletion Plugin
On Monday, 19 August 2013 at 17:59:13 UTC, David wrote: Lumen = Lumen is a KTextEditor autocompletion plugin for the D programming language, which works e.g. in Kate or KDevelop, based on the DCD autocompletion server. Lumen: https://github.com/Dav1dde/lumen DCD: https://github.com/Hackerpilot/DCD With this Plugin KDevelop finally evolves to the most awesome D IDE out there (as DCD improves). You've got autocompletion(, semantic analysis, something I want to add to DCD overtime) and an amazing GDB integration, which works for D out of the be box! Would be great if some of you could test it, it should work flawlessly. TODO (lumen only): * Add include-paths UI * Get rid of dcd-client and implement its functionallity in pure C++ TODO (as DCD progresses): * "Best matches", e.g. `void foo(int x);` when completing `foo(` display every local/function which returns an integer in a "best matches" group * Sorting by inheritance * Sorting by scopes This is awesome. I've tried KDevelop recently and good D support might make me consider using it instead of Vim (especially if Vim mode improves further). Is it viable, in longer-term future, to have features similar to what KDevelop can do for C++? (semantic highlighting, esp. the color variation based on similarity of variable names, automatic creation of a stub of a nonexistent function based on a function call, etc.).
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
On Tuesday, 6 August 2013 at 18:38:43 UTC, Kiith-Sa wrote: On Tuesday, 6 August 2013 at 17:48:57 UTC, Walter Bright wrote: On 8/6/2013 5:13 AM, Richard Webb wrote: It's possible that other library routines are causing some of the remaining difference from the MSVC build (e.g. the profiler suggests that the DMC build spends somewhat more time inside memcpy than the MSVC build). Not sure if it's down to implementation or optimization though - might be down to intrinsics/inlining and such? (the proflie for the DMC build says it's using ~1% of its time inside strlen and the profile for the MSVC build doesn't mention it at all, which i guess is because it's using an intrinsic version). If it's inlined then it won't show up in the profile. And yes, it's possible MSVC has a faster memcpy(). After all, enormous effort has been poured into memcpy(). If you use a profiler with line or instruction granularity (like perf on Linux), it will show up. On Windows, that would probably be VTune and CodeAnalyst. (obviously, as a part of the function it was inlined into, but you'll get the time consumed at lines/instructions from the inlined function)
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
On Tuesday, 6 August 2013 at 17:48:57 UTC, Walter Bright wrote: On 8/6/2013 5:13 AM, Richard Webb wrote: It's possible that other library routines are causing some of the remaining difference from the MSVC build (e.g. the profiler suggests that the DMC build spends somewhat more time inside memcpy than the MSVC build). Not sure if it's down to implementation or optimization though - might be down to intrinsics/inlining and such? (the proflie for the DMC build says it's using ~1% of its time inside strlen and the profile for the MSVC build doesn't mention it at all, which i guess is because it's using an intrinsic version). If it's inlined then it won't show up in the profile. And yes, it's possible MSVC has a faster memcpy(). After all, enormous effort has been poured into memcpy(). If you use a profiler with line or instruction granularity (like perf on Linux), it will show up. On Windows, that would probably be VTune and CodeAnalyst.
Re: glamour / gl3n
Awesome. Will try out the new gl3n once I have time to work on my project.
Re: Call for D articles
On Saturday, 8 June 2013 at 02:58:31 UTC, Drew Sikora wrote: D Developers - If anyone is interested in contributing new work covering topics and techniques for the D language, GameDev.net would be happy to host them for you. We have recently begun an open submission process with peer review that makes it easy for you to send us content to publish to our main page and reside in our archives that are heavily indexed by Google. Please find all the details here: http://www.gamedev.net/page/resources/_/gdnethelp/how-to-publish-on-gamedevnet-r2927 Additionally, if any of you already have blogs or content out there that you would like to reach a wider audience we are happy to host re-prints of your content with links back to your blog/website. Thank you for your attention. Drew Sikora Executive Producer GameDev.net Thanks for the note, I'll probably post something in the summer (too busy atm).
Re: DConf 2013 Opening Keynote by Walter Bright: video and slides available
On Wednesday, 8 May 2013 at 18:24:34 UTC, Andrei Alexandrescu wrote: On 5/8/13 2:16 PM, Walter Bright wrote: On 5/8/2013 11:00 AM, Andrei Alexandrescu wrote: BTW what's a good site for sharing slides? Can't we just put them on dconf.org? We can offer them for download, but specialized sites offer nice online navigation. Andrei Current FF (and probably other browsers) has a builtin PDF reader, which is _much_ more convenient than any web-based tool I've seen. (And a real PDF viewer is better yet). I think there would be much less problems if the files were made available directly first - it takes little effort and would allow other people to, say, upload it to YouTube and million other sites.
Re: DConf 2013 Opening Keynote by Walter Bright: video and slides available
Vimeo is often used by FOSS projects. And YouTube, obviously. And it'd be good it there was a torrent, so it's easily downloadable.
Re: Standalone opengl bindings
Actually, the current (well, WIP) version is Derelict3: https://github.com/aldacron/Derelict3
Re: ICE 0.1: a moddable shoot-em-up in D
Also note: ICE does have some compile errors with git master DMD; at least because it uses D:YAML, which has known issues there. Bot there are no errors with DMD 2.060.
Re: ICE 0.1: a moddable shoot-em-up in D
On Friday, 21 December 2012 at 22:00:27 UTC, Rob T wrote: I get a few compilation errors using dmd 2.060, nothrow that can throw, pure that calls impure, as well as several warnings such as unreachable code and warnings concerning @safe and @trusted. After patching some of it up to get rid of the fatal compile errors, this last error left me scratching my head [Errno 2] No such file or directory: 'pong-debug' I had to give up, but I'm still interested in getting this game to work, so please let us know when you manage to solve these problems. thanks! --rt Are you sure you cloned ICE, not DPong? DPong was an older project that is unmaintained; although ICE reuses some of its code. ICE is developed with 2.060 and there're no compile errors there (although there are some warnings due to keeping backwards compatibility with DMD 2.058) ICE git repo: https://github.com/kiith-sa/ICE I did a grep and found some mentions of "pong" in ICE codebase, but it was just comments and an outdated packaging script (which I removed). Nothing that would affect compilation.
Re: ICE 0.1: a moddable shoot-em-up in D
On Friday, 21 December 2012 at 07:54:19 UTC, Jacob Carlborg wrote: On 2012-12-20 19:41, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. I've compiled the game on Mac OS X now and get the following runtime error: Failed to construct a video.sdlglvideodriver.SDLGLVideoDriver: Could not load OpenGL: Failed to load symbol glMatrixIndexPointerARB from shared library ../Frameworks/OpenGL.framework/OpenGL Perhaps you need to install new graphics drivers? Segmentation fault This is on a computer using Mac OS X 10.6, I'll try later on a Mac OS X 10.8 computer. Fork: https://github.com/jacob-carlborg/ICE/tree/osx This shouldn't happen as I don't even use that extension. It's possible that it's a bug in ICE's (outdated) copy of Derelict2. I updated Derelict2 now. Can you try pulling the changes?
Re: ICE 0.1: a moddable shoot-em-up in D
On Thursday, 20 December 2012 at 22:45:10 UTC, Benjamin Thaut wrote: Did you do something special about the GC? Does it run at all or do you somehow pool your objects? Kind Regards Benjamin Thaut I do use the GC; however, in general, I avoid using it for anything that gets called very often; e.g. once per entity per frame. Code that calls the GC once per frame is not a problem. The game entities are composed of components (disjoint in memory; every component type has a manually allocated array of all components of that type, and an entity has indices into these arrays), which are structs. When some action triggers an entity spawn (in SpawnerSystem, one of subsystems working on entities), an EntityPrototype - (struct of components, not yet an entity) is either reused or allocated. I preallocate a large number of these. Once the time comes for the entity to appear in the game, components from the EntityPrototype are copied to their respective arrays. These arrays are once again preallocated, and if they run out of space, they are enlarged. These are actually "segmented" (arrays of arrays), so I never reallocate, just allocate a next segment. Overall, memory allocation is no longer a concern. Actually, GC was never a problem (I always worked with the rule - if called many times per frame, don't use GC). However, manual allocation _was_ a problem; until I rewrote most of the code to preallocate. The worst case I had with the GC was about 10% of total time; now both GC and manual allocation is below 1%. Actually; just profiled (two-level game)- GC about 0.2% ; malloc & friends about 0.4%. In some cases I use pooling for structs that get created/destroyed often; these usually are arrays stored within components, e.g. WeaponComponent, which might have any number of weapons. I do this in a very hacky way, using an allocator template argument for my (custom) collections; this allocator is generally static and specific for type being allocated.
Re: ICE 0.1: a moddable shoot-em-up in D
To clarify: yes, GC runs all the time. It doesn't have a whole lot to collect, though. It'd be inconvenient to disable it as I use stuff like closures for GUI, etc.
Re: ICE 0.1: a moddable shoot-em-up in D
On Thursday, 20 December 2012 at 20:18:42 UTC, ponce wrote: On Thursday, 20 December 2012 at 18:41:13 UTC, Kiith-Sa wrote: Comments/criticism welcome (I've worked on a few toy game projects, but this is the first one that actually had a release; there are likely many beginner errors). Hi, If you are making a shoot-em-up (especially horizontal or vertical) you should be aware that the players in this space can be quite ann... er, hardcore. There are two things in your game that they hate with a passion: player inertia and lifebar. You might want to remove those because this will probably backfire in shoot-em-up communities. Interesting. I do play shoot-em-ups but I wouldn't call myself hardcore, so I guess I might have missed something. Removing/decreasing inertia might be a good idea, I see why it might frustrate some players. However, what's the issue with a health bar? Most shoot-em-ups I play have one (and I'm not making a one-hit-you're-dead game.) Is health bar undesirable because it obstructs the view? (i.e. would a different way of showing health be preferrable?) Or is it simply "not hardcore enough"? (i.e. player having no information about health would be better? That would make the gameplay worse in my view.)
Re: ICE 0.1: a moddable shoot-em-up in D
On Thursday, 20 December 2012 at 19:24:40 UTC, Jacob Carlborg wrote: On 2012-12-20 19:41, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. Cool, but where is the Mac OS X binary :) I don't have a Mac. It can probably run on Mac OS X, although there might be some bugs, as I have now way of testing it. If you manage to get it to work on Mac, pull requests welcome :)
ICE 0.1: a moddable shoot-em-up in D
This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. There's still a lot of work to do (moddability is there but no user-friendly editor, no ship upgrading, need better sounds, bosses), but at least the game is playable. We're using a component-based entity system (where components behave as plain data), allowing various custom entities to be created without touching the code. The game is pretty slow on older PC's; this is not a D issue, but some code (graphics) is just written very inefficiently right now. It's getting better, though; D features made it easy to write tools to profile memory allocations and frame times; we can do stuff like find the slowest frames, break them down into zones to find out what took the most time, even find the allocations made during these frames. (I'd like to separate thisinto another project in future). See the full announcement here: http://icegame.nfshost.com/index.html Download the game: http://icegame.nfshost.com/pages/downloads.html Forums: http://iceforum.nfshost.com/ Comments/criticism welcome (I've worked on a few toy game projects, but this is the first one that actually had a release; there are likely many beginner errors).
For Vim D users (snippets)
Helllo, I just read somewhere that there is no support for D in
Vim,
so I'll use this for a bit of self-advertisement.
A few days ago, I moved to UltiSnips vim script
(https://github.com/SirVer/ultisnips), which I found to be more
advanced and stable compared to SnipMate,
which I used previously.
I ported my SnipMate snippets to UltiSnips, removed some bugs,
and any project-specific stuff. Sent a pullrequest to UltiSnips
and got it merged.
TLDR:
You can do stuff like (imgur gallery):
http://imgur.com/a/RB7Pw
There is a _ton_ of snippets, maybe a bit too much (I found it
very useful
for pretty much every keyword to be a snippet, i.e.
"keyword" - and
I have generated code:
trivial shortcuts ("module" (with Boost license), "imp", "al",
"?:", "scope", ...)
type definitions class ("class", "struct", "enum", ...)
flow control ("sw", "if", "ife", "elif", "for", "do", ...)
commonly called functions ("wr", "enf", ...)
DDoc - assuming "///" comments ("doc", "Par", "Thr", "Ret", ...)
Various other stuff I forgot. See the "d.snippets" file.
To add new D snippets, ":UltiSnipsEdit" while editing a D file.
Ultisnips uses to activate snippets, and ,
to move
between tabstops (editable parts), I found setting the latter
to , to be more intuitive/less keystrokes.
UltiSnips snippets can be implemented in python and
als support various possibilities of where a snippet
should be allowed (to avoid areas where it makes no sense),
e.g. only on start of line, or even regex.
This stuff is not yet used much, but it could be used to improve
the snippets further.
UltiSnips: https://github.com/SirVer/ultisnips
My fork (newest D fixes): https://github.com/kiith-sa/ultisnips
Re: D:YAML 0.4 released
A workaround is to add .d to the command line, as it seems that phobos makes use of deprecated stuff on windows. Is there a bug for it already? Otherwise I could provide a fix. -- Paulo I'm currently working on a non-D project, and didn't yet check if it works with DMD newer than 2.058. I.m planning to fix any issues in September (but that will be with DMD 2.060).
Re: D:GameVFS 0.1
On Monday, 16 July 2012 at 17:27:32 UTC, Marco Leise wrote:
Am Fri, 20 Jan 2012 00:36:11 +0100
I didn't check your code, but does it handle case-insensitive
Windows OS as well as Unix like?
I didn't think consider this when working on it, so it's probably
always case-sensitive.
Did you think of ways to probably even switch the language from
a menu?
Outside of scope of D:GameVFS. Of course, you could just
mount different directories with language files based on user
input.
From your example in the readme, it isn't immediately clear
what the names 'user', 'main' and 'root' are used for.
No particular purpose, they could be used for anything. In my
game project,
I have "root" for read-only (what goes to somewhere in /usr on
Linux),
and "user" for read-write e.g. config, logs, screenshots, etc.
(what goes in /home/username/.gamedirectory).
I assume that StackDir inherits from FSDir which is a nice
design.
No. As you can see in the API docs, StackDir and FSDir both
inherit from
VFSDir. StackDir wraps one or more VFSDirs to wrap them. So you
could even
stack a zip dir (if/when a ZipDir is implemented) on top of an
FSDir.
I actually stack StackDirs on top of each other in my project.
I'd probably expect things to work out as in F.E.A.R. or Quake
where these things are implementation details. In other words,
the game *never* attempts a write access into it's data files.
Directories can be read-only. You also need write support for
stuff like
saves, config, screenshots, etc.
auto fs = new FileSystem();
fs.mount("main"); // can be directory "main" or "main.zip"
fs.mount("user"); // overrides main now
You can use a StackDir, and mount a ZipDir (if/when implemented)
_or_ an FSDir based on whether e.g. a zip exists or not, but
you't have to detect that yourself. I don't plan on adding such
API to D:GameVFS, but it would only
take a simple function on top of it.
Note that D:GameVFS is just 0.1 now. I just implemented what I
needed at the moment so far, stuff like a ZipDir will be only
added once I need it.
Of course, any contributions are welcome - it shouldn't be too
difficult.
For the game project, see https://github.com/kiith-sa/ICE, but it
doesn't
really use D:GameVFS that heavily - only to separate read-only
and read-write.
I'm planning to use it for mods later.
I'm currently outside the D world (working on a non-D related
GSoC project),
but I'm planning on revisiting D:GameVFS and D:YAML in September.
That will only be to update compatibility to DMD 2.060 (if it's
released by then) and to fix bugs, though.
Tango (which should now have a D2 port) also has a VFS API, which
has more features (e.g. zip support) - the reason I started
D:GameVFS was that I couldn't do some things (related to
stacking) I wanted with the Tango API.
Don't remember what exactly was the problem, though.
Re: D:YAML 0.4 released
Never mind, I needed to import core.stdc.stdlib; it should work correctly now.
Re: D:YAML 0.4 released
I added import core.stdc; Compiles with or without it here, though, so I can't say if it helped. However; does that even make sense? Shouldn't you have to import a particular module instead of just core.stdc?
Re: D:YAML 0.4 released
Greate news. DMD has a bug: dmd -inline -release -O -lib -ofyaml.lib yaml.d compile fine, but: dmd -noboundscheck -inline -release -O -lib -ofyaml.lib yaml.d emit errors. Was it a DMD bug, or did it actually compile and cause errors when running? I wasn't able to reproduce it, but I'm on Linux. If it's a DMD/Windows bug, it can't do much about it (although maybe 2.058 will help?) Or are you actually trying to compile D:YAML with that command? Use the CDC script in the source to do that (see the getting started tutorial for detailed info): ./cdc.d release That compiles the release build , which includes -O, -inline, -release and -noboundscheck .
D:YAML 0.4 released
I've released D:YAML 0.4 . This release brings mostly updates to keep compatibility with DMD 2.057 and bugfixes (in particular, compilation on 32bit works now). The constructor API has also been simplified. Any custom YAML types (structs and classes serialized directly from/to YAML nodes) now need to define the opCmp operator. This is used to detect duplicates and will be used for faster access to data in unordered maps in future. (AAs were used previously, but caused bugs) If this turns out to be too impractical, and if Phobos gets a usable hash map, I might use that in future - which would still require toHash and opEquals, though. API documentation, tutorials and examples were updated to reflect the changes, and slightly improved. See CHANGES.txt in the source package for detailed information. Again, the API is unstable and might change in future.
D:GameVFS 0.1
I've released D:GameVFS 0.1, a minimalist VFS library for game developers. I'm trying to librarize various pieces of code I'm working on for my projects; this is a very simple virtual file system library. Can only read/write/create files and directories, not delete them. Currently there is no archive support - shouldn't be too difficult to implement, but I'll only implement it if I need it (contributions are welcome). It can stack directories, which I need for easy moddability. There are also no security features - if a directory you're working with gets deleted, D:GameVFS can't handle that. The API is inspired by Tango VFS API, but made with ranges in mind, using RAII/refcounting and again, very minimal. API is not stable, and will change e.g. when std.stream gets rewritten. You can get D:GameVFS 0.1 here: https://github.com/kiith-sa/D-GameVFS/downloads For basic introduction, see the tutorial in the README at https://github.com/kiith-sa/D-GameVFS and the API documentation in the package.
Re: gl3n - linear algebra and more for D
David wrote:
> Hello,
>
> I am currently working on gl3n - https://bitbucket.org/dav1d/gl3n - gl3n
> provides all the math you need to work with OpenGL, DirectX or just
> vectors and matrices (it's mainly targeted at graphics - gl3n will never
> be more then a pure math library). What it supports:
>
> * vectors
> * matrices
> * quaternions
> * interpolation (lerp, slerp, hermite, catmull rom, nearest)
> * nearly all glsl functions (according to spec 4.1)
> * some more cool features, like templated types (vectors, matrices,
> quats), cool ctors, dynamic swizzling
>
> And the best is, it's MIT licensed ;). Unfortunatly there's no
> documentation yet, but it shouldn't be hard to understand how to use it,
> if you run anytime into troubles just take a look into the source, I did
> add to every part of the lib unittests, so you can see how it works when
> looking at the unittests, furthermore I am very often at #D on freenode.
> But gl3n isn't finished! My current plans are to add more interpolation
> functions and the rest of the glsl defined functions, but I am new to
> graphics programming (about 4 months I am now into OpenGL), so tell me
> what you're missing, the chances are good that I'll implement and add
> it. So let me know what you think about it.
>
> Before I forget it, a bit of code to show you how to use gl3n:
>
>
> vec4 v4 = vec4(1.0f, vec3(2.0f, 3.0f, 4.0f));
> vec4 v4 = vec4(1.0f, vec4(1.0f, 2.0f, 3.0f, 4.0f).xyz)); // "dynamic"
> swizzling with opDispatch
> vec3 v3 = my_3dvec.rgb;
> float[] foo = v4.xyzzzwzyyxw // not useful but possible!
> glUniformMatrix4fv(location, 1, GL_TRUE, mat4.translation(-0.5f, -0.54f,
> 0.42f).rotatex(PI).rotatez(PI/2).value_ptr); // yes they are row major!
> mat3 inv_view = view.rotation;
> mat3 inv_view = mat3(view);
> mat4 m4 = mat4(vec4(1.0f, 2.0f, 3.0f, 4.0f), 5.0f, 6.0f, 7.0f, 8.0f,
> vec4(...) ...);
>
> struct Camera {
> vec3 position = vec3(0.0f, 0.0f, 0.0f);
> quat orientation = quat.identity;
>
> Camera rotatex(real alpha) { orientation.rotatex(alpha); return this; }
> Camera rotatey(real alpha) { orientation.rotatey(alpha); return this; }
> Camera rotatez(real alpha) { orientation.rotatez(alpha); return this; }
>
> Camera move(float x, float y, float z) {
> position += vec3(x, y, z);
> return this;
> }
> Camera move(vec3 s) {
> position += s;
> return this;
> }
>
> @property camera() {
> //writefln("yaw: %s, pitch: %s, roll: %s",
> degrees(orientation.yaw), degrees(orientation.pitch),
> degrees(orientation.roll));
> return mat4.translation(position.x, position.y, position.z) *
> orientation.to_matrix!(4,4);
> }
> }
>
> glUniformMatrix4fv(programs.main.view, 1, GL_TRUE,
> cam.camera.value_ptr);
> glUniformMatrix3fv(programs.main.inv_rot, 1, GL_TRUE,
> cam.orientation.to_matrix!(3,3).inverse.value_ptr);
>
>
> I hope this gave you a little introduction of gl3n.
>
> - dav1d
I looked at your project yesterday (found it on derelict forums)
and it looks really good. Currently I'm using my own code for
vectors/matrices but a dedicated library could be better.
My comments:
Not sure if DMD will do a good job optimizing your code atm
(probably no way around this but to wait - uglifying the code would serve
no purpose)
In the future, SSE support would be nice (maybe will be easier to do if we
ever get SSE intrinsics)
Seems like most of the code is in linalg.d - wouldn't it be more maintainable
to have it separated for each struct, and then public import it through one
module for easy usage?
I'm doing a lot of 2D work, and could use at least a rectangle/aabbox struct
(if I use your lib, I'll implement rectangles on top of it anyway).
Some other structs might also be useful (3D aabbox, circle, sphere?)
Although, if you want to be as close to GLSL as possible, this might
not be a good idea.
Most D projects are under the Boost license.
If you want to get this to Phobos,
(I'd like something like this in Phobos :P)
I recommend using that license
(IANAL, but I don't see much difference between MIT and Boost)
The GLSL style is good if you want it as close to GLSL as possible,
but it'd be good to have more D-style aliases (again hinting at Phobos).
(Personally I'd probably use the GLSL style, though)
Re: D:YAML 0.3 released
torhu wrote: > On 17.11.2011 17:21, Kiith-Sa wrote: >> Performance is actually not an issue here, insignificant part of total >> parsing time is spent in Constructor (only about 2%) and any slowdown >> there should not be noticeable. >> >> The idea you're proposing here would indeed simplify the API, but >> I'm not sure if the result would always be what the user wants. >> >> Any exception (potentially user-defined) would be handled and its >> message added to a YAMLException, as we would need to catch(Exception) >> in the calling code. I can't think of an example where this could be >> a problem, since the exceptions we don't expect to be handled >> are usually derived from Throwable, but what if the user expects an >> exception to be thrown at MyStruct construction and not handled by >> D:YAML at all? >> > > Do you have an example of what that could be? OutOfMemoryError and > things like that would probably go straight through, since they are > Errors and not Exceptions. I have changed the Constructor API in this way for now. Couldn't come up with a good counterexample. If it turns out to be a mistake, I'll change it back before 1.0 .
Re: D:YAML 0.3 released
Performance is actually not an issue here, insignificant part of total parsing time is spent in Constructor (only about 2%) and any slowdown there should not be noticeable. The idea you're proposing here would indeed simplify the API, but I'm not sure if the result would always be what the user wants. Any exception (potentially user-defined) would be handled and its message added to a YAMLException, as we would need to catch(Exception) in the calling code. I can't think of an example where this could be a problem, since the exceptions we don't expect to be handled are usually derived from Throwable, but what if the user expects an exception to be thrown at MyStruct construction and not handled by D:YAML at all?
Re: D:YAML 0.3 released
torhu wrote:
> On 16.11.2011 21:15, Kiith-Sa wrote:
> ...
>> GitHub: https://github.com/kiith-sa/D-YAML
>> Docs : dyaml.alwaysdata.net/docs
>>
>> You can get D:YAML 0.3 here: https://github.com/kiith-sa/D-YAML/downloads
>>
>
> Great, I've been looking into YAML lately. Would be interesting to see
> how the speed of your library compares to Tango's XML parser. Maybe
> I'll do some benchmarking.
>
> I think your API could be simplified in some places. I rewrote one of
> your examples:
>
> ---
> bool constructMyStructScalar(ref Node node, out MyStruct result, out
> string customError)
> {
> auto parts = node.as!string().split(":");
>
> try
> {
> result = MyStruct(to!int(parts[0]), to!int(parts[1]),
> to!int(parts[2]));
> return true;
> }
> catch(Exception e)
> {
> return false;
> }
> }
> ---
>
> If the value is invalid, you just return false and let the library take
> care of the rest. If you want to give detailed info about the error,
> assign to customError. The code calling this function would throw an
> exception that contains the standard line and column info, plus your
> custom message.
Thanks for your input. Your example doesn't seem to be significantly
simpler, but a good point is that the Mark structures don't need to
be passed. I'm considering this style:
---
bool constructMyStructScalar(ref Node node)
{
auto parts = node.as!string().split(":");
try
{
return MyStruct(to!int(parts[0]), to!int(parts[1]), to!int(parts[2]));
}
catch(Exception e)
{
throw SomeExceptionType("message: " ~ e.msg); //wrapped by the caller
}
}
---
This would avoid passing the Marks and force the user to specify an
error message.
As for performance, I wouldn't expect D:YAML to be faster than a well
written XML parser. YAML has a rather complicated spec due to its goal
of human readability. A faster parser could be written if various less
commonly used features were left out, e.g. if only a subset equivalent
to JSON would be supported.
Still, I'm interested in the results - both time taken and memory usage -
maybe something could be found to further improve D:YAML performance.
If you have any more ideas on how to simplify D:YAML API, I'd like to
see them. I'm only planning to freeze the API with a 1.0 release
(which must wait for some Phobos changes), and would like to make it as
good as possible until then.
D:YAML 0.3 released
I've released D:YAML 0.3 . This release brings some API improvements and many optimizations, drastically improving parsing speed and decreasing memory usage. There are also many bugfixes, more examples, and both the API documentation and tutorials have seen various improvements. D:YAML is a YAML parser and emitter library for D. API has been streamlined, Constructor in particular is now easier to use to add support for custom YAML data types. Constructor API compatibility has been broken as a result. Another breaking change is removal of the Node.getToVar method as it turned out to be a premature optimization. Node.get can now be used in a shorter form - Node.as , which might eventually replace it (1.0 release). Nodes now preserve their styles between loading and dumping. There is no way to access those styles, though (as it should be according to the specification). Focus of this release was optimization, greatly reducing parsing/emitting time and memory usage (in particular, decreasing garbage collector usage). There are no comparative benchmarks at the moment, but parsing time seems to be reduced to about 10%, and dumping time to about 50%. Error messages, API documentation and tutorials were improved as well. There are also new example and benchmark applications. Lastly, there were many bugfixes. See CHANGES.txt in the source package for detailed information. As before, it should be noted that D:YAML API is a work in progress, and there WILL be more breaking changes (although most of the API should now be in place). GitHub: https://github.com/kiith-sa/D-YAML Docs : dyaml.alwaysdata.net/docs You can get D:YAML 0.3 here: https://github.com/kiith-sa/D-YAML/downloads
Re: D:YAML 0.2 released
bls wrote:
> Am 15.10.2011 19:06, schrieb Kiith-Sa:
>> I've just released D:YAML 0.2 . This release brings emitting
>> functionality
> ...
>
> what do you think about bringing in (adapt) your YAML tool into the
> Orange serialisation library. (orange..
> https://github.com/jacob-carlborg/orange)
>
> Sounds probably not too interesting but in conjunction with the upcoming
> std.database/ ORM stuff Serialisation/De-Serialisation will become
> pretty important .
>
> // occupied snippet from Orange ..
> class Foo
> {
> int a;
> }
>
> void main ()
> {
> auto foo = new Foo; // create something to serialize
> foo.a = 3; // change the default value of "a"
>
> auto archive = new YAMlArchive!(char); // create an yaml archive
> auto serializer = new Serializer(archive); // create the serializer
>
> serializer.serialize(foo);
I can't rule out doing this in the future, but it seems like Orange work,
not D:YAML work.
Currently, D:YAML API is still not stable, so I don't think it would be a
good idea right now anyway. Once the API is stable, I'll do a 1.0 release.
Further releases will see no breaking changes.
Re: D:YAML 0.2 released
Jacob Carlborg wrote:
> On 2011-10-15 19:06, Kiith-Sa wrote:
>> I've just released D:YAML 0.2 . This release brings emitting
>> functionality, finishing the main part of D:YAML feature set. From now
>> on, the focus will be on polishing D:YAML, making code more maintainable,
>> optimizing and improving documentation.
>>
>> D:YAML is a YAML parser and emitter library for D.
>>
>> Emitting code has been fully implemented (mostly translated from PyYAML),
>> along with support for emitting custom types (loading custom types
>> already works with 0.1).
>>
>> YAML tags are now stored in nodes, allowing D:YAML to be more compliant
>> to the specification.
>>
>> Many scanner, composer and constructor bugs have been fixed.
>>
>> Loader API has been broken to make it more extensible in future -
>> Representer and Constructor are no more specified in the constructor,
>> and the load() shortcut functions have been removed, as all that's needed
>> to load a YAML document now is Loader("file.yaml").load() .
>>
>> Tutorials, API documentation and examples have been updated to reflect
>> the changes.
>>
>>
>> Note that D:YAML is still a work in progress and its API might yet see
>> some compatibility breaking changes. Basic Loader/Dumper API is unlikely
>> to break any more, but it will be updated when std.stream is rewritten.
>>
>> GitHub: https://github.com/kiith-sa/D-YAML
>> Docs : dyaml.alwaysdata.net/docs
>>
>> You can get D:YAML 0.2 here: https://github.com/kiith-sa/D-YAML/downloads
>
> I can see that D:YAML is Boost licensed, how does that work out when
> PyYAML is MIT licensed?
>
I asked Kirill Simonov (the PyYAML dev) about releasing D:YAML under the
Boost license, he said he has no problem with that.
D:YAML 0.2 released
I've just released D:YAML 0.2 . This release brings emitting functionality,
finishing the main part of D:YAML feature set. From now on, the focus will
be on polishing D:YAML, making code more maintainable, optimizing and
improving documentation.
D:YAML is a YAML parser and emitter library for D.
Emitting code has been fully implemented (mostly translated from PyYAML),
along with support for emitting custom types (loading custom types
already works with 0.1).
YAML tags are now stored in nodes, allowing D:YAML to be more compliant to
the specification.
Many scanner, composer and constructor bugs have been fixed.
Loader API has been broken to make it more extensible in future -
Representer and Constructor are no more specified in the constructor,
and the load() shortcut functions have been removed, as all that's needed to
load a YAML document now is Loader("file.yaml").load() .
Tutorials, API documentation and examples have been updated to reflect the
changes.
Note that D:YAML is still a work in progress and its API might yet see some
compatibility breaking changes. Basic Loader/Dumper API is unlikely to break
any more, but it will be updated when std.stream is rewritten.
GitHub: https://github.com/kiith-sa/D-YAML
Docs : dyaml.alwaysdata.net/docs
You can get D:YAML 0.2 here: https://github.com/kiith-sa/D-YAML/downloads
Re: D:YAML 0.1
Jacob Carlborg wrote: > On 2011-08-16 21:12, Kiith-Sa wrote: >> Jacob Carlborg wrote: >> >>> On 2011-08-16 20:13, Kiith-Sa wrote: >>>> D:YAML is a YAML parser library for D. >>>> >>>> It is mostly compliant with the YAML 1.1 spec, although there are some >>>> unsupported features (e.g. recursive data structures). >>>> >>>> Currently there is only a parser, not an emitter. >>>> >>>> The API is not yet stable, there will be breaking changes. (e.g. part >>>> of the API depends on std.stream and will probably be changed when >>>> std.stream is rewritten.) >>>> >>>> Docs can be found in doc/html in the package. There are some (very) >>>> basic tutorials/examples and an API doc. >>>> >>>> Much of D:YAML code has been ported to D from PyYAML. >>>> >>>> D:YAML is written in D2. There is no D1 or Tango support, and none is >>>> planned. >>>> >>>> Link: https://github.com/kiith-sa/D-YAML >>> >>> Interesting, I've been looking for a D YAML library for a while. How is >>> the performance, have you made any benchmarks? >>> >> >> Not yet. I intend to implement an emitter first and then start >> benchmarking/profiling/optimizing. However, as much of the code is >> directly translated from PyYAML (Python code, not the libYAML C >> extension), I imagine it will be somewhat faster than that. > > Does the parser/lexer take advantage of D's slices to make it faster? > In some places, yes, in some places, no. I didn't concentrate on preventing new strings from being allocated, but a lot of string data should pass through the code unchanged, with just slices changing. Phobos functions should help with that (E.g: afaik when you split() a string, you just get slices to the same string data?). Still, the parser, scanner (and composer) are precisely the parts of code that were ported from PyYAML, and the code is mostly similar to PyYAML.
Re: D:YAML 0.1
Jacob Carlborg wrote: > On 2011-08-16 20:13, Kiith-Sa wrote: >> D:YAML is a YAML parser library for D. >> >> It is mostly compliant with the YAML 1.1 spec, although there are some >> unsupported features (e.g. recursive data structures). >> >> Currently there is only a parser, not an emitter. >> >> The API is not yet stable, there will be breaking changes. (e.g. part of >> the API depends on std.stream and will probably be changed when >> std.stream is rewritten.) >> >> Docs can be found in doc/html in the package. There are some (very) basic >> tutorials/examples and an API doc. >> >> Much of D:YAML code has been ported to D from PyYAML. >> >> D:YAML is written in D2. There is no D1 or Tango support, and none is >> planned. >> >> Link: https://github.com/kiith-sa/D-YAML > > Interesting, I've been looking for a D YAML library for a while. How is > the performance, have you made any benchmarks? > Not yet. I intend to implement an emitter first and then start benchmarking/profiling/optimizing. However, as much of the code is directly translated from PyYAML (Python code, not the libYAML C extension), I imagine it will be somewhat faster than that.
D:YAML 0.1
D:YAML is a YAML parser library for D. It is mostly compliant with the YAML 1.1 spec, although there are some unsupported features (e.g. recursive data structures). Currently there is only a parser, not an emitter. The API is not yet stable, there will be breaking changes. (e.g. part of the API depends on std.stream and will probably be changed when std.stream is rewritten.) Docs can be found in doc/html in the package. There are some (very) basic tutorials/examples and an API doc. Much of D:YAML code has been ported to D from PyYAML. D:YAML is written in D2. There is no D1 or Tango support, and none is planned. Link: https://github.com/kiith-sa/D-YAML
AutoDDoc
AutoDDoc is a simple documentation generator script for D. It's a single file Python script that scans a project directory, finds D sources and generates documentation using DMD or something else that can process DDoc. At first it was only meant for my personal projects, but I think it might be of some use to someone. I used Python for convenience, it should not be difficult to rewrite in D, but I still prefer Python for scripts. It's cotrolled by a configuration file similarly to Doxygen, but with only basic settings (project name, version, output directory, which sources to ignore, etc.). It's trivial to generate basic documentation for a project, no need to play with DMD directly. It only generates HTML (CSS can be specified by user) and assumes that directory/file structure matches package/module structure. It includes some DDoc macros and CSS based on phobos/d-p-l.org sources. Link: https://github.com/kiith-sa/AutoDDoc
