- Pharo-dev - lists.pharo.org

[Pharo-project] Clipboard startUp
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

Hi torsten you posted the following and I wanted to know whether we should not add something in the shutdown list. Stef initialize "SystemDictionary initialize" | oldList | oldList := StartUpList. StartUpList := OrderedCollection new. "These get processed from the top down..." #( Delay DisplayScreen Cursor InputEventFetcher ProcessorScheduler "Starts low space watcher and bkground." LanguageEnvironment FileDirectory "Enables file stack dump and opens sources." NaturalLanguageTranslator ShortIntegerArray ShortRunArray CrLfFileStream Clipboard ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList ifNotNil: [oldList do: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToStartUpList: theClass]]]. #( ImageSegment PasteUpMorph "ControlManager" ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList := ShutDownList. ShutDownList := OrderedCollection new. "These get processed from the bottom up..." #( Delay DisplayScreen InputEventFetcher Form "ControlManager" PasteUpMorph StrikeFont Color FileDirectory SoundPlayer HttpUrl Password PWS MailDB ImageSegment ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToShutDownList: cls]. ]. oldList ifNotNil: [oldList reverseDo: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToShutDownList: theClass]]].

3 2

[Pharo-project] [ANN] 10372 and 10373
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

10372 ScriptLoader loadFFI should work please check better comment on ScriptLoader http://code.google.com/p/pharo/issues/detail?id=637 cleans out Undeclared 10373 Issue 943: fix polymorph cursor Polymorph Fix for colouring of submenu markers. W2K Improvements. Fix for drop-list button label in W2K theme. Support for adjustment of label inset for buttons when pressed. Added #setColor: to ColorPresenterMorph to enable use without a model. Quit gets back its normal behavior Issue 944: SUnit assert:equals SUnit assert equals + better feedback message Strange the cursor for submenu does not work... Next probably MouseOverHandler refactoring.... Stef

1 0

[Pharo-project] Just a little point
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

Hi guys After all the mails in Squeak-dev and all these nice words or explicit suggestions about us been assholes, destructors... whatever :) I would like to share with you my mindset to you. We do not want a war, nor world domination. :) We are doing pharo because Smalltalk deserves a good and beautiful opensource implementation. Our goal is not to kill Squeak. Our goal is to provide a vehicule on top of which people can invent their future been it - multimedia - seaside - kids - research We need a place to expand beauty. We want that students can get enthusiast about Smalltalk and not turned down by some ugly code. We want an agile system with lot of tests, comments, clean code, driven bit a lot of good software engineering practices. I really thank the people that trust us. Stef PS: I'm one the guy that wrote 3 squeak book, 1 seaside book (coming soon), translated etoys in french, so I'm laughing when people suggest that we are predators.

6 14

Re: [Pharo-project] [squeak-dev] Re: Just a little point
by Janko MivÅ¡ek July 7, 2009

July 7, 2009

Sorry Keith, but I must say this: The obvious reason Pharoers reject your contributions are not contributions as such but your attitude as the contributor. And I'd do the same, reject them, because they are dangerous. Because they bring you and your attitude with them. Please think that way a bit. For the sake of Squeak community and our progress. And for the sake of your work at the end. Changing your attitude will change the acceptance of your work too, be sure! Best regards Janko Keith Hodges pravi: >> If find it weird that 2 Smalltalk implementations/communities, so >> close to each other like Squeak and Pharo, go to great lengths at >> flaming each other... > > No they don't, it's just me. > > Please don't tar the mostly polite squeak-dev with my brush. > > I spent a lot of time working on stuff that pharo could use, > particularly because a lot of it was Stephane's idea in the first place, > going back to August 2006. > > My two main points of contention are Monticello and SUnit but as you can > see there are others. > > Monticello: I put a LOT, read LOTS of effort into joining the 3+ > Monticello forks into one, and assuring that it loads in to all forks of > squeak, as a strategic approach for the whole community to have common > tools everywhere. > Pharo has made that effort a waste of time, simply because they wont use > or contribute to the merged uber-Monticello. > > SUnit: I put a second lot of effort into improving SUnit so that it > could support multiple forks of squeak simultaneously. I also wrote a > non Gui test runner for automated testing. SUnit is a public resource > and is maintained in a public repository. Pharo have needlessly forked > SUnit. > > Several things that wind me up, one is wasted effort, and another is > duplicated effort, and the third is making plans to duplicate effort on > purpose. >> that will only leave us isolated, both in our own camps ? I'm >> puzzled! What do I do if I like both? Choose my camp or abandon them >> both ? > If you like both, then please encourage them to make parts that could be > common common. For example I maintain ProcessSpecific for Logging, Pharo > has integrated ProcessSpecific but has made no attempt to pick or offer > feedback to version that was maintained. This is one of numerous example > of subsystems that could easily be mutually maintained. > > There are many initiatives in the pharo camp, that could be developed > and deployed into both camps. I spent all that time on Monticello in > order to ensure that this could happen, but pharo only develops > initiatives for itself, therefore Pharo is effectively planning for > duplicated effort. > > One more example, Pharo could come up with an initiative to fix the > sources/changes file mess. This would be very benefitcial to me. However > its no good if I cant load it into squeak where a lot of my code runs. > So at some point someone would have to duplicate the effort for Squeak. > All it would take is a little thought and planning. > > When I took the initiative to write Rio as a replacement for > FileDirectory, I did it in such a way as anyone could benefit. > When I took the initiative to write Logging as a potential core feature > for Kernel/Server images I did it so that anyone could benefit. > When I wrote the TestReporter as a text based tool for testing I did it > so that anyone could benefit. > When I wrote Bob for automated image building and testing I have done it > so that it can build any image. > When I wrote Sake for rake like functionality it loads into any image. > When I wrote Sake/Packges for managing packges dependencies I did it so > that any image can benefit. > > I dont know what initiatives pharo has completed, but, and please do > correct me if I am wrong. I havent seen a single initiative from pharo > that has been developed and deployed so that everyone could benefit. > > best regards > > Keith -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

2 1

[Pharo-project] Fwd: about sensor vs. InputSensor in primitiveError:
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

> > > should not this method use InputSensor? > > primitiveError: aString > "This method is called when the error handling results in a > recursion in > calling on error: or halt or halt:." > > | context | > (String > streamContents: > [:s | > s nextPutAll: '***System error handling failed***'. > s cr; nextPutAll: aString. > context := thisContext sender sender. > 20 timesRepeat: [context == nil ifFalse: [s cr; print: > (context := context sender)]]. > s cr; nextPutAll: '-------------------------------'. > s cr; nextPutAll: 'Type CR to enter an emergency evaluator.'. > s cr; nextPutAll: 'Type any other character to restart.']) > displayAt: 0 @ 0. > [Sensor keyboardPressed] whileFalse. > Sensor keyboard = Character cr ifTrue: [Transcripter > emergencyEvaluator]. > World install "init hands and redisplay" > > >

2 2

[Pharo-project] :( no integration because of bad network connection...
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

Hi I wanted to integrate some fixes but apparently the network here does not let me use MC... so probably later tonight. Stef

1 0

[Pharo-project] OB, Completion and class variables (when used on the class side)
by Torsten Bergmann July 7, 2009

July 7, 2009

Hi there, try the following in the new pharo-dev: - create a package in OBBrowser - create a class "Foo" and add a class variable "Bar" to it - start typing a class side method by typing initBar "a class side method to init the class variable" Bar directly after "Bar" hit space and then press Tab to start with the completion. -> you get a DNU (Undefined object DNU #classPool) in ECClassVarTypeGuesser>>MethodRefs ... Bye Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

2 1

[Pharo-project] Image overwrite warning
by Torsten Bergmann July 7, 2009

July 7, 2009

Is it just me or does the latest pharo(-dev) not warn anymore if you save the image to an image file that already exist (when using "save as")? Also why are the arrows in folded menus now white? Black was better visible on the light background. Thanks Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

4 7

[Pharo-project] [ANN] Win32 Pharo setup 0.0.0.5. (based on Pharo0.1-10371)
by Torsten Bergmann July 7, 2009

July 7, 2009

A new win32 setup is available at https://gforge.inria.fr/frs/download.php/22616/setup_pharo_0.0.0.5.exe which is based on pharo0.1-10371dev09.07.1.zip (see http://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010436.html Previous Win32 Setups are still available on: https://gforge.inria.fr/frs/?group_id=1299 Have fun Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

1 0

[Pharo-project] Loads of Pharo development process questions
by Reinout Heeck July 7, 2009

July 7, 2009

I'm having trouble wrapping my head around how the Pharo development/ maintenance process is supposed to work. Most of these seem to be missing info on the wiki which merely need fleshing out there, I would update the wiki pages myself if only I knew what to write... Please bear in mind that I'm a newbie to Squeak, so some of these questions may be rather naive. One of my motivations is to evaluate the future viability of Pharo as a vehicle for commercial applications and whether it warrants to lobby for resources being allocated to its development. So here goes: The wiki mentions 'kernel' and 'MiniImage' as not being in scope of Pharo. What does that entail, does this mean that discussions about allowing nil in Sets are out of scope? What is the status of the dev-image? As delivered the tools are broken (because context menus on the source pane raise an UHE that is induced by OB-Enhancements, issue 904), is it actively used by the main committers or is the core image the place to be? Even more confusingly the above issue has been marked as fixed this night but if I do a World->System->Software Update the bug persists in my image. When I looked into fixing it myself I got confused (because I looked at InstallScript.st), it seems the code comes from various repositories -- not a single Pharo respository/branch. Are these various repositories Pharo-specific and maintained over Pharo-Inbox or do I need to submit fixes to different places? I guess as a Squeak newbie I need a high-level overview on the wiki on how code and fixes flow within Pharo, towards Squeak and towards the various tool maintainers (and back to Pharo of course, the upstream/ downstream story). What is the story when such tools and Pharo become incompatible and need to fork (or are they already forked)? Is there a vision on long-term support? Pharo wants to be agile and be free to change at will (IMO a good decision) but if it is to be viable at my job there need to be versions that receive long-term support (the 'professional' aspect of Pharo). At least bug fixes (and hopefully speed enhancements) need to be ported back to an 'LTS' release for quite a while (I'm thinking three to four years here) and on a consistent/reliable basis if Pharo is to be viable for the kind of projects I work on. Porting our projects (and project specific tool enhancements) forwards turns out to be very expensive (even in a 'conservative' environment like VisualWorks) so a mechanism needs to be in place to avoid needing too many porting moments over the lifetime of our projects (think 10+ years). The process of updating the dev image is excruciatingly slow, is this normal? The process seems to be CPU bound and takes ages for what I consider a small amount of changes - in its current state it would be unusable for the process we use at work, it will need to be brought back to well under a minute as opposed to the twenty (or so) minutes it took me yesterday. What is the background and vision for the future on this issue? Let me finish with a quick and easy newbie question: where do I find the profiler tools for Pharo? Thanks! Reinout -------

7 14