On Wednesday, October 17, 2012, Carsten Haitzler wrote:
> On Wed, 17 Oct 2012 15:17:41 -0300 Lucas De Marchi
> <lucas.demar...@profusion.mobi <javascript:;>> said:
>
> > On Wed, Oct 17, 2012 at 11:27 AM, Carsten Haitzler
> > <ras...@rasterman.com<javascript:;>
> >
> > wrote:
> > > On Wed, 17 Oct 2012 10:01:23 -0300 Gustavo Sverzut Barbieri
> > > <barbi...@profusion.mobi <javascript:;>> 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.
Again I believe your just considering the good path. The wrong will turn
into debugging hell.
I like leandro's approach as its used by him in his server lwan. You can
defer cleanup calls and this works for strings, opened files and whatever
you want.
http://tia.mat.br/posts/deferred_statements_in_c/
>
> > 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 <javascript:;>
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com <javascript:;>
>
>
>
> ------------------------------------------------------------------------------
> 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 <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
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
