February 2016 - Pharo-users

Re: [Pharo-users] Bloc Space within a Space

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > looking at your codeâ¦now I think that Alex answer was the right one :) Hopefully I can convince you otherwise ;) Pharo Smalltalk Users mailing list wrote > in fact one should be able to open a world in a world. 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. Pharo Smalltalk Users mailing list wrote > 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 how to drive it? e.g. simulate events 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. 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 ----- 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.

Feb. 16, 2016

Re: [Pharo-users] Bloc Space within a Space

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > please do not ask too much... I can't help it! Pharo has spoiled me ha ha Pharo Smalltalk Users mailing list wrote > Reaching this state requires a huge amount of work but we are almost there > :) Thank you for all that work. It is exciting to hear that we are close to launch!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Space-within-a-Space-tp4877474p4877732.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 16, 2016

Re: [Pharo-users] Monticello reverse project dependency

by Werner Kassens

Hi Peter, have you looked at metacellos #includes: method? from https://code.google.com/archive/p/metacello/wikis/APIReference.wiki : "When 'Example-AddOn' is loaded, load 'Example-UI'" includes: #('Example-UI' ); werner On 02/13/2016 11:26 PM, Peter UhnÃ¡k wrote: > Hi, > > I have the following situation: > > I have ProjectMain, and ProjectPlugin, now normally the Plugin depends > on Main, however I would like to load Plugin as part of Main. > > The problem is that I can't specify to load Plugin after Main has been > already fully loaded, if I do something like this > > BaselineOfMain>>baseline: spec > <baseline> > spec > for: #common > do: > [ spec > baseline: 'Plugin' > with: [ spec > repository: '...'; > loads: #('default' OR 'plugin') ]. > spec > package: 'Main' with: [ spec requires: #(more stuff) ]; > spec group: 'default' with: #('Main'). > specgroup: 'complete' with: #('default' 'Plugin') ] > > The BaselineOfPlugin has two groupsâ¦ "default", which loads also "Main", > and "plugin", which doesn't. > > Now the problem is that there is no guaranteed way that Plugin will load > after Main (in fact the should happen). If I load the plugin's #default, > then Metacello ends up in an endless loop for some reason, and if I load > #plugin, then it will load it before the Main which will break it > (because Plugin has dependencies on main). > > So my question is: > is it possible to reverse it somehow? > Maybe add at the end `specpostLoadDoIt: #postLoadPlugins`, and then in > that method manually load the plugins with Metacello/Gofer? Or is there > a better way? > > Thanks, > Peter

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by Alain Plantec

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. >

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by Alain Plantec

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(a)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

Feb. 15, 2016

Re: [Pharo-users] Problem with gitfiletree in pharo 5

by Norbert Hartl

Thanks that works! Norbert > Am 15.02.2016 um 11:17 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi Norbert, > > yes, there is an issue with the OSProcess plugin on Mac which isn't solved yet. In the meantime, Mariano's OSSubprocess works and a version of GitFileTree with it is available this way: > > Metacello new > baseline: 'FileTree'; > repository: 'github://dalehenrich/filetree:issue_171/repository'; > load: 'Git' > > [1] http://forum.world.st/ANN-OSSubprocess-first-milestone-tp4871382p4871459.ht… > > Thierry > > Le 15/02/2016 10:56, Norbert Hartl a Ã©crit : >> Today I tried to use a pharo 5 image for my project. I installed gitfiletree but could not access my existing git repo I use with pharo 4. >> In >> >> MCFileTreeGitRepository>>#gitBranchs >> >> the output for the git command is an empty string while executing the same on the console gives me >> >> * master >> >> Is this a OSProcess problem? Where to look at to find the culprit? >> >> thanks, >> >> Norbert >> >> >> > >

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by John Pfersich

+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(a)stfx.eu> wrote: > > >> On 15 Feb 2016, at 10:27, stepharo <stepharo(a)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 ... > >

Feb. 15, 2016

Re: [Pharo-users] Problem with gitfiletree in pharo 5

by Thierry Goubier

Hi Norbert, yes, there is an issue with the OSProcess plugin on Mac which isn't solved yet. In the meantime, Mariano's OSSubprocess works and a version of GitFileTree with it is available this way: Metacello new baseline: 'FileTree'; repository: 'github://dalehenrich/filetree:issue_171/repository'; load: 'Git' [1] http://forum.world.st/ANN-OSSubprocess-first-milestone-tp4871382p4871459.ht… Thierry Le 15/02/2016 10:56, Norbert Hartl a Ã©crit : > Today I tried to use a pharo 5 image for my project. I installed gitfiletree but could not access my existing git repo I use with pharo 4. > In > > MCFileTreeGitRepository>>#gitBranchs > > the output for the git command is an empty string while executing the same on the console gives me > > * master > > Is this a OSProcess problem? Where to look at to find the culprit? > > thanks, > > Norbert > > >

Feb. 15, 2016

Problem with gitfiletree in pharo 5

by Norbert Hartl

Today I tried to use a pharo 5 image for my project. I installed gitfiletree but could not access my existing git repo I use with pharo 4. In MCFileTreeGitRepository>>#gitBranchs the output for the git command is an empty string while executing the same on the console gives me * master Is this a OSProcess problem? Where to look at to find the culprit? thanks, Norbert

Feb. 15, 2016

Re: [Pharo-users] Bloc Space within a Space

by Sven Van Caekenberghe

> On 15 Feb 2016, at 10:27, stepharo <stepharo(a)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 ...

Feb. 15, 2016