On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis wrote:
> On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:
> > On Fri, Nov 16, 2012 at 08:52:39PM -0500, Jonathan M Davis wrote:
[...]
> > > The problem is that supporting transience complicates ranges even further, and they're already too complicated. And supporting every possible use case is likely to require yet further modifications to ranges, complicating them even further. We have to draw the line somewhere.
> > 
> > Since that is the case, that really only leaves us with two choices:
> > (1) declare transient ranges outright illegal, or (2) make all
> > default ranges non-transient (e.g. ByLine, ByChunk), and let
> > documentation warn the user that transient ranges may not work with
> > every algorithm.
> > 
> > I'm leaning towards (2), because every other option brought up so far sucks one way or another. I know coding by convention is frowned upon here, but clearly, transience is an issue that requires human insight to solve on a case-by-case basis, and no simple enforceable solution exists. Thus, the only choice seems to be to leave it up to the programmer to do the right thing. The redeeming point is that we will make byLine and byChunk non-transient by default, so that users who don't want to care, don't need to care -- the code will just do the right thing by default. We can then provide byLineFast and byChunkFast for people who want the extra performance, and know how to deal with transience correctly.
> > 
> > This solution requires no further code changes beyond making byLine and byChunk non-transient by default, which is what you have been pushing for anyway. And it doesn't have any of the drawbacks of the other approaches.
[...]
> > If we agree on (2), then ranges will be no more complicated than they are today. The two Phobos offenders, byLine and byChunk, will be non-transient by default. The documentation will warn the user that transient ranges are to be "used at your own risk", just like casting void pointers and other risky language features that are nevertheless sometimes necessary.
> 
> I'd agree with #2, except that I don't know where we'd put warnings about transience. On isInputRange? It certainly doesn't make sense to put them on every function. At most, it would make sense to put them where front or popFront is described.
[...]

I'd put it on isInputRange, since that's where .front is defined. Indicate that transient ranges are used "at your own risk" because some algorithms will not work correctly.

And optionally, each algorithm that supports transience can be documented as such (the assumption being that if something isn't explicitly documented to support transience, it probably doesn't).


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher

On 2012-11-22 15:52, Vladimir Panteleev wrote:

> That would be because your browser is using Courier New for the
> monospace CSS font family, which is notable for being smaller than other
> fonts at the same font sizes.
>
> I've overridden the definition to use the same CSS as the forum
> (basically, try "Consolas" before falling back to "monospace"). Does it
> look better now?

It looks really small in Firefox on Mac OS X as well. It has the following style according to firebug:

1em/1.2em monospace

If I remove "1em/1.2em" it looks fine. It looks fine in Safari because there the developer tools just say "monospace".

-- 
/Jacob Carlborg

On 11/22/12, Jacob Carlborg <doob@me.com> wrote:
> It looks really small in Firefox on Mac OS X as well. It has the following style according to firebug:

On Chrome (on win32) it looks ok though.

On Thursday, 22 November 2012 at 18:13:10 UTC, Jacob Carlborg wrote:
> On 2012-11-22 15:52, Vladimir Panteleev wrote:
>
>> That would be because your browser is using Courier New for the
>> monospace CSS font family, which is notable for being smaller than other
>> fonts at the same font sizes.
>>
>> I've overridden the definition to use the same CSS as the forum
>> (basically, try "Consolas" before falling back to "monospace"). Does it
>> look better now?
>
> It looks really small in Firefox on Mac OS X as well. It has the following style according to firebug:
>
> 1em/1.2em monospace
>
> If I remove "1em/1.2em" it looks fine. It looks fine in Safari because there the developer tools just say "monospace".

Do code examples on Wikipedia look fine for you (e.g. http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming )?

On 11/22/12, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> Do code examples on Wikipedia look fine for you (e.g.
> http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming
> )?
>

Those look great.

For dwiki FontFinder says:

Font
===============================
font-family (stack): Consolas,monospace
Font being rendered: monospace
font-size: 10.4px

And for wikipedia:

Font
===============================
font-family (stack): monospace,Courier
Font being rendered: monospace
font-size: 12.8px

On 11/22/2012 8:07 AM, H. S. Teoh wrote:
> On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis wrote:
>> On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:

The way you an Jonathan are replying is breaking the message threading model. How are you doing it?

On 2012-11-22 20:35, Vladimir Panteleev wrote:

> Do code examples on Wikipedia look fine for you (e.g.
> http://en.wikipedia.org/wiki/D_(programming_language)#Metaprogramming )?

Yes, they do. I'm now looking at the "computed" font size in firebug. On wikipedia it says 12.8px. On the new D wiki page it says 10.4px.

-- 
/Jacob Carlborg

On Thursday, November 22, 2012 12:53:36 Walter Bright wrote:
> On 11/22/2012 8:07 AM, H. S. Teoh wrote:
> > On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis wrote:
> >> On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:

> The way you an Jonathan are replying is breaking the message threading model. How are you doing it?

It's threading just fine in my mail client. I do recall there being some issue with newsgroup vs mailing list threading though. Maybe what you're seeing is related to that.

- Jonathan M Davis

On Thu, Nov 22, 2012 at 12:53:36PM -0800, Walter Bright wrote:
> On 11/22/2012 8:07 AM, H. S. Teoh wrote:
> >On Wed, Nov 21, 2012 at 10:10:51PM -0800, Jonathan M Davis wrote:
> >>On Friday, November 16, 2012 18:09:44 H. S. Teoh wrote:
> 
> The way you an Jonathan are replying is breaking the message threading model. How are you doing it?

The threading is fine in my MUA (mutt); I think somebody mentioned some time ago that Mailman is inserting/substituting message IDs where it shouldn't, which causes things to break. I'm not sure exactly what or where, though.


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

On Thursday, November 22, 2012 15:36:58 H. S. Teoh wrote:
> In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

Or even more likely, no design documentation gets written at all...

- Jonathan M Davis