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 05-14-2008, 09:08 AM
Nagy Gabor
 
Default callback functions

>
http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commitdiff;h=9bde1c36eb10ff121f7de5bb34ad e2a704f49c82
> > (nice jab there, pretty mature)
>
> oh well, different targets. this is just a decision. we try to keep a
> stable api, you don't. both has benefits. and at the end users can
> choose. that's the best
>

IIRC, this was reverted, but that is just one more argument to your 'not stable
API' "campaign".

In my opinion the parameters of callback functions should be reworked (warning,
API change ;-). My preferred solution would be putting one param, a pointer to a
complicated union or whatever, which can be accessed via
alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?

Bye


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-14-2008, 09:46 AM
Xavier
 
Default callback functions

2008/5/14 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
> >
> http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-g2.git;a=commitdiff;h=9bde1c36eb10ff121f7de5bb34ad e2a704f49c82
> > > (nice jab there, pretty mature)
> >
> > oh well, different targets. this is just a decision. we try to keep a
> > stable api, you don't. both has benefits. and at the end users can
> > choose. that's the best
> >
>
> IIRC, this was reverted, but that is just one more argument to your 'not stable
> API' "campaign".
>

It doesn't make any sense to stabilize such a crappy API.
But just as reminder, the API remains stable between minor releases
(3.x.y), but not between major releases (3.x)

About the dltotal thing, Dan indeed reverted it, but we need to add
that feature back with another way.
We currently have this callback :
void cb_dl_progress(const char *filename, int xfered, int total)
Dan suggested to add another one 2 days ago, I believe it was something like :
void cb_dl_total_progress(int xfered, int total)
But I already forgot. Dan, can you confirm this?

> In my opinion the parameters of callback functions should be reworked (warning,
> API change ;-). My preferred solution would be putting one param, a pointer to a
> complicated union or whatever, which can be accessed via
> alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?
>

This might not be a bad idea, any work that would allow us to get rid
of these TODO in callback.c is welcome :
/* TODO this is one of the worst ever functions written. void *data ? wtf */
/* TODO we take this route based on data2 being not null? WTF */

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-15-2008, 12:46 AM
"Dan McGee"
 
Default callback functions

On Wed, May 14, 2008 at 4:46 AM, Xavier <shiningxc@gmail.com> wrote:
> 2008/5/14 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
> About the dltotal thing, Dan indeed reverted it, but we need to add
> that feature back with another way.
> We currently have this callback :
> void cb_dl_progress(const char *filename, int xfered, int total)
> Dan suggested to add another one 2 days ago, I believe it was something like :
> void cb_dl_total_progress(int xfered, int total)
> But I already forgot. Dan, can you confirm this?

Yes, this is what I was thinking. The frontend(s) could then use these
two functions accordingly. Both would be called numerous times during
the download as they are now.

>> In my opinion the parameters of callback functions should be reworked (warning,
>> API change ;-). My preferred solution would be putting one param, a pointer to a
>> complicated union or whatever, which can be accessed via
>> alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?

I don't think this complexity is quite needed for the download
functions. Maybe the other functions later on though. Download we are
dealing with 4 numbers and a filename.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 05-15-2008, 03:24 AM
"Aaron Griffin"
 
Default callback functions

On Wed, May 14, 2008 at 7:46 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Wed, May 14, 2008 at 4:46 AM, Xavier <shiningxc@gmail.com> wrote:
> > 2008/5/14 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
>
> > About the dltotal thing, Dan indeed reverted it, but we need to add
> > that feature back with another way.
> > We currently have this callback :
> > void cb_dl_progress(const char *filename, int xfered, int total)
> > Dan suggested to add another one 2 days ago, I believe it was something like :
> > void cb_dl_total_progress(int xfered, int total)
> > But I already forgot. Dan, can you confirm this?
>
> Yes, this is what I was thinking. The frontend(s) could then use these
> two functions accordingly. Both would be called numerous times during
> the download as they are now.
>
>
> >> In my opinion the parameters of callback functions should be reworked (warning,
> >> API change ;-). My preferred solution would be putting one param, a pointer to a
> >> complicated union or whatever, which can be accessed via
> >> alpm_info_get_xfered(ptr) etc. thus making it much more flexible. Thoughts?
>
> I don't think this complexity is quite needed for the download
> functions. Maybe the other functions later on though. Download we are
> dealing with 4 numbers and a filename.

Using a struct for this would be a shade more clear. But it's really
just smoke-and-mirrors. Whether all that data is a struct or raw
params means little.

_______________________________________________
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 09:45 PM.

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