enum Foo {} is simpler but it also means that all tapedef's are equally
prefixed by "_". What if you need to have a different prefix or name?
In C I prefer 'typedef struct {....} Foo;' but 'typedef _Foo Foo' close to
the top of header helps readability when you have many structs in your .h
however your code editor may help on this too (depending on which features
your code editor has)
On Thu, Jul 17, 2014 at 9:31 PM, Jean-Philippe André <j...@videolan.org>
wrote:
> Hi
>
> On Thu, Jul 17, 2014 at 6:31 AM, Daniel Kolesa <quake...@gmail.com> wrote:
>
> > 2014-07-16 22:17 GMT+01:00 Larry de Oliveira Lira Jr <
> > la...@expertisesolutions.com.br>:
> >
> > > Hello all
> > >
> > > we have a new version of emodel based in all feedback here (thanks for
> > all)
> > > this version is in working progress, and docs is not complete yet, but
> > any
> > > new feedback is appreciated
> > >
> > > http://pastebin.com/uAxb3PHp
> > >
> > >
> > Glad you guys are trying out new Eolian stuff already. The enum won't
> parse
> > yet though...
> >
> > also
> >
> > the syntax will allow this notation:
> >
> > type Foo: enum _Foo
> > {
> > ....
> > }
> >
> > just like C allows "typedef enum _Foo { ... } Foo;".
> >
>
> Why do we need to declare type Foo when we already declared enum Foo?
> IMO this is an ugly thing in C (typedef struct _A A), no need to repeat it
> in Eo.
>
> enum Foo {} would be simpler, no?
>
> Unless there's a very good reason for it, of course :)
>
> Cheers,
>
>
> >
> >
> > >
> > > On Tue, Jul 8, 2014 at 2:46 AM, Carsten Haitzler <ras...@rasterman.com
> >
> > > wrote:
> > >
> > > > On Mon, 7 Jul 2014 11:27:27 -0300 Carlos Carvalho
> > > > <ccarva...@expertisesolutions.com.br> said:
> > > >
> > > > > Hi Raster!
> > > > >
> > > > >
> > > > > On Tue, Jul 1, 2014 at 6:36 AM, Carsten Haitzler <
> > ras...@rasterman.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > On Tue, 24 Jun 2014 12:25:53 -0300 Carlos Carvalho
> > > > > > <ccarva...@expertisesolutions.com.br> said:
> > > > > >
> > > > > > child_select() and child_select_eval() are basically not
> > documented.
> > > i
> > > > can
> > > > > > guess that they may create a EMODEL_EVENT_CHILD_SELECTED later...
> > but
> > > > what
> > > > > > is
> > > > > > the difference between these? no info there. and the docs for the
> > > > events
> > > > > > point
> > > > > > back to these functions...
> > > > > >
> > > > > > prop_list and prop_fetch are also basically undocumented. how do
> > > these
> > > > > > interact
> > > > > > with EMODEL_EVENT_PROPERTY_CHANGE callbacks? i might guess
> > prop_list
> > > > calls
> > > > > > the
> > > > > > callback on every property the object has once it has fetched
> them.
> > > > how do
> > > > > > i
> > > > > > know the calls are finished? imagine it finds one property every
> > > > second and
> > > > > > keeps calling... for how long? when is it done? no info there and
> > as
> > > > best i
> > > > > > see, no way to figure it out. prop_fetch fetches a single prop
> so i
> > > > know
> > > > > > once i
> > > > > > get the cb after that... i have my prop. now more fun - what if i
> > > > > > prop_list and
> > > > > > prop_fetch one after the other? ... fetches are delayed... but
> the
> > > same
> > > > > > callback. again - docs!
> > > > > >
> > > > > > prop_set - this sets a prop. .. what does that have to do with
> > > > > > EMODEL_EVENT_PROPERTY_CHANGE event callbacks? no info. no docs.
> no
> > > > > > explanation.
> > > > > > please... explain!
> > > > > >
> > > > >
> > > > > The prop_list will raise EMODEL_EVENT_PROPERTIES_CHANGE event. It
> > > > provides
> > > > > Eina_Value that may be dependent on implementation. In Emodel_Eio
> it
> > > > > is Eina_Value_Struct containing all properties.
> > > >
> > > > ok - so do you get one prop change event per prop list? mutliple? can
> > you
> > > > get
> > > > zero? how do you know the object has no properties at all? (if you
> prop
> > > > list
> > > > and never get a cb... how long should you wait? etc.). i'm pointing
> > out a
> > > > hole
> > > > here. if you have zero props - how do i know for sure in a known
> > bounded
> > > > amount
> > > > of time? you need to let the caller know when their prop change
> events
> > > are
> > > > finished (eg a prop change event with a NULL eina value), but you
> need
> > to
> > > > document this too. also should it maybe be Eina_Value *value in the
> > > > property
> > > > event? then the value can be shared out from the model internals
> > without
> > > > copying ... maybe const Eina_Value * to indicate its read-only
> > > >
> > > > > With prop_fetch you can retrieve the value associated with the
> > > property.
> > > > > prop_list must be executed beforehand so you can know what are the
> > > > > properties available.
> > > > > prop_fetch is associated with the event
> EMODEL_EVENT_PROPERTY_CHANGE.
> > > >
> > > > ok - so on a fetch success a prop change event is triggered, what
> > happens
> > > > on
> > > > failure? how do i know it failed? what if i do several fetches in a
> > row -
> > > > fetch
> > > > a, b then c... and later get the cb's... how do i know which one
> > failed?
> > > >
> > > > > prop_set is there so you can set a new value into given property.
> > > > > Again EMODEL_EVENT_PROPERTY_CHANGE is used.
> > > >
> > > > ok - so what on failure of set... :) (see the pattern - i'm poking at
> > > error
> > > > conditions/boundaries to ensure they are covered).
> > > >
> > > > > About child_select and child_eval, we are evaluating both and I'll
> > get
> > > > back
> > > > > in touch soon about those if you don't mind.
> > > >
> > > > ok - just scant on documentation there... thus i have to query. still
> > > > scant in
> > > > git as of right now. :)
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > child_del - does this generate EMODEL_EVENT_CHILD_DEL event
> > > callbacks?
> > > > or
> > > > > > is it
> > > > > > just referred to for interest sake? docs!
> > > > > >
> > > > > > children_fetch - less mysterious, i can guess the cb is called
> per
> > > > child,
> > > > > > every
> > > > > > child... so when is it finished calling? like above...
> > > > > >
> > > > > > children_slice_fetch - like above, but now this indicates
> children
> > > may
> > > > or
> > > > > > may
> > > > > > not be fetched? that means i don't know when it''s done. i ftech
> > > range
> > > > > > 50-150... but if some children don't exist.. what happens? do i
> get
> > > > > > called? not
> > > > > > called? when am i done?...
> > > > >
> > > > >
> > > > > > even better - a lot of the above... what happens when i do
> another
> > > > ftech
> > > > > > while
> > > > > > one is active? does it cancel and start again? shouldn't there
> > maybe
> > > > be a
> > > > > > way
> > > > > > of cancelling a pending async fetch of something too?
> > > > > >
> > > > > > children_count_get - so what does this have to do with
> > > > > > EMODEL_EVENT_CHILDREN_COUNT_GET ? - docs are thin on the ground
> > here
> > > > > >
> > > > >
> > > > > child_del , yes, it generates EMODEL_EVENT_CHILD_DEL, it is now
> > > > documented
> > > > > there as well.
> > > >
> > > > ok. good. :)
> > > >
> > > > > children_count_get is actually using
> > > EMODEL_EVENT_CHILDREN_COUNT_CHANGE.
> > > > > Added docs there describing this one too, basically it retrieves
> the
> > > > total
> > > > > number of children from given model. In Emodel_Eio example, for
> > example
> > > >
> > > > ok - not there in the .eo file yet... but put it in. :)
> > > >
> > > > > (lol), the last total number of children is returned immediately
> and
> > in
> > > > the
> > > > > background another count is performed, when it is finished it
> > > overwrites
> > > > > the last count and raise EMODEL_EVENT_CHILDREN_COUNT_CHANGE.
> > > >
> > > > ok. good - you should document this in emodel.eo as a possible
> behavior
> > > > and why
> > > > someone should listen to count changes. count get gets the currently
> > > known
> > > > count which may not be everything yet. you need a way of knowing when
> > > this
> > > > series of child count changes is finished coming in though - eg from
> an
> > > > initial
> > > > load you may get 20+ child count changes... but you need to know when
> > the
> > > > initial load is done - is this the loaded event? you need to document
> > > > this. :)
> > > >
> > > > > About children_(slice)_fetch, both belong to same hand, I mean, the
> > > fetch
> > > > > scenario you foreseen and I guess it is going to be modified so
> this
> > > kind
> > > > > of issue won't happen.
> > > > >
> > > > > I'll mail you as soon as I have news about those OK.
> > > >
> > > > ok - cool. what i'm lookign fro is docs to give the general behavior
> of
> > > an
> > > > emodel regardless of its backing implementation (eio or anything
> else).
> > > > this
> > > > model should be god enough to cover "all cases" on a core level - if
> i
> > > > write an
> > > > emodel handler, it should work correctly regardless of backing as
> long
> > > as i
> > > > have done all the things i should (eg i put a busy spinner up in my
> gui
> > > > UNTIL
> > > > my loaded callback comes in - until then i consider the model is
> still
> > > > listing/evaluating and thus is busy).
> > > >
> > > > > > btw - gustavo's point of emodel eio belonging to eio is right..
> :)
> > > for
> > > > now
> > > > > > this
> > > > > > is not important as i am taking the eio model as an example, so
> > it'll
> > > > > > eventually move to eio where it belongs.
> > > > > >
> > > > >
> > > > > Agreed, I think it makes more sense too.
> > > > >
> > > > >
> > > > > >
> > > > > > so still need a lot more explanations as to the intent of the
> api.
> > :)
> > > > > >
> > > > >
> > > > > Yes, I added some there, can you please pull again?
> > > >
> > > > i did... and reply is here. :) there are indeed more docs. good!
> still
> > > > missing
> > > > a lot on the events themselves and how things are meant to work. i'm
> > > poking
> > > > around to find holes in the design/idea now so we dont have to do it
> > > > later. :)
> > > >
> > > > > Oh, sorry for taking so long to reply your e-mail, I was busy with
> > some
> > > > > coding that's why I took longer to answer :(
> > > >
> > > > no problems. i understand. i'm busy too. not just coding. :) that's
> > fair
> > > > enough.
> > > >
> > > > > []s
> > > > >
> > > > >
> > > > > >
> > > > > > > < sending again, always forget the reply-all :( >
> > > > > > >
> > > > > > > Hi raster!
> > > > > > >
> > > > > > > I changed the code and adjusted the function names to match a
> > more
> > > > > > correct
> > > > > > > convention as you suggested.
> > > > > > > Now about the constructor, we'll implement as you suggested as
> > well
> > > > > > because
> > > > > > > it makes sense too.
> > > > > > >
> > > > > > > Can you please update from our repo because I already pushed
> some
> > > > changes
> > > > > > > to there, including more documentation too.
> > > > > > >
> > > > > > > I know you are usually very busy so I paste the links here
> again,
> > > > just in
> > > > > > > case:
> > > > > > >
> > > > > > > efl: https://github.com/expertisesolutions/efl.git branch
> > > > > > emodel-eolian
> > > > > > > elementary:
> https://github.com/expertisesolutions/elementary.git
> > > > branch
> > > > > > > eo_mvc
> > > > > > >
> > > > > > > I'll appreciate if you can take a second look :)
> > > > > > >
> > > > > > > []s!
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 19, 2014 at 11:39 PM, Carsten Haitzler <
> > > > ras...@rasterman.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Thu, 19 Jun 2014 12:20:21 -0300 Carlos Carvalho
> > > > > > > > <ccarva...@expertisesolutions.com.br> said:
> > > > > > > >
> > > > > > > > > Hi raster :)
> > > > > > > > >
> > > > > > > > > please see below.
> > > > > > > > >
> > > > > > > > > On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler <
> > > > > > ras...@rasterman.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Mon, 16 Jun 2014 12:00:20 -0300 Felipe Magno de
> Almeida
> > > > > > > > > > <felipe.m.alme...@gmail.com> said:
> > > > > > > > > >
> > > > > > > > > > Hey guys. just reading now. looking at emodel.eo a lot of
> > > these
> > > > > > methods
> > > > > > > > > > have no
> > > > > > > > > > return.... just looking at properties for starters. also
> > > > > > > > > > child_select_get().
> > > > > > > > > >
> > > > > > > > > > this needs a lot more documentation as it's really
> > mysterious
> > > > as to
> > > > > > > > what
> > > > > > > > > > this
> > > > > > > > > > does and how it's meant to work. reading the code for the
> > eio
> > > > > > emodel i
> > > > > > > > can
> > > > > > > > > > see
> > > > > > > > > > that child_select_get() will call the
> > > > EMODEL_EVENT_CHILD_SELECTED
> > > > > > on
> > > > > > > > the
> > > > > > > > > > object
> > > > > > > > > > inside of this as long as a path is selected. what does
> > > > > > load/unload do?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > There are child_select_get and child_select_set.
> > > > > > > >
> > > > > > > > yes - but the get returns nothing. this seems really bizarre.
> > it
> > > > looks
> > > > > > > > like a
> > > > > > > > property by name, but doesn't work like one at all.
> > > > > > > >
> > > > > > > > > The former is used when the application needs to know which
> > > (and
> > > > if)
> > > > > > > > child
> > > > > > > > > is currently selected by the user, so application adds
> itself
> > > as
> > > > > > listener
> > > > > > > > > and call select_get and its callback will be invoked.
> > > > > > > >
> > > > > > > > and that's what is bizarre about it. normally you'd have
> > > > > > > >
> > > > > > > > blah_set(10);
> > > > > > > > int val = blah_get();
> > > > > > > >
> > > > > > > > this doesn't work like that so i star at it in bewilderment.
> it
> > > > doesn't
> > > > > > > > follow
> > > > > > > > a pattern being used in most places in efl where a _set/_get
> > pair
> > > > are
> > > > > > > > basically
> > > > > > > > a property (some read-only, some write-only, some read/write
> so
> > > the
> > > > > > get/get
> > > > > > > > existance define that). but this looks like a property, but
> > then
> > > > > > doesn't
> > > > > > > > work
> > > > > > > > like one. might i suggest a renaming? like child_select() and
> > > then
> > > > > > > > child_select_eval() or something... up for debate.
> > > > > > > >
> > > > > > > > and properties_get, property_get and property_set also have
> an
> > > > issue in
> > > > > > > > that
> > > > > > > > they even use property there in the name but dont work like
> eo
> > > > > > properties
> > > > > > > > (above). again - prop_list(), prop_fetch(), prop_set() (as
> the
> > > set
> > > > does
> > > > > > > > look
> > > > > > > > like a property)... maybe
> > > > > > > >
> > > > > > > > also child_fetch() child_slice_fetch()...
> > > > > > > >
> > > > > > > > it sounds like we need a new convention for this kind of "we
> > > > return but
> > > > > > > > not by
> > > > > > > > any obvious return value or return pointer - we return by
> > > > callbacks"
> > > > > > (and
> > > > > > > > maybe
> > > > > > > > callback is given directly or is an event callback).
> > > > > > > >
> > > > > > > > but just saying... as i read it... it looks .. odd.
> > > > > > > >
> > > > > > > > > The later happens when the user selects a child and every
> > time
> > > it
> > > > > > happens
> > > > > > > > > an event is dispatched informing the listeners which child
> is
> > > > > > selected so
> > > > > > > > > the application can do whatever it wants with that
> > information
> > > > and
> > > > > > can
> > > > > > > > > navigate through the directory tree, in the case of eio,
> > > > > > delete/create
> > > > > > > > > files, etc..
> > > > > > > >
> > > > > > > > sure - just the naming makes it seem odd vs existing
> > conventions.
> > > > :)
> > > > > > > >
> > > > > > > > > load/unload are actually unused because in the beginning of
> > > time
> > > > we
> > > > > > tough
> > > > > > > > > to make them to perhaps behave like constructors and so
> but I
> > > > don't
> > > > > > know
> > > > > > > > if
> > > > > > > > > it makes sense and perhaps they may be removed.. ?
> > > > > > > >
> > > > > > > > i think load/unload are good. they can free memory of child
> > info
> > > on
> > > > > > unload
> > > > > > > > and
> > > > > > > > load can begin a background dir scan and info collection. we
> > > don't
> > > > load
> > > > > > > > unless
> > > > > > > > we want the data. it's a way of having a dormant "empty"
> object
> > > > with
> > > > > > > > minimal
> > > > > > > > footprint until we need the actual data.
> > > > > > > >
> > > > > > > > > > it REALLY needs docs there so people know what the
> purpose
> > is
> > > > so
> > > > > > we can
> > > > > > > > > > review
> > > > > > > > > > and understand this better. :)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Surely, I totally agree with you and this is on the way and
> > as
> > > > soon
> > > > > > as we
> > > > > > > > > have done I'll let you guys know.
> > > > > > > >
> > > > > > > > cool. i'm waiting on it. :)
> > > > > > > >
> > > > > > > > > > for some symmetry - there is a child_del in the core, but
> > > > nothing
> > > > > > for
> > > > > > > > > > adding
> > > > > > > > > > children. seems a bit... asymmetric to me? also the eio
> > model
> > > > > > overrides
> > > > > > > > > > child_del AND has a child_del of its own. why?. they have
> > > > different
> > > > > > > > input
> > > > > > > > > > params too. for the eio model, can i recommend we have a
> > path
> > > > > > property
> > > > > > > > you
> > > > > > > > > > can
> > > > > > > > > > set AND get? so you can create an empty eio model and
> then
> > > > point
> > > > > > it to
> > > > > > > > a
> > > > > > > > > > path?
> > > > > > > > > > cleaner. a custom constructor is fine but we eventually
> > want
> > > > to get
> > > > > > > > rid of
> > > > > > > > > > them
> > > > > > > > > > or as many as we can.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > EIO indeed overrides child_del and implements its own, it
> is
> > a
> > > > kind
> > > > > > of
> > > > > > > >
> > > > > > > > yeah. it does BOTH. that is the confusing bit. :)
> > > > > > > >
> > > > > > > > > unwanted indirection since emodel_eio deal with files and
> > > > > > directories and
> > > > > > > > > Emodel's child_del is kind of generic. In emodel_eio you'll
> > see
> > > > that
> > > > > > > > > child_del is redirected to eio_child_del , the later then
> > works
> > > > > > directly
> > > > > > > > > with EIO performing eio_dir_unlink (which works for simple
> > > files
> > > > > > too).
> > > > > > > > This
> > > > > > > > > indirection may be unnecessary and can be removed if
> > code/logic
> > > > > > clarity
> > > > > > > > is
> > > > > > > > > improved.
> > > > > > > >
> > > > > > > > i think it is unnecessry. :) it's kind of confusing. "so..
> > which
> > > > del
> > > > > > do i
> > > > > > > > use?
> > > > > > > > the parent class child del or the eio child del? what is the
> > > > > > difference?"
> > > > > > > > :)
> > > > > > > >
> > > > > > > > > Making something like child_add perhaps has a drawback
> > because,
> > > > as
> > > > > > far I
> > > > > > > > > know, the application must know in advance what kind of
> model
> > > it
> > > > is
> > > > > > > > > constructing. In the case of emodel_eio it is filesystem,
> but
> > > > could
> > > > > > be
> > > > > > > > > Database stuff or some other thing.
> > > > > > > >
> > > > > > > > sure. but it just seems odd to be asymmetrical. there are
> many
> > > > cases
> > > > > > where
> > > > > > > > you
> > > > > > > > can add a child generically too. that's actually how eo works
> > > > itself.
> > > > > > :)
> > > > > > > >
> > > > > > > > > Making a generic constructor I don't know if would make
> much
> > > > sense
> > > > > > > > because
> > > > > > > > > of different implementations for emodel. But we're are very
> > > open
> > > > to
> > > > > > > > change
> > > > > > > > > this if you think it is a good idea os have something in
> > mind I
> > > > don't
> > > > > > > > > though about.
> > > > > > > >
> > > > > > > > one thing you can do is define that children are not "real"
> > until
> > > > you
> > > > > > have
> > > > > > > > set
> > > > > > > > up enough information for them to be real. eg is it a file
> or a
> > > > dir or
> > > > > > a
> > > > > > > > symlink or device inode or hadr link, and what is its name,
> and
> > > > maybe
> > > > > > what
> > > > > > > > does it point to?. without these its incomplete. i would
> expect
> > > > these
> > > > > > to
> > > > > > > > be set
> > > > > > > > immediately after creation so it will be pending only
> > > temporarily.
> > > > also
> > > > > > > > this
> > > > > > > > nicely makes renaming easy. just set a new name property. no
> > > > special
> > > > > > rename
> > > > > > > > call. :) same as setting the initial name up. changing what a
> > > > symlink
> > > > > > > > points to?
> > > > > > > > easy - just set the link property to something else.
> > > > > > > >
> > > > > > > > > > so right now... docs docs - especially at the core like
> > > > emodel. :)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Yeah! It is on the way. Thanks for your feedback, we'll
> > > > appreciate.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > We are implementing a model interface and a few views
> in
> > > > > > elementary
> > > > > > > > > > > and would like feedback.
> > > > > > > > > > > The code is at
> > > > > > > > > >
> > https://github.com/expertisesolutions/efl/tree/emodel-eolian
> > > > > > > > > > > and
> > > > https://github.com/expertisesolutions/elementary/tree/eo_mvc
> > > > > > > > > > >
> > > > > > > > > > > We've designed a model interface which is tree-like
> (DAG)
> > > > where
> > > > > > each
> > > > > > > > > > > child is an Eo*, which can itself be a Emodel or not)
> and
> > > > each
> > > > > > node
> > > > > > > > > > > has properties. And the model is completely
> asynchronous.
> > > > > > > > > > >
> > > > > > > > > > > There is a list view and a form view in elementary and
> a
> > > EIO
> > > > > > emodel
> > > > > > > > in
> > > > > > > > > > > EFL which are used in examples in elementary and for
> > > testing
> > > > in
> > > > > > EFL.
> > > > > > > > > > >
> > > > > > > > > > > We developed the model interface like this because we
> > felt
> > > > this
> > > > > > > > > > > allowed more flexibility with an application being
> > entirely
> > > > > > defined
> > > > > > > > in
> > > > > > > > > > > a model class with each child for each frame (using a
> > form
> > > > view
> > > > > > or a
> > > > > > > > > > > specific implemented view for example).
> > > > > > > > > > >
> > > > > > > > > > > Any feedback is appreciated,
> > > > > > > > > > > --
> > > > > > > > > > > Felipe Magno de Almeida
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > > > > > > > > HPCC Systems Open Source Big Data Platform from
> > LexisNexis
> > > > Risk
> > > > > > > > Solutions
> > > > > > > > > > > Find What Matters Most in Your Big Data with HPCC
> Systems
> > > > > > > > > > > Open Source. Fast. Scalable. Simple. Ideal for Dirty
> > Data.
> > > > > > > > > > > Leverages Graph Analysis for Fast Processing & Easy
> Data
> > > > > > Exploration
> > > > > > > > > > > http://p.sf.net/sfu/hpccsystems
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > --
> > > > > > > > > Expertise Solutions
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > > > > > > HPCC Systems Open Source Big Data Platform from LexisNexis
> > Risk
> > > > > > Solutions
> > > > > > > > > Find What Matters Most in Your Big Data with HPCC Systems
> > > > > > > > > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> > > > > > > > > Leverages Graph Analysis for Fast Processing & Easy Data
> > > > Exploration
> > > > > > > > > http://p.sf.net/sfu/hpccsystems
> > > > > > > > > _______________________________________________
> > > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > --
> > > > > > > Expertise Solutions
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > --------------
> > > > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > --
> > > > > Expertise Solutions
> > > >
> > > >
> > > > --
> > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > --------------
> > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------------
> > > > Open source business process management suite built on Java and
> Eclipse
> > > > Turn processes into business applications with Bonita BPM Community
> > > Edition
> > > > Quickly connect people, data, and systems into organized workflows
> > > > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > > > http://p.sf.net/sfu/Bonitasoft
> > > > _______________________________________________
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Want fast and easy access to all the code in your enterprise? Index and
> > > search up to 200,000 lines of code with a free copy of Black Duck
> > > Code Sight - the same software that powers the world's largest code
> > > search on Ohloh, the Black Duck Open Hub! Try it now.
> > > http://p.sf.net/sfu/bds
> > > _______________________________________________
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> > D5
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
>
>
> --
> Jean-Philippe André
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
--
Expertise Solutions
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
