Re: DMD 2.066 Alpha
On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu wrote: Virtual by default will not change. Being able to negate the final: label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label. Andrei Just to try and establish a clear path forwards, if a pull request existed which added support for... final!true final!false ... would it be accepted? Or would a generic negate-x-DIP be required? const!false noexcept!false etc.
Re: dmd front end now switched to Boost license
On Sunday, 15 June 2014 at 01:08:00 UTC, Leandro Lucarella wrote: Joakim, el 14 de June a las 19:31 me escribiste: The frontend was dual-licensed under the Artistic license, which also allows such proprietary use, so nothing has really changed. Mmm, even when is true that the Artistic license is a bit more permissive than the GPL in some aspects, I think is hardly suitable for doing serious proprietary software (that you intent to sell). From the artistic license that was distributed by DMD: You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. Is a bit hairy, I don't think any companies would want to do proprietary tools using the artistic license :) https://github.com/D-Programming-Language/dmd/blob/083271a415716cf3e35321f91826397d91c0a731/src/artistic.txt I was referring to this clause from the Artistic license: 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. So you could have always distributed a modified, closed ldc with the frontend under the Artistic license- it would have to be ldc as the dmd backend is proprietary- as long as you also provided an unmodified ldc along with it. I don't think the part of the Artistic license you excerpted would apply to such a modified program, but even if the advertising part applied, I doubt any commercial user would care. Usually those who take your code _don't want_ to advertise where they got it from. ;) I realize you prefer the LGPL, to force others to contribute back to the frontend if they modify and distribute it, but the Boost license is much simpler and as Walter points out, proprietary use can help D's adoption. Again, I think from the practical point of view is the same. If you use boost license and tons of proprietary tools come out CHANGING the DMDFE and not contributing back, then the D community might get a boost because the have better tools but they are missing the contributions, so is hard to tell if the balance would be positive or negative. If they don't change the DMDFE (or contribute back the changes), then using boost or LGPL are the same, because it doesn't matter. Having better-quality paid tools would be a big boost, whether they released their patches or not. You point out that commercial users could always link against a LGPL frontend as a library and put their proprietary modifications in their own separate library, but that can be very inconvenient, depending on the feature. Also, I've pointed out a new model on this forum before, where someone could release a closed, paid D compiler but have a contract with their customers that all source code for a particular binary will be released within a year or two. This way, you get the best of both worlds, revenue from closed-source patches and the patches are open-sourced eventually. Such mixed models or other experimentation is possible under the freedom of more permissive licenses like Boost, but is usually much harder to pull off with the LGPL, as you'd be forced to separate all proprietary code from the LGPL frontend.
Re: DConf 2014 Day 1 Talk 5: Experience Report: Using D at Facebook and Beyond by Adam Simpkins
On 2014-06-12 19:28, Andrei Alexandrescu wrote: https://news.ycombinator.com/newest (please upvote, things get buried there quickly) https://twitter.com/D_Programming/status/477139782334963712 https://www.facebook.com/dlang.org/posts/864887076858308 http://www.reddit.com/r/programming/comments/27za5z/dconf_2014_day_1_talk_5_experience_report_using_d/ A comment about DStep and C++. The long term goal is to implement support for C++. Although, it's not something that is being worked on currently. Contributions are welcome. -- /Jacob Carlborg
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 19:27:44 UTC, Nick Sabalausky wrote: don't think those are the only important criteria. The thing is, D's licensing overall (DMDFE/DMDBE/LDC/GDC/Phobos) is kinda complicated. So any simplification, as long as it doesn't restrict anyone, is a net improvement, even if it isn't earth-shattering. Indeed. Having a single license makes the project look focused rather than a conglomerate moving in different directions.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Saturday, 14 June 2014 at 16:34:35 UTC, Dmitry Olshansky wrote: Consider something like REST API generator I have described during DConf. There is different code generated in different contexts from same declarative description - both for server and client. Right now simple fact that you import very same module from both gives solid 100% guarantee that API usage between those two programs stays in sync. But let's face it - it's a one-time job to get it right in your favorite build tool. Then you have fast and cached (re)build. Comparatively costs of CTFE generation are paid in full during _each_ build. There is no such thing as one-time job in programming unless you work alone and abandon any long-term maintenance. As time goes any mistake that can possibly happen will inevitably happen. In your proposed scenario there will be two different generated files imported by server and client respectively. Tiny typo in writing your build script will result in hard to detect run-time bug while code itself still happily compiles. Or a link error if we go a hybrid path where the imported module is emitting declarations/hooks via CTFE to be linked to by the proper generated code. This is something I'm thinking that could be a practical solution. snip What is the benefit of this approach over simply keeping all ctRegex bodies in separate package, compiling it as a static library and referring from actual app by own unique symbol? This is something that can does not need any changes in compiler or Phobos, just matter of project layout. It does not work for more complicated cases were you actually need access to generated sources (generate templates for example). You may keep convenience but losing guarantees hurts a lot. To be able to verify static correctness of your program / group of programs type system needs to be aware how generated code relates to original source. Build system does it. We have this problem with all of external deps anyway (i.e. who verifies the right version of libXYZ is linked not some other?) It is somewhat worse because you don't routinely change external libraries, as opposed to local sources. Huge mess to maintain. According to my experience all builds systems are incredibly fragile beasts, trusting them something that impacts program correctness and won't be detected at compile time is just too dangerous. Could be, but we have dub which should be simple and nice. I had very positive experience with scons and half-generated sources. dub is terrible at defining any complicated build models. Pretty much anything that is not single step compile-them-all approach can only be done via calling external shell script. If using external generators is necessary I will take make over anything else :) snip tl; dr: I believe that we should improve compiler technology to achieve same results instead of promoting temporary hacks as the true way to do things. Relying on build system is likely to be most practical solution today but it is not solution I am satisfied with and hardly one I can accept as accomplished target. Imaginary compiler that continuously runs as daemon/service, is capable of JIT-ing and provides basic dependency tracking as part of compilation step should behave as good as any external solution with much better correctness guarantees and overall user experience out of the box.
D port of docopt
In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org). https://github.com/rwtolbert/docopt.d Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D. It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive. This is also my first submission as a dub project, so hopefully I got that right as well. Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version. Regards, Bob
DIP63 : operator overloading for raw templates
http://forum.dlang.org/post/nwzuvslpvshqmwbed...@forum.dlang.org
Re: Soon be using D with Google App Engine via Managed VMs
On Thursday, 12 June 2014 at 15:23:12 UTC, Casey wrote: I didn't see anything in the article, but can you still use CloudSQL and similar from inside of one of those containers without using Java/Go/whatever else is supported by App Engine? CloudSQL can be used from anywhere, but the Datastore is limited to App Engine: «You still have access to core App Engine services such as Datastore, Task Queues, and Memcache from within Managed VMs» https://developers.google.com/cloud/managed-vms This is apparently not in preview yet, so it is not for production use and you have to apply to get access.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
15-Jun-2014 20:21, Dicebot пишет: On Saturday, 14 June 2014 at 16:34:35 UTC, Dmitry Olshansky wrote: But let's face it - it's a one-time job to get it right in your favorite build tool. Then you have fast and cached (re)build. Comparatively costs of CTFE generation are paid in full during _each_ build. There is no such thing as one-time job in programming unless you work alone and abandon any long-term maintenance. As time goes any mistake that can possibly happen will inevitably happen. The frequency of such event is orders of magnitude smaller. Let's not take arguments to supreme as then doing anything is futile due to the potential of mistake it introduces sooner or later. In your proposed scenario there will be two different generated files imported by server and client respectively. Tiny typo in writing your build script will result in hard to detect run-time bug while code itself still happily compiles. Or a link error if we go a hybrid path where the imported module is emitting declarations/hooks via CTFE to be linked to by the proper generated code. This is something I'm thinking that could be a practical solution. snip What is the benefit of this approach over simply keeping all ctRegex bodies in separate package, compiling it as a static library and referring from actual app by own unique symbol? This is something that can does not need any changes in compiler or Phobos, just matter of project layout. Automation. Dumping the body of ctRegex is manual work after all, including putting it with the right symbol. In proposed scheme it's just a matter of copy-pasting a pattern after initial setup has been done. It does not work for more complicated cases were you actually need access to generated sources (generate templates for example). Indeed, this is a limitation, and the import of generated source would be required. You may keep convenience but losing guarantees hurts a lot. To be able to verify static correctness of your program / group of programs type system needs to be aware how generated code relates to original source. Build system does it. We have this problem with all of external deps anyway (i.e. who verifies the right version of libXYZ is linked not some other?) It is somewhat worse because you don't routinely change external libraries, as opposed to local sources. But surely we have libraries that are built as separate project and are external dependencies, right? There is nothing new here except that d--obj--lib file is changed to generator--generated D file---obj file. Huge mess to maintain. According to my experience all builds systems are incredibly fragile beasts, trusting them something that impacts program correctness and won't be detected at compile time is just too dangerous. Could be, but we have dub which should be simple and nice. I had very positive experience with scons and half-generated sources. dub is terrible at defining any complicated build models. Pretty much anything that is not single step compile-them-all approach can only be done via calling external shell script. I'm not going to like dub then ;) If using external generators is necessary I will take make over anything else :) Then I understand your point about inevitable mistakes, it's all in the tool. snip tl; dr: I believe that we should improve compiler technology to achieve same results instead of promoting temporary hacks as the true way to do things. Relying on build system is likely to be most practical solution today but it is not solution I am satisfied with and hardly one I can accept as accomplished target. Imaginary compiler that continuously runs as daemon/service, is capable of JIT-ing and provides basic dependency tracking as part of compilation step should behave as good as any external solution with much better correctness guarantees and overall user experience out of the box. What I want to point out is to not mistake goals and the means to an end. No matter how we call it CTFE code generation is just a means to an end, with serious limitations (especially as it stands today, in the real world). Seamless integration is not about packing everything into single compiler invocation: dmd src/*.d Generation is generation, as long as it's fast and automatic it solves the problem(s) meta programming was established to solve. For instance if D compiler allowed external tools as plugins (just an example to show means vs ends distinction) with some form of the following construct: mixin(call_external_tool(args, 3, 14, 15, .92)); it would make any generation totally practical *today*. This was proposed before, and dismissed out of fear of security risks, never identifying the proper set of restrictions. After all we have textual mixins of potential security risk no problem. Let's focus on the facts that this has the benefits of: - sane debugging of the plug-in (it's just a program with the usual symbols) - fast, as the
Re: dmd front end now switched to Boost license
On Sun, Jun 15, 2014 at 02:20:11 +0200, Leandro Lucarella via Digitalmars-d-announce wrote: I just wanted to point out that there might be more ethical licenses to achieve the same effect (allowing companies to build proprietary tools on top on DMDFE). There's MPL which is source-file-based copyleft (rather than link-time copyleft). --Ben
Re: D port of docopt
Thanks for this. Have played with it a whole lot yet but it looks like it will work better for me than getopt does. Thanks again.
Re: D port of docopt
On Monday, 16 June 2014 at 00:40:25 UTC, Soulsbane wrote: Thanks for this. Have played with it a whole lot yet but it looks like it will work better for me than getopt does. Hope it works for you. Let me know if you have questions. While there are most likely cases of some command line interface it can't do, I continue to be impressed with all that it does do. I need to port the rest of the examples over from Python, but in reality they are just a big string and a bit of code to call the parser. Bob
Re: DMD 2.066 Alpha
On 6/15/14, 12:30 AM, Tove wrote: On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu wrote: Virtual by default will not change. Being able to negate the final: label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label. Andrei Just to try and establish a clear path forwards, if a pull request existed which added support for... final!true final!false would it be accepted? Or would a generic negate-x-DIP be required? const!false noexcept!false etc. I think we'd need an approved DIP. -- Andrei
Re: foreach
On 6/13/2014 10:03 AM, H. S. Teoh via Digitalmars-d wrote:
FWIW, I also see `for(;;)` as far better than `while(true)`. I like to
read `(;;)` as ever, so it literally reads forever { ... }. :-) (In
fact, in C/C++, you *could* #define ever (;;), then you can actually
write for ever. (Un)fortunately, in D this is not possible.)
Really, guys, the correct way to write an infinite loop is:
Loop:
... statements ...
goto Loop;
None of this candy-cane sugary stuff.
Re: D Logos
Well, they're definitely cool looking (and I certainly couldn't do anything that looks that good), but nothing about them makes me think of D. - Jonathan M Davis I totally agree with Jonathan. -- Alaksiej Stankievič
Re: foreach
On 6/15/2014 2:21 AM, Walter Bright wrote:
On 6/13/2014 10:03 AM, H. S. Teoh via Digitalmars-d wrote:
FWIW, I also see `for(;;)` as far better than `while(true)`. I like to
read `(;;)` as ever, so it literally reads forever { ... }. :-) (In
fact, in C/C++, you *could* #define ever (;;), then you can actually
write for ever. (Un)fortunately, in D this is not possible.)
Really, guys, the correct way to write an infinite loop is:
Loop:
... statements ...
goto Loop;
None of this candy-cane sugary stuff.
True story: I once had to put up with a production codebase (the
company's *flagship* product) that wasn't asm (it was VB6) and yet was
filled with garbage like this:
if ...cond... then
...statements...
goto somelabel
end
...statements...
somelabel:
Got posted on thedailywtf for that one.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. What Timon is saying is that not all memory safe code is verifiably @safe. @safe = memory safe, but not memory safe = @safe. David
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 6/15/2014 12:44 AM, David Nadlinger wrote: On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. What Timon is saying is that not all memory safe code is verifiably @safe. In D, they are defined to be the same thing, so the statement makes no sense. @safe = memory safe, but not memory safe = @safe. David
Re: foreach
On Sunday, 15 June 2014 at 07:05:37 UTC, Nick Sabalausky wrote: True story: I once had to put up with a production codebase (the company's *flagship* product) that wasn't asm (it was VB6) and yet was filled with garbage like this: if ...cond... then ...statements... goto somelabel end ...statements... somelabel: Heh, when writing a state machine the implied loops can be nontrivial and then gotos can result in cleaner, tighter and faster code than a regular loop with a switch statement or function pointers or or whatever. Co-routines and gotos can provide pretty clean state machines. IIRC the minimalistic Beta language used a lower level construct which allowed to loop a block (a pattern/object) using a restart statement. Then higher level looping constructs could be built on top of it. Basically like having the continue statement refer to a block. Anyway, for(;;) is idiomatic in C by now, so changing it would be a bad idea.
Re: Tail pad optimization, cache friendlyness and C++ interrop
David Nadlinger: @safe = memory safe, but not memory safe = @safe. Apparently that's not true, according to the post on the LLVM blog linked here: http://forum.dlang.org/thread/okratgxrikskmylmw...@forum.dlang.org Bye, bearophile
Re: D Logos
Alright, here is a link to a form so everyone can vote : https://docs.google.com/forms/d/1eL0AgKvoLyd9DVpzwG-mm2Uk82WdCjDrWSBP3MZpEFY/viewform?usp=send_form Jonathan mentioned the logo doesn't make him think about D. My interpretation of the logo is the following. It's three equal and intertwined pieces : - the 'three' parts represent Ds no compromise between convenience, modeling power and efficiency. If you put the logo aside those statements I think it's pretty obvious. - parts are the same, meaning the language is balanced properly with none of these properties outweighing the other ones. - parts are intertwined (at least in the logo I prefer), each design choice interacts nicely with the other ones. - it has D in it, although a bit hard to see I agree. - the logo looks sophisticated, which D is obviously. So I think it conveys some of the ideas behind D. Rust's logo emphasis security and strongness. Python's logo emphasis on flexibility and malleability. Java's logo emphasis on ... coffee breaks :) Anyways, feel free to provide some feedback in the form, let's see the outcome in one week. G
Re: async/await in F#
Scala Async introduces async/await as the way of simplifying future and promise construction. I haven't played with this much as yet, I have generally just used Future in Scala. Akka had something that was an extension of Scala's Future, but this is now deprecated in favour of Async. (The Akka stuff was way over-complicated to install and use.) Akka used to call this dataflow, and in the sense of dataflow as a single batch job making use of futures and promises to calculate a value, this could be seen as true. Dataflow though is about processes communicating with channels, and is far more interesting than what was called dataflow in Akka. GPars has this much more properly organized and spelled out (*). Go has gone the CSP, with elements of π-calculus, route and so can do dataflow but there are subtle issues which means dataflow should be different from π-calculus, and different from actors. This means D really needs a dataflow module to add to its data parallel module (std.parallelism) and actors module (std.concurrency provides what can be used as actors). (*) For obvious reasons :-) -- 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: D Logos
On Friday, 13 June 2014 at 03:33:41 UTC, Khaled wrote: If you like one of these designs and require some modifications then send me your feedbacks so I can update it accordingly. I like the design in principle, but it doesn't seem to spell D to my eyes at all, like others have already mentioned too. David
Re: Tail pad optimization, cache friendlyness and C++ interrop
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. Why? I found dozens of cases when @safe is broken, let alone other issues in bugzilla. After thinking about the @safety in D my conclusion is that it is impossible to evaluate memory and safety correctness of a code in which static type says nothing about where an object is allocated. Contrary to popular wisdom, one can have fixed array on heaps, classes on stack, etc. If any code which is potentially not safe is rejected, this would lead to lots of false positives making using the language very inconvenient. Even in that case, safety cannot be guaranteed by the language due to other issues, like separate compilation, etc. By the way, memory safety is also compromised by compiler bugs which make him generate buggy code. Note, when I counted memory safety problems, codegen issues were not counted. @safe should not be considered as feature which ensures that the code is memory safe, but as a feature rejecting code with high probability of memory bugs. The difference is very important. I have reached this conclusion some years ago and nothing has change in D since then which make me reconsidering my opinion (including that @safe holes were not fixed). Note, that I do not critique the language, it is fine. It is very good system level language with powerful modelling features. It is not good at verifying memory correctness, because in such languages (unlike managed ones) burden of memory correctness lies mostly on programmer. If he thinks that he can outsource memory correctness to @safe, there is high probability that he would be suddenly surprised.
Re: write(f)ln style exception factory
15-Jun-2014 02:03, Element 126 пишет: On 06/14/2014 09:04 PM, Dmitry Olshansky wrote: Recalling the previous discussion of throwing exception being costly, I thought the idiom of pay as you go is worth incorporating into the standard library. In brief: throw exception(CPU temperature is below, 2.5, K); vs throw new Exception(text(CPU temperature is below, 2.5, K)); or: enforce(false, text(CPU temperature is below, 2.5, K)); The benefit that the latter will only construct string if printing is indeed requested. Proof of concept: https://gist.github.com/DmitryOlshansky/59ec5953874bc1985ac5 The problem with it is that for some reason writeln of exception won't compile while thrown exception is printed just fine by the trace handler. Thoughts? --- writeln(myException.info); --- Is it what you are looking for ? No, normal exceptions print just fine. e.g. writeln(new Exception(abc)); I'm wondering what's wrong the one I defined, the error message seems to indicate that it doesn't have toString. It's wrong as there is one derived from Exception. Workaround was to use alias toString = Base.toString; -- Dmitry Olshansky
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 06/15/2014 10:33 AM, Walter Bright wrote:
What Timon is saying is that not all memory safe code is verifiably
@safe.
In D, they are defined to be the same thing,
Since when?
http://dlang.org/function
Function Safety
Safe functions are functions that are _statically checked_ to exhibit
_no possibility of undefined behavior_. Undefined behavior is often used
as a vector for malicious attacks.
Safe Functions
Safe functions are marked with the @safe attribute.
The following operations are not allowed in safe functions:
I.e. the documentation has two (conflicting) definitions and none of
them is the one you claim there is.
so the statement makes no sense.
Then please indicate how to fix the documentation. If you are going to
claim the Humpty Dumpty privilege, I'll back off. Thanks.
On 06/11/2014 11:35 AM, Walter Bright wrote:
What's not provable? Why would bit copying a struct not be memory safe?
Since you claim memory safe is the same as verifiably @safe, you are asking:
What's not provable? Why would bit copying a struct not be verifiably @safe?
struct S{ int x; }
void main()@safe{
S s,t;
memcpy(s,t,S.sizeof); // error
}
So, what is it that you are trying to bring across?
Re: D Logos
On Sun, 2014-06-15 at 09:17 +, David Nadlinger via Digitalmars-d wrote: On Friday, 13 June 2014 at 03:33:41 UTC, Khaled wrote: If you like one of these designs and require some modifications then send me your feedbacks so I can update it accordingly. I like the design in principle, but it doesn't seem to spell D to my eyes at all, like others have already mentioned too. More to the point, one doesn't just change a logo (*). The logo is a part of the brand and the brand is more than the logo. Although D doesn't really have an organized brand (at least as yet), the letter D with two moons red logo and the current red/brown/black website are the closest thing to a brand D has. There is also the issue of the D stick figure as a mascot. Rust and Go may not have the world's best brands, but they have a more joined up brand image than that of D. Just look at rust-lang.org and golang.org alongside dlang.org. Creating a strong brand is not easy, and it isn't just marketing hype; it is about looking at all aspects of public facing material: colou?rs, shapes, images, logos, fonts, layout, mascots, history,… A strong brand is a huge asset. The current D logo has a lot of history and a surprising public (as in programmer) awareness. This is an intangible asset not to be thrown away. We have had proposals for a new logo, a new website. I have no problem with this, but just as when dlang.org split off from Digital Mars, there needs to be thought about the whole brand, especially if you want to get traction of D usage. (*) cf. One doesn't just walk into Mordor. -- 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: Concurrent GC (for Windows)
On 14.06.2014 20:17, Dmitry Olshansky wrote: I added COW to the concurrent GC ( https://github.com/rainers/druntime/tree/concurrent_gc2 ) and it seems more stable with respect to pause times than the version with reading write watches. How do I run benchmarks and what are the newest results for you? The benchmarks have been recently merged into druntime. Compile and run runbench.d in the benchmark folder. I have updated the report and added new benchmarks at http://rainers.github.io/visuald/druntime/concurrentgc.html
Re: write(f)ln style exception factory
On 2014-06-15 11:40, Dmitry Olshansky wrote: No, normal exceptions print just fine. e.g. writeln(new Exception(abc)); I'm wondering what's wrong the one I defined, the error message seems to indicate that it doesn't have toString. It's wrong as there is one derived from Exception. Workaround was to use alias toString = Base.toString; Is this because writeln tries to use the one without parameters? If you override one method, which as overloads, you need to override all overloads or bring them into the same overload set with an alias, as you've done above. A base class and subclass have different overload sets [1]. [1] http://dlang.org/hijack.html search for Derived Class Member Function Hijacking. -- /Jacob Carlborg
A Perspective on D from game industry
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P I like how he says that productivity is important and mentions fear of meta-programming in the same article ;) Interesting though, I had totally different set of demands and expectation when used to work with C/C++. Feels like industry matters much more than a language here.
Re: A Perspective on D from game industry
Peter Alexander: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 From the post: If I have to point at what is most needed for productivity, I'd say interactivity. Interactive visualization, manipulation, REPLs, exploratory programming, live-coding. A language has both ~native efficiency and is usable for that level of interactivity is Julia :-) Bye, bearophile
Rosettacode example collection
Hi all, Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. I'm looking for some small stand-alone compiler benchmarks, so I'd very much appreciate if whoever it was could contact me via mail. Thanks, David
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P Reading his summary of the alternatives I felt D came out clearly on top, it's just that he didn't have the motivation to switch. Towards the end he mentions the web, for me (as an application developer rather than systems level guy) Android/iOS is the fly in the ointment - I'm torn as to whether to invest my energies in following D through its explorations or knuckling down and learning the Android API - after all, JDK8 + tooling is bearable now.
Re: A Perspective on D from game industry
On Sun, 2014-06-15 at 12:30 +, Abdulhaq via Digitalmars-d wrote: […] learning the Android API - after all, JDK8 + tooling is bearable now. On the other hand Android API is Apache Harmony which is Java 6. Of note: Groovy finally works on Android, so you can use what Java 8 brings, on Java 6 and Java 7 using Groovy. And note Groovy may be a dynamic language, but it is also a static language. -- 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: Rosettacode example collection
David Nadlinger: Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. I'm looking for some small stand-alone compiler benchmarks, so I'd very much appreciate if whoever it was could contact me via mail. Yes, I have such archive and I think it can be useful for your purposes, but it requires some care, so I think it's better to meet a moment on IRC in #D. Later, bearophile
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:45:30 UTC, Dicebot wrote: I like how he says that productivity is important and mentions fear of meta-programming in the same article ;) That's true, but meta programming is just a tool. Would be nice to implement dynamic visualisation and interactivity with it though. The fear of meta programming comes from Boost, and rightly so in my opinion. Boost is written with the assumption that users will never have to read its source code. When it comes to debugging and performance tuning however, that assumption is shattered. Fortunately, D makes meta programming more simple, but it's something to keep in mind. Interesting though, I had totally different set of demands and expectation when used to work with C/C++. Feels like industry matters much more than a language here. Absolutely. I'm beginning to learn of these differences since leaving gamedev :-)
Why are breakpoints caught by the runtime?
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
Re: Why are breakpoints caught by the runtime?
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
Which OS and compiler version is that? The breakpoint is
correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066 git:
# ./bptest
Trace/breakpoint trap
# gdb ./bptest
...
(gdb) run
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0041b7b5 in D main ()
(gdb)
Re: Why are breakpoints caught by the runtime?
Win7 x64
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Notice that in his post and the comments, a recurring (negative) issue is garbage collection. This is pretty common with mentions of D on reddit too, always a few posters mentioning D's GC as a negative. So many of those comments could be made obsolete by a decent precise garbage collector, and perhaps a compiler switch like the 'noruntime' one that Walter proposed a few months ago. On the plus side, D is mentioned prominently and in the comparison with C++ template programming D really shines.
Re: A Perspective on D from game industry
I can't take a blog post seriously when it's poorly written and full of grammatical errors. If you are in an engineering field of any kind, and you can't construct a paragraph in your favorite natural language, you're not worth anyone's time. The author of that blog is nothing but a sophisticated idiot who should not be taken seriously. I'm so sick of watching narcissistic cunts who just love to broadcast their opinions, enough said. On Sun, Jun 15, 2014 at 6:28 AM, Peter Alexander via Digitalmars-d digitalmars-d@puremagic.com wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P
Out of sight out of mind
Observe the following truths: 1) Issue tricking and resolution are kept separate in our community 2) That which is not visible garners no attention Presently, we file bugs/issues through issues.dlang.org, the maintenance of which is no small task and is certainly appreciated. However, it is an environment completely detached from where the actual work is performed. As such, it breeds neglect on the part of the developers: not because they do not care, but rather because they do not see. Take issue #143 for instance. It is the oldest open issue on the DLang Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two days later but was ignored for four years before Michal Minich made the second comment. Another two years went by before Martin Nowak addressed the issue, which Walter promptly reverted (reason unknown). The end result? Eight years flew by and the issue remains unresolved. This happens because we have two separate systems (one tracking problems, another tracking the resolution), both of which compete for the same precious and extremely limited resource: the volunteer time of developers. Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). Observe the following: https://github.com/AndrewEdwards/druntime/issues?state=open Note how quickly you can see the total number of open issues, traverse to any category, and identify what is important for a given milestone. We can even track our progress toward a specific milestone in seconds, or which issues we created or was assigned to us. By using this feature, we will eliminate the fire and forget problem currently observed with Bugzilla. We will be able to automatically link resolution to issue, by a mere mention of the issue number within the resolution. Issues become far more visible and, consequently, are not so easily forgotten. A complete win in my book. -Andrew
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 12:20:13 UTC, bearophile wrote: Peter Alexander: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 From the post: If I have to point at what is most needed for productivity, I'd say interactivity. Interactive visualization, manipulation, REPLs, exploratory programming, live-coding. A language has both ~native efficiency and is usable for that level of interactivity is Julia :-) My own experiments with Julia massively contradict that statement. I wrote some basic scripting programs that read large text files into hash tables which count word occurrences and Julia's performance was abysmal compared to D and Java.
Re: Out of sight out of mind
Big problem with GitHub issues is how simplistic those are. All categorization is done by labels with no internal differentiation, advanced search queries are not possible. Also bugzilla is self-hosted solution we have full control about and with GitHub you can only rely on what external API exposes. Also consider effort needed for moving all issues from existing database and breaking routine workflow of all active dmd/Phobos developers. Personally I don't think this is as much of an issue. Issues don't get much attention because there are only few people looking at them (other than own issues). Most D users don't have any reason to do so.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 15:31:40 UTC, Brian Rogoff wrote: On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Notice that in his post and the comments, a recurring (negative) issue is garbage collection. This is pretty common with mentions of D on reddit too, always a few posters mentioning D's GC as a negative. So many of those comments could be made obsolete by a decent precise garbage collector, and perhaps a compiler switch like the 'noruntime' one that Walter proposed a few months ago. I don't think a precise GC would fix this particular complaint. Games industry folks just don't like GC, mostly because of the pause, but also because of memory scarcity. I believe @nogc is going into 2.066. Maybe that will help, but we also need to make sure Phobos actually compiles with @nogc :-)
Re: Why are breakpoints caught by the runtime?
On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Schütz wrote:
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
Which OS and compiler version is that? The breakpoint is
correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066
git:
# ./bptest
Trace/breakpoint trap
# gdb ./bptest
...
(gdb) run
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0041b7b5 in D main ()
(gdb)
Obviously he is using windows and compiler version is irrelevant
- it is windows runtime issue.
Re: Why are breakpoints caught by the runtime?
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
It is default windows runtime behavior and unless it provides
some interface to adjust it, you can not fix it (except patching
and rebuilding runtime, of course). Or, perhaps, you can bypass
runtime behavior by using windows api directly to adjust the
behavior to your needs.
By the way, judging by that runtime catches windows exceptions
and rethrows them as errors (object.Error: Breakpoint), you are
not encouraged to catch them.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 15:31:40 UTC, Brian Rogoff wrote: On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Notice that in his post and the comments, a recurring (negative) issue is garbage collection. This is pretty common with mentions of D on reddit too, always a few posters mentioning D's GC as a negative. So many of those comments could be made obsolete by a decent precise garbage collector, and perhaps a compiler switch like the 'noruntime' one that Walter proposed a few months ago. On the plus side, D is mentioned prominently and in the comparison with C++ template programming D really shines. Another thing I have found funny is that how he both mentions GC as an issue an favors Go (with mandatory GC) over Rust (dismissing it memory model as irrelevant). This post really reads more like a casual rant than well-established opinion.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote: On Sunday, 15 June 2014 at 11:45:30 UTC, Dicebot wrote: I like how he says that productivity is important and mentions fear of meta-programming in the same article ;) That's true, but meta programming is just a tool. Would be nice to implement dynamic visualisation and interactivity with it though. Well I'd call it productivity tool number one when it comes to language features (as opposed to external tools). Best way to be productive at writing code is to not write it at all :) The fear of meta programming comes from Boost, and rightly so in my opinion. Boost is written with the assumption that users will never have to read its source code. When it comes to debugging and performance tuning however, that assumption is shattered. Fortunately, D makes meta programming more simple, but it's something to keep in mind. C++ has done a huge damage to meta paradigm, resulting in many programmers thinking first about how horrible actual implementation is and rarely even considering what can help to achieve with more reasonable design. Had some good time of my own debugging Boost::Spirit2 _
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 15:37:51 UTC, Caligo via Digitalmars-d wrote: I can't take a blog post seriously when it's poorly written and full of grammatical errors. If you are in an engineering field of any kind, and you can't construct a paragraph in your favorite natural language, you're not worth anyone's time. The author of that blog is nothing but a sophisticated idiot who should not be taken seriously. Location: Italy Qualifications: Rendering Engineer https://www.blogger.com/profile/01477408942876127202 Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Furthermore, you unjustly called him a sophisticated idiot and narcissistic cunt. You've only shown yourself to be the ignorant one.
Re: Out of sight out of mind
Andrew Edwards: Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now? Bye, bearophile
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 16:21:03 UTC, bearophile wrote: Andrew Edwards: Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now? Bye, bearophile Moving itself can be done automatically via GitHub API (I had script for copying isues between GitHub repos for example). Problem is that GitHub issues don't provide same set of features bugzilla does so moving inevitably comes with information loss.
Re: A Perspective on D from game industry
Brian Rogoff: On Sunday, 15 June 2014 at 12:20:13 UTC, bearophile wrote: A language has both ~native efficiency and is usable for that level of interactivity is Julia :-) My own experiments with Julia massively contradict that statement. I wrote some basic scripting programs that read large text files into hash tables which count word occurrences and Julia's performance was abysmal compared to D and Java. Julia is in its infancy, while the JavaVM is the product of a lot of work and tuning. I even expect Julia associative arrays to be currently a little slower than CPython dicts :-) So it will take years. But both D and Java are not as dynamic as Julia. Bye, bearophile
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 13:19:12 UTC, Russel Winder via Digitalmars-d wrote: On Sun, 2014-06-15 at 12:30 +, Abdulhaq via Digitalmars-d wrote: […] learning the Android API - after all, JDK8 + tooling is bearable now. On the other hand Android API is Apache Harmony which is Java 6. Yes I keep forgetting that - wishful thinking maybe. Of note: Groovy finally works on Android, so you can use what Java 8 brings, on Java 6 and Java 7 using Groovy. And note Groovy may be a dynamic language, but it is also a static language. I'll look into it. Perhaps this question is just too broad, but if you wanted to develop an application on the Android platform right now, what approach would you take? Java, Groovy, web-based?
Re: Why are breakpoints caught by the runtime?
It is default windows runtime behavior Yeah but couldn't/shouldn't it let breakpoints through?
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 16:02:18 UTC, Dicebot wrote: Another thing I have found funny is that how he both mentions GC as an issue an favors Go (with mandatory GC) over Rust (dismissing it memory model as irrelevant). Well, he mentioned that Go's mandatory GC is a negative in game dev, and only a positive vis-a-vis Rust in that Rust requires some advanced type machinery to ensure memory safety sans GC. GC does have large pluses and minuses, so it's easy to contradict ones self when discussing it. I think D would have been better off not requiring it, but trying to be GC friendly (like Rust and Ada), but that ship sailed a long time ago. Now I'd just like to see D acquire a very good GC and the ability to easily write code which doesn't use it, or uses a specialized one, or turns it off, etc. This post really reads more like a casual rant than well-established opinion. Agreed, but it's on a topic dear to all of us :-) I'm pretty optimistic about D's future. The negatives in that rant weren't so bad.
Re: Rosettacode example collection
Nothing exciting, but I tried to port the Java implementations of the benchmark game [1] to D. [2] My focus was to use the same algorithm/abstraction used in the Java implementation. I haven't finished the porting of all benchmarks but you can use them if they help you. May I ask you what you try to do? It sounds a bit we share some intent. My intent with that repo is to build a little benchmarking platform to compare languages, compilers and algorithms. My primary goal for now is to compare the benchmark game implementations of Java to see how D performs against them in terms of compilation time and performance. But it's a hobby project to get to write some D code for learning purposes first of all. And it will come forward very slowly because I don't intent to put much effort/time into it. [1] http://benchmarksgame.alioth.debian.org/ [2] https://github.com/ThomasMader/benchmark/tree/master/src On Sunday, 15 June 2014 at 12:25:39 UTC, David Nadlinger wrote: Hi all, Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. I'm looking for some small stand-alone compiler benchmarks, so I'd very much appreciate if whoever it was could contact me via mail. Thanks, David
Re: Out of sight out of mind
On 6/15/14, 12:21 PM, bearophile wrote: Andrew Edwards: Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). How do you move the Bugzilla issues and their attach files and cross links to GitHub? And how do you move all that back to Bugzilla (or another bug manager) once something terrible happens to GitHub four years from now? How do you recover your work from the GitHub five years from now when GitHub falls off the edge of the earth and simultaneously your PC with the only backup copy gets fried by an electrical surge? Say GitHub never recovers from said disaster: what will you do to reunite all the developers working on D that seem far more productive than before moving to GitHub? And while we are predicting the demise of GitHub, what happens when the server housing DITS fall into the same black hole as GitHub? People repeatedly file the same bug report, even though those reports are publicly visible on an infinitely more powerful and internally controlled system than GitHub. The database will be rebuilt by this very action. And that's assuming the worst case scenario: the GitHub server farm (and every productive member of the GitHub team) gets swallowed up by a black hole and no knows how to bring them back. As for transferring the data to GitHub, nothing says the transition has to be instantaneous. It can be accomplished in two steps: 1) Open all new issues in GitHub 2) Migrate reports individually to GitHub and close out from on Bugzilla #1 would cause the problem of requiring people to use two systems at the same time, but since we are already doing that, it does not add to the cognitive load. #2 poses the problem of who will do the work. Assuming there is no automatic way to get it done, I am willing to personally migrate every single report by hand.
Re: Rosettacode example collection
Thomas Mader: My primary goal for now is to compare the benchmark game implementations of Java to see how D performs against them in terms of compilation time and performance. So you are missing most of the point of using D, and you are perhaps even relying too much on the D GC, that is much worse than the JavaVM GC. Bye, bearophile
Re: Out of sight out of mind
On 6/15/14, 11:46 AM, Dicebot wrote: Big problem with GitHub issues is how simplistic those are. All Simplistic they are indeed. But how does that detract from the utility of the product. As programmers we are may be drawn to complexity, but some things need not be complex to be effective. categorization is done by labels with no internal differentiation, advanced search queries are not possible. Also bugzilla is self-hosted solution we have full control about and with GitHub you can only rely on what external API exposes. True, we do not have access to anything but the external API, however I don't see that as a limiting factor. When I conduct a search in DITS, I effectively search through labels. Of course those labels present themselves as data fields/values in some row of a table but they are labels none the less. If I want to find issues filed under multiple labels, i simply include all labels of interest in my search. The same is possible in GitHub, except they are presented right there on the screen for immediate access. Want to know how many bug request were closed as invalid or wontfix? Click on the labels and walla, your search is complete. I have had experienced zero issues finding information on GitHub, in spite of their overly simplistic interface. As for internal differentiation of labels... A label is simply a label. It has no differentiation or meaning except that applied to it by the community. Marking something as Product:D Component: DMD Version:D1 D2 Hardware: All All is absolutely no different than creating the labels D1, D2, and All in the DMD repo and assigning all three labels to the issue. The only thing that gives increase meaning to the labels any label (P1, P2, etc.), is the value we, the users, assign to them. As far as I can see the only thing GitHub is missing is a way to vote up the value of a label. Also consider effort needed for moving all issues from existing database and breaking routine workflow of all active dmd/Phobos developers. Breaking what routine workflow? You can claim that if it's required to file an issue in DITS before anything can be done on GitHub but that's not the case. You can also claim that if every issue resolved via GitHub is explicitly linked to it's originating issue on DITS but that's not the case either. As for the effort to move the issues I'm sure there is a process for automatically moving the DITS records to GitHub. And if there isn't, I'm not against doing the work myself. Personally I don't think this is as much of an issue. Issues don't get much attention because there are only few people looking at them (other than own issues). Most D users don't have any reason to do so. You are quite correct, most people will only work on what they want to work on. But I think a lot of these issues are ignored because they are just not being seen. This move may not motivate any specific person to work on any specific bug but it integrates the two processes, and automates some of the more often neglected trivialities. It also has the added benefit of always visible so it has the positive effect of being a constant reminder.
DIP63 : operator overloading for raw templates
http://wiki.dlang.org/DIP63
This is solution for a problem I am currently having with
implementing http://wiki.dlang.org/DIP54 (afair it was also
mentioned by Timon Gehr during old discussion of that DIP)
New proposed semantics ( to catch your attention and get to read
the link ;) ):
template Pack(T...)
{
alias expand = T;
alias opIndex(size_t index) = T[index];
alias opSlice(size_t lower, size_t upper) =
Pack!(T[lower..upper]);
alias opDollar = T.length;
}
// no ambiguity as Pack!(int, int) is not a valid type
// is(element == int)
alias element = Pack!(int, int)[1];
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 6/15/2014 2:48 AM, Timon Gehr wrote: On 06/15/2014 10:33 AM, Walter Bright wrote: What Timon is saying is that not all memory safe code is verifiably @safe. In D, they are defined to be the same thing, Since when? http://dlang.org/function Function Safety Safe functions are functions that are _statically checked_ to exhibit _no possibility of undefined behavior_. Undefined behavior is often used as a vector for malicious attacks. Safe Functions Safe functions are marked with the @safe attribute. The following operations are not allowed in safe functions: I.e. the documentation has two (conflicting) definitions and none of them is the one you claim there is. so the statement makes no sense. Then please indicate how to fix the documentation. If you are going to claim the Humpty Dumpty privilege, I'll back off. Thanks. I don't know why the documentation says that. D's @safe is about memory safety, not undefined behavior. Note that the list of eschewed behaviors are possibly memory corrupting. Signed integer overflow, for example, is not listed.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 6/15/2014 2:30 AM, Maxim Fomin wrote: On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. Why? I found dozens of cases when @safe is broken, let alone other issues in bugzilla. Those are bugs. We aim to fix them. By the way, memory safety is also compromised by compiler bugs which make him generate buggy code. Note, when I counted memory safety problems, codegen issues were not counted. I don't think we should mix intention with bugs. Bugs need to get fixed. I have reached this conclusion some years ago and nothing has change in D since then which make me reconsidering my opinion (including that @safe holes were not fixed). I do welcome help in fixing bugs.
Re: A Perspective on D from game industry
I didn't make the assumption that English is his mother tongue; however, judging by his writing, I can tell that he's been using the English language for at least a few years. In any case, the idea of a sentence or a paragraph is not unique to the English language. You learn what a sentence is and how to construct a paragraph at an early age, regardless of the language. I think it would be difficult to argue that producing a correct paragraph in a natural language is harder than producing a paragraph in an artificial language. If someone like him is still struggling with sentences and paragraphs in a natural language, why should anyone pay attention to what he has to say about programming languages? On Sun, Jun 15, 2014 at 11:20 AM, Xinok via Digitalmars-d digitalmars-d@puremagic.com wrote: Location: Italy Qualifications: Rendering Engineer https://www.blogger.com/profile/01477408942876127202 Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Furthermore, you unjustly called him a sophisticated idiot and narcissistic cunt. You've only shown yourself to be the ignorant one.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P I wonder where he got the idea that D isn't high performance... Perhaps the fact that it has a GC?
Re: Out of sight out of mind
On 6/15/2014 8:37 AM, Andrew Edwards wrote: Take issue #143 for instance. Convenient linky: https://issues.dlang.org/show_bug.cgi?id=143
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 16:20:28 UTC, Xinok wrote: Location: Italy Qualifications: Rendering Engineer https://www.blogger.com/profile/01477408942876127202 Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Furthermore, you unjustly called him a sophisticated idiot and narcissistic cunt. You've only shown yourself to be the ignorant one. Agreed, this culture of, be perfect or I won't listen to you is annoying. Natural language is not a well specified language like programming (where the computer truly can't do anything but exactly what you tell it). Natural language is only useful as a means for communication. If your only concerned with the grammar and ignore the communication, you've missed the point. (This is coming from someone who's worked on getting a computer to understand that communication and respond appropriately. Note: proper grammar does not remove ambiguity). Instead, concentrate on what was communicated and write a retort for that. For example: In his referenced 2011 post he says that a new C++ is needed because no one fully understands it. In this post he says D is of no value because no one needs to fully understand C++. He obviously doesn't understand the value of putting meta programming into the hands of the common programmer, and I believe D does this even though it can get more complex. Also in the 2011 post, D should have been listed in all three section, Scripting, High-level, System. This suggests he doesn't really see D as bridging the gap and uniting all layers.
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote: Observe the following truths: 1) Issue tricking and resolution are kept separate in our community 2) That which is not visible garners no attention Presently, we file bugs/issues through issues.dlang.org, the maintenance of which is no small task and is certainly appreciated. However, it is an environment completely detached from where the actual work is performed. As such, it breeds neglect on the part of the developers: not because they do not care, but rather because they do not see. Take issue #143 for instance. It is the oldest open issue on the DLang Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two days later but was ignored for four years before Michal Minich made the second comment. Another two years went by before Martin Nowak addressed the issue, which Walter promptly reverted (reason unknown). The end result? Eight years flew by and the issue remains unresolved. This happens because we have two separate systems (one tracking problems, another tracking the resolution), both of which compete for the same precious and extremely limited resource: the volunteer time of developers. Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). Observe the following: https://github.com/AndrewEdwards/druntime/issues?state=open Note how quickly you can see the total number of open issues, traverse to any category, and identify what is important for a given milestone. We can even track our progress toward a specific milestone in seconds, or which issues we created or was assigned to us. By using this feature, we will eliminate the fire and forget problem currently observed with Bugzilla. We will be able to automatically link resolution to issue, by a mere mention of the issue number within the resolution. Issues become far more visible and, consequently, are not so easily forgotten. A complete win in my book. -Andrew I agree with this quite a lot. If for nothing else, I agree with this because I think it makes the most sense to have the place we do pull requests be the same place we track issues. There are a few other reasons I agree with this, but the point is that I would very much like to see this happen.
Re: A Perspective on D from game industry
On 6/15/2014 7:45 AM, Dicebot wrote: I like how he says that productivity is important and mentions fear of meta-programming in the same article ;) Or how productivity is important, but fixing C++'s death-by-a-thousand-cuts productivity killers by...fixing those many little cuts as he already admits D *does*...isn't good enough because it doesn't come in the form of one big silver bullet. Like OO. Except, oops!, he doesn't like big silver bullets like OO either. And every time a language *does* fix a C++ problem, it's suddenly backtracking time: Oh, well, we already addressed that in C++ via some paperclips and chewing gum. I don't think he even knows what he wants. He just wants to sit there and let somebody else wave a wand to magically solve ALL his problems simultaneously. Nothing less will do. It really gets me that the same industry which created Frostbite 3, Unreal Engine 4, GTA5, Steam (obviously all enormous investments), mostly done *in* C++ which makes them that much MORE effort, will bitch *soo* much about C++ and STILL won't get off their asses enough to write, or even contribute to, a mere language.
Re: Out of sight out of mind
Andrew Edwards: How do you recover your work from the GitHub five years from now when GitHub falls off the edge of the earth Online sites are ephemeral. So unless there is a way to move the bug repository off GitHub if the need arises, I am not going to appreciate the idea of moving bugs to GitHub. Bye, bearophile
Re: A Perspective on D from game industry
On 6/15/2014 6:50 AM, Peter Alexander wrote: The fear of meta programming comes from Boost, and rightly so in my opinion. Boost is written with the assumption that users will never have to read its source code. When it comes to debugging and performance tuning however, that assumption is shattered. For years I avoided C++ templates (even though I implemented them in DMC++) because they were just so dang hard to read. D originally was not going to have templates for that reason. But I eventually discovered that hiding behind the complexity of C++ templates was a very simple idea - templates are just functions with compile time rather than run time arguments. (Isn't it amazing that I could implement C++ without figuring this out? I still don't understand that.) That was the enabling breakthrough for D templates. In fact, templates engender such an OMG! Templates! I don't get Templates! aura about them that I convinced Andrei to not even use the word template in his book about D!
Re: A Perspective on D from game industry
On 6/15/2014 12:27 PM, Nick Sabalausky wrote: It really gets me that the same industry which created Frostbite 3, Unreal Engine 4, GTA5, Steam (obviously all enormous investments), mostly done *in* C++ which makes them that much MORE effort, will bitch *soo* much about C++ and STILL won't get off their asses enough to write, or even contribute to, a mere language. It's all about comfort zone. It is much easier to continue doing what one is familiar with than to try something new. It's also fair to say that some people have learned D, and gone back to C++.
Re: A Perspective on D from game industry
On 6/15/2014 3:53 PM, Walter Bright wrote: On 6/15/2014 12:27 PM, Nick Sabalausky wrote: It really gets me that the same industry which created Frostbite 3, Unreal Engine 4, GTA5, Steam (obviously all enormous investments), mostly done *in* C++ which makes them that much MORE effort, will bitch *soo* much about C++ and STILL won't get off their asses enough to write, or even contribute to, a mere language. It's all about comfort zone. It is much easier to continue doing what one is familiar with than to try something new. While I do agree completely with that, any suggestion of *C++* being in someone's comfort zone just sounds like Yea, swimming in a pool of razor blades isn't ideal, but I've just gotten so darn comfortable with it! Like an old pair of shoes! With lava inside them!
Re: Out of sight out of mind
While I agree that some of these points are true, what's not true is that the use of bugzilla and it's separateness from github is the cause. Bugzilla has a similar set of features for categorization and future release management as github. Having bugs tracked via github's issue tracker won't make the use of those types of features any more or less doable or easy. Having the bugs tracked via github will not make it any easier to manage, just different. What's missing is actually using those features, which is not inconsiderable work. On 6/15/14, 8:37 AM, Andrew Edwards via Digitalmars-d wrote: Observe the following truths: 1) Issue tricking and resolution are kept separate in our community 2) That which is not visible garners no attention Presently, we file bugs/issues through issues.dlang.org, the maintenance of which is no small task and is certainly appreciated. However, it is an environment completely detached from where the actual work is performed. As such, it breeds neglect on the part of the developers: not because they do not care, but rather because they do not see. Take issue #143 for instance. It is the oldest open issue on the DLang Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two days later but was ignored for four years before Michal Minich made the second comment. Another two years went by before Martin Nowak addressed the issue, which Walter promptly reverted (reason unknown). The end result? Eight years flew by and the issue remains unresolved. This happens because we have two separate systems (one tracking problems, another tracking the resolution), both of which compete for the same precious and extremely limited resource: the volunteer time of developers. Already proven a valuable resource, GitHub offers the tools necessary to resolve this problem. The issues feature (not currently activated for any D-Programming-Language repo) allows us to set milestones (with due dates), assign tasks, and create and apply labels (multiple where required). Observe the following: https://github.com/AndrewEdwards/druntime/issues?state=open Note how quickly you can see the total number of open issues, traverse to any category, and identify what is important for a given milestone. We can even track our progress toward a specific milestone in seconds, or which issues we created or was assigned to us. By using this feature, we will eliminate the fire and forget problem currently observed with Bugzilla. We will be able to automatically link resolution to issue, by a mere mention of the issue number within the resolution. Issues become far more visible and, consequently, are not so easily forgotten. A complete win in my book. -Andrew
Re: A Perspective on D from game industry
On 6/15/2014 9:20 AM, Xinok wrote: Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Xinok does have a point that we all should be aware of. I've found a very strong correlation between poor writing skills and disorganized thinking. (Your point about non-native English speakers is well taken, one must not confuse unfamiliarity with English with disorganized thinking.) I'm hardly the only one. If one wants their views to be taken seriously, pay attention to spelling, grammar, paragraphs, organized writing, etc. There's an awful lot of stuff to read on the internet, and poor writing often elicits a meh, I'll skip this one and move on reaction.
Re: A Perspective on D from game industry
You'll likely toss me into the same boat as the post you're ranting about, but please, watch the misogynistic language here. On 6/15/14, 8:37 AM, Caligo via Digitalmars-d wrote: I'm so sick of watching narcissistic edited who just love to broadcast their opinions, enough said.
Re: A Perspective on D from game industry
I work in the game industry so I'm familiar with this type of mindset. Not everyone in my industry is like this, but unfortunately many are(I avoid working with them). He doesn't understand metaprogramming and so dismisses it. He also assumes C++ is all about Java style OOP, when modern style is wildly different from Java. And yes the game industry will likely *never* produce its own language or tools. Why? Because it is very short-term goal oriented, focusing almost entirely on the current project with little thought for long term growth. Most companies are relatively small, and even large ones like EA are very fragmented(although EA did produce its own version of the STL). Basically, this guy is a *rendering engineer*, likely good at math and algorithms, but not so hot with design. For years I avoided C++ templates (even though I implemented them in DMC++) because they were just so dang hard to read. D originally was not going to have templates for that reason. But I eventually discovered that hiding behind the complexity of C++ templates was a very simple idea - templates are just functions with compile time rather than run time arguments. (Isn't it amazing that I could implement C++ without figuring this out? I still don't understand that.) That was the enabling breakthrough for D templates. In fact, templates engender such an OMG! Templates! I don't get Templates! aura about them that I convinced Andrei to not even use the word template in his book about D!
Re: A Perspective on D from game industry
On 6/15/2014 1:10 PM, Walter Bright wrote: Xinok does have a point that we all should be aware of. I meant Caligo. My mistake.
Re: A Perspective on D from game industry
On 6/15/2014 1:20 PM, Brad Roberts via Digitalmars-d wrote: You'll likely toss me into the same boat as the post you're ranting about, but please, watch the misogynistic language here. I agree. It was not necessary to make his point.
Re: A Perspective on D from game industry
I'm going to try my hand at making a game with 2.066, because I believe @nogc is a final piece in a puzzle of making doing that easy. Much like writing bare metal D code without the runtime, I'm going to try my hand at writing D code with the main function marked as @nogc, because I reckon it's going to leave me with a saner set of syntax and semantics than either C or C++ in the end, with none of the drawbracks from the stop the world effect in a game loop. Having said that, I do think there's some kind of brain malfunction on the part of games programmers that makes them think is slow and can't escape from when they hear garbage collector and makes things more complicated and slower when they hear template. Neither of these things are true.
Re: Out of sight out of mind
On 6/15/14, 4:13 PM, Brad Roberts via Digitalmars-d wrote: While I agree that some of these points are true, what's not true is that the use of bugzilla and it's separateness from github is the cause. Bugzilla has a similar set of features for categorization and future release management as github. Having bugs tracked via github's issue tracker won't make the use of those types of features any more or less doable or easy. Having the bugs tracked via github will not make it any easier to manage, just different. What's missing is actually using those features, which is not inconsiderable work. I am not suggesting that bugzilla is the cause, rather that the separation of systems foster the condition. You are absolutely correct though. Without people actually using the features it matters not what system we use. My proposal for using one homogeneous system is geared on the idea that people doesn't care to admit that the problem exists or take initiative to fix it if they never have to look at it. Presented with it everyday however, some become motivated to take action to resolve the issue. I cannot see how doing this would negatively impact the community.
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 20:14:09 UTC, Brad Roberts via Digitalmars-d wrote: While I agree that some of these points are true, what's not true is that the use of bugzilla and it's separateness from github is the cause. Bugzilla has a similar set of features for categorization and future release management as github. Having bugs tracked via github's issue tracker won't make the use of those types of features any more or less doable or easy. Having the bugs tracked via github will not make it any easier to manage, just different. What's missing is actually using those features, which is not inconsiderable work. I couldn't agree more. GitHub certainly is not more capable than Bugzilla, and would be just as easy or hard to navigate with our large number of open issues. One thing that might be nice to have, though, is a What Should I Work On Next? type of page for newcomers, with a few saved searches and maybe some big-picture suggestions in addition to that. David
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 20:53:58 UTC, w0rp wrote: I'm going to try my hand at making a game with 2.066... It will be open-source? Can you tell what type of game you have in mind? Matheus.
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 20:51:59 UTC, Andrew Edwards wrote: My proposal for using one homogeneous system is geared on the idea that people doesn't care to admit that the problem exists or take initiative to fix it if they never have to look at it. How do I have to look at the Issues tab on GitHub any more than I have to look at issues.dlang.org? I cannot see how doing this would negatively impact the community. It's a lot of work that could be invested much better, plus we'd lose all the authorship information on the issues and comments (you can copy them as text, but all the issue subscriptions, … are no longer there). David
Re: Rosettacode example collection
On Sunday, 15 June 2014 at 17:19:42 UTC, bearophile wrote: So you are missing most of the point of using D, and you are perhaps even relying too much on the D GC, that is much worse than the JavaVM GC. I am aware of the D GC issue and know that I need to take another route to get the most out of D, but to compare languages it's also interesting to see how they compare with similar implementation. The GC might never be as performant as Java's but it's nice if you can estimate to what extent it is slower and maybe trace improvement of the GC implementation over time. The usual way of microbenchmarking is another perspective which should be looked into too but this viewpoint might show weaknesses better and might lead to clues on what should/can be improved.
Re: Out of sight out of mind
On Sunday, 15 June 2014 at 17:40:58 UTC, Andrew Edwards wrote: True, we do not have access to anything but the external API, however I don't see that as a limiting factor. When I conduct a search in DITS, I effectively search through labels. Of course those labels present themselves as data fields/values in some row of a table but they are labels none the less. If I want to find issues filed under multiple labels, i simply include all labels of interest in my search. The same is possible in GitHub, except they are presented right there on the screen for immediate access. Want to know how many bug request were closed as invalid or wontfix? Click on the labels and walla, your search is complete. I have had experienced zero issues finding information on GitHub, in spite of their overly simplistic interface. You can _either_ use text search _or_ chose labels. This is critical IMHO.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On 6/15/2014 2:30 AM, Maxim Fomin wrote: I found dozens of cases when @safe is broken, let alone other issues in bugzilla. I have added the keyword 'safe' to bugzilla. I'd appreciate it if you would go through the bugzilla issues you've identified with @safe, and mark them with the 'safe' keyword. Thanks!
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 16:06:08 UTC, Dicebot wrote: On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote: Had some good time of my own debugging Boost::Spirit2 _ That's simply an impossible task! ;-P --- Paolo
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 21:00:23 UTC, MattCoder wrote: On Sunday, 15 June 2014 at 20:53:58 UTC, w0rp wrote: I'm going to try my hand at making a game with 2.066... It will be open-source? Can you tell what type of game you have in mind? Matheus. Yeah. I'll put it all on GitHub. I did a little bit of work on it before. My past experience is just writing graphics code at university with the legacy OpenGL API. I don't want to make some AAA video game or something. I'm just going to make a dumb game where you walk around little mazes and diamonds try to kill you.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 21:11:38 UTC, Paolo Invernizzi wrote: On Sunday, 15 June 2014 at 16:06:08 UTC, Dicebot wrote: On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote: Had some good time of my own debugging Boost::Spirit2 _ That's simply an impossible task! ;-P If spending only reasonable time is in question - oh yes. If you are eager to spend months of spare time - there are some possibilities ;) btw ironically this is when I have felt in love with generic paradigm, with reasoning wow, this is kind of cool despite all C++ madness, how cool it can be with same language implementation?. ..or it is just form of Stockholm syndrome.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 20:10:34 UTC, Walter Bright wrote: On 6/15/2014 9:20 AM, Xinok wrote: Given that he lives in Italy, it's safe to assume that English is not his first language. But rather than consider what he has to say or dispute his arguments, you completely dismissed his point of view because his level of writing doesn't meet your standards. Xinok does have a point that we all should be aware of. I've found a very strong correlation between poor writing skills and disorganized thinking. (Your point about non-native English speakers is well taken, one must not confuse unfamiliarity with English with disorganized thinking.) I'm hardly the only one. If one wants their views to be taken seriously, pay attention to spelling, grammar, paragraphs, organized writing, etc. There's an awful lot of stuff to read on the internet, and poor writing often elicits a meh, I'll skip this one and move on reaction. True but if I'm going to judge a comment by the way it's written I'll take a second language piece over a foul and insulting rant any day of the week.
Re: A Perspective on D from game industry
w0rp: I'm going to try my hand at writing D code with the main function marked as @nogc, That's going to be lot of fun! Are you going to need Unicode text? One report: https://d.puremagic.com/issues/show_bug.cgi?id=12768 Bye, bearophile
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 21:18:10 UTC, Dicebot wrote: If spending only reasonable time is in question - oh yes. If you are eager to spend months of spare time - there are some possibilities ;) btw ironically this is when I have felt in love with generic paradigm, with reasoning wow, this is kind of cool despite all C++ madness, how cool it can be with same language implementation?. ..or it is just form of Stockholm syndrome. C++ meta-programming is already quite cool when you get how to make duck-typed algorithms, STL-style. It's the C++ culture that might be a problem: the STL-style is rarely used by most practitionners.
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 18:50:14 UTC, Meta wrote: On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote: http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1 The arguments against D are pretty weak if I'm honest, but I think it's important we understand what people think of D. I can confirm this sentiment is fairly common in the industry. Watch out for the little jab at Andrei :-P I wonder where he got the idea that D isn't high performance... Perhaps the fact that it has a GC? He clarifies in the comments: D is not 'high-performance' the same way as C and C++ are not. Systems is not the same as high-performance. Fortran always has been more 'high-performance' than C/C++ as it doesn't have pointer aliasing (think that C++ introduced restrict, which is the bread and butter of a HPC language only in C++11, same for threading, still no vector types...) for example. ISPC is a HPC language or Julia, Fortran, even Numpy if you want, not D or C or C++ http://c0de517e.blogspot.in/2014/06/where-is-my-c-replacement.html?showComment=1402865174608#c415780017887651116
Re: Concurrent GC (for Windows)
On 06/04/2014 10:37 PM, Rainer Schuetze wrote: Most of the remaining pause time is sweeping garbage. I think about deferring sweeping into allocations by running finalizers just before reusing the memory for another object. This can throttle allocations a bit while at the same time reduce pauses. That's pausing the thread which triggered the collection, right? Other threads don't need to wait for sweeping. Dividing the cost to run finalizers among many allocations is a charming idea.
Re: Concurrent GC (for Windows)
On 06/12/2014 08:34 AM, Rainer Schuetze wrote: If I add the actual copy into heap2 (i.e. every fourth page of 512 MB is copied), I get 80-90 ms more. The numbers are not great, but I guess the usual memory usage and number of modified pages will be much lower. I'll see if I can integrate this into the concurrent implementation. Is there a chance that we can pause mutator threads when they trigger to many page copies?
Re: A Perspective on D from game industry
On Sunday, 15 June 2014 at 20:20:37 UTC, Brad Roberts via Digitalmars-d wrote: You'll likely toss me into the same boat as the post you're ranting about, but please, watch the misogynistic language here. Yes. Misogyny is clearly the issue here. Because it obvioulsy would have been SOOO completely different and much more tame to mention narcissistic cocks. As in People who can't tell misogyny from cussing are a bunch of stupid dicks. Or Viewing 'cunt' as a worse thing than 'cock' is uniquely charactaristic of misogynistic dickheadded hypocrites. You see, everthing I said is all ok because I didn't use any *female* terms negatively. Now that we've both accepted the virtues of equality, maybe later this evening we can join up and take back the night from all those EVIL MEN that are always waging war on poor defenseless women. Because apperently this is still 1950. On 6/15/14, 8:37 AM, Caligo via Digitalmars-d wrote: I'm so sick of watching narcissistic edited who just love to broadcast their opinions, enough said.
Re: Out of sight out of mind
On 06/15/2014 10:52 PM, David Nadlinger wrote: One thing that might be nice to have, though, is a What Should I Work On Next? type of page for newcomers, with a few saved searches and maybe some big-picture suggestions in addition to that. Go to https://issues.dlang.org/colchange.cgi and change your columns to include the votes helps a lot. Could we enable this by default? It's probably not the best idea for newcomers to work on the most voted problems, as those are usually very hard.
Re: Out of sight out of mind
On 06/15/2014 05:37 PM, Andrew Edwards wrote: Take issue #143 for instance. It is the oldest open issue on the DLang Issue Tracking System. Submitted by Jarrett Billingsley on May 17, 2006, it received one comment two days later but was ignored for four years before Michal Minich made the second comment. Another two years went by before Martin Nowak addressed the issue, which Walter promptly reverted (reason unknown). The end result? Eight years flew by and the issue remains unresolved. The main reasons why issues get stuck are unfinished debates, missing decisions and the general lack of manpower. Prioritization, focus and a bit of planning would help most to improve this IMO.
