Re: [Pharo-project] Questions about ToolSet
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 marianop...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about ToolSet
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 marianop...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fwd: Communicating Event Loops
I think that this would be the first mail to smalltalk-research Begin forwarded message: From: Tom Van Cutsem tvcut...@vub.ac.be Date: February 3, 2010 5:13:00 AM GMT+01:00 To: SOFT members s...@soft.vub.ac.be Cc: Stéphane Ducasse stephane.duca...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] readOnlyFileNamed:do: vs. ...
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] readOnlyFileNamed:do: vs. ...
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Final 1.0 Steps: list of actions performed in pharo 1.0
Hi guys I added the list of actions we performed in pharo 1.0 http://code.google.com/p/pharo/wiki/ActionsInPharoOne?ts=1265189477updated=ActionsInPharoOne 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] akuhn/SUnit: run faster tests first step through tests
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Communicating Event Loops
On 3 February 2010 10:33, Stéphane Ducasse stephane.duca...@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 tvcut...@vub.ac.be Date: February 3, 2010 5:13:00 AM GMT+01:00 To: SOFT members s...@soft.vub.ac.be Cc: Stéphane Ducasse stephane.duca...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Communicating Event Loops
On Feb 3, 2010, at 12:34 PM, Igor Stasenko wrote: On 3 February 2010 10:33, Stéphane Ducasse stephane.duca...@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? Do we request that only new things are discussed on Smalltalk-research? LOOM is very old, too... in general, there is a lot of wisdom espececially in old papers. Partly because it was possible to publish easily cool ideas without having to have every open question already answered. ... the good old days :-) The problem is that if new people start, they have to read old papers. Else how can they learn? There are even things that experienced people don't know. For example, because they did not do research in this direction in the past. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] What about a real research group (was: Do you want to discuss about papers?)
I'm ok for such a list... Nevertheless, I'm wondering if we could go a bit further by doing a kind of research group with a proper web site listing all people involved and the projects there're working on. We could then establish some categories and eventually sub-groups. List all published papers, gives ressources to people... We could also have a workshop every year (in ESUG or eventually independantly). More importantly than discussions on papers, I think we need to characterise people and their expertise area... For instance, I'm interested in some areas that are not really focussed in Computer Science problematics (new compiler, traits, etc...). To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. Here are some areas I'm working on: -Case Based Reasoning - essentially similarity measure with uncertainty -Constraint Satisfaction Programming (more interested in open models) and especially the coupling between CBR and CSP -NARS, a kind of General AI (logical stuff) -Dynamic open models in general - Coevolution of model and their instances (something I'd really like to dig into) -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (- so as to model expert information) - I would like to apply that to poker game in the future :) - This is maybe the central aspect of my work Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. What others think ? Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Communicating Event Loops
Igor You know Concurrent Smalltalk was certainly like that too. Now my point is that this is good to share ideas that there are old or not. Already discussed or not. For example I would like to see the cost of it at the level of the GC. Stef Begin forwarded message: From: Tom Van Cutsem tvcut...@vub.ac.be Date: February 3, 2010 5:13:00 AM GMT+01:00 To: SOFT members s...@soft.vub.ac.be Cc: Stéphane Ducasse stephane.duca...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about a real research group (was: Do you want to discuss about papers?)
On Feb 3, 2010, at 1:18 PM, Cédrick Béler wrote: I'm ok for such a list... Nevertheless, I'm wondering if we could go a bit further by doing a kind of research group with a proper web site listing all people involved and the projects there're working on. We could then establish some categories and eventually sub-groups. List all published papers, gives ressources to people... We could also have a workshop every year (in ESUG or eventually independantly). More importantly than discussions on papers, I think we need to characterise people and their expertise area... For instance, I'm interested in some areas that are not really focussed in Computer Science problematics (new compiler, traits, etc...). To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. Here are some areas I'm working on: -Case Based Reasoning - essentially similarity measure with uncertainty -Constraint Satisfaction Programming (more interested in open models) and especially the coupling between CBR and CSP -NARS, a kind of General AI (logical stuff) -Dynamic open models in general - Coevolution of model and their instances (something I'd really like to dig into) -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (- so as to model expert information) - I would like to apply that to poker game in the future :) - This is maybe the central aspect of my work I would really like to see how we can map that to do software analysis Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. for the moment having it low profile is also a good way. What others think ? Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. Yes something like lambda the ultimate Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about a real research group (was: Do you want to discuss about papers?)
Cédrick: I like the idea, however, I think your idea may be a consequence of my idea. You can do all steps at the same time, but I rather go step by step. We first create the list, we create a group, we join people, we discuss, we learn, and after that, eventually it will naturally arrive a moment where we want to have our own real group. So...I will create the list right now :) Mariano 2010/2/3 Cédrick Béler cdric...@gmail.com I'm ok for such a list... Nevertheless, I'm wondering if we could go a bit further by doing a kind of research group with a proper web site listing all people involved and the projects there're working on. We could then establish some categories and eventually sub-groups. List all published papers, gives ressources to people... We could also have a workshop every year (in ESUG or eventually independantly). More importantly than discussions on papers, I think we need to characterise people and their expertise area... For instance, I'm interested in some areas that are not really focussed in Computer Science problematics (new compiler, traits, etc...). To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. Here are some areas I'm working on: -Case Based Reasoning - essentially similarity measure with uncertainty -Constraint Satisfaction Programming (more interested in open models) and especially the coupling between CBR and CSP -NARS, a kind of General AI (logical stuff) -Dynamic open models in general - Coevolution of model and their instances (something I'd really like to dig into) -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (- so as to model expert information) - I would like to apply that to poker game in the future :) - This is maybe the central aspect of my work Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. What others think ? Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about a real research group (was: Do you want to discuss about papers?)
Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. for the moment having it low profile is also a good way. What do you mean by low-profile... only a mailing-list ? or a small site with minimum information and link to personnal web sites ? What others think ? Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. Yes something like lambda the ultimate :) I would nevertheless choose a name with smalltalk and research or academic keywords for visibility purpose :) Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about ToolSet
On Wed, Feb 3, 2010 at 9:29 AM, Tudor Girba tudor.gi...@gmail.com wrote: 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 and accessors :) . Like this you do not create unnecessary global state. Thanks Doru!!! I like much more my suggestion. Actually it was just what I come to mind at that time. The real purpose was to see if other people agree there is a problem in ToolSet. Thanks! I created the issue http://code.google.com/p/pharo/issues/detail?id=1915 Now, when someone have time, can hack there :) 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 marianop...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
[Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller asquea...@gmail.com wrote: 4) I have refactored DirectoryEntry to no longer inherit from ArrayedCollection. Is this an improvement with any community interest? Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? Kind regards, Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
On Feb 3, 2010, at 4:43 PM, Mariano Martinez Peck wrote: On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller asquea...@gmail.com wrote: 4) I have refactored DirectoryEntry to no longer inherit from ArrayedCollection. Is this an improvement with any community interest? Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? You should never inherit from collections. The problem is that with this, you are depending on the internal working of the collection. Especially objects that model a domain object (like a Directory related thing) should *never* inherit from a collection. Only if you need a special *kind* of collection (technically), it might be interesting to do a subclass of a collection (see MethodDictionary). If you need a collection, you *use* a collection. (you put a standard collection as an instance var). It's very tempting to use inheritance to aquire behavior. But in most cases, it is wrong to use it. You can see this abuse of inheritance very often in Squeak... e.g. Scanner is the superclass of Parser, there are subclasses of SystemWindow (!!), things like that. Bad. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
Extendability, correctness of semantics, and correctness of implementation. Inheritance should adhere to an is-a relationship; because it reflects a specialization of the superclass. A DirectoryEntry is definitely not a Collection.. Regards, Chris 2010/2/3 Mariano Martinez Peck marianop...@gmail.com: On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller asquea...@gmail.com wrote: 4) I have refactored DirectoryEntry to no longer inherit from ArrayedCollection. Is this an improvement with any community interest? Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? Kind regards, Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
On Wed, Feb 3, 2010 at 4:55 PM, Chris Muller asquea...@gmail.com wrote: Extendability, correctness of semantics, and correctness of implementation. Inheritance should adhere to an is-a relationship; because it reflects a specialization of the superclass. A DirectoryEntry is definitely not a Collection.. Ahhh I didn't know you were here Chris :) This is cool. Thanks for the explanations. My question was exactly because it come to my mind the example of the MethodDictionary or the one I saw yesterday in VMMaker (Interpreter extends from ObjectMemory). Then yes, we are interested Chris :) I created the issue: http://code.google.com/p/pharo/issues/detail?id=1916 If you can submit the changes, would be really cool. The instructions to do that are here: http://code.google.com/p/pharo/wiki/HowToContribute As far as it is published, it will be integrated in Pharo 1.1. Thank you very much. Mariano Regards, Chris 2010/2/3 Mariano Martinez Peck marianop...@gmail.com: On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller asquea...@gmail.com wrote: 4) I have refactored DirectoryEntry to no longer inherit from ArrayedCollection. Is this an improvement with any community interest? Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? Kind regards, Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
Marcus, Rats :) You've stolen my thunder. Actually, I won't go as far as to say never, but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. In fairness, it might have been intended to minimize the chance of runtime errors. Think about it: by wrongly inheriting from OrderedCollection, one is freed from having to delegate its methods (it's not correct, but can seem wise to a beginner or expedient an experienced programmer with poor tools). Mess around with the internals of the user interface, and sliding a method up the hierarchy can avoid a meltdown. These things were all the more true before the days of exception handling. By all means, we should fix these things as we find them. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Wednesday, February 03, 2010 10:53 AM To: Pharo-project@lists.gforge.inria.fr Cc: Laval Jannik Subject: Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions On Feb 3, 2010, at 4:43 PM, Mariano Martinez Peck wrote: On Wed, Feb 3, 2010 at 4:34 PM, Chris Muller asquea...@gmail.com wrote: 4) I have refactored DirectoryEntry to no longer inherit from ArrayedCollection. Is this an improvement with any community interest? Do you think this is interesting ? What are the benefits of such change ? Jannik: do we kill a cycle dependency or something with this change ? You should never inherit from collections. The problem is that with this, you are depending on the internal working of the collection. Especially objects that model a domain object (like a Directory related thing) should *never* inherit from a collection. Only if you need a special *kind* of collection (technically), it might be interesting to do a subclass of a collection (see MethodDictionary). If you need a collection, you *use* a collection. (you put a standard collection as an instance var). It's very tempting to use inheritance to aquire behavior. But in most cases, it is wrong to use it. You can see this abuse of inheritance very often in Squeak... e.g. Scanner is the superclass of Parser, there are subclasses of SystemWindow (!!), things like that. Bad. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
On Feb 3, 2010, at 5:03 PM, Schwab,Wilhelm K wrote: Marcus, Rats :) You've stolen my thunder. Actually, I won't go as far as to say never, but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. And partly, this was because it was done a very long time ago... back than, it was not known how to program with this newly invented object things. Even by the people who invented it! It's often that others, who than use it, learn how to use it better than the creators. The same will happen with everything we will invent (if we invent anything, that is :-) ). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
On 3 February 2010 18:12, Marcus Denker marcus.den...@inria.fr wrote: On Feb 3, 2010, at 5:03 PM, Schwab,Wilhelm K wrote: Marcus, Rats :) You've stolen my thunder. Actually, I won't go as far as to say never, but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. And partly, this was because it was done a very long time ago... back than, it was not known how to program with this newly invented object things. Even by the people who invented it! It's often that others, who than use it, learn how to use it better than the creators. The same will happen with everything we will invent (if we invent anything, that is :-) ). +100 the good thing is, that we're free to change this. While java people got stuck with sealed stuff forever :) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Fwd: Communicating Event Loops
Igor You know Concurrent Smalltalk was certainly like that too. Now my point is that this is good to share ideas that there are old or not. Already discussed or not. Yes, that's why i asked , because i didn't understood your message. So I repeat it. Right now on my desktop when I open any Smalltalk I still have some old ideas moving inside. And we would like to create a different world in which even old ideas that were discussed long time ago but never arrived to my current desktop could be discussed. If we want people to invent the future, they should at least know the past and gets also ideas from others. For example I would like to see the cost of it at the level of the GC. The main problem here, as also mentioned in discussion, is how GC should deal with far references, i.e. how to determine correctly when object which is referenced by some far ref become garbage. May be a lifecycle like in Corba solution is needed at the level of each vat. As for the rest of it, its not any different from usual approach: GC could sweep a single vat space at any moment it wants, regardless of what other vats currently doing. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Questions about ToolSet
On Feb 3, 2010, at 12:00 AM, Mariano Martinez Peck wrote: 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 ? Apparently what you want is a kind of factory ToolSet is a facade StandardToolSet is an adaptor making the glue between the protocol of ToolSet and the actual tools. So delegation is not that bad. now by adding a inheritance relationship we could reuse default code when possible. inspectorClassOf: anObject Answer the inspector class for the given object. The tool set must know which inspector type to use for which object - the object cannot possibly know what kind of inspectors the toolset provides. self default ifNil:[^nil]. ^self default inspectorClassOf: anObject the self default ifNil: [^nil] looks also suspicious. 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) I like the suggestion of doru. ToolSet should have a way to registering new tools to specific protocol and that you can access and change a given set. One of the problem is that it can be easy if all the tools kind (all debuggers) agree to follow the same interface to get opened Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions
Very true! -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Wednesday, February 03, 2010 11:13 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] DirectoryEntry does not inherit from ArrayedCollection [WAS] Re: [squeak-dev] 3.11 questions On Feb 3, 2010, at 5:03 PM, Schwab,Wilhelm K wrote: Marcus, Rats :) You've stolen my thunder. Actually, I won't go as far as to say never, but I agree. There are places in Squeak that inherit from collections or put methods in Object, and it sure looks as though the programmer didn't know any better. And partly, this was because it was done a very long time ago... back than, it was not known how to program with this newly invented object things. Even by the people who invented it! It's often that others, who than use it, learn how to use it better than the creators. The same will happen with everything we will invent (if we invent anything, that is :-) ). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Final 1.0 Steps: list of actions performed in pharo 1.0
;-) ok i have done some edits. You can look at the diffs in the source/svn view (it took me a while to find that feature). Let me know what you think. I have left some editorlal notes [ed: ] where I need some clarification. Obviously it's just my 2p on things... cheers, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Final 1.0 Steps: list of actions performed in pharo 1.0
2010/2/4 Michael Roberts m...@mjr104.co.uk: ;-) ok i have done some edits. You can look at the diffs in the source/svn view (it took me a while to find that feature). Let me know what you Humm cool, i was not aware of this feature ;-) -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in PharoCore1.1ALPHA [Latest update: #11192]
Thanks! Indeed there were some work on UTF8Encoder and friends. do you know if the same happened in latest squeak? On Feb 3, 2010, at 10:57 PM, Yanni Chiu wrote: When attempting to load Seaside-2.8, with the image updated to 11192, I got: UndefinedObject(Object)doesNotUnderstand: #do: WriteStream(Stream)nextPutAll: WriteStreamnextPutAll: WriteStream(Stream)basicNextPutAll: UTF8TextConverter(TextConverter)nextPutAll:toStream: ByteString(String)convertToWithConverter: WAKomEncoded39 classsetUpConversionTables WAKomEncoded39 classinitialize It actually gave me an emergency evaluator, and failed to save the entire stack trace to PharoDebug.log - maybe due to UTF8 issues. I had to use the send bug report feature to capture the stack trace. I think the problem is that WAKomEncoded39 is setting things up for codepoints 0..255, but the newly optimized UTF8TextConverter has nil entries for codepoints less than 128. -- Yanni VM: Mac OS - intel - 1058 - Squeak3.8.1 of '28 Aug 2006' [latest update: #6747] Squeak VM 4.2.1b1 Image: PharoCore1.1ALPHA [Latest update: #11192] --- The full stack --- UndefinedObject(Object)doesNotUnderstand: #do: WriteStream(Stream)nextPutAll: WriteStreamnextPutAll: WriteStream(Stream)basicNextPutAll: UTF8TextConverter(TextConverter)nextPutAll:toStream: ByteString(String)convertToWithConverter: WAKomEncoded39 classsetUpConversionTables WAKomEncoded39 classinitialize MCMethodDefinitionpostloadOver: [] in [] in [] in MCPackageLoaderbasicLoad [] in [] in OrderedCollection(SequenceableCollection)do:displayingProgress: OrderedCollection(SequenceableCollection)withIndexDo: [] in OrderedCollection(SequenceableCollection)do:displayingProgress: [] in ProgressInitiationExceptiondefaultAction BlockClosureensure: ProgressInitiationExceptiondefaultAction UndefinedObjecthandleSignal: MethodContext(ContextPart)handleSignal: MethodContext(ContextPart)handleSignal: MethodContext(ContextPart)handleSignal: MethodContext(ContextPart)handleSignal: ProgressInitiationException(Exception)signal ProgressInitiationExceptiondisplay:at:from:to:during: ProgressInitiationException classdisplay:at:from:to:during: ByteString(String)displayProgressAt:from:to:during: OrderedCollection(SequenceableCollection)do:displayingProgress: [] in [] in MCPackageLoaderbasicLoad BlockClosureon:do: [] in MCPackageLoaderbasicLoad BlockClosureensure: MCPackageLoaderbasicLoad [] in MCPackageLoaderloadWithNameLike: [] in MCPackageLoaderuseChangeSetNamed:during: BlockClosureensure: MCPackageLoaderuseChangeSetNamed:during: MCPackageLoaderuseNewChangeSetNamedLike:during: MCPackageLoaderloadWithNameLike: MCVersionLoaderloadWithNameLike: MCVersionLoaderload - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GoferLoadexecute Goferexecute:do: Goferexecute: Goferload [] in UndefinedObjectDoIt [] in BlockClosurevalueSupplyingAnswers: BlockClosureon:do: BlockClosurevalueSupplyingAnswers: UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: [] in [] in MultiByteFileStream(PositionableStream)fileInAnnouncing: BlockClosureon:do: [] in MultiByteFileStream(PositionableStream)fileInAnnouncing: [] in ProgressInitiationExceptiondefaultAction BlockClosureensure: ProgressInitiationExceptiondefaultAction UndefinedObjecthandleSignal: MethodContext(ContextPart)handleSignal: ProgressInitiationException(Exception)signal ProgressInitiationExceptiondisplay:at:from:to:during: ProgressInitiationException classdisplay:at:from:to:during: ByteString(String)displayProgressAt:from:to:during: MultiByteFileStream(PositionableStream)fileInAnnouncing: MultiByteFileStream(FileStream)fileIn MultiByteFileStreamfileIn FileStream classfileIn: SimpleServiceEntryperformServiceFor: [] in ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent: BlockClosureensure: CursorWithMask(Cursor)showWhile: ToggleMenuItemMorph(MenuItemMorph)invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)mouseUp: ToggleMenuItemMorph(MenuItemMorph)handleMouseUp: MouseButtonEventsentTo: ToggleMenuItemMorph(Morph)handleEvent: MorphicEventDispatcherdispatchDefault:with: MorphicEventDispatcherdispatchEvent:with: ToggleMenuItemMorph(Morph)processEvent:using: MorphicEventDispatcherdispatchDefault:with: MorphicEventDispatcherdispatchEvent:with: MenuMorph(Morph)processEvent:using: MenuMorph(Morph)processEvent: MenuMorphhandleFocusEvent: [] in HandMorphsendFocusEvent:to:clear: [] in PasteUpMorphbecomeActiveDuring: BlockClosureon:do: PasteUpMorphbecomeActiveDuring: HandMorphsendFocusEvent:to:clear: HandMorphsendEvent:focus:clear: HandMorphsendMouseEvent: HandMorphhandleEvent: HandMorphprocessEvents [] in WorldStatedoOneCycleNowFor: Array(SequenceableCollection)do: WorldStatehandsDo: WorldStatedoOneCycleNowFor:
[Pharo-project] Newbie question deploying smalltalk applications
I created a CRC calculating algorithm and I want to be able to deploy my application for other people to use. I am not sure how to package an image so that it is user friendly. Any help would be nice. Thanks ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Newbie question deploying smalltalk applications
2010/2/4 Nathan Tuttle nathan.tut...@gmail.com I created a CRC calculating algorithm and I want to be able to deploy my application for other people to use. I am not sure how to package an image so that it is user friendly. Hi Nathan! First of all, thanks for asking how to share something :) OpenSource code is always welcome. So, the first question is, where do you have that code? just in your image? What you can do, first is to create a Monticello project in www.squeaksource.com. That's a Monticello server where people can create projects, commit, merge, etc. It is a control version system (sorry if you already know all this). So, the first step is to create a project there and then, from you image, you commit your code there. Then, people will be able to download it or even commit (depending on the settings you choose). In a second step, further, you can create a Metacello configuration for you project. This will let you have stable versions of your projects, manage dependencies between packages, etc. But I would start just with the first step. I REALLY recommend you to read Pharo By Example book. It is free and very good: http://www.pharobyexample.org/ You can download it in pdf. There, it is a complete chapter for Monticello. Read that :) Cheers Mariano Any help would be nice. Thanks ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bug in PharoCore1.1ALPHA [Latest update: #11192]
Stéphane Ducasse wrote: Thanks! Indeed there were some work on UTF8Encoder and friends. do you know if the same happened in latest squeak? I've not tried it on a recent Squeak. On Feb 3, 2010, at 10:57 PM, Yanni Chiu wrote: When attempting to load Seaside-2.8, with the image updated to 11192, I got: UndefinedObject(Object)doesNotUnderstand: #do: WriteStream(Stream)nextPutAll: WriteStreamnextPutAll: WriteStream(Stream)basicNextPutAll: UTF8TextConverter(TextConverter)nextPutAll:toStream: ByteString(String)convertToWithConverter: WAKomEncoded39 classsetUpConversionTables WAKomEncoded39 classinitialize ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
