Re: Range-Based Graph Search in D (blog post)
Trying to write a bit more about D on my blog now. To start, I've written about a proof-of-concept range-based API for graph search. http://poita.org/2014/01/09/range-based-graph-search-in-d.html I'd greatly appreciate any feedback on the design. As we don't yet have a graph library for D, it would be interesting to discuss APIs in general. I really like it, very elegant! Certain lines brought a smile to my lips :-) (using anonymous functions as graph parameters, for example). Much more elegant than my own graph code :) You wanted suggestions, here are a few. They come from my use of graphs: not so much as search-based, but as a way to store and modify 'relationships' (call graphs, import graphs) or to use them as support for state machines. * I sometimes have to use graphs with more than just `weight` on edges (names as strings, chars, for example for a state machine, etc). Do you think you could extend your design to allow parameterization on edges? Of course, to use the search algorithms, the user should provide an way to get a priority from the edges. Or any user-defined type could be used, ideally, as long as it provides a way to get a `size_t`. * I'd like a way to map on a graph (keeping the edge structure, but changing the nodes contents). I know I can map on your search result, but 1) I want a graph after mapping, not a range and 2) I don't want to search, I want to affect all nodes. * I'd like a way to iterate seeing only edges, not nodes. * I'd like a way to concatenate/link different graphs (a bit like chain for ranges). I sometimes have graphs that are assembled from many different small graphs, bottom-up style. Typically, if you assemble automata (from regexes, for example), you do it bottom-up. * Of course, I'd like a way to build a graph from nothing, putting nodes and then edges in them. * I sometimes need to extract some global information from a graph: number of nodes, number of edges, etc. * Does you design allow for backward iteration? (I mean, inverting the edges). Some graph algorithms ask for this kind of magic. * Getting strongly connected components is a very interesting algorithm to have. * you should define some template constraints on your types (Graph...), but I understand they can be added later on. Re-reading my suggestions, I see they would push your code toward my own attempts :-) I guess I'm biased. I have some (years old!) code in there: https://github.com/PhilippeSigaud/dranges/blob/master/graphrange.d https://github.com/PhilippeSigaud/dranges/blob/master/graph.d https://github.com/PhilippeSigaud/dranges/blob/master/graphalgorithm.d As for my (age old) vision on graph iteration, here it is: https://github.com/PhilippeSigaud/dranges/blob/master/recursive.d But yet again, nothing as elegant as your own code.
Re: Range-Based Graph Search in D (blog post)
On Thursday, 9 January 2014 at 22:53:02 UTC, qznc wrote: For the visitation API design: Your map approach (bool[Vertex] m_visited) is probably the most generic one. A variant, where the nodes store the flag internally is more efficient, though. Unless the graph is infinite ;-) But yes, for most graphs that would likely be more efficient than a hash lookup. I'll keep note of that. Thanks!
Re: Range-Based Graph Search in D (blog post)
On Friday, 10 January 2014 at 18:26:15 UTC, Joseph Rushton Wakeling wrote: On Friday, 10 January 2014 at 11:07:13 UTC, John Colvin wrote: Nice :) I presume you are aware of https://github.com/WebDrake/Dgraph Good inspiration for me to get back to work on that :-) @Peter -- this is really exciting to see and I will be looking into your work with great interest. Let me know if there is any overlap in our projects that we can make use of. At first glance (I'm in the midst of house-moves right now so can't give your code the attention it deserves immediately:-) it is interesting to see how our algorithms and problems of interest have resulted in different design concerns. We should definitely try and set up some mutual coding challenges to try and test scalability, performance etc. :-) I'm currently only in the exploratory phase, trying to iron out a simple but flexible API. Hard to say if there is or will be any overlap at this time. However, assuming both our designs are as generic as they hope to be, they should all be interoperable (perhaps with a bit of adaptation/forwarding)!
Re: Call D code from C#
On Friday, 10 January 2014 at 21:50:50 UTC, TC wrote: they lack modern features and portability and if I will be in position to choose UI framework for multiplatform business app, I will end up with Qt 5.x for sure. C++ remains the best tool for that job (Qt 5.x). And unfortunately, i do not have many hopes that it will change soon.
Re: Fedora RPMs
On Thursday, 5 December 2013 at 11:46:37 UTC, Martin Nowak wrote: Splitting in different packages is needed to comply with RPM guidelines, but it's a bad fit for a single binary installer on dlang.org. I'm working on a spec file for the latter. https://github.com/dawgfoto/installer/tree/fedoraSPEC It is not a requirement for no reason. You do not want to force users of your D application to install a D compiler, runtime source, etc, on every client machine, do you? Instead you would probably install just the runtime itself as a package. I have followed your recommendation regarding GitHub - now there is no need to host source packages elsewhere. Thanks for that.
Re: Call D code from C#
Am 11.01.2014 14:30, schrieb anthonyb: On Friday, 10 January 2014 at 21:50:50 UTC, TC wrote: they lack modern features and portability and if I will be in position to choose UI framework for multiplatform business app, I will end up with Qt 5.x for sure. C++ remains the best tool for that job (Qt 5.x). And unfortunately, i do not have many hopes that it will change soon. It will, but not in the direction most people would like. From what I can get from Qt conference videos since version 5 came out, QML is the way to go, with just performance critical parts still done in C++. -- Paulo
Re: Call D code from C#
Le 11/01/2014 18:23, Paulo Pinto a écrit : Am 11.01.2014 14:30, schrieb anthonyb: On Friday, 10 January 2014 at 21:50:50 UTC, TC wrote: they lack modern features and portability and if I will be in position to choose UI framework for multiplatform business app, I will end up with Qt 5.x for sure. C++ remains the best tool for that job (Qt 5.x). And unfortunately, i do not have many hopes that it will change soon. It will, but not in the direction most people would like. From what I can get from Qt conference videos since version 5 came out, QML is the way to go, with just performance critical parts still done in C++. -- Paulo I work every day on an application written in C++ with Qt and QML. The core of the application is written in C++ without Qt and only the GUI is in QML, some additionnal wrappers are necessary to inject data of the core application in QML. We have no performance issues with QML. Saddly for the moment I can't talk more about this application since it was not already released, but it's typically an application where performances are critical. Like with every script languages you need to do things with carefulness and avoid to put application logic in it. It's our experience give us the idea to do something similar in D, cause a lot of things can be better than with Qt and C++.
Re: Call D code from C#
On 2014-01-10 22:50, TC wrote: I looked at it and on the first sight it seems as a wrapper around GTK on linux side and native windows toolkit on windows. In this case I would probably rather use gtkd directly and hope for fewer problems. (but both should be tried and decided after that, DWT seems to be more OOP friendly so easier to use). It's quite a lot more than a wrapper. It's its own GUI toolkit. But yes, on Linux it uses GTK+. If I understand it correctly, its backed up with GTK2 on linux? (SWT seems to get GTK3 support in october 2013, but don't know if its already released). Yes, it uses GTK+. DWT is quite an old port, 3.4 to be exact. My point is, that GTKD, DWT are for sure pretty usable. But they lack modern features and portability and if I will be in position to choose UI framework for multiplatform business app, I will end up with Qt 5.x for sure. What do you mean lack portability? I'm currently working on the Mac OS X port. It seems that D is advancing to be ARM ready, wouldn't it be nice to be able to write UI apps for Android, iOS, WinRT, whatever in D? Yeah, of course. The advantage of DWT is that is uses the native toolkit on each platform (Linux doesn't really have one). No additional libraries are required except for the system libraries. -- /Jacob Carlborg
Re: Mobile App STACK4 with a D backend
On Saturday, 11 January 2014 at 13:11:51 UTC, Arjan wrote: On Sunday, 22 December 2013 at 13:38:22 UTC, extrawurst wrote: Hello fellow Dlers ;) about a week ago I released the multiplayer version of my android app STACK4 (https://play.google.com/store/apps/details?id=com.Extrawurst.FIR). Tested on a Nexus 4 (local only) works OK. Buttons and text are very small almost unreadable for me. yeah the resolution is a problem, it is high on my list to rework the GUI. but right now there is too much other stuff to doo ;( Also red your first 2 articles, hope you dive deeper in to the more 'technical stuff' in the once to follow. Really great you're doing this! yeah the next article shows some actual code, if that is what you are asking for. but still i need to leave some stuff for my dconf submission ^^
Re: std.signal : voting has begun
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote: Some time ago there have been a review for `std.signal` Phobos proposal (http://forum.dlang.org/thread/ujlhznaphepibgtpc...@forum.dlang.org#post-ujlhznaphepibgtpcoqz:40forum.dlang.org). It have not received much feedback and I was a it too busy to proceed with final voting at that moment but with no outstanding issues to address nothing prevents that final step. Let's put 2 week deadline to refresh memories about the proposal and make some decision. Voting closes at January 20th 23:59 GMT 0 Please take some time and help make Phobos better ;) Yes. I use it, it's been rock solid so far.
Re: Call D code from C#
On 11.01.2014 19:33, Xavier Bigand wrote: Le 11/01/2014 18:23, Paulo Pinto a écrit : Am 11.01.2014 14:30, schrieb anthonyb: On Friday, 10 January 2014 at 21:50:50 UTC, TC wrote: they lack modern features and portability and if I will be in position to choose UI framework for multiplatform business app, I will end up with Qt 5.x for sure. C++ remains the best tool for that job (Qt 5.x). And unfortunately, i do not have many hopes that it will change soon. It will, but not in the direction most people would like. From what I can get from Qt conference videos since version 5 came out, QML is the way to go, with just performance critical parts still done in C++. -- Paulo I work every day on an application written in C++ with Qt and QML. The core of the application is written in C++ without Qt and only the GUI is in QML, some additionnal wrappers are necessary to inject data of the core application in QML. We have no performance issues with QML. Saddly for the moment I can't talk more about this application since it was not already released, but it's typically an application where performances are critical. Like with every script languages you need to do things with carefulness and avoid to put application logic in it. It's our experience give us the idea to do something similar in D, cause a lot of things can be better than with Qt and C++. Thanks for sharing the information. At work I do mostly JVM/.NET stuff. Since 2006 I don't do any C++ at work, except when porting stuff to the former platforms. I just use Qt/C++ occasionally on hobby projects, so it is good to know from someone with experience on them, how the real situation is. -- Paulo
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 07:50:56 UTC, 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 Some comments: * `empty` is a property - do not append parentheses/call syntax * `!find().empty` = `canFind` or `any` * `ifind_first/last` can use `find!((a, b) = a.toLower() == b.toLower())` * I think the Phobos equivalent of `find_tail` needs a second `retro`? * I don't like the idea of adding a predicate to joiner, I think using filter is better 1. They have case-insensitive versions of pretty much everything. It's not hard to do a map!toLower/toUpper in D but it's also not obvious (nor do I know if that's actually correct in languages outside of english). There are two pairs of toLower/toUpper - the ones in std.ascii and std.uni (the std.string pair aliases to std.uni). The latter pair works correctly for all scripts. 2. Replace and erase options a very slim. Doing something like a chain() on the results of findSplit() and what you want to inject I guess would work for replacing but that's really not very elegant. remove() is simply way too cumbersome to use. I guess you could use indexOf, then indexOf again with a slice with the first result, then pass both two a tuple in remove. That's terrible though. I think the mutation algorithms in std.algorithm can handle most of these when used in conjunction with other algorithms, except that narrow strings do not have the property of assignable elements, which is kind of a fatal blow.
Re: Should this work?
On Saturday, 11 January 2014 at 03:49:28 UTC, Manu wrote:
On 11 January 2014 00:26, monarch_dodra
*However*, depending on the range type (non-transitive),
popping might
instantaneously invalidate the element you are operating on
(think
byLine, that returns a char[], not a string).
Since you mentioned it here yesterday, I thought 'byLine' would
be useful
this morning... but I can't find it!
This is an embarrassing theme.
Does it actually exist, and I am even further retarded... or
did you just
make that up?
It's because not actually a range adaptor or string adaptor, but
an stdio function:
http://dlang.org/phobos/std_stdio.html
http://dlang.org/phobos/std_stdio.html#.File.byChunk
http://dlang.org/phobos/std_stdio.html#.File.byLine
It's designed that way as to avoid allocating a new buffer.
Related:
That said, std.algorithm.splitter will lazily split a range of
characters into lines, if you give it the right terminator.
Unfortunately, it only accepts a single terminator, or a pred, so
you can't do splitter('\n' \r\n).
You can also use
http://dlang.org/phobos/std_string.html#.splitLines; to eagerly
and conveniently (and correctly) do this.
Re: Componentizing D's garbage collector
On 11.01.2014 00:58, deadalnix wrote: On Friday, 10 January 2014 at 20:37:53 UTC, Rainer Schuetze wrote: I think this might help in having different heaps (especially thread local heaps if you include shared), but I'm not sure this works in unsafe D where casting is allowed. One of the key to a fast GC is segregating the heap in smaller parts. This is why generational collectors are so popular in java for instance. Segregating the heap imply so complications. For instance, it is necessary to track reference from one heap to another, typically from young to older objects. In D, the type system provide a natural segregation. It would be a great missed opportunity to not take advantage of it. This segregation is really nice as pointers go from one to another in a single direction, avoiding the need to track references changes, and all element of the heap part share some common characteristics. These characteristics allow for specialized GC algorithms (for instance, a GC can run on the immutable heap without the program even knowing about it). Casting is by essence bypassing the type system. In this case, you must be help responsible for what happen. The language cannot provide guarantees. This might work with safe D. I haven't yet figured the consequences of implicit heap segregation by type. What restrictions will this impose on system programming? As compacting data is also pretty problematic as long as part of the scanning is conservative, we might as well consider storing generation and type information per allocation. This will destroy some optimization possibilities, though.
Re: Componentizing D's garbage collector
On 10.01.2014 22:42, Andrei Alexandrescu wrote: On 1/10/14 12:37 PM, Rainer Schuetze wrote: * At this point I won't worry about discovering roots; I assume druntime has the appropriate mechanisms in place. It currently does not have precise information, but it is dearly needed, too. Yah, that's where I'm counting on your work :o). 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. * I plan to rely on static introspection for the mark function, i.e: void mark(T)(ref T obj); would mark obj and everything transitively referred to by it. The function would probably take a second parameter that's the heap that obj is sitting in. I guess the mark function will be stored somewhere in the TypeInfo. How is this going to work with dynamic and associative array operations if these are not also templated? I need to write some code to explain it all. An figure it all :o). Waiting eagerly for the code :-) * I plan to segregate all objects that don't include references and pointers (e.g. int, int[], Tuple!(int, double) etc) into a completely different heap than the interesting objects. For the simpler objects there's no need to save detailed type information so they can be stored in a more compact, efficient manner. So no more std.emplace? std.emplace will continue to work as a way to build an object at a specified address. I suspect that allocating and manipulating objects on the GC heap in particular may have certain restrictions. One possibility to avoid such restrictions is to have a function typify(T)(void* p) which ascribes type T to heap location p. That sounds similar to my gc_emplace function. The problematic part is how to save that information in the GC. * At this point I'm unclear on how generations can be componentized, but am cautiously optimistic. Will see once I get to it. One thing that would be great now would be to make an effort to review and merge the current precise GC work. I'm sure it will be of great help with breaking into components. As written in the other thread (how to contribute to GC), I have just made an attempt to make it more reviewable: https://github.com/rainers/druntime/commits/gcx_precise2 The necessary compiler fixes are here: https://github.com/D-Programming-Language/dmd/pull/2480 Yah, time for you to get some destruction first :o). Ready to get some blows...
Re: If you had money to place for a bounty, what would you choose?
Am 11.01.2014 04:19, schrieb Brad Anderson: On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson wrote: On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling wrote: On 28/11/13 22:01, Fra wrote: What would your choice be? A really good overhaul of the website, forums etc. from a UI/UX perspective. A good number of the problems we have with D aren't problems with the language or libraries, they're problems with people finding the right information on how to work with D. +1 I'd pay to see vibe.d entered in this: http://www.techempower.com/benchmarks/ Notwithstanding the gaming that goes in benchmarking, I think not being present is a missed opportunity. Sönke has already started work on this: https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d I'm not sure what remains for it to be integrated. Once I discussed with the responsible guy over at HN. I would say he is pretty open to have D as well, he just had some issues getting it up. -- Paulo
Re: core.sys.windows.windows and TCHAR
On Friday, 10 January 2014 at 00:37:07 UTC, Adam D. Ruppe wrote: Can we change this to alias wchar instead of char? While this would be a breaking change, the ASCII Windows functions are arguably always wrong to use with D since a D char* is NOT an ascii nor Windows encoded string, so any code it breaks was already (perhaps) broken and should be changed anyway. It may opreate in a controlled environment, where all characters are ascii. I hate such assumptions though. I know there's other win32 bindings we can download, but for just the common types, I like to use the built in aliases, and TCHAR, TSTR, etc., are common in copy/pasted MSDN code and can easily be subtly wrong with this. A compromise I'd accept is putting the wchar aliases under a version(Unicode) so it is opt-in. version(Unicode) is a bug in itself. I'd say, drop ansi bindings entirely, they exist only for source-compatibility with C code written for win9x.
Re: What's going on here?
On Friday, January 10, 2014 07:24:43 monarch_dodra wrote: On Friday, 10 January 2014 at 05:34:27 UTC, Andrei Alexandrescu wrote: It's a bug in the compiler. Evaluation should proceed as if it were strictly left to right. So test(size) must be called before size is loaded to construct the slice. Please report. Andrei I remember this conversation popping up repeatedly. *Did* we ever make the choice to enforce this? I mean, is this part of the spec now? When did it happen? I seem to remember Walter was always against it. Walter has stated that he wanted to, but AFAIK, it never actually became official. But knowing how things tend to go around here, even if Walter, Andrei, and all of the main devs thought that it was official, it still probably wouldn't be in the spec. - Jonathan M Davis
Reference to DUB package list
As a newcomer, I would suggest to add a direct link to http://code.dlang.org/ on the dlang.org page. Maybe to community section? Its list is getting big and I had to read many articles to event notice that something like DUB exists. It is a great starting point to search something that is not in a phobos itself.
Re: What's going on here?
On Saturday, 11 January 2014 at 11:03:22 UTC, Jonathan M Davis wrote: Walter has stated that he wanted to, but AFAIK, it never actually became official. But knowing how things tend to go around here, even if Walter, Andrei, and all of the main devs thought that it was official, it still probably wouldn't be in the spec. - Jonathan M Davis It is in the spec[1]. [1] http://dlang.org/expression.html
Re: Should this work?
On Saturday, 11 January 2014 at 02:15:15 UTC, Manu wrote: That is the world today, that is where the bar is. D will be wildly successful on the day that programmers that have never seen it before can come along, effortlessly write whatever code they're trying to write, offered useful help by the compiler along the way, walk away feeling really smart and happy with their experience. That is not a D I want to be part of. Let's give a container library to someone that knows nothing of containers, they'll say what's with all these 'red-black trees' and 'linked lists'? I just want to store a bunch of numbers!, so you streamline the design to one container that does everything in O(n) time or better. Much simpler than the user having to learn anything, and they can get things done effortlessly and feel smart and happy. Let's get rid of value types and just heap allocate everything in the GC and make copies on every write. Much easier than learning about object lifetime and mutability. Let's get rid of static typing and make D dynamically typed. Much easier than learning about type systems. That's what D becomes if users aren't willing to RTFM. There are trade-offs in language/library design and D has traded some convenience for efficiency. You cannot have the high-performance and powerful modelling capabilities of ranges with unbounded convenience. I'm not saying convenience isn't important, but things like ranges have subtleties, and need those subtleties to achieve the performance/power they were designed for. If you want that, you'll need to bite the bullet and learn, if you don't, then just go and write Python. 3
Re: Componentizing D's garbage collector
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? Kind Regards Benjamin Thaut
Re: Should LLVM become the default D-lang platform?
On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote: Because Walter wouldn't be able to work on his current job any longer if he looks into other compiler vendors source code. IP laws are always a complicated issue. Unless you have an actual explanation as to why this would be the case, I'd simply regard this as FUD. I see how the viral nature of the GCC license might be a problem for that, but as far as LLVM is concerned, Walter would even be able to just rebrand Clang as DMC and ship it as a closed-source package. LLVM also doesn't require any copyright assignments, which might be an impediment for contributing any fixes back to GCC. David
Re: A strongly pure PRNG
On Saturday, 11 January 2014 at 10:19:00 UTC, Kagamin wrote: Formally it is immutable, see line 36. Well, by breaking the type system you can make every PRNG immutable. ;) David
Re: Does the dub registry at code.dlang.org have problems?
On Friday, 10 January 2014 at 22:07:41 UTC, Paulo Pinto wrote: Am 10.01.2014 22:16, schrieb Gary Willoughby: On Friday, 10 January 2014 at 20:57:51 UTC, Paulo Pinto wrote: I used to be an heavy Tcl/Tk user on Windows NT/2000 during 1999 - 2001. Tk only imports X11 on UNIX platforms. http://core.tcl.tk/tk/tree?ci=tip -- Paulo Looking at tk.h i see this: #ifndef _XLIB_H # if defined(MAC_OSX_TK) #include X11/Xlib.h #include X11/X.h # else #include X11/Xlib.h # endif #endif Which intimates to me that all platforms include it? Then tkDecls.h uses types that the X11 headers define, e.g (XColor): EXTERN int Tk_CanvasPsColor(Tcl_Interp *interp, Tk_Canvas canvas, XColor *colorPtr); Yes, but if you cared to look at the rest of the code, you would have seen that those X11 calls are mapped to Win32 ones. Maybe I should have expressed myself better. -- Paulo I understand that the X11 calls will be translated to the Win32 Api on Windows in the Tk source but i was talking about the headers. I think i have found the problem. At first glance dub seems to dumbly compile *everything* in the source directory whether it's imported or not and in this case that's a problem. In a few of the X11 D source files, C macros are substituted using functions which call other X11 functions which the linker then cannot resolve. If i compile using the command line on Windows then only x.d and xlib.d are in fact compiled which have no calls to any X11 function so there are no linker errors regarding X11. Now i just need to understand linking tcl/tk on windows using the optlink linker but that's a new thread :) http://forum.dlang.org/thread/xbrciixzdwkoysnny...@forum.dlang.org
Re: Should this work?
On 11 January 2014 21:29, Peter Alexander peter.alexander...@gmail.comwrote: On Saturday, 11 January 2014 at 02:15:15 UTC, Manu wrote: That is the world today, that is where the bar is. D will be wildly successful on the day that programmers that have never seen it before can come along, effortlessly write whatever code they're trying to write, offered useful help by the compiler along the way, walk away feeling really smart and happy with their experience. That is not a D I want to be part of. Let's give a container library to someone that knows nothing of containers, they'll say what's with all these 'red-black trees' and 'linked lists'? I just want to store a bunch of numbers!, so you streamline the design to one container that does everything in O(n) time or better. Much simpler than the user having to learn anything, and they can get things done effortlessly and feel smart and happy. Let's get rid of value types and just heap allocate everything in the GC and make copies on every write. Much easier than learning about object lifetime and mutability. Let's get rid of static typing and make D dynamically typed. Much easier than learning about type systems. That's what D becomes if users aren't willing to RTFM. There are trade-offs in language/library design and D has traded some convenience for efficiency. You cannot have the high-performance and powerful modelling capabilities of ranges with unbounded convenience. I'm not saying convenience isn't important, but things like ranges have subtleties, and need those subtleties to achieve the performance/power they were designed for. If you want that, you'll need to bite the bullet and learn, if you don't, then just go and write Python. 3 *sigh* If you can't see value in intuitive design as a basic principle, then my points about people on this forum being so disconnected from the world of normal programmers is even more true than I thought. Particularly if you find the concept so threatening that you need to make dumb comments mocking the principle. I never suggested making technological concessions for the principle, just keep it in clear focus while designing your APIs. Do user testing, get better feedback, identify common pitfalls. I'm just talking about quality, and greater consideration wrt api design and more user testing before committing new features to the slate.
Re: Should this work?
On Saturday, 11 January 2014 at 12:22:44 UTC, Manu wrote: *sigh* If you can't see value in intuitive design as a basic principle, then my points about people on this forum being so disconnected from the world of normal programmers is even more true than I thought. Particularly if you find the concept so threatening that you need to make dumb comments mocking the principle. I never suggested making technological concessions for the principle, just keep it in clear focus while designing your APIs. Do user testing, get better feedback, identify common pitfalls. I'm just talking about quality, and greater consideration wrt api design and more user testing before committing new features to the slate. In our defense, I've found that whenever I *do* find the APIs lacking, it is in contrast to how powerful it is to begin with. I've done things in D I would have never *dreamed* of doing in C++. You kind of get used to If it can be done, there's a D 1-liner for it. However, it's not actually the case. It doesn't necessarily mean the API is lacking though (IMO). Also, the concepts of ranges and built in UTF is relatively new. In C++, there are a ton of string operations you are supposed to do via iterators and algorithms. However, once you take unicode into account, it tends to fall short, and you start realizing that a string specific function is necessary (because of UTF) when the standard algorithm approach used to be correct. The very fact that a string is bidirectional and not random access (in terms of codepoints) is also something... you have to get used to.
Re: Should this work?
On 11 January 2014 01:37, Manu turkey...@gmail.com wrote:
On 11 January 2014 05:57, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/10/14 7:23 AM, Manu wrote:
This is what I've done. I'm just surprised that such an obvious function
doesn't exist, and suspect I was just retarded at phobos again.
Having a function that does this is kinda important to simplify lots of
expressions that otherwise need to be broken out across a bunch of lines.
I doubt it simplifies a lot.
Well you can pass it as an argument, or use it as a term in an expression
without splitting it across a whole bunch of lines.
Yes, it really does simplify many expressions.
I'm working on something where I go along munching tokens from the stream,
and performing fairly arbitrary sequential logic on them.
My code would be almost twice as long if I needed a second line to advance
the range after each line where I consider the front token's value.
It sucks particularly when there's 'if's involved:
if(r.front == x)
{
r.popFront();
x = r.front();
r.popFront();
}
else
{
r.popFront();
y = r.front();
r.popFront();
}
Surely this is obviously better:
if(r.getAndPopFront() == x)
x = r.getAndPopFront();
else
y = r.getAndPopFront();
I recall mentioning something like this, way back in 2011 - possibly
in IRC. People like the idea, no one actually sat down and wrote it.
:-)
Regards
Iain
Re: Phobos strings versus C++ Boost
On 2014-01-11 07:50:54 +, Brad Anderson e...@gnuk.net said: 1. They have case-insensitive versions of pretty much everything. It's not hard to do a map!toLower/toUpper in D but it's also not obvious (nor do I know if that's actually correct in languages outside of english). Uppercase, lowercase, and case-insensitive comparison is locale-dependent for Unicode. In the general case you can't just compare the lowercase/uppercase versions. For instance, look at the Turkish i/İ and ı/I (dot-less i), or the German ß/SS ss/SS pairs. Also, if you're sorting in alphabetical order you probably want to do something special with diacritics. The correct way to to this is to implement the Unicode Collation Algorithm: http://www.unicode.org/reports/tr10/ -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Should LLVM become the default D-lang platform?
On 11 January 2014 00:24, Manu turkey...@gmail.com wrote: On 11 January 2014 06:59, Iain Buclaw ibuc...@gdcproject.org wrote: On 10 January 2014 20:54, John Colvin john.loughran.col...@gmail.com wrote: On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote: This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets. This comes up regularly. It's already been done. Ldc *is* dmd with llvm backend. Gdc is the same idea but with the gcc framework. Indeed. But naturally I'd suggest they move to GCC. ;-) Is it possible that GDC will ever produce binaries that will link against the microsoft libs without problems? In my experience, GDC produces intrinsic calls to its own runtime all over the place, and it's not compatible with the microsoft runtime. I also recall library format mismatch, but that was a long time ago, and I think we discussed it again since deciding that GDC is now using the same format as VisualC in windows...? Can GDC write PDB debuginfo into the objects (CV8 I think it is)? As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format?
Re: Should LLVM become the default D-lang platform?
On 11.01.2014 12:58, David Nadlinger wrote: On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote: Because Walter wouldn't be able to work on his current job any longer if he looks into other compiler vendors source code. IP laws are always a complicated issue. Unless you have an actual explanation as to why this would be the case, I'd simply regard this as FUD. I see how the viral nature of the GCC license might be a problem for that, but as far as LLVM is concerned, Walter would even be able to just rebrand Clang as DMC and ship it as a closed-source package. LLVM also doesn't require any copyright assignments, which might be an impediment for contributing any fixes back to GCC. David As far as I remember he already had a few court cases caused by such kind of issues. He is the best person to explain such issues, I would say. -- Paulo
Re: Should LLVM become the default D-lang platform?
On 11 January 2014 11:58, David Nadlinger c...@klickverbot.at wrote: On Friday, 10 January 2014 at 21:00:24 UTC, Paulo Pinto wrote: Because Walter wouldn't be able to work on his current job any longer if he looks into other compiler vendors source code. IP laws are always a complicated issue. Unless you have an actual explanation as to why this would be the case, I'd simply regard this as FUD. I see how the viral nature of the GCC license might be a problem for that, but as far as LLVM is concerned, Walter would even be able to just rebrand Clang as DMC and ship it as a closed-source package. LLVM also doesn't require any copyright assignments, which might be an impediment for contributing any fixes back to GCC. Remember when I told you that LLVM devs reverted commits made by core GCC developers because apparently there was no explicit contribution by them to LLVM? :-)
Re: Should LLVM become the default D-lang platform?
On Saturday, 11 January 2014 at 13:22:52 UTC, Iain Buclaw wrote: Remember when I told you that LLVM devs reverted commits made by core GCC developers because apparently there was no explicit contribution by them to LLVM? :-) I don't recall the details, but I don't see how this is relevant to this discussion. There is a difference between requiring copyright assignment from contributors and being cautious about including code that you suspect to be incompatible with the (more liberal) license of your project. David
Re: Should LLVM become the default D-lang platform?
On Saturday, 11 January 2014 at 13:16:40 UTC, Paulo Pinto wrote: He is the best person to explain such issues, I would say. …which is precisely why I found it odd that you posted such an unqualified umbrella statement here in the first place. ;) No offense intended, but just speculating about Walter's motives doesn't really help the discussion at all. If I remember correctly, Walter joined the last bigger discussion on this issue here on the NG a year ago or so, and licensing issues were *not* one of the arguments that lasted. David
Re: [Binutils support] Add demangling to libiberty
On 10 January 2014 20:05, H. S. Teoh hst...@quickfur.ath.cx wrote: On Fri, Jan 10, 2014 at 05:51:17PM +, Iain Buclaw wrote: One of the binutils devs suggested this, to move D demangling into libiberty, that way binutils programs (and any other program that uses libiberty in a similar manner) will gain D support. [...] Yes! Please do!! This will go a long way in helping D get stronger tool support, at least on GNU platforms. This is a start. Unfortunately through testing, it becomes more apparently that the ability to demangle templates is absolute key here to the success of this. Without demangling: $ ./ld/ld-new test.o 21 | grep -v __T ./ld/ld-new: warning: cannot find entry symbol _start; defaulting to 00400120 test.o: In function `main': /opt/usr/include/d/4.9.0/__entrypoint.di:59: undefined reference to `_d_run_main' test.o: In function `_Dmain': /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `_D3std4math3tanFNaNbNeeZe' test.o: In function `test._D4test9__modinitFZv': /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `_Dmodule_ref' /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `_Dmodule_ref' test.o:(.data+0x10): undefined reference to `_D3std4math12__ModuleInfoZ' With demangling: $ ./ld/ld-new test.o --demangle=dlang 21 | grep -v __T ./ld/ld-new: warning: cannot find entry symbol _start; defaulting to 00400120 test.o: In function `main': /opt/usr/include/d/4.9.0/__entrypoint.di:59: undefined reference to `_d_run_main' test.o: In function `D main': /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `std.math.tan(real)' test.o: In function `test._D4test9__modinitFZv': /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `_Dmodule_ref' /home/iain/src/gdc/gdb/objdir/test.d:5: undefined reference to `_Dmodule_ref' test.o:(.data+0x10): undefined reference to `std.math.moduleinfo$' Anyway, here's the guts of the change. https://github.com/ibuclaw/gdb/commit/45c505dbc0eecb9fa7842dcbdf46894e450c9cbc Regards Iain.
Re: A strongly pure PRNG
Only the cast breaks the type system, I go through holes. It's just a joke, purity and immutability are valued for their deterministic traits, so a random number generator is the last thing one would want to make pure or immutable.
Re: Should this work?
Am Sat, 11 Jan 2014 10:40:25 +1000
schrieb Manu turkey...@gmail.com:
On 11 January 2014 01:20, John Colvin john.loughran.col...@gmail.comwrote:
On Friday, 10 January 2014 at 15:19:39 UTC, John Colvin wrote:
On Friday, 10 January 2014 at 15:05:18 UTC, monarch_dodra wrote:
On Friday, 10 January 2014 at 14:31:31 UTC, John Colvin wrote:
or if you want something short and simple, define a free function:
auto popFrontRet(R)(ref R range)
if(isInputRange!R)
{
range.popFront();
assert(!range.empty);
return range.front;
}
*Unless* I'm mistaken, he was asking for something that returns the
*popped* element?
Re-reading the question, it does kind of sound a bit ambiguous now.
Woops, of course:
auto popFrontRet(R)(ref R range)
if(isInputRange!R)
{
auto tmp = range.front;
range.popFront();
}
That also invalidates my second point to do with emptiness.
ugh, today is not my day:
auto popFrontRet(R)(ref R range)
if(isInputRange!R)
{
auto tmp = range.front;
range.popFront();
return tmp;
}
This returns garbage for ranges that reuse their internal
buffer for performance reasons. E.g. byLine will overwrite
what tmp points to in the call to popFront();
Yes, this is what I did. It should be added to phobos, but I figured
there's a reason it's not there...
My point was, I want this more often than I want either of those other
primitives. I'm surprised it doesn't exist, and suspected I was just being
blind again.
I also wrote popFrontRetN to capture more than one element from the start.
What about take(n) or take(n).array() ?
--
Marco
Re: Should LLVM become the default D-lang platform?
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote: This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets. You currently can't get the best of all worlds in a single compiler. LLVM does not support exceptions on native Win32. (Same is true for Win64 but I hope to change this.) LLVM does not support CodeView debug symbols. Not in the format embedded in object file and not as PDB. In short, you loose the complete native Windows tool chain. With LDC, you can use other platforms. E.g. it runs on Linux/PPC64. But you can't ignore the backend because it has bugs and is incomplete. E.g. on Linux/ARM I have a linker error when I enable generation of debug symbols. LLVM for arm-apple-darwin does not support TLS. LLVM for PPC supports only 2 of the 4 TLS models. In addition, the assembler for PPC/PPC64 does not support all instructions I need for std.math. Regards, Kai
Re: Should this work?
Am Sat, 11 Jan 2014 10:56:32 +1000 schrieb Manu turkey...@gmail.com: On 11 January 2014 02:28, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/10/14 6:02 AM, Manu wrote: I won't start another annoying thread. Great idea. What's the go with popFront()... it returns nothing? I almost always want to pop and return the front element. I can't find a function to do that... have I missed something again? http://dlang.org/phobos/std_range.html#.dropOne What do you want us to do, RTFM to you? That's not what I want at all. Maybe moveFront is what I want... but it's not clear. It doesn't really say what it does in the docs. Looking at the code, it's way more complex than I'd expect, and I can't see anywhere that it pops it from the range, which leads me to suspect it's not what I want either. I have no idea what moveFront is. I think it is a function to move items out of a container. I.e. move the ownership to the caller and leave the slot in the container in a harmless/.init state. -- Marco
Re: A strongly pure PRNG
On 11/01/14 15:12, Kagamin wrote: Only the cast breaks the type system, I go through holes. It's just a joke, purity and immutability are valued for their deterministic traits, so a random number generator is the last thing one would want to make pure or immutable. That depends on your concept of a PRNG. Strictly speaking it can/should consist of (i) an immutable state (ii) a pure function that takes as input the current immutable state and returns a new immutable state. In practice, of course, it's almost invariably easier to implement this as a type that has mutable internal state.
Re: Should LLVM become the default D-lang platform?
Am Fri, 10 Jan 2014 13:44:52 -0800 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: We plan to rig Facebook's build system to use dmd in debug mode and gdc in release mode by default. Best of both worlds. Andrei I do that too, and part of the reason why I hacked something together for the Gentoo Linux package manager, so I could install libraries for multiple compilers at once. It seems so trivial to use dmd and a companion compiler gdc or ldc, but once shared libraries and multiple D releases come into the mix, it means patching up dmd, make files and dealing with rpath to load the correct .so (compiler using a specific compiler vendor/version combination). -- Marco
Re: Should LLVM become the default D-lang platform?
Am 10.01.2014 21:56, schrieb John Colvin: also, the digital mars backend is very fast, which is actually good selling point for some use-cases where compilation speed is important. I would also prefer to keep the digital mars backend for exactly that reason. The GCC and LLVM backends are just way to slow. Kind Regards Benjamin Thaut
Re: Should LLVM become the default D-lang platform?
On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote: As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format? There are plenty of PDB parsers available, so it should be possible to uncover the format from there. Here's one. https://code.google.com/p/pdbparse/
Re: Review of std.signal
On 2013-11-07 13:45:56 +, Dicebot said: Our current victim is std.signal by Robert Klotzner which is supposed to deprecate and supersede existing (and broken) std.signals 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. -- Robert M. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: Should LLVM become the default D-lang platform?
On 11 Jan 2014 16:55, Peter Alexander peter.alexander...@gmail.com wrote: On Saturday, 11 January 2014 at 13:04:13 UTC, Iain Buclaw wrote: As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format? There are plenty of PDB parsers available, so it should be possible to uncover the format from there. Here's one. https://code.google.com/p/pdbparse/ But just to clarify, that is a reverse engineering effort?
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 12:47:12 UTC, Michel Fortin wrote: On 2014-01-11 07:50:54 +, Brad Anderson e...@gnuk.net said: 1. They have case-insensitive versions of pretty much everything. It's not hard to do a map!toLower/toUpper in D but it's also not obvious (nor do I know if that's actually correct in languages outside of english). Uppercase, lowercase, and case-insensitive comparison is locale-dependent for Unicode. In the general case you can't just compare the lowercase/uppercase versions. For instance, look at the Turkish i/İ and ı/I (dot-less i), or the German ß/SS ss/SS pairs. Also, if you're sorting in alphabetical order you probably want to do something special with diacritics. The correct way to to this is to implement the Unicode Collation Algorithm: http://www.unicode.org/reports/tr10/ I thought it was probably more complicated than that. Looks like Dmitry put it in the tracker: http://d.puremagic.com/issues/show_bug.cgi?id=10566
immutable bug?
I just managed to assign a const(char)[] to a string... caused crashes when
the original memory disappeared.
inout(char)[] todstr(inout(char)* cstr) pure nothrow
{
return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 .. 0];
}
struct Data
{
char buffer[256] = void;
@property const(char)[] filename() const pure nothrow { return
todstr(buffer.ptr); }
}
struct MyThing
{
private this(in Data* p)
{
filename = p.filename; // *** Uh oh! assigned a const(char)[] @property to
a string! ***
}
string filename;
}
Surely that assignment shouldn't be legal? Shouldn't I need to idup?
GDC and Fedora 20
I think there was a flurry of activity about this in 2011 and probably more recently, but… GDC appears not to be available on Fedora 20. Fedora is GCC 4.8 but has no GDC, Debian is also 4.8 and has GDC. So is there anywhere to get an RPM of the 4.8 version of GDC for Fedora 20? If there is great, if not and someone has a spec file, I have some machine cycles I can use to create an RPM (yes I do know that GCC takes about 200 hours to compile). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: immutable bug?
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
I just managed to assign a const(char)[] to a string... caused
crashes when
the original memory disappeared.
inout(char)[] todstr(inout(char)* cstr) pure nothrow
{
return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 ..
0];
}
struct Data
{
char buffer[256] = void;
@property const(char)[] filename() const pure nothrow { return
todstr(buffer.ptr); }
}
struct MyThing
{
private this(in Data* p)
{
filename = p.filename; // *** Uh oh! assigned a const(char)[]
@property to
a string! ***
}
string filename;
}
Surely that assignment shouldn't be legal? Shouldn't I need to
idup?
I don't know about the details of what is/isn't legal here, but
the only reason the compiler accepts it is because filename is
marked as pure.
Re: immutable bug?
On Saturday, 11 January 2014 at 18:43:39 UTC, John Colvin wrote: I don't know about the details of what is/isn't legal here, but the only reason the compiler accepts it is because filename is marked as pure. It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable.
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 08:25:39 UTC, Jakob Ovrum wrote: Some comments: * `empty` is a property - do not append parentheses/call syntax *Nod* * `!find().empty` = `canFind` or `any` The documentation needs to be improved for canFind then. It takes an `E needle` so I assumed it was an element type only. The other overload of canFind takes `Ranges needles` and stops when it finds just one of them so I assumed it'd be called in the case assert(123.canFind(321)) and would be true (0). Looks like the first overload just hands off to find() which can do either element type or a subrange but that's not clear from the documentation. any() needs some examples. I'm not sure how it'd be used for this purpose. I'll try to make some pull requests to fix both of these doc issues. * `ifind_first/last` can use `find!((a, b) = a.toLower() == b.toLower())` Yeah, but as Michael pointed out this isn't really a valid way to do case-insensitive comparison anyway. * I think the Phobos equivalent of `find_tail` needs a second `retro`? Yeah, very ugly. * I don't like the idea of adding a predicate to joiner, I think using filter is better I just figured for consistency since so much of std.algorithm accepts a predicate. I'm not opposed to sticking with filter though. 1. They have case-insensitive versions of pretty much everything. It's not hard to do a map!toLower/toUpper in D but it's also not obvious (nor do I know if that's actually correct in languages outside of english). There are two pairs of toLower/toUpper - the ones in std.ascii and std.uni (the std.string pair aliases to std.uni). The latter pair works correctly for all scripts. 2. Replace and erase options a very slim. Doing something like a chain() on the results of findSplit() and what you want to inject I guess would work for replacing but that's really not very elegant. remove() is simply way too cumbersome to use. I guess you could use indexOf, then indexOf again with a slice with the first result, then pass both two a tuple in remove. That's terrible though. I think the mutation algorithms in std.algorithm can handle most of these when used in conjunction with other algorithms, except that narrow strings do not have the property of assignable elements, which is kind of a fatal blow. Something needs to be done about this. I'm not sure what.
Re: immutable bug?
On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug.
Re: immutable bug?
On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: On Saturday, 11 January 2014 at 18:43:39 UTC, John Colvin wrote: I don't know about the details of what is/isn't legal here, but the only reason the compiler accepts it is because filename is marked as pure. It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. I had heard this mentioned before; is it true in all cases? Even when the function returns a reference to external data?
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 18:14:24 UTC, Brad Anderson wrote: On Saturday, 11 January 2014 at 12:47:12 UTC, Michel Fortin The correct way to to this is to implement the Unicode Collation Algorithm: http://www.unicode.org/reports/tr10/ I thought it was probably more complicated than that. You should read the report...
Re: Should LLVM become the default D-lang platform?
On Sat, 11 Jan 2014 05:04:03 -0800, Iain Buclaw ibuc...@gdcproject.org wrote: On 11 January 2014 00:24, Manu turkey...@gmail.com wrote: On 11 January 2014 06:59, Iain Buclaw ibuc...@gdcproject.org wrote: On 10 January 2014 20:54, John Colvin john.loughran.col...@gmail.com wrote: On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote: This might have been brought up before but I couldn't find any thread about this. As things has progressed I wonder if Digital Mars DMD should move over to use LLVM instead of its own code generation and compiler framework. As I see it with the small amount of contributors D-language has, DMD will never support anything beyond x86 as there are no resources for this. Also, why spend time on recreating the the code generation which has already been done with LLVM? This enables this community to focus on the language which is the most important part as well as supporting more and future processor targets. This comes up regularly. It's already been done. Ldc *is* dmd with llvm backend. Gdc is the same idea but with the gcc framework. Indeed. But naturally I'd suggest they move to GCC. ;-) Is it possible that GDC will ever produce binaries that will link against the microsoft libs without problems? In my experience, GDC produces intrinsic calls to its own runtime all over the place, and it's not compatible with the microsoft runtime. I also recall library format mismatch, but that was a long time ago, and I think we discussed it again since deciding that GDC is now using the same format as VisualC in windows...? Can GDC write PDB debuginfo into the objects (CV8 I think it is)? As I understand, neither GCC nor LLVM are capable of producing PDB. Has Microsoft even release any documentation or code necessary to produce files in their PDB format? This is no longer true of LLVM, they've got Windows specific builds that output PDB and link with COFF natively. See: http://llvm.org/builds/ -- Adam Wilson IRC: LightBender Aurora Project Coordinator
Re: immutable bug?
On Saturday, 11 January 2014 at 18:29:36 UTC, Manu wrote:
I just managed to assign a const(char)[] to a string... caused
crashes when
the original memory disappeared.
inout(char)[] todstr(inout(char)* cstr) pure nothrow
{
return cstr ? cstr[0 .. std.c.string.strlen(cstr)] : cstr[0 ..
0];
}
struct Data
{
char buffer[256] = void;
@property const(char)[] filename() const pure nothrow { return
todstr(buffer.ptr); }
}
struct MyThing
{
private this(in Data* p)
{
filename = p.filename; // *** Uh oh! assigned a const(char)[]
@property to
a string! ***
}
string filename;
}
Surely that assignment shouldn't be legal? Shouldn't I need to
idup?
Simplified:
const(char)[] slice(ref const char[1] c) pure nothrow
{
return c[];
}
void main()
{
char[1] m = .;
immutable i = slice(m); // should not compile
assert(i == .);
m = !; // uh-oh
assert(i == .); // fails
}
Re: GDC and Fedora 20
On 11 January 2014 18:45, Russel Winder rus...@winder.org.uk wrote: I think there was a flurry of activity about this in 2011 and probably more recently, but… GDC appears not to be available on Fedora 20. Fedora is GCC 4.8 but has no GDC, Debian is also 4.8 and has GDC. So is there anywhere to get an RPM of the 4.8 version of GDC for Fedora 20? If there is great, if not and someone has a spec file, I have some machine cycles I can use to create an RPM (yes I do know that GCC takes about 200 hours to compile). -- Russel. Didn't Dejan write a spec file for it? I wrote the reason why two years ago. But then again, two years ago GDC was a release behind GCC in terms of development. This is no longer the case. http://forum.dlang.org/post/mailman.1500.1323722164.24802.d@puremagic.com Regards Iain
Re: Review of std.signal
Definitely a good thing to have. But nothing that could not be added later on, for now I just hope there will be enough people voting, so it can actually be included in phobos. If your only concern is additional features and nothing that is wrong with the API, consider voting. I added the issue to phobosx for now: https://github.com/phobos-x/phobosx/issues/4 Best regards, Robert On Saturday, 11 January 2014 at 18:02:15 UTC, Robert M. Münch wrote: On 2013-11-07 13:45:56 +, Dicebot said: Our current victim is std.signal by Robert Klotzner which is supposed to deprecate and supersede existing (and broken) std.signals 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.
Re: Review of std.signal
This is really ugly, but I don't see any way to improve it either. Maybe if the type of classInstance.method was actually a special pointer-to-class-method type that implicitly down-casted to a delegate, it would be possible to safely use o.watch instead... I agree. Is the only reason to have a weak connection? Yes. Weak connections are the only reason.
Re: immutable bug?
On Saturday, 11 January 2014 at 18:52:39 UTC, Adam D. Ruppe wrote: On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug. Creating undefined behavior is not a sufficient reason to be a bug. Changelog mentions example with pure struct constructors which provide value implicitly castable to immutable. So, strictly speaking current behavior is conforming to spec. You can still argue that the example does not address the issue with 'this' parameter, so code should be rejected (which should happen from safity aspect). I think this case was not considered when 'unique expression' was introduced, so it is yet another hole in type system (to be more precise, bug is in spec-language, not compiler).
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 18:56:53 UTC, monarch_dodra wrote: On Saturday, 11 January 2014 at 18:14:24 UTC, Brad Anderson wrote: On Saturday, 11 January 2014 at 12:47:12 UTC, Michel Fortin The correct way to to this is to implement the Unicode Collation Algorithm: http://www.unicode.org/reports/tr10/ I thought it was probably more complicated than that. You should read the report... I meant more complicated than toLower. I'm already plenty intimidated by Unicode publications :)
Re: Componentizing D's garbage collector
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. -- /Jacob Carlborg
Re: Phobos strings versus C++ Boost
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. -- /Jacob Carlborg
Re: Should LLVM become the default D-lang platform?
On 2014-01-10 23:16, Joseph Rushton Wakeling wrote: Yes, but there's a difference between restrictive and intrusive. Using GDC doesn't intrude into anything -- the standard libraries are still Boost-licensed and simply _using_ a GPL'd piece of software doesn't place any obligations on you. The way Apple has integrated Clang into Xcode would never be possible with GCC since that would require Apple to release Xcode under the GPL license. -- /Jacob Carlborg
Re: Componentizing D's garbage collector
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
Re: Phobos strings versus C++ Boost
On 1/10/14 11:50 PM, 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 [snip] Awesome! Shall we create an issue and link the spreadsheet from there? Andrei
Re: immutable bug?
On 01/11/2014 08:16 PM, Maxim Fomin wrote: On Saturday, 11 January 2014 at 18:52:39 UTC, Adam D. Ruppe wrote: On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug. Creating undefined behavior is not a sufficient reason to be a bug. ... Add a @safe annotation and it is. Changelog mentions example with pure struct constructors which provide value implicitly castable to immutable. So, strictly speaking current behavior is conforming to spec. You can still argue that the example does not address the issue with 'this' parameter, so code should be rejected (which should happen from safity aspect). I think this case was not considered when 'unique expression' was introduced, so it is yet another hole in type system (to be more precise, bug is in spec-language, not compiler). It is an implementation bug. Implicit conversion to immutable is only supposed to work for strongly pure functions.
Re: Componentizing D's garbage collector
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
Re: Phobos strings versus C++ Boost
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
Re: Phobos strings versus C++ Boost
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, it's kind of an argument for and against Phobos/D. InPlace can't be truly inplace like Boost's is because we have actual unicode support.
Re: Phobos strings versus C++ Boost
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. -- Dmitry Olshansky
Minor Bug
Since I do not have a The D Programming Language Issue Tracking
System account I hope it is acceptable to report a minor issue
here. Thank all of you for your great work!
// begin bug.d
struct foo(int bar)
{
static const int bar = bar; // Thou shalt not write shit.
}
void main()
{
alias foo!(0) foo_t;
}
// end bug.d
$ dmd bug.d
Segmentation fault (core dumped)
$ dmd
DMD64 D Compiler v2.064
$ gdc bug.d
gdc: internal compiler error: Segmentation fault (program cc1d)
$ gdc --version
gdc (GCC) 4.8.2 20130725 (prerelease)
Platform: GNU/Linux x86_64
Re: Phobos strings versus C++ Boost
On Saturday, 11 January 2014 at 20:46:32 UTC, Andrei Alexandrescu wrote: On 1/10/14 11:50 PM, 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 [snip] Awesome! Shall we create an issue and link the spreadsheet from there? Andrei I'll probably just make an issue for each group of problems after this is done getting feedback. The big issues appear to boil down to two things: 1) The complete inability to do replace/erase functions easily and 2) the lack of Unicode collation support getting in the way of case-insensitive operations which are correct in every language. Number 1 is pretty serious for day to day coding. Number 2 would just fill a hole in our otherwise excellent Unicode support (something Boost doesn't even truly have, instead using locales and character sets). In the meantime, for English and a few other languages what we have already can be used to perform case-insensitive operations.
Re: Minor Bug
On Saturday, 11 January 2014 at 22:41:55 UTC, Bug Detector wrote:
Since I do not have a The D Programming Language Issue Tracking
System account I hope it is acceptable to report a minor issue
here. Thank all of you for your great work!
// begin bug.d
struct foo(int bar)
{
static const int bar = bar; // Thou shalt not write shit.
}
void main()
{
alias foo!(0) foo_t;
}
// end bug.d
$ dmd bug.d
Segmentation fault (core dumped)
$ dmd
DMD64 D Compiler v2.064
$ gdc bug.d
gdc: internal compiler error: Segmentation fault (program cc1d)
$ gdc --version
gdc (GCC) 4.8.2 20130725 (prerelease)
Platform: GNU/Linux x86_64
On dmd git HEAD this no longer crashes and instead outputs these
errors:
/d28/f520.d(5): Error: variable bar cannot be read at compile time
/d28/f520.d(10): Error: template instance f520.foo!(0) error
instantiating
Re: Componentizing D's garbage collector
On 1/11/14 1:20 PM, Benjamin Thaut wrote: 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). The way I see it/hope it turns out, precision is a separate concern from what I'm working on now, which is tracing. Andrei P.S. s/percise/precise/g
Re: immutable bug?
On Saturday, 11 January 2014 at 21:16:55 UTC, Timon Gehr wrote: It is an implementation bug. Implicit conversion to immutable is only supposed to work for strongly pure functions. Can someone that knows all the details of the purity strength semantic differences please open a PR to get some documentation in the spec? I've updated this bug with a comment: https://d.puremagic.com/issues/show_bug.cgi?id=7456
Facebook puts more bounties on dlang issues
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. https://www.bountysource.com/trackers/383571-d-programming-language Now here's where it gets interesting. Facebook would be glad to increase the bounty budget if that helps, i.e. if bounties do help bugs get fixed and things moving forward. Although we've seen no change in the general activity, there was little improvement in activity on the bugs selected for bounties, although quite a few of them aren't difficult to fix. Here's where you (singular and plural) can help. By working on these bugs not only you make a buck, but also push the language state of the art forward and entice more involvement from Facebook. (For ethical reasons, Walter and I decided to not participate.) So... have at it! Let's bust these bugs and show the world we're serious. Andrei
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 10: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. https://www.bountysource.com/trackers/383571-d-programming-language Now here's where it gets interesting. Facebook would be glad to increase the bounty budget if that helps, i.e. if bounties do help bugs get fixed and things moving forward. Although we've seen no change in the general activity, there was little improvement in activity on the bugs selected for bounties, although quite a few of them aren't difficult to fix. Here's where you (singular and plural) can help. By working on these bugs not only you make a buck, but also push the language state of the art forward and entice more involvement from Facebook. (For ethical reasons, Walter and I decided to not participate.) So... have at it! Let's bust these bugs and show the world we're serious. Perhaps people need some sort of urgency motivator, like higher paying (initially), but time limited bounties ;) Ie, every day the bounty is reduced by 5% or something... If it's not there tomorrow, then you'd better get it done today! Humans are proven to work most effectively when threatened with a strong sense of urgency (it's why the gamedev industry always seems to be in a perpetual state of 'crunching' :/)...
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 00:34:38 UTC, Manu wrote: Perhaps people need some sort of urgency motivator, like higher paying (initially), but time limited bounties ;) Ie, every day the bounty is reduced by 5% or something... If it's not there tomorrow, then you'd better get it done today! Humans are proven to work most effectively when threatened with a strong sense of urgency (it's why the gamedev industry always seems to be in a perpetual state of 'crunching' :/)... If you don't fix it soon then someone else will... that should give a sense of urgency :-) (not sure I agree about crunch/urgency making people more effective... but that's a different thread)
Re: immutable bug?
On 12 January 2014 04:52, Adam D. Ruppe destructiona...@gmail.com wrote: On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation. In this case, that's perfectly true. 'this' is just a function arg; it's not mutated by external state (or at all), given the same this, it will return the same thing every time. That doesn't make any claims about what 'this' is though, and whether it's immutable or 'unique' or whatever. It just promises to transform it in an identical way given the same inputs... ? But, with the hidden this pointer having a reference to the data as well, it obviously is not unique. I think the compiler should catch this; i'd call it a bug.
Re: immutable bug?
On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote: On 12 January 2014 04:52, Adam D. Ruppe It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. Can you explain how this is true? I touched on the topic in a short section of my old purity article: http://klickverbot.at/blog/2012/05/purity-in-d/#_and___again David
Re: immutable bug?
On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote: On 12 January 2014 04:52, Adam D. Ruppe destructiona...@gmail.com wrote: On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation. How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable.
Re: Review of std.signal
On Tuesday, 7 January 2014 at 08:18:26 UTC, Robert wrote: Instead of dropping it all together, I think I will just move it to the bottom and make it a goody, instead of the proposed default usage of std.signal. [...] You are probably right, will fix that. Has this been done? I don't see any changes on https://vhios.dyndns.org/dlang.org/web/phobos/std_signal.html It is for me, if I create a lamda delegate which does not use it's context. Right, I forgot about that case.
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 10:49, Peter Alexander peter.alexander...@gmail.comwrote: On Sunday, 12 January 2014 at 00:34:38 UTC, Manu wrote: Perhaps people need some sort of urgency motivator, like higher paying (initially), but time limited bounties ;) Ie, every day the bounty is reduced by 5% or something... If it's not there tomorrow, then you'd better get it done today! Humans are proven to work most effectively when threatened with a strong sense of urgency (it's why the gamedev industry always seems to be in a perpetual state of 'crunching' :/)... If you don't fix it soon then someone else will... that should give a sense of urgency :-) (not sure I agree about crunch/urgency making people more effective... but that's a different thread) If it didn't work on some level, it would be adopted as standard practise by at least 1 whole industry. It certainly does work in the short term, but applied long term, it has diminishing, and eventually severe negative returns. People aren't much use when they're burned out and hate their life. Anyway, just a question, how are the values for the bounties calculated? The values assigned make the suggestion that they should all be roughly 1-3 hour tasks (presuming most people here get paid in that ball park, I think typical for skilled comp sci). Psychology when money is involved is very interesting. People here usually contribute because they want to, and no other reason, and on things that interest them. But if they're to consider being motivated to work on something they're not interested in by financial interest alone, why would people take a pay cut to do so? Granted that a middle ground probably exists, but I doubt it's relevant here; this community represents some of the highest idealism in open-source software. So I wonder, a) should the bounty applied be less than an average hourly rate; ie, it shouldn't undermine the open-source incentive, but just give a nudge of incentive to some select issues, or b) should it be more than an average hourly rate (more like contract rates), to offer people fair compensation for the work they're doing. Surely, if it pays more than your day job, then this obviously comes first. I can imagine quite easily why a bounty that's too small wouldn't seem to create any additional pressure on getting bugs fixed; if I make more in an hour at work, then the financial motivation is basically non-existent, and the idealistic nature of open-source might even add negative pressure. I know for me personally, the moment there's a financial figure on the table, my mind immediately starts considering it in terms of time. If it's not a recreational activity, it's work, and I don't work for free. If getting these bugs fixed is a business interest for facebook, then I wonder if the bounties should be set closer to a reasonable contractor pay rate? That's what you'd be paying in the event you hired a contractor to get the work done, and it makes financial sense to any (employed) members of the community who might take the job. If you do look at it that way, I think it would be useful to attach an estimated number of hours to each task. Infact, I think that would be useful regardless... Anyway, just some thoughts.
Re: immutable bug?
On 12 January 2014 11:05, Peter Alexander peter.alexander...@gmail.comwrote: On Sunday, 12 January 2014 at 00:50:30 UTC, Manu wrote: On 12 January 2014 04:52, Adam D. Ruppe destructiona...@gmail.com wrote: On Saturday, 11 January 2014 at 18:48:15 UTC, Maxim Fomin wrote: It is legal exactly because function is marked as pure. Result of pure function is implicitly convertible to immutable. It shouldn't be here though... the reason it is implicitly convertable is that pure means the result is unique. Can you explain how this is true? I can't see anything about the concept of purity that suggests the result should be unique... Pure just means given the same inputs, it will produce the same outputs; external state can't affect the calculation. How could the result not be unique, or at least immutable? Pure functions cannot read mutable global state, so any global state returned must be immutable. Strong pure functions can also only have immutable arguments, so anything returned from those will be immutable. The only other thing that can be returned must be created within the function, which will be unique, and safely converted to immutable. 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? 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?
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 00:49:14 UTC, Peter Alexander wrote: (not sure I agree about crunch/urgency making people more effective... but that's a different thread) Studies has been made on the subject. Long story short, it works on the short term, but is counter productive on the long term.
Re: Facebook puts more bounties on dlang issues
On Sunday, 12 January 2014 at 02:04:38 UTC, Manu wrote: ... Anyway, just some thoughts. I agree with most of this. I'm spending some of my free time working on some code that helps D development in general but has no bounty on it. To work on a bug that has a bounty I'd have to: 1) Get up to speed on something that didn't immediately interest me 2) NOT do what did interest me In the SF bay area, $50 is not a lot of money. It's maybe enough to pay the bill for dinner + tip for two people, or enough to fill a small car's gasoline tank. These bounties just seem to be bonuses for people who were going to work on those bugs anyways.
Re: AA literals/initialisation
On 11 November 2013 21:38, Daniel Murphy yebbl...@nospamgmail.com wrote: Manu turkey...@gmail.com wrote in message news:mailman.355.1384158631.9546.digitalmar...@puremagic.com... immutable string[string] priorityMap = [ 1 : blocker, 2 : critical, 3 : critical, 4 : major, 5 : major, 6 : major, 7 : minor, 8 : minor, 9 : trivial ]; main.d(56): Error: non-constant expression [1:blocker, 2:critical, 3:critical, 4:major, 5:major, 6:major, 7:minor, 8:minor, 9:trivial] This is tedious, how long has it been now? Seriously, static map's are super-important, they should be able to be made immutable, and also be able to be initialised. Maybe this could be factored into the improvements for 2.065? I think yes, it can be done for 2.065. Someone remind me if we get close and it isn't done yet. I've just run into this again today. It's still very annoying. Consider this a reminder? :)
Re: AA literals/initialisation
On 12 November 2013 18:09, Don x...@nospam.com wrote:
On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
Manu turkey...@gmail.com wrote in message
news:mailman.355.1384158631.9546.digitalmar...@puremagic.com...
immutable string[string] priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
main.d(56): Error: non-constant expression [1:blocker,
2:critical,
3:critical, 4:major, 5:major, 6:major, 7:minor,
8:minor, 9:trivial]
This is tedious, how long has it been now?
Seriously, static map's are super-important, they should be able to be
made
immutable, and also be able to be initialised.
Maybe this could be factored into the improvements for 2.065?
I think yes, it can be done for 2.065. Someone remind me if we get close
and it isn't done yet.
IIRC the poor performance of array literals and AA literals is because
they're not always literals, sometimes they are variables (!) and the
compiler assumes the worst case. You are allowed to write:
void foo(int some_param)
{
immutable string[int] = [ 1: abc, some_param: def];
}
I wish we could get rid of that silliness entirely.
If the members are compile-time expressions, you probably want to mark the
variable as static const/static immutable.
I've also had this thought. Logically, you shouldn't need to declare an
immutable thing static (although currently, you do), although the advantage
would be a guaranteed compile error if you try to do something silly like
initialise from a variable.
Re: Facebook puts more bounties on dlang issues
On 1/11/14 7:16 PM, Brian Schott wrote: On Sunday, 12 January 2014 at 02:04:38 UTC, Manu wrote: ... Anyway, just some thoughts. I agree with most of this. I'm spending some of my free time working on some code that helps D development in general but has no bounty on it. Yah, it's a weird valley to climb out from. The famous original experiment on cognitive dissonance (http://en.wikipedia.org/wiki/Cognitive_dissonance) had people paid more rate a task more negatively. My hope is to convince that the message Facebook is conveying here is much stronger than the actual sums involved; it's an initiation of cooperation and involvement with a community, and it would be awesome to respond in kind. Walter and I chose the bugs and sums involved. The sums were assigned so as to not create animosity; if I'd assigned $1000 on some bug and someone else has worked or had just done a more difficult and important bug, there would be tension. The current sums are nice perks for people who'd be interested in pushing D forward anyway. And I'm telling you: doing great on bountied bugs is one pretty darn good way to push it forward. To work on a bug that has a bounty I'd have to: 1) Get up to speed on something that didn't immediately interest me 2) NOT do what did interest me In the SF bay area, $50 is not a lot of money. It's maybe enough to pay the bill for dinner + tip for two people, or enough to fill a small car's gasoline tank. Whoa, wait a minute. You live around here? Let's meet! Will send you email. These bounties just seem to be bonuses for people who were going to work on those bugs anyways. YES. But that's just the beginning! Andrei
Re: Facebook puts more bounties on dlang issues
On 12 January 2014 14:16, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/11/14 7:16 PM, Brian Schott wrote: On Sunday, 12 January 2014 at 02:04:38 UTC, Manu wrote: ... Anyway, just some thoughts. I agree with most of this. I'm spending some of my free time working on some code that helps D development in general but has no bounty on it. Yah, it's a weird valley to climb out from. The famous original experiment on cognitive dissonance (http://en.wikipedia.org/wiki/Cognitive_dissonance) had people paid more rate a task more negatively. My hope is to convince that the message Facebook is conveying here is much stronger than the actual sums involved; it's an initiation of cooperation and involvement with a community, and it would be awesome to respond in kind. Walter and I chose the bugs and sums involved. The sums were assigned so as to not create animosity; I can certainly appreciate that, and it is a delicate issue, but it really depends how it's framed. For instance, if facebook has a vested interest in D (or any technology), and they need some work done, it's common business practise to hire a contractor and get it done. Companies do this all the time for many reasons. If facebook were to hire a contractor lets say, to do some work on any open-source project, it would follow that the work, while being done in facebook's interest, is then contributed back to the project. This happens in OSS all the time, and it doesn't usually create animosity. I would imagine (although I have no evidence to draw from) that most communities would appreciate the paid contributions to the code regardless of who they paid to do it. What really pisses the community off is when a businesses hires a contractor to do some work and then DOESN'T commit their changes back to the mainline. In a sense, what you're doing here is not just hiring some contractor, but you're giving everyone in the community an equal opportunity to take the job. The criteria required to keep a respectable summed bounty impersonal, is that the task must be in facebook's own business interest. I don't think people in the D community can reasonably take issue past that, and the fact that everyone has an equal opportunity to accept the contract is in some ways a nice bonus. Perhaps you should do a poll, and see what the average sentiment on this matter is? I think most people understand that when a technology becomes backed by a large influential company, it turns out being good for the whole community. Google and Apple both made their fortunes leveraging OSS technology... I wonder how many people in the OSS communities that they leverage are pissed off about it? Are there stories of this sort? I haven't heard any. if I'd assigned $1000 on some bug and someone else has worked or had just done a more difficult and important bug, there would be tension. The current sums are nice perks for people who'd be interested in pushing D forward anyway. And I'm telling you: doing great on bountied bugs is one pretty darn good way to push it forward. Sure, and it is a nice perk, but your comment seemed to be that it hasn't motivated the action you were hoping for from a business interest point of view? To work on a bug that has a bounty I'd have to: 1) Get up to speed on something that didn't immediately interest me 2) NOT do what did interest me In the SF bay area, $50 is not a lot of money. It's maybe enough to pay the bill for dinner + tip for two people, or enough to fill a small car's gasoline tank. Whoa, wait a minute. You live around here? Let's meet! Will send you email. These bounties just seem to be bonuses for people who were going to work on those bugs anyways. YES. But that's just the beginning! Andrei
Re: AA literals/initialisation
On Sat, 11 Jan 2014 22:08:25 -0600, Manu turkey...@gmail.com wrote:
On 12 November 2013 18:09, Don x...@nospam.com wrote:
On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
Manu turkey...@gmail.com wrote in message
news:mailman.355.1384158631.9546.digitalmar...@puremagic.com...
immutable string[string] priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
main.d(56): Error: non-constant expression [1:blocker,
2:critical,
3:critical, 4:major, 5:major, 6:major, 7:minor,
8:minor, 9:trivial]
This is tedious, how long has it been now?
Seriously, static map's are super-important, they should be able to
be made
immutable, and also be able to be initialised.
Maybe this could be factored into the improvements for 2.065?
I think yes, it can be done for 2.065. Someone remind me if we get
close
and it isn't done yet.
IIRC the poor performance of array literals and AA literals is because
they're not always literals, sometimes they are variables (!) and the
compiler assumes the worst case. You are allowed to write:
void foo(int some_param)
{
immutable string[int] = [ 1: abc, some_param: def];
}
I wish we could get rid of that silliness entirely.
If the members are compile-time expressions, you probably want to mark
the variable as static const/static immutable.
I've also had this thought. Logically, you shouldn't need to declare an
immutable thing static (although currently, you do), although the
advantage would be a guaranteed compile error if you try to do
something silly like initialise from a variable.
I would disagree with that statement, because it is my understanding of
immutable that it merely means that the value is not modified after it is
initialized, it does not however mean that the value is determinate at
compile-time, nor that it is even the same in all invocations of a
function.
Re: AA literals/initialisation
On 12 January 2014 14:29, Orvid King blah38...@gmail.com wrote:
On Sat, 11 Jan 2014 22:08:25 -0600, Manu turkey...@gmail.com wrote:
On 12 November 2013 18:09, Don x...@nospam.com wrote:
On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
Manu turkey...@gmail.com wrote in message
news:mailman.355.1384158631.9546.digitalmar...@puremagic.com...
immutable string[string] priorityMap = [
1 : blocker,
2 : critical,
3 : critical,
4 : major,
5 : major,
6 : major,
7 : minor,
8 : minor,
9 : trivial ];
main.d(56): Error: non-constant expression [1:blocker,
2:critical,
3:critical, 4:major, 5:major, 6:major, 7:minor,
8:minor, 9:trivial]
This is tedious, how long has it been now?
Seriously, static map's are super-important, they should be able to be
made
immutable, and also be able to be initialised.
Maybe this could be factored into the improvements for 2.065?
I think yes, it can be done for 2.065. Someone remind me if we get
close
and it isn't done yet.
IIRC the poor performance of array literals and AA literals is because
they're not always literals, sometimes they are variables (!) and the
compiler assumes the worst case. You are allowed to write:
void foo(int some_param)
{
immutable string[int] = [ 1: abc, some_param: def];
}
I wish we could get rid of that silliness entirely.
If the members are compile-time expressions, you probably want to mark
the variable as static const/static immutable.
I've also had this thought. Logically, you shouldn't need to declare an
immutable thing static (although currently, you do), although the
advantage would be a guaranteed compile error if you try to do something
silly like initialise from a variable.
I would disagree with that statement, because it is my understanding of
immutable that it merely means that the value is not modified after it is
initialized, it does not however mean that the value is determinate at
compile-time, nor that it is even the same in all invocations of a function.
If an immutable is initialised to a literal value, then there is no
possible way for variation to exist. It certainly is the same in all
invocations of the function, and there's no need to re-allocate+initialise
it on every call to the function.
Re: AA literals/initialisation
On Sunday, 12 January 2014 at 04:05:02 UTC, Manu wrote: I've just run into this again today. It's still very annoying. Consider this a reminder? :) 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. This kind of nagging is not helping anyone, it's just annoying.
Re: AA literals/initialisation
On 12 January 2014 15:05, Jakob Ovrum jakobov...@gmail.com wrote: On Sunday, 12 January 2014 at 04:05:02 UTC, Manu wrote: I've just run into this again today. It's still very annoying. Consider this a reminder? :) 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. This kind of nagging is not helping anyone, it's just annoying. No I don't understand the problem. What I do know is that Daniel said to remind him, so I did. He made it sound like it was quite fixable-able in November.
Re: Facebook puts more bounties on dlang issues
+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.
Re: Review of std.signal
On Sunday, 12 January 2014 at 01:06:45 UTC, Vladimir Panteleev wrote: On Tuesday, 7 January 2014 at 08:18:26 UTC, Robert wrote: Instead of dropping it all together, I think I will just move it to the bottom and make it a goody, instead of the proposed default usage of std.signal. [...] You are probably right, will fix that. Has this been done? I don't see any changes on https://vhios.dyndns.org/dlang.org/web/phobos/std_signal.html Look this page: https://vhios.dyndns.org/dlang.org/web/phobos-prerelease/std_signal.html Is it OK?
Re: Componentizing D's garbage collector
Am 11.01.2014 22:20, schrieb Benjamin Thaut: 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. The language can help a lot there (pure... and scope, if fixed), so that the compiler can emit the necessary calls to make this explicit, because it already knows that it's safe without performing a garbage collection cycle.
Linux 64bit branch
I wanted to mention that I have a branch for the base and gtk repositories which compile under 64bit. https://github.com/JesseKPhillips/base/tree/64bit https://github.com/JesseKPhillips/org.eclipse.swt.gtk.linux.x86/tree/64bit I don't know if changes are correct, in the since that I don't have a grasp on the boundaries with the gtk libraries. They shouldn't affect 32bit though (it also compiles) As I have not built a working example yet I won't be creating a pull request, the compiler message for snippet 107: --- (org-eclipse-swt-program-Program.o): undefined reference to symbol 'gnome_vfs_init' //usr/lib/x86_64-linux-gnu/libgnomevfs-2.so.0: error adding symbols: DSO missing from command line --- Which could be an issue with ordering[1] or missing a library. I don't know if I'll get anything working, but wanted to provide information that there is a compiling lib for 64bit out there. 1. http://stackoverflow.com/questions/19901934/strange-linking-error-dso-missing-from-command-line
Re: Create mixins from a list of strings
On Saturday, 11 January 2014 at 07:50:51 UTC, Jakob Ovrum wrote:
Your problem is probably better solved without string mixins,
but we'd probably need to see some code or more elaboration to
accurately suggest a solution.
enum semanticArray = [test];
mixin(`T ` ~ semanticArray[0] ~ `(T)(T t) {
t.name ~= ` ~ semanticArray[0] ~ `;
return t;
}`);
This will mixin a single templated function named test, which
changes an AST node's name to whatever it was concatenated with
test. I want this to happen automatically for any length of
semanticArray.
