Bloc Space within a Space
Locked
 
Administrator
|
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 |
|
|
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 Why? You can create a separate 'Bloc-Test' space and do testing there. testSpace := BlUniverse default defaultSpaceClass new identifiedBy: 'Bloc-Test'. Cheers, Alex On Sun, Feb 14, 2016 at 3:47 PM, Sean P. DeNigris <[hidden email]> wrote: I always wanted to do this in Morphic, but it made too many assumptions about |
Re: Bloc Space within a Space
|
Administrator
|
That's where you're wrong ;-) That's exactly what I want to do! 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... 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. 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 |
|
|
In reply to this post by Aliaksei Syrel
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 :
|
|
|
In reply to this post by Sean P. DeNigris
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 |
Re: Bloc Space within a Space
|
|
> On 15 Feb 2016, at 10:27, stepharo <[hidden email]> 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 <[hidden email]> wrote: > > >> On 15 Feb 2016, at 10:27, stepharo <[hidden email]> 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 ... > > |
Re: Bloc Space within a Space
|
|
In reply to this post by Sean P. DeNigris
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 <[hidden email]> 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 |
Re: Bloc Space within a Space
|
|
In reply to this post by Sean P. DeNigris
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. > |
Re: Bloc Space within a Space
|
Administrator
|
In reply to this post by Pharo Smalltalk Users mailing list
I can't help it! Pharo has spoiled me ha ha Thank you for all that work. It is exciting to hear that we are close to launch!!
Cheers,
Sean |
Re: Bloc Space within a Space
|
Administrator
|
In reply to this post by Pharo Smalltalk Users mailing list
Hopefully I can convince you otherwise ;) That was always a wish of mine in Morphic, however in Bloc, the equivalent is a space, not a Bloc world. A Bloc world only holds the objects on the desktop, not the halos or hand. But how to drive it? e.g. simulate events I understand from a Pharo perspective that one is only expected to have one *real* space at a time which is receiving hardware events and such, but what prevents us from simulating Spaces?! If there is a SpaceElement, and Elements can be placed in the World, the principle of uniformity encourages that a SpaceElement can be placed there like any other. Exactly, like the VM simulator! Sign me up! This was the level of uniformity and explorability that I always wished in Morphic
Cheers,
Sean |
Re: Bloc Space within a Space
|
|
> > But how to drive it? e.g. simulate events ok, so we agree here. Bloc is done in that perspective. For now, you have to implement your own BlocSpace with an adequate #processEvents method, your can also implement your own main loop manager (polymorphic with BlMainLoopManager). > > > Pharo Smalltalk Users mailing list wrote >> but your code does not make sense regarding how Bloc is designed >> you can have one and only one **active** BlocSpace at a time. > > I understand from a Pharo perspective that one is only expected to have one > *real* space at a time which is receiving hardware events and such, but what > prevents us from simulating Spaces?! If there is a SpaceElement, and > Elements can be placed in the World, the principle of uniformity encourages > that a SpaceElement can be placed there like any other. yes, your right. I had that idea in mind. The only problem we have today is that the current implementation of damages repairing makes the assumption that a SpaceElement is at 0@0. (need to review BlSimpleRedrawer for that). > > > Pharo Smalltalk Users mailing list wrote >> 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. > > Exactly, like the VM simulator! Sign me up! This was the level of uniformity > and explorability that I always wished in Morphic. :) ok, so not infeasible but we are not there today. Do not forget that Bloc is currently implemented by a very small team. lets do it step by step. Cheers Alain > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877733.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
Re: Bloc Space within a Space
|
Administrator
|
Okay :) Thanks for thinking through this with me. I've had an idea for years which I'm very excited about that requires this functionality, and I've been waiting for a tool powerful and flexible enough to implement it! It looks like Bloc will be that tool and I'm happy to help and wait a bit longer...
Cheers,
Sean |
|
|
In reply to this post by John Pfersich
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 <[hidden email]> wrote: >> >> >>> On 15 Feb 2016, at 10:27, stepharo <[hidden email]> 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 ... >> >> > |
Re: Bloc Space within a Space
|
Administrator
|
In reply to this post by Pharo Smalltalk Users mailing list
Pharo Smalltalk Users mailing list wrote
>> But how to drive it? e.g. simulate events > > ok, so we agree here. Bloc is done in that perspective. > For now, you have to implement your own BlocSpace with an adequate > #processEvents method, > your can also implement your own main loop manager (polymorphic with > BlMainLoopManager). Given the flurry of Bloc development, are we able (or any closer) today to simulate a Bloc world/space/whatever-the-lingo-is, taking full control over the hand, events, etc? For years I've dreamed of being able to mock/stub out all the dependencies and have full control over a world within a world. There seemed to be agreement in principle, but it always seemed "just around the bend". I loaded Bloc in latest Pharo to play around, but am not quite sure if this is yet possible. Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
Re: Bloc Space within a Space
|
|
Hi sean
normally with bloc you should be able to build the expose mode on mac os X. with multiple little worlds showing windows inside and to control all the events. It was the goal of alain now I do not know but it should Stef BlUniverse I am the lowest level in Bloc. My responsibility is to manage the low-level services such as managing windows, event queue and the drawing synchronization. My main responsibility is to manage and to keep in sync the opened Spaces. I am the interface used to create/delete window. To achieve that, i use the notion of Host (see: BlHost). Users can choose a preferable host. In order to do that a universe must be stopped first. Example: universe stop. universe preferableHost: MyHost new. universe start. BLSpaceManager I am a Universe space manager. I contain Bloc spaces, can add or remove them. I am also responsible for sending pulses(tick) messages to spaces I know. I am used by Universe in order to provide support of multiple spaces within the Universe. - addSpace: add a space - removeSpace: remove a given space - clear close all spaces - pulse send pulse message to all spaces One simple example is simply gorgeous. Internal Representation and Key Implementation Points. Instance Variables spaces: <Object> Implementation Points On Sun, Sep 24, 2017 at 3:49 AM, Sean P. DeNigris <[hidden email]> wrote: > Pharo Smalltalk Users mailing list wrote >>> But how to drive it? e.g. simulate events >> >> ok, so we agree here. Bloc is done in that perspective. >> For now, you have to implement your own BlocSpace with an adequate >> #processEvents method, >> your can also implement your own main loop manager (polymorphic with >> BlMainLoopManager). > > Given the flurry of Bloc development, are we able (or any closer) today to > simulate a Bloc world/space/whatever-the-lingo-is, taking full control over > the hand, events, etc? For years I've dreamed of being able to mock/stub out > all the dependencies and have full control over a world within a world. > There seemed to be agreement in principle, but it always seemed "just around > the bend". I loaded Bloc in latest Pharo to play around, but am not quite > sure if this is yet possible. > > Thanks! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
Re: Bloc Space within a Space
|
Administrator
|
Stephane Ducasse-3 wrote
> with multiple little worlds showing windows inside and to control all > the events. That sounds awesome! Smalltalk is at heart a simulation bench and the inability to simulate the IDE itself has felt like heavy shackles when I tried to implement several possible-blue-plane ideas in the past. If we had a UI where we could sub out and control all the events/time/cursor, we would have something unimaginably cool :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Cheers,
Sean |
Re: Bloc Space within a Space
|
|
Start to play with Bloc. This is the moment to play and give feedback.
I will start around December/January. Stef On Tue, Sep 26, 2017 at 3:28 AM, Sean P. DeNigris <[hidden email]> wrote: > Stephane Ducasse-3 wrote >> with multiple little worlds showing windows inside and to control all >> the events. > > That sounds awesome! Smalltalk is at heart a simulation bench and the > inability to simulate the IDE itself has felt like heavy shackles when I > tried to implement several possible-blue-plane ideas in the past. If we had > a UI where we could sub out and control all the events/time/cursor, we would > have something unimaginably cool :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
|
|
In reply to this post by Stephane Ducasse-3
Hi,
Indeed, this was a focus since the very beginning. However, at present time, it is not possible to do it in practice out of the box and you cannot control the cursor either. This is something we still need to add, but it is definitely a top interest to get this working. Cheers, Doru > On Sep 24, 2017, at 9:33 AM, Stephane Ducasse <[hidden email]> wrote: > > Hi sean > > normally with bloc you should be able to build the expose mode on mac os X. > with multiple little worlds showing windows inside and to control all > the events. > It was the goal of alain now I do not know but it should > Stef > > BlUniverse > > I am the lowest level in Bloc. > My responsibility is to manage the low-level services such as managing > windows, event queue and the drawing synchronization. > > My main responsibility is to manage and to keep in sync the opened Spaces. > > I am the interface used to create/delete window. > To achieve that, i use the notion of Host (see: BlHost). > > Users can choose a preferable host. In order to do that a universe > must be stopped first. > Example: > > universe stop. > universe preferableHost: MyHost new. > universe start. > > BLSpaceManager > > I am a Universe space manager. > > I contain Bloc spaces, can add or remove them. I am also responsible > for sending pulses(tick) messages to spaces I know. > > I am used by Universe in order to provide support of multiple spaces > within the Universe. > > - addSpace: add a space > - removeSpace: remove a given space > - clear close all spaces > - pulse send pulse message to all spaces > > One simple example is simply gorgeous. > > Internal Representation and Key Implementation Points. > > Instance Variables > spaces: <Object> > > > Implementation Points > > > > On Sun, Sep 24, 2017 at 3:49 AM, Sean P. DeNigris <[hidden email]> wrote: >> Pharo Smalltalk Users mailing list wrote >>>> But how to drive it? e.g. simulate events >>> >>> ok, so we agree here. Bloc is done in that perspective. >>> For now, you have to implement your own BlocSpace with an adequate >>> #processEvents method, >>> your can also implement your own main loop manager (polymorphic with >>> BlMainLoopManager). >> >> Given the flurry of Bloc development, are we able (or any closer) today to >> simulate a Bloc world/space/whatever-the-lingo-is, taking full control over >> the hand, events, etc? For years I've dreamed of being able to mock/stub out >> all the dependencies and have full control over a world within a world. >> There seemed to be agreement in principle, but it always seemed "just around >> the bend". I loaded Bloc in latest Pharo to play around, but am not quite >> sure if this is yet possible. >> >> Thanks! >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > -- www.tudorgirba.com www.feenk.com “The smaller and more pervasive the hardware becomes, the more physical the software gets." |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |