Unit-threaded v0.4.0 released
http://code.dlang.org/packages/unit-threaded . The @HiddenTest UDA now takes a compile-time string meant to be a bug id or other reason why the test is hidden. Unfortunately that means previous code using it needs to add a string or it'll fail to compile . The new @ShouldFail UDA also takes a compile-time string for the same reason. This fauses a test to fail unless it throws. Harder to sweep under the carpet than @HiddenTest . On the sweeping front, the number of hidden tests is now reported in yellow . Exceptions that aren't a descendant of unit_threaded.check.UnitTestException display a stack trace. This is for easier debugging in case an unexpected exception is thrown . The one bug I knew of was fixed Atila
Re: Z80 Emulation Engine
Its because its viral that a lot of people avoid it. On Tue, Apr 22, 2014 at 4:33 PM, ketmar via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: If something's open source with no commercial intent, is there good reason not to use gpl? How hard is it to change later? i don't see a reason not to use GPL even on commercial code. %-)
Unencumbered V0.1.2: Write Cucumber step definitions in D
Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in real life. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On 23/04/14 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in real life. This is awesome. I've been thinking several times about implementing something like this. Now I don't have to :) How do I set up the environment to use this? How complicated is it with the server and wire protocol? -- /Jacob Carlborg
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
Thanks. :)
The examples directory (which actually only contains one example)
shows what is the bare minimum needed. You need:
1. A file with the .wire extension with the host and port for
cucumber to connect to in features/step_definitions (just like
the example). Cucumber automatically finds this
2. An app D source file that tells the compiler which modules
to look for step definitions in at compile-time. These are passed
in as compile-time string parameters to
cucumber.server.runCucumberServer (look at examples/source/app.d)
3. Compile the server app with its dependencies by using dub or
the build system of choice
4. Run the server, run cucumber in another shell, marvel at the
results :P
The only thing that may be confusing in the example directory is
the fact that the modules that app.d references are themselves in
the `tests` directory. The reason being that I actually use them
for unit tests too and as we all know, duplication is bad.
I expect to run the acceptance / feature tests from a shell
script that compiles and runs the server, runs cucumber then
brings the server down. Now that I think of it it should be
possible to do that from Cucumber itself by using `After` and
`Before`. I had to do something like that whilst bootstrapping
the process and also for some tests I wrote for my MQTT broker. I
think this should work but I can't try it right now so don't
trust me:
Before do
@server = IO.popen(./your_server_name)
Timeout.timeout(1) do
while @socket.nil?
begin
@socket = TCPSocket.new('localhost', port)
rescue Errno::ECONNREFUSED
#keep trying until the server is up or we time out
end
end
end
end
After do
@socket.nil? or @socket.close
if not @server.nil?
Process.kill(INT, @server.pid)
Process.wait(@server.pid)
end
end
The reason it should work is that Cucumber supports mixing step
definitions in Ruby and over the wire. Which is awesome.
Atila
On Wednesday, 23 April 2014 at 14:58:26 UTC, Jacob Carlborg wrote:
On 23/04/14 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially like registering functions that take the
parameters with
the types they need from the regexp captures, as well as the
compile-time failures that come from that if done incorrectly.
Now I just need to use in real life.
This is awesome. I've been thinking several times about
implementing something like this. Now I don't have to :)
How do I set up the environment to use this? How complicated is
it with the server and wire protocol?
Re: DIP60: @nogc attribute
On 23/04/14 06:33, Walter Bright wrote: I repeatedly said that it is not memory safe because you must employ escapes from it to get performance. Apparently you need that for the GC as well, that's why this thread was started to begin with. -- /Jacob Carlborg
Re: DIP60: @nogc attribute
On 22/04/14 20:48, Steven Schveighoffer wrote: I mean not like I can't because I don't want to or don't have time, but can't as in I lack the skill set :) It's interesting to debate, and I get the concepts, but I am not a CPU/cache guy, and these things are really important to get right for performance, since ref counting would be used frequently. That's the worst kind of excuses :) I don't remember the last time I started working on a project and know what I was doing/had the right skill set. I mean, that's how you learn. -- /Jacob Carlborg
Re: CT info about class' children
On 22/04/14 22:50, Yuriy wrote: Any way to do it without patching druntime? Not that I know of. -- /Jacob Carlborg
Re: What's the status of old-style operator overloads in D2?
On 22/04/14 20:06, Brian Schott wrote: We have alias a = b; and alias b a;, so there's precedent for having two ways of doing exactly the same thing. I believe that for aliasing function pointers only the latter syntax works. -- /Jacob Carlborg
Re: CT info about class' children
Yuriy wrote in message news:duumbptvbqwknucxg...@forum.dlang.org... Any way to do it without patching druntime? Patch the compiler.
Re: Compile-time memory footprint of std.algorithm
23-Apr-2014 01:00, Iain Buclaw via Digitalmars-d пишет: On 22 April 2014 21:43, Peter Alexander via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 22 April 2014 at 18:09:12 UTC, Iain Buclaw wrote: Testing a 2.065 pre-release snapshot against GDC. I see that std.algorithm now surpasses 2.1GBs of memory consumption when compiling unittests. This is bringing my laptop down to its knees for a painful 2/3 minutes. My (ancient) laptop only has 2GB of RAM :-) Has anyone looked into why it is using so much? Is it all the temporary allocations created by CTFE that are never cleaned up? I blame Kenji and all the semanticTiargs and other template-related copying and discarding of memory around the place. :o) At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. -- Dmitry Olshansky
Re: Redesign of dlang.org
On 23/04/14 00:57, Nick Sabalausky wrote: Apparently they can't even manage make basic links work properly: http://getbootstrap.com/examples/starter-template/ How anyone can manage to fuck up a href=../a is beyond me. What's fucked up with the links? -- /Jacob Carlborg
Re: Compile-time memory footprint of std.algorithm
On 4/22/2014 11:33 PM, Dmitry Olshansky wrote: At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. I made a build of dmd with a collector in it. It destroyed the speed. Took it out.
Re: Redesign of dlang.org
http://getbootstrap.com/examples/starter-template/ How anyone can manage to fuck up a href=../a is beyond me. Nick what are you talking about? They referenced some anchors in their example page and that works.
Re: Redesign of dlang.org
Eww. Font size and image scaling should *not* be a function of window size. That's just...yuck. Let the system determine it's own appropriate base font size. And it's all in that horrible, ugly, giant sized, yet minimal content and maximal blank space style that's so inexplicably popular with the latest batches of web startups. *shudder* Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all about the content after all and if that is good the rest doesn't matter.
Re: Compile-time memory footprint of std.algorithm
23-Apr-2014 10:39, Walter Bright пишет: On 4/22/2014 11:33 PM, Dmitry Olshansky wrote: At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. I made a build of dmd with a collector in it. It destroyed the speed. Took it out. Getting more practical - any chance to use it selectively in CTFE and related stuff that is KNOWN to generate garbage? -- Dmitry Olshansky
Re: Redesign of dlang.org
I would use Foundation[1] instead of Bootstrap. [1] http://foundation.zurb.com/ Whatever gets the job done. I haven't yet worked with Foundation, but it looks reasonable. Maybe we can limit the SCSS dependency by checking in the rendered CSS, so only people working on the style would need a sass compiler. One remark though, try to stay away from heavy client-side JS, dlang.org is mostly a static website and anything that makes you wait 5s for the site to be rendered misses the point.
Re: Redesign of dlang.org
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. You could make a poll on the newsgroup or ask Andrei if Google Analytics has some numbers about the User Agents used to visit our site. My guess is that we can safely ignore IE8 for our target group.
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 06:39:04 UTC, Walter Bright wrote: I made a build of dmd with a collector in it. It destroyed the speed. Took it out. Is it because of garbage collections? Then allow people configure collection threshold, say, collect garbage only when the heap is bigger than 16GB.
Re: Redesign of dlang.org
On Saturday, 19 April 2014 at 10:56:07 UTC, 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. Yes it would. It could be done as an independent second step though. 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) We can easily find better fonts :).
Re: DIP60: @nogc attribute
On 22 April 2014 05:03, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/21/2014 10:57 AM, Steven Schveighoffer wrote: On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright newshou...@digitalmars.com wrote: On 4/21/2014 5:00 AM, Steven Schveighoffer wrote: Total replacement of GC with ARC in D will: This is the wrong straw-man, I'm not advocating for this at all. Many are when they advocate ARC for D. Does that preclude you from accepting any kind of ARC for D? No. My objection is to pervasive ARC, i.e. all gc is replaced with ARC, and it all magically works. It's not magic, it's careful engineering, and considering each problem case one by one as they arise until it's good. 5. Numerous posters here have posited that the overhead of ARC can be eliminated with a sufficiently smart compiler (which does not exist). You continue to speak in extremes. People are saying that the compiler can eliminate most of the needless ARC increments and decrements, not all of them. Manu, for example, suggests it is good enough to make the overhead insignificant. I'm skeptical. I didn't quite say that, but let me justify that claim if you want to put it in those words. RC fiddling in low-frequency code is insignificant. High-frequency code doesn't typically allocate, and is also likely to implement a context specific solution anyway if it is truly performance sensitive. In the event of code where RC fiddling is found to make a significant impact on performance, there are various tools available to address this directly. There's a middle-ground that might suffer compared to GC; moderate-frequency, where code is sloppily written doing whatever it likes without any real care, and run lots of iterations. But that's not usually an example of performance sensitive code, it's just crappy code run many times, and again, they have the tools to improve it easily if they care enough to do so. I also believe programmers will learn the performance characteristics of ARC very quickly, and work with it effectively. The core of my argument is that it's _possible_ to work with ARC, it's not possible to work with GC if it is fundamentally incompatible with your application. Compilers that do this do exist. I can't reconcile agreeing that ARC isn't good enough to be pervasive with compiler technology eliminates unnecessary ARC overhead. The most important elimination is objects being passed down a call-tree via args. That can certainly eliminate properly. High-frequency code always exists nearer to the leaves. D has pure (which is definitely well employed), and 'shared' is an explicit attribute, which allows the compiler to make way more assumptions than O-C. The ARC optimisations are predictable and reliable. The suggestion that acceptable code performance relying on specific optimisation is a concept you can't reconcile is a bit strange. Programmers rely on optimisation all the time for acceptable performance. This is no different.
Re: Compile-time memory footprint of std.algorithm
On 4/22/2014 11:56 PM, Dmitry Olshansky wrote: Getting more practical - any chance to use it selectively in CTFE and related stuff that is KNOWN to generate garbage? Using it there only will require a rewrite of interpret.c.
Re: Compile-time memory footprint of std.algorithm
On 4/23/2014 12:20 AM, Kagamin wrote: On Wednesday, 23 April 2014 at 06:39:04 UTC, Walter Bright wrote: I made a build of dmd with a collector in it. It destroyed the speed. Took it out. Is it because of garbage collections? Then allow people configure collection threshold, say, collect garbage only when the heap is bigger than 16GB. It's more than that. I invite you to read the article I wrote on DrDobbs a while back about changes to the allocator to improve speed. tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters.
Re: DIP60: @nogc attribute
Manu, you obviously believe in ARC. I've made an attempt to do ARC, detailed in the other thread here. I failed. http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com Michel Fortin also wants to bring iOS ARC to D. I suggest you get together with Michel and work out a detailed design, and propose it.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 07:02:50 UTC, Martin Nowak wrote: I would use Foundation[1] instead of Bootstrap. [1] http://foundation.zurb.com/ Whatever gets the job done. I haven't yet worked with Foundation, but it looks reasonable. Maybe we can limit the SCSS dependency by checking in the rendered CSS, so only people working on the style would need a sass compiler. One remark though, try to stay away from heavy client-side JS, dlang.org is mostly a static website and anything that makes you wait 5s for the site to be rendered misses the point. I was thinking of that too, but I used this approach on one of previous projects (both, SCSS and generated CSS files were under git) and it just gave me headache as the coworker was changing CSS and committing those changes which leaved SCSS and CSS files out of sync. But we could easily just agree not to do it, and state that we don't accept pull requests that have direct changes in CSS.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 07:28:51 UTC, Martin Nowak wrote: On Saturday, 19 April 2014 at 10:56:07 UTC, 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. Yes it would. It could be done as an independent second step though. Yep, that's how I plan to do it. First just to redesign the complete website then to add features like search suggestions. 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) We can easily find better fonts :). I'm not that unsatisfied with font faces (its Consolas nad Calibri), more with sizes/spacing/colors.. But this is something I will go over with a great graphics designer who will join me at the start of May, so it will surely be much better.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 07:16:53 UTC, Martin Nowak wrote: 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. You could make a poll on the newsgroup or ask Andrei if Google Analytics has some numbers about the User Agents used to visit our site. My guess is that we can safely ignore IE8 for our target group. I would support IE8 too, as that is the latest IE you can get on XP. I know that Microsoft has discontinued XP but there are still fare share of XP users out there.. But I will leave all that cross-browser tweaking for last stage..
Re: Compile-time memory footprint of std.algorithm
23-Apr-2014 12:12, Walter Bright пишет: On 4/23/2014 12:20 AM, Kagamin wrote: On Wednesday, 23 April 2014 at 06:39:04 UTC, Walter Bright wrote: I made a build of dmd with a collector in it. It destroyed the speed. Took it out. Is it because of garbage collections? Then allow people configure collection threshold, say, collect garbage only when the heap is bigger than 16GB. It's more than that. I invite you to read the article I wrote on DrDobbs a while back about changes to the allocator to improve speed. tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters. This stinks it's not even half-serious. A x2 speed increase was due to scraping the old allocator on Win32 altogether and using plain HeapAPI. If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong. -- Dmitry Olshansky
Re: DIP60: @nogc attribute
On 23 April 2014 04:28, Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tue, 22 Apr 2014 14:12:17 -0400, Walter Bright newshou...@digitalmars.com wrote: On 4/22/2014 6:18 AM, Steven Schveighoffer wrote: On Mon, 21 Apr 2014 19:02:53 -0400, Walter Bright newshou...@digitalmars.com wrote: The thing is, with iOS ARC, it cannot be statically guaranteed to be memory safe. So? If you see no value in static guarantees of memory safety, then what can I say? Seriously, the straw man arguments have to stop. There is plenty of valuable D code that is not guaranteed memory safe. For example, druntime. ARC does not equal guaranteed memory safety. So NO, it cannot replace the GC for D @safe code. That doesn't make it useless. Why not? Assuming that direct access to the refcount is not @safe, why would ARC be unsafe? What makes it less safe than the GC?
Re: DIP60: @nogc attribute
On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote: Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe. I'm not convinced that it is safe in multi-threaded mode. How does ARC deal with parallell reads and writes from two different threads? IIRC the most common implementations deals with read/read and write/write, but read/write is too costly?
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote: Trying to be clever? Obviously not. I don't understand the motivation of this quip. You don't understand that it is offensive to respond to an intelligent question by posting a Google query? As a project maintainer you should know better. If dlang.org is being used by a programmer for 2-3 hours daily, then it is his use scenario that matters. The ability to adapt is more important for a documentation site than for a news site. There are many good reasons to scale up to insane widths, basically to cut down the length of the rendered page to get an overview. To get less prose and more code on the page. Many of the dlang pages suffers from being too long, information sought is hidden. The user is always right… as the a designer you cannot tell the user he is wrong (well, you can, but that will only piss him off). So if Kagamin is comfortable with wide windows then that most certainly is the right thing for him. Anyway, you guys are taking this process in reverse. You should start with use cases, then the requirements, then content, then functionality, then marginal design, then figure out what you need in addition in terms of styling. The current documentation is not very user friendly, no amount of styling will fix that. Styling will only make it look like you have your priorities wrong. Put a dress on a pig and it will still be a pig, an odd one. (In the commercial sector you start with stylish mockups, but that is only a political move to get thumbs up, it is not a good idea since it can lock down expectations too early.) A redesign ought to: 1. cut down on the number of operations to find the information sought. 2. maximize vertical information flow to avoid exessive scrolling (that means get rid of the top bar on doc pages) I think you need to improve ddoc and get more semantics into the markup. Today's crop of browsers are tabbed, and for many users the position of the browser window is dictated by external constraints (relation to other windows, external monitor or not etc) and it's unreasonable to demand resizing the window whenever they swap tabs. I would image the primary usage scenario is to have dlang alongside your editor. (Doing a mobile-first design for dlang is something I don't get the point of.) Ola.
Re: Redesign of dlang.org
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote: https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+readingsafe=off The first link say 100 characters per line. If 100 characters equal to page width, then page width is the optimal line length.
Re: Ehem, ARM
On Friday, 21 March 2014 at 19:59:41 UTC, Joakim wrote: Been awhile since I updated on the Android effort: I'm now able to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions. It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared. I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android. As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly. Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue. I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too. Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd: http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185 I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me. If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up. If not, I'll have something together eventually. ;) Alright, finally hacked dmd to produce something like packed TLS for ELF. I just ran the druntime unit tests on Android/x86 and all 38 modules passed, :) even after changing the number of TLS variables a couple times, which was causing segfaults with the native TLS before. I'll try running the phobos unit tests next, then building a sample Android/x86 D app/apk, ie the kind you can actually install on Android.
Re: Ehem, ARM
On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote: I know, I know, this question has been asked many times before. But it came up in a meeting the other day: is there any work being done on making D an ARM citizen so that _non-trivial_ D code can be ported to smartphones and the like? If so, what it the rough time frame? I have few small/toy D apps running on my ODROID-U2 . They are compiled using latest GDC (4.8 branch). It all works fine. Yeah, phobos is 40+MiB big, but I have gibibytes free on emmc card! ;)
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 06:47:58 UTC, Martin Nowak wrote: Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all about the content after all and if that is good the rest doesn't matter. There's a middle ground here.
Re: DIP60: @nogc attribute
On 23/04/14 10:31, Walter Bright wrote: Manu, you obviously believe in ARC. I've made an attempt to do ARC, detailed in the other thread here. I failed. http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com That conversation started out from the D/Objective-C conversations. To have ARC in D and be compatible with the one in Objective-C you don't have many choices. I'm not sure but I don't think your proposal was not compatible with ARC in Objective-C. -- /Jacob Carlborg
Re: Redesign of dlang.org
On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote: Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need! Yea, I wrote this several years ago before even knowing about sass based on what annoyed me about CSS and it looks like me and the sass people had a lot of the same complaints because our results are almost compatible. I think sass does a better job with calculations but meh, I just use box-sizing: border-box and then I don't care as much about calculations anymore anyway! Ideally I would use @ as prefix, but that may interfere with CSS @-rules (I see you have CssAtRule class to handle those), so I'd use some character that's easier to type like $ (but that is used for parent selector in upcoming CSS 4)... Yeah, that's why I picked the weird symbol, I wanted something that wasn't going to be used anywhere else in normal CSS so it wouldn't conflict. (The implementation here is stupid simple: it just does indexOf this symbol and then replaces it. The denesting is a more complete css parser, but the macros replacement is plain text search.) Anyway, I updated the github to allow $ to be used.
Re: Ehem, ARM
On 23/04/14 13:39, Joakim wrote: Alright, finally hacked dmd to produce something like packed TLS for ELF. I just ran the druntime unit tests on Android/x86 and all 38 modules passed, :) even after changing the number of TLS variables a couple times, which was causing segfaults with the native TLS before. I'll try running the phobos unit tests next, then building a sample Android/x86 D app/apk, ie the kind you can actually install on Android. That's awesome :) -- /Jacob Carlborg
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole wrote: Any chance to get this separated out just for the css part of it? Hmm, you know, maybe that wouldn't be too hard. I thought it used dom.d's css parser but it actually doesn't! So I could probably write a little css module that doesn't depend on the others (except color.d). I might work on it tonight. And ugh can I change that weird symbol to '$'? Use std.array.replace to change it before passing to the macro system. There's just the problem then that $ is a fairly common symbol so it will conflict with some other stuff.
Re: DIP60: @nogc attribute
On 2014-04-23 09:50:57 +, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com said: On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote: Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe. I'm not convinced that it is safe in multi-threaded mode. How does ARC deal with parallell reads and writes from two different threads? IIRC the most common implementations deals with read/read and write/write, but read/write is too costly? The answer is that in the general case you should protect reads and writes to an ARC pointer with locks. Otherwise the counter risk being getting out of sync and later you'll get corruption somewhere. There are atomic properties which are safe to read and write from multiple threads. Internally they use the @synchronized keyword on the object. But since there's no 'shared' attribute in Objective-C, you can't go very far if you wanted the compiler to check things for memory safety. That said, if you assume a correct implementation of the NSCopying protocol (deep copying), objects following that protocol would be safe to pass through a std.concurrency-like interface. In all honesty, I'm not that impressed with the multithreading protections in D either. It seems you so often have to bypass the type system to make something useful that it doesn't appear very different from not having them. And don't get me started with synchronized classes... -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 13:22:02 UTC, Adam D. Ruppe wrote: On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole wrote: Any chance to get this separated out just for the css part of it? Hmm, you know, maybe that wouldn't be too hard. I thought it used dom.d's css parser but it actually doesn't! So I could probably write a little css module that doesn't depend on the others (except color.d). I might work on it tonight. Thanks! I will be looking forward to it on the dub repository. And ugh can I change that weird symbol to '$'? Use std.array.replace to change it before passing to the macro system. There's just the problem then that $ is a fairly common symbol so it will conflict with some other stuff. Okay, doesn't look too bad of a deal that.
Re: DIP60: @nogc attribute
On 2014-04-23 04:33:00 +, Walter Bright newshou...@digitalmars.com said: On 4/22/2014 12:42 PM, Michel Fortin wrote: On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said: Memory safety is not a strawman. It's a critical feature for a modern language, and will become ever more important. What you don't seem to get is that ARC, by itself, is memory-safe. I repeatedly said that it is not memory safe because you must employ escapes from it to get performance. It wasn't that clear to me you were saying that, but now it makes sense. In Objective-C, the performance-sensitive parts are going to be implemented in C, that's true. But that's rarely going to be more than 5% of your code, and probably only a few isolated parts where you're using preallocated memory blocks retained by ARC while you're playing with the content. If you're writing something that can't tolerate a GC pause, then it makes perfect sense to make this performance-critical code unsafe so you can write the remaining 95% of your app in a memory-safe environment with no GC pause. D on the other hand forces you to have those GC pauses or have no memory management at all. It's a different tradeoff and it isn't suitable everywhere, but I acknowledge it makes it easier to make performance-sensitive code @safe, something that'd be a shame to lose. Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid undefined behaviours inherited from C) everything is perfectly memory safe. Allow me to make it clear that IF you never convert an ARC reference to a raw pointer in userland, I agree that it is memory safe. But this is not practical for high performance code. Framing the problem this way makes it easier to find a solution. I wonder, would it be acceptable if ARC was used everywhere by default but could easily be disabled inside performance-sensitive code by allowing the user choose between safe GC-based memory management or unsafe manual memory management? I have an idea that'd permit just that. Perhaps I should write a DIP about it. I'm pretty confident that had I continued my work on D/Objective-C we'd now be able to interact with Objective-C objects using ARC in @safe code. I was planning for that. Objective-C actually isn't very far from memory safety now that it has ARC, it just lacks the @safe attribute to enable compiler verification. I wish you would continue that work! I wish I had the time too. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Discusssion on the Discussion of the Design for a new GC
So, in order to get the ball rolling on the new GC I intend to implement for D, I want to facilitate a lively discussion of the design of it, so that it can be designed to be both robust and free of design flaws. To keep the discussion from getting derailed, I want to lay out a few guidelines, but want to get feedback on those guidelines before I actually implement them. My current draft of them is as follows: First we’ll start with a brief overview of the development process: A PR will be created for DMD, DRuntime, and, although it may stay empty, Phobos. A new commit will be created for each update of the implementation, this includes bug fixes, and continuing work on the implementation, in as many iterations as are required. This is done to allow progressive review of the code rather than trying to review the PRs as a whole, because, as it is likely to include several thousand lines of changes to the code, it would be impractical to review all at once. No force push should ever be done to the PRs except to fix a typo in or clarify a detail of the commit message for the newest commit. If there is a typo in a commit message, or it is not very clear on what was actually done, and another commit has already been pushed, the typo or un-clear message shall remain for all eternity. The suggested remedy in this case is to make a note of the typo or clarify the commit message with a comment on the commit. PRs to the PRs are welcome, it is however encouraged to coordinate any work you do with the others actively working on the GC. The primary outlet for this should be the IRC, however, should the need arise, the mailing list is a valid venue for this. Github should be used as the primary outlet for discussion of actual code, due to the ease of referencing code, as well as the ability to tell if a comment is about a piece of code that was already changed. The mailing list should be used exclusively for discussion of the design. It should not be used for discussing snippets of code in the actual implementation. It can, and should be, used to discuss snippets of code that may demonstrate a flaw, weakness, or strength in the design. The IRC should be used for rapid-fire QA, or bringing someone up-to-date with the discussion and progression of the GC so far. Discussion about inconsistencies in the coding style of the implementation (whitespaces, newlines, etc.) should reside exclusively on the IRC, as they are things that a future reader of the discussions doesn’t really care about. If a discussion of the overall code style used in the implementation is required, a thread should be created on the mailing list. The IRC should not be used to facilitate a design discussion. The reason for this is twofold, firstly the IRC has a limited audience, thus limited feedback, and secondly, I want the discussion of the design to stand as documentation for why the GC is designed the way it is. Now, on to the guidelines for the design discussion. ARC does not exist. We are implementing a GC, however, if the opportunity arises to allow an efficient implementation of interfacing with an external ARC platform, such as what is used in Objective C, discussion of that interfacing mechanism is permitted. If DMD support is needed, it exists. This means that if the GC needs DMD to be capable of something such as scope analysis in order to make a particular optimization, then DMD should be assumed to be capable of doing that. While language additions may be proposed, the design must still be able to function should the additions not be done, as the additions should only be to allow for additional optimization opportunities. For instance, re-introducing scoped class locals. After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results?
Re: CT info about class' children
On Wed, 23 Apr 2014 02:34:52 -0400, Daniel Murphy yebbliesnos...@gmail.com wrote: Yuriy wrote in message news:duumbptvbqwknucxg...@forum.dlang.org... Any way to do it without patching druntime? Patch the compiler. Did you type that with a straight face? -Steve
Re: What's the status of old-style operator overloads in D2?
On Tue, 22 Apr 2014 18:54:41 -0400, Meta jared...@gmail.com wrote:
On Tuesday, 22 April 2014 at 21:35:31 UTC, Meta wrote:
Does this work if test is in a different module from main?
struct test
{
private int opBinary(string op: *)(test other) { return 3; }
public alias opMul = opBinary!*;
}
void main()
{
test t1 = test();
test t2 = test();
auto n = t1 * t2;
assert(n == 3);
}
And it appears it does.
This changes the dynamics. opMul is not a template, which is important for
classes.
This also works, and if encapsulated into a mixin, will be a drop-in fix
for existing opMul and friends code:
struct test
{
alias opBinary(string op: *) = blah; // to demonstrate it's not
actually calling opMul because of old-style operators
int blah(test other) {return 3;}
}
BTW, I don't know when template alias got so cool, but I like it :)
-Steve
Run Doc Examples
What is stopping us from making all the code in the docs runnable like the code on the front page? http://dlang.org/ vs http://dlang.org/phobos/std_algorithm.html Import, setup and output code can be hidden until the user selects the code box.
Re: Compile-time memory footprint of std.algorithm
On Wed, 23 Apr 2014 02:39:05 -0400, Walter Bright newshou...@digitalmars.com wrote: On 4/22/2014 11:33 PM, Dmitry Olshansky wrote: At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. I made a build of dmd with a collector in it. It destroyed the speed. Took it out. The time it takes to compile a program where the compiler consumes 2G of ram on a 2G machine is infinite ;) There must be some compromise between slow-but-perfect memory management and invoking the OOM killer. -Steve
Re: CT info about class' children
Steven Schveighoffer wrote in message news:op.xerz7jcceav7ka@stevens-macbook-pro-2.local... Did you type that with a straight face? :)
Re: DIP60: @nogc attribute
On Wed, 23 Apr 2014 05:14:44 -0400, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 23 April 2014 04:28, Steven Schveighoffer via Digitalmars-d ARC does not equal guaranteed memory safety. So NO, it cannot replace the GC for D @safe code. That doesn't make it useless. Why not? Assuming that direct access to the refcount is not @safe, why would ARC be unsafe? What makes it less safe than the GC? Arguably, it is safe, as long as you only use ARC pointers. I don't know that I would ever want or use that in D (or even Objective-C). So it's not that it's not safe, it's that it cannot be a drop-in-replacement for the GC in existing D @safe code. For example, you could never use slices or ranges, or these would have to be rewritten to keep references to the full object. -Steve
Re: DIP60: @nogc attribute
On Wed, 23 Apr 2014 02:11:38 -0400, Jacob Carlborg d...@me.com wrote: On 22/04/14 20:48, Steven Schveighoffer wrote: I mean not like I can't because I don't want to or don't have time, but can't as in I lack the skill set :) It's interesting to debate, and I get the concepts, but I am not a CPU/cache guy, and these things are really important to get right for performance, since ref counting would be used frequently. That's the worst kind of excuses :) I don't remember the last time I started working on a project and know what I was doing/had the right skill set. I mean, that's how you learn. Sure, but there are things I CAN do with my limited time, that I do have the expertise for. I've already been schooled by the likes of you and Michel Fortin on my knowledge of ref counting implementation. BTW, this is how RedBlackTree (dcollections) came into existence, I had no idea what I was doing, just the API that I wanted (and back then, I had more time). The code is actually a slightly-hand-optimized copy of my CLR book's red-black algorithm. -Steve
Re: Redesign of dlang.org
On Tuesday, 22 April 2014 at 21:21:13 UTC, Aleksandar Ruzicic wrote: On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote: On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote: On 21/04/14 23:33, Dicebot wrote: I think it is very important to dogfood here and add any currently missing dependencies as dub packages instead. Unless we can use libsass, I would say it's not very productive to implement a new Sass compiler, just to avoid a dependency. I think using libsass is superior to using node/npm based dependency. Using pretty much anything from node.js infrastructure will be a big marketing hit for vibe.d (being its direct competitor in D world). I see what you mean. I get that it wouldn't be good marketing so I decided not to use npm. Although I would really like if we could do dub install -g package to distribute tools, like you can with npm.. You can do `dub fetch package; dub run package` AFAIR for packages that are applications. Though it does not make any sense to add something that is not a D project to dub, such a popular thing as sass compiler must have own package, whatever distro dlang web server runs on.
Re: CT info about class' children
Ok, i've added a pull request to be discussed. It expands RTInfo capability as Jacob suggested. What do you think? https://github.com/D-Programming-Language/druntime/pull/775
Re: What's the status of old-style operator overloads in D2?
Jacob Carlborg: I believe that for aliasing function pointers only the latter syntax works. It's a bug that needs to be fixed before the deprecation of old style alias syntax... Bye, bearophile
Re: Redesign of dlang.org
On 4/23/14, 4:30 AM, Kagamin wrote: On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote: https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+readingsafe=off The first link say 100 characters per line. If 100 characters equal to page width, then page width is the optimal line length. Maybe Google personalized my search, but the first hit is http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed pointing to a study indicating 95 characters per line as optimal for on-screen reading comprehension. The subjective preferences, however, was biased toward smaller numbers. The second link is http://baymard.com/blog/line-length-readability which points to a few studies concluding that 50-75 cpl (characters per line) would be indicated for web design. Third is http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-of-text-on-a-webpage which quotes a really nice collection of numbers from Smashing Magazine from popular websites, showing that 84% of the sites they looked at use 65-104 cpl. It just struck me that Google's own search page that I'm looking at right now, which I vaguely recall did not limit line lengths a few years ago, is now using a 90 cpl limit. The page's right-hand side is a white area. Next is http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, which mentions 66 cpl as optimal from a physiological standpoint. Next is http://socialtriggers.com/perfect-content-width/ which nicely advocates smaller cpl at the top of the content (so people read the essential message quickly) followed by 100 cpl. And so on and so forth. So I'd dlang.org to foster a behavior depending on the available real estate, as follows: * Cap cpl at e.g. 110 on very large screens. * As the available width decreases, reduce cpl up to 60. * If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 80 cpl. * As the available width reduces further, allow reduction down to e.g. 35 cpl, and then require horizontal scrolling. Andrei
Re: Redesign of dlang.org
On 4/23/14, 3:13 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote: Trying to be clever? Obviously not. I don't understand the motivation of this quip. You don't understand that it is offensive to respond to an intelligent question by posting a Google query? As a project maintainer you should know better. As a project maintainer I try to foster good exchange of information. I found the link informative. -- Andrei
Re: DIP60: @nogc attribute
On 2014-04-23 17:57, Steven Schveighoffer wrote: Sure, but there are things I CAN do with my limited time, that I do have the expertise for. I've already been schooled by the likes of you and Michel Fortin on my knowledge of ref counting implementation. That's completely different. I've felt the same for a long time. Instead of working on the compiler I built tools and libraries for D. Then I finally couldn't keep my hands off and now I have D/Objective-C working for 64bit :) -- /Jacob Carlborg
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote: ... first hit is http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-reading-digital-vs-printed pointing to a study indicating 95 characters per line as optimal for on-screen reading comprehension. The subjective preferences, however, was biased toward smaller numbers. The second link is http://baymard.com/blog/line-length-readability which points to a few studies concluding that 50-75 cpl (characters per line) would be indicated for web design. Third is http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-of-text-on-a-webpage which quotes a really nice collection of numbers from Smashing Magazine from popular websites, showing that 84% of the sites they looked at use 65-104 cpl. It just struck me that Google's own search page that I'm looking at right now, which I vaguely recall did not limit line lengths a few years ago, is now using a 90 cpl limit. The page's right-hand side is a white area. Next is http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, which mentions 66 cpl as optimal from a physiological standpoint. Next is http://socialtriggers.com/perfect-content-width/ which nicely advocates smaller cpl at the top of the content (so people read the essential message quickly) followed by 100 cpl. Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they?
Re: Discusssion on the Discussion of the Design for a new GC
On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote: So, in order to get the ball rolling on the new GC I intend to implement for D, I want to facilitate a lively discussion of the design of it, so that it can be designed to be both robust and free of design flaws. To keep the discussion from getting derailed, I want to lay out a few guidelines, but want to get feedback on those guidelines before I actually implement them. My current draft of them is as follows: First we’ll start with a brief overview of the development process: A PR will be created for DMD, DRuntime, and, although it may stay empty, Phobos. A new commit will be created for each update of the implementation, this includes bug fixes, and continuing work on the implementation, in as many iterations as are required. This is done to allow progressive review of the code rather than trying to review the PRs as a whole, because, as it is likely to include several thousand lines of changes to the code, it would be impractical to review all at once. No force push should ever be done to the PRs except to fix a typo in or clarify a detail of the commit message for the newest commit. If there is a typo in a commit message, or it is not very clear on what was actually done, and another commit has already been pushed, the typo or un-clear message shall remain for all eternity. The suggested remedy in this case is to make a note of the typo or clarify the commit message with a comment on the commit. PRs to the PRs are welcome, it is however encouraged to coordinate any work you do with the others actively working on the GC. The primary outlet for this should be the IRC, however, should the need arise, the mailing list is a valid venue for this. Github should be used as the primary outlet for discussion of actual code, due to the ease of referencing code, as well as the ability to tell if a comment is about a piece of code that was already changed. The mailing list should be used exclusively for discussion of the design. It should not be used for discussing snippets of code in the actual implementation. It can, and should be, used to discuss snippets of code that may demonstrate a flaw, weakness, or strength in the design. The IRC should be used for rapid-fire QA, or bringing someone up-to-date with the discussion and progression of the GC so far. Discussion about inconsistencies in the coding style of the implementation (whitespaces, newlines, etc.) should reside exclusively on the IRC, as they are things that a future reader of the discussions doesn’t really care about. If a discussion of the overall code style used in the implementation is required, a thread should be created on the mailing list. The IRC should not be used to facilitate a design discussion. The reason for this is twofold, firstly the IRC has a limited audience, thus limited feedback, and secondly, I want the discussion of the design to stand as documentation for why the GC is designed the way it is. Now, on to the guidelines for the design discussion. ARC does not exist. We are implementing a GC, however, if the opportunity arises to allow an efficient implementation of interfacing with an external ARC platform, such as what is used in Objective C, discussion of that interfacing mechanism is permitted. If DMD support is needed, it exists. This means that if the GC needs DMD to be capable of something such as scope analysis in order to make a particular optimization, then DMD should be assumed to be capable of doing that. While language additions may be proposed, the design must still be able to function should the additions not be done, as the additions should only be to allow for additional optimization opportunities. For instance, re-introducing scoped class locals. After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results? Wow, this takes the D forums tradition of all talk, no code, or as the original saying goes, all hat, no cattle, to a new peak. ;) I think most would agree with you on most of these guidelines, better to get onto the actual design. It might help if you put forth a tentative proposal, that the D goons can then proceed to destroy... I mean, critically evaluate.
Re: Compile-time memory footprint of std.algorithm
Dmitry Olshansky wrote in message news:lj7mrr$1p5s$1...@digitalmars.com... At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. Or you know, switch to D and use druntime's GC.
Re: Redesign of dlang.org
On Wed, Apr 23, 2014 at 04:28:30PM +, Dicebot via Digitalmars-d wrote: [...] Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). On the contrary, I find almost all websites have broken layouts because I enforce a minimal font size of 16pt (I have a high-resolution screen) -- they insist on font sizes that are far too small. Usually makes me override the site's style with my own custom-made one (or just move on to the next site). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they? They provide sizes per font measurements, which is good enough for implementing CPLs, no? T -- Time flies like an arrow. Fruit flies like a banana.
Re: Redesign of dlang.org
On 4/23/14, 9:28 AM, Dicebot wrote: Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they? I don't know. It's a good question and an interesting challenge. -- Andrei
Re: DIP60: @nogc attribute
On 4/23/2014 6:10 AM, Jacob Carlborg wrote: That conversation started out from the D/Objective-C conversations. To have ARC in D and be compatible with the one in Objective-C you don't have many choices. I'm not sure but I don't think your proposal was not compatible with ARC in Objective-C. Too many double negatives for me to be sure what you're saying. But it is clear to me that with Michel's experience with ARC in iOS combined with Manu's enthusiasm for it suggests that they are the right team to come up with a workable proposal, where mine failed.
Re: Compile-time memory footprint of std.algorithm
On 4/23/2014 2:00 AM, Dmitry Olshansky wrote: If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong. I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so. The thing is, I work all day every day on D. I cannot do more. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in.
Re: Compile-time memory footprint of std.algorithm
23-Apr-2014 20:56, Daniel Murphy пишет: Dmitry Olshansky wrote in message news:lj7mrr$1p5s$1...@digitalmars.com... At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. Or you know, switch to D and use druntime's GC. Good point. Can't wait to see D-only codebase. -- Dmitry Olshansky
Re: Compile-time memory footprint of std.algorithm
On 4/23/14, 1:56 PM, Daniel Murphy wrote: Dmitry Olshansky wrote in message news:lj7mrr$1p5s$1...@digitalmars.com... At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. Or you know, switch to D and use druntime's GC. But that will be slow. Walter's point is that if you introduce a GC it will be slower. Of course, you won't be able to compile big stuff. But developers usually have good machines, so it's not that a big deal.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 16:28:32 UTC, Dicebot wrote: *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they? Javascript libraries fill this gap: http://simplefocus.com/flowtype/
Re: Compile-time memory footprint of std.algorithm
23-Apr-2014 21:16, Walter Bright пишет: On 4/23/2014 2:00 AM, Dmitry Olshansky wrote: If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong. I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so. I'll give it a spin then. The thing is, I work all day every day on D. I cannot do more. That is understood, thanks for honesty. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in. True. -- Dmitry Olshansky
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 17:16:40 UTC, Walter Bright wrote: On 4/23/2014 2:00 AM, Dmitry Olshansky wrote: If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong. I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so. The thing is, I work all day every day on D. I cannot do more. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in. Well said Walter!
Re: Redesign of dlang.org
On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote: On the contrary, I find almost all websites have broken layouts because I enforce a minimal font size of 16pt (I have a high-resolution screen) -- they insist on font sizes that are far too small. This is why teams need some old codgers like me around. We don't see so good anymore, and need larger fonts. The teeny-tiny fonts all come from people under 25 :-) Ironically, the most unreadable web pages I've seen were on apple.com. Haven't looked at it recently, but they'd use a tiny font, and make it light gray letters on a white background. It was literally painful to try and read it. The current winnah for unreadable text goes to meld Ubuntu 13.10. For some wretched reason, 'meld' under the new Ubuntu uses a font where the letters are about one pixel wide meaning it's nearly impossible to even see the colored text. Some day I'm going to pull a tape measure between my eyes and my monitor, and get some glasses optimized for that distance.
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 15:46:00 UTC, Steven Schveighoffer wrote: The time it takes to compile a program where the compiler consumes 2G of ram on a 2G machine is infinite ;) (nitpick: not necessarily given good swap behaviour!)
Re: Discusssion on the Discussion of the Design for a new GC
On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote: After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results? What is the state of Rainer Schütze's precise gc? Duplication of effort and all that.
Get-together on Friday
Hello, Sean and I are meeting in Menlo Park, CA for breakfast on Friday morning at 9:15 AM PST. If you are in the area, are a regular of this group, and would like to get together with us please email me. Thanks, Andrei
Re: Compile-time memory footprint of std.algorithm
tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters. What about packing DMD structure members such as integers and enums more efficiently? We could start with making enums __attribute__((packed)). Is there any free static/dynamic tool to check for unexercized bits? How does Clang do to save so much space compared to GCC? Do they pack gentlier or use deallocation? A much higher-hanging fruit is to switch from using pointers to 32-bit handles on 64-bit CPUs to reference tokens, sub-expressions etc. But I guess that is a big undertaking getting type-safe and may give performance hits.
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 19:54:29 UTC, Nordlöw wrote: tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters. What about packing DMD structure members such as integers and enums more efficiently? We could start with making enums __attribute__((packed)). Is there any free static/dynamic tool to check for unexercized bits? How does Clang do to save so much space compared to GCC? Do they pack gentlier or use deallocation? A much higher-hanging fruit is to switch from using pointers to 32-bit handles on 64-bit CPUs to reference tokens, sub-expressions etc. But I guess that is a big undertaking getting type-safe and may give performance hits. Maybe we should investigate where the memory is going first before planning our attack :-)
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote: So I'd dlang.org to foster a behavior depending on the available real estate, as follows: * Cap cpl at e.g. 110 on very large screens. * As the available width decreases, reduce cpl up to 60. * If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 80 cpl. * As the available width reduces further, allow reduction down to e.g. 35 cpl, and then require horizontal scrolling. At some point you'll probably realize that the term cpl is not particularly meaningful in this context because: 1. you don't use a monofont and have to figure out what cpl is in em or rem. 2. adults detect phrases, not characters, so any measurements are done on the wrong unit anyway. 3. quantitative human factors studies that go beyond your inate capabilites tend to be full of severe methodological flaws. Waste of time.
Re: Compile-time memory footprint of std.algorithm
Maybe we should investigate where the memory is going first before planning our attack :-) I agree. Tool anyone?
Re: Compile-time memory footprint of std.algorithm
I agree. Tool anyone? https://stackoverflow.com/questions/23255043/finding-unexercised-bits-of-allocated-data Massif may give some clues.
Re: Compile-time memory footprint of std.algorithm
On 23 April 2014 21:55, Nordlöw digitalmars-d@puremagic.com wrote: Maybe we should investigate where the memory is going first before planning our attack :-) I agree. Tool anyone? I'm using valgrind - may take a while to process and merge them all. I'll post an update in the morning.
Re: Redesign of dlang.org
On 4/23/2014 2:12 PM, Walter Bright wrote: On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote: On the contrary, I find almost all websites have broken layouts because I enforce a minimal font size of 16pt (I have a high-resolution screen) -- they insist on font sizes that are far too small. This is why teams need some old codgers like me around. We don't see so good anymore, and need larger fonts. The teeny-tiny fonts all come from people under 25 :-) I certainly won't disagree that small fonts can be hard to read, but on the other end, I've seen a lot of newer websites with gigantic fonts, and I find that painful to read as well. Ironically, the most unreadable web pages I've seen were on apple.com. Haven't looked at it recently, but they'd use a tiny font, and make it light gray letters on a white background. It was literally painful to try and read it. Grey-on-white is ridiculously common and should be jailable offense. I'll never understand the the reasoning behind that readability destroyer.
Re: Redesign of dlang.org
On 4/23/2014 2:47 AM, Martin Nowak wrote: Eww. Font size and image scaling should *not* be a function of window size. That's just...yuck. Let the system determine it's own appropriate base font size. And it's all in that horrible, ugly, giant sized, yet minimal content and maximal blank space style that's so inexplicably popular with the latest batches of web startups. *shudder* Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all about the content after all and if that is good the rest doesn't matter. I didn't say style was irrelevent. I only said that there should actually *be* content.
Re: Redesign of dlang.org
On 4/23/2014 9:11 AM, Adam D. Ruppe wrote: On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote: Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need! Yea, I wrote this several years ago before even knowing about sass based on what annoyed me about CSS and it looks like me and the sass people had a lot of the same complaints because our results are almost compatible. I think sass does a better job with calculations but meh, I just use box-sizing: border-box and then I don't care as much about calculations anymore anyway! box-sizing: border-box is proof of what I've said all along: Microsoft got the box model right in old IEs, and W3C got it wrong.
Re: Redesign of dlang.org
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote: I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does. This is awesome. I think I might try it out for my next web-dev contract. If it could be put on code.dlang.org that would be awesome. I've always been tempted to use Sass or similar, but this seems like the simple tool I've actually wanted.
Re: Redesign of dlang.org
On 4/23/2014 2:34 AM, Jacob Carlborg wrote: On 23/04/14 00:57, Nick Sabalausky wrote: Apparently they can't even manage make basic links work properly: http://getbootstrap.com/examples/starter-template/ How anyone can manage to fuck up a href=../a is beyond me. What's fucked up with the links? They don't work. But...maybe they're only intended to be single-page-only examples? (Now that I think about it...) If so, then I must have misunderstood the examples. The fact that they're all pointing to different anchor links threw me off and made me assume they were supposed to be functional. (I'm accustomed to blank zero-length anchors being used to indicate intentionally non-functional placeholder link.) But I have noticed a lot of the sites that use anchor links to switch to completely different pages are basically broken. Since the very *beginning* of HTML, links have always been downright trivial to implement, and have always been considerably *easier* to *not* require JS. It's pretty much the single simplest, easiest, most fundamental thing in HTML. And yet, more than a decade now after a onclick=... linking inexplicably appeared, some people are *still* trying to implement links using JS. It's insane. However, you'll have to pardon that little rant. When I posted that Apparently they can't even manage make basic links work properly, I swear it wasn't my intention to do another JS-rant. Coming from me, JS rants are pretty much redundant at this point ;)
Re: Redesign of dlang.org
On 4/23/2014 5:55 PM, John Colvin wrote: On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote: I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does. This is awesome. I think I might try it out for my next web-dev contract. If it could be put on code.dlang.org that would be awesome. I've always been tempted to use Sass or similar, but this seems like the simple tool I've actually wanted. SCSS has always been more interesting to me than SASS, but yea, this seems to pretty much be an independently-developed equivalent to SCSS, which is pretty cool.
Re: Redesign of dlang.org
On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d wrote: On 4/23/2014 2:12 PM, Walter Bright wrote: On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote: On the contrary, I find almost all websites have broken layouts because I enforce a minimal font size of 16pt (I have a high-resolution screen) -- they insist on font sizes that are far too small. This is why teams need some old codgers like me around. We don't see so good anymore, and need larger fonts. The teeny-tiny fonts all come from people under 25 :-) I can still see relatively well, but I prefer not having to squint at the screen to read text on a webpage just because some clever web designer decided that 6pt fonts are a good idea. That's why I configured my browser to enforce a minimum font size of 14 pt (or was it 16pt?), regardless of what the stylesheet says. It's the only way I could even tolerate reading certain sites. I certainly won't disagree that small fonts can be hard to read, but on the other end, I've seen a lot of newer websites with gigantic fonts, and I find that painful to read as well. Any examples? Usually when I run into a site with (1) microscopic fonts, (2) giant (often multicolored) fonts, (3) no whitespace, or (4) has more ads/filler than content, my fingers have an almost instinctual ctrl-W (close tab) response. Sometimes not even one word registers in my brain before I move on to the next site. In fact, I'm of the arrogant opinion that websites should not specify ANY font size except a relative size to the browser's default, because chances are, whatever size you choose will look horrible on *somebody*'s device. Browsers come with a default (and user-configurable!) font size for a reason. Web designers would be foolish to disregard that. Ironically, the most unreadable web pages I've seen were on apple.com. Haven't looked at it recently, but they'd use a tiny font, and make it light gray letters on a white background. It was literally painful to try and read it. Grey-on-white is ridiculously common and should be jailable offense. I'll never understand the the reasoning behind that readability destroyer. Worse yet, I've actually seen sites that use red on gray (or the other way round -- it's too painful to recall). Or lime on turqoise. Or any of various other horrible combinations. Aughh... my eyes hurt just thinking about it... On the bright side, most sites that pick such colors usually don't have any useful content to offer either, so the ctrl-W kneejerk (fingerjerk?) fixes the problem quite quickly. T -- No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. -- Simon St. Laurent on xml-dev
Re: CT info about class' children
On Wednesday, 23 April 2014 at 16:06:58 UTC, Yuriy wrote: Ok, i've added a pull request to be discussed. It expands RTInfo capability as Jacob suggested. What do you think? https://github.com/D-Programming-Language/druntime/pull/775 Looks fairly interesting, because it partly solves the issue to allow custom rtinfo.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 16:13:42 UTC, Andrei Alexandrescu wrote: On 4/23/14, 3:13 AM, Ola Fosheim Grøstad You don't understand that it is offensive to respond to an intelligent question by posting a Google query? As a project maintainer you should know better. As a project maintainer I try to foster good exchange of information. I found the link informative. -- Andrei In most contexts that will be taken as a RTFM response, as in: «why didn't you search for this yourself?»
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 22:12:08 UTC, Nick Sabalausky wrote: SCSS has always been more interesting to me than SASS, but yea, this seems to pretty much be an independently-developed equivalent to SCSS, which is pretty cool. The funny thing is I wrote this thing a few years ago, 2011 I think, and I've been using it on several sites too. It's just been hidden from the general public in my misc. github :P There's also a javascript macro expander which adds foreach to that language via text macro hidden away in that html.d as well...
Re: Redesign of dlang.org
On Wed, Apr 23, 2014 at 06:08:52PM -0400, Nick Sabalausky via Digitalmars-d wrote: [...] But I have noticed a lot of the sites that use anchor links to switch to completely different pages are basically broken. Since the very *beginning* of HTML, links have always been downright trivial to implement, and have always been considerably *easier* to *not* require JS. It's pretty much the single simplest, easiest, most fundamental thing in HTML. And yet, more than a decade now after a onclick=... linking inexplicably appeared, some people are *still* trying to implement links using JS. It's insane. [...] I'm still amazed at the number of news sites that have non-functional links the moment you disable JS. I had been running my browser with JS turned on by default for many years, until sometime in the last few years I got so sick of JS eating up CPU, memory, causing needless browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm back to JS being off by default, and only (grudgingly) enabled for a handful of specific sites that actually *need* it. It's amazing how much faster the web suddenly became, overnight. And it's equally amazing how many links stop working without JS. It boggles the mind... doesn't HTML have a built-in link tag for that very purpose?! Another new fad nowadays seems to be CSS popups that need JS to make them go away. My usual reaction to that is to close the tab and move on. Or, if I'm feeling particularly tolerant that day, switch to user stylesheet mode (i.e., completely disregard the site's CSS and use my own), and just scour the raw text for the real content (which usually occupies, oh, 20% of the total text on the page -- apparently nowadays minimizing your S/N ratio is in, providing useful content is out). Doesn't fix the JS link issue, though, but so far, I've decided that it's not worth the bother to find out what's behind such non-working links -- esp. since Google will readily give me pages upon pages of other places where I can get similar information! :-) However, you'll have to pardon that little rant. When I posted that Apparently they can't even manage make basic links work properly, I swear it wasn't my intention to do another JS-rant. Coming from me, JS rants are pretty much redundant at this point ;) JS rants are fun. ;-) T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Re: Redesign of dlang.org
Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all about the content after all and if that is good the rest doesn't matter. I didn't say style was irrelevent. I only said that there should actually *be* content. Sorry for the irony :), indeed fluffy sites without content are useless. Reminds me of http://vimeo.com/89527215.
Re: Redesign of dlang.org
Maybe we can limit the SCSS dependency by checking in the rendered CSS, so only people working on the style would need a sass compiler. I was thinking of that too, but I used this approach on one of previous projects (both, SCSS and generated CSS files were under git) and it just gave me headache as the coworker was changing CSS and committing those changes which leaved SCSS and CSS files out of sync. Obviously not the way to do it. But we could easily just agree not to do it, and state that we don't accept pull requests that have direct changes in CSS. I think this will work out nice, css doesn't change very often.
Re: Redesign of dlang.org
On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote: If it could be put on code.dlang.org that would be awesome. http://code.dlang.org/packages/cssexpand
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 20:04:09 UTC, Peter Alexander wrote: Maybe we should investigate where the memory is going first before planning our attack :-) FWIW one hint might be found in the DCD project found here: https://github.com/Hackerpilot/DCD/ In that project compiling the lexer.d file causes a massive increase in compiler memory usage. More details found here: https://github.com/Hackerpilot/DCD/issues/93 NOTE: That was DMD running on a 32 bit Windows XP machine.
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 23:19:20 UTC, Jussi Jumppanen wrote: In that project compiling the lexer.d file causes a massive increase in compiler memory usage. The code is actually located here: https://github.com/Hackerpilot/Dscanner If you want to make DMD cry, compile it with -O -inline -release.
Re: Redesign of dlang.org
On 4/23/14, 1:53 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote: So I'd dlang.org to foster a behavior depending on the available real estate, as follows: * Cap cpl at e.g. 110 on very large screens. * As the available width decreases, reduce cpl up to 60. * If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 80 cpl. * As the available width reduces further, allow reduction down to e.g. 35 cpl, and then require horizontal scrolling. At some point you'll probably realize that the term cpl is not particularly meaningful in this context because: 1. you don't use a monofont and have to figure out what cpl is in em or rem. I'm talking averages. 2. adults detect phrases, not characters, so any measurements are done on the wrong unit anyway. For a given language (English in our case), the relationship translates into average words per line. 3. quantitative human factors studies that go beyond your inate capabilites tend to be full of severe methodological flaws. Uhm... Waste of time. I doubt it. Andrei
Re: Compile-time memory footprint of std.algorithm
Am Wed, 23 Apr 2014 21:23:17 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: 23-Apr-2014 20:56, Daniel Murphy пишет: Dmitry Olshansky wrote in message news:lj7mrr$1p5s$1...@digitalmars.com... At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much. Or you know, switch to D and use druntime's GC. Good point. Can't wait to see D-only codebase. Hmm. DMD doesn't use a known and tried, imprecise GC because it is a lot slower. How is DMD written in D using the druntime GC going to help that ? I wondered about this ever since there was talk about DDMD. I'm totally expecting compile times to multiply by 1.2 or so. -- Marco
Re: Discusssion on the Discussion of the Design for a new GC
Am Wed, 23 Apr 2014 18:35:25 + schrieb Messenger d...@shoot.me: What is the state of Rainer Schütze's precise gc? Duplication of effort and all that. +1. And I hope you know what you are up to :D. Some people may expect a magic pill to emerge from your efforts that makes the GC approx. as fast as manual memory management for typical uses or at least as good as the one in Java. We must not forget that Java has just-in-time compilation and no raw pointer access. They might have found clever ways to make use of features/restrictions in Java, that are not available to D. Memory compaction is one from the top of my head. I only know for sure that you are looking into using some ideas from TCMalloc. Other than that, what are the exact problems you are trying to solve? That would be good to know, since different goals might require different implementations. E.g. a precise GC is generally slowed down by checking data types, but it doesn't keep memory alive because some float variable happens to look like a pointer to it. What are the limitations of garbage collection? As an example: If someone loads some million items graph structure into memory, can they still make any assumption about the run time of GC.alloc()? Can generational collection be implemented? -- Marco
Re: [OT] from YourNameHere via Digitalmars-d
Am Tue, 22 Apr 2014 20:47:13 +1000 schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com: On 22 April 2014 19:00, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/21/2014 10:49 PM, Manu via Digitalmars-d wrote: I like gmail. I've been using it for the better part of 10 years, and I can access it from anywhere. Installing client software to read email feels like I'm back on my Amiga in the 90's ;) I feel quite the opposite. Recently my email provider lured me into some paid option by cleverly placing a buy option right after the login where you expect some inbox button. With a client software you know what you have. Things don't unexpectedly change. You can have your messages on your computer and don't depend on internet and server uptime. Well, I'd say that about any cloud service I guess. Congrats on fixing it so it doesn't send the html version! This is much better. Yeah sorry. I could never tell the difference. Since it's not a full client, it doesn't have features like raw-view or anything. If posts actually contain something that cannot be represented in plain text I don't mind some HTML. All posts load quickly in Claws Mail anyways, regardless of mime-type. It's just not so exciting to view the very same text message with a non-default font. :p -- Marco
Re: Package permission and symbol resolution
Am Tue, 22 Apr 2014 18:07:21 +1000 schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com: extern (C) void func(const(char)* pString); By the way: What about adding nothrow there? -- Marco
Re: Static Analysis Tooling / Effective D
Am Tue, 21 Jan 2014 04:34:56 + schrieb Brian Schott briancsch...@gmail.com: There's a small feature wishlist in the project's README, but I'd like to get some opinions from the newsgroup: What kinds of errors have you seen in your code that you think a static analysis tool could help with? Yes, this one: size_t shiftAmount = 63; […] auto x = 1 shiftAmount; The trouble is that auto will now resolve to int instead of size_t as indicated by the type of shiftAmount. Sure, my fault was to use an innocent »1« instead of »cast(size_t) 1«. So the result is: int x = -2147483648; But »1 size_t« doesn't always yield an int result! Compare to this: size_t x = 1 shiftAmount; which becomes: size_t x = 18446744071562067968; Two possible warnings could be: - Shifting an »int« by a »size_t« is not the correct way to enforce a »size_t« result. Please use »cast(size_t) 1 shiftAmount« if that was the intention. - »auto« variable definition will resolve to »int« and may lose information from expression »1 shiftAmount«. Please replace »auto« with »int« if that is what you want or set the correct data type otherwise. In both cases an explicit mention of a data type resolves the ambiguity. -- Marco
