On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri <vtorri@...>
> said:
>
>> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
>>
>>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri
>>> <vtorri@...> said:
>>>
>>>>
>>>>
>>>> On Tue, 26 Apr 2011, Enlightenment SVN wrote:
>>>>
>>>>> Log:
>>>>> some readme fun
>>>>>
>>>>>
>>>>>
>>>>> Author: raster
>>>>> Date: 2011-04-26 00:46:01 -0700 (Tue, 26 Apr 2011)
>>>>> New Revision: 58922
>>>>> Trac: http://trac.enlightenment.org/e/changeset/58922
>>>>>
>>>>> Modified:
>>>>> trunk/evas_generic_loaders/README
>>>>>
>>>>> Modified: trunk/evas_generic_loaders/README
>>>>> ===================================================================
>>>>> --- trunk/evas_generic_loaders/README 2011-04-26 07:29:30 UTC (rev
>>>>> 58921) +++ trunk/evas_generic_loaders/README 2011-04-26 07:46:01
>>>>> UTC (rev 58922) @@ -1,2 +1,27 @@
>>>>> Additional "generic" loaders for Evas that are stand-alone executables
>>>>> -evas may run from its generic loader module
>>>>> +evas may run from its generic loader module.
>>>>> +
>>>>> +Generic loaders currently provided:
>>>>> +
>>>>> + XCF (.xcf .xcf.gz)
>>>>> +
>>>>> +Wanted:
>>>>> +
>>>>> + RAW
>>>>> + (libopenraw1 ??)
>>>>> + PDF
>>>>> + (use -key option to specific what page to get and load options for
>>>>> size
>>>>> + and use poppler and/or mupdf - look at epdf)
>>>>> + PS
>>>>> + (use -key option to specific what page to get and load options for
>>>>> size
>>>>> + and use ghostscript (libgs) to render etc.)
>>>>
>>>> what is the interest compared to eyesight/epdf/eps ?
>>>
>>> trivial thumbnailing. not intended for full ps/pdf control. also to avoid
>>> the gpl issue in epdf. you could have a loader use evas itself and epdf
>>> etc. if u wanted. it'd work. use buffer engine and render to memory. i'm
>>> not that fussed really.
>>
>> I've looked a bit at the xcf code. Why are you doing a binary and not a
>> lib ? (having an init, shutdown, head and data functions)
>
> 1. its the old xcf loader code from imlib2_loaders, so its inheriting fluff
> 2. GPL. making it a lib makes it a GPL lib and anything linking to it becomes
> GPL. making an executable avoids the GPL problem. thats WHY i mentioned PDF and
> PS - epdf has a GPL problem.
i thought that with shm_open, we could avoid that problem, even with a
lib. But it seems it's not the case.
>> Also, maybe you could add a library that implment common code. I think
>> about shm_alloc and shm_free, that are (almost) not related to the loader.
>> (shm_alloc needs the name of the loader, and one would have to apss a
>> pointer for the stored values like shm_fd, etc...)
>
> when/if time permits. right now there is just 1 binary there. when there are 2
> i might make the code common and compiled into both. there is little point for
> a shared lib at this stage as the shared code is infinitesimal and any savings
> in not duplicating it are lost in multiple separate pages for the code and
> symbols and so on. :)
not a shared lib. a static lib (a .la, which is not installed, and we link
against it, like we do with sub parts of evas for example).
Vincent

On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote:
> no. if you link, then both the code and data for the GPL stuff shares the
> memory space of the rest of the lib (evas) and thus also the app using evas.
> thus.. GPL leaks through. as a separate process that dumps dumb data into a
> temporary file (that it mmaps - be it a shm "file" or a real one) or a
> pipe/stream, then they share no memory space with the app.
I hate GPL (for libs).
--
Tom.

On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen
<tom.hacohen@...> said:
> On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote:
> > no. if you link, then both the code and data for the GPL stuff shares the
> > memory space of the rest of the lib (evas) and thus also the app using evas.
> > thus.. GPL leaks through. as a separate process that dumps dumb data into a
> > temporary file (that it mmaps - be it a shm "file" or a real one) or a
> > pipe/stream, then they share no memory space with the app.
>
> I hate GPL (for libs).
that's why the generic loader mechanism executes a binary. yet its not
efficient. yes its kind of hacky - its the only solution to
1. thing to do the decoding is GPL and u dont want a license leak into an app
and
2. thing that decodes may leak memory and/or crash, so you need to isolate it
into its own process so it can crash that sometimes without bringing your main
app down with it.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Wed, Apr 27, 2011 at 2:00 PM, Carsten Haitzler <raster@...>wrote:
> 1. thing to do the decoding is GPL and u dont want a license leak into an
> app
> and
>
Yes, that's what I hate.
> 2. thing that decodes may leak memory and/or crash, so you need to isolate
> it
> into its own process so it can crash that sometimes without bringing your
> main
> app down with it.
>
This was my argument when I talked about implementing efm outside of e
itself.
Given this rationale we should split a lot more than we currently do, and
evas itself
is probably not the best place to start at :)
But yeah, reason #1 is good enough and that's why I hate GPL (for libs),
forcing us
to do such awful things just to avoid evilness.
--
Tom.

On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 27 Apr 2011 11:17:07 +0200 (CEST) Vincent Torri <vtorri@...>
> said:
>
>>
>>
>> On Wed, 27 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
>>
>>> On Wed, 27 Apr 2011 09:57:30 +0200 (CEST) Vincent Torri
>>> <vtorri@...> said:
>>>
>>>> On Tue, 26 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
>>>>
>>>>> On Tue, 26 Apr 2011 09:54:53 +0200 (CEST) Vincent Torri
>>>>> <vtorri@...> said:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, 26 Apr 2011, Enlightenment SVN wrote:
>>>>>>
>>>>>>> Log:
>>>>>>> some readme fun
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Author: raster
>>>>>>> Date: 2011-04-26 00:46:01 -0700 (Tue, 26 Apr 2011)
>>>>>>> New Revision: 58922
>>>>>>> Trac: http://trac.enlightenment.org/e/changeset/58922
>>>>>>>
>>>>>>> Modified:
>>>>>>> trunk/evas_generic_loaders/README
>>>>>>>
>>>>>>> Modified: trunk/evas_generic_loaders/README
>>>>>>> ===================================================================
>>>>>>> --- trunk/evas_generic_loaders/README 2011-04-26 07:29:30 UTC
>>>>>>> (rev
>>>>>>> 58921) +++ trunk/evas_generic_loaders/README 2011-04-26 07:46:01
>>>>>>> UTC (rev 58922) @@ -1,2 +1,27 @@
>>>>>>> Additional "generic" loaders for Evas that are stand-alone executables
>>>>>>> -evas may run from its generic loader module
>>>>>>> +evas may run from its generic loader module.
>>>>>>> +
>>>>>>> +Generic loaders currently provided:
>>>>>>> +
>>>>>>> + XCF (.xcf .xcf.gz)
>>>>>>> +
>>>>>>> +Wanted:
>>>>>>> +
>>>>>>> + RAW
>>>>>>> + (libopenraw1 ??)
>>>>>>> + PDF
>>>>>>> + (use -key option to specific what page to get and load options for
>>>>>>> size
>>>>>>> + and use poppler and/or mupdf - look at epdf)
>>>>>>> + PS
>>>>>>> + (use -key option to specific what page to get and load options for
>>>>>>> size
>>>>>>> + and use ghostscript (libgs) to render etc.)
>>>>>>
>>>>>> what is the interest compared to eyesight/epdf/eps ?
>>>>>
>>>>> trivial thumbnailing. not intended for full ps/pdf control. also to avoid
>>>>> the gpl issue in epdf. you could have a loader use evas itself and epdf
>>>>> etc. if u wanted. it'd work. use buffer engine and render to memory. i'm
>>>>> not that fussed really.
>>>>
>>>> I've looked a bit at the xcf code. Why are you doing a binary and not a
>>>> lib ? (having an init, shutdown, head and data functions)
>>>
>>> 1. its the old xcf loader code from imlib2_loaders, so its inheriting fluff
>>> 2. GPL. making it a lib makes it a GPL lib and anything linking to it
>>> becomes GPL. making an executable avoids the GPL problem. thats WHY i
>>> mentioned PDF and PS - epdf has a GPL problem.
>>
>> i thought that with shm_open, we could avoid that problem, even with a
>> lib. But it seems it's not the case.
>
> no. if you link, then both the code and data for the GPL stuff shares the
> memory space of the rest of the lib (evas) and thus also the app using evas.
> thus.. GPL leaks through. as a separate process that dumps dumb data into a
> temporary file (that it mmaps - be it a shm "file" or a real one) or a
> pipe/stream, then they share no memory space with the app.
ok
>>>> Also, maybe you could add a library that implment common code. I think
>>>> about shm_alloc and shm_free, that are (almost) not related to the loader.
>>>> (shm_alloc needs the name of the loader, and one would have to apss a
>>>> pointer for the stored values like shm_fd, etc...)
>>>
>>> when/if time permits. right now there is just 1 binary there. when there
>>> are 2 i might make the code common and compiled into both. there is little
>>> point for a shared lib at this stage as the shared code is infinitesimal
>>> and any savings in not duplicating it are lost in multiple separate pages
>>> for the code and symbols and so on. :)
>>
>> not a shared lib. a static lib (a .la, which is not installed, and we link
>> against it, like we do with sub parts of evas for example).
>
> can do - that.. once it becomes useful to do it. ie.. when there is > 1
> binary :)
pdf, dvi, ps djvu.
Vincent

On Wed, 27 Apr 2011 20:00:31 +0900 Carsten Haitzler (The Rasterman)
<raster@...> wrote:
> On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen
> <tom.hacohen@...> said:
>
> > On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote:
> > > no. if you link, then both the code and data for the GPL stuff
> > > shares the memory space of the rest of the lib (evas) and thus
> > > also the app using evas. thus.. GPL leaks through. as a separate
> > > process that dumps dumb data into a temporary file (that it mmaps
> > > - be it a shm "file" or a real one) or a pipe/stream, then they
> > > share no memory space with the app.
> >
> > I hate GPL (for libs).
>
> that's why the generic loader mechanism executes a binary. yet its not
> efficient. yes its kind of hacky - its the only solution to
>
> 1. thing to do the decoding is GPL and u dont want a license leak
> into an app and
I'm finding it ironic that a license allegedly all about preserving
freedom, tends to take away the freedom to link.
> 2. thing that decodes may leak memory and/or crash, so you need to
> isolate it into its own process so it can crash that sometimes
> without bringing your main app down with it.
That's a good reason though.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On Thu, 28 Apr 2011 06:39:01 +1000 David Seikel <onefang@...> said:
> On Wed, 27 Apr 2011 20:00:31 +0900 Carsten Haitzler (The Rasterman)
> <raster@...> wrote:
>
> > On Wed, 27 Apr 2011 13:50:39 +0300 Tom Hacohen
> > <tom.hacohen@...> said:
> >
> > > On Wed, 2011-04-27 at 19:49 +0900, Carsten Haitzler wrote:
> > > > no. if you link, then both the code and data for the GPL stuff
> > > > shares the memory space of the rest of the lib (evas) and thus
> > > > also the app using evas. thus.. GPL leaks through. as a separate
> > > > process that dumps dumb data into a temporary file (that it mmaps
> > > > - be it a shm "file" or a real one) or a pipe/stream, then they
> > > > share no memory space with the app.
> > >
> > > I hate GPL (for libs).
> >
> > that's why the generic loader mechanism executes a binary. yet its not
> > efficient. yes its kind of hacky - its the only solution to
> >
> > 1. thing to do the decoding is GPL and u dont want a license leak
> > into an app and
>
> I'm finding it ironic that a license allegedly all about preserving
> freedom, tends to take away the freedom to link.
it's the WAY gpl defined what is a derivate that is a problem. an app that
someone decided to license under BSD, or make closed that just uses a public
api provided and encouraged to be used (like evas) should not (imho) be forced
into an unwanted licensing decision for their app or software. that's their
decision. but if indirectly some deep down component of this lib causes their
app to HAVE to become GPL, then that's not preserving freedom. that's "freedom
in our way only". i'm not going to make evas do that. a generic loader that can
just blindly execute some binary that happens to have the right name avoids
that problem entirely. we've separated out the license problem. that specific
loader binary and all its derivative works become GPL. but that's as far as
that goes.
> > 2. thing that decodes may leak memory and/or crash, so you need to
> > isolate it into its own process so it can crash that sometimes
> > without bringing your main app down with it.
>
> That's a good reason though.
both are good reasons. without #1 we will NOT be getting a RAW loader, not XCF
loader, nor PDF, and so on. we can now have them, but at a performance price.
these are not common enough to be an issue, so it doesn't much matter :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri <vtorri@...>
said:
> > can do - that.. once it becomes useful to do it. ie.. when there is > 1
> > binary :)
>
> pdf, dvi, ps djvu.
once someone starts another blob of src for another binary loader.. it can be
put into common shared code. it doesn't actually have to be a lib.a - it can
just be the same c file included in both src lists. simpler :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri <vtorri@...>
> said:
>
>>> can do - that.. once it becomes useful to do it. ie.. when there is > 1
>>> binary :)
>>
>> pdf, dvi, ps djvu.
>
> once someone starts another blob of src for another binary loader.. it can be
> put into common shared code. it doesn't actually have to be a lib.a - it can
> just be the same c file included in both src lists. simpler :)
why doing simple things ? :p You're right :)
Vincent

On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri <vtorri@...>
> said:
>
>>> can do - that.. once it becomes useful to do it. ie.. when there is > 1
>>> binary :)
>>
>> pdf, dvi, ps djvu.
>
> once someone starts another blob of src for another binary loader.. it can be
> put into common shared code. it doesn't actually have to be a lib.a - it can
> just be the same c file included in both src lists. simpler :)
I'm still wondering aboutefficiency : for example, for pdf rendering,
shouldn't the use of a pdf generic loader be slower than wht i can achieve
in eyesight ?
Vincent

On Fri, 29 Apr 2011 11:58:43 +0200 (CEST) Vincent Torri <vtorri@...>
said:
>
>
> On Fri, 29 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
>
> > On Wed, 27 Apr 2011 14:06:59 +0200 (CEST) Vincent Torri
> > <vtorri@...> said:
> >
> >>> can do - that.. once it becomes useful to do it. ie.. when there is > 1
> >>> binary :)
> >>
> >> pdf, dvi, ps djvu.
> >
> > once someone starts another blob of src for another binary loader.. it can
> > be put into common shared code. it doesn't actually have to be a lib.a - it
> > can just be the same c file included in both src lists. simpler :)
>
> I'm still wondering aboutefficiency : for example, for pdf rendering,
> shouldn't the use of a pdf generic loader be slower than wht i can achieve
> in eyesight ?
rendering-wise, no, but the fact that it has to execute a whole new process
will slow it down, not to mention that if you want to access > 1 page, ot needs
to keep opening and re-parsing the file to find the page you want. it's not
meant for efficiency. it's meant to not force gpl on people who simply want to
load an image (that happens to be a pdf). this makes ethumb instantly able to
thumbnail pdf's for example. as i said - sure. not efficient, but works. not
for the purpose of making a pdf viewer or embedding pdf docs in an app where u
want content inspection and control. just for dumb "load me page x" from pdf.
or ps. or xfc.gz, ro for our always crashing svg loader...
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote:
> I'm still wondering aboutefficiency : for example, for pdf rendering,
> shouldn't the use of a pdf generic loader be slower than wht i can achieve
> in eyesight ?
Only if you fork once per page or something like that. Give it a minimal
input processing like Ghostscript's X11 target and the overhead is going
to mostly vanish. E.g. "open", "render $page $resolution" "close" should
be good enough for most purposes.
Joerg

On Sat, 30 Apr 2011, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 29 Apr 2011 17:26:23 +0200 Joerg Sonnenberger <joerg@...>
> said:
>
>> On Fri, Apr 29, 2011 at 11:58:43AM +0200, Vincent Torri wrote:
>>> I'm still wondering aboutefficiency : for example, for pdf rendering,
>>> shouldn't the use of a pdf generic loader be slower than wht i can achieve
>>> in eyesight ?
>>
>> Only if you fork once per page or something like that. Give it a minimal
>> input processing like Ghostscript's X11 target and the overhead is going
>> to mostly vanish. E.g. "open", "render $page $resolution" "close" should
>> be good enough for most purposes.
>
> the generic loader does fork once.. actually it forks AND execs TWICE per load
> (once for header, once for body).
if one has to parse the file for each display of a page, then it's
definitely not the way to use for a document viewer. It can indeed be good
for thumbnailing, like an icon on the desktop or in a file viewer.
Vincent