Re: [Pharo-dev] Nautilus Tree
Le 29/11/2013 17:20, Sean P. DeNigris a écrit : Sean P. DeNigris wrote I noticed that right now, separate packages within the same project are not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will be siblings in the tree, instead of both under MyProject. It seems like it would be more useful to have - MyProject - Core - Platform in the tree Bump... thoughts? I've done that a while ago. But not in Nautilus. Find it very convenient. Focused browsing, can forget most of the system around my workset without effort. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] Nautilus Tree
Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... So for me at least smart browsing plus tags plus good search facility can easily replace ugly hierarchy trees and packages with really long names. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). Just using common logic can take you a long way into improving the tools, the hard part is actually coding all this because it takes time and effort. Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris s...@clipperadams.com mailto:s...@clipperadams.com wrote: kilon alios wrote I dont see much room for thought, this looks to me like ideal behavior. I agree in theory, but it seems that the tree is primarily about chunking information into manageable pieces. A primary difficulty here is that packages are often divided for reasons that have nothing to do with the domain model, e.g. the ubiquitous MyPackage-Platform, which is an artifact of Metacello that is not all that relevant to a user wanting to understand the system. From the naive user perspective, if I'm exploring from the top level of the system, I want to see things like: - CodeImport - Collections - Compiler From this perspective, the 14 entries for Collections, multiplied by a few dozen top-level categories make the list unwieldy and only marginally less daunting than the flattened list we used to have (see http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ): http://forum.world.st/file/n4726287/Picture_1.png - Cheers, Sean -- View this message in context: http://forum.world.st/Nautilus-Tree-tp4723819p4726287.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] Nautilus Tree
It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.frwrote: Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... So for me at least smart browsing plus tags plus good search facility can easily replace ugly hierarchy trees and packages with really long names. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). Just using common logic can take you a long way into improving the tools, the hard part is actually coding all this because it takes time and effort. Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). On Fri, Nov 29, 2013 at 6:55 PM, Sean P. DeNigris s...@clipperadams.com mailto:s...@clipperadams.com wrote: kilon alios wrote I dont see much
Re: [Pharo-dev] Nautilus Tree
ok I found this after some google search - http://rmod.lille.inria.fr/web/pier?_s=HmL1nFoP1weCzRt7 . Is there any more recent documentation on Nautilus plugin system or any other way of extending Nautilus ? On Mon, Dec 2, 2013 at 11:05 AM, kilon alios kilon.al...@gmail.com wrote: It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.frwrote: Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... So for me at least smart browsing plus tags plus good search facility can easily replace ugly hierarchy trees and packages with really long names. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). Just using common logic can take you a long way into improving the tools, the hard part is actually coding all this because it takes time and
Re: [Pharo-dev] Nautilus Tree
Le 02/12/2013 10:05, kilon alios a écrit : It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Yes, that can be interesting. A good tagging / oragnization creation GUI can be nice. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? No. What I have is in fact a category hierachy + a name matching scheme. * The category hierarchy starts with top level items (Core, GUI, System, Packages, Networking, Development), with sub categories (such as Spec in GUI). I could have as many level of subcategories as I want. * Then I have a name matching scheme: a package starting with Spec will be put under GUI/Spec... If there is a common core, I improve on that and add subcategories under Spec to do Spec-Gui (for the packages Spec-Gui-Morphic, Spec-GUI-Amber, Spec-GUI-MVC, Spec_GUI-Gtk), and so on. The tree does automatic prefix reduction: if parent item is XXX and current item is XXXYYY then current item display is YYY. It also has an ability to clean up the system: load ConfigurationOfSomething in, it will be moved under Packages/Configuration/. You can load hundreds of configurations and they will all be stored there and you won't be annoyed by the length of the packages list (unless you open the Monticello Browser, of course :P). All this is to target the 7 +/-2 magic number HCI strives for. And the fact that we usually have a fairly good memory to find back things (they are allways in the same position). Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Yes, that's why I suggest experiments... There is a lot of tuning necessary. For example, I played a lot with automatic scoping in browsing and search... And backed off a bit because it made a mess of my search and understand workflow. I used to do like that: - looked at a method in a class - select implementors on a selector in the method source - get a browser scoped with only the implementors of that selector - look for an implementor in that browser... - :( empty browser because I was looking inside the previous scope So, now, if I ask for implementors in a selector scope, I back off one level in scoping: if the parent scope was a package, I'll search in the package scope. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . No, no, really. The underlying system is a bit hard to get into and isn't too well described, but it has everything you need to build one. Even mine... The specifics are the tree handling, but, honestly, you could use any other way to classify the code and replace that part of the GUI, reusing all the command and tracking system events logic. I reused code from the other browsers as well; I have a lot of respect for the architecture of the OmniBrowser, and for the features of Nautilus. Thierry On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.fr mailto:thierry.goub...@cea.fr
Re: [Pharo-dev] WhatsUp from: 2013-12-02 until: 2013-12-15
### Here's what I've been up to since the last WhatsUp: Pillar (http://www.smalltalkhub.com/#!/~Pier/Pillar) - huge pass on Pillar with Ben. Now the Enterprise Pharo book is generated using Pillar and there is a Markdown exporter (with computed section heading and figure numbers). There are also much more unit tests. https://ci.inria.fr/pharo-contribution/job/Pillar/ https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ - in-progress: reorganisation of Pillar so that we can configure in a file what we want in the output and use a simple command-line handler to do the export Pharo Launcher - make sure the user can configure where to put his images - launcher can now refresh just 1 template group - launcher now has a template group for some static urls (latest Pharo 2.0, latest Pharo 3.0, latest moose) Misc - fixing pier and magritte jobs - some more topics on http://topics.pharo.org/ ### What's next, until 2013-12-15 (*): - create a windows installer for the launcher - continue progressing on the Pillar command-line handler and configuration file -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Nautilus Tree
You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/ I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility. The idea is also that what you are browsing influence the browser. And Spec is good for that (as you can already see in the inspector) Ben On 02 Dec 2013, at 10:05, kilon alios kilon.al...@gmail.com wrote: It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... So for me at least smart browsing plus tags plus good search facility can easily replace ugly hierarchy trees and packages with really long names. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also
Re: [Pharo-dev] Nautilus Tree
Links are generated :) Here is the link I guess: http://rmod.lille.inria.fr/web/pier/software/Tools-Improvement/NautilusDocumentation There is no newer documentation, but this one is still up t orate (at least concerning the plugin mechanism). It is pretty simple. Have a look at some plugins and you should get it pretty fast :) Ben On 02 Dec 2013, at 10:26, kilon alios kilon.al...@gmail.com wrote: ok I found this after some google search - http://rmod.lille.inria.fr/web/pier?_s=HmL1nFoP1weCzRt7 . Is there any more recent documentation on Nautilus plugin system or any other way of extending Nautilus ? On Mon, Dec 2, 2013 at 11:05 AM, kilon alios kilon.al...@gmail.com wrote: It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser...
Re: [Pharo-dev] Nautilus Tree
what you are browsing influence the browser. Ben!! We should definitely sync on that! On Dec 2, 2013, at 11:27 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/ I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility. The idea is also that what you are browsing influence the browser. And Spec is good for that (as you can already see in the inspector) Ben On 02 Dec 2013, at 10:05, kilon alios kilon.al...@gmail.com wrote: It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps me because I can remember where things are (and the tree also shorten long package names ;)). It was not my intention to offer ONLY a tag system, hierarchy trees are useful too. I see the tag system as another alternative way of viewing classes and methods not as a complete replacement to hierarchy trees.Also the tree hides part of the name but force you to make long package names to use the tree anyway. Am I wrong ? Beware: there is no common logic in that (you're a specific case, I'd be very unhappy with your GUI as far as I can see, and the reverse is also true). Common logic means exactly what is implied, logic which some people agree on. Obviously nothing is absolute and people have different workflow which I respect and love to hear about them ;) I definitely would not want to force people doing things a single way. Anything can useful. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... Is it or are you being sarcastic ? It was never my intention to rebuilt a complete system browser, just reskin and extend the existing one. I find the system browser already extremely powerful and fun to use , I just wanted to add my own touches to it. This is why I was considering Glamour . On Mon, Dec 2, 2013 at 10:37 AM, Goubier Thierry thierry.goub...@cea.fr wrote: Le 29/11/2013 18:16, kilon alios a écrit : Currently I am working on Hyperion, a vector editor for Athens. Then I will work on Prometheas, on board documentation tool again with Athens. My third tool, if ever reach that far is Cyclops which will target the system browser. Now I am no fan of hierarchy trees. I find them hard to navigate and messy when hierarchy gets too complex. I see two solution on this one a) Sophisticated search facility, we have that already with the finder tool . I feel its time for the finder tool to go and be one with the system browser. It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. b) Tag based browsing. That means attach tags to your classes and methods , make it easy this way to make things belong to groups and most importantly one thing could belong to more than one group. This also means bye bye packages, and instead replaced with infinite level groups, a group can be inside another group which can be inside another group etc. Of course those groups wont exist only their tags will exist. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. I am also smiling to the Glamour philosophy of having a browser tool that can have multiple ways of viewing your classes. Bottom line is that I will be using existing ideas and I hope also code to push things just tiny bit further. Do it, do it! As I experienced myself, it's fairly easy to rebuilt a complete system browser... So for me at least smart browsing plus tags plus good search facility can easily replace ugly
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/30615 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] ccbd00: 30615
Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: ccbd00698e95b025f2059699f368c9968eb31993 https://github.com/pharo-project/pharo-core/commit/ccbd00698e95b025f2059699f368c9968eb31993 Author: Jenkins Build Server bo...@pharo-project.org Date: 2013-12-02 (Mon, 02 Dec 2013) Changed paths: A GroupManager.package/AbstractGroup.class/class/instance creation/cleanUp.st A GroupManager.package/AbstractGroup.class/class/instance creation/unsubscribeExistingGroups.st M Kernel.package/DateAndTime.class/class/instance creation/date_time_.st A KernelTests.package/DateAndTimeTest.class/instance/tests - instance/testInstanceCreationFromADateAndATime.st A Nautilus.package/Nautilus.class/class/accessing/resetGroups.st R Nautilus.package/PackageTreeNautilus.class/class/accessing/resetGroups.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script270.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30615.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/Finder.class/instance/accessing/selection_.st M Tools.package/FinderMethodNode.class/instance/private/browseImplementors.st M Tools.package/FinderMethodNode.class/instance/private/browseSenders.st M Tools.package/FinderSingleMethodNode.class/instance/as yet unclassified/displayString.st A Tools.package/FinderSingleMethodNode.class/instance/private/itemMethod.st R Tools.package/FinderUI.class/instance/t - accessing/rootNodeFromItem_.st Log Message: --- 30615 12307 Adding unload to GroupManager or GroupAbstract https://pharo.fogbugz.com/f/cases/12307 12273 DNU doing senders in Finder https://pharo.fogbugz.com/f/cases/12273 12305 resetGroups should be moved in superclass https://pharo.fogbugz.com/f/cases/12305 12299 #date:time: fix for 3.0 https://pharo.fogbugz.com/f/cases/12299 http://files.pharo.org/image/30/30615.zip
[Pharo-dev] Pharo picture
Accidentally stumbled upon: http://www.deviantart.com/art/October-26-412316678 Have a nice week everyone! Uko
Re: [Pharo-dev] Nautilus Tree
Goubier thanks for the information, looks like it is as I assumed it is. Its a big motivation to know that there is so much modularity in the code. Its important that we have code that is easy to extend I think, this way we can try new ideas and keep what we like and throw away what we dont without worrying about the cost in development time. By the way I forgot to say that I love the tree feature, definitely makes browsing packages much more manageable. I am also very excited that now we have a search bar for packages. Things definitely improve. thanks Benjamin I will have a look. Yes the plugin system looks very simple, I don't think will cause me any big problem. Is there a roadmap for Nautilus ? or is it add whatever you want as long as is useful approach ? I have to say that at times it makes me wonder. Pharo is a closed system, pharo code is suppose to run inside the pharo ide. So if its a closed system why we need case sensitivity and thinking hard about class and function names ? Why cant we choose many different names for each class and method and let the system choose the right class and method for us. I am also thinking namespaces, namespaces in language level are essential but at IDE level can be extremely useful as well. Lets say you dont like the names used for some classes and methods. Why go through the tedious process of subclassing and creating your own methods that call superclass methods just so you have better names for those methods. Just go in and add new names for those methods, while they keep their old ones. Name clashing ? no problemo, use tags as identifiers that will help you separate methods with same names. For me pharo could have an extremely flexible naming system. No need for case sensitivity , no fear of names clashing. I guess that is what you Goubier were referring to as scoped browsing. Tags , namespaces, flexible searching via code completion could make it easy to use the right message even for a coder that does not know the name of the message or does not even know what kind of message he wants in his code. We could even abstract the whole process of coding, starting with ideas in form of DSL that gets transformed into pharo code in the process. This DSL will be a bare bones pharo code capable of mapping to ideas, ideal for brainstorming without the need to test code and worry about syntax etc. Later on that DSL would be able to change to pharo code and be as specific as needed to be proper code, generate its own tests etc. These are some random ideas I have, more like brainstorming. But it does make me wonder because I feel that pharo can be so much more flexible than what an average language because the IDE is integrated and something we take for granted. So I think we could push things much further than anyone else. If all that sound crazy to you, its ok, I just love to brainstorm , I dont take every idea I have very seriously nor I am saying I will put these ideas to code. But I would like to know what you think about the direction pharo will be going on this matters. Namespaces for example is something we will need sooner or later because pharo will get only bigger and more complex. On Mon, Dec 2, 2013 at 12:32 PM, Roberto Minelli roberto.mine...@usi.chwrote: what you are browsing influence the browser. Ben!! We should definitely sync on that! On Dec 2, 2013, at 11:27 AM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: You can have a look here http://smalltalkhub.com/#!/~BenjaminVanRyseghem/Nautilus/ I started (and will resume working on it soon) a Spec based implementation of Nautilus with more extensibility. The idea is also that what you are browsing influence the browser. And Spec is good for that (as you can already see in the inspector) Ben On 02 Dec 2013, at 10:05, kilon alios kilon.al...@gmail.com wrote: It's done for me (with the added fact that you want to return the search results inside the system browser itself: done for me too). For Nautilus, there is a need to reactivate the Finder plugin. that's great to hear, this makes things much easier for me. How to reactivate that plugin ? Also where I can find documentation for the Nautilus plugin system ? I have no intention of reinventing the wheel, if I can just extend Nautilus that would be great. Having this option means I could even start Cyclops now, cause it will take me much less time than I expected. Takes ages to tag correctly a system as large as Pharo nowadays. Such a graph can also makes things very complex at times. You may want to look into dynamic tagging... which brings you to scoped browsing, more or less. My plan was to offer tagging for some classes I heavily use but obviously not all. I wanted to allow user to create their own tags even custom ones and sync automatically with other users against a common online tag repository. Up to you :) Me, I have a fairly good spatial memory, so a tree helps
Re: [Pharo-dev] Pharo picture
Nice one :) Alexandre Le 02-12-2013 à 8:34, Yuriy Tymchuk yuriy.tymc...@me.com a écrit : Accidentally stumbled upon: http://www.deviantart.com/art/October-26-412316678 Have a nice week everyone! Uko
Re: [Pharo-dev] How to update Deep into Pharo Chapter
I can't compile anymore when I include your text: $ pdflatex Exceptions.tex ! Extra }, or forgotten $. recently read \egroup l.880 Transcript show: 'error 2'; cr. does not display it ? $ pdflatex -version pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013) Please just include your text in Exceptions.tex. Thank you On Fri, Nov 29, 2013 at 8:01 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks! On Nov 28, 2013, at 10:27 PM, Gabriel Cotelli g.cote...@gmail.com wrote: I commited a new file (GOC-ExceptionExclusions.tex) in the Exceptions folder with a short subsection explaining the use. Feel free to review and improve it before inclusion in the main file. Probably the better insertion point is just after the ExceptionSet explanation. For testing the latex compilation I temporally put a \input in the main file (this isn't commited). Regards, Gabriel On Wed, Nov 27, 2013 at 3:45 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Yes It would be good that you put some comments so that I can read it fast. Stef On Nov 26, 2013, at 11:07 PM, Gabriel Cotelli g.cote...@gmail.com wrote: Thanks Damien, What is the expected workflow? I checkout the latex code, made the changes and then commit? On Tue, Nov 26, 2013 at 4:30 PM, Damien Cassou damien.cas...@gmail.com wrote: On Tue, Nov 26, 2013 at 6:34 PM, Gabriel Cotelli g.cote...@gmail.com wrote: Done. Username: gcotelli done -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] [Moose-dev] Re: Similarity Matrix
Really nice.In fact it would be great if we can plug the comparison between the xand y cells (which can be different).Because like that we get a simple matrix based comparator similar to theone of early paper of prejinshight work.This is the case actually.Consider this rather simple and small example:SimilarityMatrix new on: #('hello world' 'welcome to our world' 'hello means bonjour' 'bye bye') by: [ :m1 : m2 | (m1 substrings intersection: m2 substrings) size / ((1 max: (m1 substrings union: m2 substrings) size) + 1) "NB penalty for small methods" ]; gridViewThe output isIt visually says that ‘hello world’ is close to ‘welcome to out world’ and to ‘hello means bonjour’, because ‘hello’ and ‘world’ are in common.Alexandre
[Pharo-dev] Responsible development
Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Responsible development
Well, +1 We should, in a way, form a sort of “Pharo UI Team” that keeps pushing and fixing Nautilus co. On Dec 2, 2013, at 2:02 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Some squeaksource.com updates
On Sun, Dec 01, 2013 at 07:11:59PM -0800, Sean P. DeNigris wrote: David T. Lewis wrote The welcome page for http://squeaksource.com has been updated... The policy of disabling new project creation remains in effect. Thanks! It is good that so much of our history will remain accessible... create any number of projects to host on our server should probably be removed Thanks Sean, I fixed it. Dave
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 14:03, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. this is the same as saying “I have an idea for developing pharo: We should stop introducing bugs”. So: yes. Please do. ;-) Marcus
Re: [Pharo-dev] Responsible development
Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is unfixable, IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Responsible development
yes, tocayo, you are right... but there is a design problem since ever and fix that will not be easy. Also, there is the notion of main thread internal to pharo, and the main thread relative to the OS. And AFAIK, the vm runs in the main thread (in mac there is a line to uncomment for moving out main thread, but they were a problem with certain callbacks who prevent me to use it... but well, we should review that too). Esteban On Mon, Dec 2, 2013 at 2:21 PM, Esteban A. Maringolo emaring...@gmail.comwrote: Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is unfixable, IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Responsible development
Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko On 02 Dec 2013, at 14:21, Esteban A. Maringolo emaring...@gmail.com wrote: Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is unfixable, IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Nautilus Tree
kilon alios wrote: Lets say you dont like the names used for some classes and methods. Why go through the tedious process of subclassing and creating your own methods that call superclass methods just so you have better names for those methods. Just go in and add new names for those methods, while they keep their old ones. Name clashing ? no problemo, use tags as identifiers that will help you separate methods with same names. Sounds a bit (but not quite) like package extensions per the top half of [1]. [1] http://seandenigris.com/blog/?p=1015 cheers -ben
Re: [Pharo-dev] Nautilus Tree
no its not , this blog post is about extending existing classes with new methods that are stored to other packages instead of creating subclasses. My point is about offering multiple names (not just one) to existing methods and classes, plus tags to further identify the methods so it is much easier to find the method you want or make your code more readable. My approach does not generate new methods, it does not touch existing objects , nor make the system more complicated. I see it more like a database to help you find things. But thanks for the link anyway , now I know how to make extension classes. On Mon, Dec 2, 2013 at 3:34 PM, b...@openinworld.com wrote: kilon alios wrote: Lets say you dont like the names used for some classes and methods. Why go through the tedious process of subclassing and creating your own methods that call superclass methods just so you have better names for those methods. Just go in and add new names for those methods, while they keep their old ones. Name clashing ? no problemo, use tags as identifiers that will help you separate methods with same names. Sounds a bit (but not quite) like package extensions per the top half of [1]. [1] http://seandenigris.com/blog/?p=1015 cheers -ben
Re: [Pharo-dev] Responsible development
2013/12/2 Esteban Lorenzano esteba...@gmail.com: yes, tocayo, you are right... but there is a design problem since ever and fix that will not be easy. Also, there is the notion of main thread internal to pharo, and the main thread relative to the OS. And AFAIK, the vm runs in the main thread (in mac there is a line to uncomment for moving out main thread, but they were a problem with certain callbacks who prevent me to use it... but well, we should review that too). I know it's not easy, in fact I think it is hard. But I wanted to point this out. :) I barely know about how Windows processes work, so I can't speak about how to do it in Windows, Linux or MacOS. Regards! Esteban A. Maringolo
Re: [Pharo-dev] Responsible development
I do feel that this issue fall more under the jurisdiction of Exception Handling, where if something bad happens to your system the whole thing does not collapse on itself but rather reports the error and carries on. Pharo processes are not OS processes, correct me if I am wrong but they dont have their own memory or can get their own core and generally are not separate entities. They are not even real threads. So I doubt how much of a protection they will offer. But agree with your its a design issue that sooner or later will have to be addressed. If the systems is very complex , then later is more likely. On Mon, Dec 2, 2013 at 3:32 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko On 02 Dec 2013, at 14:21, Esteban A. Maringolo emaring...@gmail.com wrote: Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is unfixable, IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Responsible development
2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Unless you program everything based on callbacks, then even if you fork explicitly (new Processes) or by means of Futures, Promises, etc... at one point you'll have to wait (it is, block) every time you need to update the UI. The good practice is to spend the least time possible running thing in the UI thread. But given the fact the VM is single process in terms of host OS, callbacks won't provide much resilience either. Regards, Esteban A. Maringolo ps: As an concrete example, Android will kill any process taking more than 5 seconds in the main thread. So EVERYTHING except events, painting and layout, must take less than that, and if you do I/O or computation, you have to use threads. Ref: http://developer.android.com/guide/components/processes-and-threads.html
Re: [Pharo-dev] Solaris VM ?
Hi, After a while, I have the information. This is a x86 (this is not for me). I will try to install a Solaris VM, and install a Pharo on top. Jannik 2013/11/27 Andreas Wacknitz a.wackn...@gmx.de Hi Jannik, some time ago I was able to compile the old Squeak VM on Solaris (SPARC and x86). I haven’t tried it for a long time, especially not with Cog or StackVM. Which version of Solaris are you using? Best regards, Andreas Am 25.11.2013 um 22:50 schrieb jannik.laval jannik.la...@gmail.com: Hi guys, Does anyone know if Pharo can work on a Solaris System ? Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Responsible development
Same story with Swing UI in Java if you want decent performance. http://en.wikipedia.org/wiki/SwingWorker Phil On Mon, Dec 2, 2013 at 3:10 PM, Esteban A. Maringolo emaring...@gmail.comwrote: 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Unless you program everything based on callbacks, then even if you fork explicitly (new Processes) or by means of Futures, Promises, etc... at one point you'll have to wait (it is, block) every time you need to update the UI. The good practice is to spend the least time possible running thing in the UI thread. But given the fact the VM is single process in terms of host OS, callbacks won't provide much resilience either. Regards, Esteban A. Maringolo ps: As an concrete example, Android will kill any process taking more than 5 seconds in the main thread. So EVERYTHING except events, painting and layout, must take less than that, and if you do I/O or computation, you have to use threads. Ref: http://developer.android.com/guide/components/processes-and-threads.html
Re: [Pharo-dev] [Moose-dev] Re: Similarity Matrix
then this is really cool
:)
On Dec 2, 2013, at 1:39 PM, Alexandre Bergel alexandre.ber...@me.com wrote:
Really nice.
In fact it would be great if we can plug the comparison between the
x and y cells (which can be different).
Because like that we get a simple matrix based comparator similar to the one
of early paper of prejinshight work.
This is the case actually.
Consider this rather simple and small example:
SimilarityMatrix new
on: #('hello world' 'welcome to our world' 'hello means
bonjour' 'bye bye')
by: [ :m1 : m2 |
(m1 substrings intersection: m2 substrings) size
/ ((1 max: (m1 substrings union: m2 substrings) size) +
1) NB penalty for small methods
];
gridView
The output is
Screen Shot 2013-12-02 at 9.36.58 AM.png
It visually says that ‘hello world’ is close to ‘welcome to out world’ and to
‘hello means bonjour’, because ‘hello’ and ‘world’ are in common.
Alexandre
Re: [Pharo-dev] Responsible development
User interrupt (cmd + .) was not working? -- Pavel 2013/12/2 Esteban A. Maringolo emaring...@gmail.com Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is unfixable, IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko
Re: [Pharo-dev] Solaris VM ?
Jannik I do not understand. The people do not have a windows machine? Because I can understand thta you are solaris around but having a simple windows machine looks like a simple requirement. Stef On Dec 2, 2013, at 3:12 PM, jannik laval jannik.la...@gmail.com wrote: Hi, After a while, I have the information. This is a x86 (this is not for me). I will try to install a Solaris VM, and install a Pharo on top. Jannik 2013/11/27 Andreas Wacknitz a.wackn...@gmx.de Hi Jannik, some time ago I was able to compile the old Squeak VM on Solaris (SPARC and x86). I haven’t tried it for a long time, especially not with Cog or StackVM. Which version of Solaris are you using? Best regards, Andreas Am 25.11.2013 um 22:50 schrieb jannik.laval jannik.la...@gmail.com: Hi guys, Does anyone know if Pharo can work on a Solaris System ? Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Responsible development
Hi Phil, Yes, the SwingWorker in Swing is similar to the AsyncTask in Android, but they are one shot async tasks. In the other hand, the WebWorker in HTTP5 or Handler in Android, what they do is to post messages to the message queue of the UI thread. Regards, Esteban A. Maringolo 2013/12/2 p...@highoctane.be p...@highoctane.be: Same story with Swing UI in Java if you want decent performance. http://en.wikipedia.org/wiki/SwingWorker Phil On Mon, Dec 2, 2013 at 3:10 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/2 Yuriy Tymchuk yuriy.tymc...@me.com: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Unless you program everything based on callbacks, then even if you fork explicitly (new Processes) or by means of Futures, Promises, etc... at one point you'll have to wait (it is, block) every time you need to update the UI. The good practice is to spend the least time possible running thing in the UI thread. But given the fact the VM is single process in terms of host OS, callbacks won't provide much resilience either. Regards, Esteban A. Maringolo ps: As an concrete example, Android will kill any process taking more than 5 seconds in the main thread. So EVERYTHING except events, painting and layout, must take less than that, and if you do I/O or computation, you have to use threads. Ref: http://developer.android.com/guide/components/processes-and-threads.html
Re: [Pharo-dev] Responsible development
2013/12/2 Pavel Krivanek pavel.kriva...@gmail.com: User interrupt (cmd + .) was not working? Most of the times for simple things it does, but sometimes it doesn't. Regards, Esteban A. Maringolo
Re: [Pharo-dev] Responsible development
Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Solaris VM ?
Yes it is possible, but they prefer to have all their systems on Solaris. Jannik 2013/12/2 Stéphane Ducasse stephane.duca...@inria.fr Jannik I do not understand. The people do not have a windows machine? Because I can understand thta you are solaris around but having a simple windows machine looks like a simple requirement. Stef On Dec 2, 2013, at 3:12 PM, jannik laval jannik.la...@gmail.com wrote: Hi, After a while, I have the information. This is a x86 (this is not for me). I will try to install a Solaris VM, and install a Pharo on top. Jannik 2013/11/27 Andreas Wacknitz a.wackn...@gmx.de Hi Jannik, some time ago I was able to compile the old Squeak VM on Solaris (SPARC and x86). I haven’t tried it for a long time, especially not with Cog or StackVM. Which version of Solaris are you using? Best regards, Andreas Am 25.11.2013 um 22:50 schrieb jannik.laval jannik.la...@gmail.com: Hi guys, Does anyone know if Pharo can work on a Solaris System ? Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/ -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Responsible development
As Clement explained to be, the Cmd + . combo is only tested on VM bytecode backjumps. So, if the bytecode is stuck with no backjumps, it is definitely stuck. I'd like to see where this occurs in the VM (maybe in the hope I could have a slow, but interruptible VM at all times) - this could take the form of a setting that gets turned on. Phil On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo emaring...@gmail.comwrote: 2013/12/2 Pavel Krivanek pavel.kriva...@gmail.com: User interrupt (cmd + .) was not working? Most of the times for simple things it does, but sometimes it doesn't. Regards, Esteban A. Maringolo
Re: [Pharo-dev] Solaris VM ?
Solaris is far from dead. http://www.perkin.org.uk/posts/goodbye-oracle-hello-joyent.html http://smartos.org/ http://en.wikipedia.org/wiki/Joyent I wouldn't call that living in the past if you ask me. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Mon, Dec 2, 2013 at 3:42 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: Yes it is possible, but they prefer to have all their systems on Solaris. and live in the past (kind of 20 years back why not after all derrick and gameboy was not that bad). Indeed this is a choice. Stef Jannik 2013/12/2 Stéphane Ducasse stephane.duca...@inria.fr Jannik I do not understand. The people do not have a windows machine? Because I can understand thta you are solaris around but having a simple windows machine looks like a simple requirement. Stef On Dec 2, 2013, at 3:12 PM, jannik laval jannik.la...@gmail.com wrote: Hi, After a while, I have the information. This is a x86 (this is not for me). I will try to install a Solaris VM, and install a Pharo on top. Jannik 2013/11/27 Andreas Wacknitz a.wackn...@gmx.de Hi Jannik, some time ago I was able to compile the old Squeak VM on Solaris (SPARC and x86). I haven’t tried it for a long time, especially not with Cog or StackVM. Which version of Solaris are you using? Best regards, Andreas Am 25.11.2013 um 22:50 schrieb jannik.laval jannik.la...@gmail.com: Hi guys, Does anyone know if Pharo can work on a Solaris System ? Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/ -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Responsible development
On 02/12/13 14:32, Stéphane Ducasse wrote: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 16:24, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote Shouldn’t we develop our tools in a more friendly way? That would be fantastic. This thread is very interesting! And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not expect it to be stable, It’s not about stability of pharo 3, it about concurrency. And it’s the same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running tests, but I cannot do that in Pharo. This thread doesn’t seem to have any reason, so I should just apologise for creating it because of frustration and ask everyone to stop discussing this :) although it is remarkably so for the amount of deep changes that have been made. Maybe that has lulled us into a false sense of security/expectation. Remember, caveat emptor until it is released, when there obviously shouldn't be any changes which might introduce this kind of bug. - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726749.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
First, if you break your tools and do a loop in traditional world then you live with it. Second, if you see what guillermo is doing: running multiple core side by side (this is a first step because there is no supervisor and we are in shared memory) but this could be a solution. Third I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. such kind of reports are useless. I do not count the number of time my mac application crash on me including the finder. I would not say that pharo is less stable that Mac OS from my perspective. Especially when I see the knid of changes we are doing. Fourth we are in alpha and nautilus was massively changed. I expect a lot more bugs, because such browser is complex. Stef Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Responsible development
And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not expect it to be stable, It’s not about stability of pharo 3, it about concurrency. And it’s the same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running tests, but I cannot do that in Pharo. Of course you can do that in Pharo. AutoTest was a trial to do that. Now for example you can load code in a background process now if you modify objects that may be impacted by changes then you can get in trouble. In ruby do you run them in a patched kernel version or in the same environment? I would like to have isolated memory and several kernels running side by side but this is not something that we can achieve in a couple of days. This thread doesn’t seem to have any reason, so I should just apologise for creating it because of frustration and ask everyone to stop discussing this :) Yury you should be more precise in your point although it is remarkably so for the amount of deep changes that have been made. Maybe that has lulled us into a false sense of security/expectation. Remember, caveat emptor until it is released, when there obviously shouldn't be any changes which might introduce this kind of bug. - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726749.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 16:40, Stéphane Ducasse stephane.duca...@inria.fr wrote: First, if you break your tools and do a loop in traditional world then you live with it. Second, if you see what guillermo is doing: running multiple core side by side (this is a first step because there is no supervisor and we are in shared memory) but this could be a solution. Third I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. such kind of reports are useless. I do not count the number of time my mac application crash on me including the finder. I would not say that pharo is less stable that Mac OS from my perspective. Especially when I see the knid of changes we are doing. Fourth we are in alpha and nautilus was massively changed. I expect a lot more bugs, because such browser is complex. Stef I’m not complaining that new tools are bad. I’m gust telling that I’d prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, tools for traits instead of slots etc… I’m not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. Although you have more experience so maybe it’s better the way it is. uko Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Solaris VM ?
Hi Jannik, PharoVM is based on Cog. My old VM’s were traditional SqueakVM’s. I am not aware of precompiled Solaris VM’s based on Cog or PharoVM, so you have to build them by yourself. This should be possible; you only need some supporting libraries (e.g. GMP (earlier named GNUmp) and MPFR)) and probably CMake. When I did compile it for myself I used Solaris 10 (both, x86 and SPARC). Which variant do your customers have? Nowadays there are Solaris 10, Solaris 11, and a bunch of OpenSolaris derivates. There are some differences in the tool chains and libraries (versions). If you are not familiar with Solaris or UNIX you should be aware that UNIX in Squeak’s view is (most probably only) Linux. And this is problematic because you will most probably find some areas where there are differences between a „real“ UNIX (like Solaris) and Linux. Good luck, Andreas Am 02.12.2013 um 15:12 schrieb jannik laval jannik.la...@gmail.com: Hi, After a while, I have the information. This is a x86 (this is not for me). I will try to install a Solaris VM, and install a Pharo on top. Jannik 2013/11/27 Andreas Wacknitz a.wackn...@gmx.de Hi Jannik, some time ago I was able to compile the old Squeak VM on Solaris (SPARC and x86). I haven’t tried it for a long time, especially not with Cog or StackVM. Which version of Solaris are you using? Best regards, Andreas Am 25.11.2013 um 22:50 schrieb jannik.laval jannik.la...@gmail.com: Hi guys, Does anyone know if Pharo can work on a Solaris System ? Cheers, Jannik -- ~~Jannik Laval~~ École des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/
Re: [Pharo-dev] Responsible development
I’m not complaining that new tools are bad. I’m gust telling that I’d prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, But it was never like that. The old browser is just worse code but the logic is the same. tools for traits instead of slots I do not understand what you mean because this is totally orthogonal. etc… I’m not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. Yes but not only :) You see in PHP and perl they use them too. The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. LOL We are doing infrastructure work since years. Just open your eyes to realise it. FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest. Although you have more experience so maybe it’s better the way it is. uko Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Responsible development
Run 2 images and Monticello. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Mon, Dec 2, 2013 at 4:35 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 16:24, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote Shouldn’t we develop our tools in a more friendly way? That would be fantastic. This thread is very interesting! And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not expect it to be stable, It’s not about stability of pharo 3, it about concurrency. And it’s the same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running tests, but I cannot do that in Pharo. This thread doesn’t seem to have any reason, so I should just apologise for creating it because of frustration and ask everyone to stop discussing this :) although it is remarkably so for the amount of deep changes that have been made. Maybe that has lulled us into a false sense of security/expectation. Remember, caveat emptor until it is released, when there obviously shouldn't be any changes which might introduce this kind of bug. - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726749.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Roassal Bug related to Athens?
Hello Igor, Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019 I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error. Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice? regards, Usman
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 17:11, Stéphane Ducasse stephane.duca...@inria.fr wrote: I’m not complaining that new tools are bad. I’m gust telling that I’d prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, But it was never like that. The old browser is just worse code but the logic is the same. Yes, so time was spent to make Nautilus. It could be spent to work on concurrency. Now it’s useless to discuss whether it’s good or not to go one way or the other. We can always find good and always find bad. Sorry for disturbing, I’m getting back to work to make Pharo better :) uko tools for traits instead of slots I do not understand what you mean because this is totally orthogonal. etc… I’m not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. Yes but not only :) You see in PHP and perl they use them too. The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. LOL We are doing infrastructure work since years. Just open your eyes to realise it. FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest. Although you have more experience so maybe it’s better the way it is. uko Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Responsible development
Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
Traits do work nicely. What's your pain with them? (apart from the fact that the categorization in 2.0 is somewhat buggy)... Phil On Mon, Dec 2, 2013 at 5:11 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: I’m not complaining that new tools are bad. I’m gust telling that I’d prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, But it was never like that. The old browser is just worse code but the logic is the same. tools for traits instead of slots I do not understand what you mean because this is totally orthogonal. etc… I’m not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. Yes but not only :) You see in PHP and perl they use them too. The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. LOL We are doing infrastructure work since years. Just open your eyes to realise it. FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest. Although you have more experience so maybe it’s better the way it is. uko Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Uko
Re: [Pharo-dev] Responsible development
Yes, so time was spent to make Nautilus. It could be spent to work on concurrency. Concurrency is not magic. You have a strange belief. Pharo has nearly the same model than Java or any language with semaphore, and others basic concurrency constructs. Concurrency is not the panacea. It implies duplication or synchronisation points. What you are calling concurrency is robust and isolated execution. This is not the same and it is difficult to achieve especially with an open-source written in itself and reflective. Now it’s useless to discuss whether it’s good or not to go one way or the other. No I give you chance to educate you and learn. I'm not spending time for the sake of arguing but I invest in you :) Else I would not even reply. We can always find good and always find bad. Sorry for disturbing, I’m getting back to work to make Pharo better :) Yes. I'm not satisfied to what we have but we have it.
Re: [Pharo-dev] Responsible development
And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-) Keep up the good work! Cheers, R On Dec 2, 2013, at 5:47 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I'm not satisfied to what we have but we have it.
Re: [Pharo-dev] Responsible development
Amen On 02 Dec 2013, at 18:06, Roberto Minelli roberto.mine...@usi.ch wrote: And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-) Keep up the good work! Cheers, R On Dec 2, 2013, at 5:47 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I'm not satisfied to what we have but we have it.
Re: [Pharo-dev] Stepping through with GLORP Proxies
On Sun, Dec 1, 2013 at 11:44 AM, Clément Bera bera.clem...@gmail.comwrote: One thing with Pharo 3.0 is that the debugger is quite different than it used to be. It is now split into a model (DebugSession + DebugContext) and the view, SpecDebugger. I don't know what Eliot does have to change but the new code may require some extra work due to the debugger being different. The code is all down at the level of ContextPart so I hope it won't affect the debugger changes at all. Now the new debugger is so much easier to understand and to edit that it shouldn't be an issue... 2013/12/1 Stéphane Ducasse stephane.duca...@inria.fr On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/1 Stéphane Ducasse stephane.duca...@inria.fr: Hi eliot why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha. In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?). Excellent news! Will you be able to tell us more because Pharo needs more visibility. So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system. I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect. Regards, Esteban A. Maringolo -- best, Eliot
[Pharo-dev] Unifying Testing Ideas
We have some cool matchers (Phexample, StateSpecs), some nice mocking libraries (Mocketry, BabyMock), and Phexample's acknowledgement that tests build on each other. The problem is, it's hard to cherry-pick and build one's perfect test enviroment. For example: - Phexample and Mocketry, whose matching frameworks break each other - Phexample and BabyMock both require subclassing from their own TestCase subclass, so they can't be used together. I wonder what the solution is? Maybe some registration scheme? It'd be nice to be more coordinated here. As a first step, I manually merged BabyMock and Phexample to produce the following (IMHO) gorgeous tests... testNew self library should receive: #FMOD_System_Create:; with: FMOD_SYSTEM new; does: [ :h | h handle: 20. 0 ]. self library should receive: #FMOD_System_Init:; with: [ :a | a handle = 30 ]; answers: 0. ^ FmodSystem new. testNewSound | soundFile system | system := self given: #testNew. soundFile := FileLocator vmBinary. self library should receive: #FMOD_System_CreateSound:to:with:; with: soundFile fullName and: FMOD_SOUND new and: [ :h | h = system handle ]; answers: 0. ^ system newSoundFromFile: soundFile. testPlaySound | sound | sound := self given: #testNewSound. self library should receive: #FMOD_System:PlaySound:on:; with: sound system handle and: sound handle and: FmodChannel new; answers: 0. ^ sound play. testChannelIsPlaying | channel | channel := self given: #testPlaySound. self library should receive: #FMOD_Channel_IsPlaying:storeIn:; with: channel and: NBExternalAddress new; does: [ :c :isPlaying | isPlaying value: 1 ]. ^ channel isPlaying. The tests... let's call them specifications... clearly state how the object should talk to the FMOD library. The neat part of Phexample is that even though each specification uses the result of the last, it's smart enough not to fail the dependent if the #given: fails. It moves it into expected failures this is important because otherwise a failure deep in the system would make it difficult to pinpoint since there could be many failing specifications. n.b. in this case, I'm not sure that mocking is the best strategy and I may end up using a hand-written stub, but I wanted to do a case study. One area where I've really found mocks to shine is internal to one's system. That is, I'm writing an object and discover that it must talk to another as-yet-unwritten object. So I mock it out and in so doing define its API, which I then go implement. Also, the mocks are using a custom extension to BabyMock that allows you to pass the arguments do #does:, so it will not run on vanilla BabyMock - Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] transcript is plain bad
I can tell that it does not work when loading partial code because all the compiler warnings make sure that you cannot see anything…. I should have pushed my logger more. :(
Re: [Pharo-dev] Stepping through with GLORP Proxies
Ok then the latest Pharo 3 that you can find here: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/ is the best image for this fix. However being the bleeding edge this image is stable but might have some issues. 2013/12/2 Eliot Miranda eliot.mira...@gmail.com On Sun, Dec 1, 2013 at 11:44 AM, Clément Bera bera.clem...@gmail.comwrote: One thing with Pharo 3.0 is that the debugger is quite different than it used to be. It is now split into a model (DebugSession + DebugContext) and the view, SpecDebugger. I don't know what Eliot does have to change but the new code may require some extra work due to the debugger being different. The code is all down at the level of ContextPart so I hope it won't affect the debugger changes at all. Now the new debugger is so much easier to understand and to edit that it shouldn't be an issue... 2013/12/1 Stéphane Ducasse stephane.duca...@inria.fr On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/1 Stéphane Ducasse stephane.duca...@inria.fr: Hi eliot why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha. In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?). Excellent news! Will you be able to tell us more because Pharo needs more visibility. So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system. I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect. Regards, Esteban A. Maringolo -- best, Eliot
Re: [Pharo-dev] transcript is plain bad
The return of the toothpick is near. o/ On Mon, Dec 2, 2013 at 6:54 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: I can tell that it does not work when loading partial code because all the compiler warnings make sure that you cannot see anything…. I should have pushed my logger more. :(
Re: [Pharo-dev] transcript is plain bad
The return of the toothpick is near. o/ No I will finish my logger :) Stef
Re: [Pharo-dev] transcript is plain bad
yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: The return of the toothpick is near. o/ No I will finish my logger :) Stef
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] transcript is plain bad
Buy the way, is absence of Transcript class - ok? I know how it all works now, but is it ok? :) uko On 02 Dec 2013, at 19:58, Esteban Lorenzano esteba...@gmail.com wrote: yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: The return of the toothpick is near. o/ No I will finish my logger :) Stef
Re: [Pharo-dev] transcript is plain bad
yes, the transcript is ThreadSafeTranscript On Mon, Dec 2, 2013 at 8:00 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Buy the way, is absence of Transcript class - ok? I know how it all works now, but is it ok? :) uko On 02 Dec 2013, at 19:58, Esteban Lorenzano esteba...@gmail.com wrote: yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: The return of the toothpick is near. o/ No I will finish my logger :) Stef
Re: [Pharo-dev] Responsible development
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
Even if everything runs in one thread it doesn’t mean that you need to block something. ? You run in one thread then either it runs or it does not :) When loading Moose in one process it will load model and not process UI. I see that you do not really grasp concurrency. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. It just depends if you want to let the user do something in parallel or not. For moose this is easy to fork the loading. Now for pharo since what you load can modify the running system this is a different story. In my opinion the problem is that we are not used to run non-instant operations in a separate process, No :) The problem is that we do not have a nice way to protect the system from being executed and modified at the same time. Imagine that we would load the code in a separate structure in the parallel process and that once the code is loaded but not installed you have a fast way to install it. Then we could do loading on the side. You see the key aspect. Your UI in objective-C were not done to load Objective-C code that could modify the objective-C runtime!!! So if you want to build a simple user interface loading videos you can do it in a parallel process just using fork and paying a bit of attention. because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 20:14, Stéphane Ducasse stephane.duca...@inria.fr wrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Why ? Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Opal hook?
Hi when I load a class whose superclass is not in the image I have the impression that the system create a subclass from ProtoObject and I would like to be able to control the superclass. ProtoObject subclass: #Adaptor1Example instanceVariableNames: 'customers accountID address name phoneNumber' classVariableNames: '' poolDictionaries: '' category: 'Examples-Cookbook' Any idea where to look? Stef
Re: [Pharo-dev] Responsible development
On Mon, Dec 2, 2013 at 6:47 AM, p...@highoctane.be p...@highoctane.bewrote: As Clement explained to be, the Cmd + . combo is only tested on VM bytecode backjumps. It is also tested on every non-primitive send. So, if the bytecode is stuck with no backjumps, it is definitely stuck. I'd like to see where this occurs in the VM (maybe in the hope I could have a slow, but interruptible VM at all times) - this could take the form of a setting that gets turned on. You can always send SIGUSR1 to the VM on linux and Mac OS. You'll need to open the console to see the output unless you run the VM from a terminal. But you can find out what it's doing. Phil On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/2 Pavel Krivanek pavel.kriva...@gmail.com: User interrupt (cmd + .) was not working? Most of the times for simple things it does, but sometimes it doesn't. Regards, Esteban A. Maringolo -- best, Eliot
Re: [Pharo-dev] Responsible development
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Why ? Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find. I prefer to have cache than to have forked processes around. Stef
Re: [Pharo-dev] Responsible development
In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phds topic. On Dec 2, 2013, at 8:25 PM, kilon alios kilon.al...@gmail.com wrote: there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com http://nabble.com/.
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 20:27, Stéphane Ducasse stephane.duca...@inria.fr wrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Why ? Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find. I prefer to have cache than to have forked processes around. Cache will not help you killing Nautilus when it freezes your image (why cache by the way ?) Ben Stef
Re: [Pharo-dev] Responsible development
On 02 Dec 2013, at 19:30, Stéphane Ducasse stephane.duca...@inria.fr wrote: In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phds topic. On Dec 2, 2013, at 8:25 PM, kilon alios kilon.al...@gmail.com wrote: there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you. frank I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Responsible development
Hey, nice. I'll try that. On Mon, Dec 2, 2013 at 8:25 PM, Eliot Miranda eliot.mira...@gmail.comwrote: On Mon, Dec 2, 2013 at 6:47 AM, p...@highoctane.be p...@highoctane.bewrote: As Clement explained to be, the Cmd + . combo is only tested on VM bytecode backjumps. It is also tested on every non-primitive send. So, if the bytecode is stuck with no backjumps, it is definitely stuck. I'd like to see where this occurs in the VM (maybe in the hope I could have a slow, but interruptible VM at all times) - this could take the form of a setting that gets turned on. You can always send SIGUSR1 to the VM on linux and Mac OS. You'll need to open the console to see the output unless you run the VM from a terminal. But you can find out what it's doing. Phil On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/2 Pavel Krivanek pavel.kriva...@gmail.com: User interrupt (cmd + .) was not working? Most of the times for simple things it does, but sometimes it doesn't. Regards, Esteban A. Maringolo -- best, Eliot
Re: [Pharo-dev] Responsible development
Of course, and obviously in Squeak/Pharo, code itself is kind of mutable state... (you modify some methodDictionary, subclasses etc...). So applying concurrency to tools handling that shared mutable state is... HARD. 2013/12/2 Frank Shearar frank.shea...@gmail.com On 02 Dec 2013, at 19:30, Stéphane Ducasse stephane.duca...@inria.fr wrote: In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phds topic. On Dec 2, 2013, at 8:25 PM, kilon alios kilon.al...@gmail.com wrote: there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you. frank I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :) personnally I would be really against because just forking is just a way to have a lot more mess in the future. Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk yuriy.tymc...@me.com wrote: On 02 Dec 2013, at 17:42, Sean P. DeNigris s...@clipperadams.com wrote: Uko2 wrote It’s not about stability of pharo 3, it about concurrency... This thread doesn’t seem to have any reason Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesn’t mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Let’s take moose for example. While it is importing a model everything freezes. Is there a reason for that? I don’t see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko - Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com http://nabble.com/.
Re: [Pharo-dev] Unifying Testing Ideas
Sean P. DeNigris wrote - Phexample and BabyMock both require subclassing from their own TestCase subclass, so they can't be used together. The reason for having the base class is to verify the expectations at the end of the tests automatically. Doing this manually is possible (context assertSatisfied), but probably people would forget it without this automatic mechanism. In Java for example, mock libraries use custom JUnit runners to do this, but I haven't found something like this in SUnit. If there is a better way to do this please let me know. -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726837.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] transcript is plain bad
EstebanLM wrote yes, the transcript is ThreadSafeTranscript Does ThreadSafe mean I don't have to wrap all my debug logging in WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot of time :) - Cheers, Sean -- View this message in context: http://forum.world.st/transcript-is-plain-bad-tp4726795p4726848.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Grease conflicts #packages with RPackage
Stef wrote: Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I don’t know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I don’t exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethodpackageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan
Re: [Pharo-dev] Roassal Bug related to Athens?
On 2 December 2013 17:14, Usman Bhatti usman.bha...@gmail.com wrote: Hello Igor, Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019 I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error. right. Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice? yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago). http://lmgtfy.com/?q=nativeboost+session+awarel=1 regards, Usman -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Grease conflicts #packages with RPackage
On Mon, Dec 2, 2013 at 6:03 PM, Stephan Eggermont step...@stack.nl wrote: Stef wrote: Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I don’t know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. You will only have problems with class side #packages. Are all those 35 class side? Cheers, And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I don’t exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethodpackageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Roassal Bug related to Athens?
http://code.google.com/p/nativeboost/wiki/SessionManagement On 2 December 2013 22:02, Igor Stasenko siguc...@gmail.com wrote: On 2 December 2013 17:14, Usman Bhatti usman.bha...@gmail.com wrote: Hello Igor, Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019 I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error. right. Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice? yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago). http://lmgtfy.com/?q=nativeboost+session+awarel=1 regards, Usman -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Roassal Bug related to Athens?
and how exactly you expect that people would know what a session is ? or why that would be an issue with nativeboost or Athens ? I did not even know that there was a tutorial included about it in the Athens tutorial which is package that existing in the smalltalkhub repo of Athens in smalltalkhub for some strange reason the tutorial is not included with the standard distribution of Pharo 3 even though Athens suppose to play a huge role for Pharo in the future replacing all drawings. I have even purchased both Pharo books and they don't mention this. You cant blame him for not knowing or not googling about it. You cant google what you are not aware of. And you cant be aware if you dont have some sort of documentation in front of you. And no a maiing is not documentation. The least you could do is at smalltalkhub description tell to people to go fetch the Athens-Tutorial package and learn from it. At least that would save you a substantial amount of replies in the near future. From the tutorial alone he would have learned about the session issue and he would not have to ask and that would save him time and you. I love your work and appreciate your effort but whether we like it or not, these things are very important. On Mon, Dec 2, 2013 at 11:02 PM, Igor Stasenko siguc...@gmail.com wrote: On 2 December 2013 17:14, Usman Bhatti usman.bha...@gmail.com wrote: Hello Igor, Moose 5.0 is using Athens as default canvas for Roassal and we have bug with Roassal that seems to be related to Athens. http://code.google.com/p/moose-technology/issues/detail?id=1019 I think it is related to the fact that we create a surface in the OS with Athens and once we quit the image, the surface is destroyed as well. So, when image is restarted with the visualization trying to use the surface, we get the error. right. Could you point to what possibly can be done to avoid this error? Merely checking the existence of an appropriate drawing surface in Athens every time visualization is drawn, would it suffice? yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago). http://lmgtfy.com/?q=nativeboost+session+awarel=1 regards, Usman -- Best regards, Igor Stasenko.
[Pharo-dev] NativeBoost String Handling Bug?
I'm tearing my hair out wrapping FMOD! I finally isolated the Mac VM-crashing bug (works in Windows) to: The reason I suspect NB is that I made a simple Xcode C project which (I think) does the exact same thing, which works perfectly. I uploaded it to https://github.com/seandenigris/FMODExample . To use it, just change SOUND_FILE_PATH in main.c to the location of the included train whistle.mp3 file From Pharo, however, it only works if the path to the mp3 is: - *exactly* /Volumes/NO NAME/Smalltalk/Working Images/Salty Dog/Sounds/train whistle.mp3. No other combination seems to work on my machine - even direct parents and subdirectories of that one! WTH!! - or apparently a path without spaces The thing that has me scratching my head is that even with spaces it works from Xcode! To see the error from Pharo: 1. Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; package: 'FMOD'; load. 2. Copy the FMOD Programmers API folder from the C Sample into the image folder. 3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'. I'd relly appreciate Igor or another NB guru (if there is such a thing, lol) to take a look. I've spent days chasing this down, and I'm out of ideas... Thanks. - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] NativeBoost String Handling Bug?
On 2 December 2013 22:31, Sean P. DeNigris s...@clipperadams.com wrote: I'm tearing my hair out wrapping FMOD! I finally isolated the Mac VM-crashing bug (works in Windows) to: The reason I suspect NB is that I made a simple Xcode C project which (I think) does the exact same thing, which works perfectly. I uploaded it to https://github.com/seandenigris/FMODExample . To use it, just change SOUND_FILE_PATH in main.c to the location of the included train whistle.mp3 file From Pharo, however, it only works if the path to the mp3 is: - *exactly* /Volumes/NO NAME/Smalltalk/Working Images/Salty Dog/Sounds/train whistle.mp3. No other combination seems to work on my machine - even direct parents and subdirectories of that one! WTH!! - or apparently a path without spaces sound really as some bug.. and similar to system() call. my versions is: - it could be that strings are expected to be 16-byte aligned - that there's some bug with converting to null-terminated C string The thing that has me scratching my head is that even with spaces it works from Xcode! To see the error from Pharo: 1. Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; package: 'FMOD'; load. 2. Copy the FMOD Programmers API folder from the C Sample into the image folder. 3. FmodLibrary exampleFmodStylePlaying: '/path/to/train whistle.mp3'. I'd relly appreciate Igor or another NB guru (if there is such a thing, lol) to take a look. I've spent days chasing this down, and I'm out of ideas... Thanks. - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] NativeBoost String Handling Bug?
sound really as some bug.. and similar to system() call. my versions is: - it could be that strings are expected to be 16-byte aligned - that there's some bug with converting to null-terminated C string Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help... - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726878.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] NativeBoost String Handling Bug?
nevermind, i think i found the cause. (system call now is working) On 3 December 2013 02:08, Igor Stasenko siguc...@gmail.com wrote: On 3 December 2013 00:32, Sean P. DeNigris s...@clipperadams.com wrote: sound really as some bug.. and similar to system() call. my versions is: - it could be that strings are expected to be 16-byte aligned - that there's some bug with converting to null-terminated C string Great! It's be nice to get this and system calls working in one shot... how do we proceed? How do we test? I'm willing to help... if there some bug, it must be in NBExternalString which responsible for marshalling strings. try to change the alignment for the pointer and see how it goes in reserveStackBytes: numBytesOrBlock andStoreAddrTo: aTemp because right now it aligns the total space to reserve on stack (amount to subtract from SP), but not SP itself alignment should use powers of 2 , of course. Cheers, Sean -- View this message in context: Re: NativeBoost String Handling Bug?http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726878.html Sent from the Pharo Smalltalk Developers mailing list archivehttp://forum.world.st/Pharo-Smalltalk-Developers-f1294837.htmlat Nabble.com. -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] NativeBoost String Handling Bug?
Name: NativeBoost-Core-IgorStasenko.140 Name: NativeBoost-Tests-IgorStasenko.75 try and see if it works for you (and try syscall too, if yes then i think we can finally close the bug entry). P.S. thanks for being persistent on this one.
Re: [Pharo-dev] transcript is plain bad
On 3 December 2013 02:59, Esteban A. Maringolo emaring...@gmail.com wrote: 2013/12/2 Sean P. DeNigris s...@clipperadams.com: EstebanLM wrote yes, the transcript is ThreadSafeTranscript Does ThreadSafe mean I don't have to wrap all my debug logging in WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot of time :) According to the implementation it means there is a Mutex stopping multiple processes from doing operations (#nextPut:, #nextPutAll:) at the same time. It is... who sends the message first will be received happily, whoever is second will have to wait in a semaphore :D Funny outputs might happen if two different senders use #nextPut: intertwined. (other frameworks only left complete line outputs to loggers, to avoid this kind of scenarios). imo this is exactly the case when for 0.1% of chance that it will be required once, you spend tons of effort to make it work, means: overengineering. And, btw, good luck with solving the Halting problem along the way when you will be implementing this 'complete line' (when multiple threads sending output, but don't allowed to mix the lines) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] NativeBoost String Handling Bug?
Igor Stasenko wrote if yes then i think we can finally close the bug entry). I updated the issue and made your packages into a slice: https://pharo.fogbugz.com/default.asp?7542 SLICE-Issue-7542-NB-system-example-SeanDeNigris.1 - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Versionner CI?
I was surprised there was no job on community contributions... - Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-CI-tp4726899.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Unifying Testing Ideas
I see the only correct way to build a good testing environment: tests should be basically objects, not methods. -- Best regards, Dennis Schetinin 2013/12/3 Sean P. DeNigris s...@clipperadams.com Attila Magyar wrote The reason for having the base class is to verify the expectations at the end of the tests automatically. Doing this manually is possible (context assertSatisfied), but probably people would forget it without this automatic mechanism. In Java for example, mock libraries use custom JUnit runners to do this, but I haven't found something like this in SUnit. If there is a better way to do this please let me know. I understand the motivation. My question is how do we create appropriate hooks so that we don't get into these conflicts? I made a few enhancements to BabyMock: - anyArgument now inst var of BabyMockTestCase, similar to BmAnyMessage - #does: now optionally takes arguments The second one turns: handle := FMOD_SYSTEM new. library should receive: #FMOD_System_Create:; with: [ :a | a = handle ifTrue: [ handle := a. handle handle: 20. true ] ifFalse: [ false ] ]; answer: 0. library should receive: #FMOD_System_Init:; with: [ :a | a = handle ]; answers: 0. ...into: library should receive: #FMOD_System_Create:; with: FMOD_SYSTEM new; does: [ :h | h handle: 20. 0 ]. library should receive: #FMOD_System_Init:; with: [ :a | a handle = 20 ]; answers: 0. ... eliminating the temporary, and the separate #with: and #answer: send in the first expectation. I pushed them to http://smalltalkhub.com/mc/SeanDeNigris/FMOD/main/ since that's where I was using them, but if you give me access to the BM repo and you like the changes, I will clean them up and push there. - Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726855.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Versionner Impressions
Wow, it's light years ahead of where I last saw it! It is already much better than writing configs by hand. I was able to do about 75% via the UI to go from nothing, to an initial commit with a baseline including dependent projects and my packages. A few notes. It would be nice to be able... • to specify other repos for dependent project • to select the project's repo from a list if it's already known by the system instead of having to type Bugs: • I added BabyMock as a dependent project, Versionner showed (stable) in the UI, but when it added it to the baseline, it was loading bleeding edge • Added packages were a mixture of strings and symbols i.e. 'FMOD', #FMODSpecification, 'BabyMock-Core' • I added a main repository to Versionner, but it didn't appear in baseline when clicked update dev • If you accidentally navigate away from the version you're viewing, e.g. by clicking on another version, all changes are lost without warning Keep up the great work. This is a very important tool! - Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Impressions-tp4726902.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] NativeBoost String Handling Bug?
Yes, thank you. On 3 December 2013 05:57, Sean P. DeNigris s...@clipperadams.com wrote: Igor Stasenko wrote if yes then i think we can finally close the bug entry). I updated the issue and made your packages into a slice: https://pharo.fogbugz.com/default.asp?7542 SLICE-Issue-7542-NB-system-example-SeanDeNigris.1 - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-String-Handling-Bug-tp4726860p4726895.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] transcript is plain bad
Am 02.12.2013 um 19:56 schrieb Stéphane Ducasse stephane.duca...@inria.fr: The return of the toothpick is near. o/ No I will finish my logger :) From next week on I will have a little time to work on it, too. If you like we can discuss a few things and bring to some usable state. Norbert
Re: [Pharo-dev] Versionner Impressions
You're using it in 3.0? Norbert Am 03.12.2013 um 06:43 schrieb Sean P. DeNigris s...@clipperadams.com: Wow, it's light years ahead of where I last saw it! It is already much better than writing configs by hand. I was able to do about 75% via the UI to go from nothing, to an initial commit with a baseline including dependent projects and my packages. A few notes. It would be nice to be able... •to specify other repos for dependent project •to select the project's repo from a list if it's already known by the system instead of having to type Bugs: •I added BabyMock as a dependent project, Versionner showed (stable) in the UI, but when it added it to the baseline, it was loading bleeding edge •Added packages were a mixture of strings and symbols i.e. 'FMOD', #FMODSpecification, 'BabyMock-Core' •I added a main repository to Versionner, but it didn't appear in baseline when clicked update dev •If you accidentally navigate away from the version you're viewing, e.g. by clicking on another version, all changes are lost without warning Keep up the great work. This is a very important tool! - Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-Impressions-tp4726902.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
