Re: Pull request names
On Monday, 24 March 2014 at 17:49:43 UTC, Steven Schveighoffer wrote: If you want to say "fix issue XXX", please repeat the bug title at least. -Steve Yeah, that does get on my nerves sometimes too. But I do nothing about it, so I'm not part of the solution. I guess I should now. Also, when fixing an issue, *please* provide a link to said issue. Searching for "XXX" in the bug repo myself is un-necessary overhead.
Re: Losing 32 bits of a void pointer
On Monday, 24 March 2014 at 23:16:38 UTC, Andrej Mitrovic wrote: On 3/24/14, sumo wrote: For anyone who runs in to this, it is a because the epoll_event struct is packed on x86_64 bits processors. Have created a pull for druntime. I'm really surprised this wasn't caught sooner. I thought epoll was supposed to be popular. Maybe not so much in the context of D? Here we are using epoll a lot, but right now we have custom declarations for external API. --- Paolo
Re: Challenge: write a really really small front() for UTF8
Am 24.03.2014 17:44, schrieb Andrei Alexandrescu:
On 3/24/14, 5:51 AM, w0rp wrote:
On Monday, 24 March 2014 at 09:02:19 UTC, monarch_dodra wrote:
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
Before we roll this out, could we discuss a strategy/guideline in
regards to detecting and handling invalid UTF sequences?
Having a fast "front" is fine and all, but if it means your program
asserting in release (or worst, silently corrupting memory) just
because the client was trying to read a bad text file, I'm unsure this
is acceptable.
I would strongly advise to at least offer an option
Options are fine for functions etc. But front would need to find an
all-around good compromise between speed and correctness.
Andrei
b"\255".decode("utf-8", errors="strict") # UnicodeDecodeError
b"\255".decode("utf-8", errors="replace") # replacement character used
b"\255".decode("utf-8", errors="ignore") # Empty string, invalid
sequence removed.
i think there should be a base range for UTF8 iteration - with policy
based error extension (like in python) and some variants that defer this
base UTF8 range with different error behavior - and one of these become
the phobos standard = default parameter so its still switchable
Re: Appropriateness of posts
On Monday, 24 March 2014 at 23:04:16 UTC, Andrej Mitrovic wrote: There is a little bit too much elitism IMO. I can't see this anywhere, could you elaborate? I could. >;-} All the major contributors to D are always helpful towards newbies, especially in D.learn. Yes, bearophile, John Colvin and some others are doing a great job over at D.learn. That is true.
Re: Appropriateness of posts
I didn't have a problem with most of his posts, but constantly waving around that "windoze" flamebait at every possible opportunity (and then feigning innocence about it) was the real problem. And I'm even saying that as someone who does carry a lot of hatred toward windows (among many other things ;) ). OMG, someone made an insulting Windows pun; call the cops!
Re: Pull request names
On Monday, 24 March 2014 at 17:49:43 UTC, Steven Schveighoffer wrote: To all who are generating pull requests: I get emails for every pull request message that is posted, as do anyone who is subscribed to the github project. Though I agree with everything you said, it is possible to "watch" a repository without receiving email notifications, for those who are fine with just the web interface's notification system.
Re: Pull request names
On 3/24/2014 12:47 PM, Andrej Mitrovic wrote: On 3/24/14, Steven Schveighoffer wrote: To all who are generating pull requests. I keep saying the same thing to pull makers. When I'm not too busy I also rename their pull request to add the title description. Another thing I keep mentioning is to add a link to the bugzilla issue in the pull request. Yes, indeed. I think it's just polite to include a link to the bugzilla issue as well as a link in the bugzilla issue back to the PR.
Re: Appropriateness of posts
On 3/24/2014 8:12 PM, H. S. Teoh wrote: On Mon, Mar 24, 2014 at 11:08:05PM +, Andrej Mitrovic wrote: [...] Sorry, I didn't read this thread about Ramon yet (I'm just going through these posts). I'll look it up now. Oh you mean this guy?: http://forum.dlang.org/post/csusavszritzlaqds...@forum.dlang.org That guy really does act like a typical troll to me. I didn't have a problem with most of his posts, but constantly waving around that "windoze" flamebait at every possible opportunity (and then feigning innocence about it) was the real problem. And I'm even saying that as someone who does carry a lot of hatred toward windows (among many other things ;) ). It's a bit telling that he stopped posting almost exactly around the time Iain posted a link to the Flame Warriors[1]. :P Coincidence? Perhaps... [1] http://www.flamewarriorsguide.com/ "We're the flme waaarriors! Don't wanna flame no more! We're the flme waaarriors! But maybe tonight, just for one night, they'll be gone!" With apologies to Dokken :)
Re: Reviewing pull requests (was: A division problem)
"Steven Schveighoffer" wrote in message news:op.xc8uqgsneav7ka@stevens-macbook-pro.local... 2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. Pulls that haven't been touched in a while also don't get auto-tested.
Re: Pull request names
"Steven Schveighoffer" wrote in message news:op.xc8mg5laeav7ka@stevens-macbook-pro.local... The "view it on Github" is a link to the message. So I can see what this is about. But it would be nice if the pull request title was more descriptive. I don't know what issue 12419 is. It does say this in the wiki: http://wiki.dlang.org/Pull_Requests#Create_a_pull_request Don't forget you can edit the titles of other people's pull requests!
Re: Reviewing pull requests
On 3/24/14, 4:50 PM, Walter Bright wrote: On 3/24/2014 1:53 PM, Brad Roberts wrote: Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. Is it reasonable to, at least once a week, run the full queue? Like on Sunday morning? To do so for all platforms would take more than a morning (probably a full day). I don't, personally, think it'd be all that useful. As soon as it finished, the results would be deprecated and fresh builds started. That the queue focuses on pull requests that are actually the active requests seems pretty much ideal, imho. Also, for what it's worth, the 1 millionth test run was executed some time this past weekend.
Re: Appropriateness of posts
On Mon, Mar 24, 2014 at 11:08:05PM +, Andrej Mitrovic wrote: [...] > >Sorry, I didn't read this thread about Ramon yet (I'm just going through > >these posts). I'll look it up now. > > Oh you mean this guy?: > http://forum.dlang.org/post/csusavszritzlaqds...@forum.dlang.org > > That guy really does act like a typical troll to me. It's a bit telling that he stopped posting almost exactly around the time Iain posted a link to the Flame Warriors[1]. :P Coincidence? Perhaps... [1] http://www.flamewarriorsguide.com/ T -- It's bad luck to be superstitious. -- YHL
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 12:21:55 UTC, Daniel N wrote:
I'm currently too busy to submit a complete solution, but
please feel free to use my idea if you think it sounds
promising.
I now managed to dig up my old C source... but I'm still blocked
by dmd not accepting the 'pext' instruction...
1) I know my solution is not directly comparable to the rest in
this thread(for many reasons).
2) It's of course trivial to add a fast path for ascii... if
desired.
3) It throws safety and standards out the window.
#include
char32_t front(const char* inp)
{
static const uint32_t mask[32] =
{
0b0111''',
0b''',
0b0001'0011'',
0b'0011'0011',
0b0111'0011'0011'0011,
};
uint32_t rev = __builtin_bswap32(reinterpret_castuint32_t*>(inp)[0]);
uint32_t len = __lzcnt32(~rev);
return _pext_u32(rev, mask[len]);
}
This is what clang 3.4 generated:
## BB#0:
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
movl(%rdi), %eax
bswapl %eax
movl%eax, %ecx
notl%ecx
lzcntl %ecx, %ecx
leaq__ZZ5frontPKcE4mask(%rip), %rdx
pextl (%rdx,%rcx,4), %eax, %eax
popq%rbp
ret
Re: Reviewing pull requests
On 3/24/2014 1:53 PM, Brad Roberts wrote: Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. Is it reasonable to, at least once a week, run the full queue? Like on Sunday morning?
Re: Reviewing pull requests
On Mon, 24 Mar 2014 19:33:47 -0400, Brad Roberts wrote: The sync between github and the tester isn't instant, so time is sometimes wasted on an already merged pull. However, it does check between steps to see if the run has been marked as old. If so, it stops working on it. Brad, I wanted to just say that I don't follow the auto tester's development closely (obviously), but it's one of the best things I think has ever happened to D. Thanks for all your hard work. -Steve
Re: Reviewing pull requests
On 3/24/14, 2:26 PM, Steven Schveighoffer wrote: On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts wrote: On 3/24/14, 1:48 PM, Steven Schveighoffer wrote: On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic wrote: 2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue. OK, so it tests in reverse chronological? That makes the most sense. I was worried it was taking away time from other test runs. If a test has been started, and a merge occurs, does it stop the test? -Steve The sync between github and the tester isn't instant, so time is sometimes wasted on an already merged pull. However, it does check between steps to see if the run has been marked as old. If so, it stops working on it.
Re: Losing 32 bits of a void pointer
On 3/24/14, sumo wrote: > For anyone who runs in to this, it is a because the epoll_event > struct is packed on x86_64 bits processors. Have created a pull > for druntime. I'm really surprised this wasn't caught sooner. I thought epoll was supposed to be popular. Maybe not so much in the context of D?
Re: Appropriateness of posts
on On Monday, 24 March 2014 at 23:06:27 UTC, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 23:04:16 UTC, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 22:24:46 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 March 2014 at 13:31:34 UTC, Dicebot wrote: D community is single most friendly and helpful place I have ever seen in the internet. All communities rate themselves that way, I think it is somewhere in the middle. Meaning: there is room for improvement. There is a little bit too much elitism IMO. I can't see this anywhere, could you elaborate? Sorry, I didn't read this thread about Ramon yet (I'm just going through these posts). I'll look it up now. Oh you mean this guy?: http://forum.dlang.org/post/csusavszritzlaqds...@forum.dlang.org That guy really does act like a typical troll to me.
Re: Appropriateness of posts
On Monday, 24 March 2014 at 23:04:16 UTC, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 22:24:46 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 March 2014 at 13:31:34 UTC, Dicebot wrote: D community is single most friendly and helpful place I have ever seen in the internet. All communities rate themselves that way, I think it is somewhere in the middle. Meaning: there is room for improvement. There is a little bit too much elitism IMO. I can't see this anywhere, could you elaborate? Sorry, I didn't read this thread about Ramon yet (I'm just going through these posts). I'll look it up now.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Sunday, 23 March 2014 at 18:58:20 UTC, Walter Bright wrote: On 3/23/2014 11:29 AM, "Ola Fosheim Grøstad" While that is true you can have a soft real time thread feeding the hard real time thread Yes, and you can do that with GC, too. You can, but the way I view "soft real time" is that you accept jitter, but not prolonged freezing of threads. I don't think the current GC is "soft real time".
Re: Appropriateness of posts
On Monday, 24 March 2014 at 22:24:46 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 March 2014 at 13:31:34 UTC, Dicebot wrote: D community is single most friendly and helpful place I have ever seen in the internet. All communities rate themselves that way, I think it is somewhere in the middle. Meaning: there is room for improvement. There is a little bit too much elitism IMO. I can't see this anywhere, could you elaborate? All the major contributors to D are always helpful towards newbies, especially in D.learn. And none of us think D is perfect. You should stay around #d on freenode for a while, plenty of us whine about D deficiencies every once in a while. But we continue to use the language because it still pulls its weight.
Re: Losing 32 bits of a void pointer
On Monday, 24 March 2014 at 20:45:13 UTC, sumo wrote: On Wednesday, 19 February 2014 at 02:39:39 UTC, sumo wrote: I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue. For anyone who runs in to this, it is a because the epoll_event struct is packed on x86_64 bits processors. Have created a pull for druntime. Thumb up !
Re: Improve D's syntax to make it more python like
On Monday, 24 March 2014 at 22:23:50 UTC, Nick Sabalausky wrote: Using the same language on client/server is indeed quite nice, partly because of less mental context-switching, and also because of increased code sharing (which also makes it easier to move things between client vs server if you need to). Yes, especially for data models. It is always annoying to modify several different layers just to add some fields to a database entry. Not a big deal, but so… pointless. using Haxe pretty heavily for a good while. Haxe is a rather "ok" language, which is practically high praise coming from me - I'm typically very critical of languages. I've looked at Haxe from time to time, and I like the approach, but it has never been sufficient to solve any issues in any real code I've worked on. FWIW though, lately I've been swinging back over to the side of "I'd rather use the best language I can whenever possible, code duplication and other concerns over multiple languages be damnned." Life's too short to tolerate subpar tools. Yeah, that's where I am at now too. So currently I deal with Python, Dart (working hard to get rid of Javascript) and C++ (and dabble with XSLT, Java and Objective-C). But I'd rather use something more clean and strongly typed like Go and D, but with Pythonesque terseness and functional style list processing hight level cleaness. Unfortunately both D and Go lack production level support. And even with production level support they still lack production quality libraries for excel handling, pdf generation etc.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Sunday, 23 March 2014 at 17:38:17 UTC, Sean Kelly wrote: On Saturday, 22 March 2014 at 14:04:01 UTC, Daniel Davidson wrote: For example, I could see technical reasons why in certain non-quant areas like XML parsing where D can be faster than C++. (http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/) But then, with a large amount of time and unlimited funding the techniques could probably be duplicated in C++. Try no funding and a trivial amount of time. The JSON parser I wrote for work in C performs zero allocations and unescaping is performed on demand. D arguably makes this easier by building slicing into the language, but not decoding or copying is a design decision, not a language artifact (at least in the case of C/C++ where aliasing data is allowed). The take-away from that Tango article is that the performance hit for parsing is aggressively decoding data the user may not care about or may not want decoded in the first place. This just happens to be the approach that basically every XML parser on the planet uses for some ridiculous reason. This isn't for ridiculous reasons, this is because in other languages you have no guarantee that what you work on is immutable. So you must aggressively copy anyway. With a separate decoding step, you'll ends up copying twice, which is also wasteful.
Re: protocol for using InputRanges
On 24/03/14 14:20, Dicebot wrote: I think there is one design mistake with current InputRange rules that makes usage so inconsistent. We have `empty` but don't have any distinct `not yet started` state. If calling `popFront` at least once was required before accessing `front`, I can't imagine the case where having any non-trivial code in `front` would have been necessary. I floated some ideas along those lines, for a "first" method that would be automatically called immediately before the first call to front, popFront, etc., whatever came first. The trouble is that it's so vague _when_ it should be called. Example from std.random: RandomSample not only has a .front which needs a check as to whether the first value has actually been selected, it also has an .index method which corresponds to the index of the chosen element of the range being sampled from. Now, how is a "first" method supposed to know which methods it should precede? Any method? Specified ones? In any case, even if we could get it to work, it'd be a convenience rather than a solution, and would still in effect result in a non-const .front. OTOH a requirement that .popFront() be called at least once before .front is accessed won't wash either. At least in the case of randomSample, the code required to generate the _first_ sample point is different from what is required to .popFront().
Re: Improve D's syntax to make it more python like
On 3/22/2014 2:38 PM, "Ola Fosheim Grøstad" " wrote: On Saturday, 22 March 2014 at 17:54:16 UTC, Russel Winder wrote: like "end to end" the same language. Many are asking about server-side Dart as well as client-side Dart in the browser. Yes, a CLI/server Dart VM exists that is suitable for a http server. The advantage of client/server code sharing is obvious when you write web-apps, but I am a bit weary of using dynamic languages on web servers since runtime errors can be nasty. I personally would like to see a Dart version with a much stricter type system, but I think the Dart library is just about right for web development and the language itself is pretty well rounded and pragmatic (but nothing spectacular). Using the same language on client/server is indeed quite nice, partly because of less mental context-switching, and also because of increased code sharing (which also makes it easier to move things between client vs server if you need to). Because of that, and an irritating need to support cheapo shared/PHP-hosting servers (which are NEVER run by companies who have the slightest comprehension of security), I'd been using Haxe pretty heavily for a good while. Haxe is a rather "ok" language, which is practically high praise coming from me - I'm typically very critical of languages. FWIW though, lately I've been swinging back over to the side of "I'd rather use the best language I can whenever possible, code duplication and other concerns over multiple languages be damnned." Life's too short to tolerate subpar tools.
Re: Appropriateness of posts
On Monday, 24 March 2014 at 13:31:34 UTC, Dicebot wrote: D community is single most friendly and helpful place I have ever seen in the internet. All communities rate themselves that way, I think it is somewhere in the middle. Meaning: there is room for improvement. There is a little bit too much elitism IMO. However, friendliness is something that goes both ways. If person continuously ignores any internal rules of conduct, demands any special attention or behaves explicitly hostile, such person has no value for community. It does not matter if is trolling or simply bad attitude, does not matter if enthusiasm is real. It should, because newbie dynamics are particular to newbies. It is all about attitude. Uhu, but the community/moderators are evaluated by lurkers. Not by how newbie acts, but how what kind of response they get. If you deal well with demanding newbies, the community is portraying itself as welcoming (or even professional): You can safely assume that 90% of the list "participants" have never actually written a single word in the newsgroups. In that regard W.B. was right. The thread being questioned was very introvert. While maintaining group boundaries is important they should not establish barriers to entry. In that regard stating an opposing view diminished the boundary defining aspects of it.
Re: Lazy private selective imports
On Monday, 24 March 2014 at 22:06:07 UTC, Peter Alexander wrote: On Monday, 24 March 2014 at 21:43:36 UTC, monarch_dodra wrote: In any case, while not as convenient as a built-in "lazy import", it could be a solution worth digging into. This is why I brought this up. Oops. I *thought* the coincidence was uncanny :) You have provided a library solution, but it's ugly to have to do that manually for every function. Yeah. It's ugly. It also fails if said alias needs parameters (eg: "format!char"). It would be nice if selective and/or static imports were lazy.
Re: Lazy private selective imports
On Monday, 24 March 2014 at 21:43:36 UTC, monarch_dodra wrote: On Monday, 24 March 2014 at 21:21:30 UTC, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 21:18:49 UTC, Peter Alexander wrote: Would it be possible to perform private selective imports lazily? This was discussed fairly recently: http://forum.dlang.org/thread/l8t2o1$kq0$1...@digitalmars.com?page=9 (and previous or next pages) This is a very recent issue, as a matter of fact, I ran into it *TODAY*: https://github.com/D-Programming-Language/phobos/pull/2047 See the link at the end of the OP ;-) By combining templates and aliases, you can have a library solution: ... In any case, while not as convenient as a built-in "lazy import", it could be a solution worth digging into. This is why I brought this up. You have provided a library solution, but it's ugly to have to do that manually for every function.
Re: Lazy private selective imports
On Monday, 24 March 2014 at 21:21:30 UTC, Andrej Mitrovic wrote:
On Monday, 24 March 2014 at 21:18:49 UTC, Peter Alexander wrote:
Would it be possible to perform private selective imports
lazily?
This was discussed fairly recently:
http://forum.dlang.org/thread/l8t2o1$kq0$1...@digitalmars.com?page=9
(and previous or next pages)
This is a very recent issue, as a matter of fact, I ran into it
*TODAY*:
https://github.com/D-Programming-Language/phobos/pull/2047
By combining templates and aliases, you can have a library
solution:
//
template lazyWriteln()
{
import std.stdio : writeln;
alias lazyWriteln = std.stdio.writeln;
}
void main()
{
lazyWriteln(5);
}
//
Heck, with proper renamed imports, you can even re-use the
initial name:
//
template writeln()
{
import std.stdio : stdwriteln = writeln;
alias writeln = stdwriteln;
}
void main()
{
writeln(5);
}
//
HOWEVER (word of warning), for the second solutions, I've run
into conflicting alias issues:
std/conv.d(4864): Error:
std.string.format!(char, uint, string, uint).format at
std/string.d(2401)
conflicts with
std.string.format!(char, uint, string, uint).format at
std/string.d(2401)
I didn't dig very far to know if this is 313/314 related, or a
new issue though.
In any case, while not as convenient as a built-in "lazy import",
it could be a solution worth digging into.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 24 March 2014 at 11:57:14 UTC, Daniel Davidson wrote: On Saturday, 22 March 2014 at 17:30:45 UTC, TJB wrote: On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote: This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation. Well, right away people jumped to high-frequency trading. Although that may be the most visible area in computational finance - it's not the only one. There are areas where performance is crucial, but where trading is done at a lower frequency (where latency is not the main issue). I apologize for that. HFT has been a driver of a lot of business and attention. Of course you are right about areas with less latency sensitivity and D is attractive there. Even in latency sensitive efforts I think could be D attractive for new efforts providing some of the memory management efforts continue to evolve. My main point was selling it would be tough. Thanks Dan Dan, Thanks for your thoughtful points. I think your experience is worth listening to - I think it confirms that both: * D is worth pursuing in these areas * It won't be easy to convince others to adopt it These points are worth thinking deeply about as D is developed for the real world. TJB
Re: Reviewing pull requests
On Mon, 24 Mar 2014 16:53:36 -0400, Brad Roberts wrote: On 3/24/14, 1:48 PM, Steven Schveighoffer wrote: On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth. 2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue. OK, so it tests in reverse chronological? That makes the most sense. I was worried it was taking away time from other test runs. If a test has been started, and a merge occurs, does it stop the test? -Steve
Re: Lazy private selective imports
On Monday, 24 March 2014 at 21:18:49 UTC, Peter Alexander wrote: Would it be possible to perform private selective imports lazily? This was discussed fairly recently: http://forum.dlang.org/thread/l8t2o1$kq0$1...@digitalmars.com?page=9 (and previous or next pages)
Re: A division problem
On 3/24/14, 1:21 PM, bearophile wrote: Andrei Alexandrescu: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. My time is more efficiently used suggesting people new ideas to create new pull requests :-) You and I have very different notions of what efficiency would mean here. -- Andrei
Re: A division problem
On 3/24/14, 2:51 AM, Don wrote: It is indeed a common floating-point bug. I came up with a solution for this a couple of years ago, never got around to doing a pull request, but it's on the newsgroup somewhere. It's a little extension to the range propagation implementation. You add a boolean flag to the range, which indicates 'a fractional part has been discarded'. This flag gets set whenever you perform an integer division (or integer exponentiation with a negative power), and is cleared whenever there is a cast or a bitwise operation. Then, disallow implicit casting from integer to floating point whenever the fractional bit is set. Catches all these kinds of bugs, doesn't require any changes to the language. That seems a sensible thing to do. I've assigned https://d.puremagic.com/issues/show_bug.cgi?id=12452 to you for now. Andrei
Re: Lazy private selective imports
On Monday, 24 March 2014 at 21:18:49 UTC, Peter Alexander wrote:
// non-selective std.stdio imported
import std.stdio;
void writeln(
void main() {}
Oops, that unfinished line isn't meant to be there... :-)
Lazy private selective imports
Would it be possible to perform private selective imports lazily?
i.e. only import when the symbol selectively imported is
requested.
--
// not used => std.stdio not imported
import std.stdio : writeln;
void main()
--
// used => std.stdio imported
import std.stdio : writeln;
void main() { writeln("Hello, world"); }
--
// non-selective std.stdio imported
import std.stdio;
void writeln(
void main() {}
--
Are there problems with this?
One semantic difference this would make is that module
constructors wouldn't be run in the first case whereas they would
be without this change. Public selective imports would need to be
done eagerly.
The idea is to reduce code bloat and parse times without having
to resort to local imports everywhere and hacks like this:
https://github.com/D-Programming-Language/phobos/pull/2047/files
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 20:04:23 UTC, deadalnix wrote: On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote: On 2014-03-24 16:42:59 +, Andrei Alexandrescu said: tuple() tuple(a) tuple(a, b) tuple(a, b, c) struct() struct(a) struct(a, b) struct(a, b, c) Tuples are actually nameless structs, no? This whole point is that this part doesn't need any language semantic addition. An unpacking syntax is a useful addition, and not especially related to tuples, as you could unpack arrays for instance. And would also avoid memory allocation where possible. At least as far as unpacking the results of a function are concerned. Joseph
Re: Reviewing pull requests
On 3/24/14, 1:48 PM, Steven Schveighoffer wrote: On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth. 2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. Older than 2 weeks and they aren't likely to get tested either.. since any change to the branch (ie, a pull being merged) restarts testing, so they're effectively just dead weight down the queue. Only a lull in pull merging would allow them to be tested, which is fine since a lull in activity would otherwise just result in idle testers. So, really #2 is a non-issue.
Re: A division problem
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
This kind of code sometimes is wrong, because you forget to
cast x to double before the division and you lose precision
(but here the compiler knows that the result of the division
will go inside a double):
void main() {
int x = 15;
double y = x / 10;
}
The cause is that unfortunately in D the integer division uses
the same operator as the FP division. In Python there is the /
and // operators. In OcaML there are the / and /., in Delphi
there are the / and div operators, in Ada the two operands need
to be of the same type.
Seasoned C/C++/D programmers watch for the types every time
they perform a division, to avoid that trap. But less
experienced programmers introduce bugs with divisions. Can D
help the programmer reduce the frequency of similar bugs? And
do we want to?
Bye,
bearophile
I think I've see a thread very similar to this... well, most
willn't like but a possible solution to help programmer reduce
this is do what python did: a new operator.
Re: Reviewing pull requests
On 3/24/14, 1:11 PM, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth. Those should be closed. -- Andrei
Re: Reviewing pull requests (was: A division problem)
On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic wrote: On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth. 2 things: 1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened. 2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester. -Steve
Re: Losing 32 bits of a void pointer
On Wednesday, 19 February 2014 at 02:39:39 UTC, sumo wrote: I am using D & epoll on Fedora 3.12.10-300.fc20.x86_64 and am running into a very odd issue. For anyone who runs in to this, it is a because the epoll_event struct is packed on x86_64 bits processors. Have created a pull for druntime.
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Kill it. I'll admit to using the comma operator on occasion, but never for any reason that warranted it. If there are any lingering uses in Druntime I'm 100% for eliminating them.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 16:38:42 UTC, Andrei Alexandrescu wrote: On 3/24/14, 5:18 AM, "Marc Schütz" " wrote: This is nice, although I guess it will make parsing harder. It probably means that the distinction between "," as operator and tuple element separator will be context-dependent. No, parsing stays the same. You can think of comma returning a tuple. But for now we're forcing that tuple to never be used, so as to not change code semantics. Ah, that's clever.
Re: A division problem
Andrei Alexandrescu: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. My time is more efficiently used suggesting people new ideas to create new pull requests :-) If you diverted 1.0/10 (sic!) of the effort you put in these discussions in reviewing pull requests, that would help us all put up a lot better with the distraction. Instead of ignoring my arguments of this thread, if you want please comment regarding the merits of the idea of catching some of the division-related problems. Bye, bearophile
Re: Should we deprecate comma?
Andrei Alexandrescu: That would be a different function but same syntax. In fact for safety I favor myFunc().scatter(a, b, c) -- Andrei That's awful :-) Are you now saying you don't want a good tuple unpacking syntax in D? Then what's the "eye to tuples" you were talking about regrding comma syntax? Bye, bearophile
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 16:31:42 UTC, Andrei Alexandrescu
wrote:
On 3/24/14, 2:02 AM, monarch_dodra wrote:
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu
wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
Before we roll this out, could we discuss a strategy/guideline
in
regards to detecting and handling invalid UTF sequences?
I think std.array.front should return the invalid dchar on
error, and popFront should attempt to resync on error.
Andrei
That sounds good to me (I think). Better than a straight up
assert anyways...
...which is what the code you submitted does.
Also, I think relying on bounds checking is wrong: Disabling
bounds checking mean you are OK for memory corruption for *wrong
code*. I don't think invalid string is wrong code. 'front' should
do an actual "if", and "assert(0)" when needed. This should have
no impact on performance BTW, if done with pointer extraction
("slice.ptr[1]"), and in a trusted context.
Of course, this is all assuming we are asserting at all.
Re: Reviewing pull requests (was: A division problem)
On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote: The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 18:58:52 UTC, Michel Fortin wrote: On 2014-03-24 16:42:59 +, Andrei Alexandrescu said: tuple() tuple(a) tuple(a, b) tuple(a, b, c) struct() struct(a) struct(a, b) struct(a, b, c) Tuples are actually nameless structs, no? This whole point is that this part doesn't need any language semantic addition. An unpacking syntax is a useful addition, and not especially related to tuples, as you could unpack arrays for instance.
Re: A division problem
On 3/24/14, 12:51 PM, bearophile wrote: Peter Alexander: We are passed the initial stage of designing the language. D is used now in lots of real code. I'd like D improve some more. The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. Anyone who has any nontrivial interest in the future of D should help us turn the ratchet by reviewing pull requests. Anything - potential bugs found, safety suggestions, efficiency suggestions, LGTM - would help the core team drain that pipe. are distracting and counterproductive. It's not distracting, because it focuses on something you do often (divisions), and it's hopefully productive because it could avoid some bugs and decrease the time spent performing rote manual code review. If you diverted 1.0/10 (sic!) of the effort you put in these discussions in reviewing pull requests, that would help us all put up a lot better with the distraction. Andrei
Re: A division problem
H. S. Teoh: Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas can go on that page. I don't think Andrei will want a D3 language, so better to keep the focus on D2 first :-) And he is right because there are still some parts of D2 unfinished. The little type system improvement suggested in this thread is meant for D2. Bye, bearophile
Re: Challenge: write a really really small front() for UTF8
24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei I had to join the party at some point. This seems like 25 instructions: http://goo.gl/N7sHtK -- Dmitry Olshansky
Re: A division problem
Peter Alexander: We are passed the initial stage of designing the language. D is used now in lots of real code. I'd like D improve some more. The focus now has to be on completing the original design, The original D design is to make a language that is "focused on safety", so we are still working to complete it :-) and maybe making small non-breaking improvements where practical. I think the problem raised in this thread could have a very limited negative impact on correct existing D code, and a positive impact in finding wrong code. Discussions about fundamental changes to the language like this, It's not a fundamental change, I think it's a sufficiently limited change. As usual you can be sure only when you apply such ideas on real D code. are distracting and counterproductive. It's not distracting, because it focuses on something you do often (divisions), and it's hopefully productive because it could avoid some bugs and decrease the time spent performing rote manual code review. Bye, bearophile
Re: Should we deprecate comma?
On 3/24/14, 9:57 AM, bearophile wrote:
Andrei Alexandrescu:
Look at some of the syntaxes here:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
One of the syntaxes:
@{}
@{a}
@{a, b}
@{a, b, c}
WTF???
tuple()
tuple(a)
tuple(a, b)
tuple(a, b, c)
Andrei
So you are saying you want to support a syntax like this?
tuple(a, b, c) = myFunc();
That would be a different function but same syntax. In fact for safety I
favor myFunc().scatter(a, b, c) -- Andrei
Re: Pull request names
On 3/24/14, Steven Schveighoffer wrote: > To all who are generating pull requests. I keep saying the same thing to pull makers. When I'm not too busy I also rename their pull request to add the title description. Another thing I keep mentioning is to add a link to the bugzilla issue in the pull request.
Re: A division problem
On Mon, Mar 24, 2014 at 07:19:58PM +, Peter Alexander wrote: > On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote: > >Seasoned C/C++/D programmers watch for the types every time they > >perform a division, to avoid that trap. But less experienced > >programmers introduce bugs with divisions. Can D help the programmer > >reduce the frequency of similar bugs? And do we want to? > > We are passed the initial stage of designing the language. D is used > now in lots of real code. The focus now has to be on completing the > original design, and maybe making small non-breaking improvements > where practical. Discussions about fundamental changes to the > language like this, while interesting, are distracting and > counterproductive. Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas can go on that page. T -- English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall
Re: Should we deprecate comma?
deadalnix: tuple(1,2)two-element tuple tuple(1) one-element tuple (1) simple expression tuple() empty tuple Oh, wait... Yes, that. 99% of the problem is not in the syntax to build tuples. What's desired are mostly syntaxes to do the opposite, pulling tuples apart in a handy way. Bye, berarophile
Re: A division problem
On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote: Seasoned C/C++/D programmers watch for the types every time they perform a division, to avoid that trap. But less experienced programmers introduce bugs with divisions. Can D help the programmer reduce the frequency of similar bugs? And do we want to? We are passed the initial stage of designing the language. D is used now in lots of real code. The focus now has to be on completing the original design, and maybe making small non-breaking improvements where practical. Discussions about fundamental changes to the language like this, while interesting, are distracting and counterproductive.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu wrote: How about tuple(1,2)two-element tuple tuple(1) one-element tuple (1) simple expression tuple() empty tuple Oh, wait... Yes, that.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 13:12:36 UTC, Dicebot wrote: If you are not ready to break the code for it, there is nothing to discuss. It is not something to compromise about - either kill it completely, or just let it be. Anything else will make things only worse. Actually, Andrei's solution of not being able to use the result is really nice as it allows to redefine the meaning later, as well as it limits the breakage.
Re: Should we deprecate comma?
Michel Fortin: struct() struct(a) struct(a, b) struct(a, b, c) Tuples are actually nameless structs, no? That syntax is even longer/wordier :-) auto arr = [struct(1, 2), struct(3, 4), struct(5, 6)]; Structs usually don't support slicing and concatenation. But they are indeed related structures. Bye, bearophile
Re: Should we deprecate comma?
On 2014-03-24 16:42:59 +, Andrei Alexandrescu said: tuple() tuple(a) tuple(a, b) tuple(a, b, c) struct() struct(a) struct(a, b) struct(a, b, c) Tuples are actually nameless structs, no? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Should we deprecate comma?
w0rp: Yes, I am with you on this. I prefer tuple(1) over (1, ) I don't think people are advocating for the "(1, )" syntax. Regarding the "tuple(1)" syntax, it is one of the alternative syntaxes you can find in the DIP. One disadvantage of the "tuple()" syntax is that it's a little long, so if you have an array of tuple literals it becomes a little wordy: auto a = [tuple(1, 2), tuple(3, 4), tuple(5, 6)]; But of course having a good built-in "tuple()" syntax is much better than the current situation without any syntax. Bye, bearophile
Re: A division problem
Temtaime: It requires a little more attention and that's all. Please, stop creating such "fake" enchantments and go to fix real bugs. Thanks. I don't agree they are fake :-) We have removed several classes of common C bugs from D with those enhancements, and there is still some space left for improvements :-) Bye, bearophile
Re: A division problem
It requires a little more attention and that's all. Please, stop creating such "fake" enchantments and go to fix real bugs. Thanks.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 16:40:29 UTC, Andrei Alexandrescu wrote: On 3/24/14, 5:25 AM, w0rp wrote: Please kill the comma operator with fire. Is is just bad. On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote: Or, if you really want to distinguish them, this would work: (1,2)two-element tuple (1,) one-element tuple (1) simple expression (,) empty tuple I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple. It may be less of an issue in a static language, but it will still be an issue. I don't have an alternative syntax to propose. How about tuple(1,2)two-element tuple tuple(1) one-element tuple (1) simple expression tuple() empty tuple Oh, wait... Andrei Yes, I am with you on this. I prefer tuple(1) over (1, )
Re: Should we deprecate comma?
Dicebot:
While you can do this:
void foo(in @(int a, int b, int c}) {...}
auto result = arr.map!foo;
I believe it is dangerous misfeature and I don't want to see
this in D. Sorry :(
Why do you think it's a dangerous and a misfeature? I think you
are misaken.
It's present in most functional languages, with slight syntax
differences.
The problem is that it's hard to explain how much nice a language
feature is if you have not used it extensively in some language
:-) So I suggest you to try to write some functional code that
uses plenty of tuples. You will see how commonly useful is what I
have written :-)
A similar program in Haskell:
foo (a, b) =
show a ++ " - " ++ show b
lst = [(10, 20), (30, 40)]
main = do
print $ map foo lst
Output:
["10 - 20","30 - 40"]
And Haskell is regarded as one of the safest languages :-)
Similar code is possible in F#, OCaml, Scala, etc.
Bye,
bearophile
Pull request names
To all who are generating pull requests: I get emails for every pull request message that is posted, as do anyone who is subscribed to the github project. A recent message in my email: Re: [phobos] Fix issue 12419 (#2038) @monarchdodra Good point, done. - Reply to this email directly or view it on GitHub. The "view it on Github" is a link to the message. So I can see what this is about. But it would be nice if the pull request title was more descriptive. I don't know what issue 12419 is. Please note, I am not complaining about the volume of pull request chatter, this is great! But the title of the pull request should describe what it logically is without having to click through to a bug report or read everything about the pull request. If you want to say "fix issue XXX", please repeat the bug title at least. -Steve
Re: Should we deprecate comma?
Dicebot:
I understand but this is something that can be pretty hard to
fit into D semantics/grammar and I am not sold that it is worth
the push on its own.
I'd like a good tuple syntax in D.
What is the difference with this then?
void foo(int a, int b, int c)
{
// ...
}
auto t = tuple(10, 20, 30);
foo(t.expand);
The difference is that your experience with tuples will be less
good. One difference can be seen here. Given an array of tuples
(here I am using a shorter syntax):
auto arr = [@{1, 2}, @(3, 4)]
You can't do this:
void foo(int a, int b, int c) {...}
auto result = arr.map!foo;
And you need:
auto result = arr.map!(t => foo(t.expand));
Or:
auto result = arr.map!(t => foo(t[]));
While you can do this:
void foo(in @(int a, int b, int c}) {...}
auto result = arr.map!foo;
The point of having a tuple syntax is not to expand the set of
programs you can write with C language. It's of having a handy
syntax to perform certain very common operations with more than
one type.
I also suggest you to take a look at the DIP.
Bye,
bearophile
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 17:51:15 UTC, bearophile wrote:
The difference is that your experience with tuples will be less
good. One difference can be seen here. Given an array of tuples
(here I am using a shorter syntax):
auto arr = [@{1, 2}, @(3, 4)]
You can't do this:
void foo(int a, int b, int c) {...}
auto result = arr.map!foo;
And you need:
auto result = arr.map!(t => foo(t.expand));
Or:
auto result = arr.map!(t => foo(t[]));
While you can do this:
void foo(in @(int a, int b, int c}) {...}
auto result = arr.map!foo;
I believe it is dangerous misfeature and I don't want to see this
in D. Sorry :(
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 17:35:46 UTC, bearophile wrote:
Dicebot:
int a, b, c;
tuple(a, b, c) = foo();
writeln(a, b, c); // 000
TypeTuple!(a, b, c) = foo();
writeln(a, b, c); // 123
}
One of the points of a good tuple syntax is to not need to
define the variables before (because in several cases you can't
do that).
I understand but this is something that can be pretty hard to fit
into D semantics/grammar and I am not sold that it is worth the
push on its own.
On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
void foo(in auto tuple(a, b, c)) {}
This snippet does not make any sense.
It's equivalent to Python2.6 code:
def foo((a, b, c)):
A more complete Python2.6 program:
def foo((a, b, c)):
print a, "-", b, "-", c
t = (10, 20, 30)
foo(t)
Output:
10 - 20 - 30
What is the difference with this then?
void foo(int a, int b, int c)
{
// ...
}
auto t = tuple(10, 20, 30);
foo(t.expand);
Re: Should we deprecate comma?
Dicebot:
int a, b, c;
tuple(a, b, c) = foo();
writeln(a, b, c); // 000
TypeTuple!(a, b, c) = foo();
writeln(a, b, c); // 123
}
One of the points of a good tuple syntax is to not need to define
the variables before (because in several cases you can't do that).
On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
void foo(in auto tuple(a, b, c)) {}
This snippet does not make any sense.
It's equivalent to Python2.6 code:
def foo((a, b, c)):
A more complete Python2.6 program:
def foo((a, b, c)):
print a, "-", b, "-", c
t = (10, 20, 30)
foo(t)
Output:
10 - 20 - 30
In Haskell, OcaML, and other languages the code is similar. It's
a tuple unpacking syntax in the function signature.
The other example with foreach is very similar.
Bye,
bearophile
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 16:17:52 UTC, Andrei Alexandrescu wrote: On 3/24/14, 12:53 AM, Chris Williams wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei http://goo.gl/TaZTNB Nice! Why assert(ret != 0)? Andrei It should be -1. I wanted to make sure that bsr() wasn't called on zero, but of course that's not the correct way to test it when I'm about to ~ it.
Re: Challenge: write a really really small front() for UTF8
Whoops, wrong "original" version. That was the one before I understood the game. Here mine is fixed (but up to 180 lines - 16 labels = 164 instructions): http://goo.gl/wjIAVm On Monday, 24 March 2014 at 17:14:11 UTC, dnspies wrote: It seems like mine wasn't being inlined because I had carelessly replaced char[] with const(char)[] in the function signature (I don't know why that should make a difference, but it does) Going back to my original version (with Andre's trick to avoid letting the loop unroll), I get dnspies_orig 159 - 16 labels = 143 instructions However, MFortin1 can be made to do better by taking successive slices instead of indexing (and commenting out the check, since it no longer helps optimize). MFortin1_slice 137 - 13 labels = 124 instructions http://goo.gl/JAgVK1 On Monday, 24 March 2014 at 13:39:45 UTC, Michel Fortin wrote: On 2014-03-24 06:08:30 +, "safety0ff" said: Everything seems to work in your corrected versions: http://dpaste.dzfl.pl/3b32535559ba Andrei's version doesn't compile on recent compiler versions due to goto skipping initialization. Ok, so let's check what happens in actual usage. In other words, what happens when front is inlined and used in a loop. I'm counting the number of assembly lines of this main function for looping through each possible input using the various implementations: http://goo.gl/QjnA2k implementation line count of main in assembly andralex 285 - 9 labels = 276 instructions MFortin1 135 - 13 labels = 122 instructions MFortin2 150 - 14 labels = 136 instructions safety0ff -- not inlined (too big?) -- dnspies 161 - 15 labels = 146 instructions CWilliams233 - 25 labels = 208 instructions For compactness, my first implementation seems to be the winner, both with and without inlining. That said, I think front should only assume a non-empty char[] and thus should check the length before accessing anything after the first byte to protect against incomplete multi-byte sequences such as [0x1000_]. So I added this line to my two implementations: if (1+tailLength >= s.length) return dchar.init; Now lets see what happens with those changes: http://goo.gl/XPCGYE implementation line count of main in assembly MFortin1Check103 - 11 labels = 92 instructions MFortin2Check135 - 13 labels = 122 instructions Now I'm baffled. Adding a test makes the code shorter? It actually make the standalone functions longer by 8 instructions (as expected), but the inlined version is shorter. My guess is that the optimizer creates something entirely different and it turns out that this different version optimises better after inlining. That said, my test "main" function isn't very representative of the general case because the length is statically known by the optimizer. Let's see what it does when the length is not statically known: http://goo.gl/E2Q0Yu implementation line count of main in assembly andralex 384 - 9 labels = 375 instructions MFortin1 173 - 19 labels = 154 instructions MFortin2 182 - 18 labels = 164 instructions safety0ff -- not inlined -- dnspies -- not inlined -- CWilliams229 - 23 labels = 206 instructions MFortin1Check211 - 24 labels = 187 instructions MFortin2Check218 - 21 labels = 197 instructions So again MFortin1 is the winner for compactness. Still, I maintain that we ought to at least check the length of the array for multi-byte sequences to protect against incomplete sequences that could lay at the end of the string, so I'd favor MFortin1Check.
Re: Challenge: write a really really small front() for UTF8
It seems like mine wasn't being inlined because I had carelessly replaced char[] with const(char)[] in the function signature (I don't know why that should make a difference, but it does) Going back to my original version (with Andre's trick to avoid letting the loop unroll), I get dnspies_orig 159 - 16 labels = 143 instructions However, MFortin1 can be made to do better by taking successive slices instead of indexing (and commenting out the check, since it no longer helps optimize). MFortin1_slice 137 - 13 labels = 124 instructions http://goo.gl/JAgVK1 On Monday, 24 March 2014 at 13:39:45 UTC, Michel Fortin wrote: On 2014-03-24 06:08:30 +, "safety0ff" said: Everything seems to work in your corrected versions: http://dpaste.dzfl.pl/3b32535559ba Andrei's version doesn't compile on recent compiler versions due to goto skipping initialization. Ok, so let's check what happens in actual usage. In other words, what happens when front is inlined and used in a loop. I'm counting the number of assembly lines of this main function for looping through each possible input using the various implementations: http://goo.gl/QjnA2k implementation line count of main in assembly andralex 285 - 9 labels = 276 instructions MFortin1 135 - 13 labels = 122 instructions MFortin2 150 - 14 labels = 136 instructions safety0ff -- not inlined (too big?) -- dnspies 161 - 15 labels = 146 instructions CWilliams233 - 25 labels = 208 instructions For compactness, my first implementation seems to be the winner, both with and without inlining. That said, I think front should only assume a non-empty char[] and thus should check the length before accessing anything after the first byte to protect against incomplete multi-byte sequences such as [0x1000_]. So I added this line to my two implementations: if (1+tailLength >= s.length) return dchar.init; Now lets see what happens with those changes: http://goo.gl/XPCGYE implementation line count of main in assembly MFortin1Check103 - 11 labels = 92 instructions MFortin2Check135 - 13 labels = 122 instructions Now I'm baffled. Adding a test makes the code shorter? It actually make the standalone functions longer by 8 instructions (as expected), but the inlined version is shorter. My guess is that the optimizer creates something entirely different and it turns out that this different version optimises better after inlining. That said, my test "main" function isn't very representative of the general case because the length is statically known by the optimizer. Let's see what it does when the length is not statically known: http://goo.gl/E2Q0Yu implementation line count of main in assembly andralex 384 - 9 labels = 375 instructions MFortin1 173 - 19 labels = 154 instructions MFortin2 182 - 18 labels = 164 instructions safety0ff -- not inlined -- dnspies -- not inlined -- CWilliams229 - 23 labels = 206 instructions MFortin1Check211 - 24 labels = 187 instructions MFortin2Check218 - 21 labels = 197 instructions So again MFortin1 is the winner for compactness. Still, I maintain that we ought to at least check the length of the array for multi-byte sequences to protect against incomplete sequences that could lay at the end of the string, so I'd favor MFortin1Check.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 16:59:37 UTC, bearophile wrote:
void foo(in auto tuple(a, b, c)) {}
This snippet does not make any sense.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 16:57:09 UTC, bearophile wrote:
So you are saying you want to support a syntax like this?
tuple(a, b, c) = myFunc();
Bye,
bearophile
This actually almost works:
auto foo()
{
return tuple(1, 2, 3);
}
void main()
{
int a, b, c;
tuple(a, b, c) = foo();
writeln(a, b, c); // 000
TypeTuple!(a, b, c) = foo();
writeln(a, b, c); // 123
}
Re: Should we deprecate comma?
So you are saying you want to support a syntax like this?
tuple(a, b, c) = myFunc();
And:
foreach (tuple(a, b, c); myTuples) {}
void foo(in auto tuple(a, b, c)) {}
Bye,
bearophile
Re: Should we deprecate comma?
Andrei Alexandrescu:
Look at some of the syntaxes here:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
One of the syntaxes:
@{}
@{a}
@{a, b}
@{a, b, c}
WTF???
tuple()
tuple(a)
tuple(a, b)
tuple(a, b, c)
Andrei
So you are saying you want to support a syntax like this?
tuple(a, b, c) = myFunc();
Bye,
bearophile
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 16:41:02 UTC, John Colvin wrote:
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu
wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
On a bigendian machine with loose alignment requirements (1
byte), you can do this
Same again, but for little-endian, 18 instructions:
http://goo.gl/jlrweQ
uint front(char[] s)
{
if(!(s[0] & 0b1000_)) return s[0]; //handle ASCII
assert(s[0] & 0b0100_);
if(s[0] & 0b0010_)
{
if(s[0] & 0b0001_)
{
assert(s.length >=4 && !(s[0] & 0b1000)
&& s[1] <= 0b1011_
&& s[2] <= 0b1011_
&& s[3] <= 0b1011_);
return swapEndian(*(cast(dchar*)(s.ptr)));
}
assert(s.length >= 3 && s[1] <= 0b1011_ && s[2] <=
0b1011_);
return swapEndian(*(cast(dchar*)(s.ptr))) >> 8;
}
assert(s.length >= 2 && s[1] <= 0b1011_);
return swapEndian(*(cast(wchar*)(s.ptr)));
}
Re: Should we deprecate comma?
On 3/24/14, 5:25 AM, w0rp wrote: Please kill the comma operator with fire. Is is just bad. On Monday, 24 March 2014 at 12:20:11 UTC, Marc Schütz wrote: Or, if you really want to distinguish them, this would work: (1,2)two-element tuple (1,) one-element tuple (1) simple expression (,) empty tuple I am a regular Python user, and I advise against using this syntax for tuples. I have been bitten many times by something which I thought was a tuple becoming an expression and something I thought was a simple expression becoming a tuple. It may be less of an issue in a static language, but it will still be an issue. I don't have an alternative syntax to propose. How about tuple(1,2)two-element tuple tuple(1) one-element tuple (1) simple expression tuple() empty tuple Oh, wait... Andrei
Re: Should we deprecate comma?
On 3/24/14, 5:44 AM, bearophile wrote:
w0rp:
I am a regular Python user, and I advise against using this syntax for
tuples. I have been bitten many times by something which I thought was
a tuple becoming an expression and something I thought was a simple
expression becoming a tuple.
I agree, 1-tuples in Python are tricky. Compare it with the clear Python
list literal syntax:
[]=> 0-length list
[1] => 1-length list
[1, 2]=> 2-length list
[1, 2, 3] => 2-length list
Unfortunately ASCII offers a limited choice of delimiters :-)
I don't have an alternative syntax to propose.
Look at some of the syntaxes here:
http://wiki.dlang.org/DIP32#Use_case_of_uniform_tuple_syntax
One of the syntaxes:
@{}
@{a}
@{a, b}
@{a, b, c}
WTF???
tuple()
tuple(a)
tuple(a, b)
tuple(a, b, c)
Andrei
Re: Should we deprecate comma?
On 3/24/14, 5:35 AM, "Marc Schütz" " wrote: 1. How frequent is the breakage? Is most code going to still work? 100x Very infrequent, judging by other peoples' repsonses here, and the fact that there were only a handful of places in all of druntime and Phobos. Breaking druntime and phobos in multiple places counts as very frequent. -- Andrei
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu
wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
On a bigendian machine with loose alignment requirements (1
byte), you can do this, which is down to 13 instructions on x86
(which is of course meaningless, what with it being the wrong
endianess):
uint front(char[] s) {
if(!(s[0] & 0b1000_)) return s[0]; //handle ASCII
assert(s[0] & 0b0100_);
if(s[0] & 0b0010_)
{
if(s[0] & 0b0001_)
{
assert(s.length >=4 && !(s[0] & 0b1000)
&& s[1] <= 0b1011_
&& s[2] <= 0b1011_
&& s[3] <= 0b1011_);
return *(cast(dchar*)(s.ptr));
}
assert(s.length >= 3 && s[1] <= 0b1011_ && s[2] <=
0b1011_);
return *(cast(dchar*)(s.ptr)) >> 8;
}
assert(s.length >= 2 && s[1] <= 0b1011_);
return *(cast(wchar*)(s.ptr));
}
http://goo.gl/Kf6RZJ
There may be architectures that can benefit from this.
Re: dynamic library building and loading
On Tuesday, 18 June 2013 at 20:23:42 UTC, 1100110 wrote: On 06/18/2013 10:14 AM, Bottled Gin wrote: Actually, I seriously doubt everything is working as expected. For example, what happens when an application loads (via dlopen or similar) a D dynamic library: * Are exception handlers registered * Are module infos properly registered * What happens if I call Object.factory, will that find a class in the dynamic library * Are GC sections registered * What happens when the library is unloaded, will all of the above be unregistered and cleaned up Hello D Experts I am replying to an old thread since I want to know if and how the situation has improved over the past few months. In particular I want to link and call fairly complex D functions from a C++ application. I am exclusively using Linux. Can somebody please guide me if I should expect things to work with current DMD master from github? Regards - Puneet There's a DConf talk about shared libraries in D. Perhaps there's useful information there? http://www.youtube.com/watch?v=i63VeudjZM4 (I'm watching it now so I don't know how detailed it is.) Hello all, I'm wondering if this has been resolved to date. I get this error on master: /usr/bin/ld: generated/linux/release/64/libphobos2.so.0.66.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC generated/linux/release/64/libphobos2.so.0.66.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status even though I've built with fPIC: cc -c -m64 -fPIC -O3 etc/c/zlib/trees.c -ogenerated/linux/release/64/etc/c/zlib/trees.o cc -c -m64 -fPIC -O3 etc/c/zlib/uncompr.c -ogenerated/linux/release/64/etc/c/zlib/uncompr.o cc -c -m64 -fPIC -O3 etc/c/zlib/zutil.c -ogenerated/linux/release/64/etc/c/zlib/zutil.o etc...
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 5:51 AM, w0rp wrote: On Monday, 24 March 2014 at 09:02:19 UTC, monarch_dodra wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Before we roll this out, could we discuss a strategy/guideline in regards to detecting and handling invalid UTF sequences? Having a fast "front" is fine and all, but if it means your program asserting in release (or worst, silently corrupting memory) just because the client was trying to read a bad text file, I'm unsure this is acceptable. I would strongly advise to at least offer an option Options are fine for functions etc. But front would need to find an all-around good compromise between speed and correctness. Andrei
Re: Should we deprecate comma?
On 3/24/14, 5:18 AM, "Marc Schütz" " wrote: On Monday, 24 March 2014 at 04:00:14 UTC, Andrei Alexandrescu wrote: On 3/23/14, 8:30 PM, bearophile wrote: How is this more limited change affecting possible future syntax usage of commas for tuples? :-) The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei This is nice, although I guess it will make parsing harder. It probably means that the distinction between "," as operator and tuple element separator will be context-dependent. No, parsing stays the same. You can think of comma returning a tuple. But for now we're forcing that tuple to never be used, so as to not change code semantics. Andrei
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 3:30 AM, dnspies wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Ok, I managed to make it smaller. I think this is the smallest so far with only 23 instructions (no loop unrolling in this one): http://goo.gl/RKF5Vm This is nice because even the checks are relatively cheap. It's quite difficult to understand tho :o). -- Andrei
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 16:31:42 UTC, Andrei Alexandrescu wrote: On 3/24/14, 2:02 AM, monarch_dodra wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Before we roll this out, could we discuss a strategy/guideline in regards to detecting and handling invalid UTF sequences? I think std.array.front should return the invalid dchar on error, and popFront should attempt to resync on error. Ignoring UTF errors is a lossy operation and has the potential problem of irreversible data loss. For example, consider a program which needs to process Windows-1251 files: it would need to read the file from disk, convert to UTF-8, process it, convert back to Windows-1251, and save it back to disk. If a bug causes the UTF-8 conversion step to be accidentally skipped, then all Unicode data in that file is lost. I think UTF-8 decoding operations should, by default, throw on UTF-8 errors. Ignoring UTF-8 errors should only be done explicitly, with the programmer's consent.
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei I like comma operator and use often in my code, it's a very nice syntactic construct for mini-statements. if(len<=optlen)opti=i, optj=j, optlen=len;
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 2:02 AM, monarch_dodra wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Before we roll this out, could we discuss a strategy/guideline in regards to detecting and handling invalid UTF sequences? I think std.array.front should return the invalid dchar on error, and popFront should attempt to resync on error. Andrei
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 1:56 AM, dnspies wrote:
On Monday, 24 March 2014 at 08:06:53 UTC, dnspies wrote:
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
Here's mine (the loop gets unrolled):
dchar front(const char[] s) {
assert(s.length > 0);
byte c = s[0];
dchar res = cast(ubyte)c;
if(c >= 0) {
return res;
}
c <<= 1;
assert(c < 0);
for(int i = 1; i < 4; i++) {
assert(i < s.length);
ubyte d = s[i];
assert((d >> 6) == 0b10);
res = (res << 8) | d;
c <<= 1;
if(c >= 0)
return res;
}
assert(false);
}
Sorry, I misunderstood. We only want the x's in the output. Here's my
revised solution
http://goo.gl/PL729J
That turned out quite large. -- Andrei
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 1:06 AM, dnspies wrote:
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Andrei
Here's mine (the loop gets unrolled):
dchar front(const char[] s) {
assert(s.length > 0);
byte c = s[0];
dchar res = cast(ubyte)c;
if(c >= 0) {
return res;
}
c <<= 1;
assert(c < 0);
for(int i = 1; i < 4; i++) {
assert(i < s.length);
ubyte d = s[i];
assert((d >> 6) == 0b10);
res = (res << 8) | d;
c <<= 1;
if(c >= 0)
return res;
}
assert(false);
}
http://goo.gl/HBSv5T - looks nice! For minimum size replace the
assert(false) with one inside the loop: http://goo.gl/eWs0ft
Andrei
Re: Challenge: write a really really small front() for UTF8
On 3/24/14, 12:53 AM, Chris Williams wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei http://goo.gl/TaZTNB Nice! Why assert(ret != 0)? Andrei
Re: OS X GUI library
On Monday, 24 March 2014 at 16:07:33 UTC, Nikos wrote: On Saturday, 15 February 2014 at 01:43:20 UTC, Anton wrote: On Friday, 14 February 2014 at 18:50:21 UTC, Russel Winder wrote: I have to admit I departed D + QtD for Go + goqml since the former needs effort and the latter has got it. However I have conflict with this as I much prefer D over Go. Yeah, I would hate to have to leave D for something like Go because D doesn't have a decent OS X GUI library. I'll take a look at the links everyone here has posted, thanks. D is good language, but when I'm trying to write something more complex like GtkD virtual data table view, I realize that I can't do it in D. That is, if I want to learn D, I must learn C first. Which is nonsense. So, D needs a good GUI library written in D. And a good IDE too. VisualD is not good enough. I agree that these improvmements would be good. When you say "I can't do it in D" do you mean that you literally need to use C itself, or do you just mean using the C GTK API from D? Bear in mind that D includes many concepts and a lot of syntax C. In order to understand all of D, you will by definition end up learning a lot of C-like things, even if you don't use them very often in your real D code.
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei http://forum.dlang.org/post/fsgdviklnbugdzjsg...@forum.dlang.org
Re: OS X GUI library
On Saturday, 15 February 2014 at 01:43:20 UTC, Anton wrote: On Friday, 14 February 2014 at 18:50:21 UTC, Russel Winder wrote: I have to admit I departed D + QtD for Go + goqml since the former needs effort and the latter has got it. However I have conflict with this as I much prefer D over Go. Yeah, I would hate to have to leave D for something like Go because D doesn't have a decent OS X GUI library. I'll take a look at the links everyone here has posted, thanks. D is good language, but when I'm trying to write something more complex like GtkD virtual data table view, I realize that I can't do it in D. That is, if I want to learn D, I must learn C first. Which is nonsense. So, D needs a good GUI library written in D. And a good IDE too. VisualD is not good enough.
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 15:32:09 UTC, John Colvin wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei I've probably missed something, but here's 15 instructions: http://goo.gl/d3Mgj0 woops yeah, that's completely broken.
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei I've probably missed something, but here's 15 instructions: http://goo.gl/d3Mgj0 Also, I contacted the owner of d.godbolt.org and hopefully we'll have a more up-to-date gdc on there soon. Perhaps ldc as well :)
