February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Software update ?

by Sven Van Caekenberghe

Hi, I notice that in 1.2 images build by CI, the System>Software update menu is enabled. Is this on purpose ? Is this a change of strategy ? I see that various critical changes are still being commited to 1.1 and 1.2 as well as 1.3. For these changes an update mechanism seems nice to have and very useful. I understand that full 1.1 -> 1.2 upgrades are not possible or advisable, that is OK. Sven

Feb. 14, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Updates: Status: Closed Comment #58 on issue 3583 by stephane...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 We retroffit the 1.2 refactoring in StringHolder. Now 1.2 and 1.3 are in sync. In 13055

Feb. 14, 2011

[Pharo-project] [update 1.2] #12335

by StÃ©phane Ducasse

12335 ----- Issue 3583: Shout should only be active in code panes. Thanks Benjamin van Ryseghem. Stef

Feb. 14, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #57 on issue 3583 by stephane...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 Ok we redid everything with Benjamin in 1.2 in 12335. Can you check that this is ok?

Feb. 14, 2011

Re: [Pharo-project] saving a monticello working copy

by Sven Van Caekenberghe

Doru, On 14 Feb 2011, at 12:18, Tudor Girba wrote: > Basically, I need that given a working copy in the image, to copy it in the local package-cache. I am not sure I understand. For each MC package, your image's local package-cache is always one of the possible repositories, so why can't you just save it right there ? And later on copy it to some other repository. I am sure you know that, so your problem must be something else, no ? Sven

Feb. 14, 2011

Re: [Pharo-project] saving a monticello working copy

by Tudor Girba

Hi, I am reposting the message here in the hope that someone will answer :). Basically, I need that given a working copy in the image, to copy it in the local package-cache. Cheers, Doru On 12 Feb 2011, at 23:02, Tudor Girba wrote: > Hi, > > Does anyone know a simple way to save a Monticello working copy into the package-cache? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Feb. 14, 2011

Re: [Pharo-project] [Moose-dev] Problem loading JNIPort

by Tudor Girba

Hi Matthias, Thanks for reporting. I forwarded the message to the Pharo mailing list as well. Can anyone help? Cheers, Doru On 14 Feb 2011, at 12:10, Matthias Junker wrote: > Hi, > > i was trying to load JNIPort as described on squeaksource on my Macbook (OS X 10.6.6). I downloaded the latest Pharo 1.2 from Hudson (https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/) and opened it using SqueakVM 5.8b12. I was able to load Alien using the following command: > > Gofer it > squeaksource:'MetacelloRepository' ; > package: 'ConfigurationOfAlien'; > load. > > ((Smalltalk globals classNamed: 'ConfigurationOfAlien') > project version: 'Pharo 1.2') > load: 'Core'; load: 'LibC > > Then i loaded the JNIPort Configuration: > Gofer it > squeaksource: 'JNIPort'; > package: 'ConfigurationOfJNIPort'; > load. > > But when i load the actual project with this: > ConfigurationOfJNIPort project latestVersion load > I get the following error in the class StandardLibInterface(AlienLibrary)>>load > libraryName: '/System/Library/Frameworks/System.framework/System' > errorCode: #'not found' > > When i check on the file system i find a symbolic link which points to /usr/lib/libSystem.B.dylib (which also exists there). > > Any hints to what i'm doing wrong? > > Cheers, > Matt > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Feb. 14, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #56 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 I've done a slice for 1.2 image (String Holder is now my friend ^^) in PharoInbox And a little fix for 1.3 in order to consider SH preferences about styling Attachments: FixPluggableTextMorph2.1.cs 264 bytes

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Craig Latta

Hi GÃ¶ran-- Thanks for the summary! I think there's another option as well. If you have... - the ability to transfer methods directly between live systems, without having to recompile source code - a way of specifying groups of methods ("modules"), and prerequisite relationships between those groups ...then you can... 1. Compose a GUI using a direct-manipulation editor. 2. Represent the state of that GUI with an object (which probably makes references to several other objects). 3. Create a method that refers to that object. (One way to store the object would be as a class variable.) 4. Transfer that method to another live system. The method is probably little more than asking the GUI object to render itself. If you want to know more about how the GUI object was created, you can ask it that too. The method's module specifies at least of the GUI framework as a prerequisite. You can have as many different GUI frameworks around in a system as you like, perhaps introducing some as others are phased out. Perhaps message interfaces common to all of them will emerge over time. All along the way one uses familiar tools to inspect and change state and behavior. Although source code isn't necessary for transferring behavior from one system to another, it's all still readable. This scheme is readable, editable, easy to store, and amenable to framework change (the four things you were after). thanks again, -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

Feb. 14, 2011

Re: [Pharo-project] A new GUI visual designer

by Sven Van Caekenberghe

On 14 Feb 2011, at 10:28, Igor Stasenko wrote: >> - there does not seem to be a way to deal with non-ascii strings like 'GÃ¶ran', shouldn't there be something like JSON escapes ? > > No. Wake up. Its 2011 outside. Use unicode encodings (like UTF-8) for reading/writing source streams. > Just don't use ascii, then you won't need to escape non-ascii characters. :) I know what UTF-8 encoding is and I know the date. However, then the Tirade spec should say, all data is encoded in UTF-8 by default, leaving it open like this is asking for problems. But even then, for a data interchange format I think that ASCII + enscaping is a better deal that will cause less problems. Sven

Feb. 14, 2011