On Thu, Aug 11, 2016 at 12:30 PM, Davide Andreoli <[email protected]> wrote: > 2016-08-10 23:11 GMT+02:00 Gustavo Sverzut Barbieri <[email protected]>: > >> ping... since this blocks some stuff I'm doing, will consider in >> agreement in 14h. :-) >> > > What I can say is that Eina_Slice is a bad name, should just be Eina_Buffer > or Eina_MemBuffer. > > And I tend to agree with raster to reuse the already available binbuf, if > it's feasible. >
Slice is a good name, it's a slice of memory (without itself allocating said memory) and that's how this kind of stuff is commonly called in various places. However, I see another problem here, if we use mutable slices in our APIs, things are going to become difficult in our bindings... ideally, I would like all returned values from EFL APIs to be either immutable or alternatively owned by the caller (i.e. any writes in that returned value wouldn't affect any sort of internal state) and same with passed values, when passing EFL would either take ownership or make an internal copy for itself. Then any state changes would be done via Eo APIs. This way we can ensure bindings are super simple to generate and handle and it can even support languages that don't have mutability (like Haskell) very easily. D5 > >> >> On Tue, Aug 9, 2016 at 6:31 PM, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >> > Hi all, >> > >> > If you followed the Ecore-Con and Ecore-Con-URL Eoify emails I've sent >> > you'll notice one of the proposals is to introduce Stream Reader and >> > Writer interfaces, that the default implementations will do a read(2) >> > and write(2) with minimum interference. >> > >> > Those require the traditional "const void *buf, size_t buflen" (read) >> > and "void *buf, size_t buflen" (write). You can guess that hinting >> > the bindings and users that both are correlated is a pain, thus the >> > idea to introduce simple structures to state so: >> > >> > typedef struct _Eina_Slice { >> > const void *mem; >> > size_t len; >> > } Eina_Slice; >> > >> > typedef struct _Eina_Rw_Slice { >> > void *mem; >> > size_t len; >> > } Eina_Rw_Slice; >> > >> > With those Eolian could introduce a new native type "slice" that maps >> > to "Eina_Rw_Slice" and "const(slice)" to "Eina_Slice". >> > >> > These could be introduce in most functions we currently have >> > "_length()" variants, like "eina_stringshare_add_length()" could have >> > "eina_stringshare_add_slice()". Likewise, APIs could return both in >> > one go, like "eina_binbuf_string_get() + eina_binbuf_length_get()" >> > could be fulfilled by "eina_binbuf_slice_get()". >> > >> > For ease of use, we can even pass and return the struct directly, not >> > a pointer to one. Example: >> > >> > Eina_Slice eina_binbuf_slice_get(const Eina_Binbuf *buf) { >> > return (Eina_Slice){.mem = buf->buf, .len = buf->len}; >> > } >> > >> > which allows: >> > >> > Eina_Slice s = eina_binbuf_slice_get(buf); // no malloc/free >> > >> > Likewise for parameters: >> > >> > Eina_Error efl_interface_reader_read(Eo *obj, Eina_Rw_Slice dst, >> > size_t *used) { >> > while (1) { >> > ssize_t r = read(pd->fd, dst.mem, dst.len); >> > if (r >= 0) { >> > *used = r; >> > return 0; >> > } else if (errno != EINTR) { >> > return eina_error_from_errno(errno); /* to be created */ >> > } >> > } >> > } >> > >> > while allows: >> > >> > err = efl_interface_reader_read(obj, (Eina_Rw_Slice){.buf = >> > localbuf, .len=sizeof(localbuf)}, &used); >> > >> > (usually that's the expansion of some helper macro, like >> read_from_literal()). >> > >> > >> > All of that said, are you okay with adding Eina_Slice and Eina_Rw_Slice? >> > >> > -- >> > Gustavo Sverzut Barbieri >> > -------------------------------------- >> > Mobile: +55 (16) 99354-9890 >> >> >> >> -- >> Gustavo Sverzut Barbieri >> -------------------------------------- >> Mobile: +55 (16) 99354-9890 >> >> ------------------------------------------------------------ >> ------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. http://sdm.link/zohodev2dev >> _______________________________________________ >> enlightenment-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
