Re: Is dmd fast?
On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote: You methodology is flawed. You are essentially measuring link time against the standard lib. If you're sitting on Linux make sure that you're using the GNU gold linker (`ld.gold`) by default (`ld`). On Ubuntu/Debian you should use sudo update-alternatives --config ld to configure this. The GNU gold linker should be the default on newer distributions.
Re: Examples of dub use needed
FWIW, this thread has inspired me to begin work on a project I've titled 'The DUB Handbook'. I've been meaning to write some tutorials about DUB (among other things) for learningd.org, but I think a detailed guide would be a more worthwhile project to pursue. My intention with the text is to provide a detailed description of every dub command and configuration directive, along with examples of how to use them in both JSON and SDLang formats. I've spent an hour getting it set up today (I'm using gitbook) and expect to be working on it over the next several weeks. When it's ready for feedback, I'll make it publicly available and announce it here in the forums. I plan to release it under a CC license.
Results of Rust Survey 2016
Survey results: https://docs.google.com/document/d/1F6oELZcO_ejX2oVk20hmiBWd4lQugfFahn7yKsw/preview# Maybe we should do a D survey? For Rust, D is even mentioned. For the question "What programming languages are you most comfortable with?" 68 of 3085 people selected D. An interesting fact "currently 19.8% use Rust at work either part-time or full-time". That is 395 of 1994 people.
Re: Results of Rust Survey 2016
On Thursday, 23 June 2016 at 08:33:39 UTC, qznc wrote: An interesting fact "currently 19.8% use Rust at work either part-time or full-time". That is 395 of 1994 people. People who use it at work are more likely to respond.
Re: Results of Rust Survey 2016
On Thursday, 23 June 2016 at 08:39:35 UTC, Ola Fosheim Grøstad wrote: On Thursday, 23 June 2016 at 08:33:39 UTC, qznc wrote: An interesting fact "currently 19.8% use Rust at work either part-time or full-time". That is 395 of 1994 people. People who use it at work are more likely to respond. Yes, sadly sampling bias is a thing. Would participate in survey, sounds fun.
Re: Phobo's migration
On Wednesday, 22 June 2016 at 19:02:38 UTC, Jack Stouffer wrote: On Wednesday, 22 June 2016 at 17:55:11 UTC, Joerg Joergonson wrote: How is that? That makes no sense. If Phobo's is production ready as claimed then freezing it can't make it automagically non-production ready, can it? D cannot afford to be stagnant in a time of fierce language competition. C++ almost died off completely outside of a couple of niches because it stood still for so long. D does not have the momentum to carry it for even a half year of no improvements. I didn't say they wernt, but they are being done on phobos Honest question: have you ever looked into Kaizen and lean management https://en.wikipedia.org/wiki/Kaizen? Because stopping everything in Phobos and waiting for "breakthroughs" is a dead on arrival plan. A continuous improvement process is much more viable, realistic, and likely to produce good results. This is not true. There are many development methodologies and most of them are not suitable for designing programming languages, including all "lean" methodologies.
Re: Phobo's migration
On Wednesday, 22 June 2016 at 17:55:11 UTC, Joerg Joergonson wrote: On Wednesday, 22 June 2016 at 16:51:32 UTC, Jack Stouffer wrote: On Wednesday, 22 June 2016 at 16:44:25 UTC, Joerg Joergonson wrote: How bout Freezing Phobos, except for bugs and start migrating it to Phobos 2.0?. This would kill the language. How is that? That makes no sense. If Phobo's is production ready as claimed then freezing it can't make it automagically non-production ready, can it? The DMD developers refuse to use Phobos in the D compiler, so Phobos is obviously not production ready. (Plenty of compilers use the C++ standard library.) I agree with the need for a D3 and a completely redesigned standard library though. But it will only happen as a fork, not from within the current team...
Re: Results of Rust Survey 2016
On Thursday, 23 June 2016 at 08:33:39 UTC, qznc wrote: Survey results: https://docs.google.com/document/d/1F6oELZcO_ejX2oVk20hmiBWd4lQugfFahn7yKsw/preview# Maybe we should do a D survey? Yes, this would be interesting to have the picture. For Rust, D is even mentioned. For the question "What programming languages are you most comfortable with?" 68 of 3085 people selected D. 1666 ppl selected Python. For the same Q in the D community I wouldn't be surprised to see something like, let's say, at least 40%, because Python is quoted really often everywhere in the forum or in the bug tracker. An interesting fact "currently 19.8% use Rust at work either part-time or full-time". That is 395 of 1994 people.
Re: Interest in Paris area D meetups?
On Monday, 13 June 2016 at 21:34:45 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? In case someone else wants to join. This has been postponed to next week. Wednesday 22nd same place, same time. We were 3 and that was a great meeting. The last time I met people I don't know from the Internet was probably 10 years ago, when I met up with a girl from a dating website. And you know how it works, you chat away pretending you're not here to seduce her (well, the first 30 minutes) and suddenly the magic happens ... or not at all. Well, that was EXACTLY the same, we met up at the bar, drank a beer and talked pretending we didn't know about D and suddenly: "What? Did you just mention the D programming language?? What were the odds that 3 people meet randomly in a big old town like Paris and find out they felt in love the same programming language? Oh my God...". ... We plan to meet up roughly once a month, so let's stay tuned... :)
Re: Phobo's migration
I agree with the need for a D3 and a completely redesigned standard library though. But it will only happen as a fork, not from within the current team... http://volt-lang.org/ as variant
Re: Results of Rust Survey 2016
On Thursday, 23 June 2016 at 09:18:47 UTC, sdds wrote: On Thursday, 23 June 2016 at 08:33:39 UTC, qznc wrote: For Rust, D is even mentioned. For the question "What programming languages are you most comfortable with?" 68 of 3085 people selected D. 1666 ppl selected Python. For the same Q in the D community I wouldn't be surprised to see something like, let's say, at least 40%, because Python is quoted really often everywhere in the forum or in the bug tracker. Now that Python has won over Ruby [0], it is the dominant scripting language. [0] https://www.google.com/trends/explore#q=python%20language%2C%20ruby%20language&cmpt=q&tz=Etc%2FGMT-2
Re: Phobo's migration
On Thursday, 23 June 2016 at 08:55:07 UTC, Ola Fosheim Grøstad wrote: The DMD developers refuse to use Phobos in the D compiler, so Phobos is obviously not production ready. Ridiculous. One data point does not make a trend. Phobos is "obviously" production ready as it's being used in production at many companies https://dlang.org/orgs-using-d.html So companies are willing to build their infrastructure on D because they have determined that it's ready for there uses. But we've had a similar argument before; IIRC you brought up something about toy languages in use in companies.
Re: Phobo's migration
On Thursday, 23 June 2016 at 08:52:06 UTC, Ola Fosheim Grøstad wrote: This is not true. Please elaborate. There are many development methodologies and most of them are not suitable for designing programming languages, including all "lean" methodologies. D is a continually improving language. If it wasn't and D2 had the same design today as it did when it was released, or it had a language committee and it proceeded at a quarter of the speed, then D would not be nearly as popular as it is now. Design by committee usually produces subpar or bland results and is painfully slow to boot, and IIRC is one of the reasons Walter created D: to get away from the C++ standards committee.
Re: Phobo's migration
On 6/23/16 8:31 AM, Jack Stouffer wrote: On Thursday, 23 June 2016 at 08:55:07 UTC, Ola Fosheim Grøstad wrote: The DMD developers refuse to use Phobos in the D compiler, so Phobos is obviously not production ready. Ridiculous. One data point does not make a trend. Phobos is "obviously" production ready as it's being used in production at many companies https://dlang.org/orgs-using-d.html So companies are willing to build their infrastructure on D because they have determined that it's ready for there uses. But we've had a similar argument before; IIRC you brought up something about toy languages in use in companies. I don't mean this as disproof, but many companies are not using Phobos, even though they use D. Sociomantic definitely does not (they use D1 currently, and their D2 port probably uses a port of their library as well), and I believe Weka.io does not either. Again, this isn't proof that Phobos isn't production ready. It depends on what you need, and whether Phobos satisfies that need. -Steve
Re: inout and opApply
On 6/21/16 5:19 PM, Timon Gehr wrote: The problem here is that both variants make sense depending on context and there is no syntax to distinguish between them. This proposal interacts in a weird way with IFTI. I know you are probably right, but can you explain maybe via an example what you mean? I'm not understanding your point. -Steve
Re: inout and opApply
On 6/22/16 6:28 AM, Kagamin wrote: On Monday, 20 June 2016 at 15:09:22 UTC, Steven Schveighoffer wrote: int opApply(scope int delegate(ref inout T value) dg) inout The inout inside the delegate is wrapped just like the inout of the 'this' parameter. effectively, this becomes equivalent to several function signatures: int opApply(scope int delegate(ref T value) dg) int opApply(scope int delegate(ref const T value) dg) const int opApply(scope int delegate(ref immutable T value) dg) immutable int opApply(scope int delegate(ref inout T value) dg) inout AFAIK, there was a bugzilla issue for it. Wasn't it implemented? No, this hasn't happened yet. There may be a bugzilla issue for it, I'm not sure. -Steve
Re: Proposed Enhancement: Deprecate std.conv.text With 0 Arguments
On 6/22/16 1:12 PM, Jack Stouffer wrote: On Wednesday, 22 June 2016 at 17:04:54 UTC, Meta wrote: Intentional or not, I don't see any downside to disallowing calling text with 0 args (aside from backwards-compatibility concerns). It doesn't even return anything useful, just null. Well, the idea is that the function is a string constructor so it returns d/w/string.init with nothing passed in. I think it's worthy of a change. if(something); used to be valid code. But it's more likely to be an erroneous semi-colon. Making this an error was a huge win. Same thing with text with no args. You're actually better off using "" or string.init. -Steve
Re: Phobo's migration
On Thu, Jun 23, 2016 at 08:57:47AM -0400, Steven Schveighoffer via Digitalmars-d wrote: > On 6/23/16 8:31 AM, Jack Stouffer wrote: [...] > > Phobos is "obviously" production ready as it's being used in > > production at many companies https://dlang.org/orgs-using-d.html > > > > So companies are willing to build their infrastructure on D because > > they have determined that it's ready for there uses. But we've had a > > similar argument before; IIRC you brought up something about toy > > languages in use in companies. > > I don't mean this as disproof, but many companies are not using > Phobos, even though they use D. > > Sociomantic definitely does not (they use D1 currently, and their D2 > port probably uses a port of their library as well), and I believe > Weka.io does not either. AFAIK, the reason Sociomantic doesn't use Phobos is because their codebase started with D1, and D1 Phobos was pretty sucky. Of course, now that they have built their own library, it's hard to switch to D2 Phobos, because the current Phobos has quite a different design from before and would entail too big of a code change. > Again, this isn't proof that Phobos isn't production ready. It depends > on what you need, and whether Phobos satisfies that need. [...] Just out of curiosity, do we know which companies are definitively using Phobos in production? I do use Phobos extensively in my own projects, but currently none are "production" projects. (Mainly because there is a lot of resistance in my day job against anything that isn't plain old C. Sigh.) Most of Phobos is actually quite handy, though the older, crufty modules are annoying (like std.xml, std.json, that badly need an up-to-date replacement). T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: Is dmd fast?
Or on linux use ld.gold instead of ld.bfd. Using .so instead of .a has another problem with speed. Application link against static phobos lib is much faster than against dynamic version. Dne 22.6.2016 v 21:33 ketmar via Digitalmars-d napsal(a): On Wednesday, 22 June 2016 at 19:25:13 UTC, Jack Stouffer wrote: On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote: You methodology is flawed. You are essentially measuring link time against the standard lib. As someone else in the thread alluded to, people don't care about the nuance, and it's not particularly important. Linking is part of the compilation process that people have to wait for before their program can run. So if linking is slow, then compilation is slow. you can dramatically decrease linking times by switching from libphobos2.a to libphobos2.so.
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote: FWIW, this thread has inspired me to begin work on a project I've titled 'The DUB Handbook'. I've been meaning to write some tutorials about DUB (among other things) for learningd.org, but I think a detailed guide would be a more worthwhile project to pursue. My intention with the text is to provide a detailed description of every dub command and configuration directive, along with examples of how to use them in both JSON and SDLang formats. I've spent an hour getting it set up today (I'm using gitbook) and expect to be working on it over the next several weeks. When it's ready for feedback, I'll make it publicly available and announce it here in the forums. I plan to release it under a CC license. Like I said, thanks for clearing things up. But I have to say that more detailed descriptions of commands is not what I had in mind. What are the best coding practices and why? I obviously haven't started using dub yet, so I won't be able to judge whether a code example is merely adequate or very robust. For example, why subpackages? It's in there for a reason; what situations call for subpackages? Why use -ddoxFilterArgs? When & how to static link? What dub-based project does a good job building for multiple platforms? From what's been discussed, I should always specify version number. Is there some best practice for flagging when a change to dependencies breaks your code? I would create a build type that lists the latest version of each dependency & run unittests. Is there a better way that someone is using in the field? Right now, I'm going around trying to steal the best coding practices, and I only want to steal from the best.
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote: My intention with the text is to provide a detailed description of every dub command and configuration directive, along with examples of how to use them in both JSON and SDLang formats. Yes, this is a good idea. It took me most of a day of trying to wrestle my project into a dub-compatible state and I honestly ended up giving up because my old Makefile is shorter, faster, and much easier to understand. (IIRC, the last straw was realising dub doesn't seem to have a good answer to Make targets, so building my library test samples was... impossible? Or at least completely obtuse.) I would request that you especially look for common build idioms and how to represent them in dub, because I'm apparently not the only one who thinks it's not obvious. -Wyatt
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 13:31:37 UTC, Guido wrote: But I have to say that more detailed descriptions of commands is not what I had in mind. What are the best coding practices and why? I obviously haven't started using dub yet, so I won't be able to judge whether a code example is merely adequate or very robust. For example, why subpackages? It's in there for a reason; what situations call for subpackages? Why use -ddoxFilterArgs? When & how to static link? What dub-based project does a good job building for multiple platforms? From what's been discussed, I should always specify version number. Is there some best practice for flagging when a change to dependencies breaks your code? I would create a build type that lists the latest version of each dependency & run unittests. Is there a better way that someone is using in the field? It wouldn't be much of a handbook if it didn't cover usage. Of course I will give examples, with tips based on how I use it and any I can gather from other users. Once I make it available for feedback, feel free to suggest anything you feel is missing.
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 13:33:03 UTC, Wyatt wrote: Yes, this is a good idea. It took me most of a day of trying to wrestle my project into a dub-compatible state and I honestly ended up giving up because my old Makefile is shorter, faster, and much easier to understand. (IIRC, the last straw was realising dub doesn't seem to have a good answer to Make targets, so building my library test samples was... impossible? Or at least completely obtuse.) Makefiles that are easier to understand? Ugh. I hate Makefiles with a passion. For me, DUB is so much more intuitive. Testing a library as you develop it is straightforward. I'll certainly cover that. I'm not sure what you mean about the make targets, though. DUB does have configurations, which are approximately the same thing. I would request that you especially look for common build idioms and how to represent them in dub, because I'm apparently not the only one who thinks it's not obvious. Sure, I'll do what I can.
Re: Is dmd fast?
On 06/23/2016 03:14 AM, Nordlöw wrote: On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote: You methodology is flawed. You are essentially measuring link time against the standard lib. If you're sitting on Linux make sure that you're using the GNU gold linker (`ld.gold`) by default (`ld`). On Ubuntu/Debian you should use sudo update-alternatives --config ld to configure this. The GNU gold linker should be the default on newer distributions. Is there a way to tell? Thanks! -- Andrei
Re: Results of Rust Survey 2016
On Thursday, 23 June 2016 at 11:25:46 UTC, qznc wrote: Now that Python has won over Ruby [0], it is the dominant scripting language. [0] https://www.google.com/trends/explore#q=python%20language%2C%20ruby%20language&cmpt=q&tz=Etc%2FGMT-2 Tried to add javascript to the chart, but got a strange result.
Re: Is dmd fast?
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu wrote: The GNU gold linker should be the default on newer distributions. Is there a way to tell? Thanks! -- Andrei it's not something dmd should enforce: it is the system setting under user control. there may be many various reasons to choose one or another linker, and in terms of interoperability it's better to stick with what system provides. as of the linker itsef, on most systems /usr/bin/ld is just a symling to either ld.bfd or ld.gold. we can include some notion in DMD documentation regarding to that.
Re: Is dmd fast?
On Thursday, 23 June 2016 at 13:32:35 UTC, Daniel Kozak wrote: Or on linux use ld.gold instead of ld.bfd. Using .so instead of .a has another problem with speed. Application link against static phobos lib is much faster than against dynamic version. either i didn't understood you right, or... my tests shows that ld.gold is indeed faster than ld.bfd (as it should be), but linking against libphobos2.so is still faster in both linkers than linking against libphobos2.a. it is ~100 ms faster, for both linkers. and if you meant that resulting application speed is different... tbh, i didn't noticed that at all. i did no benchmarks, but i have videogame engine, for example, and sound engine with pure D vorbis decoding, and some other apps, and never noticed any significant speed/CPU load difference between .a and .so versions.
Re: Phobo's migration
On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer wrote: I don't mean this as disproof, but many companies are not using Phobos, even though they use D. Sociomantic definitely does not (they use D1 currently, and their D2 port probably uses a port of their library as well), and I believe Weka.io does not either. Again, this isn't proof that Phobos isn't production ready. It depends on what you need, and whether Phobos satisfies that need. AFAIK the all of the companies on that page I linked use Phobos other than Weka and Sociomantic. So, that includes AdRoll and Facebook as companies who use Phobos.
Re: Phobo's migration
On Thursday, 23 June 2016 at 08:52:06 UTC, Ola Fosheim Grøstad wrote: Honest question: have you ever looked into Kaizen and lean management https://en.wikipedia.org/wiki/Kaizen? Because stopping everything in Phobos and waiting for "breakthroughs" is a dead on arrival plan. A continuous improvement process is much more viable, realistic, and likely to produce good results. This is not true. There are many development methodologies and most of them are not suitable for designing programming languages, including all "lean" methodologies. Kaizen just means continuous improvement. My Dad is an industrial engineer and talked about it all the time growing up. I really can't even fathom why anyone would be opposed to it... Lean is a broader concept and may not necessarily be a good fit.
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 01:43:32 UTC, Mike Parker wrote: On Wednesday, 22 June 2016 at 19:20:30 UTC, jmh530 wrote: I will touch dub, but I still felt like shouting "well then why doesn't the next edition of Learning D just tell people to look at some D source code and figure it out" when I saw that... What are you referring to? My point was that I don't consider this advice for everyone. I already know how to use dub. I recommend improving the docs so that someone else doesn't have the pain points that I had when I was trying to figure it out. You had recommended looking through json/sdl files from existing projects to learn how to use dub properly. If someone took this advice for learning D, it would be to look at source code in random projects to try to understand the language. I've got your Learning D book on my bookshelf. It doesn't just have one line that says, hey just look at some source code and figure it out. It breaks things apart into small examples so that you can easily process each part. Then pitch in! I put a few changes I would make to the docs on this thread.
Re: Examples of dub use needed
On Thursday, 23 June 2016 at 15:03:20 UTC, jmh530 wrote:
You had recommended looking through json/sdl files from
existing projects to learn how to use dub properly. If someone
took this advice for learning D, it would be to look at source
code in random projects to try to understand the language. I've
got your Learning D book on my bookshelf. It doesn't just have
one line that says, hey just look at some source code and
figure it out. It breaks things apart into small examples so
that you can easily process each part.
I mentioned it as one of *six* resources. That does not at all
imply that I was suggesting it be the only way to learn DUB. You
yourself said in a subsequent post that you would like to see
more examples. What better examples than real world projects?
Checking out open source projects has always been a valuable way
to learn different aspects of software development ('Use the
source, Luke' is a common expression), including languages, but
of course it isn't the only way.
named args
http://melpon.org/wandbox/permlink/u8lpOZ9owC7QXfa3
hi, that code is based on ideas and code from this[1] thread.
some examples:
// named and in order
args!(fun, a=>6, b=>65, s=>"test", f=>1.4);
// named and out of order
args!(fun, b=>65, f=>1.4, s=>"test", a=>6);
// unnamed and in order
args!(fun, 6, 65, "test", 1.4);
// mixed and out of order
args!(fun, b=>65, 1.4, 6, "test");
// with defaults
args!(fun, 6, 65);
args!(fun, s=>"some text", 6);
// setting member variables
auto foo = new Foo().set!(my => 13, ms => "Foo", mx => 4, mf =>
1.6);
// calling static member functions
args!(Foo.print, s=>foo.ms, f=>foo.mf, y=>foo.my, x=>foo.mx);
// calling member functions
foo.args!(foo.someFun, 4, x=>6, "test", f=>1.99);
foo.args!("someFun", 4, x=>6, "test", f=>1.99);
i currently don't have much time right now so havent done alot of
tests, some issues
properly handling overloads,
calling special methods e.g. constructors, opCall
and probably more
[1]
http://forum.dlang.org/thread/awjuoemsnmxbfgzhg...@forum.dlang.org
Re: Phobo's migration
On 06/23/2016 04:04 PM, H. S. Teoh via Digitalmars-d wrote: >> Sociomantic definitely does not (they use D1 currently, and their D2 >> port probably uses a port of their library as well), and I believe >> Weka.io does not either. > > AFAIK, the reason Sociomantic doesn't use Phobos is because their > codebase started with D1, and D1 Phobos was pretty sucky. Of course, now > that they have built their own library, it's hard to switch to D2 > Phobos, because the current Phobos has quite a different design from > before and would entail too big of a code change. There are quite some issues with Phobos design decisions on its own that make it hard to use in our code base. One typical example is allocating new exception instances - it is illegal in our code as we always reuse them (and ban chaining of exceptions instead). It is still not decided if we are even going to try to switch to Phobos at all for main projects - not because our tango based code is really better (there is considerable amount of old-fashioned legacy there) but because it is under full control and pushing for even a smallest architectural change in Phobos is often larger effort than just rewriting the stuff completely. That said, I don't think the Phobos really should be (or even can be!) "production ready" in that sense. It is general purpose library and a common ground for buildin some quick prototypes. And going for more specialized domains tends to require sacrifices for everyone else.
Re: Phobo's migration
On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer wrote: […] I believe Weka.io does not [use Phobos] either. Weka actually uses Phobos quite liberally – `fgrep -rI "import std." weka` yields several thousand results (I'm sure Liran will be happy to share more details). It's just that there are also quite a few areas where they need more than Phobos currently offers. Examples would be advanced data structures/containers or workarounds allowing the Phobos algorithms to be used without GC-allocating closures for the predicate alias parameters. — David
Re: Phobo's migration
On Wednesday, 22 June 2016 at 18:25:51 UTC, jmh530 wrote: On Wednesday, 22 June 2016 at 17:55:11 UTC, Joerg Joergonson wrote: Have you every used .NET considerably? You're comparing D to something created and maintained by one of the largest software companies in the world... Sounds like a good model to follow.
Please rid me of this goto
So I was looking for an efficient exponentiation implementation, and http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at page 54. Stepanov's solution, however, duplicates code, so I eliminated it: https://dpaste.dzfl.pl/e53acb41885a The cost is the use of one goto. Can the code be restructured to not need it? Thanks, Andrei
Re: Phobo's migration
On Thursday, 23 June 2016 at 14:34:44 UTC, Jack Stouffer wrote: On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer wrote: I don't mean this as disproof, but many companies are not using Phobos, even though they use D. Sociomantic definitely does not (they use D1 currently, and their D2 port probably uses a port of their library as well), and I believe Weka.io does not either. Again, this isn't proof that Phobos isn't production ready. It depends on what you need, and whether Phobos satisfies that need. AFAIK the all of the companies on that page I linked use Phobos other than Weka and Sociomantic. So, that includes AdRoll and Facebook as companies who use Phobos. So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. Phobos clearly is hacked together shit... maybe not all, but at least some. Searching for stuff in phobos continually brings up posts about having to fix X in phobos or replace Y because of reason Z. It's clear that individuals all added their own thing to phobos, all different. You have different people taking the reins creating their version of god with no real agreement from the get go what the whole point of it all is. It's known as cobblestone, and it's not that way to build lasting structures on. You obviously have some personal reason why you chose to ignore these facts. I'm only suggesting that a better design can be had, and this is de facto. Phobos isn't perfect. Yes, .NET has MS behind it. But since you haven't used it you have no clue how well designed it is. D and phobo's will never achieve millions of lines of code apps because it can't handle it. Hence, most apps in D are 10's of thousands of lines at most. They tend to be simple, more utility or special purpose apps, a few games, or just apps that don't require much effort. Their is a fundamental reason why D hasn't taken off, given that the language design itself is better than C\C++(which is why almost all of us are here). But admitting that D is very unbalanced compared to real world language(C\C++\C#\Java\etc) is the first step to recovery. The D language was designed well(was this solely done by Walter?). It might not be perfect but its better than anything else I've seen(and most here would have similar statements?)... but when it comes to the stuff that actually makes the language do useful things, it is lacking compared to everything else worth considering. Now why is it so unbalanced? If D had a better tooling, a truly STANDARD library, an IDE, a GUI lib, etc all on par with it's language capabilities, probably the only people not using D in this world would be Bruce Jenner... and that's only because he's spending all his time trying to find his penis. I don't think any of us here have 50 years to see all this stuff actually happen. I'm definitely not going to wait around that long. At some point, The D "community" has to get it's shit together and start making real decisions about how to proceed in to the future. That requires tough decisions and real work... it requires someone with a visions, until then everything will just be cobbled together... and at some point will fall apart. Why do you not see the blatant discrepancy between the D language and everything else about D? Do you think that everything else is truly up to par with the language? What use is a the fastest engine in the world if it takes a certain special fuel that no one has invented yet? (It has a ton of use but we have to stop putting gasoline in it and invent the fuel it needs to work optimally)
Re: Is dmd fast?
On 06/23/2016 10:36 AM, ketmar wrote: as of the linker itsef, on most systems /usr/bin/ld is just a symling to either ld.bfd or ld.gold. we can include some notion in DMD documentation regarding to that. On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei
Re: Is dmd fast?
On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu wrote: On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei `ld --version` should clear that up. ;) — David
Re: Is dmd fast?
Dne 23.6.2016 v 16:39 ketmar via Digitalmars-d napsal(a):
On Thursday, 23 June 2016 at 13:32:35 UTC, Daniel Kozak wrote:
Or on linux use ld.gold instead of ld.bfd. Using .so instead of .a
has another problem with speed. Application link against static
phobos lib is much faster than against dynamic version.
either i didn't understood you right, or... my tests shows that
ld.gold is indeed faster than ld.bfd (as it should be), but linking
against libphobos2.so is still faster in both linkers than linking
against libphobos2.a. it is ~100 ms faster, for both linkers.
and if you meant that resulting application speed is different... tbh,
i didn't noticed that at all. i did no benchmarks, but i have
videogame engine, for example, and sound engine with pure D vorbis
decoding, and some other apps, and never noticed any significant
speed/CPU load difference between .a and .so versions.
Yes I was speaking about application speed or runtime overhead. Mainly
about one shot scripts something like this:
//a.d
import std.stdio: writeln;
void main() {
writeln("Ahoj svete");
}
[kozzi@samuel ~]$ dmd -defaultlib=libphobos2.so a.d
[kozzi@samuel ~]$ time for t in {1..1000}; do ./a; done > /dev/null
real0m7.187s
user0m4.470s
sys0m0.943s
[kozzi@samuel ~]$ dmd -defaultlib=libphobos2.a a.d
[kozzi@samuel ~]$ time for t in {1..1000}; do ./a; done > /dev/null
real0m1.716s
user0m0.047s
sys0m0.323s
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 01:22:55PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> So I was looking for an efficient exponentiation implementation, and
> http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting
> at page 54. Stepanov's solution, however, duplicates code, so I
> eliminated it:
>
> https://dpaste.dzfl.pl/e53acb41885a
>
> The cost is the use of one goto. Can the code be restructured to not
> need it?
[...]
I don't understand why that goto is necessary. Or, indeed, why a nested
loop is needed at all. Why can't it be written like this?:
outer: for (;;)
{
if (e % 2 != 0)
{
r = mul(r, b, overflow);
if (e == 1) return r;
}
b = mul(b, b, overflow);
e /= 2;
}
AFAICT, the two possible code paths through the loops are the same. Am
I missing something??
T
--
Winners never quit, quitters never win. But those who never quit AND never win
are idiots.
Re: Is dmd fast?
Dne 23.6.2016 v 19:24 Andrei Alexandrescu via Digitalmars-d napsal(a): On 06/23/2016 10:36 AM, ketmar wrote: as of the linker itsef, on most systems /usr/bin/ld is just a symling to either ld.bfd or ld.gold. we can include some notion in DMD documentation regarding to that. On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei [kozzi@samuel ~]$ ld -v GNU ld (GNU Binutils) 2.26.0.20160501 [kozzi@samuel ~]$ ld.gold -v GNU gold (GNU Binutils 2.26.0.20160501) 1.11
Re: Please rid me of this goto
// Loop invariant: r * (b ^^ e) is the actual result
for (;;)
{
if (e % 2 != 0)
{
r = mul(r, b, overflow);
if (e == 1) return r;
}
b = mul(b, b, overflow);
e /= 2;
}
?
Re: Please rid me of this goto
On 6/23/16 1:22 PM, Andrei Alexandrescu wrote:
So I was looking for an efficient exponentiation implementation, and
http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at
page 54. Stepanov's solution, however, duplicates code, so I eliminated it:
https://dpaste.dzfl.pl/e53acb41885a
The cost is the use of one goto. Can the code be restructured to not
need it?
Why is this not the same?
for(;;) // previously outer:
{
if (e % 2 != 0)
{
r = mul(r, b, overflow);
if (e == 1) return r;
}
b = mul(b, b, overflow);
e /= 2;
}
-Steve
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 17:22:55 UTC, Andrei Alexandrescu
wrote:
So I was looking for an efficient exponentiation
implementation, and http://www.stepanovpapers.com/PAM.pdf has a
nice discussion starting at page 54. Stepanov's solution,
however, duplicates code, so I eliminated it:
https://dpaste.dzfl.pl/e53acb41885a
The cost is the use of one goto. Can the code be restructured
to not need it?
Thanks,
Andrei
The inner loop is not a loop, so that's not a problem:
// Loop invariant: r * (b ^^ e) is the actual result
while(true) {
if (e % 2 != 0) {
r = mul(r, b, overflow);
if (e == 1) return r;
}
b = mul(b, b, overflow);
e /= 2;
}
Re: Phobo's migration
On 6/23/16 1:24 PM, Joerg Joergonson wrote: On Thursday, 23 June 2016 at 14:34:44 UTC, Jack Stouffer wrote: On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer wrote: I don't mean this as disproof, but many companies are not using Phobos, even though they use D. Sociomantic definitely does not (they use D1 currently, and their D2 port probably uses a port of their library as well), and I believe Weka.io does not either. Again, this isn't proof that Phobos isn't production ready. It depends on what you need, and whether Phobos satisfies that need. AFAIK the all of the companies on that page I linked use Phobos other than Weka and Sociomantic. So, that includes AdRoll and Facebook as companies who use Phobos. So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. Phobos clearly is hacked together shit... I look forward to Joerg's non-shit phobos implementation. Do you have an ETA for it? -Steve
Re: Phobo's migration
On Thursday, 23 June 2016 at 17:48:40 UTC, Steven Schveighoffer wrote: On 6/23/16 1:24 PM, Joerg Joergonson wrote: On Thursday, 23 June 2016 at 14:34:44 UTC, Jack Stouffer wrote: On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer wrote: [...] AFAIK the all of the companies on that page I linked use Phobos other than Weka and Sociomantic. So, that includes AdRoll and Facebook as companies who use Phobos. So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. Phobos clearly is hacked together shit... I look forward to Joerg's non-shit phobos implementation. Do you have an ETA for it? -Steve I know right!!! He sounds like an expert. I am just hoping he fixes D's casting as well.
Re: Is dmd fast?
On 06/23/2016 01:33 PM, David Nadlinger wrote: On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu wrote: On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei `ld --version` should clear that up. ;) GNU ld (GNU Binutils for Ubuntu) 2.26 So how do I get and install gold? Thanks, Andrei
Re: Is dmd fast?
On Thursday, 23 June 2016 at 17:39:45 UTC, Daniel Kozak wrote:
[kozzi@samuel ~]$ dmd -defaultlib=libphobos2.so a.d
[kozzi@samuel ~]$ time for t in {1..1000}; do ./a; done >
/dev/null
real0m7.187s
user0m4.470s
sys0m0.943s
[kozzi@samuel ~]$ dmd -defaultlib=libphobos2.a a.d
[kozzi@samuel ~]$ time for t in {1..1000}; do ./a; done >
/dev/null
real0m1.716s
user0m0.047s
sys0m0.323s
yep, you are right. on my tests .a took 0.695 total, but .so took
4.908 total.
not really matters for one-shot scripts, but... i didn't knew
that the difference is SO huge. thank you for pointing that.
Re: Please rid me of this goto
On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: I don't understand why that goto is necessary. Eh, thank you all who set me straight! I've been in my head for too long. So where is the current implementation of "^^"? If it's not as fast as this, we should replace it. -- Andrei
Re: Phobo's migration
On Thursday, 23 June 2016 at 17:24:23 UTC, Joerg Joergonson wrote: On Thursday, 23 June 2016 at 14:34:44 UTC, Jack Stouffer wrote: [...] So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. [...] What is this shit? There is a to-do list to improve Phobos posted by Walter, use that and do things. Suggest new things to be added. Be a human being. Otherwise, please go be happy with .net!
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 18:05:07 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: I don't understand why that goto is necessary. Eh, thank you all who set me straight! I've been in my head for too long. So where is the current implementation of "^^"? If it's not as fast as this, we should replace it. -- Andrei It should be in constfold ... Apparently it's in the optimizer as well :)
Re: Is dmd fast?
On Thursday, 23 June 2016 at 17:57:33 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:33 PM, David Nadlinger wrote: On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu wrote: On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei `ld --version` should clear that up. ;) GNU ld (GNU Binutils for Ubuntu) 2.26 So how do I get and install gold? Thanks, Andrei Martin covered it here: https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html
Re: Is dmd fast?
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu wrote: On 06/23/2016 03:14 AM, Nordlöw wrote: On Wednesday, 22 June 2016 at 19:20:42 UTC, deadalnix wrote: You methodology is flawed. You are essentially measuring link time against the standard lib. If you're sitting on Linux make sure that you're using the GNU gold linker (`ld.gold`) by default (`ld`). On Ubuntu/Debian you should use sudo update-alternatives --config ld to configure this. The GNU gold linker should be the default on newer distributions. Is there a way to tell? Thanks! -- Andrei ld --version
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 02:05:07PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: > > I don't understand why that goto is necessary. > > Eh, thank you all who set me straight! I've been in my head for too > long. So where is the current implementation of "^^"? AFAIK, std.math. (Which leads to questions about compiler dependency on Phobos, but let's not derail this discussion, which is something that can add immediate value, to another dreaded philosophical discussion of questionable consequences. :-P) T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: Is dmd fast?
On Thursday, 23 June 2016 at 14:28:08 UTC, Andrei Alexandrescu wrote: Is there a way to tell? Thanks! -- Andrei ld --version I presume.
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 18:20:00 UTC, H. S. Teoh wrote:
On Thu, Jun 23, 2016 at 02:05:07PM -0400, Andrei Alexandrescu
via Digitalmars-d wrote:
On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote:
> I don't understand why that goto is necessary.
Eh, thank you all who set me straight! I've been in my head
for too long. So where is the current implementation of "^^"?
AFAIK, std.math.
You're thinking of pow in std.math. I don't see opBinary!("^^")
anywhere in there. I only see ^^ in comments.
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 18:05:07 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: I don't understand why that goto is necessary. Eh, thank you all who set me straight! I've been in my head for too long. So where is the current implementation of "^^"? If it's not as fast as this, we should replace it. -- Andrei ^^ seems to be lowered here https://github.com/dlang/dmd/blob/9903aba3b1d39bf499a54edbc81c7d9f08711f3e/src/constfold.d#L506 and std.math.pow is defined here: https://github.com/dlang/phobos/blob/master/std/math.d#L6028 However you should test how it performs against the LLVM intrinsics available in LDC, e.g.: llvm.intrinsincs.llvm_pow and llvm_powi (i = integer).
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 06:35:23PM +, jmh530 via Digitalmars-d wrote:
> On Thursday, 23 June 2016 at 18:20:00 UTC, H. S. Teoh wrote:
> > On Thu, Jun 23, 2016 at 02:05:07PM -0400, Andrei Alexandrescu via
> > Digitalmars-d wrote:
> > > On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote:
> > > > I don't understand why that goto is necessary.
> > >
> > > Eh, thank you all who set me straight! I've been in my head for
> > > too long. So where is the current implementation of "^^"?
> >
> > AFAIK, std.math.
> >
>
> You're thinking of pow in std.math. I don't see opBinary!("^^")
> anywhere in there. I only see ^^ in comments.
The compiler lowers ^^ to std.math.pow. A decision which has sparked
some debate in the past.
T
--
"No, John. I want formats that are actually useful, rather than
over-featured megaliths that address all questions by piling on
ridiculous internal links in forms which are hideously over-complex." --
Simon St. Laurent on xml-dev
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 18:35:23 UTC, jmh530 wrote:
You're thinking of pow in std.math. I don't see opBinary!("^^")
anywhere in there. I only see ^^ in comments.
the "^^" is very special, 'cause it is the one and only thing
that compiler recognizes as "function call" in expression
parsing, and generates call to std.math.pow. a freakin' wart.
Re: Phobo's migration
On Thursday, 23 June 2016 at 17:24:23 UTC, Joerg Joergonson wrote: So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. It's not a complete list and anyone with half a brain would be able to surmise that. E.g. the company I work for uses D but there's no brand recognition there so there's no reason to include it. Phobos clearly is hacked together shit You keep saying "clearly" and "obviously". What you actually mean to say is "in my opinion". You still have yet to articulate what YOUR ACTUAL PROBLEM is. If you have substantive criticisms, enhancement requests are always welcome at http://issues.dlang.org maybe not all, but at least some. Searching for stuff in phobos continually brings up posts about having to fix X in phobos or replace Y because of reason Z. Yes, things can always be better, and in D people are not afraid to fix them. Unlike your precious C# which sacrifices usability in order to be backwards compatible with version 1.0. It's clear that individuals all added their own thing to phobos, all different. Maybe we should rely on a single person to design everything, or we should have a committee. Or maybe we shouldn't do those things because they either rely on a single point of failure and are anti contributions or they're slow as dog shit. You have different people taking the reins creating their version of god with no real agreement from the get go what the whole point of it all is. This is not the case. Phobos additions go through a thorough review process. You obviously have some personal reason why you chose to ignore these facts. Yes, for some reason I've become personally invested in D. No wait, that's stupid because I'm a programmer and I care about using the best tools for the job. I'm only suggesting that a better design can be had, and this is de facto. Then actually suggest something instead of saying "Make it better guys. Come on, can't you just make it better. Don't expect me to tell you what 'better' is, or how it could be implemented, just make it better." Phobos isn't perfect. Never said it was. D and phobo's will never achieve millions of lines of code apps because it can't handle it. Unsubstantiated claim. Hence, most apps in D are 10's of thousands of lines at most. Weka's code is 200k+. DMD has 120K lines of D. They tend to be simple, more utility or special purpose apps, a few games, or just apps that don't require much effort. Unsubstantiated claim. But admitting that D is very unbalanced compared to real world language(C\C++\C#\Java\etc) is the first step to recovery. Give an example. but when it comes to the stuff that actually makes the language do useful things, it is lacking compared to everything else worth considering. Now why is it so unbalanced? Give an example. If D had a better tooling, a truly STANDARD library, an IDE, a GUI lib, etc all on par with it's language capabilities, Give an example of how the current ones are lacking. Bruce Jenner... and that's only because he's spending all his time trying to find his penis. Uncalled for. We do not condone personal attacks or bigotry here. At some point, The D "community" has to get it's shit together and start making real decisions about how to proceed in to the future. How about you start now? What would you like to change? Why do you not see the blatant discrepancy between the D language and everything else about D? Give an example. Do you think that everything else is truly up to par with the language? Mostly, yeah.
Re: Please rid me of this goto
On 23.06.2016 19:22, Andrei Alexandrescu wrote: So I was looking for an efficient exponentiation implementation, and http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at page 54. Stepanov's solution, however, duplicates code, so I eliminated it: https://dpaste.dzfl.pl/e53acb41885a The cost is the use of one goto. Can the code be restructured to not need it? Thanks, Andrei Unrelated comment: 0^^0 should not overflow.
Re: Phobo's migration
On Thursday, 23 June 2016 at 17:24:23 UTC, Joerg Joergonson wrote: So, 10 companies are using phobos!! That's amazing, sure shows how great it is! I wonder if they use use import std.stdio; or actually USE phobos. Phobos clearly is hacked together shit... maybe not all, but at least some. This is the result of many different people doing small incremental changes over time, and I think it's fairly normal for a quickly growing OSS project like D. Yes, you can argue over whether D is "quickly growing" or not, but it cannot be denied that the D community has grown much larger than it was even 2 years ago. A lot of the Java standard library is a hacked-together, inconsistent mish-mash as well, and it's going to be like that forever because of strict backward-compatibility requirements. That doesn't stop Java from being the most-used language on the planet. D will get there eventually but these things take time and initiative, especially without a large financial backer like Oracle. Yes, .NET has MS behind it. But since you haven't used it you have no clue how well designed it is. D and phobo's will never achieve millions of lines of code apps because it can't handle it. Hence, most apps in D are 10's of thousands of lines at most. They tend to be simple, more utility or special purpose apps, a few games, or just apps that don't require much effort. Weka.io was mentioned in this thread, and if I recall correctly at DConf 2016 Liran said that their codebase is roughly 200k lines. It's not in the millions yet, but it's certainly more than a toy project. I'm guessing Sociomantic's codebase is similar in size if not larger. Their is a fundamental reason why D hasn't taken off, given that the language design itself is better than C\C++(which is why almost all of us are here). The fundamental reason that D hasn't taken off yet is money, plain and simple. If D had a better tooling, a truly STANDARD library, an IDE, a GUI lib, etc all on par with it's language capabilities, probably the only people not using D in this world would be Bruce Jenner... and that's only because he's spending all his time trying to find his penis. Has D recently become popular on 4chan or something? Why bother making a stupid dick joke other than to stir shit up? At some point, The D "community" has to get it's shit together and start making real decisions about how to proceed in to the future. That requires tough decisions and real work... it requires someone with a visions, until then everything will just be cobbled together... and at some point will fall apart. Lurk more and you'll see that Walter and Andrei *are* making those tough decisions. Not just the small stuff like auto-decoding but big decisions like focusing on improving the @nogc experience and C++ integration. Nobody here is paid to do anything so one is limited in their ability to steer the ship. That may change in the future but for now that's how it is. Why do you not see the blatant discrepancy between the D language and everything else about D? Do you think that everything else is truly up to par with the language? What use is a the fastest engine in the world if it takes a certain special fuel that no one has invented yet? (It has a ton of use but we have to stop putting gasoline in it and invent the fuel it needs to work optimally) It'll get there eventually. Time and money are the magic words. D's had time, and now it looks like the money will gradually start to flow. Give it 2 more years and if things go smoothly, we could be an order of magnitude or more above where we are now. Sola dea fatum novit.
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 08:59:07PM +0200, Timon Gehr via Digitalmars-d wrote: [...] > Unrelated comment: 0^^0 should not overflow. Says who? http://www.askamathematician.com/2010/12/q-what-does-00-zero-raised-to-the-zeroth-power-equal-why-do-mathematicians-and-high-school-teachers-disagree/ T -- MAS = Mana Ada Sistem?
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 18:49:56 UTC, ketmar wrote:
On Thursday, 23 June 2016 at 18:35:23 UTC, jmh530 wrote:
You're thinking of pow in std.math. I don't see
opBinary!("^^") anywhere in there. I only see ^^ in comments.
the "^^" is very special, 'cause it is the one and only thing
that compiler recognizes as "function call" in expression
parsing, and generates call to std.math.pow. a freakin' wart.
It is also has different associativity, and is one of my favorite
gotcha :
| is bitwize or. || is binary or.
& is bitwize and. && is binary and.
^ is bitwize xor. ^^ is... no, never mind.
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 07:11:26PM +, deadalnix via Digitalmars-d wrote: > | is bitwize or. || is binary or. > & is bitwize and. && is binary and. > ^ is bitwize xor. ^^ is... no, never mind. binary xor is != lol
Re: inout and opApply
On 23.06.2016 14:58, Steven Schveighoffer wrote:
On 6/21/16 5:19 PM, Timon Gehr wrote:
The problem here is that both variants make sense depending on context
and there is no syntax to distinguish between them. This proposal
interacts in a weird way with IFTI.
I know you are probably right, but can you explain maybe via an example
what you mean? I'm not understanding your point.
-Steve
One might legitimately want to pass a inout delegate to some inout
function and then use the delegate on data with arbitrary mutability
qualifiers, not just inout.
The IFTI comment was about for example something like this:
struct S{
void bar(inout int){}
void foo(T)(T arg)inout{
// this looks like it can be called with any argument
arg(&bar);
}
}
void main(){
immutable(S) s;
void delegate(void delegate(inout(int))) dg = x=>x(2);
s.foo(dg); // today, this works
// with the proposed semantics, IFTI deduces
// T = void delegate(void delegate(inout(int)))
// but then cannot convert dg to a T after
// inout resolution
}
But I don't feel strongly about which of the two variants it should be.
It's weird either way, as long as there can be only one inout in scope.
Let's make the DLang Tour an awesome landing page for D newbies
Let me start with the good news: since the DLang Tour was launched by André last month, we had about 3K unique visitors and continuously have between 100-200 visitors per day. However here are the bad news: We loose about 40% of all visitors directly on the front page and we loose the majority (>70%) on the first ten pages. Our DLang Tour is the starting point for newcomers. Hence if you think in terms of Andrei's first five minutes, we loose pretty badly! We already tried to improve things a bit (slicker design, D-man on the front page), but we need your help to motivate future D-eists and inspire them! Last week we split the tour in individual Markdown files per chapter, s.t. improving the tour is only a button click away. Moreover we plan to translate the tour in multiple languages soon [1], so any help in reviewing the tour would be great. If you discover structural problems or want to share improvement ideas, don't hesitate to ping us with a Github issue ;-) Thanks for your help in making our DLang Tour an awesome landing page for D newbies! André & Seb [1] https://github.com/stonemaster/dlang-tour/issues/132 [2] https://github.com/stonemaster/dlang-tour/issues
Re: Phobo's migration
On Thursday, 23 June 2016 at 19:05:34 UTC, Meta wrote: Lurk more and you'll see that Walter and Andrei *are* making those tough decisions. If he lurked more, he would notice that threads like this pop up every few months.
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 19:24:54 UTC, via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 07:11:26PM +, deadalnix via Digitalmars-d wrote: | is bitwize or. || is binary or. & is bitwize and. && is binary and. ^ is bitwize xor. ^^ is... no, never mind. binary xor is != lol 3 != 5 is true. 3 binaryxor 5 is false.
GSoC 2016 - std.experimental.xml after a month
-- Brace yourself: a very long post is coming -- Hi, One month after the official GSoC start, I want to share with you what's in std.experimental.xml and what will hopefully be there. If you have any question/improvement or anything to say, just leave a comment here or an issue on GitHub (https://github.com/lodo1995/experimental.xml). In particular, if you think there are problems with the current structure of the project, or major flaws in the APIs, that will be very difficult to solve at a later stage, please let me know. (Walter and Andrei, I'd really appreciate your feedback here). Thank you in advance to all who will take time to read this... What is working? - Four lexers are provided to abstract different kinds of input from the other layers, providing different speed characteristics; - The parser splits the document into nodes, doing most of the hard work; - A cursor sits on top of the parser, providing an API to advance in the document and get information about the current node; it supports string interning, which can drastically lower memory consumption (given that most nodes share names and attributes); - A validating cursor is the same as a cursor, but allows the user to plug custom validators, that are executed while advancing in the input; in the future the library will provide some predefined validators to use with it; - A very simple SAX API built on top of the cursor API is the last thing added and tested; - A partial reimplementation of std.xml is there; when completed it will allow a gradual code transition. What am I working on right now? I'm trying to implement the DOM level 3 API. The API per se is not that difficult, but the infrastructure I'm building around it is a hell. In fact, I'm trying to make the DOM nodes reference counted and allocated with a custom allocator, to allow their usage in @nogc code. This is quite painful (because the DOM has lots of circular references, and "normal" reference counting does not work with them), but with enough time I will probably manage to make it work. What is planned for the near future? - When the DOM classes will be usable (even if not 100% complete) I will start working on a DOM parser to build them from the source; - DTD check and entity substitution have to be implemented, and they will (I hope) fit nicely as pluggable components for the validating cursor; - And of course some APIs to output XML. What is (incidentally) inside the repository? - Along with the DOM classes comes a wrapper that allows to allocate classes with a custom allocator and reference count them (that is, a RefCounted!T that works only for classes); - A wonderful (or maybe not) benchmark driver that benchmarks the various components with various kinds of random generated files and prints some wonderful statistics and graphs; - Needed by the benchmarking code, a simple API to collect statistical infos (average, median, deviation) from a range of measures; - Needed by the cursor API, an Interner that can intern not only strings, but any array or class. Thank you again for your time and help. Lodovico Giaretta
[OT] 0^^0
On 23.06.2016 21:04, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 08:59:07PM +0200, Timon Gehr via Digitalmars-d wrote: [...] Unrelated comment: 0^^0 should not overflow. Says who? http://www.askamathematician.com/2010/12/q-what-does-00-zero-raised-to-the-zeroth-power-equal-why-do-mathematicians-and-high-school-teachers-disagree/ ... According to your link, it is the 'Mathematician' who says that 0^^0 = 1. This should be even less controversial in computer science circles. It's the choice that works for e.g. combinatorics and type theory. http://mathforum.org/dr.math/faq/faq.0.to.0.power.html I would not want to use a power function that does not work for (0,0).
Re: Let's make the DLang Tour an awesome landing page for D newbies
On Thursday, 23 June 2016 at 19:24:49 UTC, Seb wrote: Let me start with the good news: since the DLang Tour was launched by André last month, we had about 3K unique visitors and continuously have between 100-200 visitors per day. However here are the bad news: We loose about 40% of all visitors directly on the front page and we loose the majority (>70%) on the first ten pages. Our DLang Tour is the starting point for newcomers. Hence if you think in terms of Andrei's first five minutes, we loose pretty badly! We already tried to improve things a bit (slicker design, D-man on the front page), but we need your help to motivate future D-eists and inspire them! Last week we split the tour in individual Markdown files per chapter, s.t. improving the tour is only a button click away. I don't think you're going to solve this problem with better content for the tour--since people aren't even really getting to the content. Also, losing people after 10 pages doesn't sound that bad. I wouldn't expect people to go through the whole tour in one sitting. Nonetheless there are a couple of things that make me bounce. The main one is no visible TOC. The only way to move around the tour is to go forward or backward one by one---making it hard to skip around, or understand what topics are coming up. A div on the side with all the section links would be great. Also, while the live code window in the browser is neat, it breaks up the flow of the page, and I feel like I'd usually just prefer inline un-editable text. (E.g., what are you really going to experiment with in the Hello World script here? http://tour.dlang.org/tour/en/basics/imports-and-modules) These are just my opinions, and I don't claim to be representative of the audience you want to attract. Overall, I think this is a fantastic project. Thanks to all who've been working on it!
Re: Let's make the DLang Tour an awesome landing page for D newbies
On Thursday, 23 June 2016 at 20:25:17 UTC, Carl Vogel wrote: The main one is no visible TOC. The only way to move around the tour is to go forward or backward one by one---making it hard to skip around, or understand what topics are coming up. A div on the side with all the section links would be great. Just to follow up, I realize there's the nav bar at the top. But it doesn't give the same sense of place or order as a vertical hierarchical TOC does.
Re: Please rid me of this goto
On 06/23/2016 02:37 PM, Seb wrote: On Thursday, 23 June 2016 at 18:05:07 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: I don't understand why that goto is necessary. Eh, thank you all who set me straight! I've been in my head for too long. So where is the current implementation of "^^"? If it's not as fast as this, we should replace it. -- Andrei ^^ seems to be lowered here https://github.com/dlang/dmd/blob/9903aba3b1d39bf499a54edbc81c7d9f08711f3e/src/constfold.d#L506 and std.math.pow is defined here: https://github.com/dlang/phobos/blob/master/std/math.d#L6028 I see, thanks. Both seem to be ripe for the optimized version (they do more testing than necessary). However you should test how it performs against the LLVM intrinsics available in LDC, e.g.: llvm.intrinsincs.llvm_pow and llvm_powi (i = integer). Cool! Is that a CPU operation? Andrei
Re: Please rid me of this goto
On 06/23/2016 02:59 PM, Timon Gehr wrote: On 23.06.2016 19:22, Andrei Alexandrescu wrote: So I was looking for an efficient exponentiation implementation, and http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at page 54. Stepanov's solution, however, duplicates code, so I eliminated it: https://dpaste.dzfl.pl/e53acb41885a The cost is the use of one goto. Can the code be restructured to not need it? Thanks, Andrei Unrelated comment: 0^^0 should not overflow. Why not? -- Andrei
Re: Please rid me of this goto
On 6/23/2016 10:22 AM, Andrei Alexandrescu wrote:
https://dpaste.dzfl.pl/e53acb41885a
Paste bin links are ephemeral. The code from the link:
/**
*/
int pow(int lhs, uint rhs, ref bool overflow)
{ return powImpl(lhs, rhs, overflow); }
/// ditto
long pow(long lhs, uint rhs, ref bool overflow)
{ return powImpl(lhs, rhs, overflow); }
/// ditto
uint pow(uint lhs, uint rhs, ref bool overflow)
{ return powImpl(lhs, rhs, overflow); }
/// ditto
ulong pow(ulong lhs, uint rhs, ref bool overflow)
{ return powImpl(lhs, rhs, overflow); }
// Inspiration: http://www.stepanovpapers.com/PAM.pdf
private T powImpl(T)(T b, uint e, ref bool overflow)
{
import core.checkedint : muls, mulu;
import std.traits : isUnsigned;
static if (isUnsigned!T) alias mul = mulu;
else alias mul = muls;
if (e <= 1)
{
if (e == 1) return b;
if (b == 0) overflow = true;
return 1;
}
T r = b;
assert(e > 1);
--e;
// Loop invariant: r * (b ^^ e) is the actual result
outer: for (;;)
{
if (e % 2 != 0) goto geeba;
for (;;)
{
b = mul(b, b, overflow);
e /= 2;
continue outer;
geeba:
r = mul(r, b, overflow);
if (e == 1) return r;
}
}
assert(0);
}
unittest
{
import std.stdio;
bool overflow;
foreach (uint i; 0 .. 21)
{
assert(pow(3u, i, overflow) == 3u ^^ i);
assert(!overflow);
}
assert(pow(3u, 21u, overflow) == 3u ^^ 21);
assert(overflow);
}
void main(){}
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 21:03:08 UTC, Andrei Alexandrescu wrote: However you should test how it performs against the LLVM intrinsics available in LDC, e.g.: llvm.intrinsincs.llvm_pow and llvm_powi (i = integer). Cool! Is that a CPU operation? Andrei It is going to depend on the target.
Re: Please rid me of this goto
On 23.06.2016 23:04, Andrei Alexandrescu wrote:
On 06/23/2016 02:59 PM, Timon Gehr wrote:
On 23.06.2016 19:22, Andrei Alexandrescu wrote:
So I was looking for an efficient exponentiation implementation, and
http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at
page 54. Stepanov's solution, however, duplicates code, so I
eliminated it:
https://dpaste.dzfl.pl/e53acb41885a
The cost is the use of one goto. Can the code be restructured to not
need it?
Thanks,
Andrei
Unrelated comment: 0^^0 should not overflow.
Why not? -- Andrei
Because 0^^0 = 1, and 1 is representable.
E.g. n^^m counts the number of functions from an m-set to an n-set, and
there is exactly one function from {} to {}.
Re: Let's make the DLang Tour an awesome landing page for D newbies
On 06/23/2016 12:24 PM, Seb wrote: > We already tried to improve things a bit (slicker design, D-man on the > front page), but we need your help to motivate future D-eists and > inspire them! Sorry to repeat myself: - The first navigation link says "Install D Locally". I wouldn't click that link; I just want to get a quick idea about the language, I'm not ready to install it yet. - The page numbers don't make sense: 1/4 2/4 3/4 4/4 1/19 WAT? :) ... - I would like to have the page numbers and the left-right navigation buttons on top (in addition to the ones at the bottom) - I think first few pages have too much text. The tour could give just the flavor of the language as opposed to being a convenient resource hub. But again, thank you for putting this together. It's great but can be greater. :p Ali
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 21:03:08 UTC, Andrei Alexandrescu wrote: On 06/23/2016 02:37 PM, Seb wrote: On Thursday, 23 June 2016 at 18:05:07 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:34 PM, H. S. Teoh via Digitalmars-d wrote: I don't understand why that goto is necessary. Eh, thank you all who set me straight! I've been in my head for too long. So where is the current implementation of "^^"? If it's not as fast as this, we should replace it. -- Andrei ^^ seems to be lowered here https://github.com/dlang/dmd/blob/9903aba3b1d39bf499a54edbc81c7d9f08711f3e/src/constfold.d#L506 and std.math.pow is defined here: https://github.com/dlang/phobos/blob/master/std/math.d#L6028 I see, thanks. Both seem to be ripe for the optimized version (they do more testing than necessary). However you should test how it performs against the LLVM intrinsics available in LDC, e.g.: llvm.intrinsincs.llvm_pow and llvm_powi (i = integer). Cool! Is that a CPU operation? Depends on the target http://llvm.org/docs/LangRef.html#llvm-pow-intrinsic You should definitely benchmark between compilers. I gave it a quick for floating point and integer power (see [1, 2]). Please take the numbers with _great_ care, but I hope they show the point about the importance of benchmarking between compilers ;-) Floating-point -- dmd -inline -release -O -boundscheck=off test_pow.d -ofbin/dmd/test_pow ldc -release -O3 -boundscheck=off test_pow.d -ofbin/ldc/test_pow gdc -finline-functions -frelease -O3 test_pow.d -o bin/gdc/test_pow dmd math.pow 3 secs, 463 ms, 379 μs, and 6 hnsecs ^^ 7 secs, 295 ms, 984 μs, and 3 hnsecs ldc llvm_pow 125 ms, 673 μs, and 2 hnsecs ^^6 secs, 380 ms, 104 μs, and 2 hnsecs gdc math.pow 0 secs 125 ms ^^ 2 secs 2161 ms Integer power - dmd -inline -release -O -boundscheck=off test_powi.d -ofbin/dmd/test_powi ldc -release -O3 -boundscheck=off test_powi.d -ofbin/ldc/test_powi gdc -finline-functions -frelease -O3 test_powi.d -o bin/gdc/test_powi dmd math.pow 978 ms, 961 μs, and 8 hnsecs ^^ 1 sec, 15 ms, 177 μs, and 6 hnsecs ldc math.pow 556 ms, 366 μs, and 8 hnsecs ^^ 507 ms, 3 μs, and 1 hnsec gdc math.pow 0 secs 125 ms ^^ 0 secs 42 ms [1] https://github.com/wilzbach/perf-d/blob/master/test_pow.d [2] https://github.com/wilzbach/perf-d/blob/master/test_powi.d
Re: Please rid me of this goto
Can you post codegen for each ?
Re: inout and opApply
On 6/23/16 3:20 PM, Timon Gehr wrote:
On 23.06.2016 14:58, Steven Schveighoffer wrote:
On 6/21/16 5:19 PM, Timon Gehr wrote:
The problem here is that both variants make sense depending on context
and there is no syntax to distinguish between them. This proposal
interacts in a weird way with IFTI.
I know you are probably right, but can you explain maybe via an example
what you mean? I'm not understanding your point.
One might legitimately want to pass a inout delegate to some inout
function and then use the delegate on data with arbitrary mutability
qualifiers, not just inout.
As you say, we don't have a lot of options. We only have one designation
for inout, and we must treat it the same no matter where it is.
A possible workaround is to store the inout function pointer/delegate as
a global variable. I don't like that idea at all, but it would work.
Perhaps we could find a way to mark a function parameter as not being
part of the inout wrapping, or perhaps mark it as *being* part of the
inout wrapping (to be backwards compatible). But this is a special thing
for delegates and function pointers only, since it makes no sense for
plain parameters.
The more I think about it, the more I think we need to have a clear
demarcation of when you want the inout-containing delegate to
participate in the wrapping or not. We can't eliminate existing
behavior, and without special marking, the rules are going to be ugly
and unintuitive.
The IFTI comment was about for example something like this:
struct S{
void bar(inout int){}
void foo(T)(T arg)inout{
// this looks like it can be called with any argument
arg(&bar);
}
}
void main(){
immutable(S) s;
void delegate(void delegate(inout(int))) dg = x=>x(2);
s.foo(dg); // today, this works
// with the proposed semantics, IFTI deduces
// T = void delegate(void delegate(inout(int)))
// but then cannot convert dg to a T after
// inout resolution
}
Considering the possible use cases for something like this, I think we
are better off having this limitation than not being able to use opApply
with inout.
-Steve
Re: Proposed Enhancement: Deprecate std.conv.text With 0 Arguments
On Wednesday, 22 June 2016 at 15:39:11 UTC, Meta wrote: If it is called with 0 arguments it will return null. No it will return empty string. This behaviour has caused several bugs in my code because combined with optional parens and UFCS, it is easy to accidentally call text with 0 args but have it look like passing a variable to a function. An example bug that I recently found in my code: This is a problem with optional (), not text. test takes n parameters and return a string representation of these parameters. returning an empty string when no parameters is provided is very much expected. The alternative is to add special case. And here you get into the bad design land. When some bad design is introduced it causes problems. Now there is the option to introduce more and more bad design to work around the original bad design, or adopt a principled approach. I'd rather go for #2 . if I wanted #1, I'd be using C++ or PHP, which both fit that spot better than D. When the solution to a problem is adding more special casing, you can be sure you are not moving in the right direction.
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 11:30:51PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 23.06.2016 23:04, Andrei Alexandrescu wrote:
> > On 06/23/2016 02:59 PM, Timon Gehr wrote:
> > > On 23.06.2016 19:22, Andrei Alexandrescu wrote:
> > > > So I was looking for an efficient exponentiation implementation,
> > > > and http://www.stepanovpapers.com/PAM.pdf has a nice discussion
> > > > starting at page 54. Stepanov's solution, however, duplicates
> > > > code, so I eliminated it:
> > > >
> > > > https://dpaste.dzfl.pl/e53acb41885a
> > > >
> > > > The cost is the use of one goto. Can the code be restructured to
> > > > not need it?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Andrei
> > >
> > > Unrelated comment: 0^^0 should not overflow.
> >
> > Why not? -- Andrei
>
> Because 0^^0 = 1, and 1 is representable.
>
> E.g. n^^m counts the number of functions from an m-set to an n-set,
> and there is exactly one function from {} to {}.
This argument only works for discrete sets. If n and m are reals, you'd
need a different argument.
T
--
Verbing weirds language. -- Calvin (& Hobbes)
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: This argument only works for discrete sets. If n and m are reals, you'd need a different argument. For reals, you can use limits/continuation as argument.
Re: Proposed Enhancement: Deprecate std.conv.text With 0 Arguments
On 6/23/16 6:46 PM, deadalnix wrote: On Wednesday, 22 June 2016 at 15:39:11 UTC, Meta wrote: If it is called with 0 arguments it will return null. No it will return empty string. null is an empty string. And it does return null specifically. This behaviour has caused several bugs in my code because combined with optional parens and UFCS, it is easy to accidentally call text with 0 args but have it look like passing a variable to a function. An example bug that I recently found in my code: This is a problem with optional (), not text. A valid point. But we aren't going to have this change. test takes n parameters and return a string representation of these parameters. returning an empty string when no parameters is provided is very much expected. If it has to be valid, this is what I would expect, yes. But it doesn't have to be valid. The only place I can see this being useful is generic code which itself takes a tuple. The alternative is to add special case. And here you get into the bad design land. When some bad design is introduced it causes problems. Now there is the option to introduce more and more bad design to work around the original bad design, or adopt a principled approach. I'd rather go for #2 . if I wanted #1, I'd be using C++ or PHP, which both fit that spot better than D. It's not a special case to require a minimum number of parameters. When the solution to a problem is adding more special casing, you can be sure you are not moving in the right direction. There is already a special case for zero arguments -- a whole static if branch, in fact. -Steve
Re: Please rid me of this goto
On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: > On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: > > This argument only works for discrete sets. If n and m are reals, > > you'd need a different argument. > > > > For reals, you can use limits/continuation as argument. The problem with that is that you get two different answers: lim x^y = 0 x->0 but: lim x^y = 1 y->0 So it's not clear what ought to happen when both x and y approach 0. The problem is that the 2-variable function f(x,y)=x^y has a discontinuity at (0,0). So approaching it from some directions give 1, approaching it from other directions give 0, and it's not clear why one should choose the value given by one direction above another. Mathematicians arbitrarily chose its value to be 1 based on arguments like the one Timon gave, but it's an arbitrary choice, not something that the mathematics itself suggest. T -- Try to keep an open mind, but not so open your brain falls out. -- theboz
Re: Please rid me of this goto
On 24.06.2016 00:53, H. S. Teoh via Digitalmars-d wrote:
>Because 0^^0 = 1, and 1 is representable.
>
>E.g. n^^m counts the number of functions from an m-set to an n-set,
>and there is exactly one function from {} to {}.
This argument only works for discrete sets.
No, it works for any cardinals n and m.
If n and m are reals, you'd
need a different argument.
I don't want to argue this at all. x^^0 is an empty product no matter
what set I choose x and 0 from. 0^^0 = 1 is the only reasonable
convention, and this is absolutely painfully obvious from where I stand.
What context are you using 'pow' in that would suggest otherwise?
Also, Andrei's implementation explicitly works on integers anyway.
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 22:08:20 UTC, Seb wrote:
[1] https://github.com/wilzbach/perf-d/blob/master/test_pow.d
[2] https://github.com/wilzbach/perf-d/blob/master/test_powi.d
This is a bad way to benchmark. You are essentially testing the
compiler's ability to propagate your constants into the
benchmarking loop/hoisting the code to be benchmarked out of it.
For cross-compiler tests, you should define the candidate
functions in a separate compilation units with an extern(C)
interface to inhibit any optimisations. In this case, your code
could e.g. be altered to:
---
import std.math : pow;
extern(C) long useStd(long a, long b) { return pow(a, b); }
extern(C) long useOp(long a, long b) { return a ^^ b; }
---
extern(C) long useStd(long a, long b);
extern(C) long useOp(long a, long b);
void main(string[] args)
{
import std.datetime: benchmark, Duration;
import std.stdio: writeln, writefln;
import std.conv: to;
long a = 5;
long b = 25;
long l = 0;
void f0() { l += useStd(a, b); }
void f1() { l += useOp(a, b); }
auto rs = benchmark!(f0, f1)(100_000_000);
foreach(j,r;rs)
{
version(GNU)
writefln("%d %d secs %d ms", j, r.seconds(),
r.msecs());
else
writeln(j, " ", r.to!Duration);
}
// prevent any optimization
writeln(l);
}
---
(Keeping track of the sum is of course no longer really
necessary.)
I get the following results:
---
$ gdc -finline-functions -frelease -O3 -c test1.d
$ gdc -finline-functions -frelease -O3 test.d test1.o
$ ./a.out
0 0 secs 620 ms
1 0 secs 647 ms
4939766238266722816
---
---
$ ldc2 -O3 -release -c test1.d
$ ldc2 -O3 -release test.d test1.o
$ ./test
0 418 ms, 895 μs, and 3 hnsecs
1 409 ms, 776 μs, and 1 hnsec
4939766238266722816
---
---
$ dmd -O -release -inline -c test1.d
$ dmd -O -release -inline test.d test1.o
0 637 ms, 19 μs, and 9 hnsecs
1 722 ms, 57 μs, and 8 hnsecs
4939766238266722816
---
— David
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 23:34:54 UTC, David Nadlinger wrote: I get the following results: (This is of course not intended to be a comprehensive analysis. For example, the codegen for the two functions is actually identical on GDC and LDC, the relative differences are due to measurement noise. — David)
Re: Phobo's migration
I have plenty of work that needs being done as a dependency to a GUI toolkit. So what are you going to do to contribute? Money, time?
Re: Proposed Enhancement: Deprecate std.conv.text With 0 Arguments
On Thursday, 23 June 2016 at 23:16:23 UTC, Steven Schveighoffer
wrote:
This is a problem with optional (), not text.
A valid point. But we aren't going to have this change.
Spreading the shit doesn't make it smell good.
test takes n parameters and return a string representation of
these
parameters. returning an empty string when no parameters is
provided is
very much expected.
If it has to be valid, this is what I would expect, yes. But it
doesn't have to be valid.
The only place I can see this being useful is generic code
which itself takes a tuple.
Exactly.
The alternative is to add special case. And here you get into
the bad
design land. When some bad design is introduced it causes
problems. Now
there is the option to introduce more and more bad design to
work around
the original bad design, or adopt a principled approach. I'd
rather go
for #2 . if I wanted #1, I'd be using C++ or PHP, which both
fit that
spot better than D.
It's not a special case to require a minimum number of
parameters.
You are just pushing the problem up one level. Now every template
that call text with a sequence need to do a length check (and
none will).
The very problem is that the optional () make the argumentless
thing a special case. Special cases are like cancer, they spread.
Making more argumentless thing special cases is just making the
problem worse.
But it is pushed on somebody else, so I guess that's alright...
That reminds me of https://www.youtube.com/watch?v=aI0euMFAWF8
When the solution to a problem is adding more special casing,
you can be
sure you are not moving in the right direction.
There is already a special case for zero arguments -- a whole
static if branch, in fact.
That's an implementation detail.
string test(T...)(T args) {
auto ret = "";
foreach (a; args) {
ret ~= testImpl(a);
}
return ret;
}
Or it can be seen as the bottom turtle.
string test(T...)(T args) {
static if (args.length == 0) {
return "";
} else {
return text(a[0 .. $ - 1]) ~ textImpl(a[$ - 1]);
}
}
Anyway, looking at the implementation to figure out what the
semantic should be is completely ass backward. The implementation
should match desired semantic not the other way around.
Re: Please rid me of this goto
On 24.06.2016 01:18, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: This argument only works for discrete sets. If n and m are reals, you'd need a different argument. For reals, you can use limits/continuation as argument. The problem with that is that you get two different answers: lim x^y = 0 x->0 but: lim x^y = 1 y->0 ... That makes no sense. You want lim[x->0] x^0 and lim[y->0] 0^y. So it's not clear what ought to happen when both x and y approach 0. The problem is that the 2-variable function f(x,y)=x^y has a discontinuity at (0,0). So approaching it from some directions give 1, approaching it from other directions give 0, and it's not clear why one should choose the value given by one direction above another. ... It is /perfectly/ clear. What makes you so invested in the continuity of the function 0^y? It's just not important. Mathematicians arbitrarily chose its value to be 1 based on arguments like the one Timon gave, but it's an arbitrary choice, It is absolutely /not/ arbitrary. not something that the mathematics itself suggest. ... What kind of standard is that? 'The mathematics itself' does not suggest that we do not define 2+2=5 while keeping all other function values intact either, and it is still obvious to everyone that it would be a bad idea to give such succinct notation to such an unimportant function.
Re: Please rid me of this goto
On Fri, Jun 24, 2016 at 01:33:46AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 24.06.2016 00:53, H. S. Teoh via Digitalmars-d wrote:
> > > >Because 0^^0 = 1, and 1 is representable.
> > > >
> > > >E.g. n^^m counts the number of functions from an m-set to an n-set,
> > > >and there is exactly one function from {} to {}.
> > This argument only works for discrete sets.
>
> No, it works for any cardinals n and m.
It doesn't. What is the meaning of m-set and n-set when m and n are
real numbers? How many elements are in a pi-set? How many functions
are there from a pi-set to an e-set? Your "number of functions"
argument only works if m and n are discrete numbers.
> > If n and m are reals, you'd need a different argument.
> >
>
> I don't want to argue this at all. x^^0 is an empty product no matter
> what set I choose x and 0 from.
And 0^^x is a non-empty product when x != 0. So why should we choose
the limit of x^^0 as opposed to the limit of 0^^x?
> 0^^0 = 1 is the only reasonable convention, and this is absolutely
> painfully obvious from where I stand. What context are you using 'pow'
> in that would suggest otherwise?
When computing the limit of x^y as x->0?
> Also, Andrei's implementation explicitly works on integers anyway.
Even for integers, the limit of x^y as x->0 is 0.
My point is that the choice is an arbitrary one. It doesn't arise
directly from the mathematics itself. I understand that 0^0 is chosen
to equal 1 in order for certain theorems to be more "aesthetically
beautiful", just like 0! is chosen to equal 1 because it makes the
definition of factorial "nicer". But it's still an arbitrary choice.
T
--
Those who don't understand Unix are condemned to reinvent it, poorly.
Re: Please rid me of this goto
On Fri, Jun 24, 2016 at 01:58:01AM +0200, Timon Gehr via Digitalmars-d wrote: > On 24.06.2016 01:18, H. S. Teoh via Digitalmars-d wrote: > > On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: > > > On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: > > > > This argument only works for discrete sets. If n and m are reals, > > > > you'd need a different argument. > > > > > > > > > > For reals, you can use limits/continuation as argument. > > > > The problem with that is that you get two different answers: > > > > lim x^y = 0 > > x->0 > > > > but: > > > > lim x^y = 1 > > y->0 > > ... > > That makes no sense. You want lim[x->0] x^0 and lim[y->0] 0^y. Sorry, I was attempting to write exactly that but with ASCII art. No disagreement there. > > So it's not clear what ought to happen when both x and y approach 0. > > > > The problem is that the 2-variable function f(x,y)=x^y has a > > discontinuity at (0,0). So approaching it from some directions give > > 1, approaching it from other directions give 0, and it's not clear > > why one should choose the value given by one direction above > > another. ... > > It is /perfectly/ clear. What makes you so invested in the continuity > of the function 0^y? It's just not important. I'm not. I'm just pointing out that x^y has an *essential* discontinuity at (0,0), and the choice 0^0 = 1 is a matter of convention. A widely-adopted convention, but a convention nonetheless. It does not change the fact that (0,0) is an essential discontinuity of x^y. [...] > > not something that the mathematics itself suggest. > > ... > > What kind of standard is that? 'The mathematics itself' does not > suggest that we do not define 2+2=5 while keeping all other function > values intact either, and it is still obvious to everyone that it > would be a bad idea to give such succinct notation to such an > unimportant function. Nobody said anything about defining 2+2=5. What function are you talking about that would require 2+2=5? It's clear that 0^0=1 is a choice made by convenience, no doubt made to simplify the statement of certain theorems, but the fact remains that (0,0) is a discontinous point of x^y. At best it is undefined, since it's an essential discontinuity, just like x=0 is an essential discontinuity of 1/x. What *ought* to be the value of 0^0 is far from clear; it was a controversy that raged throughout the 19th century and only in recent decades consensus began to build around 0^0=1. T -- Let X be the set not defined by this sentence...
Re: Please rid me of this goto
On Thursday, 23 June 2016 at 23:34:54 UTC, David Nadlinger wrote:
On Thursday, 23 June 2016 at 22:08:20 UTC, Seb wrote:
[1] https://github.com/wilzbach/perf-d/blob/master/test_pow.d
[2] https://github.com/wilzbach/perf-d/blob/master/test_powi.d
This is a bad way to benchmark. You are essentially testing the
compiler's ability to propagate your constants into the
benchmarking loop/hoisting the code to be benchmarked out of it.
For cross-compiler tests, you should define the candidate
functions in a separate compilation units with an extern(C)
interface to inhibit any optimisations. In this case, your code
could e.g. be altered to:
---
import std.math : pow;
extern(C) long useStd(long a, long b) { return pow(a, b); }
extern(C) long useOp(long a, long b) { return a ^^ b; }
---
extern(C) long useStd(long a, long b);
extern(C) long useOp(long a, long b);
void main(string[] args)
{
import std.datetime: benchmark, Duration;
import std.stdio: writeln, writefln;
import std.conv: to;
long a = 5;
long b = 25;
long l = 0;
void f0() { l += useStd(a, b); }
void f1() { l += useOp(a, b); }
auto rs = benchmark!(f0, f1)(100_000_000);
foreach(j,r;rs)
{
version(GNU)
writefln("%d %d secs %d ms", j, r.seconds(),
r.msecs());
else
writeln(j, " ", r.to!Duration);
}
// prevent any optimization
writeln(l);
}
---
(Keeping track of the sum is of course no longer really
necessary.)
I get the following results:
---
$ gdc -finline-functions -frelease -O3 -c test1.d
$ gdc -finline-functions -frelease -O3 test.d test1.o
$ ./a.out
0 0 secs 620 ms
1 0 secs 647 ms
4939766238266722816
---
---
$ ldc2 -O3 -release -c test1.d
$ ldc2 -O3 -release test.d test1.o
$ ./test
0 418 ms, 895 μs, and 3 hnsecs
1 409 ms, 776 μs, and 1 hnsec
4939766238266722816
---
---
$ dmd -O -release -inline -c test1.d
$ dmd -O -release -inline test.d test1.o
0 637 ms, 19 μs, and 9 hnsecs
1 722 ms, 57 μs, and 8 hnsecs
4939766238266722816
---
— David
This is my preferred way of benchmarking as well, people often
tell me cleverer ways but nothing gives me peace of mind like
separate compilation without mangling!
Not wanting to pick on Seb in particular, but I see quite a lot
of poor benchmarking on these forums from different people
(myself included, not these days though I hope).
My biggest bugbear is actually the opposite of what you are point
out here: people doing careful benchmarking and asm-inspection of
small code-fragments in isolation when in reality it is always
going to be inlined and optimised in context.
[OT] ...
On 24.06.2016 01:58, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jun 24, 2016 at 01:33:46AM +0200, Timon Gehr via Digitalmars-d wrote:
On 24.06.2016 00:53, H. S. Teoh via Digitalmars-d wrote:
Because 0^^0 = 1, and 1 is representable.
E.g. n^^m counts the number of functions from an m-set to an n-set,
and there is exactly one function from {} to {}.
This argument only works for discrete sets.
No, it works for any cardinals n and m.
It doesn't. What is the meaning of m-set and n-set when m and n are
real numbers? How many elements are in a pi-set? How many functions
are there from a pi-set to an e-set? Your "number of functions"
argument only works if m and n are discrete numbers.
...
Most real numbers are not (identified with) cardinals, so I don't see
how that contradicts what I said, or how what you are saying is the same
thing as what you previously stated.
If n and m are reals, you'd need a different argument.
I don't want to argue this at all. x^^0 is an empty product no matter
what set I choose x and 0 from.
And 0^^x is a non-empty product when x != 0. So why should we choose
the limit of x^^0 as opposed to the limit of 0^^x?
...
I don't care about any of the limits. ^^ has an essential discontinuity
at (0,0), so the limits don't need to have a bearing on how you define
the value, but if they do, consider that there is only one direction in
which the limit is 0, and an uncountably infinite number of directions
in which the limit is 1.
Have a look at this plot: http://www.wolframalpha.com/input/?i=x%5E-y
Can you even spot the discontinuity? (I can't.)
0^^0 = 1 is the only reasonable convention, and this is absolutely
painfully obvious from where I stand. What context are you using 'pow'
in that would suggest otherwise?
When computing the limit of x^y as x->0?
...
That limit is 1 if y=0 and 0 if y!=0. I assume you mean the limit of 0^y
as y->0. Why is that important? Why should that single odd direction
ruin it for everyone else?
Also, Andrei's implementation explicitly works on integers anyway.
Even for integers, the limit of x^y as x->0 is 0.
...
This is wrong. Again, I assume that you mean 0^y as y->0.
In any case, on integers, you cannot define this limit without giving
the value at (0,0) in the first place, and the limit is whatever value
you gave.
My point is that the choice is an arbitrary one. It doesn't arise
directly from the mathematics itself. I understand that 0^0 is chosen
to equal 1 in order for certain theorems to be more "aesthetically
beautiful",
Why do you think that is? Again consider my example where a+b is
actually a+b unless a=b=2, in which case it is 5.
Now, the theorem that states that (the original) addition is associative
gets a lot less "aesthetically beautiful". Do you consider the
definition 2+2=4 an 'arbitrary choice'? If you do, then our disagreement
is founded on different ideas of what it means for notation to be
'arbitrary' as opposed to 'well-designed'.
Notation is almost exclusively about aesthetics!
just like 0! is chosen to equal 1 because it makes the
definition of factorial "nicer". But it's still an arbitrary choice.
...
n! = Γ(n+1).
0! = Γ(1) = 1. Consider it arbitrary if you wish.
(The offset by 1 here is IMHO a real example of an unfortunate and
arbitrary choice of notation, but I hope that does not take away from my
real point.)
Anyway, 2+2=4 because this makes the definition of + "nicer". It is not
an arbitrary choice. There is /a reason/ why it is "nicer".
Re: Please rid me of this goto
On Friday, 24 June 2016 at 00:26:52 UTC, John Colvin wrote: My biggest bugbear is actually the opposite of what you are point out here: people doing careful benchmarking and asm-inspection of small code-fragments in isolation when in reality it is always going to be inlined and optimised in context. Yep. This is why I was so adamant on using real-world code for my performance tracking project, in case anybody has heard me going on about that. — David
Re: Proposed Enhancement: Deprecate std.conv.text With 0 Arguments
Thank you for the input but considering that the deprecation message for this wasn't triggered a single time while compiling Phobos, I suspect that very few will be bothered by this special case. I have submitted a PMR, so we can all fight over it there: https://github.com/dlang/phobos/pull/4460
