Hi Stef, Thanks for these questions. See some replies inline and we will also create threads with the larger topics to get people more engaged.

On Jan 25, 2017, at 9:32 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Hi bloc/brick guys

I was a great talk. I had to run because I forgot my appointment to the doctor. Now some points

- first a meta point: we should check how we can get more people following the talks.

Now related to bloc/bricks

- we should pay really attention to the maintenance and deployment of the external libraries (I could ****never**** install GTK on my mac using darwin. Sure you can experiment but I think that bloc without a widget layer is a nice stuff but not usable.

Definitely. The goal here is to get something that works without problems. GTK is an experiment only at this point to see how flexible we really are on the backend side. Moz2D is another problem that I will detail in a separate email. About Brick, see the end of the mail.

- what is the oldest machine it is working?

This is an interesting question. One of the cool things about Moz2D is that it is actually another layer on top of concrete rendering backends while still being fast. The concrete rendering is flexible and decided based on the configuration of the machine depending on things like OS or hardware acceleration availability. Given that this engine is at the core of Firefox and they also have to address the problem of various hardware we are in a reasonable position. Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

What is the entrance barrier in terms of cost?

Do you have another issue in mind beside the one above?

- So since you are basically two where is the roadmap? What is your visibility in terms of % of your time on the project because at the end of the day you should earn money.

Let’s postpone this discussion for a bit longer.

- The question of the patterns used to build the widgets is important. The question of how to validate it for real is also important.

Yes, definitely. The effort did not get at that point. Bloc went through an amazing journey and it got refined multiple times by exercising it with rather crazy ideas such as effects, composition, layouts and now we think it reached a point in which the main structure is stable. I am sure we can still find smaller points to refine but the overall structure looks quite robust now. So, the next point is definitely Brick.

- Do you plan commenting/cleaning categorisation for real? I still do not get how you can design something without writing the assumptions of the design into class comments. Then with such systematic lack of comments you cannot benefit from the "no broken window effect". Now this is more if I see a comments it is either old, bad or useless "I'm an abstract class". At least it was like that the last time I checked. And they are certainly many many concerns that are hidden everywhere and are undocumented.

Yes. This is a focus point. Right now, there are assertions in the code for pre-conditions, there are tests and there are examples. The documentation is less advanced, but it is a focus point. For example, the new editor work is commented quite thoroughly and these comments will start to appear through the rest of the infrastructure. But, it would be very cool to have more people to start asking questions as this will help us drive documentation.

- How do you want to get people involved? To me this is totally unclear. Especially with the previous point in mind. I mean for real not just "oh yes we need users”

I think it is hard to get people involved without providing some benefit. As you noted above, without having working widgets, there is almost no value. That is why it is critical to get to Brick, and once we will get there the feedback will come. It was really hard to get to the state of current Bloc. Glenn and Alex did a really amazing job especially if you look at how many times they iterated over the details and put up with that uncertainty. But, the results are quite incredible and now we can shift our focus to Brick. Now, Brick worked in several incarnations, the last ones being done by Glenn. And the code is there, but the blocker was text support. That is why we had all this investment in Moz2D (the only reason why we have the patching is because of the text support) and in the editor. It was not clear at all that the idea of representing a text as a plain layout of elements will work, but since a week or so we know that it does and now we can commit to it. So, the next focus is to get the editor working and then we will iterate on that. Of course, the patterns of how we compose widgets to models is important, too and this will be on focus. MVC/MVP are options, but I am also interested to see how we can get reactive programming closer to the widgets. Cheers, Doru

Stef

On Tue, Jan 24, 2017 at 5:00 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: this is going to start now :)

...

On 24 Jan 2017, at 14:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:

Hello,

We will handle the techtalk as latest one: One video streaming and questions/discussion over our discord channel. So here are the links:

stream: https://www.youtube.com/watch?v=fvpfr6OJ0mM discord: https://discord.gg/88sbn83

See you there in 3hs! Esteban

-- www.tudorgirba.com www.feenk.com "No matter how many recipes we know, we still value a chef."

Hi,

On Jan 25, 2017, at 11:19 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: ...

Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

I have low-end systems on very recent software (chromebook on Ubuntu 16.10, laptop on 16.04), which causes two issues: - Fairly slow (shows clearly where Pharo is slow or fast) - Too new (breaks some vms)

I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :). Cheers, Doru

Thierry

-- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Doru I would like to see the laserGame implemented in Bloc (because it does not need widgets). and it will be a real example. Stef On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier <thierry.goubier@gmail.com

wrote:

2017-01-25 11:33 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

...

Hi,

...

On Jan 25, 2017, at 11:19 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: ...

Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

I have low-end systems on very recent software (chromebook on Ubuntu 16.10, laptop on 16.04), which causes two issues: - Fairly slow (shows clearly where Pharo is slow or fast) - Too new (breaks some vms)

I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :).

Should I just give it a try, or do you have something specific in mind I should bench (response time, animation jitter, etc..)?

Regards,

Thierry

...

Cheers, Doru

...

Thierry

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

Nice ideas! What would be cool if someone else would like to try to implement any of these. Anyone interested? Cheers, Doru

On Jan 25, 2017, at 11:49 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Another example is a logo turtle. With or without animation.

Stef

On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote: Doru

I would like to see the laserGame implemented in Bloc (because it does not need widgets). and it will be a real example.

Stef

On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2017-01-25 11:33 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,

...

On Jan 25, 2017, at 11:19 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: ...

Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

I have low-end systems on very recent software (chromebook on Ubuntu 16.10, laptop on 16.04), which causes two issues: - Fairly slow (shows clearly where Pharo is slow or fast) - Too new (breaks some vms)

I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :).

Should I just give it a try, or do you have something specific in mind I should bench (response time, animation jitter, etc..)?

Regards,

Thierry

Cheers, Doru

...

Thierry

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

-- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

I have got all of the old Pen demos. No big deal to adjust them to Bloc I think. Phil On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Nice ideas!

What would be cool if someone else would like to try to implement any of these. Anyone interested?

Cheers, Doru

...

On Jan 25, 2017, at 11:49 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Another example is a logo turtle. With or without animation.

Stef

On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse < stepharo.self@gmail.com> wrote: Doru

I would like to see the laserGame implemented in Bloc (because it does not need widgets). and it will be a real example.

Stef

On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

2017-01-25 11:33 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi,

...

On Jan 25, 2017, at 11:19 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Doru,

2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: ...

Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

I have low-end systems on very recent software (chromebook on Ubuntu 16.10, laptop on 16.04), which causes two issues: - Fairly slow (shows clearly where Pharo is slow or fast) - Too new (breaks some vms)

I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :).

Should I just give it a try, or do you have something specific in mind I should bench (response time, animation jitter, etc..)?

Regards,

Thierry

Cheers, Doru

...

Thierry

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

-- www.tudorgirba.com www.feenk.com

"It's not how it is, it is how we see it."

2017-01-25 13:40 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-01-25 11:45 GMT+01:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

...

Nevertheless, it would be very cool to have people test this assumption on old machines. I think Thierry was saying that he has an old machine :). @Thierry?

...

I have low-end systems on very recent software (chromebook on Ubuntu

16.10, laptop on 16.04), which causes two issues:

...

- Fairly slow (shows clearly where Pharo is slow or fast) - Too new (breaks some vms)

I can be a good performance indicator, yes.

Great. It would be really cool if you could give Bloc a try :).

Should I just give it a try, or do you have something specific in mind I should bench (response time, animation jitter, etc..)?

Would be nice just to know your feedback about BlInfiniteLinearLayoutExamples on old machines. They provide very smooth scrolling on big lists. So it should be just visible: fast it or slow.

First return: moz2D prerequisites do not install cleanly on ubuntu 16.04. They look nice and smooth, scrolling is tuned at slow for long lists. It segfaults regularly when scrolling. Do you have an example of scrolling where I can choose to scroll fast or slow depending on how I use the trackpad or scrollwheel? On Linux, the OS doesn't manipulate those events as Macs seems to be doing, so you need to code that. Regards, Thierry

Hi Thierry Thanks for your testing effort! moz2D prerequisites do not install cleanly on ubuntu 16.04. Exactly, it is hard to install many 32 dependencies on 64bit linux system. (there is no solution for this). That is why it would be nice to have 64 bit VM for 64 bit linux :) With 64bit vm there will be almost none additional dependencies required. They look nice and smooth, scrolling is tuned at slow for long lists. How do you scroll? Current scrolling behaviour is very simple while being rather powerful. Speed increases if user continuously scrolls with mouse wheel or touchpad. Faster you move your finger on touchpad or scroll more frequent with mouse wheel than faster is scrolling speed. It segfaults regularly when scrolling. This might be unrelated to the library. Could you send crash dump? Do you have an example of scrolling where I can choose to scroll fast or

slow depending on how I use the trackpad or scrollwheel? On Linux, the OS doesn't manipulate those events as Macs seems to be doing, so you need to code that.

This behaviour is a default one. Maybe problem is with SDL2 events? Video would be great to understand how you scroll and how you expect it to be :) Cheers, Alex

Hi Alex, it's good to see widget development. 2017-01-25 15:40 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:

Hi Thierry

Thanks for your testing effort!

moz2D prerequisites do not install cleanly on ubuntu 16.04.

Exactly, it is hard to install many 32 dependencies on 64bit linux system. (there is no solution for this). That is why it would be nice to have 64 bit VM for 64 bit linux :)

Yes. This is the reason I gave up on libcgit when I started GitFileTree: too complex, no :i386 system lib available.

With 64bit vm there will be almost none additional dependencies required.

Almost is the key... Given that the 64bits VM doesn't work properly on Ubuntu 16.04 and 16.10, take that as a long term goal.

They look nice and smooth, scrolling is tuned at slow for long lists.

How do you scroll? Current scrolling behaviour is very simple while being rather powerful. Speed increases if user continuously scrolls with mouse wheel or touchpad. Faster you move your finger on touchpad or scroll more frequent with mouse wheel than faster is scrolling speed.

Ok, I tried again because I could not feel the acceleration effect. Yes, it goes a bit faster. But I stopped half way through the list: it is tuned a lot slower than I'm used to with Morphic. Reversing scrolling direction halts it immediately or slows it down? I could not see. Slow it down almost immediately (tried with the trackpad).

It segfaults regularly when scrolling.

This might be unrelated to the library. Could you send crash dump?

Do you have an example of scrolling where I can choose to scroll fast or

...

slow depending on how I use the trackpad or scrollwheel? On Linux, the OS doesn't manipulate those events as Macs seems to be doing, so you need to code that.

This behaviour is a default one. Maybe problem is with SDL2 events? Video would be great to understand how you scroll and how you expect it to be :)

I'll try that on a lower-end machine. Basically, If I compare the bloc class list to a Morphic class list scrolling variable speed example, I really have to work out hard the scroll wheel with Bloc... and, still, I'm not reaching the end of the list. Works better with the track pad (reached the end, yes!) and had many DNUs. Segfaults if I quit the image with a bloc window open. Regards, Thierry

Cheers, Alex

2017-01-25 16:34 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:

On 25 January 2017 at 16:02, Thierry Goubier <thierry.goubier@gmail.com> wrote:

...

Yes, it goes a bit faster. But I stopped half way through the list: it is tuned a lot slower than I'm used to with Morphic.

Hehe :) Tuning is another story. Current implementation treats mouse wheel and trackpad in the same way, which should not be the case of course.

And you have to account a possible tuning for a touch screen as well... I've made my tuning for the trackpad of my two laptops, more or less (a bit oversensitive for the trackpad, but that makes the scrollwheel usable).

Basically, If I compare the bloc class list to a Morphic class list

...

scrolling variable speed example, I really have to work out hard the scroll wheel with Bloc... and, still, I'm not reaching the end of the list.

I made a video comparison of 3 list implementations that display all smalltalk classes. I tried to scroll identically for all three cases and covered almost the same distance with mouse wheel: ​ Morphic-Bloc-Lists.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTS1JqM01CY21PUmc/view?usp=drive_...> ​ What morphic example did you use?

AltListTests exampleTree1. I'll try to show you side by side (but do I have a scroll wheel at home? Not sure). I've made a few irregular examples to test (20000 items, with a random text size from small to very large). Illustrates mostly how slow is subpixel display of text in Morphic.

I would be also very very glad to know what DNUs and segfaults you get :)

DNU is: Instance of BlSDLEventHandler did not understand #bitOr: (note, this is the user version of Bloc, not the developer one) Regards, Thierry

Cheers, Alex