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

Re: [Pharo-project] [Vm-dev] SystemTracer64 progress

by Laval Jannik

Hi David, I cannot write my changes. So you can have them in attachment. In these .cs, there is a merge with your version .15. And it works with Pharo. Cheers Jannik On Jan 12, 2010, at 04:55 , David T. Lewis wrote: > > Over the weekend I made some progress in getting SystemTracer updated > to do 64-bit image tracing. Previously SystemTracer64 did not work on > little-endian machines (Mantis 5240). This is corrected now, and the > code is on SqueakSource in project "SystemTracing". > > I can now trace a Squeak 3.10.2 image to 64-bit format on my Linux > AMD box (little endian), producing a runnable 64-bit image. For > an up to date Squeak trunk image, I can trace a 64 image that > loads and runs (display opens and things start working), but that > has problems with resuming its background processes (low space > watcher etc). Possibly it's related to the block closure changes, > although I believe there was an earlier report of a Pharo image > with block closures being successfully traced to 64 bit format. > > Dave >

Jan. 12, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by John M McIntosh

Actually Michael the RBInternalSpellChecker does use the macintosh spell checker plugin so it does reuse. But I think we had a unix or open source alternative? Someone could go look. I found on the iPhone the currently RBInternalSpellChecker took up lots of memory, and did a frightful unpack initialization process at startup time (many many seconds) on an iPhone. It was ditched... On 2010-01-11, at 2:01 PM, Michael Rueger wrote: > On 1/11/2010 10:59 PM, Stan Shepherd wrote: > >> There is also an internal spell check, for other platforms. >> RBInternalSpellChecker. > > <broken record on> > in Sophie we built a platform independent spell checker > </broken record on> > > ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 12, 2010

Re: [Pharo-project] Presenter and Project will die aren't they ?

by John M McIntosh

Ah well yes Michael suffered thru managing, testing, and working with all those browsers & plugins. I suffered thru trying to figure out how it all worked... At least on the mac. Here's the current issue, because: Microsoft shafted netscape by abandoning the netscape API, then shafted apple by not providing an alternative we had the strange mixture of a solution for os-x, windows, X11. Then of course Microsoft IE on macintosh would change behaviour from version to version to screw with FireFox & Mozilla etc. Let alone worrying about Opera which kinda worked. Fortunately Microsoft abandon the Mac browser market, and Apple introduced Safari which again was slightly different. Now on 10.6 we had this problem an abandon API for plugins, that needed to move forward, also into the 64bit world. So Apple changed things again to either let you run Safari in 32bit using old plugins (busted), or using a modified 64bit plugins api, but not both at the same time. The words busted, non-existant, abandon, (implied ugly), appear quite a few times in the sentences above. Also on every browser version change, or operating system major version change something was just slightly funky enough to bring down the house of cards. So, time is better spent in getting 64bit squeak working, since there is plenty of hours still needed to fixup all the plugins, and check that the VM is actually sane... On 2010-01-11, at 1:59 PM, Michael Rueger wrote: > On 1/11/2010 10:58 PM, Michael Rueger wrote: > >> forget squeak/pharo in the browser. > > for those not in the know: > I'm one of the poor guys who actually spent a *lot* of time making it > possible ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 12, 2010

Re: [Pharo-project] [ANN] WorkingSet

by Damien Cassou

On Mon, Jan 11, 2010 at 9:33 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> That's strange, since I use Toolset for these queries. Should I use something else? > > I am using OB, but I get the old system browser in some cases: for > senders, implementors and sets of classes. What ToolSet do you use? In the Pharo images, the ToolSet I install takes care of launching OB in all cases. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Jan. 12, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Miguel Enrique CobÃ¡ Martinez

> BTW. How did you compute dependencies in packages you aren't completely > aware of the details. I remember a tool for this. Where can I find them? > I found this: http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php that appears to be the one you are using. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

Re: [Pharo-project] Refactoring Browser depenences

by Miguel Enrique CobÃ¡ Martinez

> > How can I get the dependencies of a given package by software? Mind to > share the package? > > Thanks I think I found it. Dependency Browser from HernÃ¡n Morales: http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php Or are you using something else? Thanks anyway. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

Re: [Pharo-project] Refactoring Browser depenences

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 02-01-2010 a las 17:42 +0100, Lukas Renggli escribiÃ³: > > Thanks Lukas. I was looking at the pdf about the dependencies of OB but it > > is different to what you told me at the beginning. For example, you told me: > > > > OB-Refactory --> Refactoring-Core, OB-Standard > > OB-Regex --> Refactoring-Core, OB-Standard > > > > But in the pdf I see OB-Regex --> OB-Refactory > > > > I just need to know the DIRECT dependencies. Those classes you use, extend, > > reference or whatever. If OB-Regex used directly classes from OB-Standard > > for example, ok, then it is a dependency. But, if you told me OB-Standard > > just because it was a dependency for OB-Refactory (and this was a dependency > > for OB-Regex), then, I don't care about it. I just need to know the direct > > dependencies (not also the dependencies or my dependencies haha ) > > I don't get what you mean, but the PDF is correct because it is > created from the code. How can I get the dependencies of a given package by software? Mind to share the package? Thanks > The PDF only contains direct dependencies, > transitive ones are removed, only the information you need to know to > load correctly. We create the Seaside loaders with this information. > > Lukas > > > > > > Cheers > > > > Mariano > > > > > > > >> > >> Lukas > >> > >> -- > >> Lukas Renggli > >> http://www.lukas-renggli.ch > >> > >> _______________________________________________ > >> 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 > > > > > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Miguel Enrique CobÃ¡ Martinez

El vie, 08-01-2010 a las 13:48 +0100, Mariano Martinez Peck escribiÃ³: > > > On Fri, Jan 8, 2010 at 1:12 PM, Esteban Lorenzano > <estebanlm(a)gmail.com> wrote: > btw, ConfigurationOfPharo shouldn't be > ConfigurationOfPharoDev? > > > No. For that we have the groups. The same ConfigurationOfPharo will be > used for differents stuff: > > ConfigurationOfPharo project version: 'xxx' load: 'StandardPharoDev' > > or > > ConfigurationOfPharo project version: 'xxx' load: 'StandardPharoWeb ' > (if they came back) > > or > > ConfigurationOfPharo project version: 'xxx' load: 'SOMETHING' (if > they came back) > I'm writing the metacello config for Magma. I suppose that the same applies here. a group for Client, a group for Server and a group for Tester. all of them defined in ConfigurationOfMagma. right? BTW. How did you compute dependencies in packages you aren't completely aware of the details. I remember a tool for this. Where can I find them? Cheers > Cheers > > Mariano > > > On 2010-01-07 17:54:27 -0300, Mariano Martinez Peck > > <marianopeck(a)gmail.com> said: > > > > > > > (Sorry for the long email) > > > > Yes, after a couple of weeks, I have written most of the > needed Metacello > > configurations for the Dev images 1.0. Forget 1.1 for a > while. Now we are > > able to: > > > > 1) Load stable version of packages > > 2) Manage the dependencies automatically > > 3) Each developer can create its custom PharoDev image > > 4) Flexibility to load the packages you want > > 5) Choose the browser for example: OB or O2 > > 6) Choose to load the tests or not > > 7) Load each package in a PharoCore image without having to > install anything > > else (all the dependencies should be managed automatically) > > 8) You can take a PharoCore image and "transform" it to a > Dev image, or even > > web. > > 9) Others... > > > > This is not completed yet. There are some things that we are > discussing with > > Dale, but they are ok as a first step. I rather go step by > step. > > > > What I did is to create all the infrastructure: > > > > a) The Configuration classes > > b) The dependencies > > c) the groups, > > > > In summary, most of the "structure" and static information. > However, I am > > not sure which version to load of each package. I will > probable take care of > > building the Dev images, but I won't: > > > > - Merge anything. It will not be my task to merge OB, or RB > or whatever. > > - Check every version of each package before doing a release > to see if it is > > stable or not. > > > > So...what I REALLY (actually, WE) need is that each > developer, each > > maintainer of the packages that we load of a PharoDev image, > help us to > > create the stable versions. To create a new version for the > Metacello > > configuration is VERY easy, The hard part is already done. > You just have to > > create a method and say which versions (except you create or > eliminate > > packages or dependencies). If you read the code, you will > probably > > understand it. However, you can read the Metacello tutorial > (no more than > > one hour), or ask me or even more in the Metacello mailing > list. > > So...PLEASE, I need the help of the maintainers to create > the versions. So > > far, I created the first version (1.0) with the latest > version. But the idea > > is that then you create 1.1.1 or 1.2 or whatever you > consider. > > > > All the configurations can be found in > > http://www.squeaksource.com/MetacelloRepository > > > > So far, I created: ConfigurationOfNewInspector, > ConfigurationOfOCompletion, > > ConfigurationOfOmniBrowser, > ConfigurationOfPharoMorphicExtras, > > ConfigurationOfPharoSound, > ConfigurationOfRefactoringBrowser, > > ConfigurationOfShout , and......ConfigurationOfPharo!!! > > > > To install them, just download that package and evaluate the > load. Example: > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfShout'; > > load. > > > > ((Smalltalk at: #ConfigurationOfShout) project version: > '1.0') load. > > > > And then, you can also for exaple do: > > > > ((Smalltalk at: #ConfigurationOfShout) project version: > '1.0') load: 'Core' > > > > this doesn't install the tests. > > > > Or for example: (ConfigurationOfOmniBrowser project > version: '1.0') load: > > 'Dev' > > > > etc... > > > > So, you can load any project and with the group you want. > All of that can be > > (or should be hahahaha) perfectly loaded in a 1.0 Core > image. > > > > What I would really appreciate is if each maintainer can > look at the code, > > load the different groups and give me feedback on the > dependencies or > > whatever. > > > > I really wait your feedback. > > > > Mariano > > > > ps: I will release soon the first dev image using this :) > > > > > > > (Sorry for the long email) Yes, after a couple of > weeks, I have writ= > > ten most of the needed Metacello configurations for the Dev > images 1.0. For= > > get 1.1 for a while. Now we are able to: 1) Load > stable version of p= > > ackages > > 2) Manage the dependencies automatically 3) Each > developer can create it= > > s custom PharoDev image > > 4) Flexibility to load the packages you want 5) Choose > the browser for e= > > xample: OB or O2 6) Choose to load the tests or not 7) > Load each pack= > > age in a PharoCore image without having to install anything > else (all the d= > > ependencies should be managed automatically) > > > > 8) You can take a PharoCore image and "transform" > it to a Dev ima= > > ge, or even web. 9) Others... This is not > completed yet. There a= > > re some things that we are discussing with Dale, but they > are ok as a first= > > > step. I rather go step by step. > > What I did is to create all the > infrastructure: a) The Configura= > > tion classes b) The dependencies > > c)=A0 the groups, In summary, most of the > "structure" and = > > static information. However, I am not sure which version to > load of each pa= > > ckage. I will probable take care of building the Dev images, > but I won'= > > t: > > > > - Merge anything. It will not be my task to merge OB, or > RB or whatever= > > . - Check every version of each package before doing a > release to see if= > > it is stable or not. So...what I REALLY (actually, > WE) need is that= > > each developer, each maintainer of the packages that we > load of a PharoDev= > > image, help us to create the stable versions. To create a > new version for = > > > the Metacello configuration is VERY easy, The hard part is > already done. Yo= > > u just have to create a method and say which versions > (except you create or= > > > eliminate packages or dependencies). If you read the code, > you will probab= > > ly understand it. However, you can read the Metacello > tutorial (no more tha= > > n one hour), or ask me or even more in the Metacello mailing > list. So...PLE= > > ASE, I need the help of the maintainers to create the > versions. So far, I c= > > reated the first version (1.0) with the latest version. But > the idea is tha= > > t then you create 1.1.1 or 1.2 or whatever you consider. > > All the configurations can be found in <a > href=3D"http://www.squeaksour= > > > ce.com/MetacelloRepository">http://www.squeaksource.com/MetacelloRepository= > > </a> So far, I created:=A0 > ConfigurationOfNewInspector, Configuratio= > > nOfOCompletion, ConfigurationOfOmniBrowser, > ConfigurationOfPharoMorphicExtr= > > as, ConfigurationOfPharoSound, > ConfigurationOfRefactoringBrowser, Configura= > > tionOfShout , and......ConfigurationOfPharo!!! > > To install them, just download that package and evaluate > the load. Exam= > > ple: Gofer new =A0=A0=A0 squeaksource: > 'MetacelloRepository&#= > > 39;; =A0=A0=A0 package: > 'ConfigurationOfShout'; =A0=A0=A0 loa= > > d. ((Smalltalk at: #ConfigurationOfShout) project > version: '1.0&= > > #39;) load. > > And then, you can also for exaple do:=A0 > > ((Smalltalk at: #ConfigurationOfShout) project version: > '1.0') load= > > : 'Core'=A0 this doesn't install the tests. > Or for = > > example:=A0 (ConfigurationOfOmniBrowser project version: > '1.0') loa= > > d: 'Dev' > > etc... So, you can load any project and with the > group you want.= > > All of that can be (or should be hahahaha) perfectly loaded > in a 1.0 Core = > > > image. What I would really appreciate is if each > maintainer can look= > > at the code, load the different groups and give me feedback > on the depende= > > ncies or whatever. > > I really wait your feedback. > Mariano ps:=A0 I will relea= > > se soon the first dev image using this :) > > > > > > > > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

[Pharo-project] PluggableTextMorph >> getText proposed modification

by Ralph Boland

In my (Squeak) project I modified PluggableTextMorph >> getText to be as follows: getText "Retrieve the current model text" | newText | getTextSelector isNil ifTrue: [^Text new]. newText := (getTextSelector numArgs = 1) ifTrue: [model perform: getTextSelector with: self] ifFalse: [model perform: getTextSelector]. newText ifNil: [^Text new]. ^newText shallowCopy The change allows the getTextSelector to pass an additional argument: self. I made this change because I wanted to know which PluggableTextMorph was asking for text. This is useful when one has large numbers of similar PluggableTextMorphs. Note that the method PluggableTextMorph >> acceptTextInModel already does this so I didn't need to modify it. Thus I think my change makes PluggableTextMorph more consistent. Any chance of this change being made a part of the Pharo image? Frankly, I would prefer that all the GUI objects that have get/set messages had this capability. For CheckBoxes I earlier added the capability to return either self or some arguments (by subclassing this time). I am happy with the result. Another way I could do this would be to create a holder for the PluggableTextMorph (or other gui object) that would respond to the getText and acceptTextInModel messages and would know which PluggableTextMorph is speaking to it (since there would be only one). The holder would replace the model in the PluggableTextMorph and have a reference to the original model to which it could forward messages. Again this would allow me to have a large number of similar PluggableTextMorphs. One could create a PluggableTextMorphHolder class for this or create a single holder class that could work with different Morph classes (only one at a timeof course) (by responding to messages from all of them). It would be nice of course if these GUI holders already existed in Squeak/Pharo so I didn't have to invent them. Which approach do you think is better? Regards, Ralph Boland -- I've been middle class and I've been poor. Middle class is better.

Jan. 12, 2010

Re: [Pharo-project] System -> About in Dev images

by Miguel Enrique CobÃ¡ Martinez

El lun, 11-01-2010 a las 23:41 +0100, Mariano Martinez Peck escribiÃ³: > > > 2010/1/11 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 11-01-2010 a las 22:06 +0000, Michael Roberts > escribiÃ³: > > I'm afraid i've got rather lost in this thread. > > > > >> As an after thought after seeing other posts on the > issue, I think > > >> more than a generic warning that "may break the > image" the > > >> Monticello comments and/or a simple explanation on the > reasons and > > >> affected packages *before* the update starts with > an option to > > >> proceed or abort is much in need. > > >> > > >> > > >> Yes, maybe. Then thing is that I am not sure in > which cases it > > >> would break. Only in overrides? How many overrides do > we have from > > >> external pacakges in Core stuff? I have no idea. > > > > > > > I think given that we are at a very early stage of building > the Pharo > > image from PharoCore i.e Metacello just coming on etc, we > should > > simplify the concerns above. > > > > Basically we should only build Pharo on top of a known > PharoCore. Just > > because packages don't contain overrides does not imply that > moving > > the core image will break packages on top. Don't offer such > a feature, > > and then worry about what will happen. > > > > Part of the Pharo build script should set a flag that > prevents system > > update in the short term. Longer term we should switch the > available > > update mechanism to #loadLatest on the > ConfigurationOfPharo. There is > > then one System update feature, but different implementation > in Pharo > > vs PharoCore. > > > > > So the vote is for disabled for now? > > > > Yes. And this is cool because we have to put focus in to make Pharo > images more stable. We cannot introduce such a feature when we are not > even stable with Dev images. Let's go step by step. Once we get stable > Dev images, good processes and package managment, then we can review > this stuff about updating. > > > Do you want to do it ? ;) > Yes, I will do it, but tomorrow. My idea is to make this a preference and the the build script just disable it. More tomorrow. Cheers > > > cheers, > > Mike > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010