From: Dave A. <da...@gu...> - 2011-01-27 16:32:23
|
Hi guys! Bad problem just before the release... :( On my Fedora14 ecore_file_download() is broken, the completion/progress callbacks are never called. I can see this in my applications, in the "elementary map test" and in the python-ecore example: examples/file/01_ecore_file_download.py Download seem to start (no error on start), the "http://" protocol is available, but no callbacks are called :/ To be sure it's not a problem of mine I'm setting up 3 virtual machine with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready this evening. No one spot the same problem? Can someone give it a try? Thanks DaveMDS |
From: Vincent T. <vt...@un...> - 2011-01-27 19:14:13
|
On Thu, 27 Jan 2011, Dave Andreoli wrote: > Hi guys! > > Bad problem just before the release... :( > > On my Fedora14 ecore_file_download() is broken, > the completion/progress callbacks are never called. I can see > this in my applications, in the "elementary map test" and in the > python-ecore example: examples/file/01_ecore_file_download.py > > Download seem to start (no error on start), the "http://" protocol is > available, but no callbacks are called :/ > > To be sure it's not a problem of mine I'm setting up 3 virtual machine > with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready > this evening. > > No one spot the same problem? Can someone give it a try? I checked (I have curl) with the program below. It starts, and the completion callback is called (status value: 0). The file is downloaded. But indeed, the progress callback is never called. It's maybe a problem in ecore_con. Vincent /* gcc -g -Wall -o ecore_file_download ecore_file_download.c `pkg-config --cflags --libs ecore-file ecore` */ #include <stdio.h> #include <Ecore.h> #include <Ecore_File.h> void comp(void *data, const char *file, int status) { printf("comp %s: %d\n", file, status); } int prog(void *data, const char *file, long int dltotal, long int dlnow, long int ultotal, long int ulnow) { printf("prog %s: %ld %ld %ld %ld\n", file, dltotal, dlnow, ultotal, ulnow); return 1; } int main() { Ecore_File_Download_Job *job; const char *url = "http://www.maths.univ-evry.fr/pages_perso/vtorri/files/salon3.jpg"; const char *dst = "salon.jpg"; ecore_init(); ecore_file_init(); if (ecore_file_download(url, dst, comp, prog, NULL, &job)) { printf("starting\n"); } else printf("error\n"); ecore_main_loop_begin(); ecore_file_shutdown(); ecore_shutdown(); return 0; } |
From: Sebastian D. <sd...@ta...> - 2011-01-27 19:41:54
|
On 01/27/2011 08:14 PM, Vincent Torri wrote: > > > On Thu, 27 Jan 2011, Dave Andreoli wrote: > >> Hi guys! >> >> Bad problem just before the release... :( >> >> On my Fedora14 ecore_file_download() is broken, >> the completion/progress callbacks are never called. I can see >> this in my applications, in the "elementary map test" and in the >> python-ecore example: examples/file/01_ecore_file_download.py >> >> Download seem to start (no error on start), the "http://" protocol is >> available, but no callbacks are called :/ >> >> To be sure it's not a problem of mine I'm setting up 3 virtual machine >> with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready >> this evening. >> >> No one spot the same problem? Can someone give it a try? > > I checked (I have curl) with the program below. It starts, and the > completion callback is called (status value: 0). The file is downloaded. > But indeed, the progress callback is never called. > > It's maybe a problem in ecore_con. Probably this commit. S. commit c75008005218334ba44aa3a5f95afb6f3b532f56 Author: discomfitor <discomfitor@7cbeb6ba-43b4-40fd-8cce-4c39aea84d33> Date: Thu Jan 20 09:27:19 2011 +0000 I think someone meant to set it like this originally but was confused by th ecore_con_url no longer shows progress bars git-svn-id: svn+ssh://svn.enlightenment.org/var/svn/e/trunk@56239 7cbeb6ba- diff --git a/ecore/src/lib/ecore_con/ecore_con_url.c b/ecore/src/lib/ecore_con/ index 1d6fcf5..fb94c5b 100644 --- a/ecore/src/lib/ecore_con/ecore_con_url.c +++ b/ecore/src/lib/ecore_con/ecore_con_url.c @@ -304,7 +304,7 @@ ecore_con_url_new(const char *url) curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSFUNCTION, _ecore_con_url_progress_cb); curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSDATA, url_con); - curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_FALSE); + curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_TRUE); curl_easy_setopt(url_con->curl_easy, CURLOPT_HEADERFUNCTION, _ecore_con_url_header_cb); |
From: Vincent T. <vt...@un...> - 2011-01-27 19:49:32
|
On Thu, 27 Jan 2011, Sebastian Dransfeld wrote: > On 01/27/2011 08:14 PM, Vincent Torri wrote: >> >> >> On Thu, 27 Jan 2011, Dave Andreoli wrote: >> >>> Hi guys! >>> >>> Bad problem just before the release... :( >>> >>> On my Fedora14 ecore_file_download() is broken, >>> the completion/progress callbacks are never called. I can see >>> this in my applications, in the "elementary map test" and in the >>> python-ecore example: examples/file/01_ecore_file_download.py >>> >>> Download seem to start (no error on start), the "http://" protocol is >>> available, but no callbacks are called :/ >>> >>> To be sure it's not a problem of mine I'm setting up 3 virtual machine >>> with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready >>> this evening. >>> >>> No one spot the same problem? Can someone give it a try? >> >> I checked (I have curl) with the program below. It starts, and the >> completion callback is called (status value: 0). The file is downloaded. >> But indeed, the progress callback is never called. >> >> It's maybe a problem in ecore_con. > > Probably this commit. not only. With my test case, the prog cb is called once and no completion cb is called (nothing is downloaded) Vincent > > S. > > commit c75008005218334ba44aa3a5f95afb6f3b532f56 > Author: discomfitor <discomfitor@7cbeb6ba-43b4-40fd-8cce-4c39aea84d33> > Date: Thu Jan 20 09:27:19 2011 +0000 > > I think someone meant to set it like this originally but was > confused by th > ecore_con_url no longer shows progress bars > > > git-svn-id: svn+ssh://svn.enlightenment.org/var/svn/e/trunk@56239 > 7cbeb6ba- > > diff --git a/ecore/src/lib/ecore_con/ecore_con_url.c > b/ecore/src/lib/ecore_con/ > index 1d6fcf5..fb94c5b 100644 > --- a/ecore/src/lib/ecore_con/ecore_con_url.c > +++ b/ecore/src/lib/ecore_con/ecore_con_url.c > @@ -304,7 +304,7 @@ ecore_con_url_new(const char *url) > curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSFUNCTION, > _ecore_con_url_progress_cb); > curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSDATA, url_con); > - curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_FALSE); > + curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_TRUE); > > curl_easy_setopt(url_con->curl_easy, CURLOPT_HEADERFUNCTION, > _ecore_con_url_header_cb); > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > |
From: Mike B. <mi...@ze...> - 2011-01-27 21:20:31
|
On Thu, 27 Jan 2011 20:49:24 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Thu, 27 Jan 2011, Sebastian Dransfeld wrote: > > > On 01/27/2011 08:14 PM, Vincent Torri wrote: > >> > >> > >> On Thu, 27 Jan 2011, Dave Andreoli wrote: > >> > >>> Hi guys! > >>> > >>> Bad problem just before the release... :( > >>> > >>> On my Fedora14 ecore_file_download() is broken, > >>> the completion/progress callbacks are never called. I can see > >>> this in my applications, in the "elementary map test" and in the > >>> python-ecore example: examples/file/01_ecore_file_download.py > >>> > >>> Download seem to start (no error on start), the "http://" protocol is > >>> available, but no callbacks are called :/ > >>> > >>> To be sure it's not a problem of mine I'm setting up 3 virtual machine > >>> with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready > >>> this evening. > >>> > >>> No one spot the same problem? Can someone give it a try? > >> > >> I checked (I have curl) with the program below. It starts, and the > >> completion callback is called (status value: 0). The file is downloaded. > >> But indeed, the progress callback is never called. > >> > >> It's maybe a problem in ecore_con. > > > > Probably this commit. > > not only. With my test case, the prog cb is called once and no completion > cb is called (nothing is downloaded) > > Vincent > > > > > S. > > > > commit c75008005218334ba44aa3a5f95afb6f3b532f56 > > Author: discomfitor <discomfitor@7cbeb6ba-43b4-40fd-8cce-4c39aea84d33> > > Date: Thu Jan 20 09:27:19 2011 +0000 > > > > I think someone meant to set it like this originally but was > > confused by th > > ecore_con_url no longer shows progress bars > > > > > > git-svn-id: svn+ssh://svn.enlightenment.org/var/svn/e/trunk@56239 > > 7cbeb6ba- > > > > diff --git a/ecore/src/lib/ecore_con/ecore_con_url.c > > b/ecore/src/lib/ecore_con/ > > index 1d6fcf5..fb94c5b 100644 > > --- a/ecore/src/lib/ecore_con/ecore_con_url.c > > +++ b/ecore/src/lib/ecore_con/ecore_con_url.c > > @@ -304,7 +304,7 @@ ecore_con_url_new(const char *url) > > curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSFUNCTION, > > _ecore_con_url_progress_cb); > > curl_easy_setopt(url_con->curl_easy, CURLOPT_PROGRESSDATA, url_con); > > - curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_FALSE); > > + curl_easy_setopt(url_con->curl_easy, CURLOPT_NOPROGRESS, EINA_TRUE); > > > > curl_easy_setopt(url_con->curl_easy, CURLOPT_HEADERFUNCTION, > > _ecore_con_url_header_cb); > > > > > > Hmm iirc that flag only affects the default curl progress output, not the callbacks, which was why I toggled it. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! |
From: Carsten H. (T. R. <ra...@ra...> - 2011-01-28 03:07:58
|
On Thu, 27 Jan 2011 20:14:04 +0100 (CET) Vincent Torri <vt...@un...> said: well first.. discomiftors patch/change did kill progress callbacks. i made them work again now. and to add to that your example below is wrong. progress cb should return 0 if it wants to keep going - return != 0 to abort the download :) > > > On Thu, 27 Jan 2011, Dave Andreoli wrote: > > > Hi guys! > > > > Bad problem just before the release... :( > > > > On my Fedora14 ecore_file_download() is broken, > > the completion/progress callbacks are never called. I can see > > this in my applications, in the "elementary map test" and in the > > python-ecore example: examples/file/01_ecore_file_download.py > > > > Download seem to start (no error on start), the "http://" protocol is > > available, but no callbacks are called :/ > > > > To be sure it's not a problem of mine I'm setting up 3 virtual machine > > with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready > > this evening. > > > > No one spot the same problem? Can someone give it a try? > > I checked (I have curl) with the program below. It starts, and the > completion callback is called (status value: 0). The file is downloaded. > But indeed, the progress callback is never called. > > It's maybe a problem in ecore_con. > > Vincent > > /* gcc -g -Wall -o ecore_file_download ecore_file_download.c `pkg-config > --cflags --libs ecore-file ecore` */ > > #include <stdio.h> > > #include <Ecore.h> > #include <Ecore_File.h> > > void comp(void *data, const char *file, int status) > { > printf("comp %s: %d\n", file, status); > } > > int prog(void *data, > const char *file, > long int dltotal, > long int dlnow, > long int ultotal, > long int ulnow) > { > printf("prog %s: %ld %ld %ld %ld\n", file, dltotal, dlnow, ultotal, ulnow); > > return 1; > } > > int main() > { > Ecore_File_Download_Job *job; > const char *url = > "http://www.maths.univ-evry.fr/pages_perso/vtorri/files/salon3.jpg"; const > char *dst = "salon.jpg"; > > ecore_init(); > ecore_file_init(); > > if (ecore_file_download(url, dst, comp, prog, NULL, &job)) > { > printf("starting\n"); > } > else > printf("error\n"); > > ecore_main_loop_begin(); > > ecore_file_shutdown(); > ecore_shutdown(); > > return 0; > } > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Vincent T. <vt...@un...> - 2011-01-28 08:11:22
|
On Fri, 28 Jan 2011, Carsten Haitzler (The Rasterman) wrote: > On Thu, 27 Jan 2011 20:14:04 +0100 (CET) Vincent Torri <vt...@un...> > said: > > well first.. discomiftors patch/change did kill progress callbacks. i made them > work again now. and to add to that your example below is wrong. progress cb > should return 0 if it wants to keep going - return != 0 to abort the download :) from your comment on irc about the progress callback: <raster> in that it returns 1 <raster> which aborts the download and from the doc: The only operations that can be aborted are those with protocol 'http' or 'ftp'. In that case @p job_ret can be filled. It can be used with ecore_file_download_abort() or ecore_file_download_abort_all() to respectively abort one or all download operations. So which one is correct ? If returning 0 for a callback that is used to display *informations* aborts the download, then for me it's a design error. Vincent |
From: Carsten H. (T. R. <ra...@ra...> - 2011-01-28 11:42:57
|
On Fri, 28 Jan 2011 09:11:14 +0100 (CET) Vincent Torri <vt...@un...> said: > > > On Fri, 28 Jan 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 27 Jan 2011 20:14:04 +0100 (CET) Vincent Torri <vt...@un...> > > said: > > > > well first.. discomiftors patch/change did kill progress callbacks. i made > > them work again now. and to add to that your example below is wrong. > > progress cb should return 0 if it wants to keep going - return != 0 to > > abort the download :) > > from your comment on irc about the progress callback: > > <raster> in that it returns 1 > <raster> which aborts the download > > and from the doc: > > The only operations that can be aborted are those with protocol 'http' or > 'ftp'. In that case @p job_ret can be filled. It can be used with > ecore_file_download_abort() or ecore_file_download_abort_all() to > respectively abort one or all download operations. > > So which one is correct ? If returning 0 for a callback that is used to > display *informations* aborts the download, then for me it's a design > error. the doc didnt even say what the return of the progress func does - that bit of the doc refers to something unrelated. i fixed the docs to document the return value. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Vincent T. <vt...@un...> - 2011-01-28 12:13:56
|
> the doc didnt even say what the return of the progress func does - that bit of > the doc refers to something unrelated. i fixed the docs to document the > return value. you didn't answer my question. Again I paste the doc: * The * @p progress_cb is called during the download operation, each time a * packet is received or when CURL wants. It can be used to display the * percentage of the downloaded file. Return 0 from this callback if provided * to continue the operation or anything else to abort the download. The only * operations that can be aborted are those with protocol 'http' or 'ftp'. In * that case @p job_ret can be filled. It can be used with * ecore_file_download_abort() or ecore_file_download_abort_all() to * respectively abort one or all download operations So it says: 1) if one returns 0 to the progress cb, one aborts the download 2) if we want to abort the download, we can use the job. Questions: a) which on is the correct way to abort a download ? b) don't you think it's a design error to allow abortion for a callback that is used to get informations (the progress callback) ? So, please, answer these questions precisely. Vincent |
From: Carsten H. (T. R. <ra...@ra...> - 2011-01-28 14:38:53
|
On Fri, 28 Jan 2011 13:13:47 +0100 (CET) Vincent Torri <vt...@un...> said: > > > the doc didnt even say what the return of the progress func does - that bit > > of the doc refers to something unrelated. i fixed the docs to document the > > return value. > > you didn't answer my question. Again I paste the doc: > > > * The > * @p progress_cb is called during the download operation, each time a > * packet is received or when CURL wants. It can be used to display the > * percentage of the downloaded file. Return 0 from this callback if provided > * to continue the operation or anything else to abort the download. The only > * operations that can be aborted are those with protocol 'http' or 'ftp'. In > * that case @p job_ret can be filled. It can be used with > * ecore_file_download_abort() or ecore_file_download_abort_all() to > * respectively abort one or all download operations > > So it says: > > 1) if one returns 0 to the progress cb, one aborts the download > 2) if we want to abort the download, we can use the job. > > Questions: > > a) which on is the correct way to abort a download ? > > b) don't you think it's a design error to allow abortion for a callback > that is used to get informations (the progress callback) ? > > So, please, answer these questions precisely. i didn't write the function. i have no answer for you. i simply documented its current behavior. it's staying as-is because that's how it is, how it now works, how code that depends on it now is expecting it to work. i see no reason why the progress callback couldnt abort by return value - eg if download amount is too big (maximum download limit). i'm not going to get into a debate on minutiae of a callback right now before release. it stays as-is. too bad. too late. if it mattered then this should have been brought up years ago when this function was written. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Dave A. <da...@gu...> - 2011-01-28 15:02:54
|
2011/1/28 Carsten Haitzler <ra...@ra...>: > On Fri, 28 Jan 2011 13:13:47 +0100 (CET) Vincent Torri <vt...@un...> > said: > >> >> > the doc didnt even say what the return of the progress func does - that bit >> > of the doc refers to something unrelated. i fixed the docs to document the >> > return value. >> >> you didn't answer my question. Again I paste the doc: >> >> >> * The >> * @p progress_cb is called during the download operation, each time a >> * packet is received or when CURL wants. It can be used to display the >> * percentage of the downloaded file. Return 0 from this callback if provided >> * to continue the operation or anything else to abort the download. The only >> * operations that can be aborted are those with protocol 'http' or 'ftp'. In >> * that case @p job_ret can be filled. It can be used with >> * ecore_file_download_abort() or ecore_file_download_abort_all() to >> * respectively abort one or all download operations what about at least add 2 define: ECORE_DOWNLOAD_CONTINUE = 0 ECORE_DOWNLOAD_ABORT = 1 DaveMDS >> >> So it says: >> >> 1) if one returns 0 to the progress cb, one aborts the download >> 2) if we want to abort the download, we can use the job. >> >> Questions: >> >> a) which on is the correct way to abort a download ? >> >> b) don't you think it's a design error to allow abortion for a callback >> that is used to get informations (the progress callback) ? >> >> So, please, answer these questions precisely. > > i didn't write the function. i have no answer for you. i simply documented its > current behavior. it's staying as-is because that's how it is, how it now > works, how code that depends on it now is expecting it to work. i see no reason > why the progress callback couldnt abort by return value - eg if download amount > is too big (maximum download limit). i'm not going to get into a debate on > minutiae of a callback right now before release. it stays as-is. too bad. too > late. if it mattered then this should have been brought up years ago when this > function was written. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > |
From: Carsten H. (T. R. <ra...@ra...> - 2011-01-29 02:38:39
|
On Fri, 28 Jan 2011 16:02:26 +0100 Dave Andreoli <da...@gu...> said: > 2011/1/28 Carsten Haitzler <ra...@ra...>: > > On Fri, 28 Jan 2011 13:13:47 +0100 (CET) Vincent Torri <vt...@un...> > > said: > > > >> > >> > the doc didnt even say what the return of the progress func does - that > >> > bit of the doc refers to something unrelated. i fixed the docs to > >> > document the return value. > >> > >> you didn't answer my question. Again I paste the doc: > >> > >> > >> * The > >> * @p progress_cb is called during the download operation, each time a > >> * packet is received or when CURL wants. It can be used to display the > >> * percentage of the downloaded file. Return 0 from this callback if > >> provided > >> * to continue the operation or anything else to abort the download. The > >> only > >> * operations that can be aborted are those with protocol 'http' or > >> 'ftp'. In > >> * that case @p job_ret can be filled. It can be used with > >> * ecore_file_download_abort() or ecore_file_download_abort_all() to > >> * respectively abort one or all download operations > > what about at least add 2 define: > ECORE_DOWNLOAD_CONTINUE = 0 > ECORE_DOWNLOAD_ABORT = 1 > > DaveMDS i don't have a problem with that - though it doesn't really change anything. you will still need to read the manual and know to return one of these. > >> > >> So it says: > >> > >> 1) if one returns 0 to the progress cb, one aborts the download > >> 2) if we want to abort the download, we can use the job. > >> > >> Questions: > >> > >> a) which on is the correct way to abort a download ? > >> > >> b) don't you think it's a design error to allow abortion for a callback > >> that is used to get informations (the progress callback) ? > >> > >> So, please, answer these questions precisely. > > > > i didn't write the function. i have no answer for you. i simply documented > > its current behavior. it's staying as-is because that's how it is, how it > > now works, how code that depends on it now is expecting it to work. i see > > no reason why the progress callback couldnt abort by return value - eg if > > download amount is too big (maximum download limit). i'm not going to get > > into a debate on minutiae of a callback right now before release. it stays > > as-is. too bad. too late. if it mattered then this should have been brought > > up years ago when this function was written. > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ra...@ra... > > > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Dave A. <da...@gu...> - 2011-01-31 09:49:41
|
Ok, I rechecked the ecore_file_download() function: On ubuntu it works well now, but on fedora14 is still BROKEN, same behavior of the last week: the function report that the download has started, but nothing is downloaded and no callbacks are called (neither progress_cb or done_cb) The version of curl is the same on both ubuntu and fedora... what else can I check? DaveMDS 2011/1/27 Dave Andreoli <da...@gu...>: > Hi guys! > > Bad problem just before the release... :( > > On my Fedora14 ecore_file_download() is broken, > the completion/progress callbacks are never called. I can see > this in my applications, in the "elementary map test" and in the > python-ecore example: examples/file/01_ecore_file_download.py > > Download seem to start (no error on start), the "http://" protocol is > available, but no callbacks are called :/ > > To be sure it's not a problem of mine I'm setting up 3 virtual machine > with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready > this evening. > > No one spot the same problem? Can someone give it a try? > > Thanks > DaveMDS > |
From: Carsten H. (T. R. <ra...@ra...> - 2011-01-31 10:48:40
|
On Mon, 31 Jan 2011 10:49:14 +0100 Dave Andreoli <da...@gu...> said: > Ok, I rechecked the ecore_file_download() function: > > On ubuntu it works well now, but on fedora14 is still BROKEN, > same behavior of the last week: > the function report that the download has started, but nothing > is downloaded and no callbacks are called (neither progress_cb or > done_cb) > > The version of curl is the same on both ubuntu and fedora... > what else can I check? now there i can't say why - it's working on unbooty here just fine. i dont have any fedora systems set up to test on - perhaps a curl bug that ubuntu/debian patched? i don't know. > DaveMDS > > > 2011/1/27 Dave Andreoli <da...@gu...>: > > Hi guys! > > > > Bad problem just before the release... :( > > > > On my Fedora14 ecore_file_download() is broken, > > the completion/progress callbacks are never called. I can see > > this in my applications, in the "elementary map test" and in the > > python-ecore example: examples/file/01_ecore_file_download.py > > > > Download seem to start (no error on start), the "http://" protocol is > > available, but no callbacks are called :/ > > > > To be sure it's not a problem of mine I'm setting up 3 virtual machine > > with clean os, Debian5, Ubuntu10.10 and Fedora14. They will be ready > > this evening. > > > > No one spot the same problem? Can someone give it a try? > > > > Thanks > > DaveMDS > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |