Mailing List Archive

William L. Thomson Jr. wrote:
> Just a quick thought looking over a couple ebuilds. It seems most times
> anyone does a error, elog, einfo, or similar. They start and end with a
> few blank lines. Calls with no arguments.
>
> Is there any reason not to make that a default? Other than difficulty of
> implementation. Anytime they are invoked back to back. Default blank
> lines are added at the beginning or end.

I have run into the same dilemma - wanting to separate blocks of
warnings/logs/info by blank space. And the particular issue I've run
into is which calls to use (i.e. what color to make the "*"). For
example, I might have two possible warnings back-to-back, and each is
conditional:

if ! use flac; then
ewarn "'flac' USE flag is not set. Blah, blah..."
ewarn "More blah blah..."
ewarn ""
fi
if ! use lame; then
ewarn "'lame' USE flag is not set. Blah, blah..."
ewarn "More blah blah..."
ewarn ""
fi

Problem is, the blank line doesn't really belong in the "warning" itself
- it's meant as a separator. And if both happen, it makes sense to
color the "*" logically (should it be yellow rather than, say, green?
If the next block of output is "green", it can look funny to see a blank
yellow as the separator, for example.

Also, there is that question of whether to put the blank line before or
after the block, and if conditional, it can be tricky to make the full
output look nice for all possibilities. I tend not to want to put a
blank line at the very end of the output (trying to be consistent with
most other ebuilds), even though that might make things more clear.
Also, I don't know inside the conditional whether it might be the last
block of output or of another conditional might follow (for example).

So I am in favor of some smart code in portage to do "nice looking"
blank line logic that would also make reading the output more clear.
Something like "eblank" or "eseparator" could be aware of the previous
and next "color" and do the right thing. Putting a blank line
consistently at the end of the ebuild output but before portage's end
summary would be nice as well (and make it easier to spot problems when
looking at the output). Also, if the ebuild itself tries to insert
blanks at the start or end, portage could remove those and enforce its
own spacing rules...

-Joe
--
gentoo-dev@lists.gentoo.org mailing list

On Wed, 2008-06-04 at 18:45 -0600, Ryan Hill wrote:
>
> I just throw a couple echos around any output.

Surely more than one way

> I think doing any kind of automatic pretty-print formatting is
> overkill, but that's just my opinion.

Yes to a point. Starting having multiple blocks like that, and your
added 2 lines per for really no reason.

I think a more ideal solution, less drastic to implement might be
allowing 2 arguments to be passed. So you could do like

elog "" "A blank line precedes this one"
elog "A blank line follow this one" ""

Then maybe if a argument = "" it can be swapped out for echo :)

--
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation

On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote:
>
> I think a more ideal solution, less drastic to implement might be
> allowing 2 arguments to be passed. So you could do like
>
> elog "" "A blank line precedes this one"
> elog "A blank line follow this one" ""

Actually 3, not sure there would be any need for more. 3 for 1 liners

elog "" "USE flag milf not set" ""

--
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation

William L. Thomson Jr. wrote:
> On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote:
>> I think a more ideal solution, less drastic to implement might be
>> allowing 2 arguments to be passed. So you could do like
>>
>> elog "" "A blank line precedes this one"
>> elog "A blank line follow this one" ""
>
> Actually 3, not sure there would be any need for more. 3 for 1 liners
>
> elog "" "USE flag milf not set" ""

Well, I'm not sure how that adds anything over just using echo, and if I
simply wanted to statically insert a blank line, I'd rather use echo on
a separate line in the ebuild, since that would be more clear.

The problem with a simple echo is that no "*" appears on the left to
maintain continuity with the rest of the output - and in a color that
makes sense in the context (maybe this isn't a "problem" - it depends on
whether that visual continuity is desired).

Also, there are those times when inserting a blank line depends on what
comes after (or before) - and if a "*" is used, the color depends on
this too. That can only be solved at a higher level (i.e. in portage).

This is all just food for thought. I happen to be into aesthetics (and,
BTW, I think Gentoo does a great job already in its use of colors,
etc.), so I think it is important to think about these things, but it's
certainly not the *most* important issue to ponder. :)

-Joe
--
gentoo-dev@lists.gentoo.org mailing list

Joe Peterson wrote:
> The problem with a simple echo is that no "*" appears on the left to
> maintain continuity with the rest of the output - and in a color that
> makes sense in the context (maybe this isn't a "problem" - it depends on
> whether that visual continuity is desired).

The far biggest problem of echo is IMHO that it's not part of the elog
framework, which means you will see only it if you are watching the
thing build. But it won't be processed by anything else set in
PORTAGE_ELOG_SYSTEM, for example the "echo" system which reprints all
gathered elog stuff from all built packages when emerge finishes, and
which I find very useful. Absence of newlines there makes that however
often hardly readable.

Using elog commands instead of plain echo helps this, but as you
mentioned, could be done better. So I'm also for some *unified* way to
specify separators in elog commands. I would prefer something that
doesn't add extra lines to ebuild. So how bout some switch to elog
commands that adds extra newline after the message, might look better
than wltjr's "" proposal. There could be also switch to add newline
before the message but I can't think of a use for it myself.
The question is how to name the switch :) "-n" could be confusing as
"echo -n" has the opposite effect. Maybe "-b" for "blank"?

--
Vlastimil Babka (Caster)
Gentoo/Java

On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote:
> Joe Peterson wrote:
> > The problem with a simple echo is that no "*" appears on the left to
> > maintain continuity with the rest of the output - and in a color that
> > makes sense in the context (maybe this isn't a "problem" - it depends on
> > whether that visual continuity is desired).
>
> The far biggest problem of echo is IMHO that it's not part of the elog
> framework,

Well I mostly included echo as a joke/pun per one of the other
comments :)

> So how bout some switch to elog
> commands that adds extra newline after the message, might look better
> than wltjr's "" proposal.

Crude I agree, but at least point for shorthand was understood :)

> There could be also switch to add newline
> before the message but I can't think of a use for it myself.
> The question is how to name the switch :) "-n" could be confusing as
> "echo -n" has the opposite effect. Maybe "-b" for "blank"?

Or -p for preceding -t for trailing. Which would make one liner

elog -pt "One line with blank ones before and after"

--
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation

William L. Thomson Jr. wrote:
> On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote:
>> There could be also switch to add newline
>> before the message but I can't think of a use for it myself.
>> The question is how to name the switch :) "-n" could be confusing as
>> "echo -n" has the opposite effect. Maybe "-b" for "blank"?
>
> Or -p for preceding -t for trailing. Which would make one liner
>
> elog -pt "One line with blank ones before and after"

The comment from Vlastimil about echo not being part of the elog system
is a very valid point indeed. As for how to specify that a newline
should be inserted, I think that using elog switches like "-n", "-p",
etc., as well as putting more than one string on a line present two
problems: the newline would be "connected" with the "elog" or "ewarn"
(or whatever style of output was chosen) and it would also potentially
make the ebuild code harder to read/debug. For example, if you have a
block of "ewarn" lines, then a blank line, then a block of "elog" lines,
you would have to decide in which style to place the special switch (so
portage would not have the opportunity to do auto-context
coloring/formatting).

I personally would prefer a new command like "eseparator" that could be
treated "smartly" by portage, taking on the appropriate color based on
what is before and after. It could also avoid multiple newlines in the
case in which two eseparator lines occur together due to pattern of
conditional blocks in the ebuild invoked under certain circumstances (I
have found this hard to code in a way that covers all possibilities, as
I mentioned before). Also, separators at the very beginning or very end
of all lines output by the ebuild could be handled consistently (either
ignored or collapsed into an implicit separator, as appropriate) by
portage to produce nice output.

-Joe
--
gentoo-dev@lists.gentoo.org mailing list

Joe Peterson wrote:
> The comment from Vlastimil about echo not being part of the elog system
> is a very valid point indeed. As for how to specify that a newline
> should be inserted, I think that using elog switches like "-n", "-p",
> etc., as well as putting more than one string on a line present two
> problems: the newline would be "connected" with the "elog" or "ewarn"
> (or whatever style of output was chosen)

In the ebuild it would look like connected but in fact portage could
just note that there was a newline switch and output it in whatever
style it wants.

> and it would also potentially
> make the ebuild code harder to read/debug.

Well you can always insert a completely blank line in the ebuild after a
"-n" message. That's easier to read than a "eseparator" line.

> For example, if you have a
> block of "ewarn" lines, then a blank line, then a block of "elog" lines,
> you would have to decide in which style to place the special switch (so
> portage would not have the opportunity to do auto-context
> coloring/formatting).

Like I said above, it still has the oportunity to do whatever it wants.

> I personally would prefer a new command like "eseparator" that could be
> treated "smartly" by portage, taking on the appropriate color based on
> what is before and after. It could also avoid multiple newlines in the
> case in which two eseparator lines occur together due to pattern of
> conditional blocks in the ebuild invoked under certain circumstances (I
> have found this hard to code in a way that covers all possibilities, as
> I mentioned before). Also, separators at the very beginning or very end
> of all lines output by the ebuild could be handled consistently (either
> ignored or collapsed into an implicit separator, as appropriate) by
> portage to produce nice output.

That should all be possible with the switches, unless I miss something.
My idea is that a switch for "post-newline" is enough, and there's no
need for "pre-newline". You use that switch whenever you end a logical
block of elog lines. Portage just notes you used it, and when another
elog comes, newline is emitted first. Multiple newlines should not even
happen (and if yes, could be easily collapsed). Last newline of the
ebuild is just consumed.
Or perhaps use this processing only for the elog post-processing system
(which I personally think matters more), and during the build itself
emit the newlines immediatelly so that non-elog output is not tied too
closely to ends of elog blocks.
--
Vlastimil Babka (Caster)
Gentoo/Java

Vlastimil Babka <caster@gentoo.org> wrote:

> I would prefer something that
> doesn't add extra lines to ebuild.

I think I would disagree with you here. I think that having a special
'eblank' or 'eseparator' command is much more readable in an ebuild.
Consider:

pkg_postinst() {
elog "Knock knock"
eblank
ewarn "Who's there?"
eblank
elog "Interrupting Cow"
eblank
ewarn "Interrup..."
elog "Moo!"
}

Versus:

pkg_postinst() {
elog -p "Knock knock"
ewarn "Who's there?"
elog -pt "Interrupting Cow"
ewarn "Interrup..."
elog "Moo!"
}

I think that in the former case it's much more obvious how the actual
output is going to look. If the cost is an ebuild that's 3 lines
longer, I think that's reasonable.

--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

В Срд, 11/06/2008 в 19:45 -0400, Jim Ramsay пишет:
> Vlastimil Babka <caster@gentoo.org> wrote:
>
> > I would prefer something that
> > doesn't add extra lines to ebuild.
>
> I think I would disagree with you here. I think that having a special
> 'eblank' or 'eseparator' command is much more readable in an ebuild.

Taking into account that as einfo, ewarn and eerror work without any
arguments too are there any benefits from eblank/eseparator?

Speaking about blank lines around elog functions I think they could be
useful and I like idea of adding options (switches) to said functions.
But speaking about names of options - -A and -B are easier to remember
as -A stands for above and -B for below and grep users already knew
that.

BTW, have anybody filled feature request?

--
Peter.

--
gentoo-dev@lists.gentoo.org mailing list

On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov <pva@gentoo.org> wrote:
> But speaking about names of options - -A and -B are easier to remember
> as -A stands for above and -B for below and grep users already knew
> that.

for grep -A means after and -B before ;)

--
Benedikt
--
gentoo-dev@lists.gentoo.org mailing list

В Вск, 15/06/2008 в 13:19 +0200, Benedikt Morbach пишет:
> > But speaking about names of options - -A and -B are easier to
> remember
> > as -A stands for above and -B for below and grep users already knew
> > that.
>
> for grep -A means after and -B before ;)

True. And still, one day I learn this options for grep, it'll became
trivial to learn them for einfo functions. :)

--
Peter.

--
gentoo-dev@lists.gentoo.org mailing list

Benedikt Morbach wrote:
> On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov <pva@gentoo.org> wrote:
>> But speaking about names of options - -A and -B are easier to remember
>> as -A stands for above and -B for below and grep users already knew
>> that.
>
> for grep -A means after and -B before ;)

I (not having used those grep options frequently), would find it hard to
remember if "-A" meant "blank line after this" or "this after a blank
line". I am more visual person, so I'd find the separate
eblank/eseparator easier to visualize, and the look of the ebuild src
would match the output more naturally.

As for why it would be more useful than eerror/ewarn without an
argument: it would potentially allow for intelligent "context-based"
coloring of the "*" (based on surrounding lines).

-Joe
--
gentoo-dev@lists.gentoo.org mailing list

Joe Peterson <lavajoe@gentoo.org> wrote:
> As for why it would be more useful than eerror/ewarn without an
> argument: it would potentially allow for intelligent "context-based"
> coloring of the "*" (based on surrounding lines).

Well, this is true and it isn't... In the case of:

ewarn line one
eblank
ewarn line two

Obviously it would be the same as ewarn. However, what about here:

ewarn line one
eblank
elog line two
eblank
einfo line three

I'm not sure how you could make a function like that smart enough to
really know what to do... so perhaps since the author is the only one
who can really know what colour they intend, they should just use the
appropriate ewarn/elog/einfo without args.

--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

"Benedikt Morbach" <benedikt.morbach@googlemail.com> wrote:

> On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov <pva@gentoo.org> wrote:
> > But speaking about names of options - -A and -B are easier to
> > remember as -A stands for above and -B for below and grep users
> > already knew that.
>
> for grep -A means after and -B before ;)

Maybe we could have '-^' and '-v' then?

I do kind of like the idea of making these flags available for people
who think it makes their ebuilds prettier... I just don't think I'll
even use them.

--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

Jim Ramsay <lack@gentoo.org> posted
20080616083401.1703135a@altair.jimramsay.com, excerpted below, on Mon, 16
Jun 2008 08:34:01 -0400:

> Joe Peterson <lavajoe@gentoo.org> wrote:
>> As for why it would be more useful than eerror/ewarn without an
>> argument: it would potentially allow for intelligent "context-based"
>> coloring of the "*" (based on surrounding lines).
>
> Well, this is true and it isn't... In the case of:
>
> ewarn line one
> eblank
> ewarn line two
>
> Obviously it would be the same as ewarn. However, what about here:
>
> ewarn line one
> eblank
> elog line two
> eblank
> einfo line three

Here's a novel idea, let blank lines be /real/ blank lines! =8^)

Seriously, when it's different messages, having a * of /any/ color
between them only confuses the case, that they /are/ different messages.
If it's paragraphs of the same message, then the color of the * isn't an
issue, just make it the same color as that for the other content lines of
the message.

Sometimes I'll check the messages, and see two or three different logs/
warnings/whatever discussed in what appears to be the same message. That
shouldn't be the case. I should be able to scan thru them and as soon as
I note that it's a message I've read before, be able to skip to the next
one. As it is, I have to read thru the entire message just to see if
something new got added to the end.

Talking about which, what I'd like would be a date-stamp noting when the
message was added, or better yet, some indication of the message being
either new or something that's necessary to check each time, even on -r
updates and remerges. If I'm updating something that has a number of
messages and is frequently updated, I should be able to see immediately
the new messages added since the last time I updated, and the ones that
always apply. Of course, that's not entirely practical to try to
implement, but it'd be nice, and it does reinforce why I'd prefer /real/
blanks between messages, not ones with colored stars that may or may not
make it look like the entire group of messages are just one single long
message, depending on whether they're all the same color or not.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list

Duncan wrote:
> Jim Ramsay <lack@gentoo.org> posted
> 20080616083401.1703135a@altair.jimramsay.com, excerpted below, on Mon, 16
> Jun 2008 08:34:01 -0400:
>
>> Well, this is true and it isn't... In the case of:
>>
>> ewarn line one
>> eblank
>> ewarn line two
>>
>> Obviously it would be the same as ewarn. However, what about here:
>>
>> ewarn line one
>> eblank
>> elog line two
>> eblank
>> einfo line three

Yes, this is a "tricky" case. In the case where the previous and next
output lines differ like this, a grey "*" could be used, or perhaps a
green one. However, read more below on my response to Duncan.

> Here's a novel idea, let blank lines be /real/ blank lines! =8^)

Duncan, your point is well-taken. Taking that idea one step further,
how about using a "neutral" color for the "*" when "eblank" is used.
For example, a medium grey. This would avoid needing logic to guess the
correct color, and it would nicely integrate with the rest of the visual
flow/look of the output. Although I was originally imagining a
context-based color picker, this may be, indeed (as some have pointed
out) overkill.

The actual issue has mostly to do with conditionals like in the example
I gave a while back (in which the blank lines need to be within the
conditionals to avoid bunching up of blank lines when the conditionals
are false). Currently, I tend to color the "*" the same as the
preceding lines (I have no choice bu to pick some color), but this
doesn't really look right, depending on how the conditionals play out.

I am leaning more and more toward the idea of a neutral color for
eblanks, as this would indeed be trivial to code and it would make
output make more sense, especially for conditionals, but for other cases
as well.

-Joe
--
gentoo-dev@lists.gentoo.org mailing list

Joe Peterson <lavajoe@gentoo.org> posted 485697D3.6070303@gentoo.org,
excerpted below, on Mon, 16 Jun 2008 10:41:55 -0600:

> I am leaning more and more toward the idea of a neutral color for
> eblanks, as this would indeed be trivial to code and it would make
> output make more sense, especially for conditionals, but for other cases
> as well.

Yes, a neutral grey, as you suggested, makes sense. That'd cure my
problem of visual separator as well, and as you said, would be trivial to
code compared to the complexity of trying to figure out dynamically which
color to use. I like it! =8^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list

On Sun, 2008-06-15 at 14:02 +0400, Peter Volkov wrote:
> В Срд, 11/06/2008 в 19:45 -0400, Jim Ramsay пишет:
> > Vlastimil Babka <caster@gentoo.org> wrote:
> >
> > > I would prefer something that
> > > doesn't add extra lines to ebuild.
> >
> > I think I would disagree with you here. I think that having a special
> > 'eblank' or 'eseparator' command is much more readable in an ebuild.
>
> Taking into account that as einfo, ewarn and eerror work without any
> arguments too are there any benefits from eblank/eseparator?

Not really and part of my thought process was less lines, less code. Not
more or staying the same. No matter what it is, typing anything on a
single line to get a new line is more than should be required IMHO.

Want a single line of output with blanks lines before and after. One has
to code 3 lines in ebuild. That should be 1 line to get 1 comment, with
auto-blanks per flag/switch, or etc. 1 line of code 3 lines of output,
efficient. 3 lines of code, 3 lines of output. Not so much.

--
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation

On Mon, 2008-06-16 at 17:01 +0000, Duncan wrote:
> Joe Peterson <lavajoe@gentoo.org> posted 485697D3.6070303@gentoo.org,
> excerpted below, on Mon, 16 Jun 2008 10:41:55 -0600:
>
> > I am leaning more and more toward the idea of a neutral color for
> > eblanks, as this would indeed be trivial to code and it would make
> > output make more sense, especially for conditionals, but for other cases
> > as well.
>
> Yes, a neutral grey, as you suggested, makes sense. That'd cure my
> problem of visual separator as well, and as you said, would be trivial to
> code compared to the complexity of trying to figure out dynamically which
> color to use. I like it! =8^)

With flags/switches coloring is moot. One can always add a different
switch/flag to get a diff color line before or after any one section.
Which is easier IMHO, less logic in detecting and setting the right
color. Which is pretty moot per my initial thoughts. Which was just to
reduce size of ebuilds (slightly), write less code.

--
William L. Thomson Jr.
amd64/Java/Trustees
Gentoo Foundation

On Wed, 04 Jun 2008 15:31:58 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:

> William L. Thomson Jr. wrote:
> > Just a quick thought looking over a couple ebuilds. It seems most
> > times anyone does a error, elog, einfo, or similar. They start and
> > end with a few blank lines. Calls with no arguments.
> >
> > Is there any reason not to make that a default? Other than
> > difficulty of implementation. Anytime they are invoked back to
> > back. Default blank lines are added at the beginning or end.
>
> I have run into the same dilemma - wanting to separate blocks of
> warnings/logs/info by blank space. And the particular issue I've run
> into is which calls to use (i.e. what color to make the "*"). For
> example, I might have two possible warnings back-to-back, and each is
> conditional:
>
> if ! use flac; then
> ewarn "'flac' USE flag is not set. Blah, blah..."
> ewarn "More blah blah..."
> ewarn ""
> fi
> if ! use lame; then
> ewarn "'lame' USE flag is not set. Blah, blah..."
> ewarn "More blah blah..."
> ewarn ""
> fi
>
> Problem is, the blank line doesn't really belong in the "warning"
> itself
> - it's meant as a separator. And if both happen, it makes sense to
> color the "*" logically (should it be yellow rather than, say, green?
> If the next block of output is "green", it can look funny to see a
> blank yellow as the separator, for example.
>
> Also, there is that question of whether to put the blank line before
> or after the block, and if conditional, it can be tricky to make the
> full output look nice for all possibilities. I tend not to want to
> put a blank line at the very end of the output (trying to be
> consistent with most other ebuilds), even though that might make
> things more clear. Also, I don't know inside the conditional whether
> it might be the last block of output or of another conditional might
> follow (for example).
>
> So I am in favor of some smart code in portage to do "nice looking"
> blank line logic that would also make reading the output more clear.
> Something like "eblank" or "eseparator" could be aware of the previous
> and next "color" and do the right thing. Putting a blank line
> consistently at the end of the ebuild output but before portage's end
> summary would be nice as well (and make it easier to spot problems
> when looking at the output). Also, if the ebuild itself tries to
> insert blanks at the start or end, portage could remove those and
> enforce its own spacing rules...

I just throw a couple echos around any output.

echo
elog "Your shoe is untied."
elog
elog "Please run this command again when your footwear is properly"
elog "secured."
echo

I think doing any kind of automatic pretty-print formatting is
overkill, but that's just my opinion.


--
fonts, gcc-porting, by design, by neglect
mips, treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662