- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3551 in pharo: Morph>>morphsInFrontOverlapping: and friends' behavior does not match comment
by pharo＠googlecode.com Jan. 19, 2011

Jan. 19, 2011

Status: New Owner: ---- New issue 3551 by sean.p.d...(a)gmail.com: Morph>>morphsInFrontOverlapping: and friends' behavior does not match comment http://code.google.com/p/pharo/issues/detail?id=3551 Morph #morphsInFrontOverlapping: #morphsInFrontOf:overlapping:do: #morphsInFrontOverlapping:do: all include the morphs submorphs in the returned collection, but the comments state "Return all top-level morphs", which means the submorphs shouldn't be included, no? Pharo1.2rc1 Latest update: #12310 Steps to reproduce: 1. Open a window (e.g. a browser) 2. Inspect it 3. evaluate: "self morphsInFrontOverlapping: self bounds"

1 1

[Pharo-project] [ANN 1.3 started] Core 1.3#13001
by Marcus Denker Jan. 19, 2011

Jan. 19, 2011

https://gforge.inria.fr/frs/download.php/28163/PharoCore-1.3-13001.zip .. same as 1.2rc1, just a 13 Scriptloader. (this way we can deep-freeze 1.2 and start adding to 1.3 instead) Hudson project to follow.... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] About XML Support in the 1.2
by Fabrizio Perin Jan. 19, 2011

Jan. 19, 2011

Hi, I have a problem with the XMLSupport version from Pharo 1.2. The problem is that I need to work with one of the last version of XMLSupport but in the pharo image 1.2 is loaded an old version of XMLSupport (I mean a version from Jan 2010). I did try to load a newer version of XMLSupport using ConfigurationOfXMLSupport but some errors make this operation impossible. So either Pharo-dev 1.2 load a newer (possibly the last) version of XMLSupport by default or Pharo-dev 1.2 should not load XMLSupport at all. I think that doesn't make sense to use by default such an old version, also considering that the last XMLSupport has nice and useful features like the XMLPluggableElementFactory. By avoiding to load XMLSupport in Pharo-dev 1.2 by default you let people free to use the version that they like. Thanks, Fabrizio

3 2

[Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds
by Torsten Bergmann Jan. 19, 2011

Jan. 19, 2011

inspirations to switch between worlds: http://clickheredammit.com/pageflip (a page flip) combined with a peeling effect in the upper corner: http://www.sohtanaka.com/web-design/examples/peeling-effect/ or a carousel of world thumbnails: http://jquery-ui.googlecode.com/svn/branches/labs/carousel/demo/dynamic.html or a coverslide: http://jquery-ui.googlecode.com/svn/branches/labs/coverslide/index.html If you want to port a more mac like UI to Pharo also check: http://www.wizzud.com/jqDock (a dock done in JavaScript, check the properties) -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 1

[Pharo-project] list on he fly selection :)
by StÃ©phane Ducasse Jan. 19, 2011

Jan. 19, 2011

Hi guys I'm sure that some of you will really like to type on that list and see it auto selectioning its elements.... Gofer it squeaksource: 'DirtyExperiments'; package: 'DirtyExperiments'; load | test | test := DummyTest on: (Smalltalk allClasses). test openInWorld Of course I would love to have that for a lot of lists..... :) Thanks Benjamin for this first version :) Stef

5 9

[Pharo-project] Cog problems
by Igor Stasenko Jan. 19, 2011

Jan. 19, 2011

I built new Cog by taking latest VMMaker-oscog.46 on MacOS VM still crashing at some random point during running all pharo-core image tests. Once i were able to run w/o crash and found following failures: MethodContextTest debug: #testClosureRestart because actually this one: MethodContextTest new privRestartBlockArgsNoRemoteTempsTest i'm not sure if this is a compiler issue (maybe it shuffling the temps) or because of Cog, which doesn't likes restarts like that :) BecomeTest>>testBecomeIdentityHash. Sometimes passes, sometimes not (try doing following in workspace): | a b | a := 'ab' copy. b := 'cd' copy. self assert: (a identityHash ~= b identityHash). a become: b. self assert: (a ~= b). self assert: (a identityHash ~= b identityHash). i'm not sure if this is a big issue.. afaik, #become: don't gives any guarantees about copying identityhash. P.S. yesterday i were able to successfully build Cog on linux using cmake configs i generating. but it crashing at first #commonReturn point, which is really weird :) I tried multiple images, same result. The crash happens in given loop: while (closure != GIV(nilObj)) { home = longAt((closure + BaseHeaderSize) + (ClosureOuterContextIndex << ShiftForWord)); closure = longAt((home + BaseHeaderSize) + (ClosureIndex << ShiftForWord)); } -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] should the PharoDev hudson image be buld using the baseline instead?
by Mariano Martinez Peck Jan. 18, 2011

Jan. 18, 2011

Hi. A trade-off here. Right now, the PharoDev image from Hudson is being built using ConfigurationOfPharo project lastestVersion. This is more or less good because we have the last version of the ConfigurationOfPharo. But at the same time, updating the versions of ConfigurationOfPharo is tedious. So, what about loading the baseline istead? So that metacello automatically load the latest version of each package/project ? The good thing is that every change in external configurations/packages will be automatically included. But at the same time this is a disavtange because we can build crap (someone commits something that doesn't work). When updating ConfigurationOfPharo by hand we usually test it before.... anyway, isn't this the idea if hudson? if it builds crap, we want to know it, as soon as possible. NOBODY should use a Hudson image (as it is now) for a stable Pharo1.2 image. what do you think? cheers mariano

3 2

[Pharo-project] Issue 3517 in pharo: Failing test AutomaticMethodCategorizerOB
by pharo＠googlecode.com Jan. 18, 2011

Jan. 18, 2011

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2-DevImage New issue 3517 by marcus.denker: Failing test AutomaticMethodCategorizerOB http://code.google.com/p/pharo/issues/detail?id=3517 >>> AutomaticMethodCategorizerOB.Tests.OBCmdAutoCategorizeWithAMCTest.testOBAutocategorizeCommandOverride >>> >>> 0.014 15

1 1

[Pharo-project] Issue 3547 in pharo: Have a look at the new match: implementation
by pharo＠googlecode.com Jan. 18, 2011

Jan. 18, 2011

Status: Accepted Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3547 by stephane...(a)gmail.com: Have a look at the new match: implementation http://code.google.com/p/pharo/issues/detail?id=3547 Collections-ul.420 Hi Squeakers, Latest trunk version broke the Aida/web and Herbert managed to find the reason in new behavior of String>>match: which doesn't allow two '**' in pattern anymore. In Aida the matching patterns are usually composed out of many strings and as it happens two stars occurs in Aida's default installation already. Because this new match behavior (not allowing two '**') is new only in Squeak but allowed in all other Smalltalks, I propose to reconsider this decision and better retract back to old behavior. answer: ------ The old behavior was definitely wrong. Here are two examples with the old behavior from the corresponding issue (http://bugs.squeak.org/view.php?id=6841 ): '*#' match: 'e'. "false" '**' match: 'e'. "false" If you look at the previous version of the method from 2004 (I don't know if this is the original or not), then you'll see that it tried to raise an error if the string contained '**', but it failed to do so because of this bug. So the intended behavior - to disallow ** in the pattern - is not new at all. IMHO the best solution to this problem is to rewrite the method to allow any combination of * and # in the pattern.

1 3

Re: [Pharo-project] Xtreams-Xtras: hashing and HMAC
by mkobetic＠gmail.com Jan. 18, 2011

Jan. 18, 2011

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > > I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a bit to keep the categories in line. > > Hmm, click the 'Browse' button in either the Monticello Browser or the Repository Browser with the correct package selected ? But I guess you know that as well... Well, those seem to be "read-only", i.e. any edits I try to make in those seem to disappear, so I've been ignoring those browsers. Interestingly, the one-click image (Pharo 1.1.1) seems to have 'browse package' in the SystemBrowser menus which seems to be more functional, but that doesn't seem present in the PharoCore 1.2, so I'm just getting by with the basic SystemBrowser atm. > The problem is the one I reported earlier: XTFileReadingWritingTest expecting a read stream to be aware of data written to a file after it was opened. This does not seem to work on Mac OS X. Yeah I have your previous report still in my inbox, but I'm kinda stuck there. As I said I don't have OSX to work with so I can't dig in to figure out what's going on. Given that it works on OSX in VW, I'm inclined to say that it should work on OSX in Squeak too. I wonder if there's some mixup in terms of file descriptors, maybe we're not talking to the same one or something such. I think Nicolas has OSX available so I'm hoping he might be able to find the time to look into it at some point.

2 1