Re: My D book is now officially coming soon
BTW it now has a cover image, that's a painting my brother did called View from Phobos, seemed appropriate :P Wow! :)
Re: My D book is now officially coming soon
On Friday, 18 April 2014 at 23:03:54 UTC, Jason King wrote: Packt is having a 1/2 price ebooks sale, so if you haven't gotten this yet, now would be the time. I just did. Yes, I did it too.
Re: DMD coding style rules?
asman wrote in message news:ktcpixnpmessxamqe...@forum.dlang.org... Thanks very much. In this case I can assume there's no std:: stuff and it isn't allowed, correct? Yes. If you started using namespaces, stl, etc it would break DDMD so it's essentially banned now.
Re: Proposal for ref counting in D - repost
On Friday, 18 April 2014 at 16:45:30 UTC, Walter Bright wrote: A lot of comments in the DIP60: @nogc attribute thread about doing ARC in D are answered in this earlier thread: http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com Thank you. I added this to the wiki so it can be easily referred to in the future instead of disappearing into the bowels of the forum: http://wiki.dlang.org/Language_design_discussions#Automatic_Reference_Counting_.28ARC.29_as_an_alternative_to_D.27s_Garbage_Collector Everyone is welcome to help edit/summarize. Mike
Re: Knowledge of managed memory pointers
On 4/16/2014 11:55 PM, Manu via Digitalmars-d wrote: It occurs to me that a central issue regarding the memory management debate, and a major limiting factor with respect to options, is the fact that, currently, it's impossible to tell a raw pointer apart from a gc pointer. No it isn't, in fact, the gc has to be able to tell the difference or it cannot do mark/sweep. It tells the difference with does the pointer point into the gc memory pool. What about 'hacks' like an unlikely sentinel value at ptr[-1]? That doesn't work as soon as one increments a pointer.
Re: DIP60: @nogc attribute
On Friday, 18 April 2014 at 22:10:06 UTC, John Colvin wrote: Which, if any, of the more sophisticated GC designs out there - in your opinion - would work well with D? Perhaps more importantly, which do you see as *not* working well with D. I think you can improve GC by: - supporting c++ owned/shared pointers at the language level and marking them as no-scan. - aligning scanned pointers in structs and classes to the same cache line - having scan metadata at an offset from the return address of functions - segmented collection - whole program analysis to figure out what individual stacks can contain - meta level invariants specified by the programmer
Re: Spawn as many thousand threads as you like and D
Am 16.04.2014 16:43, schrieb Bienlein:
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:
I still don't understand what you mean by distributed. Spawning
50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
runTask({
writefln(Hello, World!);
});
}
Alternatively, runWorkerTask will also distribute the tasks among a
set of worker threads, which would be more in line with Go AFAIK.
All right, I see. I spent some time looking at the vibe.d homepage and I
never saw any other code than something like this:
shared static this()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;
listenHTTP(settings, handleRequest);
}
void handleRequest(HTTPServerRequest req,
HTTPServerResponse res)
{
res.writeBody(Hello, World!, text/plain);
}
BTW, thank you for explaining the background, I think you were right
that the focus is far too strong on the network part of the library,
which can definitely be misleading (it was more appropriate two years
ago, when most of this was written). I've taken the opportunity and
updated a few pages to mention the non-I/O primitives and added a
paragraph clarifying the use of yield:
All of this usually happens behind the curtain of the vibe.d API, so that
everything feels like just working with normal threads and blocking operations.
All blocking functions, such as sleep() or read() will yield execution whenever
they need to wait for an event and let themselves resume when the event occurs.
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote: On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote: I have also tried to design something myself (although I'm not a designer) and this is what I came up with: http://krcko.net/dlang.org/dlang-home-draft1.png I'm not entirely satisfied with it but I believe that it looks better (or at least more modern) than the current design. So, what do you guys think? I'm normally very skeptical and critical of staying modern (and regarding someone's mention of Win8 - I find Win8 downright UGLY) - However...I really like your design, quite a lot. As long as it's: - A normal reflowing layout (not a static fixed-width one or an auto-rescaling one) Of course. - Doesn't require JS (optional JS enhancements are fine) I was told you would oppose usage of JavaScript. :) But as I've said already I plan on using JavaScript to enhance things a bit only, site would function normally with JavaScript unavailable/disabled. - Works reasonably well on mobile *including* a complete and total lack of that no zooming allowed abomination that seems so popular these days (As far as I'm concerned, full user-controlled scaling is *mandatory* for good usability on tiny hand-held devices, especially on these modern capacitive ones incapable of registering presses from anything more accurate than a blunt finger - or for anyone with less than 20/20 eyesight) Agreed. And it shouldn't just work reasonably well on mobile, it must work flawlessly well :)
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote: [snip] Or just a little switch in a corner somewhere to change the justification, with a cookie. That can be easily done (although I wouldn't use cookies) but I would prefer centered layout to be default option.
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote: On 4/18/14, 9:04, Aleksandar Ruzicic wrote: Hello, I've been D enthusiast for couple of years now (but I do not participate much in discussions here, although I read forums almost daily), and I keep telling people about D and how awesome it is. [snip] So, what do you guys think? -- Aleksandar I REALLY like the new look. I think it's about time to change the website up a little bit for the reasons listed above. It looks 'clean'. Go for it! Thanks! I'm planning to start working on this as soon as I get approval from Walter/Andrei, and as most of people who answered here are agreed that redesign would be a good thing I hope they wouldn't oppose..
Re: Spawn as many thousand threads as you like and D
Am 16.04.2014 20:34, schrieb Russel Winder via Digitalmars-d: On Wed, 2014-04-16 at 16:06 +0200, Sönke Ludwig via Digitalmars-d wrote: […] I agree, but I also wonder why you still keep ignoring vibe.d. It achieves exactly that - right now! Integration with std.concurrency would be great, but at least for now it has an API compatible replacement that can be merged later when Sean's pull request is done. Vibe.d is a single-thread event system, which is great (*) for the sort of problems Node.js, Vert.x, Tornado, Flask, Sinatra, Ratpack are used for. The point here is that CSP and dataflow are a concurrency and parallelism model that D has not got. I agree that those would be nice to have, but I think the main point was more about having transparent green threads than the actual concurrency model (at least that was the point that was itching me ;) std.concurrency is a heavyweight thread system so not really useful except to build thread pools and fork-join infrastructure. (OK that is a gross oversimplification.) std.parallelism is a great beginning of data parallelism on a thread pool. It needs more work. The thread pool needs to be brought front and centre, as a separate thing usable by other modules. On this CSP, dataflow, actors, etc. can be built. At least the infrastructure part is pretty much in place for vibe.d when using worker tasks [1]. The tasks are getting distributed among a set of worker threads and fibers (fibers are getting reused for efficiency), so that spawning tasks is a very light-weight operation. Due to other commitments, not least leading a massive update of GPars, I cannot lead on working on D things. If however someone can drive, I will certainly contribute, along the lines as I did when David Simcha wrote std.parallelism – mostly as a tester and reviewer. This also raises the issue of the D infrastructure having an obvious and documented way for people to contribute to things like std.parallelism. Whatever the truth, the perception is that to work on something like std.parallelism, you have to fork the whole of Phobos. In fact, std.parallelism is a single file 4,500 lines long (**). (*) It would be even better if it supported mocking for unit tests ;-) Absolutely, that's an issue I'm stumbling over every now and then for some parts of the code. The only issue is that it would need to be integrated in a way that doesn't make methods needlessly virtual (using interfaces everywhere) and doesn't break the API (using templates everywhere). (**) I am still not a fan of single files this big. (I actually hate this. I like to have a mental model of the source code I'm working on. But for Phobos code the only possibility is usually to stab at local parts found via a full text search, which always leaves a bad taste when making changes due to the unknown implications. A proper hierarchical organization with defined dependencies could work wonders there.) [1]: http://vibed.org/api/vibe.core.core/runWorkerTask
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 00:08:06 UTC, Kapps wrote: On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote: So, what do you guys think? -- Aleksandar I do agree that the design of the current site is rather dated. I rather like your new proposed design as well. One thing that could be nicer is the search bar being a button to click. It's standard now to just make it an input of type search with place-holder text now, which is faster and more useable. Even better, it could be automatically focused on when you load the (documentation) page so you can immediately start typing to look up an API / language feature. It sure looks like a button and it wouldn't be a button. It would be a regular text (search) input field (something that would be apparent as soon as you hover it and get that I-beam cursor over it) that would expand on click/focus (no JS needed there, don't worry Nick!). People who go directly to the homepage are likely coming to check out what D is or why they should use it (which the homepage shows), find a download button (which could still be improved upon), or search the documentation (which is still a few clicks away). I'd argue that most people are going for the third option since you don't need to download often and people just checking it out don't return frequently to check it out again. Having an immediate search field, ideally with autofocus, makes finding documentation a very easy task. I'm slightly against autofocus on search field, as I am one of people who use Backspace to navigate to previous page and I'm always frustrated when I hit Backspace on Google search results page and it's not taking me to previous page. But if majority thinks that autofocus on search is a good thing (I also think that not many people use Backspace as a means of navigation) than I would make it like that (and if there would be that little preferences page/popup this option is something that can go there together with justification settings). A prominent download button immediately visible on the home page rather than the top nav-bar would be an improvement as well. Practically every site with something to download does this, for good reason. It's one of the first things that should jump out at you when you view the site, making it as little effort as possible to commit to at least downloading the installer (see Dart, Python, Rust, Go, Ruby, etc). The longer / more effort it takes to do something, the less likely people are to try it unless they're already very convinced it's something they need. Download sites do that, so does sites that sell software. I think that dlang.org should focus on promoting D as a language, and compiler implementations should not be in spotlight. Also I think that having Download in top-nav as a first option is prominent enough. I've put what I think are the most important sections in top-nav bar (other navigation items should go to context-sensitive sidebar).
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu wrote: We can (and probably should) integrate server-side scripting as well. http://dlang.org/bugstats uses PHP. Ideally we'd migrate the entire website to vibe.d. Yes please. Ddoc might be better than plain HTML but most other frameworks for doing web sites are better than Ddoc. -- /Jacob Carlborg
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! Agree. I think we should use Bootstrap. Then we can also get a responsive web site for free. -- /Jacob Carlborg
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 08:35:32 UTC, Jacob Carlborg wrote: On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! Agree. I think we should use Bootstrap. Then we can also get a responsive web site for free. -- /Jacob Carlborg Bootstrap is great but I wouldn't use it for this project. As it might be difficult to work with when you don't want that bootstrap style look. OTOH Zurb's Foundation framework is all about structure and it leaves styling up to you which is great. Also, I prefer Sass over LESS :)
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic wrote: ... Download sites do that, so does sites that sell software. I think that dlang.org should focus on promoting D as a language, and compiler implementations should not be in spotlight. Also I think that having Download in top-nav as a first option is prominent enough. I've put what I think are the most important sections in top-nav bar (other navigation items should go to context-sensitive sidebar). Also can we have things like a getting started guide? That really impeded me at least when I was starting out.
Re: DIP60: @nogc attribute
On 2014-04-18 18:17, Brad Anderson wrote: Problems like how toUpperInPlace would still allocate (with gusto) could much more easily be recognized and fixed with @nogc available. toUpperInPlace should be removed. It cannot work reliable in place. -- /Jacob Carlborg
Re: DIP60: @nogc attribute
On 2014-04-18 22:25, Walter Bright wrote: dmd could do a better job of escape analysis, and do this automatically. That would be really nice. Is this long hanging fruit or does it require a lot of work? -- /Jacob Carlborg
Re: Redesign of dlang.org
On 2014-04-19 10:54, Aleksandar Ruzicic wrote: Bootstrap is great but I wouldn't use it for this project. As it might be difficult to work with when you don't want that bootstrap style look. OTOH Zurb's Foundation framework is all about structure and it leaves styling up to you which is great. I haven't really tried designing a web site with Bootstrap without Bootstrap styles but I think you can pick what you like and only use that. Also, I prefer Sass over LESS :) As a Ruby on Rails programmer, so do I. Therefore it's great that Bootstrap now days officially supports Sass [1]. BTW, I used Bootstrap with Sass long before it was officially supported, it worked great. [1] http://getbootstrap.com/css/#sass -- /Jacob Carlborg
Re: DIP60: @nogc attribute
Jacob Carlborg: toUpperInPlace should be removed. It cannot work reliable in place. Better to move it in std.ascii instead of removing it. Bye, bearophile
Re: DIP60: @nogc attribute
On 2014-04-19 12:21, bearophile wrote: Better to move it in std.ascii instead of removing it. The current implementation works with more characters than ASCII. -- /Jacob Carlborg
Re: Knowledge of managed memory pointers
On 2014-04-17 16:59, Steven Schveighoffer wrote: I don't think this is a viable mechanism to check pointers. It's too slow. Couldn't a single bit be used to indicate if it's a GC pointer or not? -- /Jacob Carlborg
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 10:23:39 UTC, Jacob Carlborg wrote: On 2014-04-19 10:54, Aleksandar Ruzicic wrote: Bootstrap is great but I wouldn't use it for this project. As it might be difficult to work with when you don't want that bootstrap style look. OTOH Zurb's Foundation framework is all about structure and it leaves styling up to you which is great. I haven't really tried designing a web site with Bootstrap without Bootstrap styles but I think you can pick what you like and only use that. Also, I prefer Sass over LESS :) As a Ruby on Rails programmer, so do I. Therefore it's great that Bootstrap now days officially supports Sass [1]. BTW, I used Bootstrap with Sass long before it was officially supported, it worked great. [1] http://getbootstrap.com/css/#sass Official Sass support for Bootstrap is news to me, thanks for info! I have been using Foundation in last few projects and haven't played with Bootstrap in a while but when I did I had to override most of it's styles to achieve look I wanted (which resulted in a significant amount of CSS/LESS needed just to remove Bootstrap's styles). I hope that things are better now..
Missed optimisation case - internal use of STCin
Hi, I'm currently testing out a GCC optimisation that allows you to set call argument flags. The current assumptions being: in parameters = Assume no escape, no clobber (read-only). ref parameters, classes and pointers = Assume worst case. default = Assume no escape. See here for implementation details: http://gcc.gnu.org/ml/fortran/2010-05/msg00032.html The idea for the 'in' parameters being that if we have the following: -- bool somefunc (in char[] a); The compiler can assume that whatever parameters are passed, they do not changes. So the compiler can more aggressively optimise the following case, for instance. eg: -- char[] foo = bar; assert(foo == bar); somefunc(foo); assert(foo == bar); One problem I've found with this though, is that the front-end tends to set all library function parameters as STCin, so the optimisation is fundamentally broken: eg: -- int[3] arr = [2,3,1]; arr.sort; // Defined internally as _adSort(in void[], in TypeInfo); assert(arr[0] == 1); // Compiler infers as false, throws assert. I think it would be more than reasonable to fix the frontend here so that the internal representation better matches that found in the internal runtime library. Just wanted to pass this by you guys first. Regards Iain.
Re: Redesign of dlang.org
Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. Also, search suggestions would require existence of some search service on the server. I believe that without too much effort an indexer can be written that will feed data to ElasticSearch[1] which would be used by a search service. What do you think? (Just note that this is not final design, I'm not really happy with typography here, but it shows concept good) [1] http://www.elasticsearch.org/
Re: Missed optimisation case - internal use of STCin
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote: Hi, I'm currently testing out a GCC optimisation that allows you to set call argument flags. The current assumptions being: in parameters = Assume no escape, no clobber (read-only). ref parameters, classes and pointers = Assume worst case. default = Assume no escape. That should read: ref parameters, inout parameters, classes and pointers. The default of assuming no escape is an experiment - I may limit this to only scalar types, and parameters marked as 'scope' (So long as no one plans on deprecating it soon :)
Re: Redesign of dlang.org
On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d digitalmars-d@puremagic.com wrote: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. Also, search suggestions would require existence of some search service on the server. I believe that without too much effort an indexer can be written that will feed data to ElasticSearch[1] which would be used by a search service. What do you think? (Just note that this is not final design, I'm not really happy with typography here, but it shows concept good) [1] http://www.elasticsearch.org/ I'm more a fan of Solr myself. https://lucene.apache.org/solr/
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 11:06:45 UTC, Iain Buclaw via Digitalmars-d wrote: On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d digitalmars-d@puremagic.com wrote: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. Also, search suggestions would require existence of some search service on the server. I believe that without too much effort an indexer can be written that will feed data to ElasticSearch[1] which would be used by a search service. What do you think? (Just note that this is not final design, I'm not really happy with typography here, but it shows concept good) [1] http://www.elasticsearch.org/ I'm more a fan of Solr myself. https://lucene.apache.org/solr/ I have experience with ElasticSearch but I'm open to all suggestions, if Solr is better, then we'll use Solr. But this is something Walter must approve first, as it would mean ditching Google search in favor of our own search service.
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 10:31:28 UTC, Jacob Carlborg wrote: On 2014-04-19 12:21, bearophile wrote: Better to move it in std.ascii instead of removing it. The current implementation works with more characters than ASCII. Or replace characters whose upper case representation is bigger than the lower case representation with U+FFFD or similar.
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! There is a reason why most editors have zen mode which centers your code on a screen. It's easier to read when it's centered and not too wide. You can have the browser window centered on screen and have your preferred width. It doesn't make sense to have wide window if don't ever want anything that wide, then every site which fits the window width automatically has your preferred width, otherwise the designer would need to figure out everyone's preferred width and accommodate for that, but how? [1] http://devdocs.io/ Sorry, your browser is not supported. I would understand, if it was an FPS web game, but what advanced technology a documentation site absolutely can't live without?
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote: I don't share your opinion that the web site need to be modern to avoid warding off potential adopters. If they are turned off of using a system programming language by a bland (debatable) site look and feel, then I think there was really something else bothering them. Case in point: http://gcc.gnu.org/
Re: Missed optimisation case - internal use of STCin
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote: On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote: Hi, I'm currently testing out a GCC optimisation that allows you to set call argument flags. The current assumptions being: in parameters = Assume no escape, no clobber (read-only). ref parameters, classes and pointers = Assume worst case. default = Assume no escape. That should read: ref parameters, inout parameters, classes and pointers. The default of assuming no escape is an experiment - I may limit this to only scalar types, and parameters marked as 'scope' (So long as no one plans on deprecating it soon :) What does assume no escape actually mean? [The above list doesn't really make sense. W/o context, it's hard to even tell why, hence the question.] Also, 'inout' is about constness -- doesn't affect lifetime and reachability, but does imply no clobbering. artur
Re: Redesign of dlang.org
Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. Also, search suggestions would require existence of some search service on the server. I believe that without too much effort an indexer can be written that will feed data to ElasticSearch[1] which would be used by a search service. What do you think? (Just note that this is not final design, I'm not really happy with typography here, but it shows concept good) [1] http://www.elasticsearch.org/ Note that for the new library documentation layout a similar search feature is already implemented (although not yet online), so the data is available.
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 05:08:06 UTC, froglegs wrote: Also possible in C# with structs, interop annotations and unsafe blocks. And now you aren't using the language, but a (very) poor subset of a language that doesn't even support templates. Doesn't change the fact it is possible, but hey lets sell C++ agenda. C++ exposes SSE/AVX intrinsics, C# does not. That is not correct. 1 - Nowhere in the ANSI/ISO C++ are SSE/AVX intrinsics defined, those are compiler extensions. So equal foot with the C# EMCA standard; Duh, but every C++ compiler exposes this, so it is defacto standard. C++ has plenty of non-standard standards, such as #pragma once. 3 - .NET Native and RyuJIT have official support for SIMD instructions, GPGPU support is also planned I see on MS website an article about having a vector data type. While interesting that isn't the same as exposing the actual instructions, which will limit potential gains. The aricle http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx Additionally .NET native will be MS only-- Except it already exists today with Mono. Microsoft is just making the official .NET do something, Xamarin has been doing the last years already, both in static native compilation and SIMD support. Any language can expose SIMD instructions, there is nothing special about them in C++, because like every other language, they are compiler extensions. Regardless of being a defacto standard or not. If I take the C# side on this, even though I also like C++, is because we are in a D forum, and having a C# native toolchain will certanly help young developers understand we don't need VMs for memory safe systems programming languages. Oberon compilers in the mid-90's were producing code that was as good as C compilers back then. On those days I still wrote a couple applications 100% in Assembly. I think many value too much C and C++ compilers, because they forget how long they have been around, and also never used alternative system programming languages back when C and C++ compilers used to suck. -- Paulo
Re: Missed optimisation case - internal use of STCin
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com wrote: On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote: On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote: Hi, I'm currently testing out a GCC optimisation that allows you to set call argument flags. The current assumptions being: in parameters = Assume no escape, no clobber (read-only). ref parameters, classes and pointers = Assume worst case. default = Assume no escape. That should read: ref parameters, inout parameters, classes and pointers. The default of assuming no escape is an experiment - I may limit this to only scalar types, and parameters marked as 'scope' (So long as no one plans on deprecating it soon :) What does assume no escape actually mean? [The above list doesn't really make sense. W/o context, it's hard to even tell why, hence the question.] Also, 'inout' is about constness -- doesn't affect lifetime and reachability, but does imply no clobbering. 'out' parameters - I sometimes confuse the two when I have a head cold. :o)
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 11:48:39 UTC, Kagamin wrote: On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! There is a reason why most editors have zen mode which centers your code on a screen. It's easier to read when it's centered and not too wide. You can have the browser window centered on screen and have your preferred width. It doesn't make sense to have wide window if don't ever want anything that wide, then every site which fits the window width automatically has your preferred width, otherwise the designer would need to figure out everyone's preferred width and accommodate for that, but how? I like my browser window maximized, that's how I've been using it for more than 10 years. And I'm not the only one. For other windows (editor/chat/etc) I have two additional monitors. It si true that it's impossible to satisfy all tastes but in my experience majority of websites nowadays are centered. But, when I say centered I mean having a maximum width of say 1200px, so that on most common resolutions it will be full-page website or it will be just slightly padded on both sides. Content would be left aligned, of course. On resolutions larger than 1200px in width additions information could be provided (from both sides, so that content stays centered and thus in spotlight). [1] http://devdocs.io/ Sorry, your browser is not supported. I would understand, if it was an FPS web game, but what advanced technology a documentation site absolutely can't live without? Which browser do you use? I've used it only on Firefox (Aurora to be precise) and it works flawlessly. That was just an example of how convenient is to have documentation filtered as you type. I'm not planning to make devdoc for d, just to provide nearly instantaneously results as user types search query.
Re: Missed optimisation case - internal use of STCin
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
Hi,
I'm currently testing out a GCC optimisation that allows you to set call
argument flags. The current assumptions being:
in parameters = Assume no escape, no clobber (read-only).
ref parameters, classes and pointers = Assume worst case.
default = Assume no escape.
That should read:
ref parameters, inout parameters, classes and pointers.
The default of assuming no escape is an experiment - I may limit this to
only scalar types, and parameters marked as 'scope' (So long as no one
plans on deprecating it soon :)
What does assume no escape actually mean?
[The above list doesn't really make sense. W/o context, it's
hard to even tell why, hence the question.]
Actually, I might change the default to assume worst case. I've just
tried this out, which is still valid.
class C {
int * p;
this(int x) {
p = x; // escapes the address of the parameter.
}
}
Worse, scope doesn't error on the general case either.
class D {
int * p;
this(scope int x) {
p = x; // escapes the address of the scope parameter.
}
}
Do these examples give you a good example?
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 12:04:11 UTC, Sönke Ludwig wrote: Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. Also, search suggestions would require existence of some search service on the server. I believe that without too much effort an indexer can be written that will feed data to ElasticSearch[1] which would be used by a search service. What do you think? (Just note that this is not final design, I'm not really happy with typography here, but it shows concept good) [1] http://www.elasticsearch.org/ Note that for the new library documentation layout a similar search feature is already implemented (although not yet online), so the data is available. That's excellent news! Would it be possible to use it to search through language reference too?
Re: DIP60: @nogc attribute
On Thursday, 17 April 2014 at 22:04:17 UTC, Walter Bright wrote: On 4/17/2014 1:03 PM, John Colvin wrote: E.g. you can implement some complicated function foo that writes to a user-provided output range and guarantee that all GC usage is in the control of the caller and his output range. As mentioned elsewhere here, it's easy enough to do a unit test for this. Erm, no? You can possibly track GC calls by using custom druntime fork but you can't track origins of such calls in source tree without compiler help. I hope Don's DConf talk will convince you how useful enforcing such model is ;) The advantage of having this as language instead of documentation is the turtles-all-the-way-down principle: if some function deep inside the call chain under foo decides to use a GC buffer then it's a compile-time-error. And that's how @nogc works. And it is not good enough for practical reasons, i.e. we won't be able to use @nogc for most of the Phobos.
Re: Missed optimisation case - internal use of STCin
On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
Hi,
I'm currently testing out a GCC optimisation that allows you to set call
argument flags. The current assumptions being:
in parameters = Assume no escape, no clobber (read-only).
ref parameters, classes and pointers = Assume worst case.
default = Assume no escape.
That should read:
ref parameters, inout parameters, classes and pointers.
The default of assuming no escape is an experiment - I may limit this to
only scalar types, and parameters marked as 'scope' (So long as no one
plans on deprecating it soon :)
What does assume no escape actually mean?
[The above list doesn't really make sense. W/o context, it's
hard to even tell why, hence the question.]
Actually, I might change the default to assume worst case. I've just
tried this out, which is still valid.
class C {
int * p;
this(int x) {
p = x; // escapes the address of the parameter.
}
}
This might be currently accepted, but it is clearly invalid
(escapes local; the only way to make it work safely would
be to silently copy 'x' to the GC-managed heap, which would be
way too costly).
A f(A a) { g(a); return a; } // likewise with ref instead of pointer.
This is OK (even if ideally 'g' should be forbidden from escaping 'a').
Similarly:
A f(A a) {
auto o = register(a); // can modify 'a'
o.blah(); // ditto
doneWith(o); // ditto
return a;
}
What I was wondering was things like whether that assume no escape
property was transitive; if /locally/ escaping was disallowed, and
to what extent. What does assume no escape mean at all? In your
examples you're mentioning refs together with pointers, that would
only make sense if no-escape were transitive -- but then treating all
args as no-escape would be very wrong.
Worse, scope doesn't error on the general case either.
class D {
int * p;
this(scope int x) {
p = x; // escapes the address of the scope parameter.
}
}
D's scope isn't enforced in any way right now, which means
that code could exist that is invalid, but currently works. It
would break silently(!) when compiled with a decent compiler,
which still doesn't enforce scope.
Do these examples give you a good example?
I'm worried about a) invalid assumptions making it into GDC;
b) certain valid assumptions making into GDC. The latter because
it could mean that code that's incorrect, but still accepted by
the other compilers could silently break when compiled with GDC.
artur
Re: DIP60: @nogc attribute
On 2014-04-18 23:48:43 +, Walter Bright newshou...@digitalmars.com said: On 4/18/2014 3:02 PM, Michel Fortin wrote: Objective-C enables ARC by default for all pointers to Objective-C objects. Since virtually all Objective-C APIs deal with Objective-C objects (or integral values), if you limit yourself to Objective-C APIs you're pretty much memory-safe. pretty much isn't really what we're trying to achieve with @safe. A lot of D code is memory safe too, but not all. Is D memory-safe? Yes, if you limit yourself to the @safe subset (and avoid the few holes remaining in it). Same thing for Objective-C: there exists a subset of the language that is memory safe, and pretty much everyone limit itself to that subset already, unless there's a reason to go lower-level and use C. In other words, unmanaged pointers are the assembler of Objective-C. It's unsafe and error prone, but it lets you optimize things when the need arise. The point being, D could have managed and unmanaged pointers (like Objective-C with ARC has), make managed pointers the default, and let people escape pointer management if they want to inside @system/@trusted functions. Yeah, it could, and the design of D has tried really hard to avoid such. Managed C++ was a colossal failure. I've dealt with systems with multiple pointer types before (16 bit X86) and I was really, really happy to leave that behind. Yet, there's C++ and its proliferation of library-implemented managed pointer types (shared_ptr, unique_ptr, weak_ptr, scoped_ptr, and various equivalents in libraries). Whether they're a success or a patch for shortcomings in the language, they're used everywhere despite the various mutually incompatible forms and being all leaky and arcane to use. And if I'm not mistaken, this is where the @nogc subset of D is headed. Already, and with good reason, people are suggesting using library managed pointers (such as RefCounted) as a substitute to raw pointers in @nogc code. That doesn't automatically make @nogc a failure — C++ is a success after all — but it shows that you can't live in a modern world without managed pointers. If multiple pointer types really dooms a language (your theory) then the @nogc D subset is doomed too. Yet, ARC-managed pointers are a huge success in Objective-C. I think the trick is to not bother people with various pointer types in regular code. Just make sure the default pointer type works everywhere in higher-level code, and then provide clear ways to escape that management and work at a lower level when you need to optimize a function or interface with external C code. D thrives with raw pointers only because its GC implementation happens to manage raw pointers. That's a brillant idea that makes things simpler, but this also compromises performance at other levels. I don't think there is a way out of that performance issue keeping raw pointers the default, even though I'd like to be proven wrong. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 10:07:46 UTC, Jacob Carlborg wrote: On 2014-04-18 18:17, Brad Anderson wrote: Problems like how toUpperInPlace would still allocate (with gusto) could much more easily be recognized and fixed with @nogc available. toUpperInPlace should be removed. Nonsense. It still works 99% of the time (I think only a subset of 100 letters in all of Unicode are affect, and even then, another 100 of them *shrink* on toUpper). It is really useful. It avoids *needles* allocations. Removing it would be more harmful than useful. I'm pretty confident that most of the time it is used, people don't care *that* much that *absolutely* no allocation takes place. They just don't want to be wasteful. It cannot work reliable in place. Rename toUpperMaybeInPlace. Then, for those that absolutely *can't* allocate provide a better interface. For example: `void toUpper(S, O)(S s, ref O o);` Burden on the caller to make it inplace from that (or to allocate accordingly when inplace is not possible).
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 11:21:05 UTC, Tobias Pankrath wrote: On Saturday, 19 April 2014 at 10:31:28 UTC, Jacob Carlborg wrote: On 2014-04-19 12:21, bearophile wrote: Better to move it in std.ascii instead of removing it. The current implementation works with more characters than ASCII. Or replace characters whose upper case representation is bigger than the lower case representation with U+FFFD or similar. Replacing a character with FFFD is only acceptable if it was invalid to begin with. Doing it because it's convenient is not acceptable.
Re: Missed optimisation case - internal use of STCin
On 19 April 2014 14:33, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
Hi,
I'm currently testing out a GCC optimisation that allows you to set call
argument flags. The current assumptions being:
in parameters = Assume no escape, no clobber (read-only).
ref parameters, classes and pointers = Assume worst case.
default = Assume no escape.
That should read:
ref parameters, inout parameters, classes and pointers.
The default of assuming no escape is an experiment - I may limit this to
only scalar types, and parameters marked as 'scope' (So long as no one
plans on deprecating it soon :)
What does assume no escape actually mean?
[The above list doesn't really make sense. W/o context, it's
hard to even tell why, hence the question.]
Actually, I might change the default to assume worst case. I've just
tried this out, which is still valid.
class C {
int * p;
this(int x) {
p = x; // escapes the address of the parameter.
}
}
This might be currently accepted, but it is clearly invalid
(escapes local; the only way to make it work safely would
be to silently copy 'x' to the GC-managed heap, which would be
way too costly).
A f(A a) { g(a); return a; } // likewise with ref instead of pointer.
This is OK (even if ideally 'g' should be forbidden from escaping 'a').
Similarly:
A f(A a) {
auto o = register(a); // can modify 'a'
o.blah(); // ditto
doneWith(o); // ditto
return a;
}
What I was wondering was things like whether that assume no escape
property was transitive; if /locally/ escaping was disallowed, and
to what extent. What does assume no escape mean at all? In your
examples you're mentioning refs together with pointers, that would
only make sense if no-escape were transitive -- but then treating all
args as no-escape would be very wrong.
Worse, scope doesn't error on the general case either.
class D {
int * p;
this(scope int x) {
p = x; // escapes the address of the scope parameter.
}
}
D's scope isn't enforced in any way right now, which means
that code could exist that is invalid, but currently works. It
would break silently(!) when compiled with a decent compiler,
which still doesn't enforce scope.
People should get bug fixing soon then. =)
Do these examples give you a good example?
I'm worried about a) invalid assumptions making it into GDC;
b) certain valid assumptions making into GDC. The latter because
it could mean that code that's incorrect, but still accepted by
the other compilers could silently break when compiled with GDC.
Invalid assumptions rarely make it into GDC. The testsuite is a good
bench for this, as well as several projects (now I've got dub set-up)
to test it in the wild.
Saying that, we have had to revert some optimisation cases as D's
schizophrenic nature of enforcing attributes and behaviours is
becoming increasingly dismal.
eg:
- nothrow has *no* guarantee, period, because it still allows
unrecoverable errors being thrown, and allows people to catch said
unrecoverable errors.
- pure is a tough nut to crack also. The theory should allow you to
be able to cache return values, but in practise...
- The nature of debug statements breaks guarantees of both nothrow and
pure, possibly many more.
- Defining reliable strict aliasing rules, it turns out, is not that
simple (this is something that Walter has mentioned about D should
have good guarantees for, ie: D arrays).
I'm just in investigating all avenues, as I usually do. There is no
reason why 'in' shouldn't have more powerful guarantees IMO, and what
I've found is not a problem with user code, it's a problem with the
compiler implementation.
For reference, this is the declaration of _adSort in rt.qsort:
extern (C) void[] _adSort(void[], TypeInfo);
This is how the compiler frontend defines the function internally for
its own use:
extern (C) T[] _adSort(in void[], in TypeInfo);
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 13:34:13 UTC, Michel Fortin wrote: Yet, ARC-managed pointers are a huge success in Objective-C. I think the trick is to not bother people with various pointer types in regular code. But you have to take the following into account: 1. Objective-C has a separate type for RC objects (although you have a toll-free bridge for some of CF). 2. Objective-C started out with inefficient manual RC, then required some restrictions on that when introducing ARC that removed some overhead, so the ARC overhead is less noticable. ARC isn't trivial to implement: http://clang.llvm.org/docs/AutomaticReferenceCounting.html D thrives with raw pointers only because its GC implementation happens to manage raw pointers. That's a brillant idea that makes things simpler, but this also compromises performance at other levels. I don't think there is a way out of that performance issue keeping raw pointers the default, even though I'd like to be proven wrong. Depends on how you look at it. GC does not really have a horrible performance issue, it has a terrible latency issue. If you can put everything that is latency sensitive into separate units then having background collection isn't all that bad. That is ok if you only read from the GC heap in the real time and write into non-GC buffers in real time (or have a backdoor into the GC heap during collection). If you can establish isolates of some sort (with multiple threads), then you can segment GC and reduce latency. If you take a graph that is 100% immutable, then you can GC-handle that graph as a single object. So, if you get semantics for freezing graphs (conversion to immutable) then you probably can cut down on collection time too. As the gap between memory bus speed and memory capacity increases, then more an more memory will stay mostly untouched. There is obviously opportunities for optimizing a GC for that, but you need the right semantics. Semantics beyond const-types. Surely, you can have both GC, and acceptable performance. I agree with Paulo Pinto on that point. But not with C-like semantics.
Re: Missed optimisation case - internal use of STCin
On Saturday, 19 April 2014 at 14:21:23 UTC, Iain Buclaw via Digitalmars-d wrote: eg: - nothrow has *no* guarantee, period, because it still allows unrecoverable errors being thrown, and allows people to catch said unrecoverable errors. Hm, it is hard to find clear answer in spec but I _think_ that replacing error throwing with program halting in release mode for nothrow function should be valid behavior.
Re: Missed optimisation case - internal use of STCin
On 19 April 2014 15:36, Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 19 April 2014 at 14:21:23 UTC, Iain Buclaw via Digitalmars-d wrote: eg: - nothrow has *no* guarantee, period, because it still allows unrecoverable errors being thrown, and allows people to catch said unrecoverable errors. Hm, it is hard to find clear answer in spec but I _think_ that replacing error throwing with program halting in release mode for nothrow function should be valid behavior. Nope. I can't recall the exact code, but an example is in the testsuite. It was discovered when porting to ARM, which was found to omit unwind directives for D nothrow functions, causing runtime hangs when said 'nothrow' functions infact threw an Error.
Re: Missed optimisation case - internal use of STCin
On Saturday, 19 April 2014 at 15:00:26 UTC, Iain Buclaw via Digitalmars-d wrote: Nope. I can't recall the exact code, but an example is in the testsuite. It was discovered when porting to ARM, which was found to omit unwind directives for D nothrow functions, causing runtime hangs when said 'nothrow' functions infact threw an Error. Now I am pretty sure _this_ is a druntime bug. I don't know about being able to catch actual exception but the fact that unwinding is not guaranteed for Errors is mentioned either on dlang.org or in TDPL.
Re: Missed optimisation case - internal use of STCin
On 04/19/14 16:21, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 14:33, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
I'm currently testing out a GCC optimisation that allows you to set call
argument flags. The current assumptions being:
in parameters = Assume no escape, no clobber (read-only).
ref parameters, classes and pointers = Assume worst case.
default = Assume no escape.
That should read:
ref parameters, inout parameters, classes and pointers.
The default of assuming no escape is an experiment - I may limit this to
only scalar types, and parameters marked as 'scope' (So long as no one
plans on deprecating it soon :)
What does assume no escape actually mean?
[The above list doesn't really make sense. W/o context, it's
hard to even tell why, hence the question.]
Actually, I might change the default to assume worst case. I've just
tried this out, which is still valid.
class C {
int * p;
this(int x) {
p = x; // escapes the address of the parameter.
}
}
This might be currently accepted, but it is clearly invalid
(escapes local; the only way to make it work safely would
be to silently copy 'x' to the GC-managed heap, which would be
way too costly).
A f(A a) { g(a); return a; } // likewise with ref instead of pointer.
This is OK (even if ideally 'g' should be forbidden from escaping 'a').
Similarly:
A f(A a) {
auto o = register(a); // can modify 'a'
o.blah(); // ditto
doneWith(o); // ditto
return a;
}
What I was wondering was things like whether that assume no escape
property was transitive; if /locally/ escaping was disallowed, and
to what extent. What does assume no escape mean at all? In your
examples you're mentioning refs together with pointers, that would
only make sense if no-escape were transitive -- but then treating all
args as no-escape would be very wrong.
Worse, scope doesn't error on the general case either.
class D {
int * p;
this(scope int x) {
p = x; // escapes the address of the scope parameter.
}
}
D's scope isn't enforced in any way right now, which means
that code could exist that is invalid, but currently works. It
would break silently(!) when compiled with a decent compiler,
which still doesn't enforce scope.
People should get bug fixing soon then. =)
Until some kind of diagnostics appear, most of those bugs won't
even be found. It's too easy to write auto f (in A a) and then
forget about the implicit 'scope' when modifying the function body.
Do these examples give you a good example?
I'm worried about a) invalid assumptions making it into GDC;
b) certain valid assumptions making into GDC. The latter because
it could mean that code that's incorrect, but still accepted by
the other compilers could silently break when compiled with GDC.
Invalid assumptions rarely make it into GDC. The testsuite is a good
AFAICT what you're proposing *is* invalid. I can't be sure because
it's not clear what that no-escape property means; that's why I
asked about it twice already...
Clearly, escaping objects reachable indirectly via function arguments
is perfectly fine (eg string slicing), yet you wanted to treat args as
no-escape by default.
Also, treating /some/ types specially wouldn't be ideal;
struct A { int a; /* no pointers or classes */ }
struct B { int* b; /*...*/ }
f(A); // should be treated similarly to 'f(int)'
f(B); // should be treated similarly to 'f(int*)'
Yes, not doing it is just a missed optimization, but in practice
it means that wrapping types becomes even more expensive in D (it's
already almost prohibitively so - eg returning small one-element
structs from functions needlessly happens by ref).
bench for this, as well as several projects (now I've got dub set-up)
to test it in the wild.
These problems will result in invalid optimizations, so can be hard
to trigger and may come and go away randomly.
Saying that, we have had to revert some optimisation cases as D's
schizophrenic nature of enforcing attributes and behaviours is
becoming increasingly dismal.
eg:
- nothrow has *no* guarantee, period, because it still allows
unrecoverable errors being thrown, and allows people to catch said
unrecoverable errors.
- pure is a tough nut to crack also. The theory should allow you to
be able to cache return values, but in practise...
D's pure doesn't have much in common with the normal pure concept;
exposing gcc's pure via an attribute and completely ignoring D's
version is probably the only practical solution, anything else would
be too costly, result in too small gains, and
SCons and D
My changes to SCons to support gdc and ldc2 as well as dmd, and to integrate D as a peer to C++ appear to have been merged into SCons mainline/default. This means it is time to retire the SCons_D_Tooling repository. Well, not so much retire as take out and terminate with severe prejudice – due to the merging strategy I had been using, the repository has no future. If I can get everyone using my fork of SCons to switch to using the SCons mainline, I'd appreciate it. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: DIP60: @nogc attribute
On 4/19/2014 3:10 AM, Jacob Carlborg wrote: On 2014-04-18 22:25, Walter Bright wrote: dmd could do a better job of escape analysis, and do this automatically. That would be really nice. Is this long hanging fruit or does it require a lot of work? It requires a decent working knowledge of data flow analysis techniques, and some concentrated effort.
Re: DIP60: @nogc attribute
On 4/19/2014 6:14 AM, Dicebot wrote: On Thursday, 17 April 2014 at 22:04:17 UTC, Walter Bright wrote: On 4/17/2014 1:03 PM, John Colvin wrote: E.g. you can implement some complicated function foo that writes to a user-provided output range and guarantee that all GC usage is in the control of the caller and his output range. As mentioned elsewhere here, it's easy enough to do a unit test for this. Erm, no? You can possibly track GC calls by using custom druntime fork but you can't track origins of such calls in source tree without compiler help. @nogc is there to help. The advantage of having this as language instead of documentation is the turtles-all-the-way-down principle: if some function deep inside the call chain under foo decides to use a GC buffer then it's a compile-time-error. And that's how @nogc works. And it is not good enough for practical reasons, i.e. we won't be able to use @nogc for most of the Phobos. The first step is to identify the parts of Phobos that unnecessarily use the GC. @nogc will help a lot with this.
Re: SCons and D
On Sat, Apr 19, 2014 at 06:21:10PM +0100, Russel Winder via Digitalmars-d wrote: My changes to SCons to support gdc and ldc2 as well as dmd, and to integrate D as a peer to C++ appear to have been merged into SCons mainline/default. Yay! This means it is time to retire the SCons_D_Tooling repository. Well, not so much retire as take out and terminate with severe prejudice – due to the merging strategy I had been using, the repository has no future. Well, thanks for all your work on it. I've been using your repo for all my D projects, and it has served well. If I can get everyone using my fork of SCons to switch to using the SCons mainline, I'd appreciate it. [...] I will, once the new SCons gets into the main Debian repo. (Or is it already in?) T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 17:41:58 UTC, Walter Bright wrote:
The first step is to identify the parts of Phobos that
unnecessarily use the GC. @nogc will help a lot with this.
Unless I missed it, I think we still haven't answered the issue
with throwing exceptions. I'm in particular interested in asserts
and Errors.
Will assert be usable in @nogc code? Because if not, then
basically *none* of phobos will be @nogc.
Also, I don't think statically pre-allocating the error is an
acceptable workaround.
EG:
assert(arr.length, arr is empty.);
vs
version (assert)
{
static Error e = new Error(arr is empty.);
if (!arr.length) throw e;
}
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 17:51:38 UTC, monarch_dodra wrote: Also, I don't think statically pre-allocating the error is an acceptable workaround. Just in case that's not clear, I mean for the generic assert(...). For throwing actual run-time exceptions, I think it's fine to require a static preallocation in an @nogc. Though it does raise the issue of things such as global state (what if a catcher changes the msg?), exception threading, and finaly, purity. Seems @nogc prevents both a the same time can throw and pure ... ?
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 17:41:58 UTC, Walter Bright wrote: On 4/19/2014 6:14 AM, Dicebot wrote: On Thursday, 17 April 2014 at 22:04:17 UTC, Walter Bright wrote: On 4/17/2014 1:03 PM, John Colvin wrote: E.g. you can implement some complicated function foo that writes to a user-provided output range and guarantee that all GC usage is in the control of the caller and his output range. As mentioned elsewhere here, it's easy enough to do a unit test for this. Erm, no? You can possibly track GC calls by using custom druntime fork but you can't track origins of such calls in source tree without compiler help. @nogc is there to help. The advantage of having this as language instead of documentation is the turtles-all-the-way-down principle: if some function deep inside the call chain under foo decides to use a GC buffer then it's a compile-time-error. And that's how @nogc works. And it is not good enough for practical reasons, i.e. we won't be able to use @nogc for most of the Phobos. The first step is to identify the parts of Phobos that unnecessarily use the GC. @nogc will help a lot with this. I feel like the origin of the discussion has been completely lost here and we don't speak the same language right now. The very point I have made initially is that @nogc in a way it is defined in your DIP is too restrictive to be effectively used in Phobos. In lot of standard library functions you may actually need to allocate as part of algorithm, strict @nogc is not applicable there. However, it is still extremely useful that no _hidden_ allocations happen outside of weel-defined user API and this is something that less restrictive version of @nogc could help with. The fact that you propose me to use unit tests to verify same guarantees hints that I have completely failed to explain my proposal but I can't really rephrase it any better without some help from your side to identify the point of confusion.
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote: In lot of standard library functions you may actually need to allocate as part of algorithm, strict @nogc is not applicable there. However, it is still extremely useful that no _hidden_ allocations happen outside of weel-defined user API and this is something that less restrictive version of @nogc could help with. What you want is to mark some functions with @allow_gc ? So that you only get GC where specified as a contract? But isn't this more suitable for dynamic tracing/logging? Because what you want is probably the frequency of GC allocations in a particular call tree?
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 18:12:32 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
In lot of standard library functions you may actually need to
allocate as part of algorithm, strict @nogc is not applicable
there. However, it is still extremely useful that no _hidden_
allocations happen outside of weel-defined user API and this
is something that less restrictive version of @nogc could help
with.
What you want is to mark some functions with @allow_gc ? So
that you only get GC where specified as a contract?
But isn't this more suitable for dynamic tracing/logging?
Because what you want is probably the frequency of GC
allocations in a particular call tree?
Original proposal, updated and re-worded as formal as possible.
weak @nogc functions / methods are identical to normal @nogc
function but are allowed to trigger GC via functions / methods
directly accessible via its arguments. Such weak @nogc functions
can only call strict @nogc functions in any other context.
Exact details get tricky rather quick and this is something that
needs thorough examination but rationale behind this is to move
all allocation decisions exclusively to caller side. Frequency
does not matter here, only the fact that function does not cause
allocations of its own.
Again, example of a pattern that should be common in Phobos:
void foo(ref OutputBuffer buffer) @nogc
{
buffer.put(42); // buffer.put may be not @nogc, this turns
foo into weak @nogc
throw new Exception(); // put this is prohibited anyway
someGCFunction(); // as well as this..
int[] arr; arr ~= 42; // ..and this
}
User of such functions will be 100% sure that if any allocations
happen, he is the one to blame and can tweak it in his own code,
possibly using OutputBuffer implementation that does not use GC
or allocations at all.
Re: DIP60: @nogc attribute
On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
I feel like the origin of the discussion has been completely
lost here and we don't speak the same language right now. The
very point I have made initially is that @nogc in a way it is
defined in your DIP is too restrictive to be effectively used
in Phobos.
In lot of standard library functions you may actually need to
allocate as part of algorithm, strict @nogc is not applicable
there. However, it is still extremely useful that no _hidden_
allocations happen outside of weel-defined user API and this is
something that less restrictive version of @nogc could help
with.
The fact that you propose me to use unit tests to verify same
guarantees hints that I have completely failed to explain my
proposal but I can't really rephrase it any better without some
help from your side to identify the point of confusion.
I feel what you are asking for is that something that is part of
the interface (qualifier), make no actual promises about the
function itself, but rather only help you with your
implementation? That feels wrong.
I see little value in doing:
void fun(T)(ref T t) @nogc
{
t.allocateOnGc(); //This is fine because T does it?
}
This is what you are asking for? Am I correct?
I also still don't see why @nogc would behave any different from
nothrow, pure or @safe.
***THAT SAID***, unless I'm mistaken, wouldn't your requirements
be better answered by the qualified block proposal? Remember
that proposal that (would) have allowed us to do:
void fun() @safe
{
@trusted { //doesn't create scope.
T t = someUnsafeFunctionITrust();
}
t.doIt(); //doIt must be safe
}
By the same standard, you could use it to enforce no GC. But only
in certain areas.
EG:
void fun(T)(ref T t) //inferred
{
t.allocate(); //I'm fine with this using GC
@nogc : //But as of this line, I want the compiler to ban the
GC altogether
doThings(); //I can rest assured this won't allocate on the
GC.
}
Personally, I still feel this would be a *much* more natural,
idiomatic, and more transparent approach to doing things, than
the current trusted lambda *crap* we've been doing. And it would
indeed help with writing things correctly.
...
...or I misunderstood you, in which case I apologize.
Re: DIP60: @nogc attribute
On 4/19/2014 10:51 AM, monarch_dodra wrote: On Saturday, 19 April 2014 at 17:41:58 UTC, Walter Bright wrote: The first step is to identify the parts of Phobos that unnecessarily use the GC. @nogc will help a lot with this. Unless I missed it, I think we still haven't answered the issue with throwing exceptions. I'm in particular interested in asserts and Errors. It wouldn't affect asserts.
Re: DIP60: @nogc attribute
On 4/19/2014 11:05 AM, Dicebot wrote: I feel like the origin of the discussion has been completely lost here and we don't speak the same language right now. The very point I have made initially is that @nogc in a way it is defined in your DIP is too restrictive to be effectively used in Phobos. In lot of standard library functions you may actually need to allocate as part of algorithm, strict @nogc is not applicable there. However, it is still extremely useful that no _hidden_ allocations happen outside of weel-defined user API and this is something that less restrictive version of @nogc could help with. The fact that you propose me to use unit tests to verify same guarantees hints that I have completely failed to explain my proposal but I can't really rephrase it any better without some help from your side to identify the point of confusion. The way I understood your idea, was that a template could be marked @nogc, and yet still allow template arguments that themselves may gc. This can be accomplished by creating a unit test that passes non-allocating template parameters, and then verifying the instantiation is @nogc.
Re: SCons and D
On Sat, 2014-04-19 at 10:50 -0700, H. S. Teoh via Digitalmars-d wrote: On Sat, Apr 19, 2014 at 06:21:10PM +0100, Russel Winder via Digitalmars-d wrote: My changes to SCons to support gdc and ldc2 as well as dmd, and to integrate D as a peer to C++ appear to have been merged into SCons mainline/default. Yay! :-) This means it is time to retire the SCons_D_Tooling repository. Well, not so much retire as take out and terminate with severe prejudice – due to the merging strategy I had been using, the repository has no future. Well, thanks for all your work on it. I've been using your repo for all my D projects, and it has served well. Thanks. From now on any D tool related bugs should go to the main SCons issue repository. If I can get everyone using my fork of SCons to switch to using the SCons mainline, I'd appreciate it. [...] I will, once the new SCons gets into the main Debian repo. (Or is it already in?) Can I get you to switch sooner? I want to actually remove the SCons_D_tooling repository from BitBucket. I believe that cloning the SCons mainline is entirely equivalent as I always kept SCons_D_Tooling up-to-date. An alternative is to clone my SCons repository on Mercurial, which is where I will be putting any future D-related changes. A new version of SCons will appear in Debian Sid only after a formal release and I am not sure when that will be. There has been quite a lot of activity on SCons recently so mayhap I can activate for a release sooner rather than later. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: DIP60: @nogc attribute
I think it would be useful to be able to mark structs as @nogc_alloc or something similar. Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them. Even with @nogc threads for audio/visual real time computations the GC itself will have to get down to consistent 50-200ms freezes to get fluid interaction for content computations.
Re: Redesign of dlang.org
On 4/18/2014 1:24 PM, Steven Schveighoffer wrote: On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic aleksan...@ruzicic.info wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! Making something that works like this would be excellent: http://forum.dlang.org/ God no. I like forum.dlang.org and all, but scaling the font size when the window resizes is horrible UX. Example: If I shrink the browser window, for *whatever* reason, I expect not to have an over-zealous CSS decide Oh! He must want the text to become ridiculously small! Ok!
Re: Redesign of dlang.org
On 4/19/2014 3:45 AM, Aleksandar Ruzicic wrote: On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote: [snip] Or just a little switch in a corner somewhere to change the justification, with a cookie. That can be easily done (although I wouldn't use cookies) but I would prefer centered layout to be default option. (left/right/centered) Layout != (left/right/centered/justified) text justification I don't think anyone's argued against the page layout itself being centered (as long as you don't mean to center the text itself - that would be one of the worst ways for text justification).
Re: Redesign of dlang.org
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! Why does everyone these days seem to forget that windows are resizable? FWIW though, I find *everything* freaking unreadable and barely-usable on a 16:9 - good for media, worthless for computing. There is a reason why most editors have zen mode which centers your code on a screen. It's easier to read when it's centered and not too wide. Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable. I would go for a maximum of 120 characters wide lines with content centered on larger monitors. Text justification has nothing to do with maximum line width. max-width works perfectly fine with left-justified, too. And left-justified makes it easier to distinguish individual lines, otherwise it's easier to loose your place when reading from one line down to the next line. Plus it does suffer from those inconsistently-sized spaces.
Re: Redesign of dlang.org
On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. I don't know anything about the specific search-suggestion engines, but as far as looks I (mostly) really like it. Only two comments: - There should be some visual indication of the search box besides the text itself. It *looks* nice as you have it, but practically speaking it'd be a bit awkward to not be able to see the box itself. - A *lot* of search boxes on the internet these days bake the Enter search term here (or whatever) text into the HTML, forcing non-JS users to delete the text before they're able to enter their search term. That's bad UX. Instead, the Enter search term here text should be *added* via JS and left blank in the raw HTML. That's a trivial way to ensure it works great for both JS and non-JS users.
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 21:34:31 UTC, Nick Sabalausky wrote: On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote: I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! Why does everyone these days seem to forget that windows are resizable? FWIW though, I find *everything* freaking unreadable and barely-usable on a 16:9 - good for media, worthless for computing. There is a reason why most editors have zen mode which centers your code on a screen. It's easier to read when it's centered and not too wide. Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable. I would go for a maximum of 120 characters wide lines with content centered on larger monitors. Text justification has nothing to do with maximum line width. max-width works perfectly fine with left-justified, too. And left-justified makes it easier to distinguish individual lines, otherwise it's easier to loose your place when reading from one line down to the next line. Plus it does suffer from those inconsistently-sized spaces. As I've said in one of previous messages, text will be left-aligned, there is no way I would make it centered. I was talking about layout alignment. I was talking about max-width as a means to keep text readable, as 300 characters per line is really too hard to read. It seems I'll have to implement this design proposal in HTML/CSS to be able to better communicate design decisions.
Re: Redesign of dlang.org
On 4/19/2014 7:48 AM, Kagamin wrote: On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: [1] http://devdocs.io/ Sorry, your browser is not supported. I would understand, if it was an FPS web game, but what advanced technology a documentation site absolutely can't live without? I get This site is asking to store data on your computer for offline use. I always decline that sort of thing. Aside from games (which really belong outside the browser anyway), anything that can't be handled via a normal session cookie is questionable and doesn't belong on my computer.
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote: On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote: Ok here's a mockup of search concept I would like to implement: http://krcko.net/dlang.org/dlang-search-concept.png Search suggestions feature would surely require JavaScript but IMHO it would be a really nice enhancement. I don't know anything about the specific search-suggestion engines, but as far as looks I (mostly) really like it. Only two comments: - There should be some visual indication of the search box besides the text itself. It *looks* nice as you have it, but practically speaking it'd be a bit awkward to not be able to see the box itself. OK, I'll work on a design more, I'll also try to have real designers involved to help me with these UX stuff. - A *lot* of search boxes on the internet these days bake the Enter search term here (or whatever) text into the HTML, forcing non-JS users to delete the text before they're able to enter their search term. That's bad UX. Instead, the Enter search term here text should be *added* via JS and left blank in the raw HTML. That's a trivial way to ensure it works great for both JS and non-JS users. Nowdays there is something called placeholder attribute[1] on input elements that servers just for that purpose (text goes away as soon as you start typing) and there is no JS needed for that as it is supported by all major browsers. But I like to add fallback (that works even without JS, but better with JS) for that on old browsers which don't support that feature. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML#The_placeholder_attribute
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 21:49:20 UTC, Nick Sabalausky wrote: On 4/19/2014 7:48 AM, Kagamin wrote: On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: [1] http://devdocs.io/ Sorry, your browser is not supported. I would understand, if it was an FPS web game, but what advanced technology a documentation site absolutely can't live without? I get This site is asking to store data on your computer for offline use. I always decline that sort of thing. Aside from games (which really belong outside the browser anyway), anything that can't be handled via a normal session cookie is questionable and doesn't belong on my computer. They use it to remember your selection of languages/frameworks if I'm not mistaken. That can surely be stored in a Cookie, but I also prefer localStorage, mostly for performance reasons (cookies get sent on *every* request, unless you setup subdomain just for that type of cookies) and for the fact that cookies are the worst thing ever happened to HTTP :)
Re: Redesign of dlang.org
On 4/18/2014 12:53 PM, Brad Anderson wrote: Even if it weren't better looking, just different, I'd say it should be done. I'm of the opinion that every site, no matter how good it looks, should go through redesigns periodically in order to feel fresh and non-stagnant to repeat visitors. It's a form of marketing that reassures users that something is being actively developed. On a philosophical level, I *very* strongly disagree with this as I think it amounts to deliberate enforcement of screwing with shit that ain't broke just for the sake of fucking around with it. If anything, I'm more likely lose respect for things that can't just decide on a look/layout and stick with it. Constantly keeping *CONTENT* up-to-date is *far* more indicative of active development than constant rejiggering of trivialities like style. The latter gives the impression that the developers have their priorities all wrong and are actively looking for anything to distract themselves with. *BUT*, I admit that's all just academic since I *do* agree that the proposed new design does indeed look fantastic and is worthy of replacing the current one. That said, I also happen to think your design looks fantastic and should replace the current one just based on its appearance and big improvements to usability. It feels more professional. I'm all for this change.
Re: Redesign of dlang.org
On 4/20/14, Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote: On a philosophical level, I *very* strongly disagree with this as I think it amounts to deliberate enforcement of screwing with shit that ain't broke just for the sake of fucking around with it. Yep. Also see how often MSDN breaks their links to their docs. Not that they were ever descriptive, which is another bad UX example. E.g. a page named dd183370(v=vs.85).aspx.
Re: Redesign of dlang.org
On 4/18/2014 2:56 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: Nice initiative, but the top bar looks a lot like adobe.com . I think something less corporate would be more suitable. What are you trying to communicate? A community or a corporation? I had a brief thought of that too, but I quickly dismissed it because it really *isn't* corporate-looking... I swear I'm not joking about this: *Real* corporate sites are: 1. Covered with obviously-stock photos of evenly-distributed easily-identifiable ethnicities (nothing mixed or ethnicly-ambiguous), with 50%/50%/0% gender ratio (if anything, biased towards black females with 90's hip curly-poofy hairstyles), all in suits with unrealistically gigantic Gosh I *LOVE* working in IT and/or customer support call center smiles. 2. *All* the text across the entire page is completely vacuous, highly subjective *at best*, and generally carries no real meaning whatsoever. So while there are some corporate-like elements (flat shading, clean straight lines, limited saturated-colors palette - all of which are just as modern as they are corporate) this mockup, overall, is definitely *not* very corporate-looking IMO.
Re: Redesign of dlang.org
On 4/18/2014 4:12 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: 1. visitors are likely to be familiar with one of those 2. they might have figured out something that works 3. you want to do at least what they do, but better Good points. IMO: http://www.rust-lang.org/ Too black-and-white. http://golang.org/ Too cluttered *and* too plain-white. https://www.dartlang.org/ This is a popular new style that I really, really dislike. The entry page basically amounts to one of those horribly useless intro/entry pages that used to be popular in the late 90's even though nobody liked them (*because* they were so completely useless). It's not quite *as* bad as those old intro pages, but it's only just *barely* better. They've dedicated their entire entry page to little more than a slogan. I hate pointless entry pages like that. It's such a trendy style that I guarantee it's going to look dated within 5 years. https://www.python.org/ This is a much better, less useless, variant of the popular dartlang.org style above. It isn't bad, but I'm not sure D really needs to follow this style.
Re: Redesign of dlang.org
On 4/19/2014 6:52 PM, Nick Sabalausky wrote: On 4/18/2014 4:12 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: https://www.python.org/ This is a much better, less useless, variant of the popular dartlang.org style above. It isn't bad, but I'm not sure D really needs to follow this style. One very notable downside of this style is that it pretty much requires that mobile be handled separately with a completely different layout. I see no point in wasting effort maintaining dual designs (and providing such an inconsistent UX in the process) when you can just use one style that works fine on all devices.
Re: Redesign of dlang.org
On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote: That can surely be stored in a Cookie, but I also prefer localStorage, mostly for performance reasons (cookies get sent on *every* request, unless you setup subdomain just for that type of cookies) and for the fact that cookies are the worst thing ever happened to HTTP :) Session cookies are a few **bytes** in size. Selection of languages/frameworks would also be a mere handful of bytes. That's completely dwarfed by just the HTTP headers alone. There is *NO* performance issue here whatsoever unless you're on a circa-1980's dial-up (in which case the cookie itself *still* isn't going to be the main performance issue ;) )
Re: Redesign of dlang.org
On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote: On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote: - There should be some visual indication of the search box besides the text itself. It *looks* nice as you have it, but practically speaking it'd be a bit awkward to not be able to see the box itself. OK, I'll work on a design more, I'll also try to have real designers involved to help me with these UX stuff. Honestly, I think you're selling yourself short here. You appear to have a pretty good eye for design. - A *lot* of search boxes on the internet these days bake the Enter search term here (or whatever) text into the HTML, forcing non-JS users to delete the text before they're able to enter their search term. That's bad UX. Instead, the Enter search term here text should be *added* via JS and left blank in the raw HTML. That's a trivial way to ensure it works great for both JS and non-JS users. Nowdays there is something called placeholder attribute[1] on input elements that servers just for that purpose (text goes away as soon as you start typing) and there is no JS needed for that as it is supported by all major browsers. But I like to add fallback (that works even without JS, but better with JS) for that on old browsers which don't support that feature. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML#The_placeholder_attribute Interesting, first I've heard of it. I'll have to try it out, see if browsers are intelligent enough to *not* make users delete it when JS is off. If so, then that's a pretty nice attribute.
Re: Redesign of dlang.org
On 4/19/2014 3:48 AM, Aleksandar Ruzicic wrote: On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote: As long as it's: - A normal reflowing layout (not a static fixed-width one or an auto-rescaling one) Of course. Cool. - Doesn't require JS (optional JS enhancements are fine) I was told you would oppose usage of JavaScript. :) Heh, yea, I'm kinda well-known for that 'round these parts ;) But as I've said already I plan on using JavaScript to enhance things a bit only, site would function normally with JavaScript unavailable/disabled. Yea, that's cool. Honestly, even I do that too. - Works reasonably well on mobile *including* a complete and total lack of that no zooming allowed abomination that seems so popular these days (As far as I'm concerned, full user-controlled scaling is *mandatory* for good usability on tiny hand-held devices, especially on these modern capacitive ones incapable of registering presses from anything more accurate than a blunt finger - or for anyone with less than 20/20 eyesight) Agreed. And it shouldn't just work reasonably well on mobile, it must work flawlessly well :) Heh, personally, I think working flawlessly well on mobile pretty much requires a PalmOS device (long since defunct), but that's a whole other twenty rants and would only make me feel old ;)
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote: On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote: That can surely be stored in a Cookie, but I also prefer localStorage, mostly for performance reasons (cookies get sent on *every* request, unless you setup subdomain just for that type of cookies) and for the fact that cookies are the worst thing ever happened to HTTP :) Session cookies are a few **bytes** in size. Selection of languages/frameworks would also be a mere handful of bytes. That's completely dwarfed by just the HTTP headers alone. There is *NO* performance issue here whatsoever unless you're on a circa-1980's dial-up (in which case the cookie itself *still* isn't going to be the main performance issue ;) ) Yes they are few bytes but they are sent for *every* request. That includes every image, every css/js file.. When working on large scale you want to avoid any unnecessary headers, not so much because of a client but because of a server. I work on a website that has millions unique visits weakly and when I've introduced new subdomain for static content (so that cookies wouldn't be sent for every image, and images are major form of content there) we've noticed improvements on server's performance charts. So I'll always argue that having less cookies means (even slightly) better performance :) But anyway, we're going slightly off-topic with this..
Re: Redesign of dlang.org
On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote: On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote: It looks 'clean'. Go for it! Thanks! I'm planning to start working on this as soon as I get approval from Walter/Andrei, and as most of people who answered here are agreed that redesign would be a good thing I hope they wouldn't oppose.. Although I empathize with not wanting to put the full work into something if there's a chance it may just get rejected at the last step, this is unfortunately the sort of thing that really needs to be in a full working pull request before you're likely to get any final official approval. Not getting an outright up-front objections is kinda the closest thing D has to pre-approval for large changes like this.
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 23:10:58 UTC, Nick Sabalausky wrote: On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote: On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote: - There should be some visual indication of the search box besides the text itself. It *looks* nice as you have it, but practically speaking it'd be a bit awkward to not be able to see the box itself. OK, I'll work on a design more, I'll also try to have real designers involved to help me with these UX stuff. Honestly, I think you're selling yourself short here. You appear to have a pretty good eye for design. Heh, that's nice to hear, tnx! :) But I have never before designed a website so I'm pretty skeptical about it. It seems that years of slicing and coding website designs thought me something, so it's not entirely waster years there.. :) [snip] Interesting, first I've heard of it. I'll have to try it out, see if browsers are intelligent enough to *not* make users delete it when JS is off. If so, then that's a pretty nice attribute. Yep, it' really nice UX element and it works without JS too! :)
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 23:21:15 UTC, Nick Sabalausky wrote: On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote: On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote: It looks 'clean'. Go for it! Thanks! I'm planning to start working on this as soon as I get approval from Walter/Andrei, and as most of people who answered here are agreed that redesign would be a good thing I hope they wouldn't oppose.. Although I empathize with not wanting to put the full work into something if there's a chance it may just get rejected at the last step, this is unfortunately the sort of thing that really needs to be in a full working pull request before you're likely to get any final official approval. Not getting an outright up-front objections is kinda the closest thing D has to pre-approval for large changes like this. Ok then. Given that I haven't received up-front rejections I'll start working on this and hope it wouldn't be in vain. :)
Re: Redesign of dlang.org
On 4/19/2014 4:16 AM, Aleksandar Ruzicic wrote: I'm slightly against autofocus on search field, as I am one of people who use Backspace to navigate to previous page and I'm always frustrated when I hit Backspace on Google search results page and it's not taking me to previous page. But if majority thinks that autofocus on search is a good thing (I also think that not many people use Backspace as a means of navigation) than I would make it like that (and if there would be that little preferences page/popup this option is something that can go there together with justification settings). I use a browser extension to disable backspace navigation since I get annoyed when I try to type something and the browser decides to navigate to a different page ;). That said, I don't really have an preference on autofocus vs not-autofocus. Download sites do that, so does sites that sell software. I think that dlang.org should focus on promoting D as a language, and compiler implementations should not be in spotlight. Also I think that having Download in top-nav as a first option is prominent enough. I've put what I think are the most important sections in top-nav bar (other navigation items should go to context-sensitive sidebar). I strongly believe that a prominent link the the downloads page is one of the *most* important things to have in the top-nav bar. We may not be selling it for $$, but we are selling people on it. I know I get annoyed when I'm on some software's website, want to download it, and have to looking around for it because I don't see a download link in the typical download link location (top nav-bar). We want people to download it and try it, so it's good to match people's expectations here.
Re: DIP60: @nogc attribute
Am Wed, 16 Apr 2014 20:32:20 +
schrieb Peter Alexander peter.alexander...@gmail.com:
On Wednesday, 16 April 2014 at 20:29:17 UTC, bearophile wrote:
Peter Alexander:
(I assume that nothrow isn't meant to be there?)
In D nothrow functions can throw errors.
Of course, ignore me :-)
You could do something like this:
void foo() @nogc
{
static err = new Error();
if (badthing)
{
err.setError(badthing happened);
throw err;
}
}
To be mutable err also needs to be __gshared.
But then it isn't thread safe. Two threads trying to set and
throw the same Error is a recipe for disaster.
Also: As far as I remember from disassembling C++, static
variables in functions are initialized on first access and
guarded by a bool. The first call to foo() would execute
err = new Error(); in that case. This code should not
compile under @nogc.
--
Marco
Re: Redesign of dlang.org
On 4/19/2014 7:19 PM, Aleksandar Ruzicic wrote: On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote: On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote: That can surely be stored in a Cookie, but I also prefer localStorage, mostly for performance reasons (cookies get sent on *every* request, unless you setup subdomain just for that type of cookies) and for the fact that cookies are the worst thing ever happened to HTTP :) Session cookies are a few **bytes** in size. Selection of languages/frameworks would also be a mere handful of bytes. That's completely dwarfed by just the HTTP headers alone. There is *NO* performance issue here whatsoever unless you're on a circa-1980's dial-up (in which case the cookie itself *still* isn't going to be the main performance issue ;) ) Yes they are few bytes but they are sent for *every* request. That includes every image, every css/js file.. When working on large scale you want to avoid any unnecessary headers, not so much because of a client but because of a server. Doesn't matter if you're talking server or client, it's still the same miniscule proportion of the total. Even for the server to receive it for every css/js file request, even if they *aren't* cached (and realistically they will be), it's still a mere drop in the bucket. Suppose if it were as much as 100 bytes, which would be fairly large for a cookie (mine total around 50 bytes or less when sent to the server), then even 1000 requests (considerably larger than a typical session, unless it's being overly-AJAXy, which would be a bigger performance drain for both server/client than cookies anyway) is *still* just 100kB which, for a modern server and that many requests, is nothing. It's still *completely* dwarfed by all the other crap in the client's headers alone, let alone the actual payload data being transferred back which, in most cases, will be considerably larger still.
Re: DIP60: @nogc attribute
On 20 April 2014 06:56, via Digitalmars-d digitalmars-d@puremagic.comwrote: I think it would be useful to be able to mark structs as @nogc_alloc or something similar. Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them. Why wouldn't precise GC be able to do this anyway? It already has data about everything it scans. It can easily produce a 'don't bother scanning this' bit at the start of that data without programmer assistance? Even with @nogc threads for audio/visual real time computations the GC itself will have to get down to consistent 50-200ms freezes to get fluid interaction for content computations. 50ms is 3 whole frames, 200ms is 12.5 frames! I thought you were a realtime programmer? In a visual realtime app, the GC will only be acceptable when it will not interrupt for more than 1ms or so (and I consider that quite generous, I'd be more comfortable with 500µs). Otherwise you'll lose frames anyway; if your entire world exists within 16ms slices, how can you budget the frame's usual workload around the GC interruption? And what if the GC interrupts more than once per frame? What if you have very little free memory?
Re: Missed optimisation case - internal use of STCin
On 19 April 2014 17:10, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 16:21, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 14:33, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:
On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
I'm currently testing out a GCC optimisation that allows you to set
call argument flags. The current assumptions being:
in parameters = Assume no escape, no clobber (read-only).
ref parameters, classes and pointers = Assume worst case.
default = Assume no escape.
That should read:
ref parameters, inout parameters, classes and pointers.
The default of assuming no escape is an experiment - I may limit this to
only scalar types, and parameters marked as 'scope' (So long as no one
plans on deprecating it soon :)
What does assume no escape actually mean?
[The above list doesn't really make sense. W/o context, it's
hard to even tell why, hence the question.]
Actually, I might change the default to assume worst case. I've just
tried this out, which is still valid.
class C {
int * p;
this(int x) {
p = x; // escapes the address of the parameter.
}
}
This might be currently accepted, but it is clearly invalid
(escapes local; the only way to make it work safely would
be to silently copy 'x' to the GC-managed heap, which would be
way too costly).
A f(A a) { g(a); return a; } // likewise with ref instead of pointer.
This is OK (even if ideally 'g' should be forbidden from escaping 'a').
Similarly:
A f(A a) {
auto o = register(a); // can modify 'a'
o.blah(); // ditto
doneWith(o); // ditto
return a;
}
What I was wondering was things like whether that assume no escape
property was transitive; if /locally/ escaping was disallowed, and
to what extent. What does assume no escape mean at all? In your
examples you're mentioning refs together with pointers, that would
only make sense if no-escape were transitive -- but then treating all
args as no-escape would be very wrong.
Worse, scope doesn't error on the general case either.
class D {
int * p;
this(scope int x) {
p = x; // escapes the address of the scope parameter.
}
}
D's scope isn't enforced in any way right now, which means
that code could exist that is invalid, but currently works. It
would break silently(!) when compiled with a decent compiler,
which still doesn't enforce scope.
People should get bug fixing soon then. =)
Until some kind of diagnostics appear, most of those bugs won't
even be found. It's too easy to write auto f (in A a) and then
forget about the implicit 'scope' when modifying the function body.
Do these examples give you a good example?
I'm worried about a) invalid assumptions making it into GDC;
b) certain valid assumptions making into GDC. The latter because
it could mean that code that's incorrect, but still accepted by
the other compilers could silently break when compiled with GDC.
Invalid assumptions rarely make it into GDC. The testsuite is a good
AFAICT what you're proposing *is* invalid. I can't be sure because
it's not clear what that no-escape property means; that's why I
asked about it twice already...
Clearly, escaping objects reachable indirectly via function arguments
is perfectly fine (eg string slicing), yet you wanted to treat args as
no-escape by default.
Not wanted - experimented. I could not think at the time a use case
where a parameter could escape. And *I* have shown a very valid use
case to *disprove myself*. I'm not sure of your continual persistence
of bringing this up as this is no longer relevant to me. Other than
possibly the silent breaking of 'scope' or 'in' parameters that are
misused (accepts invalid bugs).
bench for this, as well as several projects (now I've got dub set-up)
to test it in the wild.
These problems will result in invalid optimizations, so can be hard
to trigger and may come and go away randomly.
Saying that, we have had to revert some optimisation cases as D's
schizophrenic nature of enforcing attributes and behaviours is
becoming increasingly dismal.
eg:
- nothrow has *no* guarantee, period, because it still allows
unrecoverable errors being thrown, and allows people to catch said
unrecoverable errors.
- pure is a tough nut to crack also. The theory should allow you to
be able to cache return values, but in practise...
D's pure doesn't have much in common with the normal pure concept;
exposing gcc's pure via an attribute and completely ignoring D's
version is probably the only practical solution, anything else would
be too costly, result in too small gains, and be too hard to
Re: Knowledge of managed memory pointers
On Saturday, 19 April 2014 at 10:30:42 UTC, Jacob Carlborg wrote: On 2014-04-17 16:59, Steven Schveighoffer wrote: I don't think this is a viable mechanism to check pointers. It's too slow. Couldn't a single bit be used to indicate if it's a GC pointer or not? I think he's hoping more for the static type system to provide the information. I think it would be nifty if the fancy layered allocators that were being designed would return pointers with types describing the allocator itself. Could this sort of info be useful in shared libs?
Re: DIP60: @nogc attribute
On Sunday, 20 April 2014 at 00:59:26 UTC, Manu via Digitalmars-d wrote: Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them. Why wouldn't precise GC be able to do this anyway? It already has data about everything it scans. It can easily produce a 'don't bother scanning this' bit at the start of that data without programmer assistance? It doesn't know what can be reached through a node in a graph. It doesn't know what is on the GC heap. In a visual realtime app, the GC will only be acceptable when it will not interrupt for more than 1ms or so (and I consider that quite generous, I'd be more comfortable with 500µs). Otherwise you'll lose frames anyway; if No, because the @nogc thread will not be interrupted. Think MVC: the model is under GC, the view/controller is under @nogc.
Re: DIP60: @nogc attribute
On 20 April 2014 14:33, via Digitalmars-d digitalmars-d@puremagic.comwrote: On Sunday, 20 April 2014 at 00:59:26 UTC, Manu via Digitalmars-d wrote: Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them. Why wouldn't precise GC be able to do this anyway? It already has data about everything it scans. It can easily produce a 'don't bother scanning this' bit at the start of that data without programmer assistance? It doesn't know what can be reached through a node in a graph. It doesn't know what is on the GC heap. In a visual realtime app, the GC will only be acceptable when it will not interrupt for more than 1ms or so (and I consider that quite generous, I'd be more comfortable with 500µs). Otherwise you'll lose frames anyway; if No, because the @nogc thread will not be interrupted. Think MVC: the model is under GC, the view/controller is under @nogc. I don't really see why a proposed @nogc thread wouldn't hold references to GC allocated objects... what would such a thread do if it didn't have any data to work with? @nogc just says the thread won't allocate, it can still be holding all the references it likes, and still needs to be scanned.
Re: DIP60: @nogc attribute
On Sunday, 20 April 2014 at 05:21:48 UTC, Manu via Digitalmars-d wrote: I don't really see why a proposed @nogc thread wouldn't hold references to GC allocated objects... what would such a thread do if it didn't have any data to work with? Approach 1: Nogc thread can hold references to the gc heap that is known to be under bookkeeping or that is reachable from objects that are under book keeping. No need to scan the @nogc thread then. Approach 2: separate scan and freeing in the GC by pushing collected item onto a list of pending objects that are waiting for @nogc to complete an iteration before they are put on the freelist. This should work for standard culling. Ola.
Re: arrays in DMD V2
On 04/18/2014 08:47 PM, steven kladitis wrote: Thanks, I am trying to understand what I am doing. The docs seem unclear to me on how to initialize these. I think there are three ways. with brackets , the other with foreach or direct assignments. -- here is a longer version -- uncomment out the assignments to see the errors I get. -- I am trying to understand arrays. I like to differentiate between arrays and associative arrays. Although its name has array in it, an associative arrays is actually a hash table. First, let me repeat Jesse Phillips's suggestion: Do not use the C syntax. Here is the D syntax: T[N] means an array of N objects of type T. So, the following is an array of 2 ints: int[2] arr; When the size of the array is specified like that, it is a fixed-length array. There are dynamic arrays where the actual array is maintained and owned by the runtime. Such arrays are accessed by a slice. A slice is defined similar to a fixed-length array but the size is missing: int[] arr; An associative array (AA) is defined by the syntax ValueType[KeyType]. So, the following is an AA mapping strings to doubles: double[string] table; Here are three chapters on these topics: http://ddili.org/ders/d.en/arrays.html http://ddili.org/ders/d.en/slices.html http://ddili.org/ders/d.en/aa.html Ali
Re: arrays in DMD V2
On Saturday, 19 April 2014 at 03:51:02 UTC, steven kladitis wrote:
import std.stdio;
void main()
{
inta0[];
inta1[][];
string a2[][];
string a3[][string];
string a4[][string][string];
//string a4[string][string][string]; is this the same as
above
inta5[][string][string][string];
inta6[string][int][string][float];
inta7[int][int][string];
// how do you initialize each array, what type are they
multidimensional???
// how do you define all of the above with limits on each
dimension???
a0 = [1,2,3];
//writefln( a0 );
a1 = [ [ 1,2,3 ],[4,5,6]];
//writefln( a1 );
a2 = [ [a,b ],[ c,d ] ];
//writefln ( a2 );
//a3 = [ [a,b ],[ c,d ] ];
// does not work
//a4= [ [a,b ];
// does not work.
//a5 = [ [1,a,b]];
pragma(msg, typeof(a0));
pragma(msg, typeof(a1));
pragma(msg, typeof(a2));
pragma(msg, typeof(a3));
pragma(msg, typeof(a4));
pragma(msg, typeof(a5));
pragma(msg, typeof(a6));
pragma(msg, typeof(a7));
// does not work
Works for me.
a6 = int[float][string][int][string]
a7 = int[string][int][int]
//a6= [ 1,[a,1,b,4.0]];
// does not work
a6 = [a: [1: [b: [4.0: 5;
writeln(a6[a]);
//a7 = [ 1,1,a];
// does not work
a7 = [1: [2: [3: 4]]];
// also how would you do in a foreach?
foreach is for getting values out.
a0 ~= 7 // Append 7 to array
int[string] a8;
a8[hello] = 6; // Add six to a8 for hello
assert(a8[hello] == 6);
Get and set terminal size
I want use tgetnum for get terminal size http://www.mkssoftware.com/docs/man3/curs_termcap.3.asp extern(C): int tgetnum(const(char) *capname); calling a method from main writeln(tgetnum(toStringz(li))); I receive an error message Undefined symbols for architecture x86_64: _tgetnum, referenced from: _main in RSConsole.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Does anyone know what the problem is? Maybe there are other methods to get and set sizes of the Mac OS X console?
Re: Get and set terminal size
On Saturday, 19 April 2014 at 09:59:39 UTC, Adam D. Ruppe wrote: Try adding -lncurses or -lcurses to the command line. tgetnum is found in the curses library which isn't linked in automatically by default. Error: unrecognized switch '-lcurses' Error: unrecognized switch '-lncurses' :((
Re: *** GMX Spamverdacht *** Re: Reducing an array
Am 18.04.2014 22:27, schrieb Steven Schveighoffer via Digitalmars-d-learn: arr.sort(); arr = arr.uniq.array(); -Steve Thanks, also for the explanation! - Tim
Re: Get and set terminal size
Blargh, I don't know teh ldc switch for it :( Try adding pragma(lib, curses); (or ncurses) to your file with main in it, i think ldc supports that.
Re: Get and set terminal size
On Saturday, 19 April 2014 at 10:39:43 UTC, Adam D. Ruppe wrote: Blargh, I don't know teh ldc switch for it :( Try adding pragma(lib, curses); (or ncurses) to your file with main in it, i think ldc supports that. pragma(lib, curses); extern(C): int tgetnum(const(char) *capname); hmm segfault error :( Segmentation fault: 11
Re: Get and set terminal size
What are compiler and platform do you use? Probably you are trying to link with 64-bit library while being on 32-bit OS (or vice versa) It works fine on my 32-bit Debian with ldc2 and dmd.
