[Moose-dev] Re: [ann] gt diagrammer

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 &lt;thierry.goubier(a)gmail.com&gt; wrote: > Le 19/04/2018 à 06:31, Tudor Girba a écrit : > >> Hi, >> >> On Apr 18, 2018, at 9:54 PM, Thierry Goubier &lt;thierry.goubier(a)gmail.com&gt; >>> 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. > > 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 &lt;thierry.goubier(a)gmail.com&gt; >>>>> 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 &lt;tudor(a)tudorgirba.com&gt;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&gt; wrote: >>>>>>> >>>>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe &lt;sven(a)stfx.eu&gt;eu>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier &lt;thierry.goubier(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel &lt;alex.syrel(a)gmail.com&gt;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&gt; wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich < >>>>>>>>> serge.stinckwich(a)gmail.com&gt;gt;: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier < >>>>>>>>> thierry.goubier(a)gmail.com&gt; wrote: >>>>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba &lt;tudor(a)tudorgirba.com&gt;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 >