bloc status update: june 2016
Hi, Here is a brief update on the status of Bloc. Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list. Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate... The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful. Cheers, Doru -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."
2016-06-21 7:42 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster,
As you are on it, there changed somthing in UFFI between pharo 60059/60060 ( 18361 <https://pharo.fogbugz.com/f/cases/18361/Update-UFFI-version-to-0-20-2> Update UFFI version to 0.20.2) see attached screenshot
- Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
How can I see this window?
On 21 Jun 2016, at 09:23, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-21 7:42 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate... <https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...>
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster,
As you are on it, there changed somthing in UFFI between pharo 60059/60060 (18361 <https://pharo.fogbugz.com/f/cases/18361/Update-UFFI-version-to-0-20-2> Update UFFI version to 0.20.2)
see attached screenshot
- Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"What we can governs what we wish."
<uffi_athens_textrendering.PNG>
2016-06-21 13:41 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
How can I see this window?
'stringmorph' asMorph openInSceneView
On 21 Jun 2016, at 09:23, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-21 7:42 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster,
As you are on it, there changed somthing in UFFI between pharo 60059/60060 (18361 <https://pharo.fogbugz.com/f/cases/18361/Update-UFFI-version-to-0-20-2> Update UFFI version to 0.20.2)
see attached screenshot
- Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
<uffi_athens_textrendering.PNG>
Hi Doru, I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework. [image: Inline image 1] On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
Hi Clement, Thanks for looking at it. Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date. And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses. Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation. In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you. No examples are not enough, actually I take class comments over examples any day. Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo. On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
You are right, code without comments is not acceptable. But, but. How many serious, non-trivial, public code bases consisting of 10s or 100s of classes and 1000s or 10000s of methods have you, or anyone else giving remarks, written and FULLY documented according to those high standards ? I prefer for people to actually write code and hope that they will eventually document it all.
On 21 Jun 2016, at 10:22, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation.
In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you.
No examples are not enough, actually I take class comments over examples any day.
Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo.
On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
Hi Sven, 2016-06-21 10:45 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
You are right, code without comments is not acceptable.
But, but.
How many serious, non-trivial, public code bases consisting of 10s or 100s of classes and 1000s or 10000s of methods have you, or anyone else giving remarks, written and FULLY documented according to those high standards ?
That many classes undocumented is not justified by any standard, be it work in progress or not. Generated classes, ok. Last few created classes, ok. A complete hierarchy of classes without a single line of comment? Sorry, no, not justified.
I prefer for people to actually write code and hope that they will eventually document it all.
Given the lack of comments, I'd suspect this is considered as 'could be rewritten entirely' anytime soon. Not something one should invest on to understand or follow. The problem I see there is the investment one has to make to participate (or just have a look). Creating barriers like an apparent lack of comment (or a 'work in progress : not stable' tag) increase the necessary investment to put into (taking in account GUI toolkits are never 'simple', 'easy' stuff to start with). Hum, in that latest Bloc as far as I could see: nothing else than layout examples? Hard to get around in that stuff with Nautilus. Thierry
On 21 Jun 2016, at 10:22, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation.
In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you.
No examples are not enough, actually I take class comments over examples any day.
Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo.
On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
I am not the kind of guy to tell other people what is acceptable and what is not Actually its perfectly acceptable because its your code and your entitled to do whatever you want with it. You ask me how many open source and even commercial projects there are out there that have partial or bad documentation. I will say the vast majority. However Tudor said that feedback is very important for the team and I am willing to assume here that they would not complain if more joined their effort to further speed up the replacement of Morphic with Bloc. People cannot contribute or provide feedback to something they dont understand. Its a high standard to write a few lines per class and spend no more than 20 seconds when the benefits in doing so will be massive ? Sorry but I dont agree, writting class comments is super simple and super fast there are no excuses. And no it does not matter if your library is 1 billion methods. Seriously you think that anyone will actually be motivated when you end up with 1 00 classes to write comments for it ? This exactly why documentation always suffer because you live it last and it looks like a mountain to climb. One of the best quotes I have read is the following "Documentation is not mandatory by itself, its mandatory only when you want your project to succeed" But if the majority of pharo users agree with your opinion that writing code is more important than documenting it, so be it, I will have to live with that. On Tue, Jun 21, 2016 at 11:46 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:
You are right, code without comments is not acceptable.
But, but.
How many serious, non-trivial, public code bases consisting of 10s or 100s of classes and 1000s or 10000s of methods have you, or anyone else giving remarks, written and FULLY documented according to those high standards ?
I prefer for people to actually write code and hope that they will eventually document it all.
On 21 Jun 2016, at 10:22, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation.
In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you.
No examples are not enough, actually I take class comments over examples any day.
Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo.
On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
Hi, I find this discussion quite entertaining. Just to clarify: this was an update of the current status. We do not ask you to do anything. If you do choose to invest, please do so knowing that it is very early stage and we will move fast. We happily take your input into account, but please letâs get specific. For example, if you want to help us write documentation, ask concrete questions that you might have. Cheers, Doru
On Jun 21, 2016, at 11:29 AM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I am not the kind of guy to tell other people what is acceptable and what is not
Actually its perfectly acceptable because its your code and your entitled to do whatever you want with it.
You ask me how many open source and even commercial projects there are out there that have partial or bad documentation. I will say the vast majority.
However Tudor said that feedback is very important for the team and I am willing to assume here that they would not complain if more joined their effort to further speed up the replacement of Morphic with Bloc.
People cannot contribute or provide feedback to something they dont understand.
Its a high standard to write a few lines per class and spend no more than 20 seconds when the benefits in doing so will be massive ?
Sorry but I dont agree, writting class comments is super simple and super fast there are no excuses. And no it does not matter if your library is 1 billion methods.
Seriously you think that anyone will actually be motivated when you end up with 1 00 classes to write comments for it ? This exactly why documentation always suffer because you live it last and it looks like a mountain to climb.
One of the best quotes I have read is the following
"Documentation is not mandatory by itself, its mandatory only when you want your project to succeed"
But if the majority of pharo users agree with your opinion that writing code is more important than documenting it, so be it, I will have to live with that.
On Tue, Jun 21, 2016 at 11:46 AM Sven Van Caekenberghe <sven@stfx.eu> wrote: You are right, code without comments is not acceptable.
But, but.
How many serious, non-trivial, public code bases consisting of 10s or 100s of classes and 1000s or 10000s of methods have you, or anyone else giving remarks, written and FULLY documented according to those high standards ?
I prefer for people to actually write code and hope that they will eventually document it all.
On 21 Jun 2016, at 10:22, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation.
In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you.
No examples are not enough, actually I take class comments over examples any day.
Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo.
On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."
On Tue, Jun 21, 2016 at 10:45 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
You are right, code without comments is not acceptable.
But, but.
How many serious, non-trivial, public code bases consisting of 10s or 100s of classes and 1000s or 10000s of methods have you, or anyone else giving remarks, written and FULLY documented according to those high standards ?
I prefer for people to actually write code and hope that they will eventually document it all.
I agree with you. If we take the example of Bee Smalltalk, their code convention is to have no comment at all in the code, all the documentation is in separated files. So when I saw what you can see in the screenshot I provided, I thought Bloc had the same coding convention so I asked because maybe there was an external documentation too. It's not the case, there is not that many comments yet because the framework is a work in progress and that's fine with me.
On 21 Jun 2016, at 10:22, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation.
In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you.
No examples are not enough, actually I take class comments over examples any day.
Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo.
On Tue, Jun 21, 2016 at 11:11 AM Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
Hi Doru, Ok I understand I have issues keeping comments updated in my projects too :-). Do your best. I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work. How can I have the examples running ? Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill. [image: Inline image 2] Here are the examples: [image: Inline image 1] Best, Clement On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
Hi, Thanks for looking at it. You have to first switch to the Bloc space: World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window) Then, from Nautilus, you can pick an example and Inspect Return-Values to get the object. Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Hi, Thanks Doru it now works for me ! Very exciting indeed. I have a few questions: 1. In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo. 2. Can we change the fonts in Bloc ? 3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license: Copyright (C) 2011 The Android Open Source Project Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Does it mean Bloc is not under MIT ? Or is it completely unrelated ? 4. What is Cairo-Sparta ? What is the difference with Athens ? 5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time... Well keep up the good work. On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect Return-Values to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com
wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Hello Clement restoreAfter: is not only for transformation. It also restores clipping - that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements. Right now there is a huge work going on new Sparta - it will be almost stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on). Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness. In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness. Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost. Cheers Alex On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect Return-Values to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com
wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license:
It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI. Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence. Here is google's documentation:
Bellman-Ford variant - modified to reduce typical running time from O(N^2) to O(N) GridLayout converts its requirements into a system of linear constraints of the form: x[i] - x[j] < a[k]
Where the x[i] are variables and the a[k] are constants. For example, if the variables were instead labeled x, y, z we might have: x - y < 17 y - z < 23 z - x < 42
This is a special case of the Linear Programming problem that is, in turn, equivalent to the single-source shortest paths problem on a digraph, for which the O(n^2) Bellman-Ford algorithm the most commonly used general solution.
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly. Cheers, Alex On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hello Clement
restoreAfter: is not only for transformation. It also restores clipping -
that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements.
Right now there is a huge work going on new Sparta - it will be almost
stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on).
Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness.
In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill
Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness.
Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost.
Cheers Alex
On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and
right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid
Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5%
of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ?
- It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect Return-Values
to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com>
wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects
too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't
work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of
BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com>
wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring
the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Can we change the fonts in Bloc ?
Bloc is not new Pharo :) It is also not Morphic. Bloc is very low level engine that does not have theme and widgets. Morphic apps (like Nautilus) are just running in compatibility mode and are rendered on Athens canvas. Existing Pharo applications use fonts provided by StandardFonts that can be changed from Menu > Settings. Cheers, Alex On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout,
I find the following license:
It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI.
Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence.
Here is google's documentation:
Bellman-Ford variant - modified to reduce typical running time from O(N^2) to O(N) GridLayout converts its requirements into a system of linear constraints of the form: x[i] - x[j] < a[k]
Where the x[i] are variables and the a[k] are constants. For example, if the variables were instead labeled x, y, z we might have: x - y < 17 y - z < 23 z - x < 42
This is a special case of the Linear Programming problem that is, in turn, equivalent to the single-source shortest paths problem on a digraph, for which the O(n^2) Bellman-Ford algorithm the most commonly used general solution.
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hello Clement
restoreAfter: is not only for transformation. It also restores clipping
- that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements.
Right now there is a huge work going on new Sparta - it will be almost
stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on).
Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness.
In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill
Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness.
Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost.
Cheers Alex
On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and
right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid
Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5%
of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ?
- It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect Return-Values
to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com>
wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects
too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't
work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of
BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com>
wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and
refactoring the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
What is Cairo-Sparta ? What is the difference with Athens ?
Sparta-Canvas is just an implementation of Athens API that uses Cairo as backend. It is the same as Athens-Cairo, with a few small differences. - Sparta has different meaning of clipBy: during: In Athens clipBy: only accepts a Rectangle, in Sparta it is an arbitrary Path. - Sparta has some experimental api just for fun and to find out if there is a way to render faster. Since Athens is used in (many?) external packages it is not possible to redefine clipBy: . Also having a separate implementation of Athens API (Sparta-Cairo) allows developers of Bloc to iterate faster and save time on integration process. Cheers, Alex On Tue, Jun 21, 2016 at 3:46 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Can we change the fonts in Bloc ?
Bloc is not new Pharo :) It is also not Morphic. Bloc is very low level engine that does not have theme and widgets. Morphic apps (like Nautilus) are just running in compatibility mode and are rendered on Athens canvas. Existing Pharo applications use fonts provided by StandardFonts that can be changed from Menu > Settings.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout,
I find the following license:
It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI.
Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence.
Here is google's documentation:
Bellman-Ford variant - modified to reduce typical running time from O(N^2) to O(N) GridLayout converts its requirements into a system of linear constraints of the form: x[i] - x[j] < a[k]
Where the x[i] are variables and the a[k] are constants. For example, if the variables were instead labeled x, y, z we might have: x - y < 17 y - z < 23 z - x < 42
This is a special case of the Linear Programming problem that is, in turn, equivalent to the single-source shortest paths problem on a digraph, for which the O(n^2) Bellman-Ford algorithm the most commonly used general solution.
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hello Clement
restoreAfter: is not only for transformation. It also restores clipping
- that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements.
Right now there is a huge work going on new Sparta - it will be almost
stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on).
Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness.
In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill
Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness.
Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost.
Cheers Alex
On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and
right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid
Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect
Return-Values to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com>
wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects
too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't
work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of
BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com>
wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and
refactoring the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
It was like that from the very begging of Bloc development. Main developers of Bloc prefer right click to open menu (like almost everywhere except Pharo). Cheers, Alex On Tue, Jun 21, 2016 at 3:52 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
What is Cairo-Sparta ? What is the difference with Athens ?
Sparta-Canvas is just an implementation of Athens API that uses Cairo as backend. It is the same as Athens-Cairo, with a few small differences.
- Sparta has different meaning of clipBy: during: In Athens clipBy: only accepts a Rectangle, in Sparta it is an arbitrary Path. - Sparta has some experimental api just for fun and to find out if there is a way to render faster.
Since Athens is used in (many?) external packages it is not possible to redefine clipBy: . Also having a separate implementation of Athens API (Sparta-Cairo) allows developers of Bloc to iterate faster and save time on integration process.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:46 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Can we change the fonts in Bloc ?
Bloc is not new Pharo :) It is also not Morphic. Bloc is very low level engine that does not have theme and widgets. Morphic apps (like Nautilus) are just running in compatibility mode and are rendered on Athens canvas. Existing Pharo applications use fonts provided by StandardFonts that can be changed from Menu > Settings.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid
Layout, I find the following license:
It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI.
Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence.
Here is google's documentation:
Bellman-Ford variant - modified to reduce typical running time from O(N^2) to O(N) GridLayout converts its requirements into a system of linear constraints of the form: x[i] - x[j] < a[k]
Where the x[i] are variables and the a[k] are constants. For example, if the variables were instead labeled x, y, z we might have: x - y < 17 y - z < 23 z - x < 42
This is a special case of the Linear Programming problem that is, in turn, equivalent to the single-source shortest paths problem on a digraph, for which the O(n^2) Bellman-Ford algorithm the most commonly used general solution.
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hello Clement
restoreAfter: is not only for transformation. It also restores
clipping - that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements.
Right now there is a huge work going on new Sparta - it will be almost
stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on).
Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness.
In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill
Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness.
Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost.
Cheers Alex
On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and
right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid
Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect
Return-Values to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com>
wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my
projects too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't
work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of
BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com>
wrote:
Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here:
https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and
refactoring the way we can manage ,
- Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- www.tudorgirba.com www.feenk.com
"Presenting is storytelling."
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
yes, and I always said this is plain bad. how it is now it is not a contextual menu, is NextStep style and is the correct behaviour (after we can discuss if we want to keep a menu as it is now or not, but thatâs another discussion) :) Esteban
On 21 Jun 2016, at 15:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
It was like that from the very begging of Bloc development. Main developers of Bloc prefer right click to open menu (like almost everywhere except Pharo).
Cheers, Alex
On Tue, Jun 21, 2016 at 3:52 PM, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote: What is Cairo-Sparta ? What is the difference with Athens ? Sparta-Canvas is just an implementation of Athens API that uses Cairo as backend. It is the same as Athens-Cairo, with a few small differences.
- Sparta has different meaning of clipBy: during: In Athens clipBy: only accepts a Rectangle, in Sparta it is an arbitrary Path. - Sparta has some experimental api just for fun and to find out if there is a way to render faster.
Since Athens is used in (many?) external packages it is not possible to redefine clipBy: . Also having a separate implementation of Athens API (Sparta-Cairo) allows developers of Bloc to iterate faster and save time on integration process.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:46 PM, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote: Can we change the fonts in Bloc ?
Bloc is not new Pharo :) It is also not Morphic. Bloc is very low level engine that does not have theme and widgets. Morphic apps (like Nautilus) are just running in compatibility mode and are rendered on Athens canvas. Existing Pharo applications use fonts provided by StandardFonts that can be changed from Menu > Settings.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote: When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license:
It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI.
Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence.
Here is google's documentation:
Bellman-Ford variant - modified to reduce typical running time from O(N^2) to O(N) GridLayout converts its requirements into a system of linear constraints of the form: x[i] - x[j] < a[k]
Where the x[i] are variables and the a[k] are constants. For example, if the variables were instead labeled x, y, z we might have: x - y < 17 y - z < 23 z - x < 42
This is a special case of the Linear Programming problem that is, in turn, equivalent to the single-source shortest paths problem on a digraph, for which the O(n^2) Bellman-Ford algorithm the most commonly used general solution.
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly.
Cheers, Alex
On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>> wrote:
Hello Clement
restoreAfter: is not only for transformation. It also restores clipping - that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements.
Right now there is a huge work going on new Sparta - it will be almost stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on). Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness.
In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill
Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness.
Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost.
Cheers Alex
On Jun 21, 2016 1:34 PM, "Clément Bera" <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:
Hi,
Thanks Doru it now works for me ! Very exciting indeed.
I have a few questions:
1. In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
2. Can we change the fonts in Bloc ?
3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0 <http://www.apache.org/licenses/LICENSE-2.0>
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
4. What is Cairo-Sparta ? What is the difference with Athens ?
5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. - Aside from restoreAfter, there is no obvious ways on how to save time...
Well keep up the good work.
On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Thanks for looking at it.
You have to first switch to the Bloc space:
World Menu / Bloc / Switch to Bloc (I think there is a problem right now with OS-Window)
Then, from Nautilus, you can pick an example and Inspect Return-Values to get the object.
Cheers, Doru
On Jun 21, 2016, at 10:42 AM, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:
Hi Doru,
Ok I understand I have issues keeping comments updated in my projects too :-). Do your best.
I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org <http://files.pharo.org/> and retried and it still didn't work.
How can I have the examples running ?
Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill.
<Screen Shot 2016-06-21 at 10.40.39 AM.png>
Here are the examples:
<Screen Shot 2016-06-21 at 10.37.49 AM.png>
Best,
Clement
On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: Hi Clement,
Thanks for looking at it.
Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date.
And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses.
Cheers, Doru
On Jun 21, 2016, at 9:39 AM, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:
Hi Doru,
I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework.
<Screen Shot 2016-06-21 at 9.33.31 AM.png>
On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: Hi,
Here is a brief update on the status of Bloc.
Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list.
Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: - Element is responsible for drawing (no more shape) - Interaction area and clipping area are now distinct
You can find the current build on top of Pharo 6 here: https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate... <https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLate...>
The current team focus goes like this: - Alain is looking at events, - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , - Alex (Syrel) and Esteban are working on the backend to make rendering faster, - Doru is pretending to do something useful.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"What we can governs what we wish."
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Presenting is storytelling."
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
On Tue, Jun 21, 2016 at 10:07 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
yes, and I always said this is plain bad. how it is now it is not a contextual menu,
I'm not clear how you mean this "how it is now", so I /think/ I'm agreeing when I say the World Menu is a context menu - the menu in the context of the World - which is why it should be on the right-mouse-button - the same as all our other context menus and those of the rest of the world.
is NextStep style and is the correct behaviour (after we can discuss if we want to keep a menu as it is now or not, but thatâs another discussion) :)
Esteban
On 21 Jun 2016, at 15:54, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo.
It was like that from the very begging of Bloc development. Main developers of Bloc prefer right click to open menu (like almost everywhere except Pharo).
Cheers, Alex
On Tue, Jun 21, 2016 at 3:52 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license:
Copyright (C) 2011 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a lawyer can answer more correctly.
Cheers, Alex
These charts provide a nice overview... [1] http://i.stack.imgur.com/CZIoa.png [2] http://www.dwheeler.com/essays/floss-license-slide.html [3] http://choosealicense.com/licenses/ Comparing MIT and Apache, the latter... * protects against patents * protects against trademark misuse * disclaims warranty and liability * requires changes to be clearly identified (in source) * default license assignment to contributions I believe [1] is in error tagging Apache as "any change must be distributed in source form." It is only IF you distribute in source form that you need to retain all copyright, patent, trademark and attribution notices. cheers -ben
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Does it mean Bloc is not under MIT ? Or is it completely unrelated ?
Hi, Please, pay attention that the design may/will change quickly. As Doru said, it is the current status, not the final status and many changes may/will appear. I say that because we are working on it (revisiting the core model), so it would be different. Cheers, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4902208.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Tudor Girba-2 wrote
Here is a brief update on the status of Bloc.
Thanks! Tudor Girba-2 wrote
your feedback is important
As we've imagined and experimented with the UI of our future, I've felt very strongly that it's essential for the world to be built up from building blocks which make few assumptions other than their communication protocol and can be easily plugged in and out by a courageous user. A test case for this, which opens up many exciting possibilities (imagine I want to control time in my space e.g. run a simulation at 10x speed...), would be to have a world within a world. I dabbled with this idea a bit in Morphic, but quickly became frustrated because Morphic makes too many assumptions e.g. relying on globals and hardcoded classes. The last time I tried this in Bloc, the result of the discussion was that Alain said that this should be conceptually possible, but that I should be patient (http://forum.world.st/Bloc-Space-within-a-Space-td4877474.html). Are we any closer to this dream? ----- Cheers, Sean -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4902319.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean P. DeNigris wrote
A test case for this, which opens up many exciting possibilities (imagine I want to control time in my space e.g. run a simulation at 10x speed...), would be to have a world within a world. I dabbled with this idea a bit in Morphic, but quickly became frustrated because Morphic makes too many assumptions e.g. relying on globals and hardcoded classes.
The last time I tried this in Bloc, the result of the discussion was that Alain said that this should be conceptually possible, but that I should be patient (http://forum.world.st/Bloc-Space-within-a-Space-td4877474.html). Are we any closer to this dream?
Bump!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4906283.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi, That is one of the variables we have on the radar. Whether we can make it in the first iteration, remains to be seen. Cheers, Doru
On Jul 12, 2016, at 4:57 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sean P. DeNigris wrote
A test case for this, which opens up many exciting possibilities (imagine I want to control time in my space e.g. run a simulation at 10x speed...), would be to have a world within a world. I dabbled with this idea a bit in Morphic, but quickly became frustrated because Morphic makes too many assumptions e.g. relying on globals and hardcoded classes.
The last time I tried this in Bloc, the result of the discussion was that Alain said that this should be conceptually possible, but that I should be patient (http://forum.world.st/Bloc-Space-within-a-Space-td4877474.html). Are we any closer to this dream?
Bump!!
----- Cheers, Sean -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4906283.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com www.feenk.com "Sometimes the best solution is not the best solution."
Hi glenn with bloc2 (yes new implementation) it will be possible, Glenn can open separate worlds and we discussed a lot your point (and we share it). Stef Le 12/7/16 à 16:57, Sean P. DeNigris a écrit :
Sean P. DeNigris wrote
A test case for this, which opens up many exciting possibilities (imagine I want to control time in my space e.g. run a simulation at 10x speed...), would be to have a world within a world. I dabbled with this idea a bit in Morphic, but quickly became frustrated because Morphic makes too many assumptions e.g. relying on globals and hardcoded classes.
The last time I tried this in Bloc, the result of the discussion was that Alain said that this should be conceptually possible, but that I should be patient (http://forum.world.st/Bloc-Space-within-a-Space-td4877474.html). Are we any closer to this dream? Bump!!
----- Cheers, Sean -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4906283.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Does this mean "worlds within worlds" or "worlds adjacent to other worlds". If adjacent, will they be able to communicate with each other? ----- Brad Selfridge -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4906373.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
For now it means that we can write "World new open" and we can use this to write tests. We have Bloc2 SDL worlds side by side and the goal is to have everything ready (tools and widgets) and to get rid of the morphic one. In Bloc1 we did not have other physical window so we had too many constraints and morphic infection points. But we could run Morphic inside Bloc. In Bloc2 this is not possible but we get a better event bubbling model and other possibilities. Stef Le 13/7/16 à 03:27, Brad Selfridge a écrit :
Does this mean "worlds within worlds" or "worlds adjacent to other worlds". If adjacent, will they be able to communicate with each other?
----- Brad Selfridge -- View this message in context: http://forum.world.st/bloc-status-update-june-2016-tp4901988p4906373.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (13)
-
Aliaksei Syrel -
Ben Coman -
Brad Selfridge -
Clément Bera -
Dimitris Chloupis -
Esteban Lorenzano -
Glenn Cavarlé -
Nicolai Hess -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba