- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deprecation policy
by Marcus Denker Aug. 30, 2011

Aug. 30, 2011

On Aug 30, 2011, at 1:44 AM, Sean P. DeNigris wrote: > Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, > 2011'. Does it matter? No > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Bug or feature? XMLElement>>allElementsDo:
by Nicolas Anquetil Aug. 30, 2011

Aug. 30, 2011

In XML-Parser-Nodes we have: XMLNodeWithElements XMLDocument XMLElement A document is composed of elements that can hold recursively other elements XMLNodeWithElements implements (in protocol enumerating) allElementsDo: aBlock "Descend depth-first visiting each element with aBlock." self hasElements ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] Looks perfectly normal to me But then: XMLElement implements (in protocol searching !) allElementsDo: aBlock "See superclass version." aBlock value: self. super allElementsDo: aBlock. which means that anXMLElement allElementsDo: [...] runs first on itself and then on its elements ?!? Seems counter intuitive to me. Should I remove this? nicolas

5 4

[Pharo-project] NonRentrantWeakMessageSend
by StÃ©phane Ducasse Aug. 29, 2011

Aug. 29, 2011

does it make sense to have to have WeakMessageSend not been reentrant? Because we could merge WeakMessageSend and NonRentrantWeakMessageSend. Or we could move the two subclasses of WekMessageSend to the same package as WeakMessageSend or alternate solution. Rename Polymorph-EventEnhancements into Kernel-Enhancements. What do you think? Stef

1 0

[Pharo-project] [update 1.4] #14112
by StÃ©phane Ducasse Aug. 29, 2011

Aug. 29, 2011

14112 ----- - Issue 4550: methodSymbol is a bad name for selector. http://code.google.com/p/pharo/issues/detail?id=4550 - Issue 4711: Pharo 1.4 has wrong link to inbox. Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=4711 - Issue 4710: Incorrect comment for ProtoObject>>pointersToExcluding: Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=4710 - Issue 2394: Halt :) Thanks Sean De Nigris and Stefan Eggermont. http://code.google.com/p/pharo/issues/detail?id=2394 Stef

1 0

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 29, 2011

Aug. 29, 2011

On Aug 29, 2011, at 7:54 PM, Lukas Renggli wrote: >>>> No more for me. >>> >>> Introducing more code into Pharo that depends on more parts of Pharo >>> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it >>> easier to maintain and change Pharo. Or did I misunderstand something >>> about cohesion and coupling? :-) >> >> With that philosophy, we can just declare Pharo as finished and do something >> else. >> My point of view is that I invent new abstractions *and than use them* on and >> for the system itself. > > I disagree; I would like a small and stable Pharo in which crazy ideas > can be realized. For that I don't need fancy abstractions, but a > minimal, simple and absolutely stable system in which I can load and > do whatever I want. Maybe this is just me? > Is the current system simple and minimal? Do you think the Pharo we have is good enough to have a future? Marcus -- Marcus Denker -- http://marcusdenker.de

5 7

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 29, 2011

Aug. 29, 2011

On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote: >>> Nautilus looks to me like yet another Smalltalk-80 browser that works >>> exactly the same as all previous Smalltalk browsers in the last 32 >>> years (including OB). IMHO fixed lists, a text field and ugly buttons >>> do not cut it anymore. Did any Smalltalker ever work with XCode, >>> Eclipse, VisualStudio, ...? >> >> Have a "basic" browser so that we can get rid of StringHolder. > > You could push down all the code of StringHolder into the subclass(es) > and remove the empty class. This can be done with RB with a few > clicks. > >> No more for me. > > Introducing more code into Pharo that depends on more parts of Pharo > (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it > easier to maintain and change Pharo. Or did I misunderstand something > about cohesion and coupling? :-) > With that philosophy, we can just declare Pharo as finished and do something else. My point of view is that I invent new abstractions *and than use them* on and for the system itself. Marcus -- Marcus Denker -- http://marcusdenker.de

3 2

[Pharo-project] [update 1.4] #14111
by StÃ©phane Ducasse Aug. 29, 2011

Aug. 29, 2011

14111 ----- - Issue 4609: Syntax highlighting broken. ****Thanks**** Alain Plantec and Benjmain van Ryseghem

1 0

[Pharo-project] Halt
by Sean P. DeNigris Aug. 29, 2011

Aug. 29, 2011

The halt code is a mess. There are several open issues and should be several more. Here's what I found today... 1. Object>>setHaltOnce and friends are misleading See http://code.google.com/p/pharo/issues/detail?id=2621 All the accessors for the global HaltOnce are on the instance side of Object, making it unclear whether haltOnce and especially haltOnCount: are per-object or global. I suggest they be moved to some object representing the system (like SmalltalkImage or a delegate - I know we're trying to clean SmalltalkImage). #haltOnce Smalltalk haltOnceEnabled "used to be self haltOnceEnabled" ifTrue: [Smalltalk clearHaltOnce. "used to be self clearHaltOnce" ^ self halt]. makes it obvious that this is a global property, not per-instance. The first requires a comment (as indicated by the pending issue), the second is documented by the code. 2. Using Object to halt causes bloat, and doesn't buy much (except that's how we've always done it). See http://code.google.com/p/pharo/issues/detail?id=2394 for a proposal to change from "self haltOnce" to Halt once. 3. Is anyone using the versions that take a string message (e.g. #haltOnce:). A halt brings you into a debugger, so is the extra info worth the added complexity? p.s. right now, the versions are cut-and-pastes of each other I've already started to clean all this up and write tests, but wanted to be clear what the right direction is. Cheers, Sean -- View this message in context: http://forum.world.st/Halt-tp3774723p3774723.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

5 8

Re: [Pharo-project] Omnibrowser in 1.4
by Marcus Denker Aug. 29, 2011

Aug. 29, 2011

On Aug 29, 2011, at 9:08 PM, Lukas Renggli wrote: >>>> Is the current system simple and minimal? >>> >>> No, it is complex and it is getting bigger with every release. >>> >>>> Do you think the Pharo we have is good enough to have a future? >>> >>> No, there is a lot to be improved. I think the future of Pharo is what >>> can be built on top, not what can be integrated and forced upon >>> everybody. >> >> So? Maybe we should just stop and do something else. > > No and yes. > > No, don't stop: The cleanup process in Squeak 3.9, Pharo 1.0 and Pharo > 1.1 was awesome. The system got smaller and more stable with every > release. What exactly did we add in 1.2 and 1.3 other than Zinc and Finder? > > Yes, do something else. Be your own customer. Where is the next Reflectivity? > It will come. And it will require changes. Add some code, remove other code. Clients that require on deep system detail that changes will be impacted, too. I am sure you will not like it. I do not know how to move a system forward without changing it. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] Pharo 1.4
by Marcus Denker Aug. 29, 2011

Aug. 29, 2011

On Aug 22, 2011, at 1:34 PM, Ilmari Vacklin wrote: > On Monday, August 22, 2011 1:09:28 PM UTC+3, Alexandre Bergel wrote: > Hi! > I now switched to Pharo 1.4. It is much more usable than 1.3 in my opinion. > I like the code completion tool, more stable than ocompletion. > > I'd be interested in testing a new code completion tool too. I downloaded the unstable image from pharo-project.org, but its workspaces and the browser do not have code completion. Do I need to install additional packages? > 1.4 has currently no enhanced completion installed. This issue has the Gofer expression to load Ocompletion: http://code.google.com/p/pharo/issues/detail?id=4622 But maybe we should use Ecompletion instead? Or nothing? -- Marcus Denker -- http://marcusdenker.de

11 12