Re: [E-devel] e20 on Raspberry Pi

[The Rasterman]

On Mon, 4 Apr 2016 23:34:47 +0200 Andreas Volz  said:

> Am Mon, 4 Apr 2016 13:30:15 +0900 schrieb Carsten Haitzler (The
> Rasterman):
> 
> > On Sun, 3 Apr 2016 22:15:19 +0200 Andreas Volz 
> > said:
> > 
> > > Am Fri, 1 Apr 2016 16:31:42 -0700 schrieb Cedric BAIL:
> > > 
> > > > > I tried to start my application with the default Gtk based
> > > > > window manager, but it's strange. As long as I activate alpha
> > > > > and shaped window support in my application the application is
> > > > > somehow broken and hangs in the beginning. I didn't yet trace
> > > > > it out where it hangs.
> > > > >
> > > > > Do you have any ideas or explanations?
> > > > 
> > > > Not for the last problem.
> > > 
> > > I didn't change much in my application, but now I get a crash of
> > > E20 and X back to the console if I start my application on the
> > > Raspberry Pi.
> > > 
> > > In LXDE it still just hangs my application at the point it starts
> > > the window. Need to start my application in the debugger and see
> > > where it exact hangs.
> > > 
> > > See here the E crash dump:
> > > 
> > > http://tux-style.com/tmp/e-crashdump.txt
> > 
> > like 633? that's in bgr565 - 16bit handling. this will cause even
> > more slowness as e has to use efl to convert 16bpp to 32bpp then
> > render in 32bpp then render/dither back to 16bpp for the display...
> 
> Ok, have I influenced this in my application setup?
> 
> > try 24/32bpp for best results. but anyway. this says the 16bit
> > converter has a bug maybe - > thats s16 (src 16bit) ptr - and it uses
> > sbpl to multiply y + row so what's up with this? sbpl is src
> > bytes per line. so 640 there. i assume its a 320 wide window then. is
> > y and row ... wrong? row is the current row we are looking at? y + h
> > > image height? height says it's 240. row is 0... src pts and s16 are
> > > the same - so that's right. ... so it's not src. dp (destination
> > > pointer) is the issue. in
> > fact see dst - its NULL. (0x0). thats the issue. why is it null?
> > that's odd. :(
> 
> No my window is 800x480 pixels big. Maybe that's the LXTerminal size. I
> had two terminals open at this time.

well the backtrace deals with a window that is 320 wide... and data is null to
write the grabbed data (converted data from rgb565 to 32bit agb) to.. and
that is super odd.

> The good thing for me is that it seems maybe not to be my applications
> fault. Today I started just the LXTerminal from Raspi in E20 and I got
> a X crash.

oh nice!

> -- 
> Technical Blog 
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [imlib2] integer divide by zero on 2x1 ellipse

[Simon Lees]

On 04/05/2016 06:48 AM, Yuriy M. Kaminskiy wrote:
> As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639414
> imlib_image_draw_ellipse(4,4,2,1) triggers divide-by-zero and SIGFPE.
> I verified that bug can be reproduced in the current imlib2.
> Attached patch prevents sigfpe, but probably results in incorrect
> drawing.
> Minor security implications: DoS, if an application draws ellipse using
> coordinates from untrusted input.
> 

Hi,

I don't know the code well at all, but maybe setting dx/dy to 1 when
they are 0 would result in slightly more accurate drawing, setting the
result of the division to 0 would also probably be better then returning
mid function, I don't know which is the better of the two solutions,
maybe raster does.

Cheers

Simon

> 
> 
> --
> 
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [tools/eflete] master 05/06: UTC: fix test after API change

[Jaehwan Kim]

Thank you. I missed this tests.
2016. 4. 4. 오후 11:29에 "Vyacheslav Reutskiy" 님이 작성:

> rimmed pushed a commit to branch master.
>
>
> http://git.enlightenment.org/tools/eflete.git/commit/?id=26fcd1e75b140c8d5f8e96f4e26d9abc74f185de
>
> commit 26fcd1e75b140c8d5f8e96f4e26d9abc74f185de
> Author: Vyacheslav Reutskiy 
> Date:   Mon Apr 4 16:53:38 2016 +0300
>
> UTC: fix test after API change
>
> Tests was broken in  514ddf88cce7115b5514543da320b4d9be0d8ca8
>
> Change-Id: I416a9935654366a161ce4a1d073ff1feba7edec6
> ---
>  tests/test_project_manager/pm_project_close.c | 2 +-
>  tests/test_project_manager/pm_project_import_edj.c| 6 +++---
>  tests/test_project_manager/pm_project_meta_data_get.c | 2 +-
>  tests/test_project_manager/pm_project_meta_data_set.c | 2 +-
>  tests/test_project_manager/pm_project_open.c  | 2 +-
>  tests/test_project_manager/pm_project_save.c  | 2 +-
>  tests/test_project_manager/pm_project_thread_cancel.c | 2 +-
>  tests/test_project_manager/pm_project_thread_free.c   | 2 +-
>  8 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/tests/test_project_manager/pm_project_close.c
> b/tests/test_project_manager/pm_project_close.c
> index 8865d3e..0897fa3 100644
> --- a/tests/test_project_manager/pm_project_close.c
> +++ b/tests/test_project_manager/pm_project_close.c
> @@ -69,7 +69,7 @@ EFLETE_TEST (pm_project_close_test_p)
> ecore_file_recursive_rm("./UTC");
>
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> - NULL, _test_end_cb, NULL);
> + NULL, NULL, _test_end_cb, NULL);
> ecore_main_loop_begin();
>
> pro = pm_project_thread_project_get();
> diff --git a/tests/test_project_manager/pm_project_import_edj.c
> b/tests/test_project_manager/pm_project_import_edj.c
> index a678892..216a412 100644
> --- a/tests/test_project_manager/pm_project_import_edj.c
> +++ b/tests/test_project_manager/pm_project_import_edj.c
> @@ -70,7 +70,7 @@ EFLETE_TEST (pm_project_import_edj_test_p)
> ecore_file_recursive_rm("./UTC");
>
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> -  NULL, _end_cb, NULL);
> + NULL, NULL, _end_cb, NULL);
> ecore_main_loop_begin();
>
> pro = pm_project_thread_project_get();
> @@ -123,7 +123,7 @@ EFLETE_TEST (pm_project_import_edj_test_p1)
>
> res = EINA_FALSE;
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> -  _test_progress_cb, _end_cb, NULL);
> + NULL, _test_progress_cb, _end_cb, NULL);
> ecore_main_loop_begin();
> ck_assert_msg(res, "Progress callback did't called!");
>
> @@ -178,7 +178,7 @@ EFLETE_TEST (pm_project_import_edj_test_p2)
>
> res = EINA_FALSE;
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> - NULL, _test_end_cb, NULL);
> + NULL, NULL, _test_end_cb, NULL);
> ecore_main_loop_begin();
> ck_assert_msg(res, "End callback did't called!");
>
> diff --git a/tests/test_project_manager/pm_project_meta_data_get.c
> b/tests/test_project_manager/pm_project_meta_data_get.c
> index 22502e6..e123b34 100644
> --- a/tests/test_project_manager/pm_project_meta_data_get.c
> +++ b/tests/test_project_manager/pm_project_meta_data_get.c
> @@ -68,7 +68,7 @@ EFLETE_TEST (pm_project_meta_data_get_test_p)
> ecore_file_recursive_rm("./UTC");
>
> pm_project_import_edj("UTC", ".", "./edj_build/radio.edj",
> - NULL, _test_end_cb, NULL);
> + NULL, NULL, _test_end_cb, NULL);
> ecore_main_loop_begin();
>
> pro = pm_project_thread_project_get();
> diff --git a/tests/test_project_manager/pm_project_meta_data_set.c
> b/tests/test_project_manager/pm_project_meta_data_set.c
> index 86dc048..8830305 100644
> --- a/tests/test_project_manager/pm_project_meta_data_set.c
> +++ b/tests/test_project_manager/pm_project_meta_data_set.c
> @@ -69,7 +69,7 @@ EFLETE_TEST (pm_project_meta_data_set_test_p)
> ecore_file_recursive_rm("./UTC");
>
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> - NULL, _test_end_cb, NULL);
> + NULL, NULL, _test_end_cb, NULL);
> ecore_main_loop_begin();
>
> pro = pm_project_thread_project_get();
> diff --git a/tests/test_project_manager/pm_project_open.c
> b/tests/test_project_manager/pm_project_open.c
> index 5b69c11..6ae6586 100644
> --- a/tests/test_project_manager/pm_project_open.c
> +++ b/tests/test_project_manager/pm_project_open.c
> @@ -67,7 +67,7 @@ EFLETE_TEST (pm_project_open_test_p)
> ecore_file_recursive_rm("./UTC");
>
> pm_project_import_edj("UTC", ".",
> "./edj_build/test_project_manager.edj",
> - NULL, 

Re: [E-devel] e20 on Raspberry Pi

[Andreas Volz]

Am Mon, 4 Apr 2016 13:30:15 +0900 schrieb Carsten Haitzler (The
Rasterman):

> On Sun, 3 Apr 2016 22:15:19 +0200 Andreas Volz 
> said:
> 
> > Am Fri, 1 Apr 2016 16:31:42 -0700 schrieb Cedric BAIL:
> > 
> > > > I tried to start my application with the default Gtk based
> > > > window manager, but it's strange. As long as I activate alpha
> > > > and shaped window support in my application the application is
> > > > somehow broken and hangs in the beginning. I didn't yet trace
> > > > it out where it hangs.
> > > >
> > > > Do you have any ideas or explanations?
> > > 
> > > Not for the last problem.
> > 
> > I didn't change much in my application, but now I get a crash of
> > E20 and X back to the console if I start my application on the
> > Raspberry Pi.
> > 
> > In LXDE it still just hangs my application at the point it starts
> > the window. Need to start my application in the debugger and see
> > where it exact hangs.
> > 
> > See here the E crash dump:
> > 
> > http://tux-style.com/tmp/e-crashdump.txt
> 
> like 633? that's in bgr565 - 16bit handling. this will cause even
> more slowness as e has to use efl to convert 16bpp to 32bpp then
> render in 32bpp then render/dither back to 16bpp for the display...

Ok, have I influenced this in my application setup?

> try 24/32bpp for best results. but anyway. this says the 16bit
> converter has a bug maybe - > thats s16 (src 16bit) ptr - and it uses
> sbpl to multiply y + row so what's up with this? sbpl is src
> bytes per line. so 640 there. i assume its a 320 wide window then. is
> y and row ... wrong? row is the current row we are looking at? y + h
> > image height? height says it's 240. row is 0... src pts and s16 are
> > the same - so that's right. ... so it's not src. dp (destination
> > pointer) is the issue. in
> fact see dst - its NULL. (0x0). thats the issue. why is it null?
> that's odd. :(

No my window is 800x480 pixels big. Maybe that's the LXTerminal size. I
had two terminals open at this time.

The good thing for me is that it seems maybe not to be my applications
fault. Today I started just the LXTerminal from Raspi in E20 and I got
a X crash.


-- 
Technical Blog 

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [imlib2] integer divide by zero on 2x1 ellipse

[Yuriy M. Kaminskiy]

As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639414
imlib_image_draw_ellipse(4,4,2,1) triggers divide-by-zero and SIGFPE.
I verified that bug can be reproduced in the current imlib2.
Attached patch prevents sigfpe, but probably results in incorrect
drawing.
Minor security implications: DoS, if an application draws ellipse using
coordinates from untrusted input.

Description: fix divide-by-zero on drawing 2x1 ellipse
Author: Yuriy M. Kaminskiy 
Note: resulting images are probably incorrect; but SIGFPE is certainly worse.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639414

Index: imlib2-1.4.6/src/lib/ellipse.c
===
--- imlib2-1.4.6.orig/src/lib/ellipse.c
+++ imlib2-1.4.6/src/lib/ellipse.c
@@ -54,6 +54,7 @@ __imlib_Ellipse_DrawToData(int xc, int y
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -95,6 +96,9 @@ __imlib_Ellipse_DrawToData(int xc, int y
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -185,6 +189,7 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -247,6 +252,9 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -360,6 +368,7 @@ __imlib_Ellipse_FillToData(int xc, int y
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -417,6 +426,9 @@ __imlib_Ellipse_FillToData(int xc, int y
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -517,6 +529,7 @@ __imlib_Ellipse_FillToData_AA(int xc, in
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -579,6 +592,9 @@ __imlib_Ellipse_FillToData_AA(int xc, in
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Trouble pushing to imlib2

[Kim Woelders]

Hello,

I'm having trouble pushing stuff to the imlib2 git repository.
Is there some problem?
I had no problems a couple of weeks ago.


$ git pull
Current branch master is up to date.

$ git push
Counting objects: 24, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (24/24), done.
Writing objects: 100% (24/24), 2.47 KiB | 0 bytes/s, done.
Total 24 (delta 20), reused 0 (delta 0)
remote: FATAL: W refs/heads/master legacy/imlib2 kwo DENIED by 
refs/heads/master
remote: error: hook declined to update refs/heads/master
To git+ssh://g...@git.enlightenment.org/legacy/imlib2.git
  ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 
'git+ssh://g...@git.enlightenment.org/legacy/imlib2.git'

/Kim

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] UI syntax, last call discussion

[Yakov Goldberg]

On 04/04/2016 02:42 AM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 03 Apr 2016 17:37:16 +0300 Yakov Goldberg  said:
>
>> Tom, Raster thanks for comments.
>>
>> Wiki: https://phab.enlightenment.org/w/ui_builders_format/
>> Changes:
>> - first letter of widget is now lower case;
>> - fixed indentation - 4 spaces everywhere;
>> - fix Resource description;
>> - other minor updates.
>>
>> The reason I put resources separately is that I was still thinking in
>> Erigo scope.
>> You are right - resources should be right in the text.
>> And then gui builders should be able use API to get list of resources,
>> so GUI_BLDR'S own project files can be created to handle resource aliases.
>> As for format I like:
>>
>> res("path/layout.edj")
>> or
>> @"path/layout.edj"
>> or
>> ₪"path/layout.edj"
>> :)
>> ...can be decided a little bit later
> well i started work on this being done at runtime with "magic file paths" in
> efl. so far i have:
>
> "/path/to/whatever" <- normal
> "./path/to/whatveer" <- normal
> "../path/to/whatever" <- normal
> "path/to/whatever" <- normal (same as ./path/to/wahtever)
>
> and new ones:
>
> "~/path/to/whatever" <- like in shell
> "~username/path/to/whatever" <- like in shell
> "@key/path/to/whatever" <- new "magic location" where key is set at runtime
>
> so it's buried inside the path string itself. what they keys are will work out
> over time. i'm starting with some basics:
>
> @home <- same as ~/
> @tmp <- /tmp (or TMPDIR or other env vars pointing to where tmp should be)
> @data <- XDG_DATA_HOME = ~/.local/share
> @config <- XDG_CONFIG_HOME = ~/.config
> @cache <- XDG_CACHE_HOME = ~/.cache
> @run <- XDG_RUNTIME_DUR - depends likely set to /var/run/user/UID
>
> also likely:
>
> @download <- ~/Download
> @desktop <- ~/Desktop
> @documents <- ~/Documents
> @music <- ~/Music
> @pictures <- ~/Pictures
> @templates <- ~/.Templates
> @videos <- ~/Videos
>
> i am THINKING of app specific keys like:
>
> @app.dir/(prefix)
> @app.bin/(prefix/bin)
> @app.lib/(prefix/lib)
> @app.data/   (prefix/share/appname)
> @app.locale/ (prefix/share/locale)
> @app.config/ (@config/appname)
> @app.cache/  (@cache/appname)
> @app.local/  (@data/appname)
>
> ... maybe some more. then we get to the problem that efl itself should use 
> this
> too so i think over time efl should centralize data in PREFIX/share/efl (and
> binaries, libraries etc. go int he same dir anyway due to efl building as a
> single unit) so i am expecting to have:
>
> @efl.dir/
> @efl.bin/
> @efl.lib/
> @efl.data/
> @efl.locale/
> @efl.config/
> @efl.cache/
> @efl.locale/
>
> ...
>
> the same code CAN in theory do:
>
> file:/// . (but i have to write a uri parser/converter first)
> http:// (but then i have to write a whole http fetcher, downloader, 
> cacher)
> ssh:// (like with http - but need to use libssh etc.)
>
> the api is designed to be async out of the box, able t be extended by apps to
> customize special path handling of their own etc. ... once i have basics
> working i have to go over efl everywhere in eo api it takes a file... and make
> it use this.
>
> then we'll have a single place in efl to handle path redirection (magic paths)
> and this will save so much complexity in apps and even efl and make our lives
> so much better. we can drop http handling in elm_image for example but now it
> works everywhere out of the box.
>
> so there are 9in my dir here) eo classes that let you create a file object 
> from
> an input path and resolve the resulting location. here is the important bit - 
> i
> wasn't going to add any api to list files for you. i really don't think that
> belongs in this api imho.
Of course not. I meant: parser will have API to list all resources.
The rest is great!
> i think that requires you to use this api to resolve
> the path AND then to list the content yourself. :) this will require that you
> perhaps do something special lin erigo and convert erigo's @app.xxx/ namespace
> to fake/match the target application "current data/resources directory" and
> erigo setsup its own personal namespace for its own bin/data/whatever virtual
> paths (you can register special meta locations with vpath core)
>
> it'll make sense soon. :)
>
>> As for alignment in my example, I'd stick with indentation related to
>> parent. Don't know if it complicates implementation of generator...
>>
>> part["short_name"]: table(id = "table2")
>>   pack[0, 1, 1, 1]: image(file = "logo2.png")
>> part["very_long_part_name"]: table(id = "table2")
>>pack[0, 1, 1, 1]: image(file = 
>> "logo2.png")
>>
>>
>> Snippets:
>>I don't like my own suggestion either :) Need to re-think.
>>
>> Yakov
>>
>> On 03/30/2016 05:48 PM, Tom Hacohen wrote:
>>> You're a bit inconsistent on the wiki page.
>>> In some places you use lower case letters at the beginning of class
>>> names, in others upper case. In some cases you put a 

Re: [E-devel] [EGIT] [core/efl] master 03/03: Eolian: Mark all EO class_get() as weak

[Tom Hacohen]

On 04/04/16 05:20, Jean-Philippe André wrote:
> Hi Tom,
>
> On 3 April 2016 at 19:39, Tom Hacohen  wrote:
>
>> Btw, this patch is incomplete. It doesn't mark the class get functions as
>> weak.
>> [...]
>>>Eolian: Mark all EO class_get() as weak
>>
>
> This was done in two commits, and you were replying to the commit marking
> class_get as weak.
> So, yes, it does.

Sorry, tired. Noticed it too just now. Oops. :)

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] UI syntax, last call discussion

[The Rasterman]

On Mon, 4 Apr 2016 15:31:11 +1000 David Seikel  said:

> On Mon, 4 Apr 2016 13:20:50 +0900 Carsten Haitzler (The Rasterman)
>  wrote:
> 
> > On Mon, 4 Apr 2016 12:14:30 +1000 David Seikel 
> > said:
> > 
> > > > file:/// . (but i have to write a uri parser/converter first)
> > > > http:// (but then i have to write a whole http fetcher,
> > > > downloader, cacher) 
> > > > ssh:// (like with http - but need to use
> > > > libssh etc.)
> > > 
> > > As part of my SledjHamr project, I'm looking at http caching now.
> > > Polipo is something I have been using for some time as a web cache /
> > > proxy / filter.  I feel it's a good match for my big virtual world
> > > project.  I'm thinking it might port easily to EFL, which I'm
> > > likely to do eventually.
> > 
> > that is a whole different caching. polipo is a caching proxy. i am
> > thinking just simple stuff like keep files in a dir - if url opened >
> > 1 time - point back to existing file already downloaded. delete/clean
> > up files on exit. keep only up to n files or n mb worth of files
> > around that are not referenced.
> 
> Polipo, and any web cache, has code to do all of that.

but it is a binary - a process that keeps runing doing the job. thats different
to a library that has to sit around and be PARt of an existing process you
can't control much of.

> > the downside here is if app crashes or doesn't exit cleanly stuff
> > will be left around. :/ polipo is a whole different kettle of fish.
> 
> My plan is to port polipo to EFL, but not as a stand alone server
> application, but as a library, plus a thin server application.  Then
> the bits and pieces of the code can be used elsewhere.  Like to
> implement what you are thinking of.  It's the same kettle, just more
> fish.  B-)

i personally wouldn't as i would just need to do some minimal curl work and
simply match the url to an existing file for a cache. cross-process caching
can be handled by something like polipo.

i wouldn't even respect Cache-Control to begin with to begin with though.
though that'd be easy to add later. its far simpler doing it this way than
merging a whole different codebase (of 20k lines of c) into efl. i can really
add maybe a few hundred lines of code at most and i imagine that's far less work
i'd do than merging an existing binary to work inside a library and maintain
it. if have no need to do the http or socks etc - leave that to curl.

> > > It cleans up client and server side protocols, promoting them to the
> > > latest and the fastest.  Includes SOCKS4 / 5 for upstream, which I
> > > have been using via ssh.  Was designed to be a single user (mostly)
> > > proxy, which fits my needs at least.  It even has a filter which I
> > > feed converted AdBlock+ filter files to.
> > > 
> > > Since it cleans up protocols as a proxy layer, I figure it's fetcher
> > > and server bits might be usable anywhere I need an HTTP fetcher or
> > > server.  SledjHamr relies a lot on HTTP to shift assets around, so
> > > that will be useful to me.  Even file:// will be useful, one of my
> > > major features is that SledjHamr defaults to running a local server
> > > on your desktop hard drive.
> > > 
> > > I had previously ported luaproc to EFL, and I expect similar results
> > > if I port polipo, lots of the code vanished, since it was just
> > > implementing stuff EFL does anyway.  Which is what makes such things
> > > good candidates for EFL porting.  B-)
> > > 
> > > 
> > > I've not been commenting on the UI syntax, since I've been working
> > > on my own, which is a C / Lua reboot of something I wrote long ago
> > > in Java.  It's designed to suit my needs.
> 
> -- 
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel