- Pharo-dev - lists.pharo.org

[Pharo-project] I give up!!! Aka too much broken in the 64 bit world
by Schwab,Wilhelm K Sept. 13, 2009

Sept. 13, 2009

Hello all, A couple of things that I really need to have working appear to be hopelessly broken on 64 bit linux, at least for now. After a lot of struggling this weekend, I finally decided to revert to 32 bits to be able to get some work done. I created a /home partition as part of the original installation, so it was not bad to do. At this point, it boots and is currently downloading a couple hundred updates. One interesting thing is that the remote desktop (tsclient) that I use to run LookOut!! on a box across town is working. Could I have a mix of 32 and 64 bit software? Maybe tsclient was 32 bit all along though; the file command might shed some light on that. If any of you have done this retreat and have some war stories that might be of use, please let me know. Bill

1 0

[Pharo-project] Network cleanup?
by Schwab,Wilhelm K Sept. 13, 2009

Sept. 13, 2009

I'm still having trouble with DNS on Ubuntu, and it seems to be IPv6 related. However, it gets very ugly to try to figure out what does and does not (or is that should and should not?) depend on the #useOldNetwork test. Would there be any objections to a split of NetNameResolver to have have new and old subclasses, with the correct class being chosen (or sub-instance created) on initialization? I was able to get around the troubles today by noting that (for now) I have trouble iff I am on a Linux local host, but that trick will come to an abrupt end soon. Bill

2 2

[Pharo-project] [update] #10448 and 10449
by StÃ©phane Ducasse Sept. 13, 2009

Sept. 13, 2009

should work now :) (I hope at least the tests are green) 10448 ----- Merging Monticello-rej.309 pseudo actomic loading and ar.321 from trunk 10449 ----- - Issue 1129: UIManager #request: and #multilineRequest do not distinguish between empty and cancel - Polymorph Widgets Enh Added IncrementalSliderMorph. Minor fixes. Extra convenience method for auto accept text. Refactored bracket sliders. Use 0 border width for theme created image morphs. Retain font for PluggableButtonMorphs that have pluggable labels. Disable keyboard navigation for IncrementalSliderMorph buttons. IncrementalSliderMorph resilient to model absence. General fixes for absent model with respect to enablement. Pluggable enablement support for PluggableSliderMorph. Enablement support for IncrementalSliderMorph. Fixes for slider enablement. Fix for DNU on theme change with labelless PluggableButtonMorphs. - Issue 1209: PluggableButtonMorph nil label

1 0

[Pharo-project] [update] #10447 and 10448
by StÃ©phane Ducasse Sept. 13, 2009

Sept. 13, 2009

10447 ----- - Issue 1212: MCenhancement: - jf: Add methods should return their parameter - removing reference to ChangeSorter (UI) instead of ChangesOrganizer (model) 10448 ----- - Trying to merge Monticello-rej.309 pseudo actomic loading (required to make ar.321)

1 2

[Pharo-project] [update] #10449
by StÃ©phane Ducasse Sept. 13, 2009

Sept. 13, 2009

10449 ----- - Issue 1129: UIManager #request: and #multilineRequest do not distinguish between empty and cancel - Polymorph Widgets Enh Added IncrementalSliderMorph. Minor fixes. Extra convenience method for auto accept text. Refactored bracket sliders. Use 0 border width for theme created image morphs. Retain font for PluggableButtonMorphs that have pluggable labels. Disable keyboard navigation for IncrementalSliderMorph buttons. IncrementalSliderMorph resilient to model absence. General fixes for absent model with respect to enablement. Pluggable enablement support for PluggableSliderMorph. Enablement support for IncrementalSliderMorph. Fixes for slider enablement. Fix for DNU on theme change with labelless PluggableButtonMorphs. - Issue 1209: PluggableButtonMorph nil label

1 0

[Pharo-project] #forceLoading
by Schwab,Wilhelm K Sept. 13, 2009

Sept. 13, 2009

Hello all, I have been struggling a bit with ODBC on Linux, and have found that ExternalLibrary>>forceLoading does not (always?) raise an error when it fails to load the library. My best guess is that primitiveForceLoad is not failing when it should. Any ideas? Bill

1 0

[Pharo-project] Problems with MC (was Re: May be some problems with MC history)
by Michael Roberts Sept. 12, 2009

Sept. 12, 2009

Stef, we need the changes to MCPackageLoader>>basicLoad from Squeak trunk. It does a lot more to ensure correct loading of classes and methods. Our version assumes all additions are the same, both new methods and changes to existing methods. it's this assumption that causes the blow up of loading a (pharo compatible) Kernel-eem.242. I have tested that our version definitely can't load the closure fixes. I will start pulling MC changes in and see how it goes. You already started a review of Pharo version of MC? thanks, Mike On Sat, Sep 12, 2009 at 4:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks dave. > So far I found my way (but I will have a look) and I'm reading > carefully the code to see > the implication for the loading of the closure fixes. > > Stef > > On Sep 12, 2009, at 3:45 PM, David T. Lewis wrote: > >> On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote: >>>> a couple of bugs when understanding the history based merge (ugly) >>> >>> It is not a merge operation, as I said in my mail. You are merely >>> applying the changes representing a delta between two versions >>> manually. That's all, no magic involved. >>> >>>> ? ? ? ?- adding the new method to a cs does not work if you did >>>> not install >>>> the code before (ok) >>>> ? ? ? ?- class definition are not added (yeah) in the changeset. >>>> Really cool! >>> >>> I don't understand what this has to do with change-sets? >>> >>> Class definitions are part of the patch that is calculated by >>> Monticello. My guess is that the class didn't change for the delta >>> you >>> calculated. To illustrate, in the example above the changes between >>> b.1 and b.2 don't show a class change that happened between a.1 and >>> b.1, even if the delta depends on it. >>> >>> I use what I described all the time, it is maybe a bit tricky, but >>> works really well. >> >> Stef, >> >> I don't know if this is helpful or not, but FYI Edgar De Cleene has >> produced the list of change sets corresponding to the MC update stream >> for Squeak trunk. See this thread on squeak-dev: >> >> Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/13936… >> >> Dave >> >> >> _______________________________________________ >> 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 >

2 3

[Pharo-project] Graphics-Centric UI Capability?
by dmurphy＠infratecture.com Sept. 12, 2009

Sept. 12, 2009

hello all, i have been nabbling about the list archives, trying to figure out the right class to use for providing a scrolling graph pane on which i can draw shapes. suppose i were to take UITheme(class)>>exampleWindowWithToolbars and want to turn that into a simple Paint Program. what would i put in place of the StandardWindow>>newTextEditorFor:getText:setText:getEnabled: message send? are there any simple Paint Program examples i start with? thanks for any pointers! delbert

4 4

Sept. 12, 2009

hi all yesterday I decided to have a look at MC changes in squeak to see if this has an impact for the closure last fixes merge. So I did with the latest scriptLoader in the pharo repository ScriptLoader new addExtraRepositories then I select each version of the monticello package in squeak trunk starting from 314 up to 321 and used the history and asked to get the delat with the previous version. This way I could get all the changes one by one. Now I ended up having - methods refering to instance variables that were not included (methodDefinitiosn for example with 321) - when I run the tests I realized that most of the Mock classes where gone. Except for 321 I do not see a change that could affect the MC merging. Does any (lukas) use the history feature to merge? I will retry to do the changes one by one and run the tests in between to see what went wrong but I 'm not sure that what is going wrong is the changes (I have the impression that may be MC history is not capturing exactly everything but I can be wrong). Stef

3 8

Sept. 12, 2009

Hi all I suggest the following: we go over the bug tracker and move to 1.1 all the issues that are not showstopper and we declare pharo 1.0 done and we open pharo 1.1 alpha Does it make sense to you? Stef

13 27