Re: Mobile App STACK4 with a D backend
On Friday, 10 January 2014 at 20:30:34 UTC, John Colvin wrote: I don't think i've ever run anything using unity before. Also, I'm on an Intel AZ-210 so it's x86-android, which probably means quite a few untested corner-cases for unity and other libs. Wow, one of the mythical Android/x86 users running it on their actual phone! Any reason why you chose to buy x86 and how is it running for you? Intel seems to have finally turned the corner with Bay Trail, if the benchmarks are to be believed, and they just showed off some design wins at CES. It'll be interesting to see if they can ever really come back on mobile.
Re: DUB 0.9.21 beta 1
The bug turned out to be me not using importPaths correctly,
so my bad.
On Friday, 10 January 2014 at 18:48:11 UTC, Atila Neves wrote:
I finally got around to cloning the git repo and trying the
latest dub and how dub test would work.
1st of all there is a bug, should I also add it to the issue
tracker on github? In any case, when the default source
directory isn't used but explicitly named in package.json, the
static imports in the autogenerated file don't have the library
name before the modules, i.e. instead of static import
libname.modname the it had static import modname. I created
a git branch for testing purposes and moved my code to
source, deleting importPaths and sourcePaths from the
package.json and the code generation worked with the right
static imports.
The other problem I have for my use case is that, since I'm not
using the built-in unittest blocks for testing, I have testing
code that can't be turned off by omitting -unittest. So far
I've been using rdmd to figure out the test dependencies. With
the actual unit test code in a different directory, dub test
fails with a linker error. I don't know what the easiest way
would be to tell dub to also compile and link a list of
directories. Basically I need not only --main-file but also
something like --extra-dirs=dir1,dir2,dir3.
Atila
What exactly does dub test do? Is it like running rdmd
-main
-unittest foo.d?
It's similar. By default, for library projects, it generates a
maim
module of the form
---
module test_main;
import library_name.main_module;
import std.stdio;
import core.runtime;
void main() { writeln(All unit tests were successful.); }
---
and runs it with build type unittest.
It also supports setting a custom file containing main(), so
that for
example custom unit test runners can be specified and similar
things. In
this case, the generated file looks like this:
---
module test_main;
import library_name.main_module;
import custom_main_module;
---
For packages with only executable configurations it behaves
the same as
dub run --build=unittest.
Re: Call D code from C#
On 1/9/2014 10:38 AM, anthonyb wrote: On Thursday, 9 January 2014 at 17:56:46 UTC, Adam D. Ruppe wrote: On Thursday, 9 January 2014 at 16:15:23 UTC, bearophile wrote: Is QtD not good enough? When I tried it, a while ago, it was completely unusable - random runtime crashes. Which i a real shame...If D was able to access a UI like Qt, it would give a tremendous push to the language. Not being able to use easily some UI from D is holding back many people. I think Qt is the only reason some people prefer C++ even now. I agree UI is an issue. It's kind of a showstopper for me. If I were writing programs for other programmers it wouldn't matter as much, but I write them for normal people and so it has to have a GUI. I realize the first priority is having a standard library, but UI is right up there. I always run into two problems with volunteer open source projects. One, it was probably abandoned some years ago because the developers lost interest and it no longer works. Two, you have to first install the developer's three or four favorite tools before you can build it, some of which may have their own dependencies. Coming from the Windows side this is annoying. I'd prefer to use wxWidgets. Not long ago I spent a day trying to get it to work by just pulling the code into a Visual Studio project (with Visual D) and fixing compilation errors. I got the sample program to run which was encouraging, but it crashed after exit in what looked like the GC so I gave up for now. I may consider doing what you're doing and use C#/.Net framework for UI. Jim
Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
Hi everyone, Just wrote annotated v1.2.7 of Mono-D: http://mono-d.alexanderbothe.com/completion-ldc2-compatibility-dub-fix-v1-2-7 I'm too lazy to mention every part of it again over here - if there are questions: Here, in #d.mono-d, on the blog, on github - you know the usual places where to find me :) Cheers mates, Alex
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Sunday, 12 January 2014 at 23:40:33 UTC, Alexander Bothe wrote: Hi everyone, Just wrote annotated v1.2.7 of Mono-D: http://mono-d.alexanderbothe.com/completion-ldc2-compatibility-dub-fix-v1-2-7 I'm too lazy to mention every part of it again over here - if there are questions: Here, in #d.mono-d, on the blog, on github - you know the usual places where to find me :) Cheers mates, Alex after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... p.s. also, why at first launch it can't just fetch default phobos location for DMD? it's quite annoying adding this paths in settings and it may revolve unaware users from using it(like it was for me about year ago).
Re: Mono-D v1.2.7 - Completion, ldc2 compatibility, dub fixes
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote: On Sunday, 12 January 2014 at 23:40:33 UTC, Alexander Bothe wrote: Hi everyone, Just wrote annotated v1.2.7 of Mono-D: http://mono-d.alexanderbothe.com/completion-ldc2-compatibility-dub-fix-v1-2-7 I'm too lazy to mention every part of it again over here - if there are questions: Here, in #d.mono-d, on the blog, on github - you know the usual places where to find me :) Cheers mates, Alex after about half year i tried it again on OS X, and Mono-D is quite good for writing the code, but... the debug!!11 can we haz some GDB or LLDB(or both :)) support please? it shouldn't be that hard porting linux code to OS X. it may already doing something useful but it simply doesn't start... p.s. also, why at first launch it can't just fetch default phobos location for DMD? it's quite annoying adding this paths in settings and it may revolve unaware users from using it(like it was for me about year ago). It happened to me yesterday as well after the update. Is this some regression? It worked out of the box previously. -- Paulo
Re: Componentizing D's garbage collector
Am 11.01.2014 05:26, schrieb Timon Gehr: On 01/10/2014 09:03 AM, Andrei Alexandrescu wrote: * There will be no possibility to change the type of certain objects once allocated. An allocation for an immutable object cannot e.g. make it later a mutable one. (This is an essential issue with the current allocator, I think.) I assume you are aware that there is implicit casting to immutable upon return from a strongly pure function. What about it? I'd say the easiest way to deal with it is to let the compiler emit a gc_isolatedToImmutable-like call in this case which moves the object from one heap to another, assuming that the language guarantees safety.
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 06:10:41 UTC, Rikki Cattermole wrote: +1 on (potentially) Facebook hiring somebody to work on the toolchain in some form. Would set a good precedence and showing just how committed Facebook is. I don't think anyone would disagree with this. My feeling is with this we could really go far. I'm new and this is how I see it as a bit of an outsider... Facebook have put up bounties and allowed Andrei (whom I assume is one of their more high profile devs) to work on during work hours, at their expense. I think it is now the turn of the D community to step up to the plate. I'd love to have time to contribute to D directly but I don't. So I'd like to say that I really appreciate anything, no matter how small, that is contributed to D and especially all the hard work of the D core devs. Cheers, Ed
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 04:16:39 UTC, Andrei Alexandrescu wrote: Walter and I chose the bugs and sums involved. [...] I hope your ethical rule won't prevent you from working at least on the blocking and critical issues, because otherwise this would really be shooting yourself in the foot. :P
Re: Review of std.signal
On Saturday, 11 January 2014 at 18:02:15 UTC, Robert M. Münch wrote: Hi, not really a comment regarding the actual implementation but I think that good debug support for signales slots helps a lot in using it. What do I mean with this: - a way to dump in a human readable form the run-time connections. Which function / class / etc. is currently attached to which signal? - automatic logging like a call-stack in a debugger to get an idea when which signal is acted on - a way to get the order of activation for debugging to identify unwanted side-effects - etc. Big signal slot implementaitons can be hard to debug, this should be as simple as possible. Yes, it will be good to have. Also, you can vote `yes with condition` and write your condition after it (I think this description is good). In this case Robert receives your vote only if he implement your condition. It looks like not so many people use signals, so any feedback are welcome.
Re: Componentizing D's garbage collector
On 11.01.2014 22:20, Benjamin Thaut wrote: Am 11.01.2014 21:44, schrieb Andrei Alexandrescu: On 1/11/14 3:52 AM, Benjamin Thaut wrote: Am 10.01.2014 20:40, schrieb Andrei Alexandrescu: On 1/10/14 11:34 AM, Benjamin Thaut wrote: Am 10.01.2014 09:03, schrieb Andrei Alexandrescu: Destroy. Andrei Just one question. Did you read the garbage collection handbook? Yah, the new edition. Unfortunately I didn't find a lot of new stuff or things that would help in a practical implementation. Andrei Very good, In my opinion it should be required for everyone who wants to participate in D's GC to read that book. So everyone has at least a basic understanding of the problem at Hand. But if you read the book I don't understand, why you simply declare the hardest problem, percise pointer discovery, as done. To be able to actually implement and test a GC that is not a reimplementation of what we already have one needs percise pointer discovery of _all_ pointers, write barriers and GC halting points. So please enlighten me why you simply decalre this done? I'm not considering done as much as separable as a concern. All I'm saying is I hope to be able to separate the low-level part of discovering roots from the high-level part of marking used memory. BTW the way I see this done is mostly precise, i.e. there will be at least for a while some words that will be handled conservatively (stack, registers, certain union members). If there's anything in the GC book that suggest that would be impossible, please do let me know! Andrei Well as far as my understanding of GCs goes, you have two options: 1) Impercise pointer discovery = limiting yourself to a mark sweep 2) Percise pointer disccovery = option to use a semi space GC in combination with a mark sweep and generations, which allows for superior handling of short lived allocations (which is the biggest problem of D's current GC). Also without percise pointer discovery you will never be able to move objects from one heap into another. This would be especially a problem for the immutable heap, because you might want to allocate all strings on the thread local heap until you discover that you actually need them to be shared between threads. You might also need to move objects into antoher heap whenever a casts happens or global variable is assigned. Kind Regards Benjamin Thaut I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. We should aim at something in between mark sweep and compacting generational collection, e.g. a non-moving collector that keeps track of the youngest generation (I just made that up, not sure if it is realistic). Adding concurrency would also be nice...
Re: Componentizing D's garbage collector
On 11.01.2014 21:30, Jacob Carlborg wrote: On 2014-01-11 10:30, Rainer Schuetze wrote: I was thinking about using the proposed module info extension to generate data similar to RTInfo by interpreting global/tls data of a module as a struct with type info. I don't know if this is feasable. You mean this: https://github.com/D-Programming-Language/dmd/pull/2271 ? I really hope this can be merged sometime. Yes. I'm not sure if there is enough compiler support yet to figure out the global and TLS data layout of a module, especially for a static library where the module is split into a lot of object files.
Re: Componentizing D's garbage collector
Am 12.01.2014 11:27, schrieb Rainer Schuetze: I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. Could you give an example which part of the language would not be doable with a moving collector? The only thing that comes to my mind is unions and that problem can be solved by allowing the user to specify manual scanning functions for structs or classes containing unions. Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc.
Re: immutable bug?
On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote: But pure functions can (and do) return their arguments, and it's obviously not a 'strongly pure' function. So I just can't see how the assertion that it should be unique stands? That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable. Also, I was under the impression a 'strongly pure' function's arguments only need to be const, not necessarily immutable. Purity says something about the transformation performed by the function, nothing about the data it operates on. Why should all arguments need to be immutable? You don't need immutable arguments for purity, just strong purity. It's a stronger guarantee, more than normally guaranteed. Think of strong purity as pure + referentially transparent. Sorry, yes you're right, they only need to be const. And it is only if you return a mutable value that the result becomes convertible to immutable. int* f(const(int)* x); // convertible const(int)* f(const(int)* x); // not-convertible This is safe in the first instance because the result could not have come from x due to x being const. In the second instance, the result could have come from x, so it cannot be implicitly converted to immutable.
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote: Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc. We don't necessarily need that, though. In D we have a plethora of non-GC options, so it might be a better idea to tailor our GC to typical D programs rather than trying to reproduce the Java and C# collectors. For example, from a generational GC perspective, I don't think the young generation is significant in idiomatic D code, unlike Java code which relies on it heavily.
Re: [RFC] I/O and Buffer Range
09-Jan-2014 13:23, Brian Schott пишет: My experimental lexer generator now uses the buffer range. https://github.com/Hackerpilot/Dscanner/tree/NewLexer/stdx Cool! A minor note: https://github.com/Hackerpilot/Dscanner/blob/NewLexer/stdx/d/lexer.d#L487 lookahead(n) should always give a slice of length n, or 0 so you may as well test for != 0. In general you should avoid marking too often, it takes a bit of . I'm currently in favor of my 2nd design where marking is replaced by .save returning an independent view of buffer, making Buffer a normal forward range that is cheap to copy. https://github.com/blackwhale/datapicked/blob/fwd-buffer-range/dpick/buffer/ Sadly it segfaults with LDC so I can't quite assess its performance :( The problem that I have with it right now is that range.lookbehind(1).length != range.lookahead(1).length. This was confusing. That indeed may look confusing at start but keep in mind that range.front is in fact a lookahead of 1. Thus all algorithms that can work with lookahead of 1 LL(1), LALR(1) etc. would easily work any forward/input range (though any practical parser need to slice or copy parts of input aside). -- Dmitry Olshansky
Re: AA literals/initialisation
Manu turkey...@gmail.com wrote in message news:mailman.334.1389499497.15871.digitalmar...@puremagic.com... I've just run into this again today. It's still very annoying. Consider this a reminder? :) AAs should be rolled back first, and these have been sitting there for a couple of months. https://github.com/D-Programming-Language/dmd/pull/2856 https://github.com/D-Programming-Language/druntime/pull/668 Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’.
Re: Componentizing D's garbage collector
Am 12.01.2014 11:54, schrieb Jakob Ovrum: On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote: Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc. We don't necessarily need that, though. In D we have a plethora of non-GC options, so it might be a better idea to tailor our GC to typical D programs rather than trying to reproduce the Java and C# collectors. For example, from a generational GC perspective, I don't think the young generation is significant in idiomatic D code, unlike Java code which relies on it heavily. You should really try to write non-GC D code some time. You would be astonished how many hidden allocations there are.
Re: Componentizing D's garbage collector
12-Jan-2014 14:27, Rainer Schuetze пишет: On 11.01.2014 22:20, Benjamin Thaut wrote: Am 11.01.2014 21:44, schrieb Andrei Alexandrescu: Well as far as my understanding of GCs goes, you have two options: 1) Impercise pointer discovery = limiting yourself to a mark sweep 2) Percise pointer disccovery = option to use a semi space GC in combination with a mark sweep and generations, which allows for superior handling of short lived allocations (which is the biggest problem of D's current GC). Also without percise pointer discovery you will never be able to move objects from one heap into another. This would be especially a problem for the immutable heap, because you might want to allocate all strings on the thread local heap until you discover that you actually need them to be shared between threads. You might also need to move objects into antoher heap whenever a casts happens or global variable is assigned. Kind Regards Benjamin Thaut I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. I might be ignorant but why can't we make mostly-moving collector? For that we discern precise pointers (with typeinfo) and conservative (such as potential pointers in registers/stack). Then any block pointed to by a least one conservative pointer is pinned, others though can be moved freely since all of the pointers are known. -- Dmitry Olshansky
Re: Componentizing D's garbage collector
Am 12.01.2014 12:03, schrieb Dmitry Olshansky: 12-Jan-2014 14:27, Rainer Schuetze пишет: On 11.01.2014 22:20, Benjamin Thaut wrote: Am 11.01.2014 21:44, schrieb Andrei Alexandrescu: Well as far as my understanding of GCs goes, you have two options: 1) Impercise pointer discovery = limiting yourself to a mark sweep 2) Percise pointer disccovery = option to use a semi space GC in combination with a mark sweep and generations, which allows for superior handling of short lived allocations (which is the biggest problem of D's current GC). Also without percise pointer discovery you will never be able to move objects from one heap into another. This would be especially a problem for the immutable heap, because you might want to allocate all strings on the thread local heap until you discover that you actually need them to be shared between threads. You might also need to move objects into antoher heap whenever a casts happens or global variable is assigned. Kind Regards Benjamin Thaut I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. I might be ignorant but why can't we make mostly-moving collector? For that we discern precise pointers (with typeinfo) and conservative (such as potential pointers in registers/stack). Then any block pointed to by a least one conservative pointer is pinned, others though can be moved freely since all of the pointers are known. A semi-space garbage collector is best fitted for small short lived allocations. Which are mostly those that are referenced by the stack because they happend as functions are called. And for a semi-space garbage collector there is not mostly moving, it has to copy _all_ objects from one heap onto another so that those left on the original heap are known to be all garbage, can be destroyed and then the heap can be reused for the next collection. Mostly-moving doens't work here. Either you know all pointers percisely, or you don't do it. What you mean is pinning, you can pin objects for which you know they might be referenced by a impercise pointer and thus prevent them from beeing moved around. But this type of moving only works with mark sweep compacting collectors and thats not really better than what we already have. If you are really interrested in the topic I higly recommend reading The garbage collector handbook. Kind Regards Benjamin Thaut
Re: immutable bug?
On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote: Also, I was under the impression a 'strongly pure' function's arguments only need to be const, not necessarily immutable. Purity says something about the transformation performed by the function, nothing about the data it operates on. Why should all arguments need to be immutable? Your definition of purity states it clearly that the purity depends on the mutability of the input data.
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 11:02:28 UTC, Benjamin Thaut wrote: You should really try to write non-GC D code some time. You would be astonished how many hidden allocations there are. Is that down to the language, or parts of druntime and phobos that assume GC when they shouldn't?
Re: Componentizing D's garbage collector
Am 12.01.2014 12:12, schrieb Joseph Rushton Wakeling: On Sunday, 12 January 2014 at 11:02:28 UTC, Benjamin Thaut wrote: You should really try to write non-GC D code some time. You would be astonished how many hidden allocations there are. Is that down to the language, or parts of druntime and phobos that assume GC when they shouldn't? Both. Although it kept getting better lately.
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 11:02:28 UTC, Benjamin Thaut wrote: You should really try to write non-GC D code some time. I do. You would be astonished how many hidden allocations there are. I was, years ago.
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 00:19, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I've placed on behalf of Facebook a few more bounties on D-related issues. There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. I didn't hear anything from Iain Buclaw (what's happening?) and am discussing with Kai Nacke the best angle of attack regarding LDC issues. I must have been too busy not reading emails. Can you ping me about this? Thanks.
Re: ARM support
Am Fri, 10 Jan 2014 08:59:56 + schrieb Dicebot pub...@dicebot.lv: There were people trying vibe.d on ARM/Linux here and there with several issues that may or may not be already fixed by LDC/GDC/vibe.d developers. One thread I have found: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/6048/ As far as I know it works in general but using any more complex projects like vibe.d is likely to trigger any hiding issues in GDC/LDC so one needs to be ready to push through it for greater good. Interesting, I didn't know about that thread. I tried the vibe-d examples and all of them worked fine, however I didn't do extensive testing. I made a small fix to the fibers code so maybe that fixed the problem. However, fibers are probably a little bit slower that they could be as we use the libc backend and not ARM-specific ASM.
Re: ARM support
Am Fri, 10 Jan 2014 08:27:37 +
schrieb Joakim joa...@airpost.net:
On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote:
Hello,
I'm developing embedded system product on ARM9/Linux platform
and I wish I could use D and vibe.d for this task.
I have couple of questions in this matter:
Like Mike, I'm an interested user, who wants to see D on ARMv7,
not a core developer, but I'll take a shot at answering your
questions.
- What is the current status of ARM support?
Limited. The reference DMD compiler has no support for ARM,
while the LDC and GDC compilers are trying to utilize the ARM
backends of llvm and gcc to add ARM support, as Mike points out,
but they're not finished. Not sure where ARM9 specifically fits
into all this.
The exact ARM architecture version doesn't matter that much. I mainly
test ARMv5 and ARMv6 older versions are untested. But OS support does
matter, I only work on Linux/GLIBC systems right now.
- Does druntime support ARM plaforms?
Grepping through the code, druntime appears to use a fair amount
of x86 assembly, but I have not yet looked into how much of that
is optimization and therefore not strictly necessary to
reimplement on ARM.
You'll have to look at GDC/LDC druntime and not the DMD druntime to
see the ARM stuff. GDC/LDC specific stuff is not being upstreamed.
There's some ARM asm in GDC:druntime, but we try to rewrite all DMD
asm in terms of cross-platform GCC builtins (__builtin_trap instead of
asm{int 3;} and so on) so there's really not much ASM left for
GDC:druntime.
- Does GC run reliably on ARM (or is it platform independent)?
I don't think anybody can know for sure, since nobody has tried
to make it work. The source appears to be fairly independent,
but other core features like threading or fibers appear not be.
The GC works just fine for GDC/ARM. See my other reply for details.
Threading is portable as long as you're on Posix, Fibers in theory as
well (there is a backend using posix libc functions and that works fine
on ARM. But only recent glibc version 2.17 implement these functions)
Re: AA literals/initialisation
Jakob Ovrum wrote in message news:izbxftjgrkgfehqeh...@forum.dlang.org... Do you even understand the problem? This is an extremely complicated thing that you are asking, you can't do anything like it in any other programming language that I'm aware of. We have been making progress in making it work over the years, but for AAs it's at an impasse due to how AAs are implemented in the compiler. It's not _that_ bad. There are open pull requests to convert AAs to use UFCS instead of the current broken hacks, and crossing from compile to run-time just means matching the layout of the runtime AAs in AssocArrayExpression::toDt. This kind of nagging is not helping anyone, it's just annoying. I asked him to. You could at least read the quoted text.
Re: Phobos strings versus C++ Boost
On 2014-01-11 22:42, Dmitry Olshansky wrote: With high probablity :) And it's indeed quite high, the amount of bad sheep that gets longer/shorter across the whole Unicode is around 5-10 codepoints IRC. The least we can do is make that very clear in the documentation. -- /Jacob Carlborg
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 05:22:22 UTC, Manu wrote: No I don't understand the problem. What I do know is that Daniel said to remind him, so I did. I'm sorry, that was entirely my mistake.
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 11:32:00 UTC, Daniel Murphy wrote: It's not _that_ bad. There are open pull requests to convert AAs to use UFCS instead of the current broken hacks, and crossing from compile to run-time just means matching the layout of the runtime AAs in AssocArrayExpression::toDt. Alright, that looks more short-term viable than Stepanov's approach. I don't think I'm overplaying the issue though - it is a tall order to ask for compile-time construction of AAs that are then usable at runtime, and it's not fair to present them as a fundamental feature, or their absence as a bug, because it's not like other languages have anything near this kind of power. It props up quite often but it's usually due to a (perfectly understandable) misunderstanding of D's initializers for fields and module-level/static variables. The expectation is that it works like in Java and C#, where these initializers are run before main or on construction of the type. Fortunately, when the D approach is explained, thus explaining why the code errors[1], most people tend to be either content or excited. [1] The error message was fine for D1, but the phrasing is problematic for D2...
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote: There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. Maybe there’s just not so many people around who can help with compilers? I’m an application developer and can surely also help with the library, but hacking on the compiler is something I’ve never done (and don’t know if I would be any good at it)
Re: ARM support
Am Thu, 09 Jan 2014 19:07:17 +0100 schrieb Piotr Szturmaj bncr...@jadamspam.pl: Hello, Answers for GDC: I'm developing embedded system product on ARM9/Linux platform and I wish I could use D and vibe.d for this task. ARMv5 or ARMv4? I tested ARMv5 and that should work. ARMv4 should work as well but is untested. I have couple of questions in this matter: - What is the current status of ARM support? GDC is almost ready ready for a public beta. Tested with Softfloat(no FPU)/Hardfloat on ARMv5/ARMv6: * Compiler test suite passes as well as x86 * Druntime unittests pass * Phobos tests pass except for std.math.internal.gammafunction which isn't ported yet I mainly test using cross-compilers and haven't found any cross-compiler issues so for (cross-compilers also pass all those test mentioned above). The remaining work is getting my changes upstreamed which will probably take 2-4 weeks, then making a public beta with binaries for cross-compilers. See https://github.com/jpf91/GDC/tree/arm-old (old only means gcc-4.8 instead of gcc-4.9) - Does GDC support cross-compiling to ARM? Yes, that works just fine. See http://wiki.dlang.org/GDC/Cross_Compiler I use and recommend crosstool-NG. - Is it possible to remote-debug D code on ARM? (I've used GDB for C++ remote debugging on ARM11, I think this should also work with GDC compiled code) This should work just fine, but I didn't test it. Native debugging works well. (GCC-4.8 emits dwarf4 by default. If your gdb doesn't support dwarf4 you have to pass some flags to gdc to generate dwarf2) - Does druntime support ARM plaforms? Yes (the druntime in gdc. We only upstream things that work for every compiler so the upstream druntime is not complete. But as dmd doesn't target ARM anyway...) - Does phobos support ARM plaforms? Yes. Phobos is mostly CPU-architecture independent. The biggest problem is usually floating point code which assumes real==80bit. But Iain sorted out most of these issues, only std.math.internal.gammafunction remains. - Does GC run reliably on ARM (or is it platform independent)? Yes. It's basically CPU-arch independent. You need to tell it if the stack grows upward/downwards and that's it. It depends on the OS, but only for very few things (getting stack bounds, TLS memory ranges etc). As longs as you use Linux/Glibc it should work just fine. - Can you estimate eventual cost of supporting D on ARM (think of paid bounty). Can't speak for anyone else but for me it's more a matter of missing time than of money. Probably donating a board for the auto-tester could help.
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 12:20:39 UTC, Kira Backes wrote: On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote: There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. Maybe there’s just not so many people around who can help with compilers? I’m an application developer and can surely also help with the library, but hacking on the compiler is something I’ve never done (and don’t know if I would be any good at it) +1. The front-end source code shared by the compilers uses C++, and the style of C++ used is not exactly state of the art. These two facts probably make compiler contributions unappealing to most community members. The bounties are a nice perk, but before the bounty even comes into play, the developer needs to make the plunge into the front-end code base. The bounties almost exclusively target compiler issues (understandably), so with the relative dearth of compiler developers, I'm not surprised that the bounties haven't changed much.
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 21:42:46 UTC, Dmitry Olshansky wrote: 12-Jan-2014 01:22, monarch_dodra пишет: On Saturday, 11 January 2014 at 20:36:31 UTC, Jacob Carlborg wrote: On 2014-01-11 08:50, Brad Anderson wrote: The recent discussion got me wondering how Phobos stacked up against the C++ Boost String Algorithms library. Some background on the design of the Boost library: http://www.boost.org/doc/libs/1_55_0/doc/html/string_algo/design.html TL;DR: It works somewhat like ranges. Google Spreadsheet with the comparison: http://goo.gl/Wmotu4 toLower/Upper doesn't really work in place. Yeah, toLowerInplace is actually more like toLowerProbablyInPlace With high probablity :) And it's indeed quite high, the amount of bad sheep that gets longer/shorter across the whole Unicode is around 5-10 codepoints IRC. More important than the absolute amount of bad sheep is the frequency of them in your input :-)
Re: Facebook puts more bounties on dlang issues
Am Sun, 12 Jan 2014 11:32:04 + schrieb Iain Buclaw ibuc...@gdcproject.org: On 12 January 2014 00:19, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I've placed on behalf of Facebook a few more bounties on D-related issues. There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. I didn't hear anything from Iain Buclaw (what's happening?) and am discussing with Kai Nacke the best angle of attack regarding LDC issues. I guess the last missing pieces in GDC (apart from specific bugs) are NRVO, exception chaining and LTO. I probably won't work on any of these issues though, that stuff is too complicated for me ;-) But if we could get some new contributors because of these bounties that'd be even better :-)
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 12:20:39 UTC, Kira Backes wrote: Maybe there’s just not so many people around who can help with compilers? I’m an application developer and can surely also help with the library, but hacking on the compiler is something I’ve never done (and don’t know if I would be any good at it) There is only one way to find out: Just try your hand at it. ;) I was in the same position as you some year ago, but found compiler development to be a very interesting field. David
Re: Facebook puts more bounties on dlang issues
On 2014-01-12 14:10, David Nadlinger wrote: There is only one way to find out: Just try your hand at it. ;) I was in the same position as you some year ago, but found compiler development to be a very interesting field. Yeah, I agree. I have contributed with some smaller changes to the compiler without having much previous experience. -- /Jacob Carlborg
Re: AA literals/initialisation
Jakob Ovrum wrote in message news:whwxxduozvqjrcldm...@forum.dlang.org... Alright, that looks more short-term viable than Stepanov's approach. I don't think I'm overplaying the issue though - it is a tall order to ask for compile-time construction of AAs that are then usable at runtime, and it's not fair to present them as a fundamental feature, or their absence as a bug, because it's not like other languages have anything near this kind of power. This used to be true, but now we can pass heap-allocated structs and classes from compile-time to run-time. The fact we can't do the same for AAs is an embarrassing limitation. It would have happened years ago if AAs weren't such a mess.
Re: AA literals/initialisation
On 12 January 2014 21:02, Daniel Murphy yebbliesnos...@gmail.com wrote: Manu turkey...@gmail.com wrote in message news:mailman.334.1389499497. 15871.digitalmar...@puremagic.com... I've just run into this again today. It's still very annoying. Consider this a reminder? :) AAs should be rolled back first, and these have been sitting there for a couple of months. https://github.com/D-Programming-Language/dmd/pull/2856 https://github.com/D-Programming-Language/druntime/pull/668 Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’. I'm often surprised that a semi-official fork has never appeared ;) When is the next release meant to be? I saw comments in those bugs that it was supposed to be in December, but that seems too soon?
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 14:30:42 UTC, Daniel Murphy wrote: This used to be true, but now we can pass heap-allocated structs and classes from compile-time to run-time. The fact we can't do the same for AAs is an embarrassing limitation. This ability for class instances is fairly recent, but the same point remains - being able to instantiate a class at compile-time and use it at runtime is equally a tall order, not a fundamental feature, and it wasn't a bug when it was absent.
Re: Should this work?
On Friday, 10 January 2014 at 16:54:30 UTC, Brad Anderson wrote: Updating the website is almost strictly Andrei's domain so he should be able to do it independently of the release process (though integrating updating the website with the release process should probably happen at some point). ddox was merged with the tools repo 6 months ago and dlang.org 3 months ago so as far as I know all that's left is for Andrei to generate the pages and upload them as 2.065 is completed. Andrew should have access too as any release-related updates are supposed to be moved into domain of release manager.
Re: AA literals/initialisation
Jakob Ovrum wrote in message news:yvvcvcfughejigooe...@forum.dlang.org... This ability for class instances is fairly recent, but the same point remains - being able to instantiate a class at compile-time and use it at runtime is equally a tall order, not a fundamental feature, and it wasn't a bug when it was absent. I disagree. Being able to pass classes from ctfe to run-time is a fundamental feature of ctfe. AAs are even more important, as no ctfe is required to hit this limitation.
Struck Gold
I'm probably the last person in the D community to realize, but yesterday I found Gold (the linker that is). The build time for my project has diminished dramatically. I just had to be a little more specific about one of my link-time build libraries in CodeBlocks.
Re: ARM support
On Sunday, 12 January 2014 at 11:31:07 UTC, Johannes Pfau wrote:
Am Fri, 10 Jan 2014 08:27:37 +
schrieb Joakim joa...@airpost.net:
- Does druntime support ARM plaforms?
Grepping through the code, druntime appears to use a fair
amount of x86 assembly, but I have not yet looked into how
much of that is optimization and therefore not strictly
necessary to reimplement on ARM.
You'll have to look at GDC/LDC druntime and not the DMD
druntime to
see the ARM stuff. GDC/LDC specific stuff is not being
upstreamed.
There's some ARM asm in GDC:druntime, but we try to rewrite all
DMD
asm in terms of cross-platform GCC builtins (__builtin_trap
instead of
asm{int 3;} and so on) so there's really not much ASM left for
GDC:druntime.
I didn't know that ldc and gdc used their own forks of druntime
and phobos, so maybe my info is a bit off.
Re: AA literals/initialisation
Manu turkey...@gmail.com wrote in message news:mailman.355.1389539511.15871.digitalmar...@puremagic.com... I'm often surprised that a semi-official fork has never appeared ;) I don't agree with everything Walter does, but that doesn't mean I want his job. When is the next release meant to be? I saw comments in those bugs that it was supposed to be in December, but that seems too soon? When all regressions are fixed + when Walter says so + when the moon is in the correct phase
Re: Facebook puts more bounties on dlang issues
On 1/12/14 1:07 AM, Francesco Cattoglio wrote: On Sunday, 12 January 2014 at 04:16:39 UTC, Andrei Alexandrescu wrote: Walter and I chose the bugs and sums involved. [...] I hope your ethical rule won't prevent you from working at least on the blocking and critical issues, because otherwise this would really be shooting yourself in the foot. :P Haven't tried it yet, but it should be easy to decline a bounty and then reallocate it. Andrei
Re: Struck Gold
I hope you're using dmd 2.063 or git head, since dmd 2.064 with gold produces crashing code for switch jump tables. Anything with threads and boom. Atila On Sunday, 12 January 2014 at 16:25:01 UTC, Steve Teale wrote: I'm probably the last person in the D community to realize, but yesterday I found Gold (the linker that is). The build time for my project has diminished dramatically. I just had to be a little more specific about one of my link-time build libraries in CodeBlocks.
Re: Facebook puts more bounties on dlang issues
On 1/11/14 10:10 PM, Rikki Cattermole wrote: +1 on (potentially) Facebook hiring somebody to work on the toolchain in some form. Would set a good precedence and showing just how committed Facebook is. Facebook seldom hires for a specific role in Engineering. After a newly hired engineer goes through the six-week bootcamp that familiarizes him/her with Facebook's technologies, projects, and teams, the engineer chooses a team. Conversely, projects often get initiated by engineers. It's a surprisingly bottom-up organization. Andrei
Re: Componentizing D's garbage collector
On 1/12/14 2:40 AM, Benjamin Thaut wrote: Am 12.01.2014 11:27, schrieb Rainer Schuetze: I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. Could you give an example which part of the language would not be doable with a moving collector? The only thing that comes to my mind is unions and that problem can be solved by allowing the user to specify manual scanning functions for structs or classes containing unions. Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc. Yah, moving would be real nice. I hope to at least clarify the issues related to moving with my work. Andrei
Re: immutable bug?
On 1/12/14 2:49 AM, Peter Alexander wrote: On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote: But pure functions can (and do) return their arguments, and it's obviously not a 'strongly pure' function. So I just can't see how the assertion that it should be unique stands? That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable. Yep. Has this been placed in bugzilla? It's rather hi-pri. Andrei
Re: AA literals/initialisation
On 1/12/14 3:02 AM, Daniel Murphy wrote: Manu turkey...@gmail.com wrote in message news:mailman.334.1389499497.15871.digitalmar...@puremagic.com... I've just run into this again today. It's still very annoying. Consider this a reminder? :) AAs should be rolled back first, and these have been sitting there for a couple of months. https://github.com/D-Programming-Language/dmd/pull/2856 https://github.com/D-Programming-Language/druntime/pull/668 Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’. If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. Andrei
Re: immutable bug?
Andrei Alexandrescu wrote in message news:laugbo$2jcq$3...@digitalmars.com... Yep. Has this been placed in bugzilla? It's rather hi-pri. If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause.
Re: AA literals/initialisation
Andrei Alexandrescu wrote in message news:laugvv$2k3h$1...@digitalmars.com... If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. I don't know if it's undue or not, but https://github.com/D-Programming-Language/dmd/pull/2895 https://github.com/D-Programming-Language/dmd/pull/2924
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote: Am 12.01.2014 11:27, schrieb Rainer Schuetze: I think a moving collector is currently not feasible without restricting the language a lot, probably similar to safe D and more. I'm not sure we want that in general. I'd rather have more restrictions and a working precise GC, and let those who wish to do without the safety ask for it explicitly. Could you give an example which part of the language would not be doable with a moving collector? The only thing that comes to my mind is unions and that problem can be solved by allowing the user to specify manual scanning functions for structs or classes containing unions. How would the moving GC deal with pointer arithmetic? Also I don't think that we can create a GC which performs as good as the one of Java or C# if we are not willing to make the neccessary changes for a moving gc. I agree. Even ignoring the comparison with Java/C#, I think if D is to be a 'fully garbage collected language' then it will have to support a state of the art GC.
Re: Componentizing D's garbage collector
Am 12.01.2014 18:12, schrieb Brian Rogoff: How would the moving GC deal with pointer arithmetic? I don't see any problem with pointer arithmetic? Either the pointer is pointing to a gc managed memory block and will be patched accordingly, or it is not pointing to a gc managed memory block, and nothing will happen. Obviously if you do unsafe things, you have to know what you are doing and might give additional information to the gc so it can propperly support unsafe stuff.
Re: immutable bug?
On 13 January 2014 02:37, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/12/14 2:49 AM, Peter Alexander wrote: On Sunday, 12 January 2014 at 02:11:18 UTC, Manu wrote: But pure functions can (and do) return their arguments, and it's obviously not a 'strongly pure' function. So I just can't see how the assertion that it should be unique stands? That's the bug. Your function isn't strongly pure, so the result shouldn't be convertible to immutable and isn't necessarily unique. Only strongly pure functions can have results convertible to immutable. Yep. Has this been placed in bugzilla? It's rather hi-pri. I wasn't sure if it was definitely a bug. Certainly seemed like one though. https://d.puremagic.com/issues/show_bug.cgi?id=11908
Re: Facebook puts more bounties on dlang issues
Am 12.01.2014 13:20, schrieb Kira Backes: On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote: There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. Maybe there’s just not so many people around who can help with compilers? I’m an application developer and can surely also help with the library, but hacking on the compiler is something I’ve never done (and don’t know if I would be any good at it) I will surely like to do it, given my background on compiler design, however real life keeps jumping in the way. So I tend just to do advocacy. :) Compiler development is not as hard as people think, it just plain data structures manipulations. If you skim through a book like the one from Niklaus Wirth about compiler development[1], you get the basics pretty quickly. [1] http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf -- Paulo
Re: Facebook puts more bounties on dlang issues
On 1/12/14 4:20 AM, Kira Backes wrote: On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote: There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. Maybe there’s just not so many people around who can help with compilers? I’m an application developer and can surely also help with the library, but hacking on the compiler is something I’ve never done (and don’t know if I would be any good at it) There are quite a few bountied bugs that are library-related. The first I see on https://www.bountysource.com/trackers/383571-d-programming-language is https://www.bountysource.com/issues/1325915-object-not-const-correct. Let's say that's kinda runtime support so more difficult, so scanning down we see things like https://www.bountysource.com/issues/1327158-getopt-improvements-by-igor-lesik or... hmmm, that's about it. But there's also https://www.bountysource.com/issues/1325916-reading-writing-an-archive-causes-data-loss-std-zip-horribly-broken which was paid off but since reopened (arguably for a distinct matter). If I get more budget I'll try to assign more to library issues. Andrei
Re: Facebook puts more bounties on dlang issues
On 1/12/14 4:45 AM, Jakob Ovrum wrote: The bounties almost exclusively target compiler issues (understandably), so with the relative dearth of compiler developers, I'm not surprised that the bounties haven't changed much. I don't think that's accurate. In fact most activity on github (before or after Facebook's bounty program) has been on the compiler. Andrei
Re: Facebook puts more bounties on dlang issues
On 1/12/14 4:50 AM, Johannes Pfau wrote: Am Sun, 12 Jan 2014 11:32:04 + schrieb Iain Buclaw ibuc...@gdcproject.org: On 12 January 2014 00:19, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I've placed on behalf of Facebook a few more bounties on D-related issues. There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. I didn't hear anything from Iain Buclaw (what's happening?) and am discussing with Kai Nacke the best angle of attack regarding LDC issues. I guess the last missing pieces in GDC (apart from specific bugs) are NRVO, exception chaining and LTO. I probably won't work on any of these issues though, that stuff is too complicated for me ;-) But if we could get some new contributors because of these bounties that'd be even better :-) One organizational/communication problem for me is that I've never been able to grasp where GDC is, what the milestones for integrations are, what the related issues are, and how to get from where we are to where we should. I've communicated with Iain over forum, email, IRC, Skype, and to be very honest I am unable to get simple answers to these simple questions (my accent was an issue in Skype communication). One thing I do recall is that Iain mentioned (I'm paraphrasing) that he hopes to underpromise and overdeliver, i.e. just finish integration instead of bragging about it before it being done. The unfortunate recoil from that is that I have no idea where he is in the process, and whether he could use any help. Andrei
Re: Struck Gold
On 1/12/14 8:24 AM, Steve Teale wrote: I'm probably the last person in the D community to realize, but yesterday I found Gold (the linker that is). The build time for my project has diminished dramatically. I just had to be a little more specific about one of my link-time build libraries in CodeBlocks. Yah, gold is great. Did you have any issues with it linking D code? Andrei
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 17:39:31 UTC, Andrei Alexandrescu wrote: I don't think that's accurate. In fact most activity on github (before or after Facebook's bounty program) has been on the compiler. Andrei Yeah, but it looks like Phobos has a wider variety of developers.
Re: Facebook puts more bounties on dlang issues
On 1/12/14 9:48 AM, Jakob Ovrum wrote: On Sunday, 12 January 2014 at 17:39:31 UTC, Andrei Alexandrescu wrote: I don't think that's accurate. In fact most activity on github (before or after Facebook's bounty program) has been on the compiler. Andrei Yeah, but it looks like Phobos has a wider variety of developers. I understand the theory. The data simply doesn't support it. There's plenty of opened issues for Phobos and plenty of pull requests for it. Yet dmd is doing a lot better in terms of contributors. Andrei
Re: Struck Gold
On Sunday, 12 January 2014 at 17:45:42 UTC, Andrei Alexandrescu wrote: On 1/12/14 8:24 AM, Steve Teale wrote: I'm probably the last person in the D community to realize, but yesterday I found Gold (the linker that is). The build time for my project has diminished dramatically. I just had to be a little more specific about one of my link-time build libraries in CodeBlocks. Yah, gold is great. Did you have any issues with it linking D code? Andrei Code produced by dmd is not very gold compliant.
Re: immutable bug?
On 1/12/14 8:46 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:laugbo$2jcq$3...@digitalmars.com... Yep. Has this been placed in bugzilla? It's rather hi-pri. If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause. Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 17:15:44 UTC, Benjamin Thaut wrote: Am 12.01.2014 18:12, schrieb Brian Rogoff: How would the moving GC deal with pointer arithmetic? I don't see any problem with pointer arithmetic? Either the pointer is pointing to a gc managed memory block and will be patched accordingly, or it is not pointing to a gc managed memory block, and nothing will happen. Or you don't know if something is a pointer or not and so whatever it references is pinned.
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 17:39, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/12/14 4:45 AM, Jakob Ovrum wrote: The bounties almost exclusively target compiler issues (understandably), so with the relative dearth of compiler developers, I'm not surprised that the bounties haven't changed much. I don't think that's accurate. In fact most activity on github (before or after Facebook's bounty program) has been on the compiler. Andrei +1 The total number of pull requests in the compiler is a clear 500 more than in both druntime AND phobos combined.
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 17:51:42 UTC, Andrei Alexandrescu wrote: I understand the theory. The data simply doesn't support it. There's plenty of opened issues for Phobos and plenty of pull requests for it. Yet dmd is doing a lot better in terms of contributors. Andrei This could also be because dmd has more *reviewers*, and is generally *active*. Related: You still have 2 pulls in phobos that are basically merge ready, they just need you the final touches. But you aren't responding to the pings. On topic: I wouldn't mind seeing more bounties in Phobos. I'd gladly take them on, but there aren't any. Another idea would be to give a financial incentive to the *reviewers* to review high priority commits.
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 17:44, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/12/14 4:50 AM, Johannes Pfau wrote: Am Sun, 12 Jan 2014 11:32:04 + schrieb Iain Buclaw ibuc...@gdcproject.org: On 12 January 2014 00:19, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I've placed on behalf of Facebook a few more bounties on D-related issues. There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. I didn't hear anything from Iain Buclaw (what's happening?) and am discussing with Kai Nacke the best angle of attack regarding LDC issues. I guess the last missing pieces in GDC (apart from specific bugs) are NRVO, exception chaining and LTO. I probably won't work on any of these issues though, that stuff is too complicated for me ;-) But if we could get some new contributors because of these bounties that'd be even better :-) One organizational/communication problem for me is that I've never been able to grasp where GDC is, what the milestones for integrations are, what the related issues are, and how to get from where we are to where we should. I've communicated with Iain over forum, email, IRC, Skype, and to be very honest I am unable to get simple answers to these simple questions (my accent was an issue in Skype communication). One thing I do recall is that Iain mentioned (I'm paraphrasing) that he hopes to underpromise and overdeliver, i.e. just finish integration instead of bragging about it before it being done. The unfortunate recoil from that is that I have no idea where he is in the process, and whether he could use any help. We need to work on our communication. Which probably means: I need to work on my communication.
Re: immutable bug?
On 01/12/2014 11:49 AM, Peter Alexander wrote: Also, I was under the impression a 'strongly pure' function's arguments only need to be const, not necessarily immutable. Purity says something about the transformation performed by the function, nothing about the data it operates on. Why should all arguments need to be immutable? You don't need immutable arguments for purity, just strong purity. It's a stronger guarantee, more than normally guaranteed. Think of strong purity as pure + referentially transparent. Sorry, yes you're right, they only need to be const. And it is only if you return a mutable value that the result becomes convertible to immutable. int* f(const(int)* x); // convertible const(int)* f(const(int)* x); // not-convertible ... (I assume you meant those to be pure.) This is safe in the first instance because the result could not have come from x due to x being const. In the second instance, the result could have come from x, so it cannot be implicitly converted to immutable. Well, currently things are supposed to be as follows: 1. A strongly pure callable is a pure callable whose parameter types implicitly convert to immutable. 2. The result of a call to a strongly pure callable implicitly converts to immutable. The following vastly more general rule would still be sound and also capture your case: - The result of a call to a pure callable, where all arguments whose corresponding parameter types are incompatible with the result type implicitly convert to immutable (shared), implicitly converts to immutable (shared). (Incompatibility should probably just be incompatibility of qualifiers.)
Re: Struck Gold
On 1/12/2014 9:58 AM, deadalnix wrote: Code produced by dmd is not very gold compliant. That's a frustratingly meaningless comment - there's nowhere anyone can go with it.
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 10:27:42 UTC, Rainer Schuetze wrote: [...] Adding concurrency would also be nice... I just want to point out that from an outer perspective, this is a really really *really* big deal. By far the most common arguments I've heard against D are: 1. library availability (derelict, deimos now) 2. community size and impetus (getting there!) 3. shared druntime/phobos so Hello World isn't 800kb (getting there?) 4. garbage collector which is only possible to opt out of by writing C The very reliance of the garbage collector, regardless of how far between the stop-the-world sweeps are, is a showstopper for many people. They hear GC and think Java pauses. Being able to honestly claim well it runs concurrently in a separate thread and doesn't[*] incur any performance penalty would be the single biggest leap to greater adoption D could take at this point. Maybe barring it prints money, but only maybe. It may be less of a *technical* problem than, say, this or that bug in the type system, or the identity crisis of shared. But fixing those would not make for a *twentieth* of the marketing that a concurrent GC would. Fixing those would make people stay -- introducing that GC would make people join. Not saying that such bugs shouldn't get attention, I'm just saying that Bob would scroll past that link on /r/programming. In comparison, Lucarella's dconf slides were... *compelling*. (P.S. many awkwardly long hugs to those culling allocations from druntime/phobos, you rock)
Re: immutable bug?
On Sunday, 12 January 2014 at 18:09:59 UTC, Andrei Alexandrescu wrote: Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function I posted a fix for this issue (i.e. the one on which the bounty was set). Now tackling Manu's example, which turns out to exhibit a slightly different bug. David
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu wrote: On 1/12/14 3:02 AM, Daniel Murphy wrote: Manu turkey...@gmail.com wrote in message news:mailman.334.1389499497.15871.digitalmar...@puremagic.com... I've just run into this again today. It's still very annoying. Consider this a reminder? :) AAs should be rolled back first, and these have been sitting there for a couple of months. https://github.com/D-Programming-Language/dmd/pull/2856 https://github.com/D-Programming-Language/druntime/pull/668 Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’. If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. Andrei The Release Process on the wiki[1] does not have a method for a bugfix only release so it's definitely a problem. Both bugfixes and features get merged into master. The release process forbids cherry-picking between branches (some rationale for this rule would be nice; it feels like a mistake to me) so that can't be used to solve the problem. I don't think there is a way to do a bugfix only release without cherry-picking. If it were me, I'd just would have had both bugfixes and features merge into master as described by the release process and have a 2.065 branch which a single person is responsible for cherry-picking bugfixes into (alternatively you could have whoever merges the bugfix into master do it). Frankly, I think the described Release Process is much more complicated than it needs to be. Fundamentally you only need two branches at any given time: master and a release branch which only exists after the feature freeze takes place for an upcoming release (post-release the branch gets tagged, merged back into master[2], and deleted). It's a shame Github doesn't let you target multiple branches with a pull request. That'd be a nice workflow during the short lived feature freeze window. 1. http://wiki.dlang.org/Release_Process 2. Which, I found out by chance, never happens: https://github.com/D-Programming-Language/dmd/pull/3080 This is very bad as commits can easily get lost though I question whether the release branch should ever be committed to directly.
Re: Should this work?
Your proposal is awesome, this should be in phobos style guide imo.
RefCounted no thread-safety?
Hello, I was just looking at the source of std.typecons.RefCounted and it seems like it is not thread-safe at all, the count variable may be written concurrently from several threads which could cause data corruption. Is this correct or am I overlooking something (I’m still new to D). If it is correct then this should either be fixed or if it is intentional it should really be documented. rgds, Kira
Re: RefCounted no thread-safety?
12-Jan-2014 23:59, Kira Backes пишет: Hello, I was just looking at the source of std.typecons.RefCounted and it seems like it is not thread-safe at all, the count variable may be written concurrently from several threads which could cause data corruption. It cannot. In D everything is thread-local by default. And shared(RefCounted!T) would most likely fail to compile. Is this correct or am I overlooking something (I’m still new to D). If it is correct then this should either be fixed or if it is intentional it should really be documented. -- Dmitry Olshansky
Re: RefCounted no thread-safety?
On 2014-01-12 20:08:17 +, Dmitry Olshansky dmitry.o...@gmail.com said: 12-Jan-2014 23:59, Kira Backes пишет: Hello, I was just looking at the source of std.typecons.RefCounted and it seems like it is not thread-safe at all, the count variable may be written concurrently from several threads which could cause data corruption. It cannot. In D everything is thread-local by default. And shared(RefCounted!T) would most likely fail to compile. There's still a race when RefCounted is located in a GC-allocated memory block, as the destructor might get called from any thread. https://d.puremagic.com/issues/show_bug.cgi?id=4624 -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: RefCounted no thread-safety?
On Sunday, 12 January 2014 at 20:08:25 UTC, Dmitry Olshansky wrote: It cannot. In D everything is thread-local by default. And shared(RefCounted!T) would most likely fail to compile. Hello, thanks for the info, I did not test compiling with shared. You’re right about this, I was just too much used to C++11’s shared_ptr I think ;-)
Programmer en D published on dlang-fr.org
Hello everybody, I just published the current state of Programmer en D, the French translation of Ali's Programming in D, on dlang-fr: http://dlang-fr.org/cours/programmer-en-d/ There are a lot of missing chapters and no proofread have been done yet. There's an integrated module to report any error of make any suggestion on the book. Somme recent modifications from Ali are still to apply to the translation. Enjoy, and please comment if you have anything to tell about it, any suggestion, any idea, any question. Raphaël.
Re: immutable bug?
On 01/12/2014 07:10 PM, Andrei Alexandrescu wrote: On 1/12/14 8:46 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:laugbo$2jcq$3...@digitalmars.com... Yep. Has this been placed in bugzilla? It's rather hi-pri. If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause. Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected. There are other serious problems with the type system implementation, eg: https://d.puremagic.com/issues/show_bug.cgi?id=9149 https://d.puremagic.com/issues/show_bug.cgi?id=10376 https://d.puremagic.com/issues/show_bug.cgi?id=9148 On a related note, I think it makes no sense to put a bounty on the Object not const-correct issue. What would someone be required to do in order to get the bounty for that issue?
Re: RefCounted no thread-safety?
13-Jan-2014 00:12, Michel Fortin пишет: On 2014-01-12 20:08:17 +, Dmitry Olshansky dmitry.o...@gmail.com said: 12-Jan-2014 23:59, Kira Backes пишет: Hello, I was just looking at the source of std.typecons.RefCounted and it seems like it is not thread-safe at all, the count variable may be written concurrently from several threads which could cause data corruption. It cannot. In D everything is thread-local by default. And shared(RefCounted!T) would most likely fail to compile. There's still a race when RefCounted is located in a GC-allocated memory block, as the destructor might get called from any thread. https://d.puremagic.com/issues/show_bug.cgi?id=4624 Awful. The only thing worse is that arrays of structs don't have their destructors called at all. -- Dmitry Olshansky
Re: immutable bug?
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote: ... I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding Remedy's 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something?
Re: immutable bug?
On 01/12/2014 10:06 PM, Johnny Walking wrote: On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote: ... I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding Remedy's 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something? http://en.wikipedia.org/wiki/Baader-Meinhof_phenomenon
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 19:45:15 UTC, Brad Anderson wrote: On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu wrote: If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. Andrei The Release Process on the wiki[1] does not have a method for a bugfix only release so it's definitely a problem. Both bugfixes and features get merged into master. The release process forbids cherry-picking between branches (some rationale for this rule would be nice; it feels like a mistake to me) so that can't be used to solve the problem. I don't think there is a way to do a bugfix only release without cherry-picking. If it were me, I'd just would have had both bugfixes and features merge into master as described by the release process and have a 2.065 branch which a single person is responsible for cherry-picking bugfixes into (alternatively you could have whoever merges the bugfix into master do it). Frankly, I think the described Release Process is much more complicated than it needs to be. Fundamentally you only need two branches at any given time: master and a release branch which only exists after the feature freeze takes place for an upcoming release (post-release the branch gets tagged, merged back into master[2], and deleted). I had to get this off my chest even if it's unlikely to be adopted: http://wiki.dlang.org/Simplified_Release_Process_Proposal
Re: Struck Gold
On Sunday, 12 January 2014 at 19:05:59 UTC, Walter Bright wrote: On 1/12/2014 9:58 AM, deadalnix wrote: Code produced by dmd is not very gold compliant. That's a frustratingly meaningless comment - there's nowhere anyone can go with it. I know, but I have not much more infos. On some project I tested, depending on the version of gold I get either failure to link via some obscure internal gold failure or broken binaries. I started to dig in gold source code for a while to understand, but at some point time ran short and I had to give up. If gold is a necessity (like it was for me on that project) then switching to GDC is the best option for now. Gold behavior started to become erratic in the File_read::find_or_make_view zone.
Re: immutable bug?
On 1/12/14 12:35 PM, Timon Gehr wrote: On 01/12/2014 07:10 PM, Andrei Alexandrescu wrote: On 1/12/14 8:46 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:laugbo$2jcq$3...@digitalmars.com... Yep. Has this been placed in bugzilla? It's rather hi-pri. If this isn't https://d.puremagic.com/issues/show_bug.cgi?id=11503 - it most likely has the same cause. Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected. I select them with a focus on impact. Clearly the process could be improved. There are other serious problems with the type system implementation, eg: https://d.puremagic.com/issues/show_bug.cgi?id=9149 https://d.puremagic.com/issues/show_bug.cgi?id=10376 https://d.puremagic.com/issues/show_bug.cgi?id=9148 Thanks, will take those under advisement. FWIW there's been a thread taking suggestions. On a related note, I think it makes no sense to put a bounty on the Object not const-correct issue. What would someone be required to do in order to get the bounty for that issue? Make sure we have a complete solution for invoking Object's methods against const and immutable Objects? Andrei
Re: Componentizing D's garbage collector
On Sunday, 12 January 2014 at 17:15:44 UTC, Benjamin Thaut wrote: Am 12.01.2014 18:12, schrieb Brian Rogoff: How would the moving GC deal with pointer arithmetic? I don't see any problem with pointer arithmetic? Either the pointer is pointing to a gc managed memory block and will be patched accordingly, or it is not pointing to a gc managed memory block, and nothing will happen. Obviously if you do unsafe things, you have to know what you are doing and might give additional information to the gc so it can propperly support unsafe stuff. The garbage collection page of the D spec actually talks a lot about what is safe and unsafe (even though D doesn't have a moving collector). http://dlang.org/garbage.html
Re: Facebook puts more bounties on dlang issues
On 1/12/14 10:31 AM, Iain Buclaw wrote: On 12 January 2014 17:44, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/12/14 4:50 AM, Johannes Pfau wrote: Am Sun, 12 Jan 2014 11:32:04 + schrieb Iain Buclaw ibuc...@gdcproject.org: On 12 January 2014 00:19, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I've placed on behalf of Facebook a few more bounties on D-related issues. There's a bit of budget (a few hundred only) earmarked for GDC- and LDC-specific stuff. I didn't hear anything from Iain Buclaw (what's happening?) and am discussing with Kai Nacke the best angle of attack regarding LDC issues. I guess the last missing pieces in GDC (apart from specific bugs) are NRVO, exception chaining and LTO. I probably won't work on any of these issues though, that stuff is too complicated for me ;-) But if we could get some new contributors because of these bounties that'd be even better :-) One organizational/communication problem for me is that I've never been able to grasp where GDC is, what the milestones for integrations are, what the related issues are, and how to get from where we are to where we should. I've communicated with Iain over forum, email, IRC, Skype, and to be very honest I am unable to get simple answers to these simple questions (my accent was an issue in Skype communication). One thing I do recall is that Iain mentioned (I'm paraphrasing) that he hopes to underpromise and overdeliver, i.e. just finish integration instead of bragging about it before it being done. The unfortunate recoil from that is that I have no idea where he is in the process, and whether he could use any help. We need to work on our communication. Which probably means: I need to work on my communication. We all should. A good step: answer emails in which you're asked to shut up and take my money. Andrei
Re: Facebook puts more bounties on dlang issues
On 1/12/2014 2:51 PM, Andrei Alexandrescu wrote: answer emails in which you're asked to shut up and take my money. Dang, I never get emails like that.
Re: immutable bug?
On 01/12/2014 11:51 PM, Andrei Alexandrescu wrote: ... Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function Andrei This issue was trivial, and yet was assigned a higher bounty than e.g. fixing CTFE performance, which requires a large investment as far as I understand. This raises the question of how bountied issues are selected. I select them with a focus on impact. Clearly the process could be improved. ... I see. FWIW it _did_ get an issue fixed. There are other serious problems with the type system implementation, eg: https://d.puremagic.com/issues/show_bug.cgi?id=9149 https://d.puremagic.com/issues/show_bug.cgi?id=10376 https://d.puremagic.com/issues/show_bug.cgi?id=9148 Thanks, will take those under advisement. FWIW there's been a thread taking suggestions. ... (I know; at that time I didn't think those issues would qualify. :o)) On a related note, I think it makes no sense to put a bounty on the Object not const-correct issue. What would someone be required to do in order to get the bounty for that issue? Make sure we have a complete solution for invoking Object's methods against const and immutable Objects? Andrei Wasn't there a consensus that Object's methods are going away?
Re: AA literals/initialisation
On 1/12/14 2:27 PM, Brad Anderson wrote: I had to get this off my chest even if it's unlikely to be adopted: http://wiki.dlang.org/Simplified_Release_Process_Proposal cc Andrew Edwards Andrei
Re: Facebook puts more bounties on dlang issues
On 1/12/14 3:06 PM, Walter Bright wrote: On 1/12/2014 2:51 PM, Andrei Alexandrescu wrote: answer emails in which you're asked to shut up and take my money. Dang, I never get emails like that. Yah, the ones asking for money are more frequent :o). On a serious note, it would behoove our community to target a GCC release to integrate with and rally to get that done. Iain's role is crucial here. Andrei
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 23:37:12 UTC, Andrei Alexandrescu wrote: On 1/12/14 2:27 PM, Brad Anderson wrote: I had to get this off my chest even if it's unlikely to be adopted: http://wiki.dlang.org/Simplified_Release_Process_Proposal cc Andrew Edwards Andrei Done.
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 23:06:26 UTC, Walter Bright wrote: On 1/12/2014 2:51 PM, Andrei Alexandrescu wrote: answer emails in which you're asked to shut up and take my money. Dang, I never get emails like that. Royal families of African countries send me these on a regular basis. They really want my good.
Re: Rant on quality
I want to thank the DMD team as the different problem I face are solved in master. Still kind of sad that I end up once again to dev in master, but that's good. I was able to fix the regressions that introduced in my code while part of the test suite was not working. Hopefully nothing horrible happened. When do we plan to have these minor release with bug fixes ? I'd be willign to test them.
Re: immutable bug?
On 13 January 2014 07:06, Johnny Walking j...@redlabel.com wrote: On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote: ... I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding Remedy's 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something? I was doing very different work at that point, stressing totally different parts of the language - mostly meta stuff. And believe me, I had bugs, lots of them. I also had a direct hotline to Walter... I don't feel I have the authority to pester him directly or as frequently now ;) What doesn't come across in my posts is that the D experience today is _so much_ better than it was while I was doing the Remedy work. It's come a long way in terms of quality in the last 1-2 years, and generally gets better every day. I often remark to myself how relatively rare to is to run into compiler bugs today. But you know what seems to reliably make it better? Complaining about it. Well, that... and the work of all the awesome contributors! :) Silently adding workarounds to your code, and dropping a bug somewhere has significantly lesser effect. There's no other functional sense of priority I'm aware of, voting on issues has apparently little meaning. Issues that seem to get the most buzz in the forum seem to get fixed the fastest. I'm good as making noise ;)
Re: immutable bug?
On Monday, 13 January 2014 at 01:07:56 UTC, Manu wrote: On 13 January 2014 07:06, Johnny Walking j...@redlabel.com wrote: On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote: ... I'm just a bit confused, but recently I've seen many topics from Manu and problems which he's facing with D. So my question is: You don't had any problems when coding Remedy's 3D engine integration with D back then? (http://dconf.org/2013/talks/evans_1.html) or am I missing something? I was doing very different work at that point, stressing totally different parts of the language - mostly meta stuff. And believe me, I had bugs, lots of them. I also had a direct hotline to Walter... I don't feel I have the authority to pester him directly or as frequently now ;) What doesn't come across in my posts is that the D experience today is _so much_ better than it was while I was doing the Remedy work. It's come a long way in terms of quality in the last 1-2 years, and generally gets better every day. I often remark to myself how relatively rare to is to run into compiler bugs today. But you know what seems to reliably make it better? Complaining about it. Well, that... and the work of all the awesome contributors! :) Silently adding workarounds to your code, and dropping a bug somewhere has significantly lesser effect. There's no other functional sense of priority I'm aware of, voting on issues has apparently little meaning. Issues that seem to get the most buzz in the forum seem to get fixed the fastest. I'm good as making noise ;) I know the feeling with Dvorm and Cmsed's router. The amount of bugs I hit are horrendous. I'm not complaining about it or reporting them mainly because a) not on a head build and b) I'm literally pushing the compiler to its limits in some areas. Maybe once next version and it has all been announced I'll start on getting the common issues that a user might experience reported. But I suspect with these ones they aren't gonna be a simple fix. Although I am glad I am doing it now rather than a year ago. Mainly because I've learnt so much since then from the D community. I have to say more than any other in my past.
Re: immutable bug?
On Sunday, 12 January 2014 at 19:36:10 UTC, David Nadlinger wrote: On Sunday, 12 January 2014 at 18:09:59 UTC, Andrei Alexandrescu wrote: Put $150 on this. https://www.bountysource.com/issues/1325974-type-system-breaking-caused-by-implicit-conversion-for-the-value-returned-from-pure-function I posted a fix for this issue (i.e. the one on which the bounty was set). Now tackling Manu's example, which turns out to exhibit a slightly different bug. Filed as https://d.puremagic.com/issues/show_bug.cgi?id=11909, fix at https://github.com/D-Programming-Language/dmd/pull/3085. David
