Re: Call D code from C#
Hi Dejan, GTK is not an option for me mainly because I do not like the way programs written with appears on the screen. It is a little...ugly! Qt does a lot better in that field, it also has (QT) better documentation, better tools etc etc. This is why I first looked for Qt binding for D. On Thursday, 9 January 2014 at 21:29:36 UTC, Dejan Lekic wrote: On Thursday, 9 January 2014 at 15:58:20 UTC, anthony wrote: Hi to all here, (another one here that wants to desperately use D in his work environment!) So, I am a C# and C++ guy who is used to high quality tools and UI libraries. I discovered VisualD and I settled on using it, it is really awesome! The only problem that concerns me is the lack of a UI library to use with the language. GTK+ is not an option for me. Qt is but I do not see any way to use it from D. I am thinking about using D for the business logic of my programs (let's say on Windows, for start) and then C# for the UI stuff. Is there a way to access D code from C# ? Some path I need to follow, some hint... ? Thanks a lot for any help ! anthony May I ask why is GtkD not an option? Do not get me wrong, I am not a GTK advocate, I am myself a FLTK user/developer. However, GTK would probably be my second choice after FLTK, if I ever had to chose another GUI toolkit for my C++ projects.
Re: Range-Based Graph Search in D (blog post)
On Thursday, 9 January 2014 at 22:04:16 UTC, Peter Alexander wrote: 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. -Peter Put it on reddit: http://www.reddit.com/r/programming/comments/1uvgvi/rangebased_graph_search_in_d/
Re: Range-Based Graph Search in D (blog post)
On Thursday, 9 January 2014 at 22:04:16 UTC, Peter Alexander wrote: 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. -Peter Nice :) I presume you are aware of https://github.com/WebDrake/Dgraph
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 03:48:35 UTC, Jameson Ernst wrote: On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D Still no luck; same behavior when installed via the addin repo. However, I have identified this exception in the logs, that I can confirm occurs only when using the dll from the addin repo, and NOT when using a working built-from-source dll, so the odds that it is related are very high: ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output MonoDevelop.Debugger.Gdb.GdbException: -data-evaluate-expression: Usage: -data-evaluate-expression expression at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand (System.String command, System.String[] args) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession+ProcessOutputc__AnonStorey3.m__3 (System.Object ) [0x0] in filename unknown:0 It's not much to go on since there's no mdb with the distributed dll, but it's something. Alright, I noticed that I made a mistake with publishing the right version - now I've uploaded it again, uninstalled it, removed the ~/.local/share/MonoDevelop-4.0/LocalInstall/Addins/MonoDevelop.D.Debugging.Gdb.0.2.4.6 folder, installed it again, restarted MonoDevelop and tried it out - only then it worked again. The .dll inside this folder must be about 72,2kB large, no 69kB! For some reasons it did not overwrite that older dll, thus I removed it.
Re: std.signal : voting has begun
On 2014-01-06 09:11:07 +, Dicebot said: 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 ;) 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: Call D code from C#
On Friday, 10 January 2014 at 09:54:27 UTC, anthony wrote: Hi Dejan, GTK is not an option for me mainly because I do not like the way programs written with appears on the screen. It is a little...ugly! Qt does a lot better in that field, it also has (QT) better documentation, better tools etc etc. This is why I first looked for Qt binding for D. isn't they actually has same method for building ui visuals? i mean by using CSS-like styles, so it is just style, not the Gtk or Qt itself...
Re: Call D code from C#
gtk has a web based backend available. On Fri, Jan 10, 2014 at 7:31 AM, Rikki Cattermole alphaglosi...@gmail.comwrote: ... It would have enabled building a GUI app and then very simply building it for a web as well. Without changing much code. Don't think any GUI toolkit exists that can do that. [0] https://github.com/rikkimax/Cmsed [1] http://alphaglosined.blogspot.com/2014/01/creating- competing-web-service.html [2] https://github.com/rikkimax/DOOGLE
Re: Call D code from C#
On Friday, 10 January 2014 at 15:02:18 UTC, Rory McGuire wrote: gtk has a web based backend available. Awesome didn't know that thanks!
Re: Gtkd2 in serious use
I have done more work on the web page to cut out fluff, and to cover all the composition elements. There is also a beginning for the description of the user interfaces.
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
Alexander Bothe píše v Pá 10. 01. 2014 v 12:11 +: On Friday, 10 January 2014 at 03:48:35 UTC, Jameson Ernst wrote: On Friday, 10 January 2014 at 03:29:06 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 02:33:05 UTC, Jameson Ernst wrote: On a hunch that maybe it has to do with some strange assembly version or mono version mismatch, I used monodis/ilasm to roundtrip the assembly, reassembling it against the dependencies provided in the git repo. It still exhibits the same breakpoint issue, so something is the code itself must be different. I've managed to bypass the addin building system now in v0.2.4.6 - just try to install it and hopefully see the difference :D Still no luck; same behavior when installed via the addin repo. However, I have identified this exception in the logs, that I can confirm occurs only when using the dll from the addin repo, and NOT when using a working built-from-source dll, so the odds that it is related are very high: ERROR [2014-01-09 19:42:34Z]: Error while processing gdb output MonoDevelop.Debugger.Gdb.GdbException: -data-evaluate-expression: Usage: -data-evaluate-expression expression at MonoDevelop.Debugger.Gdb.GdbSession.RunCommand (System.String command, System.String[] args) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession.CheckBreakpoint (Int32 handle) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession.HandleEvent (MonoDevelop.Debugger.Gdb.GdbEvent ev) [0x0] in filename unknown:0 at MonoDevelop.Debugger.Gdb.GdbSession+ProcessOutputc__AnonStorey3.m__3 (System.Object ) [0x0] in filename unknown:0 It's not much to go on since there's no mdb with the distributed dll, but it's something. Alright, I noticed that I made a mistake with publishing the right version - now I've uploaded it again, uninstalled it, removed the ~/.local/share/MonoDevelop-4.0/LocalInstall/Addins/MonoDevelop.D.Debugging.Gdb.0.2.4.6 folder, installed it again, restarted MonoDevelop and tried it out - only then it worked again. The .dll inside this folder must be about 72,2kB large, no 69kB! For some reasons it did not overwrite that older dll, thus I removed it. Now it works :), thanks a lot
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 18:14:04 UTC, Daniel Kozák wrote: Now it works :), thanks a lot Finally! :)
Re: Range-Based Graph Search in D (blog post)
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. :-)
Re: Mobile App STACK4 with a D backend
On 12/24/2013 7:37 AM, John Colvin wrote: On Tuesday, 24 December 2013 at 10:44:56 UTC, extrawurst wrote: On Sunday, 22 December 2013 at 19:48:03 UTC, John Colvin wrote: Haven't tried the multiplayer, but it seems a really cool game. It took an absolute age to load, however. What exactly took ages ? The download, the loading on startup (unity logo) or the stack4-splashscreen (logo) ? the unity logo stayed around with a little spinning tracer in the corner for a long time on first load. It seems to not be as slow on subsequent loads. Sounds like it was just Mono JITing the game's assemblies. (Although on some platforms, Unity does AOT compilation - I forget whether Android is one of those.) Or maybe it was Dalvik JITing Mono itself, but I would think most of mono was written in native C/C++ code, so I dunno. Do you know if you've run any Unity-built program on the device before? For me, the part you describe only took about a couple seconds the first time (Galaxy S3). What device were you using? I'm curious because I'm using Unity, too (albeit with Nemerle instead of C#, but still).
Re: Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes
On Friday, 10 January 2014 at 18:17:17 UTC, Alexander Bothe wrote: On Friday, 10 January 2014 at 18:14:04 UTC, Daniel Kozák wrote: Now it works :), thanks a lot Finally! :) Confirmed working for me as well! Thanks for working with us to iron this out. I think this will help a lot of people new to D to have a smooth first impression.
Re: Mobile App STACK4 with a D backend
On Friday, 10 January 2014 at 19:43:08 UTC, Nick Sabalausky wrote: On 12/24/2013 7:37 AM, John Colvin wrote: On Tuesday, 24 December 2013 at 10:44:56 UTC, extrawurst wrote: On Sunday, 22 December 2013 at 19:48:03 UTC, John Colvin wrote: Haven't tried the multiplayer, but it seems a really cool game. It took an absolute age to load, however. What exactly took ages ? The download, the loading on startup (unity logo) or the stack4-splashscreen (logo) ? the unity logo stayed around with a little spinning tracer in the corner for a long time on first load. It seems to not be as slow on subsequent loads. Sounds like it was just Mono JITing the game's assemblies. (Although on some platforms, Unity does AOT compilation - I forget whether Android is one of those.) Or maybe it was Dalvik JITing Mono itself, but I would think most of mono was written in native C/C++ code, so I dunno. Do you know if you've run any Unity-built program on the device before? For me, the part you describe only took about a couple seconds the first time (Galaxy S3). What device were you using? I'm curious because I'm using Unity, too (albeit with Nemerle instead of C#, but still). I don't think i've ever run anything using unity before. Also, I'm on an Intel AZ-210 so it's x86-android, which probably means quite a few untested corner-cases for unity and other libs.
Re: Call D code from C#
Have a look at DWT: https://github.com/d-widget-toolkit/dwt 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). 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). 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. 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?
Re: Range-Based Graph Search in D (blog post)
On 01/09/2014 11:04 PM, Peter Alexander wrote: 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. I like the general direction. One issue with the API is that it does not deal with graphs with more than one edge between two given vertices very well. I think it'd need a separate edge abstraction. (Formally, a graph is just a pair of sets (V,E) with two functions from E to V giving you start and end vertex of an edge.) A graph search can have more properties than just the sequence of visited edges, so maybe it is not a range, but just provides a range. (And maybe also a range of events, usable instead of callbacks, maybe a DFS tree etc.) Allocation of memory for visited flags and the like should be controllable. Maybe the design should even allow using persistent data structures for storing visited flags, such that the search range can be used as a value type / forward range. As we don't yet have a graph library for D, it would be interesting to discuss APIs in general. -Peter Probably it would be worthwhile to explore a design that is similar to Phobos ranges at some level. I.e. support kinds of graphs with different capabilities. (Eg. your implicitGraph cannot enumerate all vertices or edges that are present in the Graph. The least capable graph kind reasonably supported might not even be able to quickly report all adjacent edges to a vertex. Some graphs may allow in-place mutation etc.) Then provide some explicit representations with high capabilities and helper functions to convert certain representations to (more) explicit representations. (similar to constructing eg. an array from a range.) Constructions on graphs would then return implicit representations.
Re: Should this work?
On 2014-01-10 02:34, Manu wrote: Or just alias the functions useful for string processing... I agree. It already has some aliases, converting to lower and uppercase. -- /Jacob Carlborg
Re: How to contribute to GC?
On 1/9/14 11:26 PM, Kira Backes wrote: Dear D users, I think the GC is the one are that is holding D the most back, so I’d like to help it. But I have no idea how. No, I’m not talking about the technical stuff, rather about the organizational stuff and the contribution workflow. Well you've contributed the inspirational part, per my last post :o). In truth I'd be planning it for a while, but since you just wrote this was a good time. Andrei
Re: Should this work?
On 2014-01-10 01:34, Manu wrote: I have to wonder the same thing. It's just not anything like anything I've ever called it before I guess. I guess I started with find, and then it refers you to retro if you want to reverse find, and of course, by this time I'm nowhere near std.string anymore. Hard to find something if you're not even looking in the same file :/ But strchr is a good name? If I wanted the index of a character in a string I would most likely look for something called indexOf, or index. In Java and C# it's called indexOf, in Ruby it's called index. In Python it's called index (and find). In PHP it's called strrpos and in C++ it's called find. I think we're in pretty good shape here with D. -- /Jacob Carlborg
Componentizing D's garbage collector
The GC comes up repeatedly in discussions around here. I've been thinking for a while about breaking it down into components, and now it seems the time is ripe. The design at http://goo.gl/ZVCJeB seems to be a win. It works well, comprehends all major allocation tropes, someone implemented a subset of it in C++ and measured good results, and a coworker is considering adopting the design for a C++ project as well. I've started with the next logical step - higher-level allocation that is aware of the type of the object being allocated, and realized that integrating a notion of tracing is appropriate at that level, and actually quite easy. So I'm thinking of just doing it. A few highlights: * The design will foster the small, composable components with required/optional primitives that worked for std.allocator. * I plan to review and probably discard all of the pointers-to-functions nonsense in the current GC. * At this point I won't worry about discovering roots; I assume druntime has the appropriate mechanisms in place. Instead I'll focus on primitives such as given this root, mark all that transitively follows from it (conservatively or not). * 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 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. * There will be no possibility to change the type of certain objects once allocated. An allocation for an immutable object cannot e.g. make it later a mutable one. (This is an essential issue with the current allocator, I think.) * 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. Destroy. Andrei
Re: Should this work?
On 2014-01-10 02:18, Adam D. Ruppe wrote: BTW, I'll say it again: it was a *lot* easier to get started with this back in the phobos1 days, where std.string WAS the one-stop location for string stuff. There was std.uni back in the D1 days as well ;) -- /Jacob Carlborg
Re: Should this work?
On 2014-01-10 02:34, Adam D. Ruppe wrote: Some code differences from the old days: * before: converting to and from string was in std.string. Functions like toInt, toString, etc. Nowadays, this is all done with std.conv.to. The new way is way cool, but a newbie's first place to look might be for std.string.toString rather than std.conv.to!string. I think it would be good to still have a few alias, like toString and toInt. * before: some char type stuff was in std.string (and the rest in std.ctype IIRC). Now, it is in std.ascii and std.uni. std.uni was available in D1 as well. -- /Jacob Carlborg
Re: Should this work?
On 1/9/14 11:56 PM, Jacob Carlborg wrote: On 2014-01-10 02:34, Manu wrote: Or just alias the functions useful for string processing... I agree. It already has some aliases, converting to lower and uppercase. I wouldn't want to get to the point where many functions have 2-3 names. Andrei
Re: Should this work?
On 2014-01-10 03:40, Jesse Phillips wrote: Trying to look over the API pages for C# or Java to find what you need isn't fun. But it can be a little better if you know which class you need. It's easier in a more object oriented language. It's most likely that you will find string operations in the String class in Java, C# and Ruby. -- /Jacob Carlborg
Re: Should this work?
On 2014-01-10 03:40, Brad Anderson wrote: DDox improves on this a bit by giving a table with brief descriptions right up top: http://vibed.org/temp/dlang.org/library/std/string.html What's the hold up of making the official documentation use DDox? -- /Jacob Carlborg
Re: Should this work?
10-Jan-2014 12:15, Jacob Carlborg пишет: On 2014-01-10 03:40, Brad Anderson wrote: DDox improves on this a bit by giving a table with brief descriptions right up top: http://vibed.org/temp/dlang.org/library/std/string.html What's the hold up of making the official documentation use DDox? Seconded. -- Dmitry Olshansky
Re: How to contribute to GC?
On Friday, 10 January 2014 at 08:04:49 UTC, Andrei Alexandrescu wrote: Well you've contributed the inspirational part, per my last post :o). In truth I'd be planning it for a while, but since you just wrote this was a good time. Andrei Great news! Then please tell me as soon as I can help with *anything* (be it test-driving your implementation, documentation, writing unit tests, fixing bugs, writing articles and maybe even implementing a part of it, and so on) I’ve done some testing with the current GC and the current stop-the-world latency is acceptable until about 50,000 objects, but I’ll probably need a lot more than that for the MMORPG server. Right now I’m using the GC for everything, which is the right approach I think to not do premature optimizations ;-) When the project is about to go live (scheduled end of 2014) I hope the GC is improved enough so it can just stay like it is (and I’d gladly publish benchmark numbers and write articles about the improvements). Only as a last resort would I move resources to manual memory management. So I really hope we can improve this until the end of 2014 and as I said I’ll help with anything I can. rgds, Kira Backes
Re: Should this work?
On Friday, 10 January 2014 at 08:15:19 UTC, Jacob Carlborg wrote: What's the hold up of making the official documentation use DDox? I’m also interested in this, since the current documentation is not beginner-friendly due to missing overview and this hurts D.
Re: rdmd and shebang limits
On Friday, 10 January 2014 at 02:11:27 UTC, Jesse Phillips wrote: On Thursday, 9 January 2014 at 11:25:19 UTC, Andrea Fontana wrote: I've just discovered that shebang line has a (very short) limit. Only 127 bytes are read from line It means that something like this doesn't work: #!/usr/bin/rdmd --shebang -I/asdasdasdasd/asdasdasdasd/asdasdasdasd -I/qweqweqweqwe/qweqweqweqwe/qweqweqweqwe/qweqweqweqwe/qweqweqweqwe/qweqweqweqwe/ If you need to specify import paths, your script is probably fragile and broken on different linux/bsd distributions. I don't have a solution. It was just an example, of course. It was the easiest way to add some long params :)
Re: Should this work?
On 2014-01-10 02:13, H. S. Teoh wrote: The hand-classified table of functions in std.algorithm and std.range is more useful, IMO. At least it lets you use divide-and-conquer to zoom down to your area of interest, whereas the order of links in the blob of links has no relation whatsoever to the functionality provided. I'm convinced the both of the tables on in the std.algorithm documentation can automatically be generated with a bit help from the compiler. Add a macro, $(CATEGORY), the compiler knows about. The compiler will the generate the first table by using the symbol (which it already knows about) and the $(CATEGORY) macro. The second table can be generated in a similar way, just take the summary (first paragraph) of the documentation of the symbol. The order of docs for each symbol also follows the order in the source code, which may not necessarily follow a logical order. This makes browsing the docs difficult -- one minute it's describing find() overloads, next minute it's talking about set unions, then after that it's back to findAfter(), then it jumps to remove(), etc.. Try finding what you want when the docs are 50 pages of this random jumping around. All the more this makes a hand-classified table of symbols indispensable. I would say that is poorly organized code. Although, if you do have a $(CATEGORY) macro, as described above, it might be a good idea to group the rest of the documentation after this as well. -- /Jacob Carlborg
Re: Should this work?
On 2014-01-09 21:27, H. S. Teoh wrote:
Yeah, that error drives me up the wall too. I often get screenfuls of
errors, dumping 25 or so overloads of some obscure Phobos internal
function (like toImpl) as though an end-user would understand any of it.
You have to parse all the sig constraints (and boy some of them are
obscure), *understand* what they mean (which requires understanding how
Phobos works internally), and *then* try to figure out, by elimination,
which is the one that you intended to match, and why your code failed to
match it.
I'm almost tempted to say that using sig constraints to differentiate
between template overloads is a bad idea. Instead, consider this
alternative implementation of toImpl:
template toImpl(S,T)
// N.B.: no sig constraints here
{
static if (... /* sig constraint conditions for overload #1 */)
{
S toImpl(T t)
{
// implementation here
}
}
else static if (... /* sig constraint conditions for overload
#2 */)
{
S toImpl(T t)
{
// implementation here
}
}
...
else // N.B.: user-readable error message
{
static assert(0, Unable to convert ~
T.stringof ~ to ~ S.stringof);
}
}
By putting all overloads inside a single template, we can give a useful
default message when no overloads match.
If I recall correctly, Andrei has mentioned that something like the
above doesn't works so well with __tratis(compile).
--
/Jacob Carlborg
Re: Member-assignment for std.container.Array!Struct
On 1/9/14 11:36 PM, Matthias Walter wrote:
Hi,
about 2 years ago I stopped using D for my projects since there were too
many bugs that hindered me from making quick progress. Since I got
several mails from bugzilla about those bugs being fixed I wanted to
give it another try. Unfortunately, the following non-working code made
me think to stop using it once again:
struct S
{
int i;
}
Array!S array = [ S(0) ];
array[0].i = 1;
The reason is certainly that the change only affects a copy and not the
true array-member. I remember that there was a discussion about sealed
containers and returning references, etc.
My question is now: Has there been any progress in this direction? I
know that the design of ref's semantics is a nontrivial topic, but on
the other hand in my opinion std.container.Array is completely useless
if not even the above code works as one would expect!
It's an outrage, and this particular combination of (mis)features has
never got to my attention until now.
I've submitted https://d.puremagic.com/issues/show_bug.cgi?id=11889 on
your behalf. I've also sent out the fix
https://github.com/D-Programming-Language/phobos/pull/1845 for review.
(It's simple, but perhaps I'm missing some subtler issues.)
Apologies for this!
Andrei
Re: rdmd and shebang limits
On Friday, 10 January 2014 at 05:16:19 UTC, Andrei Alexandrescu wrote: On 1/9/14 3:40 PM, Andrea Fontana wrote: Yes I read rdmd but I didn't notice @cmd that was on dmd help, my fault! However as I said in my second post, probably it won't solve the problem: shebang is useful if you can write a self-contained script, something that fits inside a single file. I agree with Andrei. It would be a good solution for my case and it shouldn't break anything. Submit a bug request so it gets done. Andrei Done https://d.puremagic.com/issues/show_bug.cgi?id=11890
Re: ARM support
On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote: Hello, I'm developing embedded system product on ARM9/Linux platform and I wish I could use D and vibe.d for this task. I have couple of questions in this matter: Like Mike, I'm an interested user, who wants to see D on ARMv7, not a core developer, but I'll take a shot at answering your questions. - What is the current status of ARM support? Limited. The reference DMD compiler has no support for ARM, while the LDC and GDC compilers are trying to utilize the ARM backends of llvm and gcc to add ARM support, as Mike points out, but they're not finished. Not sure where ARM9 specifically fits into all this. - Does GDC support cross-compiling to ARM? I've never tried it, but they do claim some support. - Is it possible to remote-debug D code on ARM? (I've used GDB for C++ remote debugging on ARM11, I think this should also work with GDC compiled code) I've been thinking about looking into this myself, for my work on Android/x86, but I have not done so. - Does druntime support ARM plaforms? Grepping through the code, druntime appears to use a fair amount of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM. - Does phobos support ARM plaforms? Phobos appears to be largely arch-independent by comparison, but still supports x86 best in the cases where it isn't. - Does GC run reliably on ARM (or is it platform independent)? I don't think anybody can know for sure, since nobody has tried to make it work. The source appears to be fairly independent, but other core features like threading or fibers appear not be. - Can you estimate eventual cost of supporting D on ARM (think of paid bounty). Not sure.
Re: Should this work?
On 1/9/14 11:53 PM, Jacob Carlborg wrote: Even if you do get how ranges work it can be difficult to figure out where a function is located, in std.algorithms, std.string, std.array, std.uni or std.range. Like, is this a string operation or a general container algorithm?. Why is there a std.string.indexOf function? Isn't that a general array operation or algorithm? Isn't std.string.(left|right)Justify a general operation as well? That's a documentation issue. We've pursued generalization of string algorithms with good result. As such indexOf is susceptible for generalization. However, the justification functions are unlikely to be useful for other data types because most don't have a notion of filler object. Andrei
Re: rdmd and shebang limits
I’d be interested in implementing this ticket (since using D in scripts seems awesome) as my first contribution to D :-) If noone else with more experiences grabs it before me, I’ll do it rgds, Kira
Re: Should this work?
On 1/10/14 12:17 AM, Dmitry Olshansky wrote: 10-Jan-2014 12:15, Jacob Carlborg пишет: On 2014-01-10 03:40, Brad Anderson wrote: DDox improves on this a bit by giving a table with brief descriptions right up top: http://vibed.org/temp/dlang.org/library/std/string.html What's the hold up of making the official documentation use DDox? Seconded. Let's set to switch to ddox with 2.065. Andrei
Re: Should this work?
On 2014-01-10 02:06, Manu wrote: Then there's probably a fundamental problem somewhere, and it should be re-thought at a lower level. Perhaps even something super simple like a can't-go-wrong naming convention, that makes it REALLY plain when string related function are dealing with bytes, codepoints, or graphemes? Isn't it with convention that every thing _can_ go wrong. It would seem to be that a lot of the confusion and complexity surrounding strings is because it tries to be 'correct' (and varying levels of correct in different circumstances), but there are no clear relationships between different functions that deal with these different versions of 'correct'-ness. I think the confusion comes from strings are just plain arrays, which are also containers. If there's a function that works on containers it will work on arrays and strings as well. Because of that it's put in a general module for containers, in this case std.algorithm. Functions that work on arrays will also work on strings and they're put in the most general location they fit, std.array. Functions that work only work on strings are put in std.string. The we of course have some other modules, like std.uni and std.utf making it a bit more complicated. I suspect your effort is not uncommon. Is this not clear evidence of a critical problem? Probably. I find that to be a problem in most standard libraries. They have very general functionality but very few convenient functions, that require calling two or three functions and perhaps creating an object. -- /Jacob Carlborg
Re: ARM support
On Friday, 10 January 2014 at 08:27:39 UTC, Joakim wrote: On Thursday, 9 January 2014 at 18:07:16 UTC, Piotr Szturmaj wrote: - Does druntime support ARM plaforms? Grepping through the code, druntime appears to use a fair amount of x86 assembly, but I have not yet looked into how much of that is optimization and therefore not strictly necessary to reimplement on ARM. Sorry, I should have also said that there is some limited ARM support, mostly just translating arch-dependent headers, in druntime.
Re: Should this work?
On Friday, 10 January 2014 at 08:31:28 UTC, Andrei Alexandrescu wrote: On 1/10/14 12:17 AM, Dmitry Olshansky wrote: 10-Jan-2014 12:15, Jacob Carlborg пишет: On 2014-01-10 03:40, Brad Anderson wrote: DDox improves on this a bit by giving a table with brief descriptions right up top: http://vibed.org/temp/dlang.org/library/std/string.html What's the hold up of making the official documentation use DDox? Seconded. Let's set to switch to ddox with 2.065. Andrei Let's not put to much stress on release/deployment process (which changing documentation engine will require) and make at least one simple release just to get everyone familiar with it.
Re: How to contribute to GC?
On Friday, 10 January 2014 at 07:26:37 UTC, Kira Backes wrote: It seems like sociomantics wanted to port CDGC to D2 but I did not see any work following that, they also wanted to refactor the existing GC but I also don’t think much has been done there. AFAIK it is on hold because porting demands more time Leandro can currently spend on it. Ask him for details.
Re: Should this work?
On 2014-01-10 07:18, Manu wrote:
Surely it can't be *ptr and ++ptr as you say, otherwise none of it would
be unicode safe...?
For UTF-8 strings it's an extra if-statement:
immutable c = str[0];
if(c 0x80)
{
//ptr is used to avoid unnnecessary bounds checking.
str = str.ptr[1 .. str.length];
}
--
/Jacob Carlborg
Re: Should this work?
On 2014-01-10 09:29, Andrei Alexandrescu wrote: That's a documentation issue. We've pursued generalization of string algorithms with good result. As such indexOf is susceptible for generalization. However, the justification functions are unlikely to be useful for other data types because most don't have a notion of filler object. They might not have a default filler object but you can pass the filler as an argument. -- /Jacob Carlborg
Re: Should this work?
On 2014-01-10 09:16, Andrei Alexandrescu wrote: I wouldn't want to get to the point where many functions have 2-3 names. They're aliased in from std.uni, I think that's a different thing. It's not like Ruby which has both collect and map, in the same place, meaning the same thing. -- /Jacob Carlborg
Re: Member-assignment for std.container.Array!Struct
On Friday, 10 January 2014 at 08:27:42 UTC, Andrei Alexandrescu
wrote:
It's an outrage, and this particular combination of
(mis)features has never got to my attention until now.
I've submitted
https://d.puremagic.com/issues/show_bug.cgi?id=11889 on your
behalf. I've also sent out the fix
https://github.com/D-Programming-Language/phobos/pull/1845 for
review. (It's simple, but perhaps I'm missing some subtler
issues.)
Apologies for this!
Andrei
Array returns a value by design. I don't think it's array that's
wrong here, it's being able to assign to members of an rvalue
(IMO).
Off the top of my head, a possible language enhancement would be
to allow member functions to be marked as ref, in which case,
they only work on lvalue (as applying the function on a temp
would make no sense).
eg:
struct S
{
void doit();
void opAssign(int) ref;
}
void main()
{
S().doit(); //OK, rvalue call
S() = 5; //Nope, opAssign requires an lvalue.
}
Re: ARM support
There were people trying vibe.d on ARM/Linux here and there with several issues that may or may not be already fixed by LDC/GDC/vibe.d developers. One thread I have found: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/6048/ As far as I know it works in general but using any more complex projects like vibe.d is likely to trigger any hiding issues in GDC/LDC so one needs to be ready to push through it for greater good.
Re: How to contribute to GC?
On 2014-01-10 08:26, Kira Backes wrote: Dear D users, I think the GC is the one are that is holding D the most back, so I’d like to help it. But I have no idea how. No, I’m not talking about the technical stuff, rather about the organizational stuff and the contribution workflow. It seems like sociomantics wanted to port CDGC to D2 but I did not see any work following that, they also wanted to refactor the existing GC but I also don’t think much has been done there. Then there is also a precise GC. It exists, but is anything planned for this to be included? So, I’d really like to help with the GC but I have no idea how. - There is no overview of what people are doing on the GC or their GC forks As far as I know there are two efforts on improving the GC: * Leandro Lucarella (sociomantics as you mentioned above) - Working on a concurrent GC. http://dconf.org/2013/talks/lucarella.html * Rainer Schütze - Working on a concurrent GC. http://dconf.org/2013/talks/schuetze.html - I have basically no idea what of the current work will be included into Phobos, so I don’t what to base my contribution on - I don’t know which ideas I could work on so that they eventually will be included - Finally, I don’t know what the core D team is already planning or what their vision is, what they’re planning themselves, what they want to see in D, what they will accept as contribution As far as I know nothing is decided. We all just know we want a better GC. I have not heard anything from the core D team. What's missing is someone to finish the work and create a pull request. Maybe we need a project page or a group or something for the GC? Where we can collect all ideas, see who’s working on what, see what’s wanted and so on. That would probably be a good idea. Perhaps on the wiki http://wiki.dlang.org/ -- /Jacob Carlborg
Re: Two versions of library reference on this page
On 2014-01-10 08:31, Kira Backes wrote: After some research I think this can’t be fixed by a pull request, since old HTML files are not deleted. Maybe it could be overwritten by some generated .html? It also exists here, btw: http://dlang.org/phobos-prerelease/phobos.html You can do a couple of things: * Report an issue: http://d.puremagic.com/issues/ * See if there are any links to that page and create a pull request to remove it * See if there is anything that generates that page and create a pull request to remove it Or you might already have done the above. -- /Jacob Carlborg
Re: Hitchikers Guide to Porting Phobos / D Runtime to other architectures
On Friday, 10 January 2014 at 00:02:22 UTC, Sean Kelly wrote: On Thursday, 9 January 2014 at 20:16:14 UTC, Jacob Carlborg wrote: On 2014-01-09 19:39, Sean Kelly wrote: I do think we may need to stick with manually written headers though, as much for copyright reasons as anything. Why not an automatic solution? Why would the copyright matter if it's manually or automatically translated? Because of this clause from the Boost license page: The conceptual interface to a library isn't covered. The particular representation expressed in the header is covered, as is the documentation, examples, test programs, and all the other material that goes with the library. A different implementation is free to use the same logical interface, however. Interface issues have been fought out in court several times; ask a lawyer for details. I suspect that an automatic translation might be subject to the representation issue, while a manual rewrite should not. IANAL and I agree that this may be a somewhat legally murky topic, but Android extensively uses automatically translated headers and I don't think it has caused them much of a problem. Well, other than that whole Java mess with Oracle, ;) which Google won. I count 632 header files in the platform headers that I'm using for Android/x86 that contain the following notice: *** This header was automatically generated from a Linux kernel header *** of the same name, to make information necessary for userspace to *** call into the kernel available to libc. It contains only constants, *** structures, and macros generated from the original header, and thus, *** contains no copyrightable information.
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 23:02:57 UTC, Joseph Rushton Wakeling wrote: On 08/01/14 21:22, Paulo Pinto wrote: As I shared a few times here, it was Oberon which opened my eyes to GC enabled systems programming languages, around 1996, maybe. What was the GC design for Oberon, and how does that relate to what's in D (and what's in other GC'd languages)? The original Oberon was a simple mark and sweep collector. Initially implemented in Assembly. In later versions it was coded in Oberon itself. Original 1992/2005 edition http://www.inf.ethz.ch/personal/wirth/ProjectOberon1992.pdf 2013 edition with images of the workstations were Oberon ran http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf EthOS used a mark and sweep GC with support for weak pointers and finalization. Running when the system was idle or when not enough memory was available. http://research.microsoft.com/en-us/um/people/cszypers/books/insight-ethos.pdf Active Oberon implementation used a mark and sweep with finalization support. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.5753rep=rep1type=pdf Modula-3 used a compacting GC initially, with an optional background one. https://modula3.elegosoft.com/cm3/doc/help/bib.html http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.6890 Cedar used a concurrent reference-counting collector, coupled with a mark and sweep one for cycle removals, with finalization support http://www.textfiles.com/bitsavers/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf The features are quite similar to D: - GC - Allocation of data structures statically in global memory and stack - Escape hatches to allocate memory manually when needed I cannot say if they also allow for interior pointers like D does. However the main point about Oberon and other languages wasn't only technical, but human. Funny enough that is also Andrew Koening's latest post http://www.drdobbs.com/cpp/social-processes-and-the-design-of-progr/240165221 The people designing such systems believed that it was possible to write from the ground up a workstation operating system in a GC enabled systems programming language, with minimal Assembly. They did succeed and built workstations that were usable for normal office work, which were then used at ETHZ, Xerox and Olivetti for some time. For games, some more effort would be required I do acknowledge that. However the world at large, ignored these efforts. As Andrew nicely puts on his article, many times the social barrier is higher than the technical one. For many developers hearing the GC word, safe coding, bounds checking is enough to make them run away as fast as they can. -- Paulo
Does the dub registry at code.dlang.org have problems?
Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org.
Re: Does the dub registry at code.dlang.org have problems?
On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. -- /Jacob Carlborg
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 22:02:48 UTC, Ola Fosheim Grøstad wrote: On Thursday, 9 January 2014 at 19:16:10 UTC, Paulo Pinto wrote: Every time I see such discussions, it reminds me when I started coding in the mid-80s and the heresy of using languages like Pascal and C dialects for microcomputers, instead of coding everything in Assembly or Forth If you insist on bringing up heresy... Motorola 680xx is pretty nice compared to x86, although the AMD64bit mode is better than it was. 680xx feels almost like C, just better ;9, I think only MIPS is close in programmer friendlieness. Forth is nice too, very minimalistic and quite powerful for the simplistic implementation. I had a Forth64 module for my C64 to dabble with, a bit hard to create more than toy programs in Forth... Postscript is pretty close actually, and clean. But Forth is dense, so dense that you don't edit text files, you edit text screens... But don't diss assembly, try to get more than 8 sprites and move sprites into the screen border without assembly, can't be done! High level languages, my ass, BASIC can't do that! But hey, I am not arguing in favour of Forth and C (although I would argue in favour of 680xx and MIPS). I am arguing in favour of smart compilers that allow you to go low level at the top of the call stack where it matters (inner loops) without having to resort to a different language. D is close to that, so it is a promising candidate. And... I actually think D is too lax in some areas. I don't think you should be allowed to call C/C++ without nailing down the pre/postconditions, basically describing what happens in terms of optimization constraints. I also want the programmer to be able to assert facts that the compiler fail to prove so that it can be used for optimization. Basically the ability to guide the optimizer so you don't have to resort to low level coding. I also think giving access to malloc is a bad idea. :-P And well, I am not new to GC, I have actually used Simula quite a bit in classes/teaching newbies. Simula incidentally has exactly the same Garbage Collector that D has AFAIK. I remember we had a 1970s internal memo describing the garbage collector of Simula on the curriculum of the compiler course... So that is vry old news. Actually Simula kinda has the same kind of string type representation that D has too. And OO. And it has coroutines… While it doesn't have templates, it does actually have name parameters that has textual substitution semantics (in addition to ref and value). Now I also kinda like that it has :- for reference assignment and := for value assignment, but I didn't like it back then. 45 years later D merge Simula semantics with C (and some more stuff). And that is an interesting thing, of course. But hey, no point in pretending that other people don't know what programming a GC high level language entails. If I want low latency, I go to C/C++ and hopefully D. If I want high level productivity I use whatever fits the bill… all GC languages. But I don't think D should be the first option in any non-speed area yet, so the GC is of limited use for now IMO. (In clusters you might want that though, speed+convenience but no need for low latency.) I think D could pick up more good stuff from Python, like the array closures that allows you to succinctly transform arrays. Makes large portions of Python's standard library pointless. What I really like about D is that the front end code appears to be quite readable. Take a look at clang and you will see the difference. So, I guess anyone with C++ knowledge has the opportunity to tune both syntax and semantics to their own liking and share it with others. That's pretty sweet (I'd like to try that one day). Sorry if I hit any nerve, one never knows the experience of other people in the Internet. It is just that in the enterprise world I have been part of projects that ported C and C++ based servers to JVM/.NET ones, always with comparable performance. I do acknowledge that in game programming it might be different, however even AAA do play with GC systems nowadays, even if they have some issues to optimize their behavior. For example, The Witcher 2 for the XBox 360. http://www.makinggames.de/index.php/magazin/2155_porting_the_witcher_2_on_xbox_360 -- Paulo
Re: Componentizing D's garbage collector
On 10/01/14 09:03, Andrei Alexandrescu wrote: The GC comes up repeatedly in discussions around here. I've been thinking for a while about breaking it down into components, and now it seems the time is ripe. The design at http://goo.gl/ZVCJeB seems to be a win. It works well, comprehends all major allocation tropes, someone implemented a subset of it in C++ and measured good results, and a coworker is considering adopting the design for a C++ project as well. I've started with the next logical step - higher-level allocation that is aware of the type of the object being allocated, and realized that integrating a notion of tracing is appropriate at that level, and actually quite easy. So I'm thinking of just doing it. Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding?
Re: Componentizing D's garbage collector
On 2014-01-10 10:56, Joseph Rushton Wakeling wrote: Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding? There's the classic The Garbage Collection Handbook. Here in a later edition: http://www.amazon.com/The-Garbage-Collection-Handbook-Management/dp/1420082795 -- /Jacob Carlborg
Re: Componentizing D's garbage collector
On Friday, 10 January 2014 at 09:57:18 UTC, Joseph Rushton Wakeling wrote: On 10/01/14 09:03, Andrei Alexandrescu wrote: The GC comes up repeatedly in discussions around here. I've been thinking for a while about breaking it down into components, and now it seems the time is ripe. The design at http://goo.gl/ZVCJeB seems to be a win. It works well, comprehends all major allocation tropes, someone implemented a subset of it in C++ and measured good results, and a coworker is considering adopting the design for a C++ project as well. I've started with the next logical step - higher-level allocation that is aware of the type of the object being allocated, and realized that integrating a notion of tracing is appropriate at that level, and actually quite easy. So I'm thinking of just doing it. Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding? Two good books http://www.amazon.de/The-Garbage-Collection-Handbook-Management/dp/1420082795 http://www.amazon.de/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484
Re: Componentizing D's garbage collector
On Friday, 10 January 2014 at 09:57:18 UTC, Joseph Rushton Wakeling wrote: Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding? You mean about how GCs work? I have the book Garbage Collection: Algorithms for Automatic Dynamic Memory Management by Richard Jones, Rafael D Lins. I can recommend it. It is not too technical that it gets too hard. But it doesn't tell the reader how to write a GC. It's more an overview of various approaches in GC construction.
Re: Does the dub registry at code.dlang.org have problems?
On Friday, 10 January 2014 at 09:27:39 UTC, Jacob Carlborg wrote: On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. It's literally been added in the last hour and 'My Packages' is now updated. That's over 12 hours of waiting.
Re: Does the dub registry at code.dlang.org have problems?
On Friday, 10 January 2014 at 09:27:39 UTC, Jacob Carlborg wrote: On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. I also have another package waiting called 'tcltk' which hasn't been added yet and now all my packages in the UI have the following error: Failed to get GIT tags/branches: Failed to get tags: Failed to read JSON from https://api.github.com/repos/nomad-software/x11/tags: Unexpected reply for 'https://api.github.com/repos/nomad-software/x11/tags': Forbidden
Re: Componentizing D's garbage collector
On Friday, 10 January 2014 at 10:05:45 UTC, Bienlein wrote: On Friday, 10 January 2014 at 09:57:18 UTC, Joseph Rushton Wakeling wrote: Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding? You mean about how GCs work? I have the book Garbage Collection: Algorithms for Automatic Dynamic Memory Management by Richard Jones, Rafael D Lins. I can recommend it. It is not too technical that it gets too hard. But it doesn't tell the reader how to write a GC. It's more an overview of various approaches in GC construction. Seems like we were all in parallel with our book recommendations; only some minutes apart ...
Re: Componentizing D's garbage collector
On 2014-01-10 11:30, Bienlein wrote: Seems like we were all in parallel with our book recommendations; only some minutes apart ... That would hopefully indicate they're good recommendations :) -- /Jacob Carlborg
Re: How to contribute to GC?
On Friday, 10 January 2014 at 08:15:47 UTC, Kira Backes wrote: I’ve done some testing with the current GC and the current stop-the-world latency is acceptable until about 50,000 objects, Could you post your benchmark code so I can see results on my systems (Win7 64 and OS X). What platform did you test?
Re: Componentizing D's garbage collector
10-Jan-2014 12:03, Andrei Alexandrescu пишет: The GC comes up repeatedly in discussions around here. I've been thinking for a while about breaking it down into components, and now it seems the time is ripe. The design at http://goo.gl/ZVCJeB seems to be a win. O.T.: Please use full URLs, it's not that long. Also how about actually starting formal process to include it as core.alllocator (package preferably). This activity can go in parallel with with getting a through reveiw of currrent GC and taking steps towards precise GC into the mainstream. I've started with the next logical step - higher-level allocation that is aware of the type of the object being allocated, and realized that integrating a notion of tracing is appropriate at that level, and actually quite easy. So I'm thinking of just doing it. A few highlights: * The design will foster the small, composable components with required/optional primitives that worked for std.allocator. * I plan to review and probably discard all of the pointers-to-functions nonsense in the current GC. Cool so far. * 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. This will not work AFAICT. Since nobody can tell what kind of type a user-defined program may have and GC is certainly not templated on all types. GC would have to rely on TypeInfos or rather RTInfo-s that describe the layout of Ts in a uniform way (bitmaps to indicate pointers, etc.). I think Walter had some ideas on how to represent these to reduce space. * 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. Yup. I though GC already did something like that, with BlkAttr.NO_SCAN. * There will be no possibility to change the type of certain objects once allocated. An allocation for an immutable object cannot e.g. make it later a mutable one. (This is an essential issue with the current allocator, I think.) Would that mean 3 separate heaps, so that addresses given for immutable stuff would never be (sometime later) assigned to (thread-local) mutable? I might have got this point of yours wrong, but I think there is a merit in having separate heap at least for shared stuff. -- Dmitry Olshansky
Re: Where is contribution most needed to the D community?
The current state of Phobos documentation is terrible in some moments. Many types and functions are not described how to use. For example, from documentation I don't know how to use ErrnoException. Does it have field for error code copied from errno, or should I use errno directly when I meet this exception? What message does ErrnoException provide? It's from stderror function or some dependent on caller? Plenty of questions arise when you need to know how do class or function work, and you often need to browse source code to find out what happens. But ideally documentation must be full, so user does not have to look into sources. There is also sensible lack of examples. Look at std.encoding. Well, actually I'm sure that the whole module needs to be rewritten, I don't see any benefits of templated approach to work with encoding. Other thing is auto as returned type. It's very handy in code, but I think library documentation should mark returned types more explicitly. So there is many work on Phobos documentation to make it better. Also there are some deprecated modules needed for replacement, for example, std.stream and std.socketstream (but I'm not sure why). I believe streams are important to ease programming, but they need really good interface and implementation (flexible and extensible), maybe you have some ideas on it.
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Thursday, 9 January 2014 at 15:37:11 UTC, Jesse Phillips wrote: On Thursday, 9 January 2014 at 00:37:27 UTC, Atila Neves wrote: Thanks. Not many votes though given all the downvotes. The comments manage to be even worse than on my first blog post. For some reason they all assume I don't know C++ even though I know it way better than D, not to mention that they nearly all miss the point altogether. Sigh. I wonder if someone who knows C++ is going to help you out and improve your code, much like others did with the other languages you used. I know C++. It's not that I can't finish it, it's that I can't be bothered to. That's the whole point of the post. Atila
Re: Does the dub registry at code.dlang.org have problems?
On Friday, 10 January 2014 at 10:26:54 UTC, Gary Willoughby wrote: On Friday, 10 January 2014 at 09:27:39 UTC, Jacob Carlborg wrote: On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. I also have another package waiting called 'tcltk' which hasn't been added yet and now all my packages in the UI have the following error: Failed to get GIT tags/branches: Failed to get tags: Failed to read JSON from https://api.github.com/repos/nomad-software/x11/tags: Unexpected reply for 'https://api.github.com/repos/nomad-software/x11/tags': Forbidden Everything seems to be fine now. Whoever is responsible for code.dlang.org please look into these issues. If we are going to use it as D's default package repository it needs to be bullet-proof and faster than it currently is. Waiting 14hrs+ for a package to be accepted or updated is quite frankly not good enough, especially if you are trying to test dependencies and resolve issues across packages. Thank you.
Re: Where is contribution most needed to the D community?
- Make DCD plugins for editors so they can autocomplete, go to definition +1
Re: Does the dub registry at code.dlang.org have problems?
On 1/10/14, Gary Willoughby d...@nomad.so wrote: I also have another package waiting called 'tcltk' which hasn't been added yet and now all my packages in the UI have the following error: Hi, I have a D OOP Tk wrapper which I paused working on for a while since I had other plans at the moment. Currently it only works on Win32 (I didn't have the time to work on enabling it on other platforms yet) but it has lots of features and tests too: https://github.com/AndrejMitrovic/dtk/ I'm not home right now though (~ next 3 weeks), so I can only periodically check the e-mail every now and then.
Re: Componentizing D's garbage collector
One big generic problem for GC that is to manage efficiently a huge tree. More you program use memory for GC will go slower. Maybe to have a GC profile for these applications could to be a good thing.
Re: Does the dub registry at code.dlang.org have problems?
Am 10.01.2014 13:31, schrieb Gary Willoughby: On Friday, 10 January 2014 at 10:26:54 UTC, Gary Willoughby wrote: On Friday, 10 January 2014 at 09:27:39 UTC, Jacob Carlborg wrote: On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. I also have another package waiting called 'tcltk' which hasn't been added yet and now all my packages in the UI have the following error: Failed to get GIT tags/branches: Failed to get tags: Failed to read JSON from https://api.github.com/repos/nomad-software/x11/tags: Unexpected reply for 'https://api.github.com/repos/nomad-software/x11/tags': Forbidden This most probably indicates that the API request limit for GitHub was reached. It will be reset on the next hour after that happens. The limit can be increased by registering code.dlang.org as a GitHub application, but that needs an OAuth client implementation first. Implementing a clear error message in this case would of course also be a good first step. Any contributions are welcome there! Everything seems to be fine now. Whoever is responsible for code.dlang.org please look into these issues. If we are going to use it as D's default package repository it needs to be bullet-proof and faster than it currently is. Waiting 14hrs+ for a package to be accepted or updated is quite frankly not good enough, especially if you are trying to test dependencies and resolve issues across packages. Thank you. That it took so long was a bug, which unfortunately is hard to debug as the log output isn't verbose enough to show where it failed/hung - I'll increase the log level and look into it when/if it happens again. Normally, though, it will take a maximum of about 15 minutes, with the possibility of triggering a manual update to get an almost instant update.
Re: Does the dub registry at code.dlang.org have problems?
On 1/10/2014 9:31 PM, Gary Willoughby wrote: Everything seems to be fine now. Whoever is responsible for code.dlang.org please look into these issues. If we are going to use it as D's default package repository it needs to be bullet-proof and faster than it currently is. Waiting 14hrs+ for a package to be accepted or updated is quite frankly not good enough, especially if you are trying to test dependencies and resolve issues across packages. Thank you. To test dependencies and such, you should use 'dub add-local' with your local copy of the source. I currently have a couple of dub-managed libraries I've been working on that I haven't even put on github yet and used add-local so that they're available to my test apps. That way you don't have to register anything with code.dlang.org until you're ready for release.
Re: Should this work?
On 10 January 2014 00:07, Manu turkey...@gmail.com wrote: This works fine: string x = find(Hello, 'H'); This doesn't: string y = find(retro(Hello), 'H'); Error: cannot implicitly convert expression (find(retro(Hello), 'H')) of type Result!() to string Is that wrong? That seems to be how the docs suggest it should be used. On a side note, am I the only one that finds std.algorithm/std.range/etc for string processing really obtuse? I can rarely understand the error messages, so say it's better than STL is optimistic. Using std.algorithm and std.range to do string manipulation feels really lame to me. I hate looking through the docs of 3-4 modules to understand the complete set of useful string operations (std.string, std.uni, std.algorithm, std.range... at least). I also find the names of the generic algorithms are often unrelated to the name of the string operation. My feeling is, everyone is always on about how cool D is at string, but other than 'char[]', and the builtin slice operator, I feel really unproductive whenever I do any heavy string manipulation in D. I also hate that I need to import at least 4-5 modules to do anything useful with strings... I feel my program bloating and cringe with every gigantic import that sources exactly one symbol. I won't start another annoying thread. 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?
Re: Where is contribution most needed to the D community?
On 2014-01-10 12:36, FreeSlave wrote: The current state of Phobos documentation is terrible in some moments. Many types and functions are not described how to use. For example, from documentation I don't know how to use ErrnoException. Does it have field for error code copied from errno, or should I use errno directly when I meet this exception? What message does ErrnoException provide? It's from stderror function or some dependent on caller? Plenty of questions arise when you need to know how do class or function work, and you often need to browse source code to find out what happens. But ideally documentation must be full, so user does not have to look into sources. I agree. There is also sensible lack of examples. Look at std.encoding. Well, actually I'm sure that the whole module needs to be rewritten, I don't see any benefits of templated approach to work with encoding. Other thing is auto as returned type. It's very handy in code, but I think library documentation should mark returned types more explicitly. So there is many work on Phobos documentation to make it better. Ddoc needs to resolve auto to the actual type. Also there are some deprecated modules needed for replacement, for example, std.stream and std.socketstream (but I'm not sure why). I believe streams are important to ease programming, but they need really good interface and implementation (flexible and extensible), maybe you have some ideas on it. I think they need to be able to work with ranges. -- /Jacob Carlborg
Re: core.sys.windows.windows and TCHAR
On Fri, 10 Jan 2014 00:37:06 -, Adam D. Ruppe destructiona...@gmail.com 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. IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various functions) which is a sub-set of UTF-16. So, calling a windows W function with wchar[] could also break.. just in far fewer cases than char[] with A functions. 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. As far as I am aware there is no good reason to prefer the ascii functions over the multibyte ones. So, I think defaulting to multibyte is a reasonable decision. Having a way to opt back into ascii would be desirable in some cases though. So, I think we want both sets of aliases in version blocks (Ascii and Multibyte) and we actually want the compiler to define the default of Multibyte which would be overridden by version=Ascii on the command line. Remind me, cos I haven't looked in ages. Do we define prototypes for both the A and W versions of functions outside of version() blocks? Then use version blocks to alias either the W or A to a name without either? (in the same way the windows headers do) Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Should this work?
On Thu, 09 Jan 2014 17:25:13 -, Manu turkey...@gmail.com wrote: On 10 January 2014 03:17, Regan Heath re...@netmail.co.nz wrote: On Thu, 09 Jan 2014 17:15:41 -, Regan Heath re...@netmail.co.nz wrote: In other words, why can't we alias or wrap the generic routines in std.string What I meant here is why can't we alias or wrap the generic routines (from std.range, std.algo.. into aliases/functions) in std.string. We can and should. Very liberally. I'm still very concerned about the magnitude of bloat that gets pulled in by any of these modules though. They're all intimately connected, none of them seem to be able to exist without all of the others. And there are some really huge template functions out there. Massive functions, which take multiple template arguments (N^2 permutations), where the template types might only affects one or 2 lines... they need to be broken down into very small template functions, and a non-templated inner function. We need, if one does not exist already, a dependency mapper tool. One which would give some sort of graphical/hierarchical output of modules and their dependencies, ideally drilling right down to the functions, methods, variables etc being used. Sounds fun, and there is a DMD frontend to build on right? Anyone got the spare time? Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Should this work?
On Fri, 10 Jan 2014 08:16:53 -, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/9/14 11:56 PM, Jacob Carlborg wrote: On 2014-01-10 02:34, Manu wrote: Or just alias the functions useful for string processing... I agree. It already has some aliases, converting to lower and uppercase. I wouldn't want to get to the point where many functions have 2-3 names. This is only a problem if they are all in the same sphere of concern.. by that I mean if you're looking for string functions and you find 2 names for the same function this would be wrong/confusing/pointless. But, if you have one name in the string category and one in the range category and they were both the same function underneath I don't see this as the same problem, right? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Should this work?
On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote: I won't start another annoying thread. 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? It seems you have to use both the .front property to access the element, and popFront() to advance to the next element. I can't understand why you need two methods; maybe there's a very good reason for that.
Re: Componentizing D's garbage collector
On Fri, 10 Jan 2014 09:56:45 -, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Can you recommend some good background reading for those of us who would love to have some input (or at least insight) to this, but don't yet have the theoretical understanding? IMO, the Microsoft documentation for the C# GC is a good place to start. http://msdn.microsoft.com/en-us/library/ms973837.aspx It's an overview of a specific collector so you get a concrete understand of one way to do it, which you can then use as a foundation to build understanding on etc. It's the only thing I've read on GC and I understood (at least at the surface level) Andrei's post completely. Plus it's not too long, and available online for free :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Should this work?
On Friday, 10 January 2014 at 14:13:37 UTC, marcpmichel wrote: On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote: I won't start another annoying thread. 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? There isn't (at least, not that I know of). I would be trivial to implement, but because it would be implemented in terms of front/popFront, it would not be any faster. *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). It seems you have to use both the .front property to access the element, and popFront() to advance to the next element. I can't understand why you need two methods; maybe there's a very good reason for that. You *need* two methods for the very simple use case of reading without popping. As for returning the popped element when calling pop: It's an extra cost. C++ introduced back and pop_back (as well as pop/top) with those exact semantics for this reason. D also adds an issue of data integrity.
Re: Should this work?
On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote: On 10 January 2014 00:07, Manu turkey...@gmail.com wrote: This works fine: string x = find(Hello, 'H'); This doesn't: string y = find(retro(Hello), 'H'); Error: cannot implicitly convert expression (find(retro(Hello), 'H')) of type Result!() to string Is that wrong? That seems to be how the docs suggest it should be used. On a side note, am I the only one that finds std.algorithm/std.range/etc for string processing really obtuse? I can rarely understand the error messages, so say it's better than STL is optimistic. Using std.algorithm and std.range to do string manipulation feels really lame to me. I hate looking through the docs of 3-4 modules to understand the complete set of useful string operations (std.string, std.uni, std.algorithm, std.range... at least). I also find the names of the generic algorithms are often unrelated to the name of the string operation. My feeling is, everyone is always on about how cool D is at string, but other than 'char[]', and the builtin slice operator, I feel really unproductive whenever I do any heavy string manipulation in D. I also hate that I need to import at least 4-5 modules to do anything useful with strings... I feel my program bloating and cringe with every gigantic import that sources exactly one symbol. I won't start another annoying thread. 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? Popping the front off a range doesn't necessarily require the work needed to return the front itself. A trivial example would be a range of e^n : popFront just incrememnts n but calculating front requires the relatively expensive exponentiation. Also, it is legal call popFront on a range with only one element remaining, leaving it empty. It is not valid to then look at the front. You want both at once? take a look at the various std.range.take*
Re: Should this work?
On 2014-01-10 15:13, marcpmichel wrote: It seems you have to use both the .front property to access the element, and popFront() to advance to the next element. I can't understand why you need two methods; maybe there's a very good reason for that. For optimization reasons. You don't always need both popFront and front. -- /Jacob Carlborg
Re: Should this work?
On Friday, 10 January 2014 at 14:28:09 UTC, John Colvin wrote:
On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
On 10 January 2014 00:07, Manu turkey...@gmail.com wrote:
This works fine:
string x = find(Hello, 'H');
This doesn't:
string y = find(retro(Hello), 'H');
Error: cannot implicitly convert expression
(find(retro(Hello),
'H')) of type Result!() to string
Is that wrong? That seems to be how the docs suggest it
should be used.
On a side note, am I the only one that finds
std.algorithm/std.range/etc
for string processing really obtuse?
I can rarely understand the error messages, so say it's
better than STL is
optimistic.
Using std.algorithm and std.range to do string manipulation
feels really
lame to me.
I hate looking through the docs of 3-4 modules to understand
the complete
set of useful string operations (std.string, std.uni,
std.algorithm,
std.range... at least).
I also find the names of the generic algorithms are often
unrelated to the
name of the string operation.
My feeling is, everyone is always on about how cool D is at
string, but
other than 'char[]', and the builtin slice operator, I feel
really
unproductive whenever I do any heavy string manipulation in D.
I also hate that I need to import at least 4-5 modules to do
anything
useful with strings... I feel my program bloating and cringe
with every
gigantic import that sources exactly one symbol.
I won't start another annoying thread.
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?
Popping the front off a range doesn't necessarily require the
work needed to return the front itself. A trivial example would
be a range of e^n : popFront just incrememnts n but calculating
front requires the relatively expensive exponentiation.
Also, it is legal call popFront on a range with only one
element remaining, leaving it empty. It is not valid to then
look at the front.
You want both at once? take a look at the various
std.range.take*
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;
}
Re: Does the dub registry at code.dlang.org have problems?
On 1/10/14 5:26 AM, Sönke Ludwig wrote: Am 10.01.2014 13:31, schrieb Gary Willoughby: On Friday, 10 January 2014 at 10:26:54 UTC, Gary Willoughby wrote: On Friday, 10 January 2014 at 09:27:39 UTC, Jacob Carlborg wrote: On 2014-01-10 10:21, Gary Willoughby wrote: Does the dub registry at code.dlang.org have problems? I registered two new packages yesterday and they are still not included in the registry. It's annoying that registering or updating existing packages take ages to be reflected on code.dlang.org. I can see that x11 was added/updated yesterday. Note that projects with a version tag is sorted first. I also have another package waiting called 'tcltk' which hasn't been added yet and now all my packages in the UI have the following error: Failed to get GIT tags/branches: Failed to get tags: Failed to read JSON from https://api.github.com/repos/nomad-software/x11/tags: Unexpected reply for 'https://api.github.com/repos/nomad-software/x11/tags': Forbidden This most probably indicates that the API request limit for GitHub was reached. It will be reset on the next hour after that happens. The limit can be increased by registering code.dlang.org as a GitHub application, but that needs an OAuth client implementation first. Implementing a clear error message in this case would of course also be a good first step. Any contributions are welcome there! OAuth is only needed if you need to perform actions as someone else. Otherwise your own account creds are sufficient to be able to do 5000 queries an hour rather than the unauth'ed limit of 60 an hour.
Re: Should this work?
On 11 January 2014 00:31, John Colvin john.loughran.col...@gmail.comwrote:
On Friday, 10 January 2014 at 14:28:09 UTC, John Colvin wrote:
On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
On 10 January 2014 00:07, Manu turkey...@gmail.com wrote:
This works fine:
string x = find(Hello, 'H');
This doesn't:
string y = find(retro(Hello), 'H');
Error: cannot implicitly convert expression (find(retro(Hello),
'H')) of type Result!() to string
Is that wrong? That seems to be how the docs suggest it should be used.
On a side note, am I the only one that finds std.algorithm/std.range/etc
for string processing really obtuse?
I can rarely understand the error messages, so say it's better than STL
is
optimistic.
Using std.algorithm and std.range to do string manipulation feels really
lame to me.
I hate looking through the docs of 3-4 modules to understand the
complete
set of useful string operations (std.string, std.uni, std.algorithm,
std.range... at least).
I also find the names of the generic algorithms are often unrelated to
the
name of the string operation.
My feeling is, everyone is always on about how cool D is at string, but
other than 'char[]', and the builtin slice operator, I feel really
unproductive whenever I do any heavy string manipulation in D.
I also hate that I need to import at least 4-5 modules to do anything
useful with strings... I feel my program bloating and cringe with every
gigantic import that sources exactly one symbol.
I won't start another annoying thread.
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?
Popping the front off a range doesn't necessarily require the work needed
to return the front itself. A trivial example would be a range of e^n :
popFront just incrememnts n but calculating front requires the relatively
expensive exponentiation.
Also, it is legal call popFront on a range with only one element
remaining, leaving it empty. It is not valid to then look at the front.
You want both at once? take a look at the various std.range.take*
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;
}
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.
Does nobody see this coming up in their code? I have it basically every
time I use ranges, and as usual, surprised others don't feel the same way.
Re: Should this work?
On 10 January 2014 00:07, Manu turkey...@gmail.com wrote: This works fine: string x = find(Hello, 'H'); This doesn't: string y = find(retro(Hello), 'H'); Error: cannot implicitly convert expression (find(retro(Hello), 'H')) of type Result!() to string Is that wrong? That seems to be how the docs suggest it should be used. On a side note, am I the only one that finds std.algorithm/std.range/etc for string processing really obtuse? I can rarely understand the error messages, so say it's better than STL is optimistic. Using std.algorithm and std.range to do string manipulation feels really lame to me. I hate looking through the docs of 3-4 modules to understand the complete set of useful string operations (std.string, std.uni, std.algorithm, std.range... at least). I also find the names of the generic algorithms are often unrelated to the name of the string operation. My feeling is, everyone is always on about how cool D is at string, but other than 'char[]', and the builtin slice operator, I feel really unproductive whenever I do any heavy string manipulation in D. I also hate that I need to import at least 4-5 modules to do anything useful with strings... I feel my program bloating and cringe with every gigantic import that sources exactly one symbol. One more, again here to reduce spam... 2 overloads exist: void func(const(char)* str); void func(const(char)[] str); Called with literal string: func(literal); called with argument types (string) matches both. I appreciate the convenience of the automatic string literal - const(char)* cast. But in this case, surely it should just choose the array version of the function, like it does it calling with a 'string' variable? The convenience should be just that, a convenience, not a hard rule...?
Re: Where is contribution most needed to the D community?
On 1/10/14 3:36 AM, FreeSlave wrote: The current state of Phobos documentation is terrible in some moments. Agreed. Please submit bug reports for it. This is one area in which literally every member of the community can contribute. Andrei
Re: Should this work?
Am Fri, 10 Jan 2014 08:42:14 +0100 schrieb Jacob Carlborg d...@me.com: On 2014-01-10 01:57, Manu wrote: I've heard that, and I think that's a lame argument. Would people rather break peoples code *who deliberately chose to use a beta feature, and accept the contract while doing so (that it would later be moved to 'std' proper)*, or consistently produce features that have very little proven foundation in practical application? It takes year(/s) before enough people can have had a crack at a new API in enough scenarios to reveal where it went right, and where it went wrong. I think it's a good idea, others don't. When do we have a meeting of the elders to decide on this matter? -- Marco
Re: Should this work?
On Friday, 10 January 2014 at 14:30:05 UTC, Jacob Carlborg wrote: On 2014-01-10 15:13, marcpmichel wrote: I can't understand why you need two methods; maybe there's a very good reason for that. For optimization reasons. You don't always need both popFront and front. In C++ another reason is exception safety. I am not sure if this holds for D as well since structs have different semantics for copy/move.
Re: Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector
On Friday, 10 January 2014 at 11:43:05 UTC, Atila Neves wrote: On Thursday, 9 January 2014 at 15:37:11 UTC, Jesse Phillips wrote: On Thursday, 9 January 2014 at 00:37:27 UTC, Atila Neves wrote: Thanks. Not many votes though given all the downvotes. The comments manage to be even worse than on my first blog post. For some reason they all assume I don't know C++ even though I know it way better than D, not to mention that they nearly all miss the point altogether. Sigh. I wonder if someone who knows C++ is going to help you out and improve your code, much like others did with the other languages you used. I know C++. It's not that I can't finish it, it's that I can't be bothered to. That's the whole point of the post. Atila I know, that doesn't mean someone can't come in and fix what they see wrong with it. C++ programmers have less reason to prove their language, but I think most are in denial that their language is diffacult and that it is a problem.
Re: Should this work?
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.
Re: Should this work?
On 1/10/14 12:49 AM, Jacob Carlborg wrote: On 2014-01-10 09:29, Andrei Alexandrescu wrote: That's a documentation issue. We've pursued generalization of string algorithms with good result. As such indexOf is susceptible for generalization. However, the justification functions are unlikely to be useful for other data types because most don't have a notion of filler object. They might not have a default filler object but you can pass the filler as an argument. By that I was implying that the whole notion is not sensible for general types. Honest, I did consider generalizing everything in std.string, but the algorithms left in there made little sense for other types than strings. Andrei
Re: Should this work?
On Friday, 10 January 2014 at 14:30:05 UTC, Jacob Carlborg wrote: On 2014-01-10 15:13, marcpmichel wrote: I can't understand why you need two methods; maybe there's a very good reason for that. For optimization reasons. You don't always need both popFront and front. mkay; this is a good reason indeed. But maybe a simple pop() similar to the popFrontRet() above method could be added to the library. I know I looked for it the first time.
Re: Should this work?
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;
}
Re: Member-assignment for std.container.Array!Struct
On 1/10/14 12:53 AM, monarch_dodra wrote: On Friday, 10 January 2014 at 08:27:42 UTC, Andrei Alexandrescu wrote: It's an outrage, and this particular combination of (mis)features has never got to my attention until now. I've submitted https://d.puremagic.com/issues/show_bug.cgi?id=11889 on your behalf. I've also sent out the fix https://github.com/D-Programming-Language/phobos/pull/1845 for review. (It's simple, but perhaps I'm missing some subtler issues.) Apologies for this! Andrei Array returns a value by design. It's my design. The rationale for returning by value has since vanished. The idea was to make impossible to take addresses of elements inside containers (I still plan to write an article sealed containers at some point). However, Walter and I decided to ban taking the address of ref returns since (currently not enforced). Andrei
Re: Should this work?
Am Thu, 09 Jan 2014 15:51:36 -0500 schrieb Jerry jlqu...@optonline.net: Marco Leise marco.le...@gmx.de writes: Am Thu, 09 Jan 2014 15:20:13 + schrieb John Colvin john.loughran.col...@gmail.com: The point about graphemes is good. D's functions still stop mid-way. From UTF-8 you can iterate UTF-32 code points, but grapheme clusters are the new characters. I.e. the basic need to iterate Unicode _characters_ is not supported! I cannot even come up with use cases for working with code points and think they are a conceptual black hole. Something carried over from a time when grapheme clusters didn't exist. Actually, you can do tons of NLP without grapheme clusters. If you're paranoid, you standardize on a specific Unicode normalization first. You can probably get a bit better results by paying attention to clusters, but I suspect it will be a marginal improvement. That said, I do agree with the OP that the string API is currently more complex to understand than I'd like. However, it's significantly easier to use than what's in standard C++ for anything beyond ascii. Jerry Sorry, I got confused with the Unicode definitions. I see now that a grapheme cluster is e.g. \r\n. What I really meant is that Phobos needs to support graphemes. But seeing that monsters like this exist: n͠g, I don't even know if this is one character or two, but right now Phobos sees it as three characters. -- Marco
Re: Componentizing D's garbage collector
On 1/10/14 3:29 AM, Dmitry Olshansky wrote: 10-Jan-2014 12:03, Andrei Alexandrescu пишет: * 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. This will not work AFAICT. Since nobody can tell what kind of type a user-defined program may have and GC is certainly not templated on all types. GC would have to rely on TypeInfos or rather RTInfo-s that describe the layout of Ts in a uniform way (bitmaps to indicate pointers, etc.). I think Walter had some ideas on how to represent these to reduce space. You know I wouldn't write that unless I had an ace up my sleeve. Watch me :o). * 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. Yup. I though GC already did something like that, with BlkAttr.NO_SCAN. That design will disappear. The attribute won't be settable once initialized, and will never be conservative (scan all words in this block). * There will be no possibility to change the type of certain objects once allocated. An allocation for an immutable object cannot e.g. make it later a mutable one. (This is an essential issue with the current allocator, I think.) Would that mean 3 separate heaps, so that addresses given for immutable stuff would never be (sometime later) assigned to (thread-local) mutable? I might have got this point of yours wrong, but I think there is a merit in having separate heap at least for shared stuff. Yah, separation of shared data allocation is crucial. We'll see. Andrei
Re: Should this work?
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? If you want to use Phobos, get your ass in gear and learn Phobos. Andrei
Re: Should this work?
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.
Re: Should this work?
On 1/10/14 6:07 AM, Regan Heath wrote: On Fri, 10 Jan 2014 08:16:53 -, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/9/14 11:56 PM, Jacob Carlborg wrote: On 2014-01-10 02:34, Manu wrote: Or just alias the functions useful for string processing... I agree. It already has some aliases, converting to lower and uppercase. I wouldn't want to get to the point where many functions have 2-3 names. This is only a problem if they are all in the same sphere of concern.. by that I mean if you're looking for string functions and you find 2 names for the same function this would be wrong/confusing/pointless. But, if you have one name in the string category and one in the range category and they were both the same function underneath I don't see this as the same problem, right? The way I see it one learns a name for an algorithm (low cognitive load) and then uses it everywhere. This is not Go. Andrei
