19 Apr
2018
19 Apr
'18
6:31 a.m.
Hi,
I am not quite sure what you mean by filling the pool by releasing objects. Can you
explain? Also, I let Alex describe the details :)
Doru
On Apr 18, 2018, at 9:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Doru,
Le 18/04/2018 à 06:45, Tudor Girba a écrit :
Yes, it does:
https://twitter.com/feenkcom/status/984744251920658432
Hi,
Sorry for the late reply. I missed this email.
BlInfiniteElement’s comment says:
"I'm an element which is supposed to contain huge amount of children and layout
only those of them that are visible inside my viewport.
I work with DataSources to fetch data from and can present data within different Infinite
Layouts.”
Ok so this is a generalisation of the fasttable approach.
I wanted to know if it could handle data sources where elements size is variable and
unknown unless you render the element. It is used in
both lists and in the text editor.
Obvious, isn't it. A text is a list of lines...
I am not sure which variable you refer to by
"currently processing a request”. Can you clarify?
Can't find it, but must have been triggered when looking at variables like
layoutRequestEaten. Yes, it seems like it.
Interesting: found the cache used in the BLInfiniteElement (BlRecycler?). Also found a
pool (BlInfinitePool) ? Couldn't find what it could be a pool of... Strange, you add
things in the pool when you release them (so you fill the pool by releasing objects?).
Looks like a LIFO stack to me. Regards,
Thierry
> Cheers,
> Doru
>> On Apr 9, 2018, at 3:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
>>
>> The only way one can review it is to reverse engineer the whole code
>> base then. How much did you say? 2 peoples, how many months?
>>
>> A few questions then, after a cursory glance:
>>
>> - In what way an infinite BlElement is infinite?
>> - Why does an infinite BlElement has what seems to be a sort of
>> "currently processing a request" instance variable?
>>
>> Regards,
>>
>> Thierry
>>
>> 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
>>> Hi,
>>>
>>> We are doing that. We rewrote the system multiple times precisely because of
these reasons. We could certainly do better, but I think that any meaningful conversation
must happen around code, and we’d be happy to learn where we did not exploit all
abstractions we could. Actually, I would be happy to even have a conversation about
issues, even if the solution is not given. It can start by simply being pointed to code
that does not sound right.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>
>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
>>>>>
>>>>>
>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel
<alex.syrel(a)gmail.com>om>:
>>>>>> Hi,
>>>>>>
>>>>>> For the record, View class, a root class of all visual elements
in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used
on more than 2 billion devices :)
>>>>>>
>>>>>> Remind me, please: what is the budget of Google for the ongoing
maintenance of Android?
>>>>>>
>>>>>> The core of Bloc is just 14k lines of code. It would be nice to
know how many lines of code should be considered too much, 5k, 7.43k or 10k.
>>>>>>
>>>>>> For a non-rendering core? 2k.
>>>>>
>>>>> I think that having a time/space efficient high quality well
documented code base is definitively a goal, they are probably not there yet.
>>>>>
>>>>> Being the smallest out there is probably not a goal, nor is that a
particularly interesting one, IMHO.
>>>>
>>>> Small means a real effort has been to:
>>>>
>>>> - not reimplement already available mechanisms,
>>>>
>>>> - build the most effective abstractions,
>>>>
>>>> - do not factor in unneeded customizations points,
>>>>
>>>> I value highly someone that try to reach thoses.
>>>>
>>>> Thierry
>>>>
>>>>>> Thierry
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Alex
>>>>>>
>>>>>> On 9 April 2018 at 11:12, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich
<serge.stinckwich(a)gmail.com>om>:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think it might be more interesting to start the review from
the usage of it, not from the internals.
>>>>>>
>>>>>> Well, from the usage of it, I've seen nothing that
doesn't fit into
>>>>>> the yagt. I've seen that field evolve and try clever things,
really
>>>>>> different things, and Bloc does not look like one of thoses.
>>>>>>
>>>>>>> Indeed, Bloc is primarily an engineering effort. But, there
are a couple of things that make it rather different from other solutions. For example:
>>>>>>> - Only one rendering tree in all cases. This works also for
graph visualizations that work with any element without imposing knowledge about edges in
the base system. We think this is quite important, and especially when combined with a
performant rendering, it can open new doors for UI design.
>>>>>>
>>>>>> Look, from the point of view of the man of the art, it
doesn't seems
>>>>>> like a breakthrough.
>>>>>>
>>>>>>
>>>>>> Do we need a breakthrought for UI ?
>>>>>> No !
>>>>>> We need something that works that's it, stable software with
good documentation and tests.
>>>>>> After that people can build the next-UI if they want, but this is
build on solid foundations.
>>>>>>
>>>>>> Agreed. And this is where it is critical.
>>>>>>
>>>>>> I used Morphic since Self 3.0, beginning of my PhD (1994, I
think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011,
I was horrified by what it has became: a monster of thousands over thousands of buggy
lines.
>>>>>>
>>>>>> And now I see a replacement, that, before going into production,
is already at 45k lines? And with a planned, huge dependency on the GUI lib of another
project?
>>>>>>
>>>>>> Do you imagine how it will be, 10 years down the line?
>>>>>>
>>>>>> Do you think it will be the stable foundation you're looking
for?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Compared to other smalltalk-based solutions, yes, it may be seen
as an
>>>>>> improvement.
>>>>>>
>>>>>> I think you underestimate how advanced that field has been / is,
and
>>>>>> how far behind the state of the art are industrial solutions.
>>>>>>
>>>>>> There is only one development in the Smalltalk space in GUI that
is
>>>>>> worthy of interest for me: the anti-aliasing of Juan Vuletich.
It
>>>>>> would have so much impact overall (remove all dependencies on
external
>>>>>> libs, remove the need to do font anti-aliasing, scrap thousands
of
>>>>>> lines of slow and ugly Smalltalk code, simplify the FreeType
>>>>>> infrastructure, remove MBs of external librairies, ensure
long-term
>>>>>> porting ease / code evolution).
>>>>>>
>>>>>> M
>>>>>> aybe this was a breakthrought, but how many users ?
>>>>>>
>>>>>> Very few users. Juan has not yet implemented it.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Thierry
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Serge Stinckwich
>>>>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>>>>> "Programs must be written for people to read, and only
incidentally for machines to execute."
>>>>>> http://www.doesnotunderstand.org/
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> --
> www.tudorgirba.com
> www.feenk.com
> "Things happen when they happen,
> not when you talk about them happening."
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Don't give to get. Just give."
19 Apr
19 Apr
6:38 a.m.
New subject: [ann] gt diagrammer
Le 19/04/2018 à 06:31, Tudor Girba a écrit :
I am not quite sure what you mean by filling the pool by releasing objects. Can you
explain? Also, I let Alex describe the details :)
Doru
Hi,
This shows just it can handle varying height. Easy.
But that doesn't answer the key question: does it need to know their
height (of all elements) or not ? That one is a bit harder.
Thierry
On Apr 18, 2018, at 9:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
Hi Doru,
Le 18/04/2018 à 06:45, Tudor Girba a écrit :
Yes, it does:
https://twitter.com/feenkcom/status/984744251920658432 Hi,
Sorry for the late reply. I missed this email.
BlInfiniteElement’s comment says:
"I'm an element which is supposed to contain huge amount of children and layout
only those of them that are visible inside my viewport.
I work with DataSources to fetch data from and can present data within different Infinite
Layouts.”
Ok so this is a generalisation of the fasttable approach.
I wanted to know if it could handle data sources where elements size is variable and
unknown unless you render the element. It is used in both lists and in the text editor.
Obvious, isn't it. A text is a list of lines...
I am not sure which variable you refer to by
"currently processing a request”. Can you clarify?
Can't find it, but must have been triggered when looking at variables like
layoutRequestEaten. Yes, it seems like it.
Interesting: found the cache used in the BLInfiniteElement (BlRecycler?). Also found a
pool (BlInfinitePool) ? Couldn't find what it could be a pool of... Strange, you add
things in the pool when you release them (so you fill the pool by releasing objects?).
Looks like a LIFO stack to me. Regards,
Thierry
> Cheers,
> Doru
>> On Apr 9, 2018, at 3:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
>>
>> The only way one can review it is to reverse engineer the whole code
>> base then. How much did you say? 2 peoples, how many months?
>>
>> A few questions then, after a cursory glance:
>>
>> - In what way an infinite BlElement is infinite?
>> - Why does an infinite BlElement has what seems to be a sort of
>> "currently processing a request" instance variable?
>>
>> Regards,
>>
>> Thierry
>>
>> 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
>>> Hi,
>>>
>>> We are doing that. We rewrote the system multiple times precisely because of
these reasons. We could certainly do better, but I think that any meaningful conversation
must happen around code, and we’d be happy to learn where we did not exploit all
abstractions we could. Actually, I would be happy to even have a conversation about
issues, even if the solution is not given. It can start by simply being pointed to code
that does not sound right.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>
>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>eu>:
>>>>>
>>>>>
>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel
<alex.syrel(a)gmail.com>om>:
>>>>>> Hi,
>>>>>>
>>>>>> For the record, View class, a root class of all visual elements
in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used
on more than 2 billion devices :)
>>>>>>
>>>>>> Remind me, please: what is the budget of Google for the ongoing
maintenance of Android?
>>>>>>
>>>>>> The core of Bloc is just 14k lines of code. It would be nice to
know how many lines of code should be considered too much, 5k, 7.43k or 10k.
>>>>>>
>>>>>> For a non-rendering core? 2k.
>>>>>
>>>>> I think that having a time/space efficient high quality well
documented code base is definitively a goal, they are probably not there yet.
>>>>>
>>>>> Being the smallest out there is probably not a goal, nor is that a
particularly interesting one, IMHO.
>>>>
>>>> Small means a real effort has been to:
>>>>
>>>> - not reimplement already available mechanisms,
>>>>
>>>> - build the most effective abstractions,
>>>>
>>>> - do not factor in unneeded customizations points,
>>>>
>>>> I value highly someone that try to reach thoses.
>>>>
>>>> Thierry
>>>>
>>>>>> Thierry
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Alex
>>>>>>
>>>>>> On 9 April 2018 at 11:12, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich
<serge.stinckwich(a)gmail.com>om>:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier
<thierry.goubier(a)gmail.com> wrote:
>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think it might be more interesting to start the review from
the usage of it, not from the internals.
>>>>>>
>>>>>> Well, from the usage of it, I've seen nothing that
doesn't fit into
>>>>>> the yagt. I've seen that field evolve and try clever things,
really
>>>>>> different things, and Bloc does not look like one of thoses.
>>>>>>
>>>>>>> Indeed, Bloc is primarily an engineering effort. But, there
are a couple of things that make it rather different from other solutions. For example:
>>>>>>> - Only one rendering tree in all cases. This works also for
graph visualizations that work with any element without imposing knowledge about edges in
the base system. We think this is quite important, and especially when combined with a
performant rendering, it can open new doors for UI design.
>>>>>>
>>>>>> Look, from the point of view of the man of the art, it
doesn't seems
>>>>>> like a breakthrough.
>>>>>>
>>>>>>
>>>>>> Do we need a breakthrought for UI ?
>>>>>> No !
>>>>>> We need something that works that's it, stable software with
good documentation and tests.
>>>>>> After that people can build the next-UI if they want, but this is
build on solid foundations.
>>>>>>
>>>>>> Agreed. And this is where it is critical.
>>>>>>
>>>>>> I used Morphic since Self 3.0, beginning of my PhD (1994, I
think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011,
I was horrified by what it has became: a monster of thousands over thousands of buggy
lines.
>>>>>>
>>>>>> And now I see a replacement, that, before going into production,
is already at 45k lines? And with a planned, huge dependency on the GUI lib of another
project?
>>>>>>
>>>>>> Do you imagine how it will be, 10 years down the line?
>>>>>>
>>>>>> Do you think it will be the stable foundation you're looking
for?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Compared to other smalltalk-based solutions, yes, it may be seen
as an
>>>>>> improvement.
>>>>>>
>>>>>> I think you underestimate how advanced that field has been / is,
and
>>>>>> how far behind the state of the art are industrial solutions.
>>>>>>
>>>>>> There is only one development in the Smalltalk space in GUI that
is
>>>>>> worthy of interest for me: the anti-aliasing of Juan Vuletich.
It
>>>>>> would have so much impact overall (remove all dependencies on
external
>>>>>> libs, remove the need to do font anti-aliasing, scrap thousands
of
>>>>>> lines of slow and ugly Smalltalk code, simplify the FreeType
>>>>>> infrastructure, remove MBs of external librairies, ensure
long-term
>>>>>> porting ease / code evolution).
>>>>>>
>>>>>> M
>>>>>> aybe this was a breakthrought, but how many users ?
>>>>>>
>>>>>> Very few users. Juan has not yet implemented it.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Thierry
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Serge Stinckwich
>>>>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>>>>> "Programs must be written for people to read, and only
incidentally for machines to execute."
>>>>>> http://www.doesnotunderstand.org/
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> --
> www.tudorgirba.com
> www.feenk.com
> "Things happen when they happen,
> not when you talk about them happening."
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Don't give to get. Just give."
2:31 p.m.
New subject: [ann] gt diagrammer
But that doesn't answer the key question: does it need to know their
height (of all elements) or not ? That one is a bit harder.
The list measures and lays out only visible elements, which means that at
any time it only knows the width / height of some small subset of items.
Cheers,
Alex
On 19 April 2018 at 06:38, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
> Le 19/04/2018 à 06:31, Tudor Girba a écrit :
>
>> Hi,
>>
>> On Apr 18, 2018, at 9:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com>
>>> wrote:
>>>
>>> Hi Doru,
>>>
>>> Le 18/04/2018 à 06:45, Tudor Girba a écrit :
>>>
>>>> Hi,
>>>> Sorry for the late reply. I missed this email.
>>>> BlInfiniteElement’s comment says:
>>>> "I'm an element which is supposed to contain huge amount of
children
>>>> and layout only those of them that are visible inside my viewport.
>>>> I work with DataSources to fetch data from and can present data within
>>>> different Infinite Layouts.”
>>>>
>>>
>>> Ok so this is a generalisation of the fasttable approach.
>>>
>>> I wanted to know if it could handle data sources where elements size is
>>> variable and unknown unless you render the element.
>>>
>>
>> Yes, it does:
>> https://twitter.com/feenkcom/status/984744251920658432
>>
>
> This shows just it can handle varying height. Easy.
But that doesn't answer the key question: does it need to know their
height (of all elements) or not ? That one is a bit harder.
>
> Thierry
>
>
> It is used in both lists and in the text editor.
>>>>
>>>
>>> Obvious, isn't it. A text is a list of lines...
>>>
>>> I am not sure which variable you refer to by "currently processing a
>>>> request”. Can you clarify?
>>>>
>>>
>>> Can't find it, but must have been triggered when looking at variables
>>> like layoutRequestEaten. Yes, it seems like it.
>>>
>>> Interesting: found the cache used in the BLInfiniteElement
>>> (BlRecycler?). Also found a pool (BlInfinitePool) ? Couldn't find what
it
>>> could be a pool of... Strange, you add things in the pool when you release
>>> them (so you fill the pool by releasing objects?). Looks like a LIFO stack
>>> to me.
>>>
>>
>> I am not quite sure what you mean by filling the pool by releasing
>> objects. Can you explain? Also, I let Alex describe the details :)
>>
>> Doru
>>
>>
>> Regards,
>>>
>>> Thierry
>>>
>>> Cheers,
>>>> Doru
>>>>
>>>>> On Apr 9, 2018, at 3:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>> The only way one can review it is to reverse engineer the whole code
>>>>> base then. How much did you say? 2 peoples, how many months?
>>>>>
>>>>> A few questions then, after a cursory glance:
>>>>>
>>>>> - In what way an infinite BlElement is infinite?
>>>>> - Why does an infinite BlElement has what seems to be a sort of
>>>>> "currently processing a request" instance variable?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Thierry
>>>>>
>>>>> 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We are doing that. We rewrote the system multiple times
precisely
>>>>>> because of these reasons. We could certainly do better, but I
think that
>>>>>> any meaningful conversation must happen around code, and we’d be
happy to
>>>>>> learn where we did not exploit all abstractions we could.
Actually, I would
>>>>>> be happy to even have a conversation about issues, even if the
solution is
>>>>>> not given. It can start by simply being pointed to code that does
not sound
>>>>>> right.
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>>
>>>>>> On Apr 9, 2018, at 1:04 PM, Thierry Goubier <
>>>>>>> thierry.goubier(a)gmail.com> wrote:
>>>>>>>
>>>>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe
<sven(a)stfx.eu>eu>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier
<thierry.goubier(a)gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel
<alex.syrel(a)gmail.com>om>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> For the record, View class, a root class of all
visual elements in
>>>>>>>>> Android 27 is 26'488 lines of code. It didn't
hover prevent it from being
>>>>>>>>> used on more than 2 billion devices :)
>>>>>>>>>
>>>>>>>>> Remind me, please: what is the budget of Google for
the ongoing
>>>>>>>>> maintenance of Android?
>>>>>>>>>
>>>>>>>>> The core of Bloc is just 14k lines of code. It would
be nice to
>>>>>>>>> know how many lines of code should be considered too
much, 5k, 7.43k or 10k.
>>>>>>>>>
>>>>>>>>> For a non-rendering core? 2k.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think that having a time/space efficient high quality
well
>>>>>>>> documented code base is definitively a goal, they are
probably not there
>>>>>>>> yet.
>>>>>>>>
>>>>>>>> Being the smallest out there is probably not a goal, nor
is that a
>>>>>>>> particularly interesting one, IMHO.
>>>>>>>>
>>>>>>>
>>>>>>> Small means a real effort has been to:
>>>>>>>
>>>>>>> - not reimplement already available mechanisms,
>>>>>>>
>>>>>>> - build the most effective abstractions,
>>>>>>>
>>>>>>> - do not factor in unneeded customizations points,
>>>>>>>
>>>>>>> I value highly someone that try to reach thoses.
>>>>>>>
>>>>>>> Thierry
>>>>>>>
>>>>>>> Thierry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>> On 9 April 2018 at 11:12, Thierry Goubier <
>>>>>>>>> thierry.goubier(a)gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <
>>>>>>>>> serge.stinckwich(a)gmail.com>gt;:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <
>>>>>>>>> thierry.goubier(a)gmail.com> wrote:
>>>>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com>om>:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I think it might be more interesting to start the
review from the
>>>>>>>>>> usage of it, not from the internals.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Well, from the usage of it, I've seen nothing
that doesn't fit into
>>>>>>>>> the yagt. I've seen that field evolve and try
clever things, really
>>>>>>>>> different things, and Bloc does not look like one of
thoses.
>>>>>>>>>
>>>>>>>>> Indeed, Bloc is primarily an engineering effort. But,
there are a
>>>>>>>>>> couple of things that make it rather different
from other solutions. For
>>>>>>>>>> example:
>>>>>>>>>> - Only one rendering tree in all cases. This
works also for graph
>>>>>>>>>> visualizations that work with any element without
imposing knowledge about
>>>>>>>>>> edges in the base system. We think this is quite
important, and especially
>>>>>>>>>> when combined with a performant rendering, it can
open new doors for UI
>>>>>>>>>> design.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Look, from the point of view of the man of the art,
it doesn't
>>>>>>>>> seems
>>>>>>>>> like a breakthrough.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do we need a breakthrought for UI ?
>>>>>>>>> No !
>>>>>>>>> We need something that works that's it, stable
software with good
>>>>>>>>> documentation and tests.
>>>>>>>>> After that people can build the next-UI if they want,
but this is
>>>>>>>>> build on solid foundations.
>>>>>>>>>
>>>>>>>>> Agreed. And this is where it is critical.
>>>>>>>>>
>>>>>>>>> I used Morphic since Self 3.0, beginning of my PhD
(1994, I
>>>>>>>>> think), followed it to the beginning of Squeak
(1998). When I came back to
>>>>>>>>> Pharo in 2011, I was horrified by what it has became:
a monster of
>>>>>>>>> thousands over thousands of buggy lines.
>>>>>>>>>
>>>>>>>>> And now I see a replacement, that, before going into
production,
>>>>>>>>> is already at 45k lines? And with a planned, huge
dependency on the GUI lib
>>>>>>>>> of another project?
>>>>>>>>>
>>>>>>>>> Do you imagine how it will be, 10 years down the
line?
>>>>>>>>>
>>>>>>>>> Do you think it will be the stable foundation
you're looking for?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Compared to other smalltalk-based solutions, yes, it
may be seen
>>>>>>>>> as an
>>>>>>>>> improvement.
>>>>>>>>>
>>>>>>>>> I think you underestimate how advanced that field has
been / is,
>>>>>>>>> and
>>>>>>>>> how far behind the state of the art are industrial
solutions.
>>>>>>>>>
>>>>>>>>> There is only one development in the Smalltalk space
in GUI that is
>>>>>>>>> worthy of interest for me: the anti-aliasing of Juan
Vuletich. It
>>>>>>>>> would have so much impact overall (remove all
dependencies on
>>>>>>>>> external
>>>>>>>>> libs, remove the need to do font anti-aliasing, scrap
thousands of
>>>>>>>>> lines of slow and ugly Smalltalk code, simplify the
FreeType
>>>>>>>>> infrastructure, remove MBs of external librairies,
ensure long-term
>>>>>>>>> porting ease / code evolution).
>>>>>>>>>
>>>>>>>>> M
>>>>>>>>> aybe this was a breakthrought, but how many users ?
>>>>>>>>>
>>>>>>>>> Very few users. Juan has not yet implemented it.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Thierry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> --
>>>>>>>>> Serge Stinckwich
>>>>>>>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>>>>>>>> "Programs must be written for people to read,
and only
>>>>>>>>> incidentally for machines to execute."
>>>>>>>>> http://www.doesnotunderstand.org/
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Moose-dev mailing list
>>>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Moose-dev mailing list
>>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>> www.feenk.com
>>>>>>
>>>>>> "We cannot reach the flow of things unless we let go."
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>
>>>> --
>>>> www.tudorgirba.com
>>>> www.feenk.com
>>>> "Things happen when they happen,
>>>> not when you talk about them happening."
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
20 Apr
20 Apr
9 a.m.
New subject: [ann] gt diagrammer
Le 19/04/2018 à 14:31, Aliaksei Syrel a écrit :
But that doesn't answer the key question: does
it need to know their
height (of all elements) or not ? That one is a bit harder.
The list measures and lays out only visible elements, which means that
at any time it only knows the width / height of some small subset of items.
Could you write an example where the height of each element is decided
at random each time it is rendered, for, say, about 10000 elements? I
have already one like that, and would be interested to see how you write
that (and trace it to see how it behaves).
Mind you, I think this would be the sort of examples you need to show,
because then you really have a quantitative difference.
Regards,
Thierry
Cheers,
Alex
On 19 April 2018 at 06:38, Thierry Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
Le 19/04/2018 à 06:31, Tudor Girba a écrit :
Hi,
On Apr 18, 2018, at 9:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
Hi Doru,
Le 18/04/2018 à 06:45, Tudor Girba a écrit :
Hi,
Sorry for the late reply. I missed this email.
BlInfiniteElement’s comment says:
"I'm an element which is supposed to contain huge amount
of children and layout only those of them that are
visible inside my viewport.
I work with DataSources to fetch data from and can
present data within different Infinite Layouts.”
Ok so this is a generalisation of the fasttable approach.
I wanted to know if it could handle data sources where
elements size is variable and unknown unless you render the
element.
Yes, it does:
https://twitter.com/feenkcom/status/984744251920658432
<https://twitter.com/feenkcom/status/984744251920658432>
This shows just it can handle varying height. Easy.
But that doesn't answer the key question: does it need to know their
height (of all elements) or not ? That one is a bit harder.
Thierry
It is used in both lists and in the text editor.
Obvious, isn't it. A text is a list of lines...
I am not sure which variable you refer to by "currently
processing a request”. Can you clarify?
Can't find it, but must have been triggered when looking at
variables like layoutRequestEaten. Yes, it seems like it.
Interesting: found the cache used in the BLInfiniteElement
(BlRecycler?). Also found a pool (BlInfinitePool) ? Couldn't
find what it could be a pool of... Strange, you add things
in the pool when you release them (so you fill the pool by
releasing objects?). Looks like a LIFO stack to me.
I am not quite sure what you mean by filling the pool by
releasing objects. Can you explain? Also, I let Alex describe
the details :)
Doru
Regards,
Thierry
Cheers,
Doru
On Apr 9, 2018, at 3:54 PM, Thierry Goubier
<thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
The only way one can review it is to reverse
engineer the whole code
base then. How much did you say? 2 peoples, how many
months?
A few questions then, after a cursory glance:
- In what way an infinite BlElement is infinite?
- Why does an infinite BlElement has what seems to
be a sort of
"currently processing a request" instance variable?
Regards,
Thierry
2018-04-09 14:08 GMT+02:00 Tudor Girba
<tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>:
Hi,
We are doing that. We rewrote the system
multiple times precisely because of these
reasons. We could certainly do better, but I
think that any meaningful conversation must
happen around code, and we’d be happy to learn
where we did not exploit all abstractions we
could. Actually, I would be happy to even have a
conversation about issues, even if the solution
is not given. It can start by simply being
pointed to code that does not sound right.
Cheers,
Doru
On Apr 9, 2018, at 1:04 PM, Thierry Goubier
<thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>> wrote:
2018-04-09 12:00 GMT+02:00 Sven Van
Caekenberghe <sven(a)stfx.eu
<mailto:sven@stfx.eu>>:
On 9 Apr 2018, at 11:36, Thierry
Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>>
wrote:
2018-04-09 11:23 GMT+02:00 Aliaksei
Syrel <alex.syrel(a)gmail.com
<mailto:alex.syrel@gmail.com>>:
Hi,
For the record, View class, a root
class of all visual elements in
Android 27 is 26'488 lines of code.
It didn't hover prevent it from
being used on more than 2 billion
devices :)
Remind me, please: what is the
budget of Google for the ongoing
maintenance of Android?
The core of Bloc is just 14k lines
of code. It would be nice to know
how many lines of code should be
considered too much, 5k, 7.43k or 10k.
For a non-rendering core? 2k.
I think that having a time/space
efficient high quality well documented
code base is definitively a goal, they
are probably not there yet.
Being the smallest out there is probably
not a goal, nor is that a particularly
interesting one, IMHO.
Small means a real effort has been to:
- not reimplement already available mechanisms,
- build the most effective abstractions,
- do not factor in unneeded customizations
points,
I value highly someone that try to reach thoses.
Thierry
Thierry
Cheers,
Alex
On 9 April 2018 at 11:12, Thierry
Goubier <thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>>
wrote:
2018-04-09 11:02 GMT+02:00 Serge
Stinckwich
<serge.stinckwich(a)gmail.com
<mailto:serge.stinckwich@gmail.com>>:
On Mon, Apr 9, 2018 at 9:54 AM,
Thierry Goubier
<thierry.goubier(a)gmail.com
<mailto:thierry.goubier@gmail.com>>
wrote:
2018-04-09 9:14 GMT+02:00 Tudor
Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>>:
Hi,
I think it might be more
interesting to start the review
from the usage of it, not from
the internals.
Well, from the usage of it, I've
seen nothing that doesn't fit into
the yagt. I've seen that field
evolve and try clever things, really
different things, and Bloc does not
look like one of thoses.
Indeed, Bloc is primarily an
engineering effort. But, there
are a couple of things that make
it rather different from other
solutions. For example:
- Only one rendering tree in all
cases. This works also for graph
visualizations that work with
any element without imposing
knowledge about edges in the
base system. We think this is
quite important, and especially
when combined with a performant
rendering, it can open new doors
for UI design.
Look, from the point of view of the
man of the art, it doesn't seems
like a breakthrough.
Do we need a breakthrought for UI ?
No !
We need something that works that's
it, stable software with good
documentation and tests.
After that people can build the
next-UI if they want, but this is
build on solid foundations.
Agreed. And this is where it is
critical.
I used Morphic since Self 3.0,
beginning of my PhD (1994, I think),
followed it to the beginning of
Squeak (1998). When I came back to
Pharo in 2011, I was horrified by
what it has became: a monster of
thousands over thousands of buggy lines.
And now I see a replacement, that,
before going into production, is
already at 45k lines? And with a
planned, huge dependency on the GUI
lib of another project?
Do you imagine how it will be, 10
years down the line?
Do you think it will be the stable
foundation you're looking for?
Compared to other smalltalk-based
solutions, yes, it may be seen as an
improvement.
I think you underestimate how
advanced that field has been / is, and
how far behind the state of the art
are industrial solutions.
There is only one development in the
Smalltalk space in GUI that is
worthy of interest for me: the
anti-aliasing of Juan Vuletich. It
would have so much impact overall
(remove all dependencies on external
libs, remove the need to do font
anti-aliasing, scrap thousands of
lines of slow and ugly Smalltalk
code, simplify the FreeType
infrastructure, remove MBs of
external librairies, ensure long-term
porting ease / code evolution).
M
aybe this was a breakthrought, but
how many users ?
Very few users. Juan has not yet
implemented it.
Regards,
Thierry
Regards,
--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people
to read, and only incidentally for
machines to execute."
http://www.doesnotunderstand.org/
<http://www.doesnotunderstand.org/>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>
"We cannot reach the flow of things unless we
let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>
"Things happen when they happen,
not when you talk about them happening."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
www.tudorgirba.com <http://www.tudorgirba.com>
www.feenk.com <http://www.feenk.com>
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2191
days inactive
2192
days old
3 comments
3 participants
participants (3)
-
Aliaksei Syrel -
Thierry Goubier -
Tudor Girba