- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Communicating Event Loops

by Igor Stasenko

On 3 February 2010 10:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I think that this would be the first mail to smalltalk-research > Err, what you mean? All i could say, that this scheme already discussed on squeak-dev couple of years ago... This is exactly the way where i think we should eventually go to. So what is new about it? > Begin forwarded message: > >> From: Tom Van Cutsem <tvcutsem(a)vub.ac.be> >> Date: February 3, 2010 5:13:00 AM GMT+01:00 >> To: SOFT members <soft(a)soft.vub.ac.be> >> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: Communicating Event Loops >> >> Hi, >> >> For those interested in concurrency control: last week I gave a presentation about AmbientTalk's concurrency model at a meeting for Javascript industry developers. The presentation was recorded, and if you're interested you can see it here: >> http://ssjs.pbworks.com/Communicating-Event-Loops >> >> (towards the end there is an interesting discussion about the pros and cons of Erlang-style vs AmbientTalk-style concurrency) >> >> Cheers, >> Tom > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 3, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

this loads well in the latest 1,1 core :) so now we should really have a look and these cool changes Stef On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: > SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: TestCase. > Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load.

Feb. 3, 2010

[Pharo-project] Final 1.0 Steps: list of actions performed in pharo 1.0

by stephane ducasse

Hi guys I added the list of actions we performed in pharo 1.0 http://code.google.com/p/pharo/wiki/ActionsInPharoOne?ts=1265189477&updated… We should move on and make that list shinning a bit. Then use the trick of miguel and get done So mike can you have a look at the english. Adrian can you do a pass on them. Stef

Feb. 3, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by StÃ©phane Ducasse

Hi henrik if you get a chance to have a look at the slice I uploaded it would be good. I like the idea that people have a look at other code, which is what we do when we integrate now for my own code I always feel nervous :) Stef On Feb 3, 2010, at 9:40 AM, Henrik Sperre Johansen wrote: > On 02.02.2010 23:06, John M McIntosh wrote: >> Ok, I can speak from experience that the file clean up logic does work in Squeak because in Sophie we would open 100's of files in a big project and we did discover a bug in >> the finalization logic that the FileStream uses to cleanup linkages after the copy of the object is made in the finalization logic. >> > I have seen no problems with finalization not working (eventually, which > I guess is what Bill alluded to). > I 100% agree with having it as standard for the common file handle > creation methods. > There are cases such as existsFile:, newFileNamed:do: and friends, etc., > where you only use a stream temporarily and can close it before the end > of the method's scope, not registering it in those cases does make a > difference. (Which is what the test was meant to show). > Whether it would actually be better to just not close it manually, and > wait for the finalization to do it instead, might be worth investigating. >> This was not the fault of how the finalization logic works, rather it was a bug in the user code. >> >> Now the reason for the finalization on streams is that in most/all? file systems system resources are a finite resource, (see denial of service attacks). Isn't it 1024 file handles in os-x? >> If you allocate a file,work with it, then GC the stream without closing then Squeak might be fine, but the actual operating system resource is dangling. >> >> So you need the finalization to cleanup, unless you can get the programmer always to promise to close the handle. Perhaps when an ensure:[] (always used everywhere?). >> However the model usually used is open the file, and sometime in the future close it via some other logic path we can't force fit the programmer into an ensure: [] pattern. >> >> So on a file handle open failure the code code runs a full GC because you could have the case where you have 900 handles allocated by GCed objects in OldSpace. Since >> object in Old Space could be dead, but not realized as dead yet a full gc is required to clean them up, which triggers the finalization, which frees the zombie handles. > In the example, the stream is closed manually by the old version of > RemoteString text. > Thus, no finalization really triggers in this case, but the close still > triggers a rehash of the weak FileRegistry on every close. >> >> >> This is not a fault of the finalization logic, it's to do with having multiple collectors and wanting to minimize the effort put into looking for dead objects, until we really really have to... >> >> So the logic on failure will trigger a full GC/finalization process, and then on the 2nd attempt if required fail because you've actually run into a system resource issue, or some other fatal file open error. >> >> >> I am wondering here if your benchmark results are clouded by having a fullGC run. I'd check fullGC count before/after to see how it's being changed. >> > > As stated above, the handles were closed manually, thus I'd wager the > finalization process never did get to run to clean them up. > Either way, as long as it consistently reproduces shorter runtimes, does > it really matter what the causes were? > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 3, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Sperre Johansen

On 02.02.2010 23:06, John M McIntosh wrote: > Ok, I can speak from experience that the file clean up logic does work in Squeak because in Sophie we would open 100's of files in a big project and we did discover a bug in > the finalization logic that the FileStream uses to cleanup linkages after the copy of the object is made in the finalization logic. > I have seen no problems with finalization not working (eventually, which I guess is what Bill alluded to). I 100% agree with having it as standard for the common file handle creation methods. There are cases such as existsFile:, newFileNamed:do: and friends, etc., where you only use a stream temporarily and can close it before the end of the method's scope, not registering it in those cases does make a difference. (Which is what the test was meant to show). Whether it would actually be better to just not close it manually, and wait for the finalization to do it instead, might be worth investigating. > This was not the fault of how the finalization logic works, rather it was a bug in the user code. > > Now the reason for the finalization on streams is that in most/all? file systems system resources are a finite resource, (see denial of service attacks). Isn't it 1024 file handles in os-x? > If you allocate a file,work with it, then GC the stream without closing then Squeak might be fine, but the actual operating system resource is dangling. > > So you need the finalization to cleanup, unless you can get the programmer always to promise to close the handle. Perhaps when an ensure:[] (always used everywhere?). > However the model usually used is open the file, and sometime in the future close it via some other logic path we can't force fit the programmer into an ensure: [] pattern. > > So on a file handle open failure the code code runs a full GC because you could have the case where you have 900 handles allocated by GCed objects in OldSpace. Since > object in Old Space could be dead, but not realized as dead yet a full gc is required to clean them up, which triggers the finalization, which frees the zombie handles. In the example, the stream is closed manually by the old version of RemoteString text. Thus, no finalization really triggers in this case, but the close still triggers a rehash of the weak FileRegistry on every close. > > > This is not a fault of the finalization logic, it's to do with having multiple collectors and wanting to minimize the effort put into looking for dead objects, until we really really have to... > > So the logic on failure will trigger a full GC/finalization process, and then on the 2nd attempt if required fail because you've actually run into a system resource issue, or some other fatal file open error. > > > I am wondering here if your benchmark results are clouded by having a fullGC run. I'd check fullGC count before/after to see how it's being changed. > As stated above, the handles were closed manually, thus I'd wager the finalization process never did get to run to clean them up. Either way, as long as it consistently reproduces shorter runtimes, does it really matter what the causes were? Cheers, Henry

Feb. 3, 2010

[Pharo-project] Fwd: Communicating Event Loops

by StÃ©phane Ducasse

I think that this would be the first mail to smalltalk-research Begin forwarded message: > From: Tom Van Cutsem <tvcutsem(a)vub.ac.be> > Date: February 3, 2010 5:13:00 AM GMT+01:00 > To: SOFT members <soft(a)soft.vub.ac.be> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Communicating Event Loops > > Hi, > > For those interested in concurrency control: last week I gave a presentation about AmbientTalk's concurrency model at a meeting for Javascript industry developers. The presentation was recorded, and if you're interested you can see it here: > http://ssjs.pbworks.com/Communicating-Event-Loops > > (towards the end there is an interesting discussion about the pros and cons of Erlang-style vs AmbientTalk-style concurrency) > > Cheers, > Tom

Feb. 3, 2010

Re: [Pharo-project] Questions about ToolSet

by Tudor Girba

Hi, I think that introducing more global state is not a good idea. I believe a cleaner solution would be to create have ToolSet default return an instance of a ToolSetImplementation, and then create a instance variables in the ToolSetImplementation for these tools and let me customize it from outside. Like this you do not create unnecessary global state. Cheers, Doru On 3 Feb 2010, at 09:11, George Herolyants wrote: > Hi, Mariano > > I also confronted this problem when I was writing some extension of > NewInspector. And I agree, the current process of registering of new > tools is ugly. I solved the problem with writing some code, which > created an anonymous class which merged behaviour of all the tool sets > passed to it as arguments and installed this class as default tool > set. Tricky way, but it worked, IIRC :). > > But I think there should be cleaner way. Maybe something similar to > what you propose, but without introducing new names in the global > namespace. Maybe we can do define all those tool classes as class > variables and define a protocol in ToolSet or StandardToolSet to > install (and maybe even use new settings framework to do it)? > > What do you think? > > George > > 2010/2/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi folks. I found I big problem with the way ToolSet works or at >> least with >> the way I think it works. Right now, there is the class ToolSet with >> certain methods like API and then a class side method to register a >> XXX >> ToolSet as default. So, we have for example, the StandardToolSet >> which >> implements/overrides some of the methods of ToolSet. Of course, >> that ToolSet >> (StandardToolSet) is the default. Evaluate ToolSet default and you >> will get >> that one. Becuase that is done is StandardToolSet class >> initialize >> >> Now...the first question, why StandardToolSet doesn't extend from >> ToolSet >> ? shouldn't that be better ? >> >> Anyway, this is the big problem. The only way right now to change the >> toolset is to create a new class and register it. Suppose I want to >> install >> NewInspector and put in the ToolSet that now, the inspector to use is >> NewInspector instead of old Inspector. The only way I see right now >> is to >> create new class and implement the method inspectorClassOf: As >> you can >> see, NewInspector had to do that in class NewInspectorToolSet. They >> had to >> create that class just to implement that method and register it... >> >> Now, suppose I want to install shout, and I want to say that the >> default >> workspace is SHWorkspace (shout one), not the normal one. >> Ok...easy, I do >> the same of the NewInspector (but changing the method openWorkspace >> instead >> of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I >> have or >> NewInspectorToolSet or ShoutToolSet. Of course, this has no sense >> AT ALL. >> >> So, my proposal is to change ToolSet, so that any tool can change >> certain >> things, without needing to do that. Examples: >> >> For example, in StandardToolSet, we have: >> >> StandardToolSet >> openWorkspace >> Workspace open >> >> I would change that for something like: >> >> >> StandardToolSet >> openWorkspace >> (Smalltalk at: #WorkspaceClassName) open >> >> Of course Smalltalk at: #WorkspaceClassName must be initialized >> the first >> time with something like Smalltalk at: #WorkspaceClassName put: >> Workspace >> >> I don't like the name WorkspaceClassName, we should look for better >> names. >> >> Then, I can just have a post do it when loading Shout that evaluates: >> >> (Smalltalk at: #WorkspaceClassName put: SHWorkspace) >> >> Here there is no need to create subclasses neither to register a new >> toolset. >> >> Ok...this is an example, but the idea is to apply this to most cases. >> >> What do you think ? >> >> Mariano >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Feb. 3, 2010

Re: [Pharo-project] Questions about ToolSet

by George Herolyants

Hi, Mariano I also confronted this problem when I was writing some extension of NewInspector. And I agree, the current process of registering of new tools is ugly. I solved the problem with writing some code, which created an anonymous class which merged behaviour of all the tool sets passed to it as arguments and installed this class as default tool set. Tricky way, but it worked, IIRC :). But I think there should be cleaner way. Maybe something similar to what you propose, but without introducing new names in the global namespace. Maybe we can do define all those tool classes as class variables and define a protocol in ToolSet or StandardToolSet to install (and maybe even use new settings framework to do it)? What do you think? George 2010/2/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi folks. I found I big problem with the way ToolSet works or at least with > the way I think it works.Â Right now, there is the class ToolSet with > certain methods like API and then a class side method to register a XXX > ToolSet as default.Â So, we have for example, the StandardToolSet which > implements/overrides some of the methods of ToolSet. Of course, that ToolSet > (StandardToolSet) is the default. Evaluate ToolSet default and you will get > that one. Becuase that is done is StandardToolSet class >> initialize > > Now...the first question,Â whyÂ StandardToolSet doesn't extend from ToolSet > ? shouldn't that be better ? > > Anyway, this is the big problem. The only way right now to change the > toolset is to create a new class and register it. Suppose I want to install > NewInspector and put in the ToolSet that now, the inspector to use is > NewInspector instead of old Inspector. The only way I see right now is to > createÂ new class and implement the method inspectorClassOf:Â As you can > see, NewInspector had to do that in class NewInspectorToolSet. They had to > create that class just to implement that method and register it... > > Now, suppose I want to install shout, and I want to say that the default > workspace is SHWorkspace (shout one), not the normal one. Ok...easy, I do > the same of the NewInspector (but changing the method openWorkspace instead > of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I have or > NewInspectorToolSet or ShoutToolSet. Of course, this has no sense AT ALL. > > So, my proposal is to change ToolSet, so that any tool can change certain > things, without needing to do that. Examples: > > For example, in StandardToolSet, we have: > > StandardToolSet >> openWorkspace > Â Â Â Workspace open > > I would change that for something like: > > > StandardToolSet >> openWorkspace > Â Â Â (Smalltalk at: #WorkspaceClassName) open > > Of course Smalltalk at: #WorkspaceClassNameÂ must be initialized the first > time with something like Smalltalk at: #WorkspaceClassName put: Workspace > > I don't like the name WorkspaceClassName, we should look for better names. > > Then, I can just have a post do it when loading Shout that evaluates: > > (Smalltalk at: #WorkspaceClassName put: SHWorkspace) > > Here there is no need to create subclasses neither to register a new > toolset. > > Ok...this is an example, but the idea is to apply this to most cases. > > What do you think ? > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 3, 2010

Re: [Pharo-project] Questions about ToolSet

by Schwab,Wilhelm K

As long as you make it no harder for me to use the old inspector, I'm open to just about anything. No arguement that toolsets in their current form are strange. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Tuesday, February 02, 2010 6:00 PM To: Pharo Development Subject: [Pharo-project] Questions about ToolSet Hi folks. I found I big problem with the way ToolSet works or at least with the way I think it works. Right now, there is the class ToolSet with certain methods like API and then a class side method to register a XXX ToolSet as default. So, we have for example, the StandardToolSet which implements/overrides some of the methods of ToolSet. Of course, that ToolSet (StandardToolSet) is the default. Evaluate ToolSet default and you will get that one. Becuase that is done is StandardToolSet class >> initialize Now...the first question, why StandardToolSet doesn't extend from ToolSet ? shouldn't that be better ? Anyway, this is the big problem. The only way right now to change the toolset is to create a new class and register it. Suppose I want to install NewInspector and put in the ToolSet that now, the inspector to use is NewInspector instead of old Inspector. The only way I see right now is to create new class and implement the method inspectorClassOf: As you can see, NewInspector had to do that in class NewInspectorToolSet. They had to create that class just to implement that method and register it... Now, suppose I want to install shout, and I want to say that the default workspace is SHWorkspace (shout one), not the normal one. Ok...easy, I do the same of the NewInspector (but changing the method openWorkspace instead of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I have or NewInspectorToolSet or ShoutToolSet. Of course, this has no sense AT ALL. So, my proposal is to change ToolSet, so that any tool can change certain things, without needing to do that. Examples: For example, in StandardToolSet, we have: StandardToolSet >> openWorkspace Workspace open I would change that for something like: StandardToolSet >> openWorkspace (Smalltalk at: #WorkspaceClassName) open Of course Smalltalk at: #WorkspaceClassName must be initialized the first time with something like Smalltalk at: #WorkspaceClassName put: Workspace I don't like the name WorkspaceClassName, we should look for better names. Then, I can just have a post do it when loading Shout that evaluates: (Smalltalk at: #WorkspaceClassName put: SHWorkspace) Here there is no need to create subclasses neither to register a new toolset. Ok...this is an example, but the idea is to apply this to most cases. What do you think ? Mariano

Feb. 3, 2010

[Pharo-project] Questions about ToolSet

by Mariano Martinez Peck

Hi folks. I found I big problem with the way ToolSet works or at least with the way I think it works. Right now, there is the class ToolSet with certain methods like API and then a class side method to register a XXX ToolSet as default. So, we have for example, the StandardToolSet which implements/overrides some of the methods of ToolSet. Of course, that ToolSet (StandardToolSet) is the default. Evaluate ToolSet default and you will get that one. Becuase that is done is StandardToolSet class >> initialize Now...the first question, why StandardToolSet doesn't extend from ToolSet ? shouldn't that be better ? Anyway, this is the big problem. The only way right now to change the toolset is to create a new class and register it. Suppose I want to install NewInspector and put in the ToolSet that now, the inspector to use is NewInspector instead of old Inspector. The only way I see right now is to create new class and implement the method inspectorClassOf: As you can see, NewInspector had to do that in class NewInspectorToolSet. They had to create that class just to implement that method and register it... Now, suppose I want to install shout, and I want to say that the default workspace is SHWorkspace (shout one), not the normal one. Ok...easy, I do the same of the NewInspector (but changing the method openWorkspace instead of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I have or NewInspectorToolSet or ShoutToolSet. Of course, this has no sense AT ALL. So, my proposal is to change ToolSet, so that any tool can change certain things, without needing to do that. Examples: For example, in StandardToolSet, we have: StandardToolSet >> openWorkspace Workspace open I would change that for something like: StandardToolSet >> openWorkspace (Smalltalk at: #WorkspaceClassName) open Of course Smalltalk at: #WorkspaceClassName must be initialized the first time with something like Smalltalk at: #WorkspaceClassName put: Workspace I don't like the name WorkspaceClassName, we should look for better names. Then, I can just have a post do it when loading Shout that evaluates: (Smalltalk at: #WorkspaceClassName put: SHWorkspace) Here there is no need to create subclasses neither to register a new toolset. Ok...this is an example, but the idea is to apply this to most cases. What do you think ? Mariano

Feb. 2, 2010