Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 23:27:06 UTC, tsbockman wrote: I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong. I think maybe the C++ approach is better. If you want something into C++ std your best bet is to try to get it into Boost first.
Re: Telegram Supergroup as an alternative to IRC
On Thursday, 16 June 2016 at 14:33:07 UTC, Dechcaudron wrote: Hey there community, I've been using D for the last couple of months already. I usually have to drop by the IRC to ask some fast questions and so on, but IRC and its clients' limitations make it kind of a pain to communicate through it. If anybody uses Telegram around here, its Desktop client would prove an amazing alternative and its supergroups can host up to 5000 people. I understand there are some major differences, but all in all I understand the advantages outweight the cons. Mentions, for example, are way easier to use, as well as replies, link and media sharing... So, anybody willing to join me? Even if it's 3 people in the beggining, it'll be alright. Just send a message to @Dechcaudron from Telegram and I'll answer so we can assemble the group :D In China, the telegarm can not connect server. if use it, must have a proxy.
Re: Areas of D usage
On Wednesday, 15 June 2016 at 20:01:09 UTC, Seb wrote: Thanks a lot for all your help! The initial version is online now & please feel invited to improve upon this document: http://dlang.org/areas-of-d-usage.html Try to view the page as a sceptical visitor and look for signs of a overly slick salesman. Too much text, try to tone down the evangelical subjectivity. It makes me suspicious and I instantly distrust all the information on the page. Is there any substance to «projects that show the rising popularity of D among game developers»? Why describe the language on a page with examples of usage at all? Why not just have one entry for each product and describe D's role in it. For instance, was the entire Remedy game implemented in D? Give a neutral synopsis, then link to the external page.
Re: Garbage Collector
On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote: On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote: I don’t believe a community is capable of creating a good GC. you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field. That's pretty harsh Ketmar. It's obvious he knows the general ideas and was just wondering if using the .NET GC was a viable option. I think responding to others in such a demeaning way is harmful to the D community as it isolates people. It doesn't encourage people to be curious or want to start a discussion. Having people, especially newcomers to D come in and make suggestions and solutions is a great thing for a community. It means they saw enough potential in the language to want to know more and maybe even how they could contribute.
Re: Garbage Collector
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote: Has anyone thought about taking GC from .NET and reusing it in D? One significant point has been already mentioned: cost of write barriers. I'd like to mention another factor: .NET GC is a copying one, it moves data around. One good feature of current D is it never moves data, so you can very easily call C and C++ code and pass pointers to your buffers and stuff and C/C++ code just takes these pointers and works with them as usual. No pinning, no marshaling, zero overhead. If you take a moving GC like .NET's, you immediately make all C/C++ interaction much harder, now you need to worry about pinning stuff or copying "managed" data to "unmanaged" memory and back. This is all costly both in terms of CPU cycles and of programmer cycles. You'll need "FFI", what most other GC-ed languages have to have, and D doesn't.
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 22:30:48 UTC, Walter Bright wrote: Andrei is in charge of the library and has my full support. We've talked many times about raising the bar much higher on Phobos. It's a tough competitive environment for programming languages out there, and we should all expect the review process going forward for Phobos to be brutal. On the other hand, getting an endorsement from Andrei for a design is something anyone should be proud of, and I suspect will be worth the blood, sweat and tears. I know my own code has gotten a lot better from Andrei's professional criticism. There are many ways to go about "raising the bar"; making Andrei the sole arbiter of a design's quality will not necessarily accomplish this, but will make the need for constant communication with him a major bottleneck for development, regardless. It also risks making him into a single point of failure. I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong.
Re: std.experimental.checkedint is ready for comments!
On 6/16/2016 2:11 PM, tsbockman wrote: My problem with `checkedint` was that I formed a wrong idea of whose approval I needed (interested Phobos devs collectively, versus Andrei specifically). Andrei is in charge of the library and has my full support. We've talked many times about raising the bar much higher on Phobos. It's a tough competitive environment for programming languages out there, and we should all expect the review process going forward for Phobos to be brutal. On the other hand, getting an endorsement from Andrei for a design is something anyone should be proud of, and I suspect will be worth the blood, sweat and tears. I know my own code has gotten a lot better from Andrei's professional criticism.
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 21:52:16 UTC, Walter Bright wrote: https://www.digitalmars.com/sargon/halffloat.html Your HTTPS cert seems to be broken
Re: Telegram Supergroup as an alternative to IRC
On Thursday, 16 June 2016 at 17:22:47 UTC, Adam D. Ruppe wrote: What clients are you using? You might look into another one and there's also the bots on the D irc that can help with other things, like ".note somebody the bot will give them this message when they are next active" I think chat things accumulate too many features though... they lose their value if they aren't simple, I prefer email for anything more complex than throw-away lines. Telegram is dead simple. Things like straight mentioning a user, "complex" in IRC if you don't have a proper client, can be done in telegram with a right click. I understand many of you won't be interested. For the rest, the supergroup is already up. Just enter https://telegram.me/dlangTelegram We're only two people so far, but don't push it, these things take time. For me, it's way more convenient to use Telegram than any IRC. Cheers!
Re: Areas of D usage
On Wednesday, 15 June 2016 at 20:01:09 UTC, Seb wrote: ... The initial version is online now & please feel invited to improve upon this document: http://dlang.org/areas-of-d-usage.html As engineer I don't like gears in the 'Embedded applications' paragraph: they are not match.
Re: std.experimental.checkedint is ready for comments!
On 6/16/2016 6:56 AM, Steven Schveighoffer wrote: I understand your frustration. All I can say is, open source contributors have to have a thicker skin (and I'm not saying you don't). We are all human and have our faults, and any team in any context can have miscommunication, or misunderstandings. I can assure you it's not the plan to waste people's time or to cause frustration. Even with a mitigating plan in place, these can happen. Have a plan that you can control, with a viable path if the things you can't don't go your way. +1 Also, if it isn't approved for Phobos, that doesn't necessarily mean the work is wasted. Dub is full of add on libraries, add it there. Approval from others is not necessary. My own Sargon is for things I wrote that were not approved for Phobos for one reason or another: https://www.digitalmars.com/sargon/halffloat.html Work is wasted only when the author gives up on it.
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 21:02:32 UTC, Walter Bright wrote: On 6/15/2016 8:56 PM, tsbockman wrote: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? It's a consequence of starting to read a document cold, i.e. the first thing noticed is the formatting, then the typos, then the names, etc. A deep understanding of the design comes much later, only after having thoroughly read it and hit all the speedbumps of typos, etc. Yes I understand - it's a very natural thing to do (and I have done it myself). I think my suggestion fundamentally boils down to, "Try to communicate to submitters early on who needs to approve their change, and that they may delay addressing all the lesser issues until after their basic proposal has been (tentatively) approved." My problem with `checkedint` was that I formed a wrong idea of whose approval I needed (interested Phobos devs collectively, versus Andrei specifically).
Re: std.experimental.checkedint is ready for comments!
On 6/15/2016 8:56 PM, tsbockman wrote: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? It's a consequence of starting to read a document cold, i.e. the first thing noticed is the formatting, then the typos, then the names, etc. A deep understanding of the design comes much later, only after having thoroughly read it and hit all the speedbumps of typos, etc.
Re: Auto Tester Failing
On 6/16/16 11:24 AM, Steven Schveighoffer wrote: On 6/16/16 10:42 AM, Steven Schveighoffer wrote: On 6/16/16 8:48 AM, Jack Stouffer wrote: Just a heads up that the tests for Win_32_64 are failing due to a missing timezone. All auto merged PRs will not be merged until this is fixed. https://github.com/dlang/phobos/pull/4433 Please don't pull without letting auto-tester run, I haven't tested on Windows. Didn't work. More time zones are missing. I'm going to figure it out and fix. New attempt: https://github.com/dlang/phobos/pull/4434 -Steve
Re: Telegram Supergroup as an alternative to IRC
On Thursday, 16 June 2016 at 14:33:07 UTC, Dechcaudron wrote: I've been using D for the last couple of months already. I usually have to drop by the IRC to ask some fast questions and so on, but IRC and its clients' limitations make it kind of a pain to communicate through it. What clients are you using? You might look into another one and there's also the bots on the D irc that can help with other things, like ".note somebody the bot will give them this message when they are next active" I think chat things accumulate too many features though... they lose their value if they aren't simple, I prefer email for anything more complex than throw-away lines.
Re: Parsing D Maybe Not Such a Good Idea <_<;
On Wednesday, 15 June 2016 at 07:16:31 UTC, Basile B. wrote: You're right it's not so simple and you're also right about "everything", my "everything" is not used adequatly... Sorry, I don't mean to complain. Actually the work has already all been done, rather elegantly in fact. If libdparse can get through a significant subset of D2 code, I have to say I'm pretty impressed with the project, and can't praise it enough. https://github.com/Hackerpilot/libdparse // disclaimer: this link not endorsed by the hackerpilot org ltd It already has a D formatter in it, which dumps (prettified!) D code to any sort of output range, and there's a case in it for every single kind of node in the AST. (speaking of which, when are we getting static switch statements?) What I meant by "D is not simple" isn't that I'm up a creek, without a paddle, but that the paddle is really complex, and I'd have no hope of tackling it if it wasn't already done. The complexity of D's syntax is not so much a problem here, as a spectacle. It depends on the grammatical construct you want to parse. But it's already much more simple when the comments are removed from the lexical token list. I suppose. What's complicated is the shoving of expressions everywhere, since those spider out to all possible forms of construct. That means the difficulty of parsing does NOT depend on the grammatical construct you want to parse, except for a few, very minor constructs, only the ones that don't even *potentially* include expressions in their grammar. So, regardless of what you're doing, you pretty much have to handle every single kind of construct, but if "handle" means "transform, then output" and you can separate those two steps, then if someone does all the output for you, the "transform" step can be very simple and specific. Not because you can remove the comment nodes, but because you can ignore ALL nodes that you're not interested in transforming.
Re: Auto Tester Failing
On 6/16/16 10:42 AM, Steven Schveighoffer wrote: On 6/16/16 8:48 AM, Jack Stouffer wrote: Just a heads up that the tests for Win_32_64 are failing due to a missing timezone. All auto merged PRs will not be merged until this is fixed. https://github.com/dlang/phobos/pull/4433 Please don't pull without letting auto-tester run, I haven't tested on Windows. Great. Please issue the message to stderr. -- Andrei
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 13:56:26 UTC, Steven Schveighoffer wrote: And there is a further problem -- Walter and Andrei are gatekeepers, but are stretched incredibly thin. Having had some time to think about all it now, I believe this was my actual problem. When I started working on this, I was new to the D project and, based on following the GitHub discussions and observing the voting and review process for `std.logger` and `std.ndslice`, I believed that the acceptance process for Phobos was somewhat democratic: the more people who approved of a design, the more likely it would be accepted (with, of course, substantially more weight placed on the opinions of the leadership, who at the time I identified more or less as, "those with merge rights"). Having seen the outcome of the recent auto-decoding discussion, and the way that this review effectively ended abruptly the moment that Andrei Alexandrescu decided that he didn't like my design for `checkedint` - despite a number of other people earlier speaking positively of it - I now perceive that the democratic aspects of the Phobos process are essentially advisory in nature, with little-to-no real authority attached to them. I do not intend this as a criticism, as I am not a stickler for democracy. I do think this should be communicated clearly to future new contributors, though, to avoid confusion. (Keep in mind that I joined the project before the "all new Phobos symbols must be approved by Andrei" rule was announced.) Anyway, I think I see things from Andrei's perspective now, and would like to apologize for taking offense, now that I understand his role better. I will, however, be ending my participation in the D development process, as I am not personally interested in working in an environment where everything I do needs pre-approval from someone with his opinions and leadership style (this is not specifically about `checkedint`) - especially since he seems too busy to effectively manage more contributors using the current system, anyway. I will continue to be available for follow-up on the work I have already done, and will try to finish at least some of my current pending pull requests. I wish D well, and may still post on the forums once in a while.
Re: Auto Tester Failing
On 6/16/16 10:42 AM, Steven Schveighoffer wrote: On 6/16/16 8:48 AM, Jack Stouffer wrote: Just a heads up that the tests for Win_32_64 are failing due to a missing timezone. All auto merged PRs will not be merged until this is fixed. https://github.com/dlang/phobos/pull/4433 Please don't pull without letting auto-tester run, I haven't tested on Windows. Didn't work. More time zones are missing. I'm going to figure it out and fix. -Steve
Re: Anybody still using the chm docs
On Wednesday, 15 June 2016 at 11:54:31 UTC, captaindet wrote: It's a huge maintenance effort for us to produce the chm files. ... So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? i am very glad the chm file exists whenever i am not online, e.g. on a plane or train (free wifi is not a given everywhere). finding something in the local html is quite awkward w/o google... if it really takes up too much time i will understand if it has to go too, especially if i a am the minority. just saying: i do use it occasionally, and whenever i do it is a big help. /det +1
Re: Anybody still using the chm docs
What's the main difference between it and just pointing your browser at the downloaded html files? Search and index? Well, seach and index are not the only operations you need. One of the common operation with every CHM viewer is to bookmark something for an example. I've just checked the Zeal application and realised it does not have this simple feature (or I could not find it). Also, I want it to open at the same place I was last time I used the viewer... Simply run KChmViewer and open the CHM document from DMD package with it, and compare it with any other similar solution...
Re: Auto Tester Failing
On 6/16/16 8:48 AM, Jack Stouffer wrote: Just a heads up that the tests for Win_32_64 are failing due to a missing timezone. All auto merged PRs will not be merged until this is fixed. https://github.com/dlang/phobos/pull/4433 Please don't pull without letting auto-tester run, I haven't tested on Windows. -Steve
Re: Telegram Supergroup as an alternative to IRC
On 17/06/2016 2:33 AM, Dechcaudron wrote: Hey there community, I've been using D for the last couple of months already. I usually have to drop by the IRC to ask some fast questions and so on, but IRC and its clients' limitations make it kind of a pain to communicate through it. If anybody uses Telegram around here, its Desktop client would prove an amazing alternative and its supergroups can host up to 5000 people. I understand there are some major differences, but all in all I understand the advantages outweight the cons. Mentions, for example, are way easier to use, as well as replies, link and media sharing... So, anybody willing to join me? Even if it's 3 people in the beggining, it'll be alright. Just send a message to @Dechcaudron from Telegram and I'll answer so we can assemble the group :D You're hard pressed to consider even XMPP as a replacement for IRC. Its a highly mature technology with clear solutions for all necessary usage patterns. Not to mention there are clients on pretty every platform imaginable. So no, Telegram has 0 advantages over IRC. It only has cons. Don't expect anybody to consider it seriously and yes there are some of us on e.g. gitter and Discord its just not used in any real form.
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 06:55:00 UTC, lobo wrote: Has this work/design been submitted as a DIP? I cannot find it. I thought all Phobos additions of any magnitude were required to pass the DIP submission first in order to avoid this sort of situation. If there is a DIP that was accepted then to have it knocked back now would suck. Without a DIP you have to expect the design could be turned down by any core developer when they first get the opportunity to review it, no matter how long after the work was initiated. bye, lobo My observation has been that the DIP process is not followed, in practice. The DIP for this project (which I did not start; I merely continued @burner's work) is actually the same one as that of the recently accepted `ndslice`: https://wiki.dlang.org/DIP80
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 12:25:39 UTC, Andrei Alexandrescu wrote: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? I don't think people are doing it on purpose - it's just easier to start with the trivial nit-picks, because you don't need a deep understanding of the code and the problem domain (or decision-making authority) to complain about a missing ' ' or something. I can see how that could be happening. Often (and in this case) there are different folks touching on the different points. Yes, it's mostly a process issue, not an individual one. See my earlier reply to John Colvin, for a practical suggestion as to how to improve with this.
Telegram Supergroup as an alternative to IRC
Hey there community, I've been using D for the last couple of months already. I usually have to drop by the IRC to ask some fast questions and so on, but IRC and its clients' limitations make it kind of a pain to communicate through it. If anybody uses Telegram around here, its Desktop client would prove an amazing alternative and its supergroups can host up to 5000 people. I understand there are some major differences, but all in all I understand the advantages outweight the cons. Mentions, for example, are way easier to use, as well as replies, link and media sharing... So, anybody willing to join me? Even if it's 3 people in the beggining, it'll be alright. Just send a message to @Dechcaudron from Telegram and I'll answer so we can assemble the group :D
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 07:02:21 UTC, John Colvin wrote: I think anything sufficiently large is likely to be reviewed in that order. In a lot of cases all the work for 1 - 8 is progressively done while working out 9. Should people not mention the smaller mistakes / disagreements they find along the way until they've reached the end and can provide a final judgement? I think that consideration should be given to splitting reviews into two phases by policy: 1. The big picture: refining the overall design, and debating whether the change is worthwhile or not. This ends when the change has been formally approved by someone who has the authority to do so. 2. Completing and polishing the implementation, until it is actually ready to merge. Distinguish clearly between these phases, and make it clear to submitters that they are not required or expected to fix/finish all the little stuff until (1) is over, since there's a good chance it will all be irrelevant, anyway. Obviously there will be some fuzziness as to whether an issue belongs in (1) or (2), but there's lots and lots of stuff that clearly falls into one or the other. One of the things that such a policy would accomplish is to highlight the essential (but often ignored) question, "Who actually has authority to approve this?"
Re: Is GC smart enough not to reallocate?
On Thursday, 16 June 2016 at 13:54:11 UTC, MMJones wrote:
Suppose one has something like
class foo
{
int[] x;
void bar()
{
x = [];
}
}
Does the GC trash the "cache" when calling bar or does it
realize that it can use the same memory for x and essentially
just shortens the array?
Is it equivalent to setting length = 0?
I'm a bit worried that setting a managed array to [] might
cause a completely new reallocation, which is unnecessary and
undesirable.
To prevent confusion, here's a related example:
void foo()
{
int[] x = [1,2,3];
x = [4];
}
in theory, the first allocation (for [1,2,3]) could be avoided.
It wouldn't be the GC doing it though, it would just be the
optimiser eliminating the redundant initialisation of x.
However:
class C
{
int[] x;
this()
{
x = [3,2,1];
}
void foo()
{
x = [0];
}
}
auto bar()
{
auto c = new C;
auto localX = c.x;
c.foo();
return localX;
}
the initialisation of c.x is no longer redundant, because the
memory is referenced by localX, so a new allocation is necessary
in foo.
P.S. remember that D's arrays/slices aren't "managed" as such.
Only the memory backing them is managed, and then only if the
memory was allocated by the GC.
Re: Anybody still using the chm docs
On Thursday, 16 June 2016 at 13:18:23 UTC, Dejan Lekic wrote: I still use CHM document as it is absolutely the best solution compared to anything else. What's the main difference between it and just pointing your browser at the downloaded html files? Search and index?
Is GC smart enough not to reallocate?
Suppose one has something like
class foo
{
int[] x;
void bar()
{
x = [];
}
}
Does the GC trash the "cache" when calling bar or does it realize
that it can use the same memory for x and essentially just
shortens the array?
Is it equivalent to setting length = 0?
I'm a bit worried that setting a managed array to [] might cause
a completely new reallocation, which is unnecessary and
undesirable.
Re: Is GC smart enough not to reallocate?
On 6/16/16 9:54 AM, MMJones wrote:
Suppose one has something like
class foo
{
int[] x;
void bar()
{
x = [];
}
}
Does the GC trash the "cache" when calling bar or does it realize that
it can use the same memory for x and essentially just shortens the array?
If you reassign x, the compiler does not know enough context to assume
nothing else has a reference to x's old data. So no, it would not re-use
that same data.
Is it equivalent to setting length = 0?
Even this is not going to overwrite the data. You'd need to do:
x.length = 0;
x.assumeSafeAppend;
I'm a bit worried that setting a managed array to [] might cause a
completely new reallocation, which is unnecessary and undesirable.
Use assumeSafeAppend when you need to do this.
BTW, x = [] is equivalent to x = null. So this is most certainly going
to cause a new allocation on the next append.
-Steve
Re: Anybody still using the chm docs
On Thursday, 16 June 2016 at 02:32:05 UTC, Jack Stouffer wrote: On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? For offline browsing, Windows and Linux users can use Zeal [1] which is FOSS, and macOS users can use Dash[2], which is free as in beer. Both of which can use this D docset [3]. So no, there's no reason to maintain the chm docs. [1] https://zealdocs.org/ [2] https://kapeli.com/dash [3] https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme Thanks for the Zeal, I did not know about it. Both Gnome and KDE have their "help" tools that more/less do the same.
Re: std.experimental.checkedint is ready for comments!
On 6/15/16 11:56 PM, tsbockman wrote: On Thursday, 16 June 2016 at 02:53:38 UTC, Andrei Alexandrescu wrote: On 6/15/16 9:34 PM, tsbockman wrote: Why didn't you make your design requirements known at any earlier point in this process? If you are ultimate gate keeper for Phobos (as you seem to be), you ought to make your requirements known *before* the implementation is finished. Apologies about that. I've done a bit of spelunking to see what happened. Indeed the first reference to SafeInt is on a forum post on 6/7/2015, followed immediately by https://github.com/dlang/phobos/pull/3389 which entailed a long discussion. You first posted about checkedint here on 6/30/2015, in a large thread. At that time, I had the std.allocator review going on (started on 6/11/2015), a newborn baby, and a move across the continent to worry about (which happened at the end of June). It is entirely possible I just missed that discussion, or more likely saw it and had no meaningful input at the time. There has been a gap in forum posts with "checkedint" in the title between 7/3/2015 and 6/7/2016, Numerous other mentions were made of this project in various contexts on the forums, in GitHub pull requests, and on the bug tracker - including discussions in which you participated. 'posts with "checkedint" in the title' is too narrow of a search filter. so it's not like there was a continuing presence I was working hard to ignore. I honestly think there's nothing to be offended over. Malicious intent is not required to make the act offensive; you're still jumping into a project a year in the making and demanding that I choose between investing an additional six months (wild guess) of my time working on things I don't care about (at best), or canceling the project (which has otherwise received generally positive feedback so far). I am not too upset mostly because I had a variety of reasons for pursuing this, not all of which depend on getting it into Phobos. This underlies a larger issue. There must be a protocol that guarantees a proposal is brought to consideration to the D leadership. Dicebot is leading such an initiative (which can be seen as a revamping of DIPs) and we hope to get it finalized soon. Andrei That is part of the problem, but this is also a fine example of a broader pattern that I have noticed in D's review process: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? This is a good point. I personally have avoided doing anything in 1-8 unless I first agree it's a change I think we should accept. Which then results in 0) nobody is looking at this!??? I will occasionally chime in when there is a particular pain point with design philosophy, but the problem is, this gives the impression that I am willing to accept the change after X nitpicks are done. I try not to do this unless there is another reviewer that seems motivated to do a full review who has already posted, and they haven't covered that piece. On the other hand, peoples minds can change. e.g: "The early iterations of `checkedint` worked this way (although I had no plans to support user-defined hooks). I implemented and debugged it, and thought it was about ready to submit many months ago. Then I actually tried *using* it, and hated it." And there is a further problem -- Walter and Andrei are gatekeepers, but are stretched incredibly thin. So a reviewer that is keen on a certain addition may put in a lot of time on steps 1-8 assuming that step 9 is a given, and when W/A come around to looking at it, they say no. How to fix this? I don't know. The only recommendation I have is to do 2 things: 1. Get pre-approval if you have your heart set on Phobos inclusion. Make SURE you understand the expectations from Andrei and Walter. 2. Be willing to put it on code.dlang.org instead, and Phobos as a secondary goal (your approach). I had a similar experience with dcollections, though I never really intended on it being in Phobos, it was meant for Tango. But that didn't work out either, as the gatekeeper there was working on his own version of containers. Unless the PR is a complete mess, (9) and (8) should be debated *first*, before worrying about any of the other stuff. Why waste people's time fixing trivialities, if it's all going to just be deleted or rewritten anyway? I understand your frustration. All I can say is, open source contributors have to have a thicker skin (and I'm not saying you don't). We are all human and have our faults, and any team in any context can have miscommunication, or misunderstandings. I can assure you it's not the plan to waste people's time or to cause frustration. Even with a mitigating plan in place, these can happen. Have a plan that you can control, with a viable path if the things you can't don't go your way.
Re: Anybody still using the chm docs
On 17/06/2016 1:22 AM, Dejan Lekic wrote: I still use CHM document as it is absolutely the best solution compared to anything else. I think it is a mistake to compare CHM with PDF... They are made for different things... I forgot to mention - I use CHM on Linux. It is not my fault that opensource community could not come up with a better or/and standardised solution... The only standard solution for this that Linux has are man pages - clearly not suitable this purpose! Other, better solutions are there, but are not adopted by all - Gnome has one format, KDE another, etc... CHAOS. Therefore, I decided to use CHM. It's doable to have epub generation[0]. PDF can do a heck a lot more then what most people even know[1]. [0] http://master.dl.sourceforge.net/project/d-apt/files/doc/2.071.0/dlangspec-2.071.0.epub [1] http://help.adobe.com/en_US/acrobat/acrobat_dc_sdk/2015/HTMLHelp/#t=Acro12_MasterBook%2FJS_API_AcroJSPreface%2FJS_API_AcroJSPreface.htm
Re: Anybody still using the chm docs
I still use CHM document as it is absolutely the best solution compared to anything else. I think it is a mistake to compare CHM with PDF... They are made for different things... I forgot to mention - I use CHM on Linux. It is not my fault that opensource community could not come up with a better or/and standardised solution... The only standard solution for this that Linux has are man pages - clearly not suitable this purpose! Other, better solutions are there, but are not adopted by all - Gnome has one format, KDE another, etc... CHAOS. Therefore, I decided to use CHM.
Re: Anybody still using the chm docs
On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: It's a huge maintenance effort for us to produce the chm files. We no longer generate documentation on Windows, but just for the chm generation we have dedicated tools [¹] to create an index (from a json generated via ddoc) and copy the html files. So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? https://github.com/dlang/dlang.org/pull/1374 [¹]: https://github.com/dlang/dlang.org/blob/7cc6e938154f90aa49fa6451a85b13e35ab2de99/chmgen.d I still use CHM document as it is absolutely the best solution compared to anything else. I think it is a mistake to compare CHM with PDF... They are made for different things... If people want to get rid of PDF, then I propose we start providing ePub instead of CHM. That could be the only sane alternative to the CHM we have.
Auto Tester Failing
Just a heads up that the tests for Win_32_64 are failing due to a missing timezone. All auto merged PRs will not be merged until this is fixed.
Re: Anybody still using the chm docs
On Thursday, 16 June 2016 at 11:04:48 UTC, Martin Nowak wrote: On Thursday, 16 June 2016 at 02:32:05 UTC, Jack Stouffer wrote: For offline browsing, Windows and Linux users can use Zeal [1] which is FOSS, and macOS users can use Dash[2], which is free as in beer. Both of which can use this D docset [3]. So no, there's no reason to maintain the chm docs. [1] https://zealdocs.org/ [2] https://kapeli.com/dash [3] https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme Interesting, is this generated from the html pages? Yeah
Re: std.experimental.checkedint is ready for comments!
On 6/16/16 2:55 AM, lobo wrote: Without a DIP you have to expect the design could be turned down by any core developer when they first get the opportunity to review it, no matter how long after the work was initiated. We're still working on making DIPs a process that requires leadership to intervene, but I'd say this is already true now. Per the title of this thread: "std.experimental.checkedint is ready for comments!". What kind of comments were expected? Andrei
Re: std.experimental.checkedint is ready for comments!
On 6/15/16 11:56 PM, tsbockman wrote: Numerous other mentions were made of this project in various contexts on the forums, in GitHub pull requests, and on the bug tracker - including discussions in which you participated. 'posts with "checkedint" in the title' is too narrow of a search filter. I am sure there were, which was especially visible to you because you were following the project. Some examples would be helpful so I can learn from them. so it's not like there was a continuing presence I was working hard to ignore. I honestly think there's nothing to be offended over. Malicious intent is not required to make the act offensive; you're still jumping into a project a year in the making and demanding that I choose between investing an additional six months (wild guess) of my time working on things I don't care about (at best), or canceling the project (which has otherwise received generally positive feedback so far). Agreed malice is not required. But I'm still having trouble seeing the offense. Annoyance at a negative review, sure, we're all human. But taking offense? The closest anything came to "demanding" anything has been: This suggests a much simpler design [...] But I suggest you to reconsider. How could I have phrased my review and follow-up in ways that are not offensive? Should I have just accepted the proposal on grounds that a lot of work has been put into it and the deadline has passed for influencing it? (Non-rhetorical questions.) Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? I don't think people are doing it on purpose - it's just easier to start with the trivial nit-picks, because you don't need a deep understanding of the code and the problem domain (or decision-making authority) to complain about a missing ' ' or something. I can see how that could be happening. Often (and in this case) there are different folks touching on the different points. Andrei
Re: Example on dlang.org // Round floating point numbers
On 16-Jun-2016 14:55, Martin Tschierschke wrote: The example // Round floating point numbers with the floating point substitution using the Regex: reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`; To something like `[0-9]+\.[0-9]+(?![^.])` Is not so nice, because it would match for dates like 16.06.2016, too. (I remember having a simmilar problem when trying to substitute 123.44 Euro to German format: 123,44 Euro ending up with a modified date: 16,06.2016) Sure this may be not the point of the example, but I dislike it therefore. How to expand the Regex not to match dates? Regards martin -- Dmitry Olshansky
Example on dlang.org // Round floating point numbers
The example // Round floating point numbers with the floating point substitution using the Regex: reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`; Is not so nice, because it would match for dates like 16.06.2016, too. (I remember having a simmilar problem when trying to substitute 123.44 Euro to German format: 123,44 Euro ending up with a modified date: 16,06.2016) Sure this may be not the point of the example, but I dislike it therefore. How to expand the Regex not to match dates? Regards martin
Email snafu
Hi folks, due to an email snafu I accidentally archived all of my Inbox email last night (I fell asleep pressing 'A'). I'm now going back through my archive trying to recover emails that are still waiting for an answer. Of those, some are related to D work that I might be missing. Kindly please resend if you can. Thanks! -- Andrei
Re: Anybody still using the chm docs
On Thursday, 16 June 2016 at 02:32:05 UTC, Jack Stouffer wrote: On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote: So I'm wondering if in 2016 someone really needs an offline copy of a website shipped with a binary release? For offline browsing, Windows and Linux users can use Zeal [1] which is FOSS, and macOS users can use Dash[2], which is free as in beer. Both of which can use this D docset [3]. So no, there's no reason to maintain the chm docs. [1] https://zealdocs.org/ [2] https://kapeli.com/dash [3] https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme Interesting, is this generated from the html pages?
Re: Fixed date to move to ddox for Phobos documentation
On 2016-06-04 18:10, Seb wrote: More than two and half years ago, Sönke added ddox builds for the Phobos documentation. We all know that there are many reasons for ddox - being able to generate single pages for methods is just one, it also eliminates all the JavaScript hacks (e.g. the quickindex menu, anchors, ...) that we have added over time to deal with the shortcomings of ddoc. This post originates from a recent discussion [2] that showed the higher ranking of the ddox pages in search engines because of those single pages, more static content and meta information. To quote Adam [3]: ddox got a decent go up to here. But then we need to decide what's next - a clear goal, including a due date, gets us all aligned and removes a lot of the uncertainty on the author's side; it is some reassurance that they aren't wasting their time, and encourages outside teams to get onboard. We got the MREF change into Phobos a month ago and Sönke has fixed the last blocking bug with ddox (broken source code links) a couple of days ago. Just found this issue [1], symbols are hyphenated in Safari. [1] https://github.com/rejectedsoftware/ddox/issues/126 -- /Jacob Carlborg
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 03:56:02 UTC, tsbockman wrote: That is part of the problem, but this is also a fine example of a broader pattern that I have noticed in D's review process: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? I don't think people are doing it on purpose - it's just easier to start with the trivial nit-picks, because you don't need a deep understanding of the code and the problem domain (or decision-making authority) to complain about a missing ' ' or something. But, that doesn't change the fact that the process still feels almost perfectly designed to waste contributors' time. Unless the PR is a complete mess, (9) and (8) should be debated *first*, before worrying about any of the other stuff. Why waste people's time fixing trivialities, if it's all going to just be deleted or rewritten anyway? I think anything sufficiently large is likely to be reviewed in that order. In a lot of cases all the work for 1 - 8 is progressively done while working out 9. Should people not mention the smaller mistakes / disagreements they find along the way until they've reached the end and can provide a final judgement?
Re: std.experimental.checkedint is ready for comments!
On Thursday, 16 June 2016 at 03:56:02 UTC, tsbockman wrote: On Thursday, 16 June 2016 at 02:53:38 UTC, Andrei Alexandrescu wrote: [...] Numerous other mentions were made of this project in various contexts on the forums, in GitHub pull requests, and on the bug tracker - including discussions in which you participated. 'posts with "checkedint" in the title' is too narrow of a search filter. [...] Malicious intent is not required to make the act offensive; you're still jumping into a project a year in the making and demanding that I choose between investing an additional six months (wild guess) of my time working on things I don't care about (at best), or canceling the project (which has otherwise received generally positive feedback so far). I am not too upset mostly because I had a variety of reasons for pursuing this, not all of which depend on getting it into Phobos. [...] That is part of the problem, but this is also a fine example of a broader pattern that I have noticed in D's review process: Pull requests are routinely reviewed in an upside-down fashion: 1) Formatting 2) Typos 3) Names 4) Tests (and names again) 6) Docs (and names) 8) Design (and more about names) 9) Does this even belong in Phobos? I don't think people are doing it on purpose - it's just easier to start with the trivial nit-picks, because you don't need a deep understanding of the code and the problem domain (or decision-making authority) to complain about a missing ' ' or something. But, that doesn't change the fact that the process still feels almost perfectly designed to waste contributors' time. Unless the PR is a complete mess, (9) and (8) should be debated *first*, before worrying about any of the other stuff. Why waste people's time fixing trivialities, if it's all going to just be deleted or rewritten anyway? Has this work/design been submitted as a DIP? I cannot find it. I thought all Phobos additions of any magnitude were required to pass the DIP submission first in order to avoid this sort of situation. If there is a DIP that was accepted then to have it knocked back now would suck. Without a DIP you have to expect the design could be turned down by any core developer when they first get the opportunity to review it, no matter how long after the work was initiated. bye, lobo
