Re: DlangUI project update
On Tuesday, 30 December 2014 at 04:39:42 UTC, Vadim Lopatin wrote:
On Monday, 29 December 2014 at 19:55:13 UTC, kdmult wrote:
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin
wrote:
I've tried to find some replacement for it, and found
FreeImage
There is http://code.dlang.org/packages/dlib which includes
dlib.image - image processing (filters, color correction,
FFT, HDRI, graphics formats I/O, support for 8 and 16-bit RGBA
buffers and floating point operations)
Thanks! I will try it.
DLIB works perfectly for me.
I've removed FreeImage dependency from dlangui completely.
Some objections:
JPEG reading from master branch is working, but unaccessible from
tagged version.
Two warnings in jpeg.d prevent using dub build from master branch.
dlib/image/io/jpeg.d(76): Warning: use '{ }' for an empty
statement, not a ';'
dlib/image/io/jpeg.d(259): Warning: statement is not reachable
When file format is not supported, image loader fails assertion.
Why not return null or throw exception? It's not feasible.
It will be great if dlib with JPEG reading support is released!
Temporary disabling JPEG support.
Image interface provides access to pixels as float point rgba
only.
Double conversion occurs when I'm getting data.
Are there any plans to provide some interface to read data as
integers? E.g. 8bitRGBA.
As well I've tried de_image (can be used instead of dlib if built
with version=USE_DEIMAGE).
RGBA PNGs are being loaded ok.
BW pngs cannot be read - author is working on fix.
No JPEG support - it would be great if author could add it in
future.
Will keep checking the progress of de_image development.
Re: DlangUI project update
On Tue, 30 Dec 2014 09:19:05 + Vadim Lopatin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: As well I've tried de_image (can be used instead of dlib if built with version=USE_DEIMAGE). yet it requires fill devisualization. for now it complains about manipulation.d(5): Error: module linegraph is in file 'devisualization/util/core/linegraph.d' which cannot be read ;-) and this prevents building example1, as dub tries to build de_image unconditionally. otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? signature.asc Description: PGP signature
Re: DlangUI project update
btw: i'm not trying to say something bad about the project. quite contrary: i wish it success, as i really want native D cross-platform GUI library, and want it not to be DWT (as DWT is not working for me anyway ;-). signature.asc Description: PGP signature
Re: DlangUI project update
On Tuesday, 30 December 2014 at 09:37:09 UTC, ketmar via Digitalmars-d-announce wrote: On Tue, 30 Dec 2014 09:19:05 + Vadim Lopatin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: As well I've tried de_image (can be used instead of dlib if built with version=USE_DEIMAGE). yet it requires fill devisualization. for now it complains about manipulation.d(5): Error: module linegraph is in file 'devisualization/util/core/linegraph.d' which cannot be read ;-) It's reproduced with new DUB (newer that 0.9.22 available for download on code.dlang.org). I've disabled de_image dependency so far (dlangui v0.1.22) to fix this problem. and this prevents building example1, as dub tries to build de_image unconditionally. otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? Of course, it's not supposed to work like this :) Are you running it under linux? It's working for me on ubuntu 14.4
Re: DlangUI project update
On Tue, 30 Dec 2014 10:15:10 + Vadim Lopatin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? Of course, it's not supposed to work like this :) Are you running it under linux? yes. Slackware GNU/Linux, x86, nVidia GT8600, proprietary nVidia drivers (rather old, something around 320). built as README says, i.e. with `dub run --force dlangui:example1` (i added force just to be sure that no stale libraries were used). signature.asc Description: PGP signature
Re: DlangUI project update
On Tuesday, 30 December 2014 at 09:37:09 UTC, ketmar via Digitalmars-d-announce wrote: otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? It looks like resources from dlangui/lib are not loaded. I see only ones from examples/example1/res Can you try to copy dlangui/res directory to directory where executable is located?
Re: DlangUI project update
On Tuesday, 30 December 2014 at 10:28:53 UTC, Vadim Lopatin wrote: On Tuesday, 30 December 2014 at 09:37:09 UTC, ketmar via Digitalmars-d-announce wrote: otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? It looks like resources from dlangui/lib are not loaded. I see only ones from examples/example1/res Can you try to copy dlangui/res directory to directory where executable is located? Sorry, from dlangui/res, not from dlangui/lib
Re: DlangUI project update
On Tue, 30 Dec 2014 10:28:52 + Vadim Lopatin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Tuesday, 30 December 2014 at 09:37:09 UTC, ketmar via Digitalmars-d-announce wrote: otherwise it's not crashing anymore, yet it still looks very funny: http://ketmar.no-ip.org/2014-12-30-11-35-26_700x500.png is it supposed to look like this? It looks like resources from dlangui/lib are not loaded. I see only ones from examples/example1/res Can you try to copy dlangui/res directory to directory where executable is located? sure, no prob. yes, after i coped dlangui res/ dir to the directory where example1 binary resides, everything is working as it should. (actually, i copied it to dlangui/examples/example1/bin, where dub creates symlink to the real binary) p.s. there is small glitch with checked checkboxes though: image is not transparent. p.p.s. can i turn that $##%^%@#@ font antialiasing off? ;-) signature.asc Description: PGP signature
Re: DlangUI project update
On Tue, 30 Dec 2014 10:39:39 + thedeemon via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 29 December 2014 at 09:50:23 UTC, ketmar via Digitalmars-d-announce wrote: it would be not that hard to write a native D png loader Here is some already: https://github.com/adamdruppe/arsd/blob/master/png.d I've used it successfully. Just one thing: it uses GC heap very actively (causing leaks on 32 bits), so I had to work around that. and i bet that there is 'stb_image.d' somewhere on github, which does jpg and bmp. signature.asc Description: PGP signature
Re: DlangUI project update
On Tue, 30 Dec 2014 10:39:39 + thedeemon via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 29 December 2014 at 09:50:23 UTC, ketmar via Digitalmars-d-announce wrote: it would be not that hard to write a native D png loader Here is some already: https://github.com/adamdruppe/arsd/blob/master/png.d I've used it successfully. Just one thing: it uses GC heap very actively (causing leaks on 32 bits), so I had to work around that. p.s. i'm using some of Adam's modules, but keep forgetting to look in arsd to check if it has something handy that i never used. ;-) signature.asc Description: PGP signature
Re: DlangUI project update
On Tuesday, 30 December 2014 at 10:37:14 UTC, ketmar via Digitalmars-d-announce wrote: On Tue, 30 Dec 2014 10:28:52 + On Tuesday, 30 December 2014 at 09:37:09 UTC, ketmar via Can you try to copy dlangui/res directory to directory where executable is located? sure, no prob. yes, after i coped dlangui res/ dir to the directory where example1 binary resides, everything is working as it should. BTW, new release of DUB will include my pull request to support directories as items in copyFiles - resources will be copied automatically. (actually, i copied it to dlangui/examples/example1/bin, where dub creates symlink to the real binary) p.s. there is small glitch with checked checkboxes though: image is not transparent. Probably, it's issue of dlib png imported, but i'm not 100% sure. p.p.s. can i turn that $##%^%@#@ font antialiasing off? ;-) I can implement such setting for you :) Does it really look ugly with font antialiasing? P.S: I've turned on JPEG support - from ~master of dlib.
Re: DlangUI project update
On Friday, 26 December 2014 at 12:33:04 UTC, Vadim Lopatin wrote: DlangUI project is alive and under active development. https://github.com/buggins/dlangui Update: FreeImage dependency is removed. dlib is now used to read images. I'm trying to improve project documentation. DDOC generates ugly unusable output. DDOX is much better. But I cannot figure out how to embed custom navigation panel (e.g. like on vibed.org) on documentation pages (as I have for DDOC generated files). dub --build=ddox produces pages with only navigation by generated documentation. Ho do I add custom pages, with links to them from documentation pages? It looks like ddox ignores .dd files from project. Could someone help? Best regards, Vadim
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: DlangUI project update
On Tue, 30 Dec 2014 12:59:18 + Vadim Lopatin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: p.p.s. can i turn that $##%^%@#@ font antialiasing off? ;-) I can implement such setting for you :) Does it really look ugly with font antialiasing? it's looking $#^#$%^%@# @$#%^%%$ $#%%#$@#^ UGLY. any font aliasing looks like this. my eyes bleeding when i looking at antialiased fonts. i either can turn that stupid thing off, or the program is completely unusable for me. i read that you planning fontconfig support, so please just don't forget about aliasing and hinting options. there are some people that prefer to switch antialiasing off and turn full hinting on, as this is the best settings for free microsoft core fonts for the web set (or at least we believe that this is the best). signature.asc Description: PGP signature
Re: DlangUI project update
On Friday, 26 December 2014 at 12:33:04 UTC, Vadim Lopatin wrote: Hello! DlangUI project is alive and under active development. https://github.com/buggins/dlangui Recent changes: - new controls: ScrollWidget, TreeView, ComboBox, ... - new dialogs: FileOpenDialog, MessageBox - a lot of bugfixes - performance improvements in software renderer - killer app: new example - Tetris game :) Try Demos: # download sources git clone https://github.com/buggins/dlangui.git cd dlangui # example 1 - demo for most of widgets dub run dlangui:example1 --build=release # tetris - demo for game development dub run dlangui:tetris --build=release DlangUI is cross-platform GUI library written in D. Main features: - cross platform: uses SDL for linux/macos, Win32 API or SDL for Windows - hardware acceleration: uses OpenGL for drawing when built with version USE_OPENGL - easy to extend: since it's native D library, you can add your own widgets and extend functionality - Unicode and internationalization support - easy to customize UI - look and feel can be changed using themes and styles - API is a bit similar to Android - two phase layout, styles Screenshots (a bit outdated): http://buggins.github.io/dlangui/screenshots.html See project page for details. I would like to get any feedback. Will be glad to see advises, bug reports, feature requests. Best regards, Vadim Is it possible to use your GUI for opengl game? I need to inject a gui in an existing main loop.
Re: DlangUI project update
On Tue, 30 Dec 2014 18:18:38 + MrSmith via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Is it possible to use your GUI for opengl game? I need to inject a gui in an existing main loop. as it seems to have OpenGL as one of the backends, i think that it shouldn't be hard even if it is not supported directly right now. please write about your progress here (if there will be any). signature.asc Description: PGP signature
Re: Harbored-mod 0.1: A documentation generator with DDoc and Markdown support based on Harbored
On Tuesday, 30 December 2014 at 14:46:06 UTC, Kiith-Sa wrote: ... and I think at this point it might be useful for other people as well. Thx, it works fine (altough I haven't tested the markdown features yet) and fixes an issue I had with the original harbored. If someone want to build **harbored-mod** using Coedit, there is a new version of an old tutorial. https://github.com/BBasile/Coedit/wiki#integration-of-the-documentation-generator-harbored-mod-to-coedit
Re: DlangUI project update
On Tuesday, 30 December 2014 at 18:32:04 UTC, ketmar via Digitalmars-d-announce wrote: On Tue, 30 Dec 2014 18:18:38 + MrSmith via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Is it possible to use your GUI for opengl game? I need to inject a gui in an existing main loop. as it seems to have OpenGL as one of the backends, i think that it shouldn't be hard even if it is not supported directly right now. please write about your progress here (if there will be any). I've built library with 2.066.1 and master Despite resources is not copied by dub it works fine. Fixed C-style arrays and sent PR https://github.com/buggins/dlangui/pull/24
ATTN Derelict Users and Package Maintainers
I've added a new feature to Derelict that I'd appreciate some feedback on. It works for me, but I want to verify that it works in the wild before I expand it to other packages and move forward with another feature I plan to add. You can read more about it in my blog post at [1]. If you are using DerelictSDL2 in a project, I'd appreciate it if you'd change your dependency to derelict-sdl2: =1.9.0 and let me know if it breaks your build or not. And if you aren't using any of the functions added in SDL 2.0.2, then I'd also appreciate it if you'd test the new feature as described in the blog post: // If you require functions in 2.0.1 DerelictSDL2.load( SharedLibVersion( 2, 0, 1 )); // If you don't need any functions beyond 2.0.0 DerelictSDL2.load( SharedLibVersion( 2, 0, 0 )); The goal is to allow you to load any version of SDL that your app can support from one package. I've noticed that most people tend to use the highest version of DerelictSDL2 (1.2.x), which only loads SDL 2.0.2 and 2.0.3 and will fail with the lower versions, even though they aren't using any of the newer API additions. If you have a package you maintain that uses DerelictUtil for loading, you do not need to implement this yourself. It is entirely optional. Not all DerelictOrg packages will get this. However, if it makes sense in the context of the library you are loading, please consider implementing it and letting me know how it goes. Essentially, you'll need to change your dependency to derelict-util:=1.9.0 and override the new protected method configureMinimumVersion in your loader to install a library-specific MissingSymbolCallback. I've linked an example in the blog post. [1] http://dblog.aldacron.net/new-derelict-feature/
Re: Worst Phobos documentation evar!
On 12/29/2014 10:04 PM, Rikki Cattermole wrote: On 30/12/2014 6:36 p.m., Andrei Alexandrescu wrote: On 12/29/14 9:13 PM, Rikki Cattermole wrote: I wonder if I can get ddoc to generate json files. That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei I've had a go, its mostly already possible for json. Although escaping is a major issue. For things like a double quote. This is what I have: Thank you for doing this! License: The MIT License (MIT) Can you please consider the Boost license? It's what everything else in D uses. Having multiple licenses interleaved makes things much more complicated for corporate lawyers to adopt.
Re: Nicer anchors
On 12/29/14 11:11 PM, Kapps wrote: On Tuesday, 30 December 2014 at 05:30:26 UTC, Andrei Alexandrescu wrote: On 12/29/14 4:19 PM, Andrei Alexandrescu wrote: Please destroy https://github.com/D-Programming-Language/dlang.org/pull/734 -- Andrei Improved anchors are up on the site. Please try'em out! -- Andrei http://dlang.org/phobos/std_algorithm.html Just has quickindex, quickindex displayed instead of any anchors. Ah, thanks. Fixed on the site, here's the pr: https://github.com/D-Programming-Language/dlang.org/pull/735 -- Andrei
Re: Nicer anchors
On Tuesday, 30 December 2014 at 04:27:33 UTC, Andrei Alexandrescu wrote: appealing, and that is frustration. After all _anyone_ concerned with the state of ddox could check for themselves in less than a minute by attempting to build the docs. The irritation pattern that seems to be present in this group as of late only invites more of it. Well, to fix something, one would first need to know that it's broken. (It would take me more than a minute to check as I don't use dub or have it installed.) The better route out of this is to kindly invite contributors who added ddox support, and all others who are interested, to improve ddox build to the point of making it robustly usable. I trust you are out there reading this. Thanks. I think you are entirely right in that such issues should be resolved not by D project leaders, but delegated to Dub/DDox maintainers. But we should be aware of possible communication issues regarding in whose court the ball is at the moment. I've filed an issue, hope this helps: https://github.com/rejectedsoftware/ddox/issues/69
Re: DConf 2015?
On 30 Dec 2014 03:40, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/29/2014 3:37 AM, Kingsley wrote: I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage The best thing you can do is submit a speaking proposal. which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London? It'll be at Utah Valley University: http://www.uvu.edu/visitors/aboutuvu/ Where's the announcement? (sorry if you already have, I am yet to see it). Iain.
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 00:37:26 UTC, Kiith-Sa wrote: On Monday, 29 December 2014 at 23:56:47 UTC, Walter Bright 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. Documentation here in SR Labs is allowed only in ReStructuredText: it's just a pleasure to use it. --- Paolo
Re: DConf 2015?
On 30 Dec 2014 08:59, Iain Buclaw ibuc...@gdcproject.org wrote: On 30 Dec 2014 03:40, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/29/2014 3:37 AM, Kingsley wrote: I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage The best thing you can do is submit a speaking proposal. which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London? It'll be at Utah Valley University: http://www.uvu.edu/visitors/aboutuvu/ Where's the announcement? (sorry if you already have, I am yet to see it). Iain. Even a new frontpage at dconf.org with new Dconf2015 stripes, current proposed location and date (even if still not finalized - emphasis on *to be confirmed*), and early request for speakers would be great. Infact, even just an early request for speakers *before* any finalized plans for date and location would be beneficial for those wanting to take part. :-) Iain.
Re: module win32.winioctl :IOCTL_STORAGE_EJECT_MEDIA' Value is Error
Am 30.12.2014 um 04:03 schrieb FrankLike: On Monday, 29 December 2014 at 12:19:34 UTC, dennis luehring wrote: Am 29.12.2014 um 13:00 schrieb FrankLike: Now,I use the win32.winioctl.d file,find :IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will get the error value 50.(by GetLastError()). It should be 0x2d4808.If you use it ,it works ok. Why have this kind of mistake? Frank maybe just a bug but https://github.com/Diggsey/druntime-win32/blob/master/winioctl.d seems to be correctly defined IOCTL_STORAGE_EJECT_MEDIA = CTL_CODE_T!(IOCTL_STORAGE_BASE, 0x0202, METHOD_BUFFERED, FILE_READ_ACCESS), Sorry,I've known what's wrong with it. Should do similar to C++: import win32.winioctl; Don't similar to c#: public uint IOCTL_STORAGE_EJECT_MEDIA = 0x2d4808; so it was your fault not using the IOCTL_STORAGE_EJECT_MEDIA as defined in the import where do you get the 0x0202 value from your questions, problems AND solutions are always very hard to understand
Re: Worst Phobos documentation evar!
On 30/12/2014 8:57 p.m., Walter Bright wrote: On 12/29/2014 10:04 PM, Rikki Cattermole wrote: On 30/12/2014 6:36 p.m., Andrei Alexandrescu wrote: On 12/29/14 9:13 PM, Rikki Cattermole wrote: I wonder if I can get ddoc to generate json files. That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei I've had a go, its mostly already possible for json. Although escaping is a major issue. For things like a double quote. This is what I have: Thank you for doing this! Unfortunately I can't take it any further as there will need to be compiler support. Things like white space and quote escaping is just nasty right now. License: The MIT License (MIT) Can you please consider the Boost license? It's what everything else in D uses. Having multiple licenses interleaved makes things much more complicated for corporate lawyers to adopt. That was example output based upon Devisualization.Window:interfaces. Don't worry about it. I posted just so e.g. Andrei could take it further since I can't.
version(assert) defined variables
Hi all,
Please consider the following program:
int main()
{
version(assert) int var;
assert(var == 0);
return 0;
}
When compiled with dmd test.d, it passes without a problem. When
compiled with dmd test.d -release, it produces the following error:
test.d(5): Error: undefined identifier var
This makes no sense. In order to make the program compile, I need to do
the (quite nonsensical):
version(assert) assert(var == 0);
Is this on purpose?
Shachar
Re: http://wiki.dlang.org/DIP25
On 12/29/14 8:10 PM, Manu via Digitalmars-d wrote: On 30 December 2014 at 07:29, Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/29/14 3:42 PM, Dicebot wrote: I think it wouldn't be a bad idea to investigate a new way to express attributes, but I think no matter what we do, we need to rein in the explosion of attributes that needs to be put on every function. The approach is to infer everything, right? The only time you are required to make it explicit is when it's an important detail of your API, and you want to receive compile errors when you violate such explicit request. This only works for templates. Unless we devise a new object scheme and linker... But I agree. The problem is, most times, you WANT to ensure your code is @safe pure nothrow (and now @nogc), even for template functions. That's a lot of baggage to put on each signature. I just helped someone recently who wanted to put @nogc on all the std.datetime code, and every signature had these 4 attributes except a few. I tried to have him put a big @safe: pure: nothrow: @nogc: at the top, but the occasional exceptions made this impossible. It's unfortunate we couldn't start with these being the defaults, and then add the occasional @system, @unpure, and @throws where appropriate. Some mechanism of aliasing attribute combinations is itching to get done :) -Steve
Re: const Propagation
On 12/29/14 9:12 PM, Matt Soucy wrote:
On 12/29/2014 02:07 PM, anonymous wrote:
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but that would mean
that I would implement the whole visitor twice - one const and one non-const version. Is
that really the only way? Can't I tell the D compiler that the argument of that
lambda shares the const-ness of the current object?
D offers inout; this actually aims into the right directing, but I guess it
does not help here.
Is there any static if-something construct to check the const-ness of an
object?
There's a pattern I suggested before[1] that I'd like to mention
in addition to the template solutions Steven Schveighoffer and
Daniel Kozak gave:
Call the non-const overload from the const overload and cast
accordingly.
In your case:
void blah(void function(Hugo h) f) {
f(this);
}
void blah(void function(const Hugo h) f) const {
(cast(Hugo) this).blah(cast(void function(Hugo)) f);
}
This is safe as long as the non-const overload does not mutate
the object when f doesn't. BUT you have to make sure of that
yourself; the compiler can't help anymore.
[1]
http://stackoverflow.com/questions/22442031/how-to-make-a-template-function-const-if-the-template-is-true/22442425#22442425
Wait, is there a reason that you cast away const instead of adding it? I
haven't done too much with D const lately, but in C++ I know that I would have
the non-const version call the const version instead - seems a bit safer, and
the compiler can check it a bit beter.
It would still require a cast. Remember the function pointer passed to
non-const blah requires a non-const Hugo. So you would have to cast at
least the function pointer to void function(const(Hugo)). This doesn't
sit as well as casting the other way (you can always call a function
that takes a const Hugo with a non-const Hugo), although practically
speaking, there isn't any damage done. However, the call of f inside the
const blah function would violate const. If f were marked as pure, this
could be actually damaging.
Either solution looks ugly and error-prone to me. I like the template
solution the best, either as a template this member or a UFCS template
function call. The delegate solution I posted earlier is neat, but seems
too inelegant.
-Steve
Re: Lost a new commercial user this week :(
On 12/29/14 8:54 PM, Andrei Alexandrescu wrote: On 12/29/14 4:25 PM, Walter Bright wrote: On 12/29/2014 8:51 AM, Dicebot wrote: On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote: If anybody cared about good Windows debugging support or getting vibe.d working flawlessly on Windows, they'd have done it already. Now, Manu might bring more attention to those issues through his post and someone may decide to work on them as a result- it has already spurred Walter to try and improve the phobos docs- which is why I have no problem with his criticism. Criticism about documentation is actually very well-placed - it is an issue that affects everyone, can be fixed in small chunks and does not require huge effort investment for each chunk. No one loses, everyone wins, yay! I am trying to lead by example, but so far I see only a couple pull requests from others improving the Phobos docs. C'mon, guys, most fixes are pretty trivial, it's just that there's a lot of them. If everyone does one for a function they're already familiar with, we can get a lot done. I've also fixed a stray paren in std.algorithm (https://github.com/D-Programming-Language/phobos/pull/2824), which was diagnosed correctly every time the documentation was generated. During doc generation there are also a bunch of warnings about undocumented or mismatched params. It would be awesome if someone was on it. I very much appreciate the folks who make it a point to contribute to the github repos in addition to helping out people on the forums. I've identified as a distinct task of mine for 2015 to improve my leadership skills, starting with convincing someone to literally remove one character :o). Please, let's make the build of the documentation be an error on auto tester. I can say personally, there is so much more involved with building the docs than I care to deal with. You need all the repositories, and the dlang.org repository, which I rarely use. IIRC, you also need everything laid out in the right way to get that to work. If the auto tester simply errored when the doc has issues, then at least someone would be aware of it. -Steve
Re: Aliases and UDA's
Manu via Digitalmars-d wrote in message news:mailman.3785.1419919315.9932.digitalmar...@puremagic.com... I guess the reason is that A is not really a thing; it is translated to S!int when being given to T? Is that the point where world is lost? Yes. world is still there, but you can't actually get the symbol A. I'm not really sure how I can achieve what I want here... I need to attribute particular instantiations of a template struct as shown. Why does it have to be UDAs? You can easily put the 'attributes' inside S or define a template for getting the attributes from an arbitrary S. Something like: enum myAttributes(T : S!int) = TypeTuple!(world); enum myAttributes(T : S!U, U) = TypeTuple!();
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 05:36:47 UTC, Andrei Alexandrescu wrote: That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei Would it not be easier to just do a raw convert to XML and use XSLT to transform into other formats?
Re: Worst Phobos documentation evar!
On Tue, 2014-12-30 at 13:08 +, via Digitalmars-d wrote: On Tuesday, 30 December 2014 at 05:36:47 UTC, Andrei Alexandrescu wrote: That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei Would it not be easier to just do a raw convert to XML and use XSLT to transform into other formats? And, of course, ASCIIDoc was invented to be a human usable input to such a tool chain. Though now with ASCIIDoctor there is a direct to PDF without using FOP or LaTeX. Markdown is inadequate for more than single page HTML, XeLaTeX is incorrectly disliked by far too many people, ReStructured Text is perceived to be Python specific,… ASCIIDoc wins. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 13:18:46 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-12-30 at 13:08 +, via Digitalmars-d wrote: On Tuesday, 30 December 2014 at 05:36:47 UTC, Andrei Alexandrescu wrote: That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei Would it not be easier to just do a raw convert to XML and use XSLT to transform into other formats? And, of course, ASCIIDoc was invented to be a human usable input to such a tool chain. Though now with ASCIIDoctor there is a direct to PDF without using FOP or LaTeX. Markdown is inadequate for more than single page HTML, XeLaTeX is incorrectly disliked by far too many people, ReStructured Text is perceived to be Python specific,… ASCIIDoc wins. coming from Python, i'm in favour of rST, markdown and asciidoc.
Re: Worst Phobos documentation evar!
About that user experience: http://forum.dlang.org/post/nyclgpfzpkzemgitf...@forum.dlang.org
#code2014
http://www.code2014.com/ Help give D some publicity!
Re: Worst Phobos documentation evar!
On 12/29/14 10:49 PM, ketmar via Digitalmars-d wrote: On Mon, 29 Dec 2014 15:49:10 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/29/2014 2:40 PM, Adam D. Ruppe wrote: Ddoc isn't too bad, but trying to document examples in dom.d turned into a mess of /// finds $(LT)foo/$(GT) quickly and I couldn't stand it. I'd make a macro: XML=$(LT)$0/$(GT) I use custom macros all the time in Ddoc. If you aren't, you're not doing it right :-) that's why ddoc is completely unusable either for reading as is or for generating separate documentation. i was very excited about built-in documentation generator in D, and now i'm not using it at all. i rarely generating stand-alone docs, they are just not handy for me. i prefer to read documentation right in the source (yet i still want to have an option to generate stand-alone files). did you tried to read Phobos documentation in Phobos sources? those macros are pure visual noise. i don't mind if D will understand one of the Markdown variants, or textile, or rss -- anything that is READABLE without preprocessing, yet can be easily processed to another format. i don't mind learning another markdown dialect if i can easily read it without preprocessing. that's why i'm not using doxygen too: it's noisy. seems that most document generator authors are sure that only generated documentation matters, so source documentation can be of any uglyness. yet if documentation is hard to read without preprocessor, it is hard to write it too! so people will tend to avoid writing it, and they will especially avoid polishing it, 'cause it's write-only, contaminated and hard to fix. D documentation WILL be bad until ddoc will start to understand some markdown-like mostly macro-free markup language. Those are exactly my thoughts.
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
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 01:50:01 UTC, ketmar via Digitalmars-d wrote: D documentation WILL be bad until ddoc will start to understand some markdown-like mostly macro-free markup language. I honestly don't think the macros are the biggest problem though. I think a bigger deal is the lack of overviews. Take a look here: http://dlang.org/phobos/std_algorithm.html There's some overview, and even a couple links. But the point about opaque types that are supposed to just work isn't easy to find. Contrast it to what Microsoft wrote up for Windows: http://msdn.microsoft.com/en-us/library/ms713499%28v=vs.85%29.aspx There's conceptual overviews, real-world examples, and the references (which link back to the relevant concepts and examples). std.algorithm could mention the concept of laziness, show examples of the opaque functions, have examples of the common (like seriously one of the most frequently asked questions I've seen) how do I turn it into an array?, or show/explain how and why to avoid that. That's mostly plain text that could be written up in the module explanation or as a separate page. I think that's more important than what macros are used.
Re: compile-time opIndex
On 12/18/14 11:54 AM, Dicebot wrote: I wasn't subscribed to druntime changes thus missed this discussion. Will chime in there soon. Ping, still waiting on this :) -Steve
Re: compile-time opIndex
On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven Schveighoffer wrote: On 12/18/14 11:54 AM, Dicebot wrote: I wasn't subscribed to druntime changes thus missed this discussion. Will chime in there soon. Ping, still waiting on this :) -Steve *blush*
Re: compile-time opIndex
On 12/30/14 10:51 AM, Dicebot wrote: On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven Schveighoffer wrote: On 12/18/14 11:54 AM, Dicebot wrote: I wasn't subscribed to druntime changes thus missed this discussion. Will chime in there soon. Ping, still waiting on this :) *blush* OK, I see your response, but I'm still curious as to how/whether your DIP would solve it. Any thoughts on the feature brought up in this thread? -Steve
Re: Nicer anchors
On 30/12/2014 01:27, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 01:18:39 UTC, Andrei Alexandrescu wrote: How would that achieve cross referencing? To be clear, what your change does is make links like this work, yes? http://erdani.com/d/phobos-prerelease/std_range_package.html#.RefRange.save No, this has worked for some time. (BTW, nice leading dot there...) Necessary for full backwards link compatibility. The toPrettyChars function outputs the fully-qualified name too without needing a script. DDOC_ANCHOR is fully qualified (and its more complicated than just toPrettyChars).
Re: Nicer anchors
On 30/12/2014 02:18, Vladimir Panteleev wrote: I'm not sure using numbers to distinguish overloads is a good idea. Such links would break easily. Note: that isn't part of Andrei's pull. Using numbers is the only workable way, other schemes would also break easily, probably moreso. I implemented it so that ditto overloads don't get a separate number, to avoid some breakage when adding dittos.
Re: Worst Phobos documentation evar!
On 28/12/2014 17:09, Nick Treleaven wrote: On 28/12/2014 14:22, Joseph Rushton Wakeling via Digitalmars-d wrote: BTW is it just me, or are the various isSomething methods of std.traits not having documentation generated properly? See: http://dlang.org/phobos/std_traits.html ... and try searching for, say, isBoolean, or isSomeString. Works with my newer dmd, I'm not sure why that link doesn't have them. Also the pre-release docs seem to have them: http://dlang.org/phobos-prerelease/std_traits.html#isSomeString
Re: Lost a new commercial user this week :(
On 12/30/14 4:30 AM, Steven Schveighoffer wrote: Please, let's make the build of the documentation be an error on auto tester. I can say personally, there is so much more involved with building the docs than I care to deal with. You need all the repositories, and the dlang.org repository, which I rarely use. IIRC, you also need everything laid out in the right way to get that to work. mkdir /dir/for/d/ cd /dir/for/d/ git clone https://github.com/D-Programming-Language/tools tools/update.sh ... and you're there. This should be on a wiki page. Takers? If the auto tester simply errored when the doc has issues, then at least someone would be aware of it. Agreed. Andrei
Re: Nicer anchors
On 12/30/14 8:59 AM, Nick Treleaven wrote: On 30/12/2014 02:18, Vladimir Panteleev wrote: I'm not sure using numbers to distinguish overloads is a good idea. Such links would break easily. Note: that isn't part of Andrei's pull. Yah, I was surprised when I saw'em. Using numbers is the only workable way, other schemes would also break easily, probably moreso. I implemented it so that ditto overloads don't get a separate number, to avoid some breakage when adding dittos. Agreed. I think the best solution is to simply group overloads together. They already do related things in any given module, so consolidating documentation makes sense anyway. Andrei
Any LaTeX expers n da house?
With https://github.com/D-Programming-Language/dlang.org/pull/736, beautiful PDF generation via LaTeX is now possible. There are, of course, many details to tend to. For starters, currently the doc is overly sparse, which makes it large (520 pages). But the basic framework is in place and works. Who would want to give it a shot at beautifying it? Andrei
Re: Nicer anchors
On 12/29/14 5:27 PM, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 01:18:39 UTC, Andrei Alexandrescu wrote: How would that achieve cross referencing? To be clear, what your change does is make links like this work, yes? http://erdani.com/d/phobos-prerelease/std_range_package.html#.RefRange.save (BTW, nice leading dot there...) The toPrettyChars function outputs the fully-qualified name too without needing a script. Look at the Jump to: anchors and compare them: https://web.archive.org/web/20141129100337/http://dlang.org/phobos/std_datetime.html vs. http://dlang.org/phobos/std_datetime.html There is no comparison. It's a shame it took me so long to finish this. Andrei
Re: Worst Phobos documentation evar!
On 28/12/2014 17:11, Nick Treleaven wrote: But for some reason codePoints and codeUnits are in between .encode.3 and .encode.4! I made a start on fixing Walter's points, and fixed the above: https://github.com/D-Programming-Language/phobos/pull/2825
Re: Worst Phobos documentation evar!
On Mon, Dec 29, 2014 at 05:19:27PM -0800, Walter Bright via Digitalmars-d wrote: On 12/29/2014 4:45 PM, H. S. Teoh via Digitalmars-d wrote: [...] But at least you can make it work with LaTeX. Whatcha gonna do with Markdown? Again, I wasn't defending Markdown. Then I'm a bit lost on what the point of complaining about Ddoc is. Are you arguing that Ddoc should implement LaTeX? No, I'm saying that ddoc fails to be either (1) a human-readable source that can also be converted into a nicer format like HTML or LaTeX, or (2) a powerful-enough markup language that encompasses all necessary functionality that HTML/LaTeX/etc. encompass. Apparently point (2) fails by design, since you Andrei repeatedly claim that ddoc should not be too powerful. Point (1) fails because no matter what you do, you still have to insert markup *somewhere*. IOW, it's neither nice enough to be human-readable, nor powerful enough to justify the reduction in readability. The only way to get it right is to turn your ddoc comments into tag soup. Are you seriously suggesting that we have to write ddoc tag soup while coding? Or that we first write in plain text then go back afterwards and wrap every paragraph in $(P ...) macros? The only reason zero source code changes were required, was because the ddoc comments were already written with the requisite tag soup to begin with. Which is OK, if that's the correct way to use ddoc... but in that case, the page on dlang.org that describes ddoc should be revised to not give the false impression that you can just write documentation comments in plain text format and expect to get nice output from it. I think this is an unfair critique. The blank lines separating paragraphs work fine. They certainly do not. Consider this: First section heading: Passing in a forward range that doesn't have .length may trigger some unexpected side effects. Some other description goes here. Second section heading: More descriptions follow here. The correct XHTML markup would be something like this: h2First section heading:/h2 pPassing in a forward range that doesn't have .length may trigger some unexpected side effects./p pSome other description goes here./p h2Second section heading/h2 pMore descriptions follow here./p Now consider the structure of the input, as understood by ddoc: $(HEADING First section heading:) Passing in a forward range ... side effects. $(BLANKLINE) Some other description goes here. $(HEADING Second section heading:) More descriptions follow here. How do you get from this structure, to the structure of the XHTML markup above? You can't. You *can* hack it so that p is inserted by $(HEADING), and $(BLANKLINE) prepends /p, and $(BLANKLINE) expands to /pp, but this will fail at the transition to the second heading: the second paragraph won't be closed. Unless you also prepend /p in $(HEADING), but then the first heading will acquire an extraneous /p, which breaks the markup. Things get worse if you now try to insert code blocks between paragraphs, or paragraphs within quoted blocks. Basically, the structure of $(BLANKLINE) does not perfectly align with tag boundaries, therefore no hack will cover all possible cases. The XHTML output will be malformed. Basically, $(BLANKLINE) only works if you use br/ for paragraph breaks, but that screws up CSS styling when you actually want semantically-tagged paragraphs. Using blank lines to separate paragraphs would be fine, *if* ddoc processes them internally and wraps paragraphs in $(P...) automatically instead of inserting $(BLANKLINE). However, currently it doesn't. And I am loathe to change this because the PR will inevitably get rejected, since it will break every ddoc macro set that relies on $(BLANKLINE). Ddoc is not intended to be LaTeX. That it can't do everything a professional typesetting language can is not remarkable, no other markup language can, either. The problem with this, is that ddoc is imposed upon all D users. It tries to be readable, but fails to be beyond the most trivial of cases. Things like embedded code blocks and section headings have special meaning, and have a nice human-readable input syntax, but other common constructs such as lists and tables require ugly macro syntax. I'd rather that macro syntax is either used *everywhere* (make it a full-fledged markup language) or nowhere (make it a fully human-readable language), but what we have now is a halfway job. And then, having included macros, which are deemed necessary, it doesn't go far enough either -- certain things (like autoindexing symbols in a module for making a table of contents, for example) aren't possible without lots of manual work and duplication. There are no capabilities for working with the text itself -- like capitalization so that you can use
Re: Worst Phobos documentation evar!
On Mon, Dec 29, 2014 at 05:45:08PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 12/29/14 3:47 PM, H. S. Teoh via Digitalmars-d wrote: On Mon, Dec 29, 2014 at 11:12:54PM +, Adam D. Ruppe via Digitalmars-d wrote: On Monday, 29 December 2014 at 23:11:09 UTC, Walter Bright wrote: $(TROW all , `all!a 0([1, 2, 3, 4])` returns `true` ) Would that still work if the first column was something like (0,0) - including a comma? I've advocated nicer macros before, ddoc's recursive expansion makes for a lot of nice options, but the comma being a separator kinda worries me. We've already had to resort to $(COMMA) hacks to work around comma issues in Phobos docs. :-( That's to be expected from any macro system. Not to mention that as it stands, ddoc is only really convenient for HTML output; while it's certainly *possible* to target it for non-HTML output, it's a pain. Take LaTeX, for example. I have successfully generated LaTeX from dlang.org and phobos. Of what quality? Have you actually looked at the LaTeX output to see if it's actually correct? I doubt it's actually 100% correct. LaTeX is quite sensitive in some places to extra spaces, or special ways of writing certain text elements. If these details are not taken care of, sure it will still produce output, but there will be little niggling problems sprinkled throughout -- lines that don't line up properly, words that aren't spaced properly, etc.. You have things like Mr.\ So-and-so (i.e., backslash followed by a single space) for inserting space of the appropriate width after a period (.) that doesn't end a sentence, where a normal . would introduce end-of-sentence spacing. The only way to fully support this in ddoc is to use $(DOT) or some such hack instead of writing a literal .. Or take the various dashes: -- for ndash, --- for mdash in LaTeX, but ndash; or mdash; for HTML, respectively. Again, the only way to correctly support this in ddoc is to define $(MDASH) and $(NDASH) macros. And what's the problem? This is exactly right, and fine. A macro system supports any formatter, present or future. One that's based on tricks needs to add a new trick for each formatter idiosyncrasy. So we should stop the false advertisement that ddoc input is supposed to be human readable, because it is not. So instead of writing dashes in your ddocs, you now have to write the much more verbose and far uglier $(MDASH) and $(NDASH). But it gets worse. No it does not get worse. That's pretty much it. Certain character sequences in LaTeX need to be escaped; for example $ needs to be written as \$, whereas it can appear literally in HTML. Again, the only solution is $(DOLLAR). Yah, as I said that's pretty much it. You need to encapsulate special stuff in macros, which is all uniform and simple. Yes, and the system degrades into something no better than writing raw HTML or LaTeX, when every other element in your text is special stuff. Do you seriously believe that the . in Mr. So-and-So is special stuff? And what if another formatter requires special markup for - because it has special meaning? So now, a simple string like: Mr. So-and-So must be written as: Mr$(DOTSPACE)So$(HYPHEN)and$(HYPHEN)So Which is OK if that's the way things are intended to work, but we should seriously stop selling ddoc as human readable because at this point, it most certainly is not. Ditto for opening/closing quotation marks, which are `` and '' in LaTeX, and ldquo; and rdquo; in HTML. And non-breaking space, which is ~ in LaTeX, and nbsp; in HTML. So now, what was originally an easily-readable documentation comment: Returns: A range of dollar amounts -- if the input is $100 or more, as stated in Dr. Watson's A One specs; otherwise an empty range. becomes this monstrosity: Returns: A range of dollar amounts$(MDASH)if the input is $(DOLLAR)100 or more$(COMMA) as stated in Dr$(DOTSPACE)Watson's $(RDQUO)A$(NBSP)One$(LDQUO) specs; otherwise an empty range. That's an extreme example. BTW it doesn't look much worse than TDPL's source. [...] Yes, and therefore we should stop selling ddoc as a human-readable input format, since the above example is anything but. T -- Caffeine underflow. Brain dumped.
Re: Nicer anchors
On Tuesday, 30 December 2014 at 18:00:38 UTC, Andrei Alexandrescu wrote: Look at the Jump to: anchors and compare them: Ah, I was looking in completely the wrong place and with javascript disabled nothing was there anyway. Well, yeah, that's a step up from where it was. Not where it should be yet though, I think a list or table that gives a summary would be the next nice step.
Re: Nicer anchors
On Tue, Dec 30, 2014 at 09:55:17AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 12/30/14 8:59 AM, Nick Treleaven wrote: On 30/12/2014 02:18, Vladimir Panteleev wrote: I'm not sure using numbers to distinguish overloads is a good idea. Such links would break easily. Note: that isn't part of Andrei's pull. Yah, I was surprised when I saw'em. Using numbers is the only workable way, other schemes would also break easily, probably moreso. I implemented it so that ditto overloads don't get a separate number, to avoid some breakage when adding dittos. Agreed. I think the best solution is to simply group overloads together. They already do related things in any given module, so consolidating documentation makes sense anyway. [...] Note that consolidating docs for overloads doesn't work as well as it should, due to: https://issues.dlang.org/show_bug.cgi?id=13270 T -- Customer support: the art of getting your clients to pay for your own incompetence.
Re: Worst Phobos documentation evar!
On Tue, Dec 30, 2014 at 03:20:30PM +, Adam D. Ruppe via Digitalmars-d wrote: On Tuesday, 30 December 2014 at 01:50:01 UTC, ketmar via Digitalmars-d wrote: D documentation WILL be bad until ddoc will start to understand some markdown-like mostly macro-free markup language. I honestly don't think the macros are the biggest problem though. I think a bigger deal is the lack of overviews. Yeah, one of the most glaring defects of ddoc is the inability to generate tables of contents and/or indices. This forces you to manually maintain TOCs, navigation bars, etc., which is a royal pain and prone to quickly falling out-of-date as the code changes. There have already been a number of Phobos PR's that have slipped through without proper updating of the manually-maintained tables of links at the top of the module docs. Being able to automate this, or at least give a compiler warning when things don't match up, would be GREATLY appreciated. Take a look here: http://dlang.org/phobos/std_algorithm.html There's some overview, and even a couple links. But the point about opaque types that are supposed to just work isn't easy to find. Contrast it to what Microsoft wrote up for Windows: http://msdn.microsoft.com/en-us/library/ms713499%28v=vs.85%29.aspx There's conceptual overviews, real-world examples, and the references (which link back to the relevant concepts and examples). std.algorithm could mention the concept of laziness, show examples of the opaque functions, have examples of the common (like seriously one of the most frequently asked questions I've seen) how do I turn it into an array?, or show/explain how and why to avoid that. That's mostly plain text that could be written up in the module explanation or as a separate page. I think that's more important than what macros are used. PR, please. ;-) This is a lack in content, that no macro system can make up for, as you said. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 14:54:37 + Kiith-Sa via Digitalmars-d digitalmars-d@puremagic.com wrote: 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 that's great, but it's not built-in. i can't tell about other people, but i for myself tend to ignore any external documentation generation tool. if it is not with compiler, it's nonexistent for me. but thanks for your work, it's much better to have separate tool than to have none. ;-) signature.asc Description: PGP signature
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 13:18:46 UTC, Russel Winder via Digitalmars-d wrote: XeLaTeX is incorrectly disliked by far too many people Remind me what makes XeLaTex distinct. I recall using it as a convenient way to allow (i) utf8 input and (ii) graphics of any kind (PNG, JPEG, PDF, EPS all mixed in one document), but I'm not sure I see its relevance here.
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 15:20:30 + Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 30 December 2014 at 01:50:01 UTC, ketmar via Digitalmars-d wrote: D documentation WILL be bad until ddoc will start to understand some markdown-like mostly macro-free markup language. I honestly don't think the macros are the biggest problem though. I think a bigger deal is the lack of overviews. but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. sure, markdown will not magically solve other problems, but at least it will remove one of the annoyances, which is good in itself. signature.asc Description: PGP signature
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 13:08:28 + via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 30 December 2014 at 05:36:47 UTC, Andrei Alexandrescu wrote: That should be possible (probably after a few improvements). I'm working on a few templates for alternate formats including LaTeX, plain text, and well, now json. -- Andrei Would it not be easier to just do a raw convert to XML and use XSLT to transform into other formats? and drop Ddoc completely, as if it is required an external tool to get something readable, the whole point of built-in documentation generator is lost. signature.asc Description: PGP signature
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 13:18:05 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: Markdown is inadequate for more than single page HTML which is exactly what API reference documentation is! a list of functions with explanations, some samples and a brief overview. this is why markdown-like language is a good choice. stop writing Charles Dickens' novels in source code, please! ;-) signature.asc Description: PGP signature
Re: Any LaTeX expers n da house?
On Tuesday, 30 December 2014 at 18:04:06 UTC, Andrei Alexandrescu wrote: With https://github.com/D-Programming-Language/dlang.org/pull/736, beautiful PDF generation via LaTeX is now possible. There are, of course, many details to tend to. For starters, currently the doc is overly sparse, which makes it large (520 pages). But the basic framework is in place and works. Who would want to give it a shot at beautifying it? Andrei cool I love Latex :-)
Re: http://wiki.dlang.org/DIP25
On Tue, 30 Dec 2014 07:14:24 -0500
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
But I agree. The problem is, most times, you WANT to ensure your code is
@safe pure nothrow (and now @nogc), even for template functions. That's
a lot of baggage to put on each signature. I just helped someone
recently who wanted to put @nogc on all the std.datetime code, and every
signature had these 4 attributes except a few. I tried to have him put a
big @safe: pure: nothrow: @nogc: at the top, but the occasional
exceptions made this impossible.
It's unfortunate we couldn't start with these being the defaults, and
then add the occasional @system, @unpure, and @throws where appropriate.
Some mechanism of aliasing attribute combinations is itching to get done :)
or at least the way to undo some attributes. we can undo @safe,
but what about notrhow? @nogc? const? and, by the way, final
and static!
it's very handy to write something like this:
final:
nothrow:
@nogc:
void foo () { ... }
...
// and ocasionally we need this:
virtual bar () throw @gc { ... }
// and go on with 'final nothrow @nogc'
...
sure, we can move `bar` to another place, or make ugly nestes {}
blocks, or invent some other workarounds. but they are still
workarounds, and this frustrates me alot. if we have a way to make
something default (`final:`), we MUST have a way to cancel that
defaults both temporary and permanently.
another nice D feature that is half-done.
signature.asc
Description: PGP signature
Re: version(assert) defined variables
On Tue, 30 Dec 2014 14:07:41 +0200
Shachar Shemesh via Digitalmars-d digitalmars-d@puremagic.com wrote:
Hi all,
Please consider the following program:
int main()
{
version(assert) int var;
assert(var == 0);
return 0;
}
When compiled with dmd test.d, it passes without a problem. When
compiled with dmd test.d -release, it produces the following error:
test.d(5): Error: undefined identifier var
This makes no sense. In order to make the program compile, I need to do
the (quite nonsensical):
version(assert) assert(var == 0);
Is this on purpose?
of course. D does exactly what you tell it to do. `assert()` is not a
kind of macro, so it MUST compile, whether compiler will generate the
code for it later or will just drop it. i.e. it must be correct and
pass all semantic analysis phases and symbol resolving phases.
please, remember, that there is NO c-like macros in D. just don't
expect something to simply ignore it's input. this is true for
`version` blocks too: ignored `version` block must not confuse
parser. only parser this time, but you still can't throw arbitrary
nonsence with unbalanced parens there and expect the code to compiles
ok.
signature.asc
Description: PGP signature
Re: Worst Phobos documentation evar!
On 12/30/14 3:57 PM, ketmar via Digitalmars-d wrote: On Tue, 30 Dec 2014 13:18:05 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: Markdown is inadequate for more than single page HTML which is exactly what API reference documentation is! a list of functions with explanations, some samples and a brief overview. this is why markdown-like language is a good choice. stop writing Charles Dickens' novels in source code, please! ;-) Yes, exactly. If you need to add special HTML beyond what Markdown offers you, then you are doing it wrong. My question is: why D docs need more that the basics?
It is happening again!
Be afraid. Be very afraid. DConf 2015 is coming. https://github.com/D-Programming-Language/dconf.org/pull/30 -- Andrei
Re: Worst Phobos documentation evar!
On 12/30/14 10:19 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Dec 29, 2014 at 05:45:08PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 12/29/14 3:47 PM, H. S. Teoh via Digitalmars-d wrote: On Mon, Dec 29, 2014 at 11:12:54PM +, Adam D. Ruppe via Digitalmars-d wrote: On Monday, 29 December 2014 at 23:11:09 UTC, Walter Bright wrote: $(TROW all , `all!a 0([1, 2, 3, 4])` returns `true` ) Would that still work if the first column was something like (0,0) - including a comma? I've advocated nicer macros before, ddoc's recursive expansion makes for a lot of nice options, but the comma being a separator kinda worries me. We've already had to resort to $(COMMA) hacks to work around comma issues in Phobos docs. :-( That's to be expected from any macro system. Not to mention that as it stands, ddoc is only really convenient for HTML output; while it's certainly *possible* to target it for non-HTML output, it's a pain. Take LaTeX, for example. I have successfully generated LaTeX from dlang.org and phobos. Of what quality? Excellent. Have you actually looked at the LaTeX output to see if it's actually correct? Of course. I doubt it's actually 100% correct. It is. https://github.com/D-Programming-Language/dlang.org/pull/736. Destroyed? Andrei
Re: Worst Phobos documentation evar!
On 12/30/14 10:10 AM, H. S. Teoh via Digitalmars-d wrote: Using blank lines to separate paragraphs would be fine,*if* ddoc processes them internally and wraps paragraphs in $(P...) automatically instead of inserting $(BLANKLINE). However, currently it doesn't. And I am loathe to change this because the PR will inevitably get rejected, since it will break every ddoc macro set that relies on $(BLANKLINE). I'd pull it, and I think it can work alongside BLANKLINE. -- Andrei
Re: Nicer anchors
On 12/30/14 10:24 AM, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 18:00:38 UTC, Andrei Alexandrescu wrote: Look at the Jump to: anchors and compare them: Ah, I was looking in completely the wrong place and with javascript disabled nothing was there anyway. Well, yeah, that's a step up from where it was. Not where it should be yet though, I think a list or table that gives a summary would be the next nice step. Then DO IT. https://www.youtube.com/watch?v=JoqDYcCDOTg -- Andrei
Re: Worst Phobos documentation evar!
On 12/30/14 10:35 AM, H. S. Teoh via Digitalmars-d wrote: PR, please.;-) This is a lack in content, that no macro system can make up for, as you said. I've been long hoping for this insight to occur in this thread. -- Andrei
Re: Any LaTeX expers n da house?
On 12/30/14 11:03 AM, bioinfornatics wrote: On Tuesday, 30 December 2014 at 18:04:06 UTC, Andrei Alexandrescu wrote: With https://github.com/D-Programming-Language/dlang.org/pull/736, beautiful PDF generation via LaTeX is now possible. There are, of course, many details to tend to. For starters, currently the doc is overly sparse, which makes it large (520 pages). But the basic framework is in place and works. Who would want to give it a shot at beautifying it? Andrei cool I love Latex :-) I have https://github.com/D-Programming-Language/dlang.org/pulls on 1-minute auto refresh. -- Andrei
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 18:44:15 UTC, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. Yeah, I see that too; I complain about ddoc as well (though I generally like it, I just wish it encoded the output correctly and had some nicer defaults, but I don't care enough to fight over it) but I don't think it is that big of a block because the hard part is writing the text rather than the formatting.
dconf.org site updates welcome for 2015
Right now it's barebone. Anyone do a take on the 2015 conference logo? -- Andrei
Re: Worst Phobos documentation evar!
On 12/30/14 11:47 AM, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 18:44:15 UTC, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. Yeah, I see that too; I complain about ddoc as well (though I generally like it, I just wish it encoded the output correctly and had some nicer defaults, but I don't care enough to fight over it) but I don't think it is that big of a block because the hard part is writing the text rather than the formatting. Agreed! -- Andrei
Re: Any LaTeX expers n da house?
cool I love Latex :-) I have https://github.com/D-Programming-Language/dlang.org/pulls on 1-minute auto refresh. -- Andrei While you're waiting, would you mind to comment on https://github.com/D-Programming-Language/phobos/pull/2804 ? :-)
Re: Worst Phobos documentation evar!
On 12/30/14 11:51 AM, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 18:38:05 UTC, H. S. Teoh via Digitalmars-d wrote: Yeah, one of the most glaring defects of ddoc is the inability to generate tables of contents and/or indices. Absolutely, though I think this is more of a process thing than a ddoc thing - you could easily enough generate those files in a makefile as part of the build... I've written a program to do this before, but it was years ago and probably doesn't work anymore (i based it on the html output.) Exactly. And TOCs and indexes are generated wildly differently depending on the publishing platform. I don't think ddoc should do that. PR, please. ;-) This is a lack in content, that no macro system can make up for, as you said. I wrote a book, surely that gets me off the hook?! hey i found the time to write a rhyme, but those kind of conceptual things would take a lot of hours probably comparable to the book itself... You're soon to find out that paradoxically writing a book enlists you for more, not less, work. Andrei
Re: Worst Phobos documentation evar!
On Tuesday, 30 December 2014 at 18:38:05 UTC, H. S. Teoh via Digitalmars-d wrote: Yeah, one of the most glaring defects of ddoc is the inability to generate tables of contents and/or indices. Absolutely, though I think this is more of a process thing than a ddoc thing - you could easily enough generate those files in a makefile as part of the build... I've written a program to do this before, but it was years ago and probably doesn't work anymore (i based it on the html output.) PR, please. ;-) This is a lack in content, that no macro system can make up for, as you said. I wrote a book, surely that gets me off the hook?! hey i found the time to write a rhyme, but those kind of conceptual things would take a lot of hours probably comparable to the book itself...
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 19:47:53 + Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 30 December 2014 at 18:44:15 UTC, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. Yeah, I see that too; I complain about ddoc as well (though I generally like it, I just wish it encoded the output correctly and had some nicer defaults, but I don't care enough to fight over it) but I don't think it is that big of a block because the hard part is writing the text rather than the formatting. sure, we need the actual text in the first place. ;-) but making it easier to create and format that text is good too. signature.asc Description: PGP signature
Re: It is happening again!
You wrote Oren in a few places where it should be Orem, I pointed them out in the PR.
Re: Worst Phobos documentation evar!
On 12/30/2014 10:19 AM, H. S. Teoh via Digitalmars-d wrote: Of what quality? Have you actually looked at the LaTeX output to see if it's actually correct? I doubt it's actually 100% correct. LaTeX is quite sensitive in some places to extra spaces, or special ways of writing certain text elements. If these details are not taken care of, sure it will still produce output, but there will be little niggling problems sprinkled throughout -- lines that don't line up properly, words that aren't spaced properly, etc.. Andrei has been using LaTeX for years, and writes his (successful) books with it. You've got a tough slog convincing him he doesn't know his way around it :-) He tried to teach me LaTeX once, but I was a poor student.
Re: It is happening again!
UVU is a nice location for me though because I have a friend who lives right nearby in Lindon! That's realistically *walking* distance and so much less traffic than getting around California. I can prolly make it to the whole thing this year. Facebook had the advantage of being closer to my parents and perhaps some prestige of being the whole Silicon Valley place, but UVU is better in pretty much every other way.
Re: Worst Phobos documentation evar!
On 12/30/2014 10:10 AM, H. S. Teoh via Digitalmars-d wrote: Using blank lines to separate paragraphs would be fine, *if* ddoc processes them internally and wraps paragraphs in $(P...) automatically instead of inserting $(BLANKLINE). However, currently it doesn't. And I am loathe to change this because the PR will inevitably get rejected, since it will break every ddoc macro set that relies on $(BLANKLINE). Ddoc should do the $(P ) thing instead of $(BLANKLINE). The latter is a mistake on my part, as when I originally build Ddoc I had a lesser understanding of what the right output should be. It's a correctable mistake, and (as Andrei suggests) can coexist with BLANKLINE. The problem with this, is that ddoc is imposed upon all D users. It tries to be readable, but fails to be beyond the most trivial of cases. Things like embedded code blocks and section headings have special meaning, and have a nice human-readable input syntax, but other common constructs such as lists and tables require ugly macro syntax. I'd rather that macro syntax is either used *everywhere* (make it a full-fledged markup language) or nowhere (make it a fully human-readable language), but what we have now is a halfway job. Lists and tables are rarely used, and I don't find them unreadable. And then, having included macros, which are deemed necessary, it doesn't go far enough either -- certain things (like autoindexing symbols in a module for making a table of contents, for example) aren't possible without lots of manual work and duplication. There are no capabilities for working with the text itself -- like capitalization so that you can use macros for extracting and placing text snippets in different places, inserting escape sequences for sensitive characters in the target format, extracting symbols to make a table of contents, etc.. This is apparently a deliberate design choice, which makes it feel like we're dangling the enticing capability to be a powerful documentation system, yet we withhold actual text-processing capabilities so that you either have to live with inferior output, or implement custom post-processing tools. Again, it feels like another halfway job, it's neither here nor there. Propose solutions. Your one about $(P ) is a good one.
Re: It is happening again!
On 12/30/14 12:04 PM, Adam D. Ruppe wrote: You wrote Oren in a few places where it should be Orem, I pointed them out in the PR. Thanks! Fixed. -- Andrei
Re: Worst Phobos documentation evar!
On 12/30/2014 7:20 AM, Adam D. Ruppe wrote: std.algorithm could mention the concept of laziness, show examples of the opaque functions, have examples of the common (like seriously one of the most frequently asked questions I've seen) how do I turn it into an array?, or show/explain how and why to avoid that. Yes, better examples of solving real world issues would be better, and is exactly why I did these two documentation examples: https://github.com/D-Programming-Language/phobos/pull/2805 https://github.com/D-Programming-Language/phobos/pull/2806 If you've got ideas for better examples for other functions, please, don't hold back!
Re: Worst Phobos documentation evar!
On 12/30/2014 11:42 AM, Andrei Alexandrescu wrote: On 12/30/14 10:35 AM, H. S. Teoh via Digitalmars-d wrote: PR, please.;-) This is a lack in content, that no macro system can make up for, as you said. I've been long hoping for this insight to occur in this thread. -- Andrei Yup.
Re: Worst Phobos documentation evar!
On 12/30/2014 11:54 AM, Andrei Alexandrescu wrote: You're soon to find out that paradoxically writing a book enlists you for more, not less, work. Great examples are hard to come by. Would you, Adam and Ali be amenable to deriving examples from your books and putting them in the Phobos docs? I've already put one example from my slides into the Phobos docs :-)
Re: Worst Phobos documentation evar!
On 12/30/2014 11:49 AM, Andrei Alexandrescu wrote: On 12/30/14 11:47 AM, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 18:44:15 UTC, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. Yeah, I see that too; I complain about ddoc as well (though I generally like it, I just wish it encoded the output correctly and had some nicer defaults, but I don't care enough to fight over it) but I don't think it is that big of a block because the hard part is writing the text rather than the formatting. Agreed! -- Andrei I agree so strongly that just email me the freakin' text and I'll mark it up and submit it. Ketmar, I expect my email inbox to fill up promptly! :-)
Re: Worst Phobos documentation evar!
On 12/30/2014 10:44 AM, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. sure, markdown will not magically solve other problems, but at least it will remove one of the annoyances, which is good in itself. Come on. An example, for example(!), is just inserting D code between ---, and better examples would be very helpful.
Re: Worst Phobos documentation evar!
On Tue, Dec 30, 2014 at 11:36:16AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 12/30/14 10:10 AM, H. S. Teoh via Digitalmars-d wrote: Using blank lines to separate paragraphs would be fine,*if* ddoc processes them internally and wraps paragraphs in $(P...) automatically instead of inserting $(BLANKLINE). However, currently it doesn't. And I am loathe to change this because the PR will inevitably get rejected, since it will break every ddoc macro set that relies on $(BLANKLINE). I'd pull it, and I think it can work alongside BLANKLINE. -- Andrei How would we make it work alongside BLANKLINE? Define $(P ...) as $(BLANKLINE)$0 ? I'm not sure it will actually be equivalent, though, and might cause some problems with existing ddoc macro sets. Or are you saying emit *both* BLANKLINE and P, and the user simply sets one of them to be a no-op? T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
Re: It is happening again!
On 12/30/2014 12:07 PM, Adam D. Ruppe wrote: UVU is a nice location for me though because I have a friend who lives right nearby in Lindon! That's realistically *walking* distance and so much less traffic than getting around California. I can prolly make it to the whole thing this year. Facebook had the advantage of being closer to my parents and perhaps some prestige of being the whole Silicon Valley place, but UVU is better in pretty much every other way. I'm looking forward to seeing everyone again. Glad you're coming!
Re: Worst Phobos documentation evar!
On 12/30/14 12:31 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, Dec 30, 2014 at 11:36:16AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 12/30/14 10:10 AM, H. S. Teoh via Digitalmars-d wrote: Using blank lines to separate paragraphs would be fine,*if* ddoc processes them internally and wraps paragraphs in $(P...) automatically instead of inserting $(BLANKLINE). However, currently it doesn't. And I am loathe to change this because the PR will inevitably get rejected, since it will break every ddoc macro set that relies on $(BLANKLINE). I'd pull it, and I think it can work alongside BLANKLINE. -- Andrei How would we make it work alongside BLANKLINE? Define $(P ...) as $(BLANKLINE)$0 ? I'm not sure it will actually be equivalent, though, and might cause some problems with existing ddoc macro sets. Or are you saying emit *both* BLANKLINE and P, and the user simply sets one of them to be a no-op? The latter. Continue emitting BLANKLINE but set it to nothing. -- Andrei
Re: It is happening again!
On Tuesday, 30 December 2014 at 19:33:49 UTC, Andrei Alexandrescu wrote: Be afraid. Be very afraid. DConf 2015 is coming. https://github.com/D-Programming-Language/dconf.org/pull/30 -- Andrei http://reddit.com/r/programming/comments/2quko6/dconf_2015_announced_via_a_github_pull_request/
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 12:26:52 -0800
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 12/30/2014 11:49 AM, Andrei Alexandrescu wrote:
On 12/30/14 11:47 AM, Adam D. Ruppe wrote:
On Tuesday, 30 December 2014 at 18:44:15 UTC, ketmar via Digitalmars-d
wrote:
but the unnecessary noisy (and badly documented, that's it)
documentation language surely doesn't add any joy for documentation
writer.
Yeah, I see that too; I complain about ddoc as well (though I generally
like it, I just wish it encoded the output correctly and had some nicer
defaults, but I don't care enough to fight over it) but I don't think it
is that big of a block because the hard part is writing the text rather
than the formatting.
Agreed! -- Andrei
I agree so strongly that just email me the freakin' text and I'll mark it up
and
submit it. Ketmar, I expect my email inbox to fill up promptly! :-)
i'm sux in writing documentation. i'm always explaining the things that
are perfectly clear for everyone and failed to explain the things that
are not so obvious ('cause they are obvious to me ;-). so i doubt that
it even pass spamcheck.
besides, if i start to do some real work, i will not have enough time
to write my rants here!
signature.asc
Description: PGP signature
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 12:24:13 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/30/2014 11:54 AM, Andrei Alexandrescu wrote: You're soon to find out that paradoxically writing a book enlists you for more, not less, work. Great examples are hard to come by. Would you, Adam and Ali be amenable to deriving examples from your books and putting them in the Phobos docs? I've already put one example from my slides into the Phobos docs :-) this is a great idea, i think! maybe we can even add a links to Ali and Adam books, so people can find those boox just by reading the Phobos documentation? signature.asc Description: PGP signature
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.
Re: http://wiki.dlang.org/DIP25
On Monday, 29 December 2014 at 20:42:37 UTC, Dicebot wrote: On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer wrote: But this precludes doing anything with a mutable t inside foo, since inout means const within the function. Hm, yes, this is indeed quite the problem. I have totally forgot that compiler has no means of figuring out which invocation of inout is currently used. But something very similar feels necessary to me. There is constness, lifetime, purity - inventing new dedicated keyword for each case does not feel like scaling approach. Especially when existing one is named so generic. I've been pondering this for a while, maybe someone with a better theoretical foundation has an answer... These concepts you mention (I'd add type erasure, because that's what `inout` is currently about) are inter-connected and have some overlap with each other. But at the same time, they are still separate concepts. Do you think they are just aspects of one all-encompassing Grand Unified Concept? Because if they turn out to be fundamentally separate, they are better treated as such, instead of mixing them up. Dedicated keywords may be the way to go if this is the case. (From what I've seen so far, I think they are indeed separate, but who knows?) In general, I get the impression from both DIP25 and DIP69 that both are motivated by minimizing the change to the existing language, instead of looking for the most powerful solution (that may have other use-cases besides the ones under consideration). I.e., instead of asking which concepts are behind the problem in question, how these concepts could be expressed in an ideal world, and then making compromises to fit them into D, it seems like we're starting with some premises (as few changes as possible, no type modifiers), and then look for a solution that needs to sacrifice the smallest number of use cases to stay within the constraints. This is particularly bad if our premises are going against the nature of the problem we want to solve, because then we are guaranteed to get a bad solution.
Re: Worst Phobos documentation evar!
On Tue, 30 Dec 2014 12:25:19 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/30/2014 10:44 AM, ketmar via Digitalmars-d wrote: but the unnecessary noisy (and badly documented, that's it) documentation language surely doesn't add any joy for documentation writer. sure, markdown will not magically solve other problems, but at least it will remove one of the annoyances, which is good in itself. Come on. An example, for example(!), is just inserting D code between ---, and better examples would be very helpful. ah. it's incredibly hard to make a good example. yet i hope to gather some examples soon, as it is possible that i will train some mates in D. i will consider to look what parts of documentation are hard for 'em and what examples i will devise to explain the things, and then i will try to submit some ERs. signature.asc Description: PGP signature
Re: http://wiki.dlang.org/DIP25
On 12/29/14 5:02 PM, Manu via Digitalmars-d wrote: On 30 December 2014 at 01:52, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/29/14 2:58 AM, John Colvin wrote: On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote: There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks. Andrei But (one of) his point(s) is that the choice between type qualifier and storage class directly impacts his work. Why shouldn't a user express such a point? Making that point is fine so long as the costs are discussed alongside with the applicability to one particular task. -- Andrei It's not one particular task. It is the common theme for almost all ref related problems (other than rvalue-ref, which is just arbitrarily rejected currently). Not arbitrary at all. The problem with binding rvalues to ref is that subsequently the ref may escape the scope. DIP25 would not have been possible if rvalues bound to ref. I'm trying to raise that topic for discussions, but nobody wants to talk about it, and would rather focus on patches instead. I don't know exactly where ref as type constructor would lead. That would imply you'd have more restraint in pushing it. Sure, it would be complex no doubt, but not necessarily any more or less complex than the awkward network of edge cases we're trying to deal with in these discussions currently. My feeling is, all these discussions are essentially arguing an *extremely* complex suite of language patches. I'm interested in considering the root problem for contrast... I think we'd find ourselves in a position with a lot less edges as result. I think you are wrong about this. Andrei
Re: Worst Phobos documentation evar!
On 12/30/14 1:02 PM, ketmar via Digitalmars-d wrote: On Tue, 30 Dec 2014 12:24:13 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/30/2014 11:54 AM, Andrei Alexandrescu wrote: You're soon to find out that paradoxically writing a book enlists you for more, not less, work. Great examples are hard to come by. Would you, Adam and Ali be amenable to deriving examples from your books and putting them in the Phobos docs? I've already put one example from my slides into the Phobos docs :-) this is a great idea, i think! maybe we can even add a links to Ali and Adam books, so people can find those boox just by reading the Phobos documentation? Define we :o). More to come. -- Andrei
Re: http://wiki.dlang.org/DIP25
On 12/29/14 4:40 PM, Manu via Digitalmars-d wrote: On 29 December 2014 at 14:13, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 12/28/14 7:40 PM, Manu via Digitalmars-d wrote: I'd also like to know how this will help DIP69? Just takes the entire ref handling out of the equation. Then DIP69 seems to lose all purpose? The whole thing is about safer indirections. DIP69 allows defining entire variables with scope, something DIP25 does not address (but helps enforcing safety for). I was giving a context with vibe.d, but I think they key take-aways were: First-impressions; in our case, that was Windows environment setup, but the point should be taken generally, and that includes IDE integration. The effect of a poor experience here is eroding user confidence before they've even written a single line of code. Expectations are high, other programming communities are nailing this. Debugging was the biggest issue, and turned out to be the dealbreaker. We couldn't get behind something that we were unable to fix if we have to. (I say 'we', meaning the general office perception, and that perception was definitely coloured by the prior experiences re; first-impressions) Also documentation received a lot of criticism from the new-users, although I didn't identify it as a deal-breaker. I experienced this same frustration myself years ago. It's easy to address, I just wanted to demonstrate importance. Trust me that these guys were REALLY excited to try out D when we got started. But their confidence was eroded very quickly by these factors in aggregate. I think D will get another shot with this lot at some later stage when demonstrable progress has been made. Yah, I hear ya. We need to muster talent and funds to make all that happen. Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time. I've already argued against this assertion, because it got kind of aggressive. I was just reporting a case-study. People can do whatever they want, I'm only trying to reaffirm the reality of the importance of the same stuff that I've been going on about since the day I showed up here. There has been really great improvement, and we're getting awfully close to the line, but we're still just a little way short. It's a shame, because that boring stuff that nobody is interested in working on is inhibiting people from getting amongst the cool stuff that's going on here. Yah, and I used to somehow consider the community was at fault about it. There is something wrong when people don't have the time to contribute because they're too busy arguing in the forums - even the most trivial matters that would literally take vastly shorter time to actually fix. Then I thought it might be a failure of leadership: it's Walter and I who do something wrong if we're unable to rally the community into action. I'm open to suggestions on how to do better going forward. Andrei
