Community

On Tue, Jan 15, 2013 at 07:06:05PM +0100, Artur Skawina wrote:
> On 01/15/13 18:52, H. S. Teoh wrote:
> > Probably. And it's probably the reason I dislike today's trend of
> > half-height^W^W I mean, half-width, monitors: I always work with
> > maximized windows, and I don't like overly long lines, so resizing the
> > font to approximately 80 columns at 1920x1080 would literally be
> > half-height for me, even worse than 80x24.
>
> xrandr --output DVI-0 --rotate left
>
> :^)
[...]
That's actually not a bad idea!! Y'know what, I might actually do that
for my next monitor (I think 4:3 monitors are going out of fashion so
fast that in 5 years, they would probably be nowhere to be found). I
shall start a new trend of ultra-high monitors!
T
--
This sentence is false.

On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:
> I really cannot understand the obsession computing people have
> with
> using monospace fonts, I just assume it is a hang over from the
> line
> printer era which created a mindset that most people do not
> challange.
> As soon as computers moved from 80x24 terminals to editors with
> pixel
> based accuracy and nice fonts I ditched all use of monospace
> fonts.
It's not strictly a computing thing; I've known a few editors who
won't work on manuscripts with a proportional font either.
(Though I suspect you're familiar with the classic manuscript
style guidelines.) Personally, I find monospace makes it much
easier to make glyph distinctions and spot errors.

On Tuesday, 15 January 2013 at 18:10:00 UTC, H. S. Teoh wrote:
> I shall start a new trend of ultra-high monitors!
>
About time more people showed up to this party... ;)
Make sure you're getting a panel with VESA mount; many monitors
even at the fairly-high end of the spectrum have cheap stands
that don't give rotation and height adjustment. My current layout
is with the vertical monitor on the left, but I think I prefer it
on the right, more.

On Tue, Jan 15, 2013 at 06:11:46PM +0000, Russel Winder wrote:
[...]
> On Tue, 2013-01-15 at 12:09 -0500, Andrei Alexandrescu wrote:
> […]
> > In book code samples you need frequently to align things vertically
> > (e.g. comments):
> >
> > int a = 42; // the meaning of everything
> > a += 0.1; // error! cannot assign double to int
>
> That sort of alignment is nigh on impossible in a proportional font
> using listing or minted. Of course there is no association between the
> comments so no reason why they should align. Tab alignments
> definitely a bad idea for import by reference material.
[...]
This is exactly the sort of thing where I find proportional fonts
unusable for code.
It's not inherently so, though. I've oft dreamed of a new way of
displaying code, in which same-line comments are displayed in a separate
pane in the editor (rather than intermixed with the code in the same
pane). This comment pane can be adjustable in size and position, and
comments can even be made collapsible (and the code pane would adjust
the amount of space between lines to keep all comments aligned with
their respective lines of code). Why should the textual representation
of the code be conflated with the way it is displayed anyway? Let the
code editor do all the formatting and layout, including alignment of
same-line comments across lines. The actual source file can be free of
all unnecessary whitespace (the compiler doesn't care anyway).
In fact, this allows for very long lines of code (say a complicated
if-condition) to be formatted alongside a long comment block, something
like this:
if ((cond1 && !cond2) || // Check if the complicated
(!cond3 && cond4) || // conditions described earlier
(value1 < value2*16) || // are fulfilled.
(value1 >= minVal))
{
...
}
You never have to manually wrap the code and comment lines yourself
(which would be very painful if you want to keep everything aligned).
The source file could very well represent this thus:
if ((cond1 && !cond2) || (!cond3 && cond4) || (value1 < value2*16) || (value1 >= minVal)) // Check if the complicated conditions described earlier are fulfilled.
{
...
}
and the code editor does the pretty layout for you.
T
--
Spaghetti code may be tangly, but lasagna code is just cheesy.

On 2013-01-15 17:00, H. S. Teoh wrote:
> reading the format string alone says nothing about what meaning is
> intended. What is found in a what? Also, it doesn't let you vary the
> word order correctly. Nor does it let you perform inflection correctly.
>
> For true ease of translation, you need:
>
> 1) Logical naming of format arguments, e.g.:
>
> "%{filename} is found in %{dirname}"
I agree that named arguments are best -- then you don't require extra comments.
As for argument positioning, it already can be specified, for example "%1$s".
> 2) Some way to indicate the function of each word so that inflection can
> be cone correctly, e.g.:
>
> "%{filename.nominative} is found in %{dirname.locative}"
>
> or something like that, in languages where words change form depending
> on function. There will, of course, need to be requisite mechanisms for
> interpreting these word function identifiers.
Filename and dirname don't look like good examples - they don't change.
Well, this is a problem much deeper than providing simple translation, so let's
drop this for now.
> 3) Some way to indicate multiplicity:
>
> "1 file was found" vs. "2 files were found"
>
This is already taken care of in every gettext system I know.
The code would look something like this:
writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
2, "folder X");
where ngettext takes 3 arguments: eng_singular, eng_plural, count.

On 15/01/2013 01:11, Timon Gehr wrote:
<snip>
> I assume you are using thunderbird, because that changed its layout
> fairly recently. You can fix this by right-clicking on the button ->
> 'Customize...' IIRC.
But for some strange reason, getting rid of the Reply button gets rid of
it when viewing email as well. :(
Stewart.

On 15/01/2013 07:24, Tavi Cacina wrote:
<snip>
> That piece of code is correct.
> http://en.wikipedia.org/wiki/Erase-remove_idiom
I must have misread the documentation on cplusplus.com. I'd somehow
made out that it returns an iterator that skips over the "removed" values.
So the semantics of remove are counter-intuitive, and what it actually
does is to change something like [1, 3, 5, 5, 7, 5, 9] into [1, 3, 7, 9,
RG, RG, RG] (RG = random garbage), and return an iterator that points to
the first RG, and then erase is used to delete the elements from that
point to the end of the array. I see now.
But it goes to show that std::remove is counter-intuitve in itself, and
that there ought to be a more intuitive way in STL of doing a
search-and-remove operation.
Still, there's nothing to stop you from writing a function wrapper for
this boilerplate code rather than writing it out every time.
Stewart.

On 15/01/2013 10:20, FG wrote:
<snip>
> All thanks to a terrible naming decision...
> It's not remove but move_to_end. Why call it remove?
It doesn't necessarily move them to the end, going by
http://www.cplusplus.com/reference/algorithm/remove/
"The relative order of the elements not removed is preserved, while the
elements past the new end of range are still valid, although with
unspecified values."
Just looking at the sample implementation there....
if (!(*first == value)) *result++ = *first;
places each non-removed value in its place in the final state of the
container, but doesn't do anything particular with the value where it
was taken from. In a C++11 implementation, I would expect it to become
if (!(*first == value)) *result++ = std::move(*first);
Stewart.

On Tue, Jan 15, 2013 at 09:23:22PM +0100, FG wrote:
> On 2013-01-15 17:00, H. S. Teoh wrote:
> >reading the format string alone says nothing about what meaning is
> >intended. What is found in a what? Also, it doesn't let you vary the
> >word order correctly. Nor does it let you perform inflection
> >correctly.
> >
> >For true ease of translation, you need:
> >
> >1) Logical naming of format arguments, e.g.:
> >
> > "%{filename} is found in %{dirname}"
>
>
> I agree that named arguments are best -- then you don't require extra
> comments. As for argument positioning, it already can be specified,
> for example "%1$s".
Yes, but argument positioning is easy to mix up when the format string
has a lot of arguments. Named arguments are the best. Self-documenting,
and also avoids careless mistakes (like mistyping %1$s when you mean
%2$s).
> >2) Some way to indicate the function of each word so that inflection
> >can be cone correctly, e.g.:
> >
> > "%{filename.nominative} is found in %{dirname.locative}"
> >
> >or something like that, in languages where words change form
> >depending on function. There will, of course, need to be requisite
> >mechanisms for interpreting these word function identifiers.
>
> Filename and dirname don't look like good examples - they don't
> change. Well, this is a problem much deeper than providing simple
> translation, so let's drop this for now.
Yeah filename and dirname are not good examples. A better example (for
Indo-European languages at least) is with verbs:
writeln("The cat %s the dog.", verb);
In some languages, the form of "cat" and "dog" may need to change
depending on what the verb is. But then these cases are probably too
complex to capture in a format string in the first place, so perhaps the
point is moot.
> >3) Some way to indicate multiplicity:
> >
> > "1 file was found" vs. "2 files were found"
>
> This is already taken care of in every gettext system I know.
> The code would look something like this:
>
> writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
> 2, "folder X");
>
> where ngettext takes 3 arguments: eng_singular, eng_plural, count.
What if there are two (or more) items in the string that have counts?
T
--
"Uhh, I'm still not here." -- KD, while "away" on ICQ.