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

Re: [Pharo-project] OmniBrowser in PharoCore 1.3

by Guillermo Polito

Hi! Which version are you loading? I didn't test it in 1.3 yet because 1.2 is not out, hehe. BTW, can you copy the error here? It's a bit weird that the error is related to Preferences... Guille On Mon, Feb 21, 2011 at 10:23 AM, Adrien BARREAU <abarreau.dev(a)live.fr>wrote: > Hello all, > > I'm trying to load the OmniBrowser in PharoCore 1.3. > I use the ConfigurationOfOmniBrowser in MetacelloRepository. > > But it raises errors on messages to the Preferences class. > > Is there a way to load this browser in PharoCore 1.3? It's more difficult > to use the basic browser. > > Thanks, > Adrien. >

Feb. 21, 2011

[Pharo-project] OmniBrowser in PharoCore 1.3

by Adrien BARREAU

Hello all, I'm trying to load the OmniBrowser in PharoCore 1.3. I use the ConfigurationOfOmniBrowser in MetacelloRepository. But it raises errors on messages to the Preferences class. Is there a way to load this browser in PharoCore 1.3? It's more difficult to use the basic browser. Thanks, Adrien.

Feb. 21, 2011

Re: [Pharo-project] Cobol is the new language to know?

by Geert Claes

Schwab,Wilhelm K wrote: > > My favorite parts were: > > âI have seen examples of developers on older technologies like RPG and > Delphi charging twice the rate of a developer on a newer technology.â > > Did it ever occur to them that some of these systems (e.g. Smalltalk) > might actually be more productive and hence worth the boost in rate? Most > are just lean supply, but there is also the the power tool vs. hammer > concept at work too. > I thought that bit was interesting too. I used to be a Powerbuilder (which Delphi and VB more or less copied) developer and moved away from it because contracts (even back then) were too few and far between to sustain a reasonable income, so they probably simply need to charge extra to cover for the periods between contracts :) -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317247.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 21, 2011

Re: [Pharo-project] Issue 3741 in pharo: Decompiler hangs

by pharo＠googlecode.com

Comment #1 on issue 3741 by ryd...(a)gmail.com: Decompiler hangs http://code.google.com/p/pharo/issues/detail?id=3741 ParseNode answers false to isTemp though, so the remoteTemps call should never be reached. A description/reproducible case of what is wrong would be ncie.

Feb. 21, 2011

Re: [Pharo-project] Cobol is the new language to know?

by Schwab,Wilhelm K

My favorite parts were: âI have seen examples of developers on older technologies like RPG and Delphi charging twice the rate of a developer on a newer technology.â Did it ever occur to them that some of these systems (e.g. Smalltalk) might actually be more productive and hence worth the boost in rate? Most are just lean supply, but there is also the the power tool vs. hammer concept at work too. "From the point of view of the companies and institutions, this is a problem. The longer they wait to modernise these systems, the more it is going to cost them when they do â for they will need experts in the old to explain what the heck the systems do to those attempting to modernise it." Translation: programmers are too dumb to read anything they don't "know." Give me well-written code in a language I've never seen over a mess in something I use every day. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Geert Claes [geert.wl.claes(a)gmail.com] Sent: Monday, February 21, 2011 6:35 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Cobol is the new language to know? I just cringed when I read: "The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be supported in the near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion (according to Object Consulting they have a three-year shelf life), while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments." http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 21, 2011

[Pharo-project] Issue 3741 in pharo: Decompiler hangs

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3741 by hisnamei...(a)gmail.com: Decompiler hangs http://code.google.com/p/pharo/issues/detail?id=3741 this method can't work, because ParseNode can't understand remoteTemps: popIntoTemporaryVariable: offset | maybeTVTag tempVector start | maybeTVTag := stack last. ((maybeTVTag isMemberOf: Association) and: [maybeTVTag key == #pushNewArray]) ifTrue: [blockStartsToTempVars notNil "implies we were intialized with temp names." ifTrue: "Use the provided temps" [[(tempVector := tempVars at: offset + 1 ifAbsent: [ParseNode basicNew]) isTemp and: [tempVector isIndirectTempVector and: [tempVector remoteTemps size = maybeTVTag value size]]] assert] ifFalse: "Synthesize some remote temps" [tempVector := maybeTVTag value. offset + 1 <= tempVars size ifTrue: [start := 2. tempVector at: 1 put: (tempVars at: offset + 1)] ifFalse: [tempVars := (Array new: offset + 1) replaceFrom: 1 to: tempVars size with: tempVars. start := 1]. start to: tempVector size do: [:i| tempVector at: i put: (constructor codeTemp: numLocalTemps + offset + i - 1 named: 't', (tempVarCount + i) printString)]. tempVars at: offset + 1 put: (constructor codeRemoteTemp: offset + 1 remoteTemps: tempVector)]. tempVarCount := tempVarCount + maybeTVTag value size. stack removeLast. ^self]. self pushTemporaryVariable: offset; doStore: statements I get the problem in PharoInstantMessenger ver.4 if you wanna test. It's really annoying to spend a day on that, just because a variable is declared in a block. For a 30yo language, it sucks

Feb. 21, 2011

Re: [Pharo-project] Issue 3738 in pharo: Morphic Animations enhancement

by pharo＠googlecode.com

Comment #2 on issue 3738 by ryd...(a)gmail.com: Morphic Animations enhancement http://code.google.com/p/pharo/issues/detail?id=3738 A few points: Class comments? Sure, for most they're somewhat self-explanatory, but for say, SlideAnimation, it would be nice to know what unit the delay is in, and what it actually does. There's also no common interface (that I can see) for adjusting the speed of the animations. AnimationsRunner animateZoomOutOf: .... smells bad. There's no corresponding ZoomInOf: ..., and why isn't it just zoom: aMorph in the first place, where new extent determines whether it is a zoom in or a zoom out? AnimationsRunner class >> #uniqueInstance Why does it use super? Some WindowAnimation subclasses are in -Core, others in -Windows Some animations take responsibility of all drawing up to the point where you copy the bits to the canvas, while others use existing methods in other parts of the system. Personally, I'd prefer a consistent approach in what is the Animations responsibility (having everything self-contained would be my preference)

Feb. 21, 2011

[Pharo-project] Cobol is the new language to know?

by Geert Claes

I just cringed when I read: "The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be supported in the near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion (according to Object Consulting they have a three-year shelf life), while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments." http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… http://www.channelregister.co.uk/2011/02/20/cobol_is_the_new_language_to_kn… -- View this message in context: http://forum.world.st/Cobol-is-the-new-language-to-know-tp3317188p3317188.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 21, 2011

[Pharo-project] Issue 3740 in pharo: Provide Settings to directly open the full Debugger View

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3740 by camillob...(a)gmail.com: Provide Settings to directly open the full Debugger View http://code.google.com/p/pharo/issues/detail?id=3740 Instead of only opening the small preview window which requires another interaction to get to the full debugger view, directly open the full debugger view. Since this is triggered by a setting, the default behavior is unaffected. Attachments: FullDebuggerSettings.2.cs 5.4 KB

Feb. 21, 2011

Re: [Pharo-project] Issue 1915 in pharo: Making ToolSet more flexible

by pharo＠googlecode.com

Comment #6 on issue 1915 by siguc...(a)gmail.com: Making ToolSet more flexible http://code.google.com/p/pharo/issues/detail?id=1915 This is a changesets for new ToolRegistry. See class comment for use. A pomodoro technique should be applied to fix all direct references to various tools. A following script can be used to detect them: Smalltalk tools browseDirectToolReferences Attachments: ToolRegistry.3.cs 10.1 KB ToolRegistry-changes.8.cs 30.3 KB

Feb. 21, 2011