[ann] gt diagrammer
Locked
12
12
 
|
2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>:
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?
Very few users. Juan has not yet implemented it. Regards, Thierry
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 :) 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. Cheers, Alex On 9 April 2018 at 11:12, Thierry Goubier <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>:
Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
For a non-rendering core? 2k. Thierry
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: [ann] gt diagrammer
|
|
> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: > > > > 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: > 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. > Thierry > > > Cheers, > Alex > > On 9 April 2018 at 11:12, Thierry Goubier <[hidden email]> wrote: > > > 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: > > > On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: > 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: > > 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> > >> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >> >> >> >> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >> 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 <[hidden email]> wrote: >> >> >> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >> >> >> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >> > 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 >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
Hi,
Thanks for your thoughts. Yes, the main feature of Bloc is that it works and that it can enable us to create interfaces for Pharo that are from this millennium. We do look well outside of the Smalltalk world, but it can happen that we might have overlooked something. I’d be happy to get pointed to those places. For example, I would be very interested in systems that have editors that can both work with 100Mb and that can now mix text with graphics in any way we want, while typing, and that enable applications like Connector. Bloc is not an increment over Morphic, and we would have not reached it by incrementing over Morphic. We know because we tried. About the size issue: Indeed, we are sensitive to this as well. However, this code was actually developed by about 2 people at any point in time. And it was rewritten multiple times. So, the argument that it falls under its own weight is not quite correct given that it did not stop us from producing significant things with it. The size is offset by the fact that the system is debuggable. It should also be noted that the basic framework provides a lot already. We know this because the editor is 3k lines of code and Mondrian is 1K (two applications with radically different needs). The dependency on Moz2D is not mandatory. It is offered as an option for those that want to produce industrial solutions. The current core has parts that do not necessarily have to be there (for example, support for overlays or scrolling). So, the minimal core can be made below 10k without much work. Cheers, Doru > On Apr 9, 2018, at 11:36 AM, Thierry Goubier <[hidden email]> wrote: > > > > 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: > 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. > > Thierry > > > Cheers, > Alex > > On 9 April 2018 at 11:12, Thierry Goubier <[hidden email]> wrote: > > > 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: > > > On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: > 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: > > 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by Thierry Goubier
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 <[hidden email]> wrote: > > 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: >> >> >>> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >>> >>> >>> >>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>> 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 <[hidden email]> wrote: >>> >>> >>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >>> >>> >>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >>>> 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 >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email]>: > 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 <[hidden email]> wrote: >> >> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: >>> >>> >>>> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >>>> >>>> >>>> >>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>>> 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 <[hidden email]> wrote: >>>> >>>> >>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >>>> >>>> >>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >>>>> 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 >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
Administrator
|
In reply to this post by Tudor Girba-2
Tudor Girba-2 wrote
> We could certainly do better… I would be happy to even have a conversation > about issues… Thank you guys for this thread! It is very helpful to understand how/why we got to the current situation from Morphic to Bloc :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev
Cheers,
Sean |
|
|
In reply to this post by Thierry Goubier
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.” It is used in both lists and in the text editor. I am not sure which variable you refer to by "currently processing a request”. Can you clarify? Cheers, Doru > On Apr 9, 2018, at 3:54 PM, Thierry Goubier <[hidden email]> 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 <[hidden email]>: >> 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 <[hidden email]> wrote: >>> >>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: >>>> >>>> >>>>> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >>>>> >>>>> >>>>> >>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>>>> 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 <[hidden email]> wrote: >>>>> >>>>> >>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >>>>> >>>>> >>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >>>>>> 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 >>>>> [hidden email] >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> 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 >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
Hi,
> On Apr 18, 2018, at 9:54 PM, Thierry Goubier <[hidden email]> 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 >> 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 <[hidden email]> 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 <[hidden email]>: >>>> 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 <[hidden email]> wrote: >>>>> >>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: >>>>>> >>>>>> >>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>>>>>> 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 <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >>>>>>>> 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 >>>>>>> [hidden email] >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> 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 >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> 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 >> [hidden email] >> 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
Le 19/04/2018 à 06:31, Tudor Girba a écrit :
> Hi, > >> On Apr 18, 2018, at 9:54 PM, Thierry Goubier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>>>> 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 <[hidden email]> wrote: >>>>>> >>>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <[hidden email]>: >>>>>>> >>>>>>> >>>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier <[hidden email]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>>>>>>> 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 <[hidden email]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <[hidden email]>: >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <[hidden email]> wrote: >>>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <[hidden email]>: >>>>>>>>> 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 >>>>>>>> [hidden email] >>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> 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 >>>>> [hidden email] >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> 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 >>> [hidden email] >>> 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: Le 19/04/2018 à 06:31, Tudor Girba a écrit : _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email] > <mailto:[hidden email]>> wrote: > > Le 19/04/2018 à 06:31, Tudor Girba a écrit : > > Hi, > > On Apr 18, 2018, at 9:54 PM, Thierry Goubier > <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] <mailto:[hidden email]>>: > > 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 > <[hidden email] > <mailto:[hidden email]>> wrote: > > 2018-04-09 12:00 GMT+02:00 Sven Van > Caekenberghe <[hidden email] > <mailto:[hidden email]>>: > > > > On 9 Apr 2018, at 11:36, Thierry > Goubier <[hidden email] > <mailto:[hidden email]>> > wrote: > > > > 2018-04-09 11:23 GMT+02:00 Aliaksei > Syrel <[hidden email] > <mailto:[hidden email]>>: > 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 <[hidden email] > <mailto:[hidden email]>> > wrote: > > > 2018-04-09 11:02 GMT+02:00 Serge > Stinckwich > <[hidden email] > <mailto:[hidden email]>>: > > > On Mon, Apr 9, 2018 at 9:54 AM, > Thierry Goubier > <[hidden email] > <mailto:[hidden email]>> > wrote: > 2018-04-09 9:14 GMT+02:00 Tudor > Girba <[hidden email] > <mailto:[hidden email]>>: > > 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 > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > 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 > [hidden email] > <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > <mailto:[hidden email]> > 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 > [hidden email] > <mailto:[hidden email]> > 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 > [hidden email] <mailto:[hidden email]> > https://www.list.inf.unibe.ch/listinfo/moose-dev > <https://www.list.inf.unibe.ch/listinfo/moose-dev> > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |