December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Responsible development

by Roberto Minelli

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

Dec. 2, 2013

Responsible development

by Yuriy Tymchuk

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

Dec. 2, 2013

Re: [Pharo-dev] [Moose-dev] Re: Similarity Matrix

by Alexandre Bergel

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

Dec. 2, 2013

Re: [Pharo-dev] How to update Deep into Pharo Chapter

by Damien Cassou

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.ducasse(a)inria.fr> wrote: > thanks! > > On Nov 28, 2013, at 10:27 PM, Gabriel Cotelli <g.cotelli(a)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.ducasse(a)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.cotelli(a)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.cassou(a)gmail.com> >> wrote: >>> >>> On Tue, Nov 26, 2013 at 6:34 PM, Gabriel Cotelli <g.cotelli(a)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

Dec. 2, 2013

Re: [Pharo-dev] Pharo picture

by Alexandre Bergel

Nice one :) Alexandre > Le 02-12-2013 Ã 8:34, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> a Ã©crit : > > Accidentally stumbled upon: http://www.deviantart.com/art/October-26-412316678 > > Have a nice week everyone! > Uko

Dec. 2, 2013

Re: [Pharo-dev] Nautilus Tree

by kilon alios

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.minelli(a)usi.ch>wrote: > > 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.pharo(a)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.alios(a)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.goubier(a)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 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 < > sean(a)clipperadams.com > >> <mailto:sean@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 > >> > >> > > > > >

Dec. 2, 2013

Pharo picture

by Yuriy Tymchuk

Accidentally stumbled upon: http://www.deviantart.com/art/October-26-412316678 Have a nice week everyone! Uko

Dec. 2, 2013

[pharo-project/pharo-core] ccbd00: 30615

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: ccbd00698e95b025f2059699f368c9968eb31993 https://github.com/pharo-project/pharo-core/commit/ccbd00698e95b025f2059699… Author: Jenkins Build Server <board(a)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

Dec. 2, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30615 Home: https://github.com/pharo-project/pharo-core

Dec. 2, 2013

Re: [Pharo-dev] Nautilus Tree

by Roberto Minelli

> 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.pharo(a)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.alios(a)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.goubier(a)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 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 <sean(a)clipperadams.com >> <mailto:sean@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 >> >> >

Dec. 2, 2013