[E-devel] Enlightenment DR 0.22.2 Release

2018-03-14 Thread Simon Lees 
CHANGES
https://git.enlightenment.org/core/enlightenment.git/tree/NEWS?h=v0.22.2


4d581ef85246f0cba003427bb9b3758e3de137babea1cdd2affd70a2cbe1632c
http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.22.2.tar.xz

See the full announcement for more details:
https://www.enlightenment.org/news/e0.22.2_release

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] A step to improving communication - Meetings

2018-03-14 Thread The Rasterman 
On Wed, 14 Mar 2018 23:00:44 +1030 Simon Lees  said:

> On Friday, 9 March 2018 21:20:33 ACDT, Carsten Haitzler wrote:
> > On Fri, 9 Mar 2018 10:08:57 +0100 Jonathan Aquilina
> > 
> > said:
> >
> >> Hi Stefan you forgot there is slack and can speak in the
> >> channel on Irc that
> >> way if we have the bot there as well they can join us through slack
> >
> > I heard today slack intends on dropping IRC integration. Also it has
> proven
> > problematic in its integration for addressing people due to the bot-style
> > integration.
> >
> 
> The bot style intergration is all our fault as we are taking an existing
> irc channel and trying to bridge it to slack. If you go the otherway and
> just point your IRC client to the slack channel the intergration is
> really good, i'm using it in a bunch of other places and it has worked
> really well, we just do it wrong. Either way there removing the part
> that worked well not the bot way that we use.

matrix seems to integrate perfectly to an existing irc network and
channels... :) so... there is at least one far better solution there:

matrix.

i took chrisophe's advice and checked it out. it's not too shabby. it's my
current solution for "when away from pc" for irc. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Writing better titles for your tickets

2018-03-14 Thread Simon Lees 
As of the last couple of enlightenment releases we pull the titles of
bug tickets out of phab and include them in the release notes. It would
be nice if these titles were somewhat meaningfull.

Anyway for everyones entertainment here are my favorite 3 enlightenment
bugs fixed for e22.2

| [[ https://phab.enlightenment.org/T6617|T6617 ]] |evas is broken |
| [[ https://phab.enlightenment.org/T6644|T6644 ]] |bugs efl and
enlightenment gi |
| [[ https://phab.enlightenment.org/T6721|T6721 ]] |bryce can scroll now? |

Cheers

  ---

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] futures again... :(

2018-03-14 Thread Gustavo Sverzut Barbieri 
On Wed, Mar 14, 2018 at 2:50 AM, Carsten Haitzler  wrote:
> On Tue, 13 Mar 2018 10:35:15 -0300 Gustavo Sverzut Barbieri
>  said:
>
>> On Tue, Mar 13, 2018 at 1:17 AM, Carsten Haitzler 
>> wrote: [...]
>> >>
>> >> > > >> for instance, with events rarely we carry payload info, usually one
>> >> > > >> queries from the object... like text changed on widgets.
>> >> > > >>
>> >> > > >> however for promises, with the chaining idea, rarely you should be
>> >> > > >> getting the owner object... in the rare cases you need it, use "the
>> >> > > >> closure" (void *data), which BTW is specific for each future in the
>> >> > > >> chain, then you can chain multiple and "pass thru" the value if you
>> >> > > >> need multiple objects (ie: say you need to get a value and show it
>> >> > > >> to 2 label objects, you can connect 2 cb in a chain, each with a
>> >> > > >> label object.
>> >> > > >
>> >> > > > actually it's going to be incredibly common. example:
>> >> > > >
>> >> > > > file_set on an image object... what do you think people want to do?
>> >> > > > they want to then SHOW the object or emit a signal to it or
>> >> > > > something. they want to initiate some response.
>> >> > > >
>> >> > > > for exe's and threads the object will not be magically deleted if 
>> >> > > > the
>> >> > > > exe exits or thread exits. the object has to exist firstly to 
>> >> > > > collect
>> >> > > > the results (i/o, exit code results etc.) - it has fd's it has to
>> >> > > > listen on etc. etc. ...
>> >> > >
>> >> > > not sure if you checked the efl_future (EFL, not EINA) version I told
>> >> > > you... the object goes there for you... no need for you, the promise
>> >> > > creator, to do that...
>> >> > >
>> >> > > the promise create should only care about resolving a value or
>> >> > > rejecting it.
>> >> >
>> >> > in this case it'd be resolving the result of an action of an object -
>> >> > same as file_set. the object is the key thing here, not the value.
>> >>
>> >> here, since the loaded data is tied to the object... sure... but the
>> >> promise should return none, like "job" or "timeout"... you get a
>> >> notification the action completed, not the object that originated it
>> >> (ie: job is the mainloop).
>> >
>> > i agree with you here as there is no action required on the loop object 
>> > once
>> > the promise is complete. because threads and exe's require action (deletion
>> > of the object otherwise you'll leak) i think it's key to pass the object
>> > here, not the exit code. :)
>> >
>> > sure. you can pass it with data... but then the user of the api no longer
>> > can pass anything else of their own as data as they used up that one value
>> > for the object which is going to need addressing as above. the exit code is
>> > going to be directly accessible from the passed object so no need to jump
>> > through hoops to get it... :)
>> >
>> > at least in THIS case i think passing exit code is worse than passing
>> > object.
>> >
>> > to boot your "i wand void pointers for threads" argument now has void ptr's
>> > for in and out values for threads... and it's likely you don't want the
>> > exit code but this value. i can't pass everything... so i have to choose
>> > something to p[ass that is the most useful, and if i pass the object, you
>> > can get the out pointer that is the "return data" from the thread. thus i
>> > think this favours object being the value even more.
>>
>> you can pass void* as EINA_VALUE_TYPE_BLOB, the only thing is not much
>> can be done about it, just release (free).
>
> that's far less useful than the EO obj handle... :) this can't be done for the
> task class because it doesn't know about the thread superclass offering void
> ptrs.

okay... I'm not going to convince you, so I'll stop trying.


>> and my position still remains, even for threads... getting the actual
>> thread results.
>
> so when a future is bound to an object - which actually most of ours seem to
> be (file_set, if exe/thread get in it task class there too, jobs, timeouts),
> why hide the bound object? by forcing it to be manually passed by the void
> *data we use up the only user-supplied data into the result. it can't be used
> by the user for their own data.

because it's not relevant and shouldn't be exposed. It's how all other
implementations do it...

what I tried to say N times and gave up in the statement above is that
you shouldn't consider the source object, just the expected output
value.

later, if you change from an exe to something else, say use
eina_future_resolved(value) to do a mock/test... it "just works", you
test the remaining pipeline without really executing the action. Not
just for testing, but also to enable reuse the chain.


> exe's produce int exit codes only. threads produce an int exit code AND can
> deliver a void ptr as an output value as well (like ecore_thread). how do i
> know which the user will want/need? the best way is to

Re: [E-devel] A step to improving communication - Meetings

2018-03-14 Thread Simon Lees 
On Friday, 9 March 2018 21:20:33 ACDT, Carsten Haitzler wrote:
> On Fri, 9 Mar 2018 10:08:57 +0100 Jonathan Aquilina
> 
> said:
>
>> Hi Stefan you forgot there is slack and can speak in the
>> channel on Irc that
>> way if we have the bot there as well they can join us through slack
>
> I heard today slack intends on dropping IRC integration. Also it has
proven
> problematic in its integration for addressing people due to the bot-style
> integration.
>

The bot style intergration is all our fault as we are taking an existing
irc channel and trying to bridge it to slack. If you go the otherway and
just point your IRC client to the slack channel the intergration is
really good, i'm using it in a bunch of other places and it has worked
really well, we just do it wrong. Either way there removing the part
that worked well not the bot way that we use.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel