On Wed, 17 Oct 2012 15:17:41 -0300 Lucas De Marchi
<lucas.demar...@profusion.mobi> said:
> On Wed, Oct 17, 2012 at 11:27 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Wed, 17 Oct 2012 10:01:23 -0300 Gustavo Sverzut Barbieri
> > <barbi...@profusion.mobi> said:
> >
> > did u read the docs provided? they provide example use cases (simplified).
> >
> > as to the below - the cost of the ptr isn't worth worrying about - they are
> > temporary... VERY temporary. it's a special thing to allow c to be more like
> > js/lua/shell etc. think of eobj. now we do things like
> >
> > obj = eo_add(class, parent,
> > GEOMETRY(10, 20, 50, 30),
> > FILE_SET("/path/to/file"),
> > GROUP_SET("groupname"));
> >
> > ok - so file is a constant string. so is group. now let's pretend we want to
> > FIND a data file in a path or relative to the apps installed dir at runtime
> > and we have:
> >
> > const char *file_find(const chart *file);
> >
> > how could i do something convenient like
> >
> > obj = eo_add(class, parent,
> > GEOMETRY(10, 20, 50, 30),
> > FILE_SET(file_find("image.jpg")),
> > GROUP_SET(group_find("base")));
> >
> > the only way is to provide a buffer to snprintf into OR to return a
> > strduped or strinshare'd string... the problem is all our existing api
> > doesn't free this
>
> What's the problem of passing a a buffer to snprintf into?
having to keep creating/declaring such buffers yourself all the time.
> const char *file_find(char buf[PATH_MAX], const char *filename)
> {
> const char *prefix = "/tmp";
> snprintf(buf, PATH_MAX, "%s/%s", filename);
> return buf;
> }
>
> obj = eo_add(class, parent,
> GEOMETRY(10, 20, 50, 30),
> FILE_SET(file_find(buf1, "image.jpg")),
> GROUP_SET(group_find(buf2, "base")));
>
>
> one big downside from your approach with Eina_Tmpstr is that it's not
> clear at all who is responsible to free it. Sure there can be a
> convention like "the function receiving Eina_Tmpstr as parameter free
> it". But it's a convention prone to bugs. And it will do very bad
> things if you pass it around:
if something is delcared as
FILE_SET(Eina_Tmpstr *str)
then it declares that it will do the cleanup.
> void f(Eina_Tmpstr *newname) {
> my_movefile(my_homedir(), newname);
> my_movefile(my_tmpdir(), newname);
> eina_tmpstr_del(newname);
> }
>
> > string afterwards. it has no idea where the string came from so you CANNOT
> > do the above as you will leak strings as no one frees them. the alternative
> > is that you have to do it in 2 stages - get the strings first, then call
> > the api, then free them afterwards. imaging you wanted to find 2 different
> > files - so you couldnt use a static char buffer either as u'd overwrite the
> > same buffer within the call args.
>
> you shouldn't use a static char buffer, but as many buffers as the
> strings you will snprintf.
and that becomes a problem where you need multilpe strs and keep declaring
fixed 4k buffers pushing the stack up a lot each time. it also just is extra
cumbersomeness we can avoid - that is what tmpstr does.
> >
> > tmpstr solves that by provide a very short list of "currently active"
> > strings that are duplicated and survive as a return string SO they can be
> > passed in as params to the method above and then be freed by the method
> > when done. the advantage is they are really simple and trivially detected
> > as being a tmpstr or not. if not it does what it does now - leaves it
> > alone. it may be a const str or some other buffer that doesn't need freeing
> > here. this system is to be able to preserve an entire string as a return
> > value long enough to go INTO another func as is given as examples in the
> > docs.
> >
> > this is also part of making things IDE friendly. as above with FILE_SET
> > literally an IDE could provide not just autocomplete but once u start
> > typeing in FILE_SET(... pop up a file browser to select a data file from
> > your apps "project tree" without having to find the full file name and just
> > put it in there with the file find api as above nicely for you. as you
> > scroll around a thumbnail of the file is provided above.near the entry in
> > the src and if u want ot change it just click on it and select something
> > else. it's making it user friendly AND compact. it's one step of many.
>
> this IDE-friendly thing could be made regardless how FILE_SET operates
> or am I missing anything?
it has no context for what purpose the string (or file) will be used. it
just knows u are finding a file. it doesn't know its an image, or a video file
(emotion), etc. and thus is unable to do nice filtering for you.
the POINT of tmpstr is to do this:
do_thing(obj, find_file("x"), find_file("y"), find_file("z");
instead of:
char buf1[4096], buf2[4096], buf3[4096];
find_file(buf1, sizeof(buf1), "x");
find_file(buf2, sizeof(buf2), "y");
find_file(buf3, sizeof(buf3), "z");
do_thing(obj, buf1, buf2, buf3);
it's a lot more compact. it's easier to read. easier to use. it uses less
memory (the 2nd example forces the stack to push up 12k and once stack pushes
its high water mark it stays permanently there even if we pop back down).
you don't HAVE to use it. you can do the 2nd one - it's still compatible as it
skips strings it doesn't know about and is SAFE when doing that (unlike
stringshare which has to assume a few bytes before the stringptr are some
strshare data bits). we can add a clean/flush call that nukes all tmpstrs every
now and again. users can call it at the end of a function if they want too and
we can enforce it via the mainloop just in case.
> Lucas De Marchi
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> 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
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
