I always wanted to do this in Morphic, but it made too many assumptions about the World's environment e.g. use of globals like ActiveHand and World. I gave it a shot (see below). The new space did appear in the current world, but the rectangle seemed to open in the container world, not in the new world because when I closed the new space via the halo the rectangle remained. For me, it is very important to have a space easily create-able and drivable. This makes real testing possible, prevents another global mess, and makes other /really/ exciting possibilities within reach. Can it be done in Bloc? If not, what would it take? s := BlBlocSpace new. root := s rootElement. root extent: 500 @ 500. root openInWorld; yourself. rect := BlElement exampleRectangle. rect openInWorld: root world. s redraw. root updateDrawing. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I'm not sure I understand what you want to archive with provided code :) Space is not something you want to embed in another space. Space manages UI thread, event fetching, alarms and many other low level stuff. Universe contains spaces and there can be only one running space at a time - read there can be only one active UI thread and event fetcher in the system. Check Bloc-Core-Universe. Alain put a lot of effort writing class docs. Please, could you explain in more detail your idea and provide some examples where embedding of spaces could be applicable? This makes real testing possible, prevents another global
mess, and makes other /really/ exciting possibilities within reach
Why? You can create a separate 'Bloc-Test' space and do testing there.
testSpace := BlUniverse default defaultSpaceClass new identifiedBy: 'Bloc-Test'. BlUniverse default addNewSpace: testSpace. BlUniverse default switchToSpace: testSpace.
Cheers, Alex On Sun, Feb 14, 2016 at 3:47 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
I always wanted to do this in Morphic, but it made too many assumptions about the World's environment e.g. use of globals like ActiveHand and World. I gave it a shot (see below). The new space did appear in the current world, but the rectangle seemed to open in the container world, not in the new world because when I closed the new space via the halo the rectangle remained. For me, it is very important to have a space easily create-able and drivable. This makes real testing possible, prevents another global mess, and makes other /really/ exciting possibilities within reach. Can it be done in Bloc? If not, what would it take?
s := BlBlocSpace new. root := s rootElement. root extent: 500 @ 500. root openInWorld; yourself. rect := BlElement exampleRectangle. rect openInWorld: root world. s redraw. root updateDrawing.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Aliaksei Syrel wrote
Space is not something you want to embed in another space.
That's where you're wrong ;-) That's exactly what I want to do! Aliaksei Syrel wrote
Space manages UI thread, event fetching, alarms and many other low level stuff
Yes! That's all the stuff I want to stub out and control. Imagine I want to control time in my space e.g. run a simulation at 10x speed... Aliaksei Syrel wrote
Universe contains spaces and there can be only one running space at a time - read there can be only one active UI thread and event fetcher in the system.
Yes, this is what I am disappointed before. Of course that makes sense in practice in the normal operation of the system, but limits one's creativity to pre-approved uses. IMHO this is the kind of coding-for-one-world-view that made Morphic infuriating to really try to reinvent. Aliaksei Syrel wrote
You can create a separate 'Bloc-Test' space and do testing there.
I should have been more specific. Yes, one can do functional testing, but one can not stub out the dependencies and unit test properly. In fact, IMHO this area of the design is a symptom of lack of TDD. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877492.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Sean I agree that TDD would really make sure that we can script such object. I do not know how to motivate people to do so. In bloc I started to write tests and I immediately found bugs. So it was positive and may be we should have a group of people writing tests. Now I have to finish the mooc and I was waiting that bloc stabilise again. Because I spent time writing comments and they are probably wrong now especially since writing comments on thing you do not master is a PAIN. Stef
On 15 Feb 2016, at 10:27, stepharo <stepharo@free.fr> wrote:
Sean I agree that TDD would really make sure that we can script such object. I do not know how to motivate people to do so. In bloc I started to write tests and I immediately found bugs. So it was positive and may be we should have a group of people writing tests. Now I have to finish the mooc and I was waiting that bloc stabilise again. Because I spent time writing comments and they are probably wrong now especially since writing comments on thing you do not master is a PAIN.
Stef
The first comments (class/method), explaining the design, API and implementation, should always be written by the original authors. It helps them as well, because trying to explain something in words help to validate the design. Only in the next phase should overview/introduction/teaching/book documentation be written by others who might be better explaining things. Documentation is absolutely necessary, especially for published code. Maybe someone should run the 'missing comments' statistics again over the current 50 image ...
+1 - I've been doing TDD commercially since 2003 and as far as I can tell it's a great way to squash bugs. I'd be willing to write tests. Sent from my iPad
On Feb 15, 2016, at 01:36, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 15 Feb 2016, at 10:27, stepharo <stepharo@free.fr> wrote:
Sean I agree that TDD would really make sure that we can script such object. I do not know how to motivate people to do so. In bloc I started to write tests and I immediately found bugs. So it was positive and may be we should have a group of people writing tests. Now I have to finish the mooc and I was waiting that bloc stabilise again. Because I spent time writing comments and they are probably wrong now especially since writing comments on thing you do not master is a PAIN.
Stef
The first comments (class/method), explaining the design, API and implementation, should always be written by the original authors. It helps them as well, because trying to explain something in words help to validate the design.
Only in the next phase should overview/introduction/teaching/book documentation be written by others who might be better explaining things.
Documentation is absolutely necessary, especially for published code.
Maybe someone should run the 'missing comments' statistics again over the current 50 image ...
Le 15/2/16 11:26, John Pfersich a écrit :
+1 - I've been doing TDD commercially since 2003 and as far as I can tell it's a great way to squash bugs. I'd be willing to write tests.
you see if you write tests for Pharo we will welcome them :)
Sent from my iPad
On Feb 15, 2016, at 01:36, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 15 Feb 2016, at 10:27, stepharo <stepharo@free.fr> wrote:
Sean I agree that TDD would really make sure that we can script such object. I do not know how to motivate people to do so. In bloc I started to write tests and I immediately found bugs. So it was positive and may be we should have a group of people writing tests. Now I have to finish the mooc and I was waiting that bloc stabilise again. Because I spent time writing comments and they are probably wrong now especially since writing comments on thing you do not master is a PAIN.
Stef The first comments (class/method), explaining the design, API and implementation, should always be written by the original authors. It helps them as well, because trying to explain something in words help to validate the design.
Only in the next phase should overview/introduction/teaching/book documentation be written by others who might be better explaining things.
Documentation is absolutely necessary, especially for published code.
Maybe someone should run the 'missing comments' statistics again over the current 50 image ...
Hello Sean, Thanks for your remarks. I think that the current space design has the adequate abstractions to do the kind of tests you want. And youâre right, it should be possible. But please do not ask too much. Before having this kind of TDD possible we have to reach a point where we can use Bloc and Brick with real user input events. Maybe we are wrong but this was our approach. Reaching this state requires a huge amount of work but we are almost there :) Cheers Alain
Le 14 févr. 2016 à 19:26, Sean P. DeNigris <sean@clipperadams.com> a écrit :
Aliaksei Syrel wrote
Space is not something you want to embed in another space.
That's where you're wrong ;-) That's exactly what I want to do!
Aliaksei Syrel wrote
Space manages UI thread, event fetching, alarms and many other low level stuff
Yes! That's all the stuff I want to stub out and control. Imagine I want to control time in my space e.g. run a simulation at 10x speed...
Aliaksei Syrel wrote
Universe contains spaces and there can be only one running space at a time - read there can be only one active UI thread and event fetcher in the system.
Yes, this is what I am disappointed before. Of course that makes sense in practice in the normal operation of the system, but limits one's creativity to pre-approved uses. IMHO this is the kind of coding-for-one-world-view that made Morphic infuriating to really try to reinvent.
Aliaksei Syrel wrote
You can create a separate 'Bloc-Test' space and do testing there.
I should have been more specific. Yes, one can do functional testing, but one can not stub out the dependencies and unit test properly. In fact, IMHO this area of the design is a symptom of lack of TDD.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877492.html Sent from the Pharo Smalltalk Users mailing list arch
But I thought that space/universe was done so that we could build multidesktop with mini space to select where to jump and we can imagine that such mini space would be running. So what sean wants to do should be possible. At least I thought that alain planed it. stef Le 14/2/16 16:51, Aliaksei Syrel a écrit :
I'm not sure I understand what you want to archive with provided code :) Space is not something you want to embed in another space. Space manages UI thread, event fetching, alarms and many other low level stuff. Universe contains spaces and there can be only one running space at a time - read there can be only one active UI thread and event fetcher in the system. Check Bloc-Core-Universe. Alain put a lot of effort writing class docs.
Please, could you explain in more detail your idea and provide some examples where embedding of spaces could be applicable?
This makes real testing possible, prevents another global mess, and makes other /really/ exciting possibilities within reach
Why?
You can create a separate 'Bloc-Test' space and do testing there.
testSpace := BlUniverse default defaultSpaceClass new identifiedBy: 'Bloc-Test'. BlUniverse default addNewSpace: testSpace. BlUniverse default switchToSpace: testSpace.
Cheers, Alex
On Sun, Feb 14, 2016 at 3:47 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
I always wanted to do this in Morphic, but it made too many assumptions about the World's environment e.g. use of globals like ActiveHand and World. I gave it a shot (see below). The new space did appear in the current world, but the rectangle seemed to open in the container world, not in the new world because when I closed the new space via the halo the rectangle remained. For me, it is very important to have a space easily create-able and drivable. This makes real testing possible, prevents another global mess, and makes other /really/ exciting possibilities within reach. Can it be done in Bloc? If not, what would it take?
s := BlBlocSpace new. root := s rootElement. root extent: 500 @ 500. root openInWorld; yourself. rect := BlElement exampleRectangle. rect openInWorld: root world. s redraw. root updateDrawing.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hello again Sean, looking at your codeâ¦now I think that Alex answer was the right one :) in fact one should be able to open a world in a world. one should be able to script a space, thus, one should be able to write a test with a local BlocSpace, adding elements into it and so on but your code does not make sense regarding how Bloc is designed you can have one and only one **active** BlocSpace at a time. imagine that a BlocSpace is a Pharo image. Making your code working would mean that we would be able to run a Pharo image within a Pharo image.
s := BlBlocSpace new.
ok
root := s rootElement. ok root extent: 500 @ 500. ok
root openInWorld; yourself.
this does not make sense for me
rect := BlElement exampleRectangle. rect openInWorld: root world.
this can make sense
s redraw. root updateDrawing.
this canot work also because only the current space can draw. ok, at least it means that we have to write good documentation about the bloc design. Cheers Alain
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (6)
-
Alain Plantec -
Aliaksei Syrel -
John Pfersich -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe