- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11176
by StÃ©phane Ducasse Jan. 21, 2010

Jan. 21, 2010

Finally :) 11176 ----- - Issue 1553: Buffer the StandardFileStream inputs Thanks levente

1 0

[Pharo-project] Monticello remove methods
by Stan Shepherd Jan. 21, 2010

Jan. 21, 2010

-- View this message in context: http://n2.nabble.com/Monticello-remove-methods-tp4433742p4433742.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 3

[Pharo-project] [update 1.1] #11175
by StÃ©phane Ducasse Jan. 21, 2010

Jan. 21, 2010

11175 ----- - preparing buffered file stream: integrating multibyteFileStream from Squeak trunk

1 0

[Pharo-project] Can't debug in 1.1
by Martin McClure Jan. 21, 2010

Jan. 21, 2010

This one's pretty nasty. Symptom: The debugger in recent and current 1.1 images is completely broken. To reproduce (save your image first!): "self halt" doit. It goes into an infinite loop, and if there's a way to get out of that without killing the VM I'd like to know about it. Alt-. works, but just tries to open another debugger, which goes into another infinite loop, etc. Cause: DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is corrupt. It has an array of 22 nils, expired is 0, so it contains nothing, but tally=16. This causes MapCache to lie about its size. This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an infinite loop, the whileTrue: condition is always true, it keeps trying to remove non-existent elements to get the size to be less than 16 but the size is always 16. I don't see any obvious code paths to get into this state. I suspect it may have been left in this state when weak collections were updated with the new code not too long ago. Cure: In an inspector, set tally=0. Debuggers then work again. Not sure how to package this as a slice, so I'll leave the update to someone else, and get back to hashing, which was hard when every walkback froze my system :-) Regards, -Martin

7 12

[Pharo-project] [update 1.1] #11174
by StÃ©phane Ducasse Jan. 21, 2010

Jan. 21, 2010

11174 ----- - Issue 1856: FastÂ§up line splitting - Issue 1857: Let keyboard menu shortcut work in MCPatchBrowser even if showAnnotationPane setting is off - Issue 1749: Date class>>readFrom is in the wrong decade - Issue 1849: Small cleanups... - Issue 1804: Can t debug in 1.1 (sorry that it took so long to integrate)

1 0

[Pharo-project] A dog-slow browser
by Igor Stasenko Jan. 21, 2010

Jan. 21, 2010

Please, don't take it as a offense, but as a constructive critics :) Pharo-core browser is awfully slooow! That's why i prefer to develop in squeak trunk image. Why it showing the distracting hourglass cursor when stepping over a list of methods in method's list? (press and hold the up arrow key when inside a methods list)... damn.. what happens there, that it consumes so much time to just switch the source code in a single text pane? -- Best regards, Igor Stasenko AKA sig.

12 41

[Pharo-project] [ANN] ConfigurationOfRFB
by Miguel Enrique CobÃ¡ Martinez Jan. 21, 2010

Jan. 21, 2010

I have uploade the Metacello configuration for RFB (a.k.a. Remote Frame Buffer a.k.a. VNC) To load it in a 10506 PharoCore image: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfRFB'; load. (Smalltalk at: #ConfigurationOfRFB) project latestVersion load. Enjoy. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

1 1

Jan. 21, 2010

Hi nicolas I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them since in moose we are computing a lot LOC :) By any chance could we get the same in pharo? Else I will harvest them. Stef

3 10

[Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB
by Mariano Martinez Peck Jan. 20, 2010

Jan. 20, 2010

> That's the reason of having OB and O2. While both now work together in the > same image > without inferring each other, this indeed increases the number of classes > in the image > quite a lot as they duplicate a whole bunch of code. So I strongly suggest > to either use > OB or O2, even though you can have both. But I do not see a reason why > people want to > switch between the two dynamically in the same image. > > We have two things to choose: which browser is default and which ones are installed. Both ? only one ? The solution I like most, is in these options: 1) Install both: OB and O2. Let OB as default. 2) Install only OB, of course, as default, and those who wants can install O2 in that dev image. They way to install O2 now is very easy. 3) Install only OB, of course, as default, but create a group in ConfigurationOfPharo like "StandardDevImageWithO2" so that those people who want a dev image with O2 can just evaluate that in a core image and wala! With 1 the image will be smaller but won't have O2 preinstalled. With 2) and 3) you will have also O2 but bigger image. I think I will coose 2) AND 3). Those who want to install O2 directly in a dev image, use the ConfigurationOfO2 and those who wants to create a dev image over the core, they use ConfigurationOfPharo with the new group I can create. What do you think ? Mariano

9 13

[Pharo-project] Bug in ThreadSafeTranscript
by Stefan Marr Jan. 20, 2010

Jan. 20, 2010

Hi: ThreadSafeTranscript crShow: is not thread-safe, but definitely need to be thread-safe. The problem is, it is using a mutex currently. (I guess thats the reason why there is no accessSemaphore critical: [...]. in crShow) Replacing it by a reentrant/recursive Monitor would probably allow to avoid code duplication. Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

2 1