FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-04-2008, 09:31 PM
Joe Peterson
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-05-2008, 12:45 AM
Ryan Hill
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-05-2008, 01:40 AM
Joe Peterson
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-06-2008, 10:42 PM
Vlastimil Babka
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-07-2008, 12:07 AM
Joe Peterson
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-07-2008, 12:22 AM
Vlastimil Babka
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-11-2008, 11:45 PM
Jim Ramsay
 
Default Default blank lines for error, elog, einfo, etc

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)
 
Old 06-15-2008, 11:19 AM
"Benedikt Morbach"
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-15-2008, 01:16 PM
Joe Peterson
 
Default Default blank lines for error, elog, einfo, etc

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
 
Old 06-16-2008, 12:34 PM
Jim Ramsay
 
Default Default blank lines for error, elog, einfo, etc

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)
 

Thread Tools




All times are GMT. The time now is 12:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org