August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Image startup classe(s) ?

by StÃ©phane Ducasse

there is a difference between startup and bootstrap. if you have a working image and you want to launch it. Easy look at the mail of javier else then look at the C part of GNU smalltalk and how you have to make sure that you have chicken before an egg. We are starting to work on that for pharo. but just starting. Stef On Aug 5, 2010, at 6:09 AM, James Ladd wrote: > I'm interested in which classes are part of the startup/bootup of the Pharo Image. > What classes get called first to bring all the other items online, like the workspace? > > Rgs, James. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by StÃ©phane Ducasse

self contained. In a project I do not care what the world is doing. What I want is my exact project to load the way I want and all the time in a productable manner. So I want to control which part may change (my code) and which part is curved into the stone. So duplication is not a problem. Then if I load a specific version then the recursion of the model make sure that it will load all the necessary package. so this is not like we do not have abstractions to build upon. Stef On Aug 5, 2010, at 4:32 AM, Javier PimÃ¡s wrote: > Maybe I saying nonsense, if that is the case just ignore me but... why have many packages that do almost exactly the same? Aren't you going to get a lot of repeated code lying around in different packages? ie. I think most packages have almost exactly the same baselines for pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX and let them stay in the same class and package? Or maybe adding other pragma to specify which pharo version each baseline/version describes. I'm sure there could be other solutions. That way you'd have all the configurations in the same place and also reuse code if needed instead of duplicating it. > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Miguel, > > I think that this kind of approach makes lots of sense ... I've toyed with the idea of a "white list" of configuration versions, but someone would have to be responsible for maintaining the "white list" and the users would have to responsible for using the "white list" ... > > A repository per version is very simple and gives the maintainer flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribiÃ³: > Why there should be repository per release? As i know > MetacelloConfiguration already contains information about compatible > Pharo versions. > > Because is cleaner and as the releases of Pharo diverge a lot more, the > code to install package becomes full of conditionals to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals an several > variations of preDoits and postDoits and test what version image is > ConfigurationOfMagma is being ran. After a couple of hours I gave up. > > The correct solution is to have a specific ConfigurationOfMagma for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update the > ConfigurationOfXXX without disturbing or broke the stable ones. > - It permits the ConfigurationOfXXX code to remain clean, without a > conditionals for every posible combination of release image version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to decide when to > stop supporting old version of a certain package by deleting the old > versionXX: methods of the ConfigurationOfXXX in the newer pharo > releases. Not always is good to be able to install each and every > version of a package in the newest release of pharo (maybe even old > versions won't work in the new releases, like the menu registration > issue or classes that doesn't belong to the core image) > - It permits to issue maintenance ConfigurationOfXXX releases for a > stable or "old-stable" image releases, without altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: > El miÃ©, 04-08-2010 a las 11:46 +0200, Torsten Bergmann escribiÃ³: > Hi Miguel, > > hey, nice! If we follow this convention then it is easy to implement > a universe browser that selects the correct universe repo and > displays all loadable versions. Loading stuff should just be > a few clicks away - I personally hate all this MC/Gofer typing ... > > Attached is a quick/simple implementation of such a browser: > > Mann, Sie sind Ã¼ber schnell! > > I tested it in PharoCore 1.0 and worked after a few changes, but the > interface is cool. +1 to aim it be the default universe browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't register on menu because of the > lacking pragmas) > - UniverseBrowser pharoUniverse returns PharoCore1.0 instead of Pharo10 > to build the universe name. This could be changed in two ways: > - Add a system property that states the image repository: > SystemVersion current universeName "Returns Pharo10 for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the gofer package I uploaded to > PharoInbox (if it is approved, so there is only a unique source for > converting image version string to universe names) > > Other than that, I like the browser. > > > > - file in the attached changeset (I tried in Pharo 1.2) > - open via World menu -> "Universe Browser" > - select the configuration you want and from the context menu choose > -- "Load configuration" -> only the config is loaded > -- "Load configuration and latest version" -> the config and lates version is loaded > > Have fun! I used Pharo 1.2 - should work in Pharo 1.0 and 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2010

[Pharo-project] Pharo book error

by laurent laffont

Hi, the search field in header raise an error. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

Aug. 5, 2010

[Pharo-project] [ANN 1.2] pre-built core#12082

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27329/PharoCore-1.2-12082.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 5, 2010

Re: [Pharo-project] Image startup classe(s) ?

by Javier PimÃ¡s

I'm not sure if this is what you are looking for, but I think you should see SmalltalkImage>>snapshot:andQuit:embedded:. This method get's called when saving the image. And when loading an image, the VM starts from the middle of it, just after the line that sends primitiveSnapshot. Also you can inspect SmalltalkImage's StartUpList class var. All classes in that collection are sent the message startUp: via processStartUpList: method. Hope it helps. Regards, Javier. 2010/8/5 James Ladd <james_ladd(a)hotmail.com> > I'm interested in which classes are part of the startup/bootup of the > Pharo Image. > What classes get called first to bring all the other items online, like the > workspace? > > Rgs, James. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 5, 2010

[Pharo-project] Image startup classe(s) ?

by James Ladd

I'm interested in which classes are part of the startup/bootup of the Pharo Image. What classes get called first to bring all the other items online, like the workspace? Rgs, James.

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Javier PimÃ¡s

Maybe I saying nonsense, if that is the case just ignore me but... why have many packages that do almost exactly the same? Aren't you going to get a lot of repeated code lying around in different packages? ie. I think most packages have almost exactly the same baselines for pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX and let them stay in the same class and package? Or maybe adding other pragma to specify which pharo version each baseline/version describes. I'm sure there could be other solutions. That way you'd have all the configurations in the same place and also reuse code if needed instead of duplicating it. Regards, Javier. On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Miguel, > > I think that this kind of approach makes lots of sense ... I've toyed with > the idea of a "white list" of configuration versions, but someone would have > to be responsible for maintaining the "white list" and the users would have > to responsible for using the "white list" ... > > A repository per version is very simple and gives the maintainer > flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > >> El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribiÃ³: >> >>> Why there should be repository per release? As i know >>> MetacelloConfiguration already contains information about compatible >>> Pharo versions. >>> >> >> Because is cleaner and as the releases of Pharo diverge a lot more, the >> code to install package becomes full of conditionals to handle the >> distinct issues with each pharo release. >> For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, 1.1 and >> 1.2. >> But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 >> doesn't have the classes DirectoryEntryDirectory and DirectoryEntryFile >> that are used by the new magma version. >> So I had to modify the configuration with conditionals an several >> variations of preDoits and postDoits and test what version image is >> ConfigurationOfMagma is being ran. After a couple of hours I gave up. >> >> The correct solution is to have a specific ConfigurationOfMagma for each >> released pharo version. >> This have benefits also: >> - It permits the unstable repository to heavily update the >> ConfigurationOfXXX without disturbing or broke the stable ones. >> - It permits the ConfigurationOfXXX code to remain clean, without a >> conditionals for every posible combination of release image version and >> package to be installed version >> - It permits the maintainer of a ConfigurationOfXXX to decide when to >> stop supporting old version of a certain package by deleting the old >> versionXX: methods of the ConfigurationOfXXX in the newer pharo >> releases. Not always is good to be able to install each and every >> version of a package in the newest release of pharo (maybe even old >> versions won't work in the new releases, like the menu registration >> issue or classes that doesn't belong to the core image) >> - It permits to issue maintenance ConfigurationOfXXX releases for a >> stable or "old-stable" image releases, without altering the >> configurationOfXXX in other repositories >> Cheers >> >> 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: >>> >>>> El miÃ©, 04-08-2010 a las 11:46 +0200, Torsten Bergmann escribiÃ³: >>>> >>>>> Hi Miguel, >>>>> >>>>> hey, nice! If we follow this convention then it is easy to implement >>>>> a universe browser that selects the correct universe repo and >>>>> displays all loadable versions. Loading stuff should just be >>>>> a few clicks away - I personally hate all this MC/Gofer typing ... >>>>> >>>>> Attached is a quick/simple implementation of such a browser: >>>>> >>>>> Mann, Sie sind Ã¼ber schnell! >>>> >>>> I tested it in PharoCore 1.0 and worked after a few changes, but the >>>> interface is cool. +1 to aim it be the default universe browser in 1.2. >>>> Simple, to the point. >>>> In Pharo 1.0 I had: >>>> >>>> - Open it with Universe open (doesn't register on menu because of the >>>> lacking pragmas) >>>> - UniverseBrowser pharoUniverse returns PharoCore1.0 instead of Pharo10 >>>> to build the universe name. This could be changed in two ways: >>>> - Add a system property that states the image repository: >>>> SystemVersion current universeName "Returns Pharo10 for image >>>> releases 1.0, 1.0.1, 1.0.5, etc) >>>> - Use the equivalent method in the gofer package I uploaded to >>>> PharoInbox (if it is approved, so there is only a unique source for >>>> converting image version string to universe names) >>>> >>>> Other than that, I like the browser. >>>> >>>> >>>> >>>> - file in the attached changeset (I tried in Pharo 1.2) >>>>> - open via World menu -> "Universe Browser" >>>>> - select the configuration you want and from the context menu choose >>>>> -- "Load configuration" -> only the config is >>>>> loaded >>>>> -- "Load configuration and latest version" -> the config and lates >>>>> version is loaded >>>>> >>>>> Have fun! I used Pharo 1.2 - should work in Pharo 1.0 and 1.1 too >>>>> (havent tested). >>>>> >>>>> Bye >>>>> T. >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> Cheers >>>> >>>> -- >>>> Miguel CobÃ¡ >>>> http://miguel.leugim.com.mx >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 5, 2010

Re: [Pharo-project] update to OCompletion

by Tim Mackinnon

I shall definitely give that a read - especially now i have an example to think back on. By the way - these chapters that people keep writing, are a great help (the monticello one certainly took away a huge load of frustrations I was having) - so thanks to everyone that keeps chipping away at them! tim On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: > I am glad I helped. You can also take a look to the Metacello draft > we wrote for Pharo By Example 2. I attach it.

Aug. 4, 2010

Re: [Pharo-project] Pharo 1.1. impressions and suggestions

by Mariano Martinez Peck

Hi Janko. All this feedback is very much appreciatted. I will answer inline what I know. > Suggestions: > =========== > > - some Start button? Maybe named World? Not just ProfStef's 'go > evaluation' (which is much better than nothing of course). At least a > right click to come to a Word menu must be explained somewhere at the > start, otherwise one is lost how to proceed. > you mean in the welcome workspace to put the button to replace the evaluation of ProfStef go ? > > - window buttons on Linux and Windows are on the wrong side. This is > very dangerous thing, user can quickly make en error and accidentialy > close a window. In any case it is very very annoying! A real > showstopper for me! > > I agree!!! Several times was asked to has this behavior depending of the OS where you are. gary any idea how to do this? > - System browser has no package view, just categories. This is > confusing to newcomers, what are packages, what categories? Having > packages also in a category view will be more understandable. > > +1 But you can see O2. It has packages. > - back button in browser, like on web browsers! > > O2 has too > - why hierarchy button opens a new browser, why rather not toggle > hierarchy/category view in the same window? > I like the idea > > > - Browser opens just too small size. It should open in a size > recomendable for further development (like for encouraging the 10 > lines per method rule) > > +1 > > - Search line on the top of browser should have a 'Search:' at the > start, to find it easily with an eye. What if it ignore the > upper/lowercase by default. Users are used of ignore-case search from > elsewhere, like Google. > > Yes, in O2 it is exactly like that. I wish OB to be like that too. Lukas? > - Still no breakpoints! Please introduce them, Squeak/Pharo seems > nowadays the only Smalltalk without breakpoints! > I would love this also so that not to change my code or forget them. > > - why isn't a class comment visible below the class definition in the > same pane, as was once? > would be nice too...maybe there is a simple setting for that? in such case I can enable for the dev images if people agree > > - Undocumented classes should have a special mark to encourage > commenting them. Maybe that question mark button (?) in red color? > > good idea Cheers Mariano > > Best regards > Janko > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] Pharo 1.1. impressions and suggestions

by StÃ©phane Ducasse

Thanks janko Give me another engineer and we redo completely the browsers :) Stef > Dear Pharoers, > > I just finished syncing new Aida from VW on new Pharo 1.1 and during > that I collect few impressions and also suggestions, how to proceed. > Please find them as a kind of "concrete congratulation" to your work :) > > Impressions: > =========== > > - design is nice and polished, default font looks professional > - responsiveness and speed of browsing seems now fast enough > - very nice and simple Word menu > - nicely enhanced Inspector > - nice Google-like search in browser > - Aida is among few projects on DEVImageWorkspace, thanks guys! > - Settings browser is a real progress forward, nicely organized, but > with still too much choices. I suppose many settings are never or > really rarely used, those should be put outside this Settings browser. > - Help system also looks very promising! With an introduction of > context help also (like ? icons elsewhere) we can come close to ideal > help. Of course we need also good docs writers to write a really good > help, nicely balanced between a newcomer than expert viewpoint. > > Suggestions: > =========== > > - some Start button? Maybe named World? Not just ProfStef's 'go > evaluation' (which is much better than nothing of course). At least a > right click to come to a Word menu must be explained somewhere at the > start, otherwise one is lost how to proceed. > > - window buttons on Linux and Windows are on the wrong side. This is > very dangerous thing, user can quickly make en error and accidentialy > close a window. In any case it is very very annoying! A real > showstopper for me! > > - System browser has no package view, just categories. This is > confusing to newcomers, what are packages, what categories? Having > packages also in a category view will be more understandable. > > - back button in browser, like on web browsers! > > - why hierarchy button opens a new browser, why rather not toggle > hierarchy/category view in the same window? > > - in general: avoid opening new windows, rather "reuse" the same one. > This is the current usability trend elsewhere. > > - What about introducing tabs in browser? This is very very useful and > handy, mostly because we are used of tabs from web browsers. > > - Browser opens just too small size. It should open in a size > recomendable for further development (like for encouraging the 10 > lines per method rule) > > - What if we introduce "add class", "add method" etc. dialogs in menu > too? Yes yes I know, but look from a newcomer perspective.. > > - Search line on the top of browser should have a 'Search:' at the > start, to find it easily with an eye. What if it ignore the > upper/lowercase by default. Users are used of ignore-case search from > elsewhere, like Google. > > - Inspector and explorer still two different but very similar things. > Inspector is now much better than before, having tree view of > inspected object do we still need to add confusion with additional > explorer? > > - Help needs a search field. API docs hierarchy is quite deep and > without a search near to unusable. Also, in a System browser there > need to be a link to the corresponding help text. And vice versa, > link to the class in browser from help. > > - Still no breakpoints! Please introduce them, Squeak/Pharo seems > nowadays the only Smalltalk without breakpoints! > > - why isn't a class comment visible below the class definition in the > same pane, as was once? > > - Undocumented classes should have a special mark to encourage > commenting them. Maybe that question mark button (?) in red color? > > - Popup menu in method pane is too large, some choices not really so > important to be there (like paste..., explore it, do again(redo?) ) > - Popup menu: choices find, find again, extended search should be > joined in one find... > - Popup menu: set breakpoint, clear breakpoint > > > Best regards > Janko > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010