- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo-Kernel Gofer broken
by Marcus Denker March 7, 2012

March 7, 2012

On Mar 6, 2012, at 10:11 PM, Pavel Krivanek wrote: > Well, the issue that broke Pharo-Kernel is fixed but in meantime > Pharo-Kernel Gofer is on knees again. The reason is that Monticello is > newly dependent on SystemAnnouncements (that comes together with tests > so it is dependent on SUnit and thus cannot be loaded without the next > remodularization). I will fix that. -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Pharo-Kernel Gofer broken
by Pavel Krivanek March 6, 2012

March 6, 2012

Well, the issue that broke Pharo-Kernel is fixed but in meantime Pharo-Kernel Gofer is on knees again. The reason is that Monticello is newly dependent on SystemAnnouncements (that comes together with tests so it is dependent on SUnit and thus cannot be loaded without the next remodularization). -- Pavel

1 0

[Pharo-project] .changes are now 37MBâ¦.
by Marcus Denker March 6, 2012

March 6, 2012

... what do we do? http://code.google.com/p/pharo/issues/detail?id=4843 (but that will not help that much. And someone would need to look at the tracker entry and make it ready for integration). or just do a condense? The history is in Monticello. http://code.google.com/p/pharo/issues/detail?id=5379 Marcus -- Marcus Denker -- http://marcusdenker.de

4 3

[Pharo-project] Nautilus feedback
by Alexandre Bergel March 6, 2012

March 6, 2012

Hi! Nautilus is cool! I use it in the Pharo1.4-based Moose image. Some comments: - Cmd-t when selecting a package does not run the tests - Cmd-b does not open a Nautilus, but a standard browser What about the refactoring engine? Does it work in Pharo 1.4? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 8

[Pharo-project] [update 1.4] #14380
by Marcus Denker March 6, 2012

March 6, 2012

14380 ----- Issue 5440: Fix isPostmortem http://code.google.com/p/pharo/issues/detail?id=5440 Issue 5438: removeAllButPackages: wants to remove method categories that are owned by traits http://code.google.com/p/pharo/issues/detail?id=5438 Issue 4780: Unify union / difference / intersection on Collections http://code.google.com/p/pharo/issues/detail?id=4780 Issue 5439: GoferOperationTest fails http://code.google.com/p/pharo/issues/detail?id=5439 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Colored Stdout/Stderr logging with headless images
by Sven Van Caekenberghe March 6, 2012

March 6, 2012

This is so cool and beautiful, this new addition where errors with headless images are printed directly to stout or stderr with coloring ! I just saw it the first time today. Really helpful. Thanks a lot Camillo ! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

4 5

Re: [Pharo-project] We crossed 5000 closed issues!
by Marcus Denker March 6, 2012

March 6, 2012

On Mar 6, 2012, at 3:07 PM, Benoit St-Jean wrote: > Congratulations! Now, we should aim for a much smaller goal... > > Let's make Pharo so good that we'll average less than 1.00 bug fixed a day because Pharo's code will be sooooooooo gooooooooood, rock solid and stable ! ;) > > Keep in mind that these are mostly improvements... We could freeze Pharo and only fix bugs. That would be easy. But is what we have already good enough for that? Do we have a future with Pharo if we only fix bugs? Marcus -- Marcus Denker -- http://marcusdenker.de

2 2

March 6, 2012

SimpleButtonMorph>>updateReferencesUsing: aDictionary "Copy and update references in the arguments array during copying." super updateReferencesUsing: aDictionary. arguments _ arguments collect: [:old | aDictionary at: old ifAbsent: [old]]. no users. I would remove it. Stef

1 1

[Pharo-project] Filesystem onDisk and inMemory are renamed in 1.4
by Tudor Girba March 6, 2012

March 6, 2012

Hi, Filesystem is part of the Pharo 1.4 image and the code resides in the Pharo 1.4 repository. Essentially, as Lukas pointed out, this is a fork. There is absolutely nothing wrong with that, especially if you want to base the core on it. However, the problem is what happens with the changes. Do they flow back to the original author, or do you want to fork completely? Of course, a collaboration requires at least two parties to work together :), but it would still be cool to get the position clear. Of course, some changes are internal and they have little impact on the end user, but sometimes the public interface changes, too, and that is more problematic. Case in point are the onDisk and inMemory methods which were renamed to disk and memory, respectively. This basically breaks any previous code that is using Filesystem. Is there a particular reason for doing this (the original names seem perfectly legitimate), or was it just a mistake? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

3 3

March 6, 2012

I'm fighting with timeStamp and old code checking size of timeStamp and this is why we should improve the infrastructure and in particular code management. Stef timeStamp "Answer the authoring time-stamp for the given method, retrieved from the sources or changes file. Answer the empty string if no time stamp is available." "(CompiledMethod compiledMethodAt: #timeStamp) timeStamp" | file preamble stamp tokens tokenCount | self fileIndex = 0 ifTrue: [^ String new]. "no source pointer for this method" file := SourceFiles at: self fileIndex. file ifNil: [^ String new]. "sources file not available" "file does not exist happens in secure mode" file := [file readOnlyCopy] on: FileDoesNotExistException do:[:ex| ^ String new]. preamble := self getPreambleFrom: file at: (0 max: self filePosition - 3). stamp := String new. tokens := (preamble findString: 'methodsFor:' startingAt: 1) > 0 ifTrue: [Scanner new scanTokens: preamble] ifFalse: [Array new "ie cant be back ref"]. (((tokenCount := tokens size) between: 7 and: 8) and: [(tokens at: tokenCount - 5) = #methodsFor:]) ifTrue: [(tokens at: tokenCount - 3) = #stamp: ifTrue: ["New format gives change stamp and unified prior pointer" stamp := tokens at: tokenCount - 2]]. ((tokenCount between: 5 and: 6) and: [(tokens at: tokenCount - 3) = #methodsFor:]) ifTrue: [(tokens at: tokenCount - 1) = #stamp: ifTrue: ["New format gives change stamp and unified prior pointer" stamp := tokens at: tokenCount]]. file close. ^ stamp there are a couple of method with such logic. Stef

1 0