Re: DConf keynote speaker ideas
On Sunday, 22 November 2015 at 15:23:18 UTC, Andrei Alexandrescu wrote: On 11/22/2015 06:38 AM, Mathias Lang via Digitalmars-d wrote: Over the proposed speakers so far, Carmack would be my favorite. I've asked him a few days ago, he declined. -- Andrei +1 for Tim Sweeney (if Carmack is not available). AFAIK he even was somehow involved with D waaay back around 2000. ... after googling: not sure about involved, but he did post to the forum: https://www.google.sk/search?sclient=psy-ab=2=1678=985=1=cdr%3A1%2Ccd_min%3A01.01.1999%2Ccd_max%3A01.01.2002=tim+sweeney+digital+mars=tim+sweeney+digital+mars_l=serp.3...55655.57773.1.57878.13.8.0.0.0.0.0.0..0.00...1c.1.64.serp..13.0.0.sPMPPuI2DqA https://www.google.sk/search?sclient=psy-ab=2=1678=985=1=cdr%3A1%2Ccd_min%3A01.01.1999%2Ccd_max%3A01.01.2002=tim+sweeney+d+lang=tim+sweeney+d+lang_l=serp.3...78672.79872.2.80041.7.6.0.0.0.0.0.0..0.00...1c.1.64.serp..20.0.0.NXIxL1ISmy0
Re: std.container: fork in the road
1. Just keep the current spec and deal with it. Some containers are and will remain garbage collected because they started as such. Add new containers that are better alongside them. 2. Do break compatibility of containers, mainly by taking advantage of them being under-documented. In a way we wouldn't break much because not much has been specified. There are, however, parts where we'd need to change specification. 3. Leave std.container alone and move forward with std.experimental.collection. I am confident the language and its endorsed idioms have reached enough maturity to not make this addition into a regular event. Andrei 3 or 2. std.allocator support is important as well (otherwise may as well continue rolling my own incomplete containers). std.container was always 'sorta usable' but never good enough.
Re: Right after allocators: containers or database connectivity?
On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote: My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly. After that I'm ready for some major library work, and I had two things in mind. One would be a good pass of std.container, in particular (a) a design review with the DbI glasses on; (b) better documentation - sadly it seems to me so inadequate as to make containers themselves unusable; (c) investigate use of UFCS - std.container's design predates UFCS yet is a perfect fit for it, and most likely other cool language improvements we've added since. The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options. For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford). So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up. Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice! It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there! Please help me choose what to work on next. Andrei Containers. But - we really need those allocators working in actual released Phobos first.
Re: Any news from Kiith-Sa ?
On Tuesday, 31 March 2015 at 14:32:38 UTC, Baz wrote: Kiith-Sa, come back with us !! I'm currently ignoring all my projects and GitHub in general to avoid distraction as I'm closing the end of my university studies (thesis, finals, events, etc.). I expect to resume working on my projects in 2 months or so.
Re: Unreal Bindings
On Tuesday, 3 March 2015 at 22:01:46 UTC, Jonas Drewsen wrote: On Tuesday, 3 March 2015 at 17:15:47 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 3 March 2015 at 15:59:20 UTC, Per Nordlöw wrote: Unreal Engine 4 is not free: https://www.unrealengine.com/blog/ue4-is-free D bindings anyone? Yes, please! Although 5% of gross earnings is more like «free»... Shameless plug. Unity3d 5.0 is now free and with no revenue share. http://unity3d.com aaand no source code access, i.e. no ability to work on D bindings (or, of fixing bugs when they can't be fixed in a timely fashion - after all, prioritized bug handling (still not nearly as good as source access) comes at a cost).
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 digitalmars-d-announce@puremagic.com 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)
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)
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 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: H1 2015 Priorities and Bare-Metal Programming
On Monday, 2 February 2015 at 14:43:22 UTC, Manu wrote: On 2 February 2015 at 07:47, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/1/2015 3:29 AM, weaselcat wrote: On Sunday, 1 February 2015 at 11:22:04 UTC, Johannes Pfau wrote: which perform as well as C code, but only with force-inline why is this still not part of the language? I'm not sure of anything else that has been repeatedly asked for without any good counterarguments. Because http://wiki.dlang.org/DIP56 generated nothing but controversy. I'm pretty sure the only controversy is that you want it to be a pragma, everyone else wants it to be an attribute. I don't think anyone has argued against a force_inline. I don't care if it is a pragma or attribute or whatever, it just *needs to exist*.
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 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.
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: 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?
Re: defunct / stale forums on front page
On Monday, 26 January 2015 at 03:17:55 UTC, Vladimir Panteleev wrote: On Monday, 26 January 2015 at 03:14:00 UTC, ketmar wrote: On Mon, 26 Jan 2015 02:36:29 +, Vladimir Panteleev wrote: On Monday, 26 January 2015 at 02:13:44 UTC, ketmar wrote: On Mon, 26 Jan 2015 02:00:01 +, Laeeth Isharc wrote: Imagine you move from a javascript browser to one without dlang.org is imfunctional without js, so there is no sense to make anything else working right without js. dlang.org should work just fine without JS. Same goes for the forums, but of course you won't be able to use the JS-powered horizontal-split view mode. yet it doesn't work: side menu is not working anymore, which renders dlang.org completely unusable for me. Everything works for me. The menu is completely expanded without JS, providing access to all areas of the website. Please explain what exactly doesn't work. It's broken if dlang.org is allowed yet ajax.googleapis.com is disallowed. Thus anyone who blocks google yet has dlang.org enabled (e.g. for the links in docs) is unable to use the menus.
Re: Czech D community
Nie som Cech, ale som zo Slovenska (vychod), robim kod pre diplomivku v D (https://github.com/kiith-sa/tharsis-core) a zatial som robil 2 kratke prednasky/workshopy v Kosiciach na propagaciu. Mam podozrenie ze kym sa drasticky nezvysi popularita D, akekolvek ceske/slovenske forum bude mat minimalnu aktivitu lebo vacsia cast ludi (tych co vedia anglicky) pojde na forum.dlang.org, ale za pokus to stoji. I'm not Czech, but I'm from Slovakia (east), I'm writing code for my master's thesis in D (https://github.com/kiith-sa/tharsis-core) and so far I've given 2 short talks/workshops in Kosice to promote it. I suspect that until a drastic increase in D popularity, the activity of czech/slovak forum would be minimal because the majority of people (of those who speak english) will use forum.dlang.org, but it's worth trying.
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: Data-Oriented Demo: SOA, composition via crazy 'using'
On Thursday, 22 January 2015 at 19:28:13 UTC, Justin Whear wrote: On Thu, 22 Jan 2015 18:03:31 +, Justin Whear wrote: On Thu, 22 Jan 2015 17:40:17 +, Justin Whear wrote: I just whacked this out in D: http://dpaste.dzfl.pl/90d96cf05792 Remembered the allMembers trait, using a pointer to parent, etc: http:// dpaste.dzfl.pl/6fd66ae9b767 OK, I'm done now. 100% better: http://dpaste.dzfl.pl/4ac987a0fc5a Could you put this up on GitHub/dub? Even if simple this could be very useful.
Re: dlang.org redesign n+1
On Wednesday, 21 January 2015 at 17:16:52 UTC, Sebastiaan Koppe wrote: On Wednesday, 21 January 2015 at 17:12:22 UTC, aldanor wrote: Sebastian, could please you publish your fork somewhere so we could take a closer look and/or fork/destroy it? It would also be easier to make specific suggestions https://github.com/skoppe/dlang.org I case you only want to make changes to the css, you can checkout the `compiled` branch and just make changes to the css/styles.css Too much wasted space on wide screens (right half of the screen is almost empty) Suggested improvement: http://imgur.com/a/zgSJa
Re: dlang.org redesign n+1
On Thursday, 22 January 2015 at 01:34:01 UTC, Sebastiaan Koppe wrote: On Wednesday, 21 January 2015 at 17:52:56 UTC, Kiith-Sa wrote: Suggested improvement: http://imgur.com/a/zgSJa Can't open link. Direct image links: current: http://i.imgur.com/5IN3Nui.png better: http://i.imgur.com/CdgKxhM.png (this will be even better for the cases where there are multiple text blocks besides a code block) - it both helps save horizontal space and slightly decreases the need for scrolling.
Re: New menus are up
On Tuesday, 20 January 2015 at 16:33:43 UTC, Vladimir Panteleev wrote: On Tuesday, 20 January 2015 at 16:31:12 UTC, bearophile wrote: Vladimir Panteleev: All expandable sections should show up as expanded when no JS is available. But currently they aren't doing that, right? They are. It is working for me when I disable JS in Firefox (via about:config). If it doesn't work for you, how can I reproduce the problem? It's broken with NoScript if dlang.org is allowed but ajax.googleapis.com is disallowed.
D on Slashdot
http://developers.slashdot.org/story/15/01/20/2026221/is-d-an-underrated-programming-language?utm_source=rss1.0mainlinkanonutm_medium=feed
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: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 07:44:24 UTC, Andrei Alexandrescu wrote: On 1/17/15 11:42 PM, DaveG wrote: On Sunday, 18 January 2015 at 04:44:56 UTC, Israel wrote: On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? I'd appreciate your help with reviewing and pulling this, and also with improving the colors (which I'm terrible at) and page tracking as mentioned in the pull request. I'm no designer, but I do have some comments. Without consistency it just looks a bunch of parts rather than a singular thing. Some elements have gradients, some don't. Some elements have round corners, some don't. Elements with borders use different widths, some have none. In regards to borders, we engineering types (maybe it's just me) tend to put boxes around stuff to represent discrete units when basic design concepts, like proximity and contrast, may be better suited for the task. I just took a quick pass at it in the browser: Original: https://dl.dropboxusercontent.com/u/114394/D-site/current.png Cleanup: https://dl.dropboxusercontent.com/u/114394/D-site/001.png Cleanup w/o bg: https://dl.dropboxusercontent.com/u/114394/D-site/002.png Think consistency and subtlety. Good design generally goes unnoticed. Looking good. Could you please do a pull request after mine gets in? Thanks! -- Andrei The thing with the red gradients looks incredibly horrible/ bad constrast actually makes it physically (eye strain) unpleasant. The cleanup looks better, but now the site has 3 columns with 3 different styles (not just colors, but e.g. flat vs gradient, edgy vs rounded, having that extra border on the bottom vs not having it) Dlang.org needs design by a designer, not by art-insensitive programmers. No, I'm not much of a designer either, unfortunately. But it should not be too hard to find a student with decent art sense who can do much better than this. Also, note that the collapsible menu can be done in pure CSS, no JS needed, which would allow it to work consistently even with NoScript.
Re: css minification
I looked at the favicon, and... the file is .ico (bad format), stores 5 versions of the icon (16x16 to 64x64) even though only 16x16/32x32 are supported. Here are just the 16x16(383b) and 32x32(1.77kiB) versions, as PNGs (better compression than gif, and official standard - used RGBA, as 8-bit lost quality with almost identical size): http://imgur.com/l4612WV,ThgDnJH#0 . Pick one and use it. I cut 1 pixel column from the 16x16 version because it was... 17x16. See http://www.w3.org/2005/10/howto-favicon
Re: css minification
On Friday, 16 January 2015 at 21:39:52 UTC, Andrei Alexandrescu wrote: On 1/16/15 1:32 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 21:26:04 UTC, Andrei Alexandrescu wrote: Well good point. As of January two of the css files are in the top 3 most trafficked files off of dlang.org, second only to favicon.ico. That's probably because HTTP caching is not configured. Ideally, you'd put the file's modification time in its path, e.g.: link rel=stylesheet type=text/css href=css/1421443851/style.css / css/*/style.css would point to the same style.css (via internal, not HTTP redirect). Then, css/* can be cached forever, as the URL of the file would change when the file changes. This is what DFeed does, but I'm not sure if this is feasible with just DDoc and makefiles, though. Nice. Wanna take it up? Generally I'm looking for less work for me and more work for others :o). -- Andrei Also, -1 for CSS minification, if I'll ever want to make any CSS contibutions I'll start by looking at the CSS in the browser. +1 for gzip and caching. *don't even consider* microoptimizations like this if you're not even doing that yet, whatever gains you might get are negligible by comparison.
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: Thoughts on replacement languages (Reddit + D)
On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote: On Sunday, 11 January 2015 at 06:56:02 UTC, thedeemon wrote: At this moment I only see some popularity comparisons Yes in fact they are talking more about popularity between both languages. and I think they're generally correct... Since I'm relative new here, I want know from you agree with this statement: [–]clay_davis_sheeit 4 points 17 hours ago* get real. D is more dead now than it was a year ago. if you won't accept repo counts, look at how many people attended D con vs Gophercon Matheus. That guy has been trolling every D thread in the last year. Either way, D is definitely way more popular/active than it was a year ago, especially with a large jump around last summer, but not nearly as much as Go nor Rust at the moment. (D Rust Go at the moment as far as popularity is concerned).
Re: ddox question
On Sunday, 11 January 2015 at 17:28:37 UTC, Andrei Alexandrescu wrote: On 1/11/15 3:03 AM, Mathias LANG wrote: On Saturday, 10 January 2015 at 17:23:24 UTC, Andrei Alexandrescu wrote: In the ddox-generated documentation the heading is e.g. Module std.container. I wanted to style std.container in code font, but can't find where that text is generated. I've searched dlang.org/ and dub/, no avail. Andrei IIUC, you're looking for this: https://github.com/rejectedsoftware/ddox/blob/ce797a3182c1263feb4a6f4c9ce9b88b95d83003/views/layout.dt Which is the base of all layout. But from a quick look (https://github.com/rejectedsoftware/ddox/search?utf8=%E2%9C%93q=h1), the title is the only h1 on the page, so you could just tweak the CSS. I don't think the CSS would be enough. The title is Module xxx.yyy. I only need to format xxx.yyy in code font. How do I do that? -- Andrei Seems to be https://github.com/rejectedsoftware/ddox/blob/ce797a3182c1263feb4a6f4c9ce9b88b95d83003/views/ddox.module.dt (line 9) Just look at files in https://github.com/rejectedsoftware/ddox/tree/ce797a3182c1263feb4a6f4c9ce9b88b95d83003/views . I don't use DDox, but it's easy to get around.
Re: core.stdc.* documentation
On Monday, 12 January 2015 at 00:29:49 UTC, Andrei Alexandrescu wrote: I just fixed documentation to generate docs for all symbols in core.stdc.complex. Looks unhelpful: http://erdani.com/d/library-prerelease/core/stdc/complex.html Any idea on how to make this better? Thanks, Andrei Links to cppreference.com . Please not LUCKY, it often results in not-the-best or even straght not-good results. E.g. cacos/cacosf/cacosl: http://en.cppreference.com/w/c/numeric/complex/cacos
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 00:33:52 UTC, Andrei Alexandrescu wrote: On 1/11/15 4:33 PM, MattCoder wrote: On Sunday, 11 January 2015 at 23:27:34 UTC, Nick B wrote: Perhaps its better to have a number (average or mean) than no number. Just ask 50 or 100 uers (or more) for their number of downloads for the last 12 or 18 months. This is turn will give you a guess-estimate as to the size of the community. If the number is small, say 4, then this will indicate that the community is near 100,000 users. Interesting for example, in my case I downloaded twice on the last 12 months (2.062 and 2.066). Answers from others would be helpful. Thanks! -- Andrei About 3-5 per release on average in my case. (I have 3 machines and often change distros on 2 of them). If I count D workshops, +30, but most of those are not likely to become D users.
Re: Game development
On Thursday, 8 January 2015 at 16:53:46 UTC, Ras wrote: Hello, I want to write the game engine in C++ and write all the game logic and ai etc in D. How would i do this? Manu Evans has pretty much this, he's active on this newsgroup, maybe he can help you: https://github.com/TurkeyMan/fuji . But writing a game engine is not something you can simply do quickly or that someone can do for you. It can take years depending on what the engine is supposed to do. Connecting C++ with D is a trivial detail compared to all the work involved.
Re: 4x4
On Thursday, 8 January 2015 at 16:27:48 UTC, Andrei Alexandrescu wrote: On 1/8/15 8:19 AM, Johannes Pfau wrote: What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? As we usually don't rename functions with inconsistent naming or otherwise bad names because of backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect. I was thinking along the way of simplifying documentation and links. -- Andrei This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.)
Re: call for GC benchmarks
On Monday, 5 January 2015 at 14:52:36 UTC, Martin Nowak wrote: On 01/05/2015 11:26 AM, Benjamin Thaut wrote: If you are interrested I might be able to branch of a old revision and make it compile with the latest dmd again. I'm interested in realistically simulating your allocation patterns. That includes types and allocation sizes, allocation order, lifetime and connectivity. Definitely sounds interesting. Maybe make a proxy GC, record all allocations to a file, then replay those allocations as a benchmark?
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: Worst Phobos documentation evar!
On Wednesday, 31 December 2014 at 19:11:27 UTC, Walter Bright wrote: On 12/31/2014 7:20 AM, Vladimir Panteleev wrote: On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright wrote: * reddit * github These both use Markdown. The syntax is the same, except for minor things, such as the handling of newlines. Yes, the same only different. * wiki * hackernews Hacker News and both the new D Wiki, and the old, do not use Markdown. It's just another variation of it - which is my point. It's NOT a different variant. It's a different LANGUAGE. That's like saying D is a variant of Pascal.
Re: Worst Phobos documentation evar!
On Wednesday, 31 December 2014 at 20:05:43 UTC, Walter Bright
wrote:
On 12/31/2014 11:45 AM, Kiith-Sa wrote:
It's NOT a different variant. It's a different LANGUAGE.
That's like saying D is a variant of Pascal.
It's not illegitimate to consider all { } languages as variants
of each other.
With that kind of thinking everyone would still be using COBOL
and FORTRAN.
Re: Worst Phobos documentation evar!
On Wednesday, 31 December 2014 at 23:53:48 UTC, Walter Bright wrote: On 12/31/2014 3:42 PM, ketmar via Digitalmars-d wrote: ah, the following is even better: Now do it it markdown. Oh wait, markdown doesn't enable specification of different kinds of fonts and formatting. Markedown doesn't have local hyperlinks. Have fun with LUCKY in markdown. Of course, you can skip all that and just have generic tables, and generic formatting and fantastically ugly urls, but you can do that in Ddoc, too, and avoid using any pesky macros like LUCKY. I'll make it easy for you. Just show us $(LUCKY Boyer-Moore _algorithm) in markdown. The point is, you do not have to use the macros if Ddoc if you don't want to. seriously, which part of: DDoc with Markdown do you fail to understand? This: http://defenestrate.eu/docs/tharsis-core/concepts/process.html is the kind of article I write in my documentation (one of the first few, there will be about 10 more). It's in ReStructuredText, which again, is pretty much a more feature-rich Markdown. I couldn't do that with DDoc without an extremely unreadable source; now, with DDoc+Markdown (https://github.com/kiith-sa/harbored-mod), I can do it with maybe one macro for the admonitions.
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: Worst Phobos documentation evar!
About that user experience: http://forum.dlang.org/post/nyclgpfzpkzemgitf...@forum.dlang.org
Re: Worst Phobos documentation evar!
And here's that modified documentation generator with Markdown support (won't help anyone trying to contribute to Phobos, but maybe other projects): http://forum.dlang.org/thread/itizuviesrhfaijyi...@forum.dlang.org
Idea/request: If you have a DUB project, add a code.dlang.org badge to README
(accidentally posted this into D.learn first, was intended to be here) A few weeks/months ago someone here mentioned that it'd be good if DUB projects linked to code.dlang.org to help anyone who runs into such a project quickly discover other D projects. MAny GitHub projects have badges/shields on top of their READMEs - little image strips showing things like continuous integration status, code coverage, etc. There's also a service generating these: shields.io I generated a simple listed at| code.dlang.org shield, and added it to my project READMEs as a link pointing to code.dlang.org for example, see D:YAML README: https://github.com/kiith-sa/D-YAML You can do the same by either linking to or downloading the shield: https://img.shields.io/badge/listed%20at-code.dlang.org-red.png (used red... because mars) and putting the image (whether as a link to shields.io or your own copy) into your README. It's not likely to be a huge improvement, but I expect it *can* help people notice more D projects and it's trivial to do.
Idea/request: If you have a DUB project, add a code.dlang.org badge to README
A few weeks/months ago someone here mentioned that it'd be good if DUB projects linked to code.dlang.org to help anyone who runs into such a project quickly discover other D projects. MAny GitHub projects have badges/shields on top of their READMEs - little image strips showing things like continuous integration status, code coverage, etc. There's also a service generating these: shields.io I generated a simple listed at| code.dlang.org shield, and added it to my project READMEs as a link pointing to code.dlang.org for example, see D:YAML README: https://github.com/kiith-sa/D-YAML You can do the same by either linking to or downloading the shield: https://img.shields.io/badge/listed%20at-code.dlang.org-red.png (used red... because mars) and putting the image (whether as a link to shields.io or your own copy) into your README. It's not likely to be a huge improvement, but I expect it *can* help people notice more D projects and it's trivial to do.
Re: Idea/request: If you have a DUB project, add a code.dlang.org badge to README
On Tuesday, 30 December 2014 at 21:19:52 UTC, jklp wrote: On Tuesday, 30 December 2014 at 21:12:38 UTC, Kiith-Sa wrote: A few weeks/months ago someone here mentioned that it'd be good if DUB projects linked to code.dlang.org to help anyone who runs into such a project quickly discover other D projects. MAny GitHub projects have badges/shields on top of their READMEs - little image strips showing things like continuous integration status, code coverage, etc. There's also a service generating these: shields.io I generated a simple listed at| code.dlang.org shield, and added it to my project READMEs as a link pointing to code.dlang.org for example, see D:YAML README: https://github.com/kiith-sa/D-YAML You can do the same by either linking to or downloading the shield: https://img.shields.io/badge/listed%20at-code.dlang.org-red.png (used red... because mars) and putting the image (whether as a link to shields.io or your own copy) into your README. It's not likely to be a huge improvement, but I expect it *can* help people notice more D projects and it's trivial to do. red is connoted negative/agressive, I think blue would be better. Or maybe yellow-mustard for those who have doubtful tastes... If you want blue, just replace red with blue. I used red because it's the color of the D logo, site and the color of Mars (as D was originally called Mars and lot of D things are named after Mars, e.g. Phobos/Deimos etc.)
Re: Idea/request: If you have a DUB project, add a code.dlang.org badge to README
On Tuesday, 30 December 2014 at 21:19:52 UTC, jklp wrote: On Tuesday, 30 December 2014 at 21:12:38 UTC, Kiith-Sa wrote: A few weeks/months ago someone here mentioned that it'd be good if DUB projects linked to code.dlang.org to help anyone who runs into such a project quickly discover other D projects. MAny GitHub projects have badges/shields on top of their READMEs - little image strips showing things like continuous integration status, code coverage, etc. There's also a service generating these: shields.io I generated a simple listed at| code.dlang.org shield, and added it to my project READMEs as a link pointing to code.dlang.org for example, see D:YAML README: https://github.com/kiith-sa/D-YAML You can do the same by either linking to or downloading the shield: https://img.shields.io/badge/listed%20at-code.dlang.org-red.png (used red... because mars) and putting the image (whether as a link to shields.io or your own copy) into your README. It's not likely to be a huge improvement, but I expect it *can* help people notice more D projects and it's trivial to do. red is connoted negative/agressive, I think blue would be better. Or maybe yellow-mustard for those who have doubtful tastes... aand what I was supposed to post (I didn't itend to put this in D.learn): http://forum.dlang.org/thread/tbspahcinalabopfb...@forum.dlang.org#post-tbspahcinalabopfbxey:40forum.dlang.org
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 19:47:50 UTC, Walter Bright wrote: On 12/29/2014 3:19 AM, Jacob Carlborg wrote: On 2014-12-29 06:39, Walter Bright wrote: Having used both Ddoc and Markdown, I seriously disagree with this. Take a look at the markdown source for DIP69. It's horrific. Do you mean on the wiki? The wiki doesn't use Markdown. At least not anyone I've seen. It uses something pretty similar. They all kinda mush together in my mind :-( It's NOT SIMILAR at all. It's a completely different language. Also as mentioned above, DDoc macros are extremely ugly and hard to read (and to make sense of, with their lisp-ness). Not to mention, *almost everyone* coding today knows Markdown and can immediately begin contributing to the docs, without looking up DDoc documentation or a *freaking macro file in one of D's repositories*. Only a subset of D devs know DDoc macros, and a very small minority of those know DDoc macros used by Phobos. This is ugly, it is the *very definition* of ugly. (how the heck am I even supposed to read that?): DDoc: $(OL $(LI If $(D line) has type $(D string), $(D wstring), or $(D dstring), a new string of the respective type is allocated every read.) $(LI If $(D line) has type $(D char[]), $(D wchar[]), $(D dchar[]), the line's content will be reused (overwritten) across reads.) $(LI If $(D line) has type $(D immutable(ubyte)[]), the behavior is similar to case (1), except that no UTF checking is attempted upon input.) $(LI If $(D line) has type $(D ubyte[]), the behavior is similar to case (2), except that no UTF checking is attempted upon input.)) This is *much less ugly*: Markdown: 1. If `line` has type `string`, `wstring`, or `dstring`, a new string of the respective type is allocated every read. 2. If `line` has type `char[]`, `wchar[]`, `dchar[]`, the line's content will be reused (overwritten) across reads. 3. If `line` has type `immutable(ubyte)[]`, the behavior is similar to case (1), except that no UTF checking is attempted upon input. 4. If `line` has type `ubyte[]`, the behavior is similar to case (2), except that no UTF checking is attempted upon input. And my favorite, tables in DDoc. First 3 lines for brevity: DDoc: $(BOOKTABLE Cheat Sheet, $(TR $(TH Function Name) $(TH Description) ) $(LEADINGROW Searching ) $(TR $(TDNW $(LREF all)) $(TD $(D all!a 0([1, 2, 3, 4])) returns $(D true) because all elements are positive) ) $(TR $(TDNW $(LREF any)) $(TD $(D any!a 0([1, 2, -3, -4])) returns $(D true) because at least one element is positive) ) ... Markdown (assuming some kind of automatic crossreferencing, which *needs* to be in any decent documentation generator, and DDox, which renders your preview new documentation, already does it) | Function Name | Description | | - |- | | #all | `all!a 0([1, 2, 3, 4])` returns `true` ... | | #any | `any!a 0([1, 2, -3, -4])` returns `true` ... | (shortened to fit mail, but you should be able to get the point) If you don't want so many pipes / aligning work, this works too: Function Name | Description - | - #all | `all!a 0([1, 2, 3, 4])` returns `true` ... #any | `any!a 0([1, 2, -3, -4])` returns `true` ... And yes, the above is limited, it can't do everything DDoc can do. Macros are useful when you need something way out of the ordinary. But using them for things like tables or lists or 5 different macros for links because you don't think cross-referencing is important is insane. I'd be happy if I could use *something that's not DDoc macros* 99% of the time. But if I want my docs to be anything better than bare text with Params:, Returns: and Examples:, I have to write that kind of gibberish (actually, not anymore, as I said I'm working on DDoc + markdown).
Re: Worst Phobos documentation evar!
Great, width limit messed up the (first version of) the table. | Function Name | Description | | - |- | | #all | `all!a 0([1, 2, 3, 4])` returns `true` | | #any | `any!a 0([1, 2, -3, -4])` returns `true` |
Re: Worst Phobos documentation evar!
Yeah, now have a large table and have one line that's longer. *Read* my post. The rows don' have to be aligned. And as I mentioned, IF you have a special case, THEN it's time for macros. But it shouln't happen for basic things like bold, code, links, references, 90% of tables or lists. I spend about half of my coding time writing documentation. DDoc is like I'm writing my documentation with LISP, or rather, Scheme. If I wanted to do that I wouldn't mind writing my code in Scheme either. BTW, you can line table entries up in Ddoc, too: $(TABLE $(THDR Function Name, Description ) $(TROW all , `all!a 0([1, 2, 3, 4])` returns `true` ) $(TROW any , `any!a 0([1, 2, -3, -4])` returns `true`) ) No, it has to be at least: $(TABLE $(THDR Function Name, Description ) $(TROW all , $(D all!a 0([1, 2, 3, 4])) returns $(D true) ) $(TROW any , $(D any!a 0([1, 2, -3, -4])) returns $(D true)) ) because I need macros even for something as common as an inline code fragment. Not to mention, if I include the full table lines, not just ~70 chars this newsgroup will take, the difference in readability is much more massive.
Re: Worst Phobos documentation evar!
On Monday, 29 December 2014 at 23:56:47 UTC, Walter Bright wrote: On 12/29/2014 3:31 PM, Kiith-Sa wrote: because I need macros even for something as common as an inline code fragment. Markup, macro, same thing. Not to mention, if I include the full table lines, not just ~70 chars this newsgroup will take, the difference in readability is much more massive. Not really, because you can create your own custom macros to shorten things up. I use Ddoc all the time, and I create custom macros ALL THE TIME for semantic shortcuts, prettying things up, saving typing, etc. Any repetitive tasks are candidates for a custom macro. If you're not using custom macros, and you find Ddoc tedious and repetitive, you're using it wrong. I cannot use a custom macro to shorten $(D a == b). A well-written paragraph will have 20 such $(D XXX), $(B XXX), $(I XXX), not to mention $(SOMELINK xxx.com XXX). And there's no way to make lists or tables readable: *unless* their contents is homogenous, at best I will have rows full of $(XXX ). etc. is completely unreadable for anyone but people who have spent at least a year looking at the mess that is Phobos documentation comments. Javadoc is more readable in sources, as is Doxygen. Python's Sphinx is more readable in their sources. [Rust](http://doc.rust-lang.org/rustdoc.html) is using markdown for their documentation and they don't have any issues either. Yes, *you* use DDoc all the time. But *you* are also forcing it on everyone using the language, and on any average programmer who may potentially use D, most of whom don't share your love for macros and MANY of whom know much more common formats like Markdown. Most people don't write their docs in LaTeX either. Besides, no-one is proposing to *remove* the macros, the proposal it to add syntax for basic cases which frankly can *not* be made any less ugly with macros. And yeah, so you will need to escape I'm writing my *thesis* in ReStructuredText, which is basically Markdown on steroids with *way* more special characters than Markdown, and I almost never need to escape anything. Either way, I'm done with this argument, I expect it will take many more pissed-off users for this to change. As for the CSS thing, yes, you need that built in. It doesn't have to be amazing but it *has to be usable*. to be usable, documentation must be as simple to generate as: doxygen Doxyfile That's what a user coming from most different languages expects, if they don't get it, it seems *broken* and is extremely off-putting. When I was starting with D this almost made me give up. Bare HTML files, no cross-referencing, unreadable, no menu. No information on the site on how to get a usable documentation (not sure how it's now, it's been a few years), and coming from Doxygen, writing a bunch of .ddoc files I wasn't even told about wasn't what would come to my mind. The default does not need to look amazing, but there must be something usable to start with, without *any* work other than having documentation comments in your code. Any other common documentation generator will produce something that can at least be browsed.
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 01:35:57 UTC, Andrei Alexandrescu wrote: On 12/29/14 12:04 PM, Jacob Carlborg wrote: On 2014-12-29 20:48, Walter Bright wrote: I don't care much for hybrids, they are confusing and ugly. Markdown already support raw HTML. We could use Markdown but with Ddoc macros instead of raw HTML. BTW, Ddoc macros are really ugly. Ideas for a better syntax? I like the idea of a uniform syntax for all macros instead of learning one syntax for each artfact. -- Andrei Current syntax: $(B bolded) OO O O * 4 characters of overhead * The characters are 'big' and seem like text (especially $), taking attention away from the actual content. Different from e.g. **bold** or `italic` * To type, needs 6 keypresses - 2 shifts + 4 keys (shift held for one key) - as a person with RSI, this is relevant to me * Need parens even for 1-argument version, increasing lisp-ness with nested macros - Idea: short 1-argument syntax - I think one way to improve this would be to add an equivalent of the short template instantiation syntax: someFunction(to!(ReturnType!T)) is less lispy and more readable than someFunction(to!(ReturnType!(T))) (especially with longer lines, more args, deeper nestings) similarly e.g. (not proposing this exact syntax - just an example) $(LI B$bold D$true) is more readable than $(LI $(B bold) $(D true)) And requires only 2 keypresses (including shift) for the 1-parameter macros. Of course, this only helps with 1-parameter macros, but that's very often the worst source of visual noise in DDoc, especially with things like list items and tables (nesting), especially if the lines are long. -- Idea: 2(3 with space) character syntax -- I'm not sure if this is viable without causing more damage than benefit (too much escaping). Idea: use 2 delimiting characters, preferably 'small' characters that don't distract. E.g (again, these are not actual proposals, just to illustrate the point): `B bold` (very little visual noise but perhaps a bit too little/easy to miss, 3 keypresses including space) ;B bold; (slightly more visual noise but not too distracting, but ';' is probably too common character so there could be too much escaping, 3 keypresses) .. etc.
Re: Worst Phobos documentation evar!
As opposed to some other markup language. You're always going to have 20 such markup instances, one way or another. There's a big difference between the amount of visual noise between different instances. I'm using D for 5 years and when I still find DDoc laced with $(LI $(B bold) $(D code)) hard to read. And there's no way to make lists or tables readable: Yes, there is. I just showed you. I don't consider that to be readable, especially, as I mentioned, if the items are long lines of non-plain text. No matter what form Ddoc takes, it will force some method upon users. However, you can use Doxygen on .d sources if you prefer. I don't use it because it doesn't *really* understand D. I'm not arguing for Doxygen's syntax / D support or lack thereof. I'm arguing for its user experience. The D language has a use for most every character, so escapes will be needed a lot. D blocks in DDoc are usually in: --- code here --- With a Markdown-like syntax, inline code could be in `inline code here` . I admit you would need to escape the backticks, which are very rare, especially in inline code fragments. I also admit *that* would force you to not reliably use *some* D code fragments *outside* backticks. And I find it unlikely that there are more than 3 fragments in entire Phobos doc this would break. to be usable, documentation must be as simple to generate as: doxygen Doxyfile dmd -D source.d The result takes a shitload of work to make it useful, especially if your project has more than 1 module (and no, passing more files won't help with that). THIS is useful (it's very close to what Doxygen spits out by default): http://irrlicht.sourceforge.net/docu/index.html D claims to have a builtin documentation generator, but you can either spend a week searching for nonexistent documentation about how to make decent documentation *or* you can get a third-party documentation generator, which is the same experience you get with C++ and Doxygen. The only place anyone has to use Ddoc is in the Phobos documentation. If Doxygen is better, more convenient, etc., why aren't you using it? Ddoc must be doing something right :-) I'm modifying a third-party documentation generator to support Markdown and to get decent Doxygen doxyfile user experience right now.
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 01:57:20 UTC, Andrei Alexandrescu wrote: On 12/29/14 4:37 PM, Kiith-Sa wrote: Either way, I'm done with this argument, I expect it will take many more pissed-off users for this to change. I've seen little else than emotion and appeal to such in making your argument. -- Andrei I admit that. DDoc has been making me angry for years. And I do find the lack of readability of DDoc to be so much of an obvious issue, and I do thing it will hurt D (not so much as GC/noGC fanatcs, but it will, especially people who like writing documentation (yeah, such people exist, I'm one of them)). And now I have my monhly 'procastinate by actively posting on a forum' day.
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 04:33:10 UTC, Andrei Alexandrescu wrote: On 12/29/14 6:50 PM, Kiith-Sa wrote: .. etc. You seem to not like your own proposals! -- Andrei I like them less than a markdown-DDoc combo. They (at least the first one) are still a way to make DDoc more readable even without markdown. As escaping seems to be considered to be the major issue here the second proposal may result in a lot of extra escaping depending on character/s used (and I personally would hate $MACRO arg1 arg2$ which would reuse $ to minimize escaping). The first idea I don't find anything to dislike about, but it will only help for 1-param macros. That's not a 'bad', just 'good to a lesser degree'.
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 04:34:30 UTC, Andrei Alexandrescu wrote: On 12/29/14 7:20 PM, Kiith-Sa wrote: On Tuesday, 30 December 2014 at 01:57:20 UTC, Andrei Alexandrescu wrote: On 12/29/14 4:37 PM, Kiith-Sa wrote: Either way, I'm done with this argument, I expect it will take many more pissed-off users for this to change. I've seen little else than emotion and appeal to such in making your argument. -- Andrei I admit that. DDoc has been making me angry for years. And I do find the lack of readability of DDoc to be so much of an obvious issue, and I do thing it will hurt D (not so much as GC/noGC fanatcs, but it will, especially people who like writing documentation (yeah, such people exist, I'm one of them)). And now I have my monhly 'procastinate by actively posting on a forum' day. The one way out is to propose something at least as useful and quite a bit more palatable. -- Andrei See previous post. Useful? not 'at least as' in my mind. Palatable? probably, less escaping/special cases.
Re: Worst Phobos documentation evar!
On Sunday, 28 December 2014 at 15:57:39 UTC, Ary Borenszweig wrote: On 12/27/14 10:00 PM, Walter Bright wrote: This is so bad there isn't even a direct link to it, it hides in shame. Just go here: http://dlang.org/phobos/std_encoding.html#.transcode and scroll up one entry. Here it is: size_t encode(Tgt, Src, R)(in Src[] s, R range); Encodes c in units of type E and writes the result to the output range R. Returns the number of Es written. Let me enumerate the awesomeness of its awfulness: 1. No 'Return:' block, though it obviously returns a value. 2. No 'Params:' block, though it obviously has parameters. 3. No 'Example:' block 4. No comparison with other 'encode' functions in the same module. 5. No description of what 'Tgt' is. 6. No description of what 'Src' is. 7. No clue where the variable 'c' comes from. 8. No clue where the type 'E' comes from. 9. 'R' is a type, not an instance. 10. I suspect it has something to do with UTF encodings, but there is no clue. After programming in Ruby for a long time (and I think in Python it's the same) I came to the conclusion that all the sections (Return, Params, Example) just make writing the documentation a harder task. For example: ~~~ /* * Returns a lowered-case version of a string. * * Params: * - x: the string to be lowered case * Return: the string in lower cases */ string lowercase(string x) ~~~ It's kind of redundant. True, there might be something more to say about the parameters or the return value, but if you are reading the documentation then you might as well read a whole paragraph explaining everything about it. For example, this is the documentation for the String#downcase method in Ruby: ~~~ def downcase(str) Returns a copy of `str` with all uppercase letters replaced with their lowercase counterparts. The operation is locale insensitive—only characters “A” to “Z” are affected. Note: case replacement is effective only in ASCII region. hEllO.downcase #= hello ~~~ Note how the documentation directly mentions the parameters. There's also an example snippet there, that is denoted by indenting code (similar to Markdown). I think it would be much better to use Markdown for the documentation, as it is so popular and easy to read (although not that easy to parse). Then it would be awesome if the documentation could be smarter, providing semi-automatic links. For example writing #string.join would create a link to that function in that module (the $(XREF ...) is very noisy and verbose). It depends on the function being documented. For 'downcase', such blocks are overkill; for more complex functions (and templates!) they're very helpful Params: is an excellent place to explain the *requirements* for the parameters. Even the current doc, which seems to be rewritten since Walter's post, does not make use of this: there's a paragraph The input to this function MUST be validly encoded... - this should not be a separate paragraph; it should be mentioned right in Params: for that parameter. Consistently documenting requirements/contract for each parameter in the Params: entry for that parameter makes it easy to find the requirement at glance. DDoc is powerful, but it is a very nasty case of hard things are possible, easy things are hard (e.g. tables, and very unreadable in source $(B bold) instead of **bold**, $(D code) instead of `code`, $(LINK2 ...), etc. . I'm working on generating documentation with both DDoc and Markdown in the same source, BTW, but not with the builtin DMD generator. Most of markdown can be used without conflicts, with notable exceptions of: --- // horizontal line (but - - - works) heading2 // (but ## heading2 works, and '-' can be replaced by something els) I think it'd be a good idea to add at least a subset of markdown to DMD DDoc, which could generate DDoc macros (e.g. **bold**, *italic*, `inline code` (DDoc already has nice syntax for code *blocks*), [link](www.link.com), and some table syntax (not in vanilla markdown, but e.g. GitHub markdown/PanDoc markdown have a common syntax) - I may be able to find some time to work on this for DMD DDoc in summer (not sooner unfortunately, I'd need some time to look around the code as I never touched it), but would it have a chance of being merged? (Walter?)
Re: Worst Phobos documentation evar!
On Sunday, 28 December 2014 at 16:44:05 UTC, Kiith-Sa wrote: On Sunday, 28 December 2014 at 15:57:39 UTC, Ary Borenszweig wrote: On 12/27/14 10:00 PM, Walter Bright wrote: This is so bad there isn't even a direct link to it, it hides in shame. Just go here: http://dlang.org/phobos/std_encoding.html#.transcode and scroll up one entry. Here it is: size_t encode(Tgt, Src, R)(in Src[] s, R range); Encodes c in units of type E and writes the result to the output range R. Returns the number of Es written. Let me enumerate the awesomeness of its awfulness: 1. No 'Return:' block, though it obviously returns a value. 2. No 'Params:' block, though it obviously has parameters. 3. No 'Example:' block 4. No comparison with other 'encode' functions in the same module. 5. No description of what 'Tgt' is. 6. No description of what 'Src' is. 7. No clue where the variable 'c' comes from. 8. No clue where the type 'E' comes from. 9. 'R' is a type, not an instance. 10. I suspect it has something to do with UTF encodings, but there is no clue. After programming in Ruby for a long time (and I think in Python it's the same) I came to the conclusion that all the sections (Return, Params, Example) just make writing the documentation a harder task. For example: ~~~ /* * Returns a lowered-case version of a string. * * Params: * - x: the string to be lowered case * Return: the string in lower cases */ string lowercase(string x) ~~~ It's kind of redundant. True, there might be something more to say about the parameters or the return value, but if you are reading the documentation then you might as well read a whole paragraph explaining everything about it. For example, this is the documentation for the String#downcase method in Ruby: ~~~ def downcase(str) Returns a copy of `str` with all uppercase letters replaced with their lowercase counterparts. The operation is locale insensitive—only characters “A” to “Z” are affected. Note: case replacement is effective only in ASCII region. hEllO.downcase #= hello ~~~ Note how the documentation directly mentions the parameters. There's also an example snippet there, that is denoted by indenting code (similar to Markdown). I think it would be much better to use Markdown for the documentation, as it is so popular and easy to read (although not that easy to parse). Then it would be awesome if the documentation could be smarter, providing semi-automatic links. For example writing #string.join would create a link to that function in that module (the $(XREF ...) is very noisy and verbose). It depends on the function being documented. For 'downcase', such blocks are overkill; for more complex functions (and templates!) they're very helpful Params: is an excellent place to explain the *requirements* for the parameters. Even the current doc, which seems to be rewritten since Walter's post, does not make use of this: there's a paragraph The input to this function MUST be validly encoded... - this should not be a separate paragraph; it should be mentioned right in Params: for that parameter. Consistently documenting requirements/contract for each parameter in the Params: entry for that parameter makes it easy to find the requirement at glance. DDoc is powerful, but it is a very nasty case of hard things are possible, easy things are hard (e.g. tables, and very unreadable in source $(B bold) instead of **bold**, $(D code) instead of `code`, $(LINK2 ...), etc. . I'm working on generating documentation with both DDoc and Markdown in the same source, BTW, but not with the builtin DMD generator. Most of markdown can be used without conflicts, with notable exceptions of: --- // horizontal line (but - - - works) heading2 // (but ## heading2 works, and '-' can be replaced by something els) I think it'd be a good idea to add at least a subset of markdown to DMD DDoc, which could generate DDoc macros (e.g. **bold**, *italic*, `inline code` (DDoc already has nice syntax for code *blocks*), [link](www.link.com), and some table syntax (not in vanilla markdown, but e.g. GitHub markdown/PanDoc markdown have a common syntax) - I may be able to find some time to work on this for DMD DDoc in summer (not sooner unfortunately, I'd need some time to look around the code as I never touched it), but would it have a chance of being merged? (Walter?) argh, formatting, the heading2 thing should be: heading2
Re: Worst Phobos documentation evar!
That's a good idea. I propose rule #1: Under no circumstances will auto be allowed in any examples. The compiler should even reject files in which they appear. One of the most frustrating things is to read documentation with type T (completely uninformative) followed by an example with auto. Doesn't work with Voldemort types, stupid with LongClassName a = new LongClassName(long, parameter, list). Use your brain, not under no circumstances rules, when writing documentation. Same as Params:/Returns: - they may not be useful for trivial functions but are very useful with more complex ones. Again, use your brain - Will someone reading this thing I'm writing here have any actual idea about how to use this function?
Re: Lost a new commercial user this week :(
Finally, contracts are overwhelming, and it's also a feature of D that nobody has seen before. When someone new to D encounters a contract in the docs, they no longer trust their ability to usefully interpret the documentation, and almost certainly become confused; nobody expects to see an 'if' statement in a function declaration. I think that's a shame. The contract usually has no impact on using the function, or how it should be understood, is just applies some limitations to it's genericity. I think contracts should be disconnected and listed separately, as additional information, or with some subtext that makes it obvious what that often confusing bit of text actually means. Ironically, the string and algorithm functions are probably the worst offenders, but coincidentally, there is a high chance that these are the first functions anyone will ever reach for, so they present a terrible first impression. I think you mean constraints, not contracts.
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: What's missing to make D2 feature complete?
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. For me it's these 3 points. - tuple support (DIP32, maybe without pattern matching) - working import, protection and visibility rules (DIP22, 313, 314) - finishing non-GC memory management D as a language is feature complete enough for me as is; improving the compiler, fixing remaining major compiler bugs/inconsistencies between spec and compiler is more important for me. Maybe the ability to force-inline if nothing else. Outside the language itself: - Phobos could obviously use some fixing (especially obsolete stuff without a real replacement like std.stream) - a GC that doesn't suck would help (I see people working on that from time to time, never gets finished/integrated) - A finished std.allocator would help, whether or not Phobos uses it internally - std.simd - Proposed changes with GC/RC/manual allocation in would be very useful, but I expect that to take a shitload of time, assuming it doesn't get derailed and replaced by a yet more grandiose idea (remember TempAlloc - std.allocator - now this - nothing of that got finished) Also, this pisses me off way too often: a way to build documentation as easily as doxygen Doxyfile (no need to write own CSS to get a non-atrocious result, no messing with dependencies because DMD needs to import files I'm not building documentation with, no assuming I have a server by default, no generating files to feed to another program) and get a ready-for-use, readable, static HTML-CSS result. All of DMD/DDoc, ddox and harbored are too involved. (I would also prefer to have Markdown or ReST within DDoc, e.g. I don't find $(B bold) to be readable, I'll probably eventually try to eventually implement that myself). .. that ended up surprisingly long. TLDR: language is good, Phobos needs work, doc generation sucks
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote: On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote: Docs need to have examples which are plain and obvious, and the language will be absorbed by osmosis. I agree. Can you point to specific cases that need an example? If it doesn't have an example, it needs an example, no matter how trivial it is. That's a good place to start. Of course, then there are lazy examples that don't really help in real use. These need to be identified and rewritten.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath wrote: On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote: On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote: On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote: Docs need to have examples which are plain and obvious, and the language will be absorbed by osmosis. I agree. Can you point to specific cases that need an example? If it doesn't have an example, it needs an example, no matter how trivial it is. That's a good place to start. Of course, then there are lazy examples that don't really help in real use. These need to be identified and rewritten. • If you look up how to do $x in the documentation and it is takes you time to figure that out, consider to add an example for $x to the documentation. • If you answer/ask a question in D.learn on how to do $x, consider to add an example for $x to the documentation. This way we should build up exactly those examples that are useful. Turned into an issue (not really a traditional issue since it's never solved, but to hopefully remind people). Also mentioned in the wiki(Get involved): https://issues.dlang.org/show_bug.cgi?id=13876 http://wiki.dlang.org/Get_involved
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/
Questions at D reddit (benchmarks game, D worms)
Noticed 2 non-bot threads at Reddit (sorry for spam, but due to all D talk being here newcomers may get the impression of a dead community), maybe someone here is able to answer them? https://www.reddit.com/r/d_language/comments/2ppxya/is_there_any_interest_in_writing_algorithms_in_d/ https://www.reddit.com/r/d_language/comments/2pov92/worms_in_d/
Re: What is the D plan's to become a used language?
On Friday, 19 December 2014 at 00:21:06 UTC, H. S. Teoh via Digitalmars-d wrote: On Thu, Dec 18, 2014 at 08:12:07PM +, Laeeth Isharc via Digitalmars-d wrote: [...] - better reference documentation. I don't believe I lack the ability generally to figure things out, but the dlang.org library reference is far from being utterly clear if you don't start from a place of understanding the language and its concepts. once you get the spirit of it, it all makes sense, but modern people don't tend to be distinguished by their grit and many will give up first. Please file documentation enhancement bugs in bugzilla. I do try to work on improving documentation when I have the time, but if nobody points out a possible improvement, I might never think of it (or it might take a long time before I notice it, esp. if I rarely use that module!). I'm sure others who browse bugzilla from time to time will also appreciate having documentation bugs to work on -- since they're generally the lowest-hanging fruit that even most newbies should be able to contribute to. - better worked examples. python is outstanding for this. you can figure out how to do anything by looking at someone else's example. of course there isn't presently the support for this, and I recognize that one attracts a different kind of person when it becomes easy to learn a language. but such is the price of maturity. Please file doc enhancement requests for these too. :-) A lot of Phobos documentation is unfortunately quite lacking in good examples. I've done a few of them, but generally, having a bugzilla issue for it is much better, because I may already know function X like the back of my hand and so never notice that the examples aren't that good, whereas if a newbie pointed out that the examples for X are unclear, then I'd know there's an issue and look into how to explain X better. [...] - finally, a bit better organisation. Andrei spoke about needing more lieutenants. Of course it's a no-brainer that he shouldn't be spending his time designing a conference web site. But perhaps you could make it clearer by adding a section on the D wiki front page: Interested in supporting D? Here's how you can help. It could then take you to a page that breaks down different areas to work on and tasks to be accomplished on each of them. Then someone with time and inclination can see oh - it would be great to have someone promote this event on Reddit. But as things stand, I imagine to a certain extent nobody knows what specifically they can do. [...] There's some preliminary info at: http://wiki.dlang.org/Get_involved But it would be greatly appreciated if you could help improve it by adding more material. ;-) T In case you'll have time/will to work on this in near future - resulted from previous D docs suck discussion (I'll probably do some of it eventually, but I'm unlikely to be free till summer): https://issues.dlang.org/show_bug.cgi?id=13863
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote: On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote: There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience. This is valuable information, while it's fresh in your mind can you please submit a bugzilla issue for each point? They then made HUGE noises about the quality of documentation. The prevailing opinion was that the D docs, in the eyes of a not-a-D-expert, are basically unreadable to them. The formatting didn't help, there's a lot of noise and a lack of structure in the documentation's presentation that makes it hard to see the information through the layout and noise. As senior software engineers, they basically expected that they should be able to read and understand the docs, even if they don't really know the language, after all, what is the point of documentation if not to teach the language... I tend to agree, I find that I can learn most languages to a basic level by skimming the docs, but the D docs are an anomaly in this way; it seems you have to already know D to be able to understand it effectively. They didn't know javascript either, but skimming the node.js docs they got the job done in an hour or so, after having wasted *2 days* trying to force their way through the various frictions presented but their initial experience with D. I understand what you're saying, but I find it hard to figure out just what to do to change it. Any specific suggestions? One thing I ran into often when I was inexperienced with D: the template constraints make some signatures extremely messy, and it takes a while to figure out when you have e.g. 3 template functions of the same name in std.algorithm, all with crypric signatures. Example: ptrdiff_t countUntil(alias pred = a == b, R, Rs...)(R haystack, Rs needles) if (isForwardRange!R Rs.length 0 isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) is(typeof(startsWith!pred(haystack, needles[0]))) (Rs.length == 1 || is(typeof(countUntil!pred(haystack, needles[1..$]); ptrdiff_t countUntil(alias pred = a == b, R, N)(R haystack, N needle) if (isInputRange!R is(typeof(binaryFun!pred(haystack.front, needle)) : bool)); countUntil is trivial to use, but the docs make it seem complicated and it takes a while to read them. (This is not really a good example as with countUntil it's not *that* bad, but I think it should be enough to show the problem) In this specific case, it would be useful if the constraint was somehow separated from the rest of the signature and less emphasized (CSS). Also, in this example, the documentation text itself immediately goes into detail (e.g. mentioning startsWith!) instead of starting with a simple explanation of the concept. I think this could be helped somewhat if the example This is one example of too much noise. Example of 'not teaching the language': For the first few months using D, I had no idea what D 'range' (I knew Python) is and it made the docs harder to understand. I think most or all mentions of terms important in D such as 'range' should link to a *simple* explanation of what a range/whatever is (maybe in Ali Cehreli's book?). Also... some docs are just plain lazy (does something similar but not the same as this C function we couldn't even be arsed to link to), missing examples (or missing *useful* examples, etc.) - A lot of docs assume the reader knows some specific other language, not only C I occasionally try to push minor doc fixes but currently I'm rather swamped, may do some work on that next summer.
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: Optimization fun
On Saturday, 8 November 2014 at 01:53:33 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Nov 07, 2014 at 05:31:44PM -0800, Walter Bright via Digitalmars-d wrote: On 11/7/2014 4:41 PM, H. S. Teoh via Digitalmars-d wrote: [...] But speaking of which, I found dmd -profile's output in trace.log a little difficult to understand because of the lack of self-documenting headers in the first section. gprof, for example, produces nicely-labelled output that describes what the data means. Would you accept a PR along these lines? I don't really know what you have in mind, so I'll have to say it depends. Keep in mind that subsequent runs of the profiler parse the previous output file and add it to the results. Just add a simple header that describes what each column means. Also, in the second section, I'm getting some negative numbers for the call times, which seem to indicate integer overflow? This basically destroys the usefulness of dmd -profile for my test cases, since most of the interesting cases for me are those with long running times, which for sure will run into integer overflow at the sample rate that dmd -profile is using, causing the second section to be essentially randomly sorted. Yeah, a negative number is likely an overflow. Reduce the test case! Unfortunately, I can't. The behaviour I'm trying to profile is the long-term running case, because there's a whole bunch of setup at the beginning that initially takes a while, but eventually it's the long-running part that dominates the runtime behaviour. Reducing the test case will only increase the initial noise, which I'm not interested in, and reduce the running time of the main loop of interest. Besides, what I'm trying to optimize for is the large, complex case; the simple cases already run fast enough that the performance characteristics are not that interesting to me. It's the long-term part that's interesting because that's when the GC starts kicking in and pressure on system RAM starts to increase. I'm surprised that dmd's profiler can't even handle something that only runs for 7-8 seconds or so! gprof certainly has no such limitation. Is it relatively simple to make dmd -profile use larger integer widths for profiling? If not, I'm afraid I'm just gonna have to stick with gdc/gprof instead. T Except for very specific cases, neither gprof or DMD's profiler are good for profiling. If you're on Linux, you have perf, which works well with D and is way ahead of anything the DMD profiler will be able to do *after* man-years of further development. See (shameless advertisement): http://defenestrate.eu/_static/profiling-slides/index.html#22 (especially perf record/perf report)
Slides about profiling (on Linux)
I've been planning to write a blog post about profiling D on Linux for a while, and... while I still didn't get around to writing an actual post, I recently gave a talk/workshop about profiling/optimizing on Linux at local hackerspace. While it's aimed at the local C/C++ audience, a lot of it is relevant to D (especially perf, which works well with D - except for name mangling - I keep hearing about people using valgrind/callgrind with D but never got it to work myself). Slides and sample code: http://defenestrate.eu/2014/10/31/profiling_on_linux.html
Re: std.json sucessor
On Monday, 13 October 2014 at 17:21:44 UTC, Sönke Ludwig wrote: Am 13.10.2014 16:36, schrieb Daniel Murphy: Sönke Ludwig wrote in message news:m1ge08$10ub$1...@digitalmars.com... Oh, I've read both line and column into a single uint, because of four words per token - considering that word == 16bit, but Andrei obviously meant word == (void*).sizeof. If simply using uint instead of size_t is meant, then that's of course a different thing. I suppose a 4GB single-line json file is still possible. If we make that assumption, we'd have to change it from size_t to ulong, but my feeling is that this case (format error at 4GB human tries to look at that place using an editor) should be rare enough that we can make the compromise in favor of a smaller struct size. What are you using the location structs for? In D:YAML they're only used for info about errors, so I use ushorts and ushort.max means 65535 or more.
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: [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: 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: GC behavior
On Monday, 6 October 2014 at 16:23:41 UTC, Jonathan wrote: If I pool all unused objects such that no object needs to be GC'ed, does it still perform scanning? What are other good ways to avoid its overhead? As you might tell, I know rather little how D's garbage collection works. I'm working on a game engine and trying to be as resource efficient as possible. FYI, I've been using Rust for the last three months and decided to take a break from it. The documentation is far from the quality that D has and managing explicit lifetimes becomes a serious pain during mid project, especially in cases that you know are already safe. Suggestion (may or may not be useful depending on your game): use an ECS (http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/) approach with big, manually allocated arrays of structs in the implementation. I'm working on something but it's not documented enough/API is butt-ugly/not nearly stable-enough yet: https://github.com/kiith-sa/tharsis-core Some people are working on other ECS's too, see code.dlang.org (some are very efficient, some are not... don't remember which). And (very simplistic advice, but...) if ECS doesn't fit your needs or you do use GC to allocate a lot of stuff anyway, reuse dead objects and control the GC by disable()ing/reenabling and explicitly fullCollect()ing.
Re: GC behavior
On Monday, 6 October 2014 at 17:46:34 UTC, Jonathan wrote: Kiith-Sa, thanks for the info! I started to check out your entity project and love how your incorporating threads and syncing new/old state. You did state that your cleaning up things, but my initial reaction is that entitymanager is performing too many roles. I'd remove the heavy game state and threading into another class to make it cleaner, imho. https://github.com/kiith-sa/tharsis-core/blob/master/source/tharsis/entity/entitymanager.d Yeah, the threading is currently the most work-in-progress thing (basically, I'm dealing with tradeoffs between trying to get the best average performance and least latency from non-realtime OS scheduling). EntityManager is pretty much the kitchen-sink class where things exist until they are refactored away (most of Tharsis code used to be there at some point in the past). It will probably end up just as a shell delegating to all internals regarding entit/component management and process execution. However, EntityManager API itself is more complicated than needed for most users (and needs to be used together with other classes which add to the complexity) - it, together with other 'low-level' API classes will probably eventually be hidden behind a more user-friendly facade (yeah, I hate design patterns, but that's pretty much what it will be), with the ability to access EntityManager/others for more advanced users.
Re: Hunting down rogue memory allocations?
On Friday, 3 October 2014 at 08:18:45 UTC, thedeemon wrote: On Thursday, 2 October 2014 at 20:16:56 UTC, Gary Willoughby wrote: Say i have created a program written in D, what tools are available for me to track memory allocations? I wrote a tiny module trackallocs.d that inserts a GC proxy and outputs to log file (or stdout) all the allocations, gathering some stats. You can turn tracking on and off in any place of your code. Used it before 2.066 where @nogc appeared to check whether my code was allocation-free. Current version works in both 2.066 and earlier versions. Find it here: https://bitbucket.org/infognition/dstuff/src/ Inside it uses one hack based on knowledge of D runtime internals, so in future versions of D runtime, if Proxy struct changes again, it may need to be changed as well. This is really cool stuff, I needed something like this but didn't know it was possible. Mind if I use some parts of it in my profiler? (there's no license)
Re: Hunting down rogue memory allocations?
On Thursday, 2 October 2014 at 20:16:56 UTC, Gary Willoughby wrote: Say i have created a program written in D, what tools are available for me to track memory allocations? If you write a program and its performance is slow because you suspect too many allocations are taking place in unrecognised areas, what tools or techniques do you use to find where they are and eliminate them? If *time* spent by allocations is a problem, profile with `perf top` (assuming you have Linux): Look for 'gc', 'malloc', 'calloc', etc. (Plain perf record will also work, but not be as quick/interactive. CodeXL works too.) See https://perf.wiki.kernel.org/index.php/Tutorial - you probably need some specific arguments to get caller info, didn't use it for a while so I don't remember. If e.g. the GC is an issue, it should be immediately evident with some GC function taking e.g. over 5% of time. Usually the actual overhead will be much higher but divided into multiple smaller functions that will take little time individually. Drill down into one of these and look at its callers. Eliminate the most common source of calls, look again, repeat. Usually removing a source of alloc calls will result in better speedup than the profiler suggests. If *space* is a problem, Valgrind doesn't work with most D programs for some reason (probably D's fault), so, good luck with that. But eliminating the biggest time wasters usually helps space as well (or rather, it makes it more controllable as you know better where you allocate memory).
Re: So what exactly is coming with extended C++ support?
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote: On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote: Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D. I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway. Hello. AAA developer (Remedy) here using D. Custom tech, with a custom binding solution written originally by Manu and continued by myself. A GC itself is not a bad thing. The implementation, however, is. With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it. ARC garbage collection would certainly be beneficial there. I looked in to adding support at a language level and at a library level for it, but the time it would have taken for me to learn both of those well enough to not muck it up is not feasible. Writing a garbage collector that we have greater control over will also take up too much time. The simpler solution is to enforce coding standards that avoid triggering the GC. It's something I will look at again in the future, to be sure. And also to be sure, nothing is being done in Unity to the scale we do stuff in our engine (at least, nothing in Unity that also doesn't use a ton of native code to bypass Unity's limitations). GC.free() can be used to manually delete GC-allocated data. (destroy() must be called first to call te destructor, though) - delete does both but is deprecated. You could write a simple RAII pointer wrapper if you don't want to always call destroy()+GC.free() manually. Or do you need something else?
Re: RFC: moving forward with @nogc Phobos
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
auto setExtension(MemoryManagementPolicy mmp = gc, R1,
R2)(R1 path, R2
ext)
if (...)
{
static if (mmp == gc) alias S = string;
else alias S = RCString;
S result;
...
return result;
}
Incredible code bloat? Boilerplate in each function for the
win?
I'm at loss as to how it would make things better.
Sean's idea to make string an alias of the policy takes care
of this
concern. -- Andrei
But Sean's idea only takes strings into account. Strings aren't
the only
allocated resource Phobos needs to deal with. So extrapolating
from that
idea, each memory management struct (or whatever other
aggregate we end
up using), say call it MMP, will have to define MMP.string,
MMP.jsonNode
(since parseJSON() need to allocate not only strings but JSON
nodes),
MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
Nope, still don't see how this could work. Please clarify, kthx.
T
MMP.Ref!redBlackTreeNode ?
(where Ref is e.g. a ref-counted pointer type (like RefCounted
but with class support) for RC MMP but plain GC reference for GC
MMP, etc.)
I kinda like this idea, since it might possibly allow
user-defined memory management policies (which wouldn't get
special compiler treatment that e.g. RC may need, though).
Re: How to get nogc to work with manual memory allocation
On Sunday, 24 August 2014 at 08:03:11 UTC, Bienlein wrote:
Hello,
I was having a look at the new nogc annotation and therefore
wrote some code that creates an instance on the heap bypassing
the GC (code adapted from http://dpaste.dzfl.pl/2377217c7870).
Problem is that calls to call the class' constructor,
destructor and others can't be called anymore once nogc is
used. So the question is how to get manual allocation and
deallocation done with using nogc. Here is the experimental
code:
@nogc
T nogcNew(T, Args...) (Args args)
{
import std.conv : emplace;
import core.stdc.stdlib : malloc;
// get class size of class object in bytes
auto size = __traits(classInstanceSize, T);
// allocate memory for the object
auto memory = malloc(size)[0..size];
if(!memory)
{
import core.exception : onOutOfMemoryError;
onOutOfMemoryError();
}
// call T's constructor and emplace instance on
// newly allocated memory
return emplace!(T, Args)(memory, args);
}
@nogc
void nogcDel(T)(T obj)
{
import core.stdc.stdlib : free;
// calls obj's destructor
destroy(obj);
// free memory occupied by object
free(cast(void*)obj);
}
@nogc
void main()
{
TestClass test = nogcNew!TestClass();
test.x = 123;
nogcDel(test);
test.x = 456; // no protection violation ?!
// remove @nogc to run this
TestClass t = new TestClass();
t.x = 789;
delete t;
t.x = 678; // protection violation as expected
}
I have omitted the code for the TestClass class to save space.
Problem is that the compiler outputs this:
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew'
cannot call non-@nogc function
'core.exception.onOutOfMemoryError'
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew'
cannot call non-@nogc function 'std.conv.emplace!(TestClass,
).emplace'
Error: @nogc function 'main.nogcDel!(TestClass).nogcDel' cannot
call non-@nogc function 'object.destroy!(TestClass).destroy'
Is there a way to get around this? Then the test.x = 456; did
not cause a protection violation although the instance was
deallocated before calling nogcDel. Something with the
deallocation in nogcDel seems not to work. Some hint
appreciated on this. When calling delete t the protection
violation happens on the next line as expected.
Thanks a lot, Bienlein
@nogc is *no GC*, it has nothing to do with where you allocate
from, no matter how some would choose to interpret it (I use it
to mean 'no heap' pretty often in my own projects, though, can be
useful).
You can mark it @nogc by wrapping the non-@nogc stuff in a
function and casting it, but you *absolutely* must be sure GC is
not used in any called functions.
You could possibly do that by requiring T's constructor to be
@nogc, not sure if the other functions can use GC or not.
Also, your function seems to be written only for classes,
if this is intended, you should have an
if(is(T == class))
template constraint there.
Re: Non-GC based List/Set/Map implementation?
On Tuesday, 26 August 2014 at 10:38:47 UTC, Bienlein wrote: Hello, does anyone know of a List/Set/Map implementation that does not rely on the GC? The would be the last thing I need for D to be really happy with it ;-) Thanks, Bienlein These use the work-in-progress std.allocator and seem to be more maintained, although they don't seem to take advantage of DMD 2.066 (@nogc) yet: https://github.com/economicmodeling/containers
Re: RFC: std.json sucessor
On Monday, 25 August 2014 at 22:40:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 25 August 2014 at 21:53:50 UTC, Ola Fosheim Grøstad
wrote:
I presume you can load 16 bytes and do BITWISE-AND on the MSB,
then match against string-end and carefully use this to boost
performance of simultanous UTF validation, escape-scanning,
and string-end scan. A bit tricky, of course.
I think it is doable and worth it…
https://software.intel.com/sites/landingpage/IntrinsicsGuide/
e.g.:
__mmask16 _mm_cmpeq_epu8_mask (__m128i a, __m128i b)
__mmask32 _mm256_cmpeq_epu8_mask (__m256i a, __m256i b)
__mmask64 _mm512_cmpeq_epu8_mask (__m512i a, __m512i b)
__mmask16 _mm_test_epi8_mask (__m128i a, __m128i b)
etc.
So you can:
1. preload registers with … , \\… and \0\0\0…
2. then compare signed/unsigned/equal whatever.
3. then load 16,32 or 64 bytes of data and stream until the
masks trigger
4. tests masks
5. resolve any potential issues, goto 3
D:YAML uses a similar approach, but with 8 bytes (plain ulong -
portable) to detect how many ASCII chars are there before the
first non-ASCII UTF-8 sequence, and it significantly improves
performance (didn't keep any numbers unfortunately, but it
decreases decoding overhead to a fraction for most inputs (since
YAML (and JSON) files tend to be mostly-ASCII with non-ASCII from
time to time in strings), if we know that we have e.g. 100 chars
incoming that are plain ASCII, we can use a fast path for them
and only consider decoding after that))
See the countASCII() function in
https://github.com/kiith-sa/D-YAML/blob/master/source/dyaml/reader.d
However, this approach is useful only if you decode the whole
buffer at once, not if you do something like foreach(dchar ch;
asdsššdfáľäô) {}, which is the most obvious way to decode in D.
FWIW, decoding _was_ a significant overhead in D:YAML (again,
didn't keep numbers, but at a time it was around 10% in the
profiler), and I didn't like the fact that it prevented making my
code @nogc - I ended up copying chunks of std.utf and making them
@nogc nothrow (D:YAML as a whole is not @nogc but I use @nogc in
some parts basically as @noalloc to ensure I don't allocate
anything)
Re: Learning D
On Monday, 25 August 2014 at 16:46:11 UTC, Ryan wrote: Me: Software developer for 30 years. So perhaps this is old fashion, but I wanted to start using D by whipping together nice little personal utilities. I tried installing MonoDevelop and Mono-D. I can't even figure out the basics, such as adding references to a project. There are no options in the context menus, and although it looks like drag an drop might work (a '+' sign appears by the cursor), dropping a file from the filesystem doesn't work either. Although I dream of someday being able to add a reference to a project, I'm not really sure what I might drag in. I managed to download and compile GtkD, since it seems like a GUI would be a nice place to start (again, old fashion). I got three *.lib files out of it... H... Maybe these are references?? I had installed the Visual Studio plugin, but I don't want to use this since I would like to eventually migrate away from Windows. Let me cut to the chase. I have no friggin' clue how to start, and I can't seem to find a tutorial anywhere... What IDE should I use? I'm not big fan of Eclipse, although if I had to use it this wouldn't be a dealbreaker. Give me something easy and lightweight, unless you've got a GUI builder (this is why I started with MonoDevelop, though this isn't working so well for me). What Widget library should I use? I started with GTKD, but since there are no tutorials does this mean nobody actually does this? Should I use DWT? What about QT? I just want something simple and mainstream to start learning D with. Any thoughts? I don't use an IDE, but MonoD seems to be the most recommended cross-platform option. It has a wiki page here if it helps: http://wiki.dlang.org/Mono-D I recommend only using an IDE that uses DUB (http://code.dlang.org/about), which is becoming the de facto standard for building D projects, and is cross-IDE, allowing you to move between IDEs and to work with developers using other IDEs. MonoD probably uses this, as does DDT(Eclipse). I have no idea what interface MonoD or other IDEs offer for DUB, but DUB uses a 'dub.json' file where you specify libraries you use and their versions. DUB will automatically download the libraries when you compile the project. Available DUB packages (libraries/apps) are listed at http://code.dlang.org . That is probably also the best list of D libs we have at the moment, although many projects are not there yet. Only use DWT if you like Java-style code. QtD is not in usable state yet. GtkD should be good, better for 'big' apps (i.e. more features), TkD for simple ones (simpler to use). To learn about the language itself, this (free) book is really good: http://ddili.org/ders/d.en/index.html
Re: Relaxing the definition of isSomeString and isNarrowString
On Sunday, 24 August 2014 at 12:49:30 UTC, Marc Schütz wrote: On Sunday, 24 August 2014 at 12:24:03 UTC, Andrei Alexandrescu wrote: To that end I'm working on RCString, an industrial-strength string type that's much like string, just reference counted and with configurable allocation. It's safe, too - user code cannot casually extract references to string internals. By default allocation would use GC's primitives; one thing I learned to appreciate about our GC is its ability to free memory explicitly, which means RCString will free memory deterministically most of the time, yet if you leak some (e.g. by having RCString class members) the GC will pick up the litter. I think reference counting backed up by a GC that lifts litter and cycles and is a modern, emergent pattern that D could use to great effect. Any reason why this is restricted to strings? I.e., is there something special about strings (apart from auto-decoding) that doesn't apply to arrays in general? If not, wouldn't an RCArray be a better idea? We already have an 'RCArray' (std.container.Array) although it's not perfect. We don't have a reference counted string type that would work with the string operation functions.
Re: struct or class
On Sunday, 24 August 2014 at 11:56:44 UTC, nikki wrote:
I come from languages that don't offer structs, I have this
json load function that has to keep some data and intuitively
I've written a struct, I've read about the differences, heap vs
stack, value vs reference, but know I think i am overthinking
it.
Is this decent:
bool loadFromFile (string path)
{
auto data = readText(path);
JSONValue parsed = parseJSON(data);
struct AtlasSpriteData
{
SDL_Rect clipRectangle;
int xOffset;
int yOffset;
}
AtlasSpriteData[string] dict;
foreach( string name, value; parsed[frames] ){
SDL_Rect clipRectangle;
auto spriteSourceSize =
value[spriteSourceSize];
clipRectangle.x = to!int(frame[x].toString());
clipRectangle.y = to!int(frame[y].toString());
clipRectangle.w = to!int(frame[w].toString());
clipRectangle.h = to!int(frame[h].toString());
int xOffset = to!int(spriteSourceSize[x].toString());
int yOffset = to!int(spriteSourceSize[y].toString());
auto data = AtlasSpriteData(clipRectangle, xOffset,
yOffset);
dict[name] = data;
}
Or should I use a class for that AtlasSpriteData?
reading about it I get the impression everytime I'll look up
data from that dictionary data will get copied ?
In this case class makes sense (assuming AtlasSpriteData has few
instances that will be shared around a lot). But you could also
use a pointer to a struct, especially if you manually allocate it
and want to avoid the GC. Also, you can read data from the
associative array by reference (basic example, no error checking):
ref AtlasSpriteData spriteData(string name) { return dict[name]; }
Re: Is there a native function to detect if file is UTF encoding?
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote:
To call decode() from std.encoding I need to make sure it is an
UTF (may ne ASCII too) otherwise is will skyp over ASCII
values. Is there any D native for it or I need to check byte
order mark and write one myself?
This may be simpler for reference:
https://github.com/kiith-sa/tinyendian/blob/master/source/tinyendian.d
Note that you _can't_ reliably differentiate between UTF-8 and
plain ASCII,
because not all UTF-8 files start with a UTF-8 BOM.
However, you can (relatively) quickly determine if a UTF-8/ASCII
buffer contains only ASCII characters; as UTF-8 bytes always have
the topmost bit set, and ASCII don't, you can use a 64-bit
bitmask and check by 8 characters at a time.
See
https://github.com/kiith-sa/D-YAML/blob/master/source/dyaml/reader.d,
specifically the countASCII() function - it should be easy to
change it into 'detectNonASCII':
/// Counts the number of ASCII characters in buffer until the
first UTF-8 sequence.
///
/// Used to determine how many characters we can process without
decoding.
size_t countASCII(const(char)[] buffer) @trusted pure nothrow
@nogc
{
size_t count = 0;
// The topmost bit in ASCII characters is always 0
enum ulong Mask8 = 0x7f7f7f7f7f7f7f7f;
enum uint Mask4 = 0x7f7f7f7f;
enum ushort Mask2 = 0x7f7f;
// Start by checking in 8-byte chunks.
while(buffer.length = Mask8.sizeof)
{
const block = *cast(typeof(Mask8)*)buffer.ptr;
const masked = Mask8 block;
if(masked != block) { break; }
count += Mask8.sizeof;
buffer = buffer[Mask8.sizeof .. $];
}
// If 8 bytes didn't match, try 4, 2 bytes.
import std.typetuple;
foreach(Mask; TypeTuple!(Mask4, Mask2))
{
if(buffer.length Mask.sizeof) { continue; }
const block = *cast(typeof(Mask)*)buffer.ptr;
const masked = Mask block;
if(masked != block) { continue; }
count += Mask.sizeof;
buffer = buffer[Mask.sizeof .. $];
}
// If even a 2-byte chunk didn't match, test just one byte.
if(buffer.empty || buffer[0] = 0x80) { return count; }
++count;
return count;
}
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
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: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
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 Awesome. This needs to be one of the first things a visitor notices on the D site.
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: [OT] Uploading DConf videos
On Saturday, 19 July 2014 at 03:39:55 UTC, Andrei Alexandrescu wrote: On 7/18/14, 6:15 PM, Kiith-Sa wrote: This. Vimeo is quite popular, quality shouldn't be a problem and people aren't going to wait for an hour like with archive.org. Awesome. Can you please volunteer to mirror all of dconf videos to vimeo? Thanks. Andrei: I'm about 90% sure you're doing something wrong. I've never seen a HD youtube video with such low quality. Ask Dicebot, he's doing it. Andrei I'm trying it out. I've probably hit your issue with Vimeo, though: Vimeo is impractical unless you pay them (~50€/year). With a free account you can only upload 1 HD video / week. I guess you pay for what you get with no ads. I'm going to upload one video anyway just to test it. My point, however, is that you need the video to be accessible before you post it somewhere to Reddit. Archive.org is *not* accessible, it's bandwidth is way too limited. You need to have it on Vimeo, or YouTube, or whatever *before* you post it. Dicebot uploading it an hour later and posting it in a comment that may or may not get noticed (or me uploading it a day later) is not going to help.
Re: [OT] Uploading DConf videos
On Saturday, 19 July 2014 at 03:39:55 UTC, Andrei Alexandrescu wrote: On 7/18/14, 6:15 PM, Kiith-Sa wrote: This. Vimeo is quite popular, quality shouldn't be a problem and people aren't going to wait for an hour like with archive.org. Awesome. Can you please volunteer to mirror all of dconf videos to vimeo? Thanks. Andrei: I'm about 90% sure you're doing something wrong. I've never seen a HD youtube video with such low quality. Ask Dicebot, he's doing it. Andrei I uploaded one DConf video to test Vimeo: https://archive.org/details/dconf2014-day01-panel Vimeo has a limit of 500MB/week so I actually had to reencode it myself (~734-~480MB). Then Vimeo reencoded it again after upload. So quality with a paid account would likely be higher. The top image is the original, middle is my reencode before uploading and bottom is the result at Vimeo: http://imgur.com/a/2SXHx There's a visible loss of detail, but it's not nearly evident as on the screens you have shown. Here's the video: https://vimeo.com/101179246
Re: [OT] Uploading DConf videos
... and I did try YouTube now just to see if the quality is really that bad. It isn't: http://i.imgur.com/Cu1tUQl.png That's about as good as the archive.org originals. I took this with YouTube resolution set to 1280x720 on a 1920x1080 monitor. I really think you are doing something wrong. Or YouTube is serving lower resolution to you for some reason even if you have HD turned on. Maybe a crappy ISP?
Re: [OT] Uploading DConf videos
On Saturday, 19 July 2014 at 22:42:40 UTC, Kiith-Sa wrote: ... and I did try YouTube now just to see if the quality is really that bad. It isn't: http://i.imgur.com/Cu1tUQl.png That's about as good as the archive.org originals. I took this with YouTube resolution set to 1280x720 on a 1920x1080 monitor. I really think you are doing something wrong. Or YouTube is serving lower resolution to you for some reason even if you have HD turned on. Maybe a crappy ISP? ... and for completeness here's a screen of the same video with 360p (480p actually looks better): http://i.imgur.com/bE1ak5i.png I think this is what YouTube is serving to you (even though colors seem different? - details are the same)
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/
Re: [OT] Uploading DConf videos
On Saturday, 19 July 2014 at 00:31:33 UTC, Joakim wrote: On Friday, 18 July 2014 at 22:39:02 UTC, Andrei Alexandrescu wrote: On 7/18/14, 12:53 PM, Jacob Carlborg wrote: On 2014-07-18 17:44, Andrei Alexandrescu wrote: Somehow the same DConf videos are of better quality on archive.org than on youtube.com. Could you explain that? -- Andrei You're streaming and not downloading from Youtube. I always download longer video clips from Youtube. I don't want any buffering while watching. Is there an easy way to download off of youtube one of DConf talks at the same quality as the archive.org content? -- Andrei Do you increase the resolution of your Youtube videos when you don't like the quality that it's streaming? It's not clear if you are complaining about the quality because you're on a slow network and Youtube is giving you the low-quality encode, or if you don't like their higher-quality encodes also. If you click on the Settings icon that looks like a gear below the video, you can force the quality as high as the original video uploaded, by changing the default Auto resolution mode. I can't complain about their HD encodes. As for downloading from Youtube, that's not really officially supported, but scripts/apps like the one linked earlier will do it. Have you looked at Vimeo? They're probably the second-biggest video site after Youtube and are sticklers for quality resolution, as they used to focus on the indie filmmaker community, and they officially support downloading videos, if the uploader chooses to enable that option. This. Vimeo is quite popular, quality shouldn't be a problem and people aren't going to wait for an hour like with archive.org. Andrei: I'm about 90% sure you're doing something wrong. I've never seen a HD youtube video with such low quality. Either you didn't set the resolution higher (default is 360p or something), or you have a crappy connection and YouTube refuses to stream high-quality (it happened to me a few times that I still got the low-quality video after setting it to HD - refresh (F5) after setting the resolution sometimes works), or as said above you made that screen only a few seconds after starting/skipping a part of the video.
