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


 
 
LinkBack Thread Tools
 
Old 12-03-2007, 09:20 PM
Xavier
 
Default output issues status

So, a while ago I reported some output issues here, making the distinction
between two kind :
http://www.archlinux.org/pipermail/pacman-dev/2007-September/009317.html

The first kind was worked around by Dan by removing these pointless "done"
messages :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=3017b71cb5cde3aef7e0efb5f 49843cccf759956

For the second one, Dan and Aaron had an argument about how to solve it.
Dan has a preference for delaying the output, and Aaron prefers padding with
space (the way it was in 3.0).

22:56 phrakture >> i don't get why you dislike padding with spaces. lots of other apps do that
22:57 phrakture >> i personally think it's a far better idea than blocking message output
22:57 phrakture >> because, well, what if we have a front end that doesn't output progress
22:57 phrakture >> and thus has no progress callback
22:59 toofishes >> we aren't blocking message output *from the backend*
22:59 toofishes >> this is all in the frontend!
23:00 toofishes >> if you had an install where there were 20 permission errors,
we are going to have 20 progress bar fragments right now.
23:00 phrakture >> right, and I'm saying we can solve that with maybe 3 lines of code
23:00 toofishes >> ok, patches welcome
23:00 phrakture >> but it's padding, and you dislike that
23:01 toofishes >> well i haven't seen your implementation. maybe i won't dislike it.
23:01 toofishes >> i just feel like this isn't the right way or something.


Since Aaron promised restoring the padding way in 3 lines, I couldn't really
compete with that , and besides 3.0 already has a sample implementation.
So I tried exploring the delayed output way instead, and hacked something
together in ~50 lines. It's very ugly and hackish, but it's just meant as a
proof of concept, because I'm not even sure the idea is right.


>From 9de58523ee64c4c2d86148fad30be1c6cf543d22 Mon Sep 17 00:00:00 2001
From: Chantry Xavier <shiningxc@gmail.com>
Date: Mon, 3 Dec 2007 22:57:54 +0100
Subject: [PATCH] Delay output during progress bar.

This is just a proof of concept patch to fix the output issue related to the
progress bar by delaying the output.

Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
---
src/pacman/callback.c | 27 ++++++++++++++++++++++++++-
src/pacman/util.c | 29 +++++++++++++++++++++++++++++
src/pacman/util.h | 1 +
3 files changed, 56 insertions(+), 1 deletions(-)

diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index 6129d8d..7d52f5d 100644
--- a/src/pacman/callback.c
+++ b/src/pacman/callback.c
@@ -48,6 +48,10 @@ static struct timeval initial_time;
/* transaction progress bar ? */
static int prevpercent=0; /* for less progressbar output */

+/* delayed output */
+static int on_progress = 0;
+static alpm_list_t *output = NULL;
+
/* Silly little helper function, determines if the caller needs a visual update
* since the last time this function was called.
* This is made for the two progress bar functions, to prevent flicker
@@ -408,6 +412,19 @@ void cb_trans_progress(pmtransprog_t event, const char *pkgname, int percent,

/* call refactored fill progress function */
fill_progress(percent, percent, getcols() - infolen);
+
+ if(percent == 100) {
+ alpm_list_t *i = NULL;
+ on_progress = 0;
+ for(i = output; i; i = i->next) {
+ printf("%s", (char *)i->data);
+ }
+ alpm_list_free_inner(output, free);
+ alpm_list_free(output);
+ output = NULL;
+ } else {
+ on_progress = 1;
+ }
}

/* callback to handle display of download progress */
@@ -546,7 +563,15 @@ void cb_log(pmloglevel_t level, char *fmt, va_list args)
return;
}

- pm_vfprintf(stdout, level, fmt, args);
+ if(on_progress) {
+ char *string = NULL;
+ pm_vasprintf(&string, level, fmt, args);
+ if(string != NULL) {
+ output = alpm_list_add(output, string);
+ }
+ } else {
+ pm_vfprintf(stdout, level, fmt, args);
+ }
}

/* vim: set ts=2 sw=2 noet: */
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 89313c8..78b6fcf 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -526,6 +526,35 @@ int pm_fprintf(FILE *stream, pmloglevel_t level, const char *format, ...)
return(ret);
}

+int pm_vasprintf(char **string, pmloglevel_t level, const char *format, va_list args)
+{
+ int ret = 0;
+ char *msg = NULL;
+
+ /* if current logmask does not overlap with level, do not print msg */
+ if(!(config->logmask & level)) {
+ return ret;
+ }
+
+ /* print the message using va_arg list */
+ ret = vasprintf(&msg, format, args);
+
+ /* print a prefix to the message */
+ switch(level) {
+ case PM_LOG_ERROR:
+ asprintf(string, _("error: %s"), msg);
+ break;
+ case PM_LOG_WARNING:
+ asprintf(string, _("warning: %s"), msg);
+ break;
+ default:
+ break;
+ }
+ free(msg);
+
+ return(ret);
+}
+
int pm_vfprintf(FILE *stream, pmloglevel_t level, const char *format, va_list args)
{
int ret = 0;
diff --git a/src/pacman/util.h b/src/pacman/util.h
index 0295d7e..4f4b3db 100644
--- a/src/pacman/util.h
+++ b/src/pacman/util.h
@@ -55,6 +55,7 @@ int yesno(char *fmt, ...);
int pm_printf(pmloglevel_t level, const char *format, ...) __attribute__((format(printf,2,3)));
int pm_fprintf(FILE *stream, pmloglevel_t level, const char *format, ...) __attribute__((format(printf,3,4)));
int pm_vfprintf(FILE *stream, pmloglevel_t level, const char *format, va_list args) __attribute__((format(printf,3,0)));
+int pm_vasprintf(char **string, pmloglevel_t level, const char *format, va_list args) __attribute__((format(printf,3,0)));

#ifndef HAVE_STRNDUP
char *strndup(const char *s, size_t n);
--
1.5.3.6


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-03-2007, 09:29 PM
"Aaron Griffin"
 
Default output issues status

On Dec 3, 2007 4:20 PM, Xavier <shiningxc@gmail.com> wrote:
> Since Aaron promised restoring the padding way in 3 lines, I couldn't really
> compete with that , and besides 3.0 already has a sample implementation.
> So I tried exploring the delayed output way instead, and hacked something
> together in ~50 lines. It's very ugly and hackish, but it's just meant as a
> proof of concept, because I'm not even sure the idea is right.

Hah, yeah I actually assumed some sort of vasprintf-esque function, so
I would have counted that too.

Still, I think that for the time being a "hackish" solution is best
(even though this one is pretty good), because we just need to do some
cleanup to get 3.1 out the door.

I like it.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-03-2007, 09:50 PM
Xavier
 
Default output issues status

On Mon, Dec 03, 2007 at 04:29:58PM -0600, Aaron Griffin wrote:
> On Dec 3, 2007 4:20 PM, Xavier <shiningxc@gmail.com> wrote:
> > Since Aaron promised restoring the padding way in 3 lines, I couldn't really
> > compete with that , and besides 3.0 already has a sample implementation.
> > So I tried exploring the delayed output way instead, and hacked something
> > together in ~50 lines. It's very ugly and hackish, but it's just meant as a
> > proof of concept, because I'm not even sure the idea is right.
>
> Hah, yeah I actually assumed some sort of vasprintf-esque function, so
> I would have counted that too.
>
> Still, I think that for the time being a "hackish" solution is best
> (even though this one is pretty good), because we just need to do some
> cleanup to get 3.1 out the door.
>
> I like it.
>

Oh, ok then. Let's see if this "hackish" solution is also good enough for
Dan, and then the eventual cleanup / refactoring / renaming that needs to be
done, as well as commenting this hack in the code.

I originally tried to base the detection of the progress bar in cb_trans_evt,
based on the events sent before and after the progress bar.
But there were the different upgrade / add / remove cases to consider, and it
looked a bit messy.
So I tried to move it at the end of cb_trans_progress, based on the "int
percent" argument, and it turned out to be easier, and better factored for
the different cases.

Anyway, I wasn't familiar with this part of the code at all, so this hack
should be carefully reviewed before being considered to be merged

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-03-2007, 11:42 PM
"Dan McGee"
 
Default output issues status

On Dec 3, 2007 4:50 PM, Xavier <shiningxc@gmail.com> wrote:
> On Mon, Dec 03, 2007 at 04:29:58PM -0600, Aaron Griffin wrote:
> > On Dec 3, 2007 4:20 PM, Xavier <shiningxc@gmail.com> wrote:
> > > Since Aaron promised restoring the padding way in 3 lines, I couldn't really
> > > compete with that , and besides 3.0 already has a sample implementation.
> > > So I tried exploring the delayed output way instead, and hacked something
> > > together in ~50 lines. It's very ugly and hackish, but it's just meant as a
> > > proof of concept, because I'm not even sure the idea is right.
> >
> > Hah, yeah I actually assumed some sort of vasprintf-esque function, so
> > I would have counted that too.
> >
> > Still, I think that for the time being a "hackish" solution is best
> > (even though this one is pretty good), because we just need to do some
> > cleanup to get 3.1 out the door.
> >
> > I like it.
> >
>
> Oh, ok then. Let's see if this "hackish" solution is also good enough for
> Dan, and then the eventual cleanup / refactoring / renaming that needs to be
> done, as well as commenting this hack in the code.

For now, this looks quite good enough. Great work. You did this as
cleanly as one would possibly be able to- the only other concern would
be with a interrupt, which I haven't tested.

> I originally tried to base the detection of the progress bar in cb_trans_evt,
> based on the events sent before and after the progress bar.
> But there were the different upgrade / add / remove cases to consider, and it
> looked a bit messy.
> So I tried to move it at the end of cb_trans_progress, based on the "int
> percent" argument, and it turned out to be easier, and better factored for
> the different cases.
>
> Anyway, I wasn't familiar with this part of the code at all, so this hack
> should be carefully reviewed before being considered to be merged

I'm going to let it bake on my working branch tonight (I made a few
small changes but nothing huge). If everyone could give it a test that
would be great.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-04-2007, 05:11 PM
Xavier
 
Default output issues status

On Mon, Dec 03, 2007 at 06:42:11PM -0600, Dan McGee wrote:
> For now, this looks quite good enough. Great work. You did this as
> cleanly as one would possibly be able to- the only other concern would
> be with a interrupt, which I haven't tested.
>
> I'm going to let it bake on my working branch tonight (I made a few
> small changes but nothing huge). If everyone could give it a test that
> would be great.
>

Nothing wrong with your small changes, but it reminded me of something I
didn't mention:
the delayed output is only done when --debug is NOT set, because when --debug
is used, the progress bar is disabled with noprogressbar = 1. So in
pm_vasprintf, the logmask will never overlap with LOG_DEBUG or LOG_FUNCTION.

However, that only concerns this particular usage of pm_vasprintf, so you
were right to add LOG_DEBUG and LOG_FUNCTION handling to pm_vasprintf. It
just isn't used currently.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-04-2007, 06:04 PM
"Dan McGee"
 
Default output issues status

On Dec 4, 2007 12:11 PM, Xavier <shiningxc@gmail.com> wrote:
> On Mon, Dec 03, 2007 at 06:42:11PM -0600, Dan McGee wrote:
> > For now, this looks quite good enough. Great work. You did this as
> > cleanly as one would possibly be able to- the only other concern would
> > be with a interrupt, which I haven't tested.
> >
> > I'm going to let it bake on my working branch tonight (I made a few
> > small changes but nothing huge). If everyone could give it a test that
> > would be great.
> >
>
> Nothing wrong with your small changes, but it reminded me of something I
> didn't mention:
> the delayed output is only done when --debug is NOT set, because when --debug
> is used, the progress bar is disabled with noprogressbar = 1. So in
> pm_vasprintf, the logmask will never overlap with LOG_DEBUG or LOG_FUNCTION.
>
> However, that only concerns this particular usage of pm_vasprintf, so you
> were right to add LOG_DEBUG and LOG_FUNCTION handling to pm_vasprintf. It
> just isn't used currently.

Yeah, I realized this, but one of two things should be done:
1. Copy the existing switch statement with all the options (as I ended
up doing).
2. Make an explicit comment in the code why certain statements were omitted.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 12-04-2007, 07:27 PM
Xavier
 
Default output issues status

On Tue, Dec 04, 2007 at 01:04:28PM -0600, Dan McGee wrote:
> Yeah, I realized this, but one of two things should be done:
> 1. Copy the existing switch statement with all the options (as I ended
> up doing).
> 2. Make an explicit comment in the code why certain statements were omitted.
>

Ok, fair enough. As I already said, I'm fine with 1.
I thought it might still be worth adding a little comment where pm_vasprintf
is called, in cb_log, but I actually wouldn't know what to write exactly, and
I'm not sure it would be really useful, so forget it.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 08:43 AM.

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