Re: DConf Lightning talk submissions
On 4/20/2016 5:08 AM, Atila Neves wrote: I have an idea already, are they being accepted or only in Berlin? Since we may get to 150 people attending, we have to be a little more organized about this than usual :-) An awful lot of the attendees have names I don't recognize, so they may not be regular readers of the forum. Hence it would be unfair to have signups here. Probably what's best would be to have a signup sheet at the conference. Please remind me if I forget!
Re: Gnome Builder IDE
On Wed, 2016-04-20 at 17:21 +, Karabuta via Digitalmars-d wrote: > […] > > Works well for Fedora 23 in software centre. I will recommended > Fedora 24 for 3.20 I have submitted a bug report for the failure on Fedora Rawhide. -- 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 signature.asc Description: This is a digitally signed message part
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: ## How complete are the free compilers? ## Why is every D compiler shipping an own version of Phobos? These two can be answered at once. LDC and GDC share the same frontend code as DMD, but not the glue layer and backend (don't worry, it's only the DMD backend that has the more restrictive licence). Language and library development happens in DMD and with regard to DMD's current capabilities. Changes to DMD and druntime often require effort to port to LDC and GDC, due to the different backends. So an LDC or GDC release is complete w.r.t. a given past DMD version, but new features may have been added in more recent DMDs. The constraints on shipping a shared phobos between them: ABI compatibility: we don't have it, even across compiler versions It would hold back phobos development (e.g. "you can't do that, because GDC doesn't support it yet") You would still need to ship a separate runtime for each compiler, so you don't really gain anything.
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^). Is performance of the outputted code a criterium? Or the number of supported architectures?
Re: final switch and straight integers
On Wednesday, 20 April 2016 at 17:42:03 UTC, Basile Burg wrote: On Wednesday, 20 April 2016 at 10:19:17 UTC, Dominikus Dittes Scherkl wrote: Anyway, something need to be changed. a) allow Range Cases (nice for ints but bad idea for enums) b) require also non-enum types to explicitly state all cases (bad idea for any multi-byte type, even near useless for single bytes) c) forbid other types than enum in final switch I strongly vote for (c). A good `int` value for a variable `int x` can be enforced (min(), max(), clamping, warping, etc) **before** a final switch(x). No, because final switch requires you to enumerate all possible cases. If c) is done then the compiler in this cas would disallow something that's completly safe (generally speaking I mean, here safe == no SwitchException possible). Why would you ever want to use final switch on int? Why not simply use the normal switch? Especially if you enforced a useful range with min(), max(), etc. would it not be better to do the remaining cases manually? (or even do the range check in the default case?)
Re: std.experimental.allocator.make should throw on out-of-memory
On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow wrote: I'd say either you specify the amount of retries, or give some amount that would be acceptable for some background program to retry for. Say, 30 seconds. Would that actually be more helpful than simply printing an OOM message and shutting down / crashing? Because if the limit is 30 seconds *per allocation* then successfully allocating, say, 20 individual objects might take anywhere between 0 seconds and almost (but not *quite*) 10 minutes. In the latter case the program is still making progress but for the user it would appear frozen.
Re: Compiling with -profile=gc makes program crash - why?
On Wednesday, 20 April 2016 at 22:31:31 UTC, Ivan Kazmenko wrote: On Wednesday, 20 April 2016 at 22:27:36 UTC, Ivan Kazmenko wrote: I'm trying to use DMD option "-profile=gc". With this option, the following simple program crashes with 2.071.0 down to 2.069.0 but still works on 2.068.2. The command line is "dmd -g -profile=gc prfail1.d" on Windows (compiled to 32-bit by default). Ouch, meant to post to D.learn. Sorry! Well, perhaps no point in reposting now. You are using "spawn". So it is a multithreaded program. -profile=gc doesn't work with multithreadd programs. Always creates problems.
Re: [PRs] How to update on Github
On Tuesday, 19 April 2016 at 13:34:24 UTC, John Colvin wrote: On Tuesday, 19 April 2016 at 13:05:35 UTC, tcak wrote: I would recommend making a copy of the whole repository locally before any of that just in case you mess something up, at least while you're not as confident with git. Isn't it enough to just: git branch before-rebase (You can also add -f to replace an existing backup branch).
Re: about destroy and delete.
On Wednesday, 20 April 2016 at 09:00:41 UTC, Daniel Kozak wrote: On Wednesday, 20 April 2016 at 08:10:15 UTC, Dsby wrote: I see https://dlang.org/deprecate.html#delete ... so, I want to know why don't destroy direct printf ? if you call destroy on struct pointer it is same as assign null to it so destroy(s) is same as s = null; OK it is more like s = (Struct*).init; But if you do (*s).destroy(), it will work (ok it will call destructor two times but thats not error) Or if you use class instead of struct it will works as you expected Thanks for all.
Re: Compiling with -profile=gc makes program crash - why?
On Thursday, 21 April 2016 at 09:23:26 UTC, tcak wrote: I'm trying to use DMD option "-profile=gc". You are using "spawn". So it is a multithreaded program. -profile=gc doesn't work with multithreadd programs. Always creates problems. Humm, when I searched whether it should work, I only found a reassuring post by Walter[1] almost a year ago. The issue tracker does not seem to contain an entry either. Perhaps I should create one, then. [1] http://forum.dlang.org/post/mia2kf$djb$1...@digitalmars.com
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 08:30:59 UTC, John Colvin wrote: On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: ## How complete are the free compilers? ## Why is every D compiler shipping an own version of Phobos? The constraints on shipping a shared phobos between them: ABI compatibility: we don't have it, even across compiler versions It would hold back phobos development (e.g. "you can't do that, because GDC doesn't support it yet") You would still need to ship a separate runtime for each compiler, so you don't really gain anything. Once we have full ABI compatibility we need to make sure we can work with a shared druntime: If an application compiled with compiler A(requiring runtime A) should be able to link with a shared library compiled by compiler B (requiring runtime B) both 'modules' need to use the same runtime => runtime A==B. This is because we can't have two GCs running concurrently (and there's some more low-level stuff). What we need is a defined ABI for druntime. Then one druntime implementation is installed system wide. The implementation can differ (e.g. GDC might use GCC builtins) but the ABI needs to be fixed to make sure every compiler can use the 'system' druntime. Think of libc or libc++ for example: You can't reliably link modules from compilers using different libcs (or you end up with GC proxies and similar hacks). Compiler specific extensions (gcc.builtins, etc) then must be moved to extra libraries (libgdc) (only if they affect the ABI though. gcc.builtins is actually a bad example as it doesn't contain non-extern functions).
Re: DConf 2016 offical presentation template
On Thursday, 21 April 2016 at 00:55:34 UTC, Andrei Alexandrescu wrote: qznc wrote: On Wednesday, 20 April 2016 at 07:53:53 UTC, Benjamin Thaut wrote: Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. My advice for "graphical-design-challenged" presenters would be * If you feel unsure about colors, then don't use them. Black on white is enough. Syntax highlighting might be an exception, but even there black on white might be enough. * Only use one font (including title page, footer, etc). Use some default font (Times New Roman, Arial, etc). * A second font, if you show code. Use a fixed-width font for that. The one you use in your terminal or IDE. * Only use size, bold, and maybe italic for formatting. Do not use underline, small caps, or other fancy stuff. * Use a big font size. * Left align everything. There is no law that you have to center anything. Left align feels more structured, because everything lines up on the left. * Avoid bullet points. Consider "one statement per slide". Consider removing the bullets. * If you have images, make them fullscreen. Fullscreen also applies to diagrams, plots, etc. A quick look through the old dconf videos tells me that for example Walter mostly uses a simple plain black-on-white scheme. However, the slides would benefit from being left-alignment imho. Great tips thanks. I use powerdot. I think a ppt template for beginners would be great. For the emacs users here :) (surely you know this yet) org-mode + org-export allows you to write in a very light markup language and export your work to several formats at once (this includes several html5 backends, beamer backend, etc..). And the editing experience with org-mode is superb, you can collapse all your document, show the section you are working in now, promote/demote headings, move headings (and hierarchical content) up and down with a keystroke, and much, much more. Antonio
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: ## Where should D source-code / D interfaces be put? If I install a D library or source-only module as a distribution package, where should the sources be put? So far, I have seen: * /usr/include/d * /usr/include/dlang/ * /usr/include/d/(dmd|gdc|ldc) * /usr/share/dlang Having one canonical path would be awesome ;-) /usr/include/d or /usr/include/dlang. I prefer /usr/include/d as it's shorter, but the important point is that we need to decide on a common standard. You currently can't install druntime or phobos headers in this directory, as each compiler will have slightly modified versions and then you end up with /usr/include/d/(dmd|gdc|ldc). But all other library headers should be shareable between compilers and can be placed in /usr/include/d. (This might even work for phobos, I don't think we have many compiler specific changes there. But then you need to use the same frontend version for all compilers.) You can only install headers for one library version with this approach! A versioned approach is nicer /usr/include/d/libfoo/1.0.0 but requires explicit compiler support and it's unlikely this will happen (or explicit dub support and you compile everything through dub). ## dub: Where should dub modules be installed? What does FHS recommend in this case? If you only keep headers/sources you could install into /usr/include. Otherwise you probably need /var/cache or /var/lib or somehting like that. If you split packages you could use the standard /usr/lib* folders but then you need to keep versioned subdirectories to support installing multiple versions. ## dub: How to install modules? Ideally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 ) See above. The main question is: Do you want to have a C style install of one version of a library and have gdc find the includes and library when running gdc main.a -libfoo or do you want dub-style support for multiple library versions which means you need to compile everything through dub. I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface. ++ Aside from these things, there are also some other things which would be very useful: ## Shared library support in all compilers This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible.
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote: I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface. We could probably also provide a small wrapper tool for this: pkgdc gdc -use=libfoo:1.0.0 -other -gdc-args pkgdc dmd -use=libfoo:1.0.0 -other -dmd-args looks up package flags and calls the real compiler with appropriate args. We'd need to define standard for this to be really useful though.
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: ## How complete are the free compilers? This is an important question, because we would need to know whether we can expect D code to be compiled by any compiler, or whether there are tradeoffs that must be made. This question is asking manly how complete LDC and GDC are compared to each other, but also whether both are implementing the D2 specification completely. The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^). Many D users are enthusiasts and push the compiler to its limits, they are usually stuck with DMD (even DMD HEAD sometimes) as it provides the latest fixes. It depends on the coding style, AppStream generator is an example of old good plain business logic one is unlikely to need recent frontend for, but for people writing black magic code a couple of versions lag of free compilers behind DMD is usually a blocker, but whoever uses the free compilers already considers them complete enough for their tasks. Currently LDC looks like the most actively maintained one.
Re: Changelog entries as folder or in wiki
On 4/20/16 11:09 PM, Vladimir Panteleev wrote: On Wednesday, 20 April 2016 at 23:51:41 UTC, Seb wrote: Honestly I prefer 1) - the changelog entry can be approved & checked during the code review on Github and the reviewers can check that such an addition is provided in the PR. On a new release we can just cat the files and remove them - having a short and long description is easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply `cat *.short.dd *.long.dd` to get the full changelog. Btw grouping of similar changes is automatically done by the filenames. Yes. It's not entirely clear how to add things to the changelog, and conflicts are easy to create. I will note that any time a PR fixes an issue (and the issue is simply a bug), there is no need for a changelog entry, as Martin auto-generates a list of all the bugs fixed. It's those complicated changes, or ones that have no issue that need an entry. Agreed. Previewing the changelogs in the doc tester would be nice too (on my list). +1, I have no idea how changelog entries look because I have no idea what the macros do :) Making it easy to auto-generate the changelog from these files would be useful for release time as well. -Steve
Re: final switch and straight integers
On 4/19/16 6:04 PM, Stefan Koch wrote:
On Tuesday, 19 April 2016 at 14:53:18 UTC, Steven Schveighoffer wrote:
or we
should do away with requiring handling all enum cases.
Are you suggesting getting rid of final switch ?
No, what I'm suggesting is that final switch behave consistently. For
integers, final switch doesn't require all possible values be handled,
but for enums it does. One way to make this consistent is to not require
all enums be handled. I'm not suggesting that this is the best answer,
just that it is a possible way to square the inconsistency.
Note that even with final switch on an enum, you have issues, especially
if the enum is considered to be a bitfield:
enum bitfield {
flag1 = 1 << 0,
flag2 = 1 << 1
}
...
void foo(bitfield x)
final switch(x)
{
case flag1:
writeln("flag1");
break;
case flag2:
writeln("flag2");
break;
}
This compiles, but doesn't handle flag1 | flag2. So final switch isn't
helping to cover all cases.
In other cases, you may have a member of an enum that isn't ever used as
a value, but you have to cover it:
enum message {
foo,
bar,
mask = foo | bar
}
final switch is nice when you fit into the use case. When not, you have
to fall back to normal switch. I find many times wanting to use final
switch but having to follow the rules would make it look silly.
-Steve
Throw static exception - Re: std.experimental.allocator.make should throw on out-of-memory
On Wednesday, 20 April 2016 at 19:32:01 UTC, Basile Burg wrote:
a system exist to throw @nogc exceptions that would work in
this case (the message doesn't have to be customized so it can
be static):
@nogc @safe
void throwStaticEx(T, string file = __FILE__, size_t line =
__LINE__)()
{
static const e = new T(file, line);
throw e;
}
Nice idea, I tweaked it a bit to accept custom arguments to T
e.g. a message:
http://dpaste.dzfl.pl/5e58c0142ccd
throw staticEx!(Exception, "Look ma, @nogc exception!");
That works, but I couldn't get the staticEx(string msg) overload
to compile. Anyway, maybe something like this could go in
std.exception?
Re: final switch and straight integers
On 4/20/16 4:23 AM, Johan Engelen wrote:
On Wednesday, 20 April 2016 at 06:36:01 UTC, bearophile wrote:
It's easy to cover all the values in a switch, using ranges.
Not as easy as you would think:
int i;
switch(i) {
case 0: .. case 9:
break;
case 10: ..case 1000:
break;
default:
break;
}
--> Error: had 990 cases which is more than 256 cases in case range
The FE always lowers CaseRangeStatements into a list of CaseStatements,
so LDC currently has the same limitation.
Um... this seems a horrid limitation.
-Steve
Re: DConf 2016 offical presentation template
On 4/20/16 3:53 AM, Benjamin Thaut wrote: Is there a official presentation template for Dconf 2016? If not it would be greate if someone could create one. Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. Kind Regards Benjamin Thaut In my presentation, I just used whatever default Keynote (apple office) used (black background, white text). When I first started writing it, to insert code snippets, I was taking screenshots of my editor to get the syntax highlighting. What turned out to work better, is copying and pasting from a terminal based editor (vim), which copied the font, colors, and formatting. Then the presentation doesn't look pixelated if scaled, and you can edit stuff after the fact (though editing the coloring is difficult, easier to copy and paste again). Just thought I'd post this in case anyone finds it useful. -Steve
Re: Compiling with -profile=gc makes program crash - why?
On Thursday, 21 April 2016 at 09:23:26 UTC, tcak wrote: You are using "spawn". So it is a multithreaded program. -profile=gc doesn't work with multithreadd programs. Always creates problems. Then it would probably help if that is mentioned on this page somewhere. https://dlang.org/dmd-windows.html
Re: std.experimental.allocator.make should throw on out-of-memory
On Thursday, 21 April 2016 at 09:15:05 UTC, Thiez wrote: On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow wrote: I'd say either you specify the amount of retries, or give some amount that would be acceptable for some background program to retry for. Say, 30 seconds. Would that actually be more helpful than simply printing an OOM message and shutting down / crashing? Because if the limit is 30 seconds *per allocation* then successfully allocating, say, 20 individual objects might take anywhere between 0 seconds and almost (but not *quite*) 10 minutes. In the latter case the program is still making progress but for the user it would appear frozen. Good point. Maybe having a global threshold of 30 seconds while it waits and retries every 1/2 second. In 30 seconds a lot can change. You can get gigabytes of memory freed from other processes and jobs. In the end it really depends on the application. A backup utility that you run overnight gives you 8+ hours to do the backup that probably takes up to 2 hours to actually do. On the other hand no one (sane anyways) wants to wait if they are actively using the application and would prefer it to die quickly and restart it when there's fewer demands on the system.
Re: std.experimental.allocator unittest failures on Win32
On Wednesday, 20 April 2016 at 13:43:59 UTC, Vladimir Panteleev wrote: Hi, When I attempt to run the Phobos tests on my machine, I get the following: [...] Should anyone run into this, these disappeared after updating snn.lib.
Re: final switch and straight integers
On Thursday, 21 April 2016 at 12:45:34 UTC, Steven Schveighoffer
wrote:
On 4/19/16 6:04 PM, Stefan Koch wrote:
On Tuesday, 19 April 2016 at 14:53:18 UTC, Steven
Schveighoffer wrote:
or we
should do away with requiring handling all enum cases.
Are you suggesting getting rid of final switch ?
No, what I'm suggesting is that final switch behave
consistently. For integers, final switch doesn't require all
possible values be handled, but for enums it does. One way to
make this consistent is to not require all enums be handled.
I'm not suggesting that this is the best answer, just that it
is a possible way to square the inconsistency.
Note that even with final switch on an enum, you have issues,
especially if the enum is considered to be a bitfield:
enum bitfield {
flag1 = 1 << 0,
flag2 = 1 << 1
}
`final enum` was suggested for strict enums that can't be used as
flags. If we had that, we could phase out `final switch` on
non-strict enums.
Re: std.experimental.allocator.make should throw on out-of-memory
On Thursday, 21 April 2016 at 13:42:50 UTC, Era Scarecrow wrote: On Thursday, 21 April 2016 at 09:15:05 UTC, Thiez wrote: On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow wrote: I'd say either you specify the amount of retries, or give some amount that would be acceptable for some background program to retry for. Say, 30 seconds. Would that actually be more helpful than simply printing an OOM message and shutting down / crashing? Because if the limit is 30 seconds *per allocation* then successfully allocating, say, 20 individual objects might take anywhere between 0 seconds and almost (but not *quite*) 10 minutes. In the latter case the program is still making progress but for the user it would appear frozen. Good point. Maybe having a global threshold of 30 seconds while it waits and retries every 1/2 second. In 30 seconds a lot can change. You can get gigabytes of memory freed from other processes and jobs. In the end it really depends on the application. A backup utility that you run overnight gives you 8+ hours to do the backup that probably takes up to 2 hours to actually do. On the other hand no one (sane anyways) wants to wait if they are actively using the application and would prefer it to die quickly and restart it when there's fewer demands on the system. I'm proposing that make throws an exception if the allocator cannot satisfy a request (ie allocate returns null). How the allocator tries to allocate is it's own business; if it wants to sleep (which I don't believe would be helpful outside of specialized cases), make doesn't need to care. Sleeping would be very bad for certain workloads (you mentioned games), so having make itself sleep would be inappropriate.
Re: std.experimental.allocator.make should throw on out-of-memory
On Thursday, 21 April 2016 at 13:42:50 UTC, Era Scarecrow wrote: On Thursday, 21 April 2016 at 09:15:05 UTC, Thiez wrote: On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow wrote: I'd say either you specify the amount of retries, or give some amount that would be acceptable for some background program to retry for. Say, 30 seconds. Would that actually be more helpful than simply printing an OOM message and shutting down / crashing? Because if the limit is 30 seconds *per allocation* then successfully allocating, say, 20 individual objects might take anywhere between 0 seconds and almost (but not *quite*) 10 minutes. In the latter case the program is still making progress but for the user it would appear frozen. Good point. Maybe having a global threshold of 30 seconds while it waits and retries every 1/2 second. In 30 seconds a lot can change. You can get gigabytes of memory freed from other processes and jobs. In the end it really depends on the application. A backup utility that you run overnight gives you 8+ hours to do the backup that probably takes up to 2 hours to actually do. On the other hand no one (sane anyways) wants to wait if they are actively using the application and would prefer it to die quickly and restart it when there's fewer demands on the system. But background processes might run for months, so having a global threshold of 30 seconds combined with a 0.5 second delay between retries may result in too few retries in the long run. So if the retry thing is really the way you want to go you probably need to keep track of how many times you've retried recently, and then slowly forget about those retries as more time passes (time spent waiting for a retry doesn't count). Of course this demands additional bookkeeping, but the overhead should be acceptable: the 'allocation succeeds' happy path doesn't need to know about any of this stuff. But at the end of the day I would expect the user to be much happier if the software simply informs them of insufficient memory. The proposed retry scheme would only really have a positive effect when the system the software runs on spends a significant amount of time flirting with OOM, while never quite reaching it to the point where other applications start crashing. I think this scenario is very rare/unlikely, and if it occurs the user would benefit much more from shutting down some other applications, buying more RAM, or (*shudder*) by allowing swapping. By silently retrying you are effectively denying the user the information they need to solve the actual problem. Meanwhile, on some operating systems (e.g. Linux) the system will happily hand out more memory than it physically possesses, because as long as you don't write to that memory it doesn't need its own page, so allocations will never return null (for some values of 'never', they can still return null if you run out of virtual memory, but on a 64-bit system that will realistically only happen if you specifically write your program to trigger this scenario). Writing to memory can summon the OOM-killer, which will kill processes to satisfy its desire to feast on the bodies of the fallen. On such a systems attempting to defend against allocation returning null seems rather pointless.
Re: Distributor's whishlist and questions for D
Hi, and thanks for your detailed explanations! On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote: On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: [...] You currently can't install druntime or phobos headers in this directory, as each compiler will have slightly modified versions and then you end up with /usr/include/d/(dmd|gdc|ldc). That doesn't seem to be the case for LDC on Debian... It installs Phobos into /usr/include/d/std, which makes GDC go crazy as soon as LDC is installed too. I suspect this is a packaging bug, if so, I'll report a bug against LDC. But all other library headers should be shareable between compilers and can be placed in /usr/include/d. (This might even work for phobos, I don't think we have many compiler specific changes there. But then you need to use the same frontend version for all compilers.) This is probably a very naive question, but: Isn't the D specification finished? If the language is done, why would there be a dependence of Phobos on a specific compiler? Or is this because the new code in Phobos might expose bugs in the compiler itself, which causes these incompatibilities? You can only install headers for one library version with this approach! A versioned approach is nicer /usr/include/d/libfoo/1.0.0 but requires explicit compiler support and it's unlikely this will happen (or explicit dub support and you compile everything through dub). Would be nice, but since we - most of the time - only allow one version of a specific software package to be present in distributions, it isn't a huge issue. ## dub: Where should dub modules be installed? What does FHS recommend in this case? If you only keep headers/sources you could install into /usr/include. By the FHS, /usr/include/d should be okay for headers (well, the spec explicitly says C programming language headers, but well :P). Otherwise you probably need /var/cache or /var/lib or somehting like that. /var/cache and /var/lib are forbidden for distributors, since they contain state information which shouldn't be touched (as always, there are exceptions...). If the dub packages contain architecture-independent stuff only, they need to go to /usr/share/dlang or /usr/include/d, and the shared or static library must go to /usr/lib//. If you split packages you could use the standard /usr/lib* folders but then you need to keep versioned subdirectories to support installing multiple versions. Multiple versions would be a rare event, since no distro package management system allows that (excluding Nix here, which is kind of special). Installing arbitrary arch-specific content into a subdirectory in /usr/lib is fine too, but I doubt that will be necessary... ## dub: How to install modules? Ideally, dub would also have a "dub install" command, to install the binary, "headers (.di)"/sources and data into standard directories on Linux. (reported as https://github.com/dlang/dub/issues/811 ) See above. The main question is: Do you want to have a C style install of one version of a library and have gdc find the includes and library when running gdc main.a -libfoo For plain gdc/ldc, I'd say: yes or do you want dub-style support for multiple library versions which means you need to compile everything through dub. For stuff using dub, I'd say yes to that too ;-) I'd love to have some extended compiler support (so you could simply do gdc -use=libfoo:1.0.0 and this would pick up the correct headers and linker flags). But as some DMD maintainers are opposed to this idea it won't happen. You'll probably always need dub for a 'nice' user interface. ++ Aside from these things, there are also some other things which would be very useful: ## Shared library support in all compilers This is mainly a GDC issue. DMD and LDC support shared libs, although I don't think these libraries are ABI compatible. Sounds more and more like LDC is - at time - the better choice over GDC...
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 11:58:23 UTC, Kagamin wrote:
On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp
wrote:
[...]
Many D users are enthusiasts and push the compiler to its
limits, they are usually stuck with DMD (even DMD HEAD
sometimes) as it provides the latest fixes. It depends on the
coding style, AppStream generator is an example of old good
plain business logic one is unlikely to need recent frontend
for, but for people writing black magic code a couple of
versions lag of free compilers behind DMD is usually a blocker,
but whoever uses the free compilers already considers them
complete enough for their tasks. Currently LDC looks like the
most actively maintained one.
Asgen is super-boring code ;-) Mainly because the task it
performs can be represented without using much black magic. But
still, in order to make it work, I needed to embed a copy of
std.concurrency.Generator in my code, because GDCs Phobos didn't
contain that thing yet (and it's *so* useful!). Basically, the
huge differences in the standard versions is what annoyed me the
most in D, since it also means you can't trust the documentation
much, depending on the compiler you use. For someone new to D,
this is annoying.
LDC also fails to compile asgen:
```
/usr/include/d/std/parallelism.d-mixin-3811(3837): Error:
template core.atomic.atomicOp cannot deduce function from
argument types !("+=")(shared(ulong), int), candidates are:
/usr/include/d/core/atomic.d(178):
core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod)
if (__traits(compiles, mixin("val" ~ op ~ "mod")))
/usr/include/d/std/parallelism.d-mixin-3811(3837): Error:
template core.atomic.atomicOp cannot deduce function from
argument types !("+=")(shared(ulong), int), candidates are:
/usr/include/d/core/atomic.d(178):
core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod)
if (__traits(compiles, mixin("val" ~ op ~ "mod")))
/usr/include/d/std/parallelism.d-mixin-3823(3849): Error:
template core.atomic.atomicOp cannot deduce function from
argument types !("+=")(shared(ulong), int), candidates are:
/usr/include/d/core/atomic.d(178):
core.atomic.atomicOp(string op, T, V1)(ref shared T val, V1 mod)
if (__traits(compiles, mixin("val" ~ op ~ "mod")))
/usr/include/d/std/parallelism.d(3344): Error: template instance
std.parallelism.ParallelForeach!(Package[]) error instantiating
source/engine.d(90):instantiated from here:
parallel!(Package[])
```
while GDC compiles the code flawlessly (LDC previously even
crashed, but that was with the beta version). I will investigate
why this happens now, but it's basically these small things which
make working with D less fun, at least when you want to use a
system without proprietary components.
Re: Compiling with -profile=gc makes program crash - why?
On Thursday, 21 April 2016 at 10:57:12 UTC, Ivan Kazmenko wrote: Humm, when I searched whether it should work, I only found a reassuring post by Walter[1] almost a year ago. The issue tracker does not seem to contain an entry either. Perhaps I should create one, then. [1] http://forum.dlang.org/post/mia2kf$djb$1...@digitalmars.com Issue created: https://issues.dlang.org/show_bug.cgi?id=15947
Re: Distributor's whishlist and questions for D
On Thursday, 21 April 2016 at 09:07:57 UTC, Johan Engelen wrote: On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp wrote: The question here is also, which compiler should be the default (which IMHO would be the most complete, most bug-free actively maintained one ^^). Is performance of the outputted code a criterium? Or the number of supported architectures? The number of supported architectures is at least a criterium for Debian (speed is also important, obviously ^^) - for arch support, one could set a different compiler on different architectures though...
Re: Distributor's whishlist and questions for D
Am Thu, 21 Apr 2016 01:01:01 + schrieb Matthias Klumpp : > Hello! > Me bringing dub to Debian (and subsequently Ubuntu) has sparked > quite some interest in getting more D applications shipped in > Linux distributions. Having been in a similar situation years ago, I can share my experience with packaging Dlang libraries and programs. > ## Why is every D compiler shipping an own version of Phobos? > If one assumes that the D2 language specification is stable, and > D compilers implement it completely, the question is why every > compiler is shipping an own copy of Phobos. This is a major pain, > since e.g. GDCs Phobos is behind what is documented on dlang.org, > but also because the compilers sometimes accidentally use the > "wrong" Phobos version (e.g. GDC trying to use the one of LDC), > leading to breakage. > Also, distributors hate code duplication, so deduplicating this > would be awesome (druntime being compiler-specific makes sense to > me, Phobos not so much...). > It's not an essential thing, but would be quite nice... The compiler devs would need to explain the coupling of druntime and Phobos. What I know is that Dlang's ABI and Phobos' API are still changing. There are at this very moment talks about changing the function name mangling, a deprecation of broken visibility rules and the shared keyword will need a rewrite at some point in the future. In practice you have a different Phobos per compiler and language release. I currently have 9 versions of Phobos installed, most of them in 4 flavors: 32-bit/64-bit, shared and static. > ## Where should D source-code / D interfaces be put? > If I install a D library or source-only module as a distribution > package, where should the sources be put? So far, I have seen: > * /usr/include/d > * /usr/include/dlang/ > * /usr/include/d/(dmd|gdc|ldc) > * /usr/share/dlang > Having one canonical path would be awesome ;-) As explained Phobos is installed in multiple versions, so I mostly used the compilers' defaults. For third party libraries I had the same question and figured the best would be a poll. Since November 2013 over 100 votes were cast with ~2/3 preferring /usr/include/dlang/ over /usr/include/d/: http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527 This is today the de-facto path on Arch and Gentoo at least. > ## dub: Where should dub modules be installed? > ## dub: How to install modules? For packaging purposes I avoided dub in the past as too much of a black box, for the flexibility usually expected on Gentoo. Many packages ship with make files that integrate better with the system's package manager. > ## Shared library support in all compilers +1. For dmd, I changed the default in dmd.conf to link with the shared Phobos. It's been working pretty well since around 2.065 or so. I also install packages like gtkd with .so > ## Stable ABI among compilers I agree with you, but let me add that you need multiple Phobos versions installed in parallel in some cases. You may have an app that depends on a library that doesn't compile with the latest dmd/Phobos. IIRC gtkd for Gtk2 doesn't work on dmd-2.071 any more. -- Marco
Re: Distributor's whishlist and questions for D
Am Thu, 21 Apr 2016 15:34:35 + schrieb Matthias Klumpp : > That doesn't seem to be the case for LDC on Debian... It installs > Phobos into /usr/include/d/std, which makes GDC go crazy as soon > as LDC is installed too. See also: http://forum.dlang.org/post/mailman.1433.1460903305.26339.digitalmars-d-...@puremagic.com -- Marco
Re: Distributor's whishlist and questions for D
> > You can only install headers for one library version with this > > approach! A versioned approach is nicer > > /usr/include/d/libfoo/1.0.0 but requires explicit compiler > > support and it's unlikely this will happen (or explicit dub > > support and you compile everything through dub). > > Would be nice, but since we - most of the time - only allow one > version of a specific software package to be present in > distributions, it isn't a huge issue. For gtkd 2.4.2 and 3.2.3 I have these directories: /usr/include/dlang/gtkd-2 /usr/include/dlang/gtkd-3 It makes sense, since Gtk2 can be installed in parallel with Gtk3 and the major version suffix ensures both packages wont overwrite each other's imports. -- Marco
Re: DConf 2016 offical presentation template
On Wednesday, 20 April 2016 at 20:40:03 UTC, qznc wrote: On Wednesday, 20 April 2016 at 07:53:53 UTC, Benjamin Thaut wrote: Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. My advice for "graphical-design-challenged" presenters would be [snip] Converted this into a blog article: http://beza1e1.tuxen.de/slide_design_programmers.html It even has an image :)
Re: Compiling with -profile=gc makes program crash - why?
On 4/21/2016 8:47 AM, Ivan Kazmenko wrote: Issue created: https://issues.dlang.org/show_bug.cgi?id=15947 Thank you.
Re: Distributor's whishlist and questions for D
Am Thu, 21 Apr 2016 15:34:35 + schrieb Matthias Klumpp : > Hi, and thanks for your detailed explanations! You're welcome :-) > On Thursday, 21 April 2016 at 11:49:13 UTC, Johannes Pfau wrote: > > On Thursday, 21 April 2016 at 01:01:01 UTC, Matthias Klumpp > > wrote: > >> [...] > > > > You currently can't install druntime or phobos headers in this > > directory, as each compiler will have slightly modified > > versions and then you end up with /usr/include/d/(dmd|gdc|ldc). > > That doesn't seem to be the case for LDC on Debian... It installs > Phobos into /usr/include/d/std, which makes GDC go crazy as soon > as LDC is installed too. > I suspect this is a packaging bug, if so, I'll report a bug > against LDC. > IIRC GDC makes sure to install in some lib/gcc directory to avoid such problems. But it's possible ldc defaults to the include directory. As an example, Arch Linux configures all compilers to use /usr/include/dlang&(ldc|gdc|dmd): https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ldc#n37 https://projects.archlinux.org/svntogit/community.git/tree/trunk/folders.diff?h=packages/gdc https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n54 > > But all other library headers should be shareable between > > compilers and can be placed in /usr/include/d. (This might even > > work for phobos, I don't think we have many compiler specific > > changes there. But then you need to use the same frontend > > version for all compilers.) > > This is probably a very naive question, but: Isn't the D > specification finished? If the language is done, why would there > be a dependence of Phobos on a specific compiler? > Or is this because the new code in Phobos might expose bugs in > the compiler itself, which causes these incompatibilities? We only introduce backwards compatible changes, but it's still possible that a new feature will be used in a new phobos version. Most of the time it's some obscure template bug fix which will require a new frontend version. And phobos is often one of the first libraries to use bug fixes or new compiler features. > [...] > > See above. The main question is: Do you want to have a C style > > install of one version of a library and have gdc find the > > includes and library when running gdc main.a -libfoo > > For plain gdc/ldc, I'd say: yes > > > or do you want dub-style support for multiple library versions > > which means you need to compile everything through dub. > > For stuff using dub, I'd say yes to that too ;-) Where do ruby / python package managers install their packages? I guess they're special as they use arch-independent sources? Anyway, for a one-version system wide install standard /usr/include/d and /usr/lib is probably best. I don't know a reasonable location for a dub 'repository' though. > >> ## Shared library support in all compilers > > > > This is mainly a GDC issue. DMD and LDC support shared libs, > > although I don't think these libraries are ABI compatible. > > Sounds more and more like LDC is - at time - the better choice > over GDC... GDC is indeed lagging behind a little bit. We're working on it ;-)
Re: DConf 2016 offical presentation template
On 4/20/2016 12:53 AM, Benjamin Thaut wrote: Is there a official presentation template for Dconf 2016? If not it would be greate if someone could create one. Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. I found this book helpful: http://www.amazon.com/dp/0071636080 once you get past the click-baity title. It's well worth the $2.50 investment, and a quick read. Even if you only get one good idea out of it, it's worth while.
Re: Changelog entries as folder or in wiki
On Thursday, 21 April 2016 at 03:09:43 UTC, Vladimir Panteleev wrote: On Wednesday, 20 April 2016 at 23:51:41 UTC, Seb wrote: Honestly I prefer 1) - the changelog entry can be approved & checked during the code review on Github and the reviewers can check that such an addition is provided in the PR. On a new release we can just cat the files and remove them - having a short and long description is easy too: `mychange.short.dd` and `mychange.long.dd`. One can simply `cat *.short.dd *.long.dd` to get the full changelog. Btw grouping of similar changes is automatically done by the filenames. Agreed. I opened a PR for this - https://github.com/dlang/phobos/pull/4228/files :)
Re: DConf 2016 offical presentation template
On Thursday, 21 April 2016 at 22:37:06 UTC, Walter Bright wrote: On 4/20/2016 12:53 AM, Benjamin Thaut wrote: Is there a official presentation template for Dconf 2016? If not it would be greate if someone could create one. Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. I found this book helpful: http://www.amazon.com/dp/0071636080 once you get past the click-baity title. It's well worth the $2.50 investment, and a quick read. Even if you only get one good idea out of it, it's worth while. I haven't decided on what my presentation will look like yet, but I'll be roughly following the tips here: https://zachholman.com/posts/slide-design-for-developers/ It isn't perfectly applicable to a completely-technical presentation, but the general tips are quite useful (large fonts, easy-to-parse layout, and supporting the presentation rather than _being_ the presentation).
Re: DConf 2016 offical presentation template
On Wednesday, 20 April 2016 at 07:53:53 UTC, Benjamin Thaut wrote: Many programmers (me included) are not good with picking colors and thus presentations usually don't look as good as they could. Ill just leave this here http://i2.wp.com/socialmediaguerilla.com/wp-content/uploads/2013/10/data-ink.gif https://speakerdeck.com/cherdarchuk/remove-to-improve-the-data-ink-ratio
Re: DConf 2016 offical presentation template
On Friday, 22 April 2016 at 00:35:21 UTC, Mithun Hunsur wrote: supporting the presentation rather than _being_ the presentation). Powerpoints have a bad habit of damaging presentations rather than supporting them... I hate slides. Focus on making interesting content and consider doing a hand out with actual details. A slide has less information on it than a tweet perhaps best is to think of it as a series of suggested tweets - brief marketing information rather than anything useful.
Re: DConf 2016 offical presentation template
On Friday, 22 April 2016 at 01:53:02 UTC, Adam D. Ruppe wrote: On Friday, 22 April 2016 at 00:35:21 UTC, Mithun Hunsur wrote: supporting the presentation rather than _being_ the presentation). Powerpoints have a bad habit of damaging presentations rather than supporting them... I hate slides. Focus on making interesting content and consider doing a hand out with actual details. A slide has less information on it than a tweet perhaps best is to think of it as a series of suggested tweets - brief marketing information rather than anything useful. My favorite advice on giving presentations: http://www.cs.berkeley.edu/~jrs/speaking.html Maybe not everything applies to a talk where you will be showing code, but still great advice in my opinion.
