- Pharo-dev - lists.pharo.org

[Pharo-project] So...we freeze 1.1 ? (next steps?)
by Torsten Bergmann May 17, 2010

May 17, 2010

>> But now we should go beta=releaseCandidate1 >> >> >No, I don't agree. That's not the same. One thing is beta and another thing >is a release candidate. While I appreciate that Stef wants to push out 1.1. quickly since there are so many good things in this release we should clearly start to build a beta, test it and then (based on these results) have a first release candidate. Pharo core is stable - but is pharo-dev already? We really should have a beta. We all know: Pharo = core + packages >Imagine you are going to download a software which is in RELEASE CANDIDATE >and has a lot of problems and bugs....is not good for marketing. especially if the website says: "Pharo is an attractive platform to build and deploy mission critical Smalltalk applications." So +1 for Mariano here Mariano: what is the state of building a dev image from the core for 1.1.? Last time I tried the ConfigurationOfPharo with 1.1. I run into the condense changes problem - which I thing was fixed now. Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4 5

[Pharo-project] maybe a stupid question :)
by Torsten Bergmann May 17, 2010

May 17, 2010

>I mean "pharo" is "pharo core" Is Linux only the Kernel? No. You have a Linux version (distro) and the kernel version. >and "pharo dev" is just pharo+packages loaded Pharo-dev is what is distributed by default and typically called "Pharo". Similar to the platform and loaded packages in Eclipse or the linux kernel with loaded packages to form a Linux system. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 5

Re: [Pharo-project] [Vm-dev] CMake for Windows?
by Mariano Martinez Peck May 17, 2010

May 17, 2010

On Sun, May 16, 2010 at 11:15 PM, Geoffroy Couprie <geo.couprie(a)gmail.com>wrote: > > Hello, > > Here is the latest set of files for CMake: > http://eleves.ec-lille.fr/~couprieg/divers/changes-16-05-10.tar.gz<http://eleves.ec-lille.fr/%7Ecouprieg/divers/changes-16-05-10.tar.gz> > (you have to remove platforms/win32/vm/config.h to make it build) > > I tried to remove the dependency on the Squeak-win2-tools package. The > Direct3D code still uses a lot of DirectX 7 structures, and the recent > MinGW toolchain provides DirectX 8, so the B3DAccelerator plugin > doesn't build right now. If it's ok, I'll send other patches to make > it work with the new version. Otherwise, it's possible to modify > config.cmake for B3DAccelerator to use DirectX 7. > > Could these patches be included now? The Unix VM builds without any > problem, so it can become the main way to build it (just replace > platforms/unix/cmake/configure by platforms/cmake/configure in the > tutorials). There may still be some problems with the Windows build, > but I'll send more patches once these are pushed in the svn :) > > Hi Geoffroy. This is cool work. I cannot help you in the details of how to commit that in SVN as I have no idea. Listen to David. Now...I have a couple of ideas: 1) regardless that, it would be really really cool if you can document all this in the pharo collaborative book. As you can see there is already a chapter for VM http://book.pharo-project.org/book/Virtual-Machine/ and the windows part is empty: http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnWindow… So...we can write the two possibilities to compile in Windows: the standard one and this new one using CMake. You can start writing the one of CMake :) If you want, please just let us know and we create a user for you. 2) In addition, I think it would be a good idea to have a Git for scripts for the VM. If Squeak VM developers like them, they can also include it in the svn. Laurent Laffont already has a git repository with scripts like easy_squeakvm or something like that. So, you may want to commit your code there too. 3) What about integrating like easy_squeakvm with this ? or do a easy_squeakvm version of CMake for winwows ? I would love to do for example: ./easy_squeakvm.sh --os=Windows or ./easy_squeakvm.sh --os=Unix 4) Would be really great to have a Screencast about how to compile windows with CMake :) Cheers and continue pushing. Mariano > Best regards, > > Geoffroy >

2 1

[Pharo-project] Community Supported Packages
by Torsten Bergmann May 17, 2010

May 17, 2010

Hi Chris, >I don't know if you watched all that carefully, but in the last 48 hours >we've made our decision >You seem to think we're having a discussion about it. That's what I would call a very quick decision after the proposal from Saturday leaving out people who didnt follow over the weekend. But since the people who showed up agreed with Andreas I'm fine with the decision. However using Monticello in one or the other way will have an impact on future development and how people can contribute. >I think at bottom you are more of a Pharo guy. Yes, maybe I'm biased since I now usually use Pharo images since they satisfy more needs I personally know from other Smalltalk and non-Smalltalk environments. On the other side I'm with Squeak from the beginning, still contribute and try to keep up compatibility for packages as much as possible. There are many things that make up Squeak different and unique. I've contributed code, fixes, packages, discussions, installer code, help system to both: Squeak and Pharo and still try to keep them as compatible as possible. So what did you do to prevent reinventing the wheel within the broader community? >Added to which, you say that Pharo has packages to manage? Yes, look at ConfigurationOfPharo and you will find the packages forming the Pharo release from a pharo core. Also look at squeaksource/MetacelloRepository - for other configurations (sadly only a few of them work for Squeak yet) You seem to think that Pharo is solely there to satisfy Seaside users which is a very naive view. >I repeat, you are one step behind the times, Torsten Looks like I'm old and behind the times since I was not able to read and respond over the weekend B) >We have chosen. Colin has just created the first test case. Which will make my "Squeak/Pharo dissociative identity disorder" a little bit harder since I have another difference. Nonetheless I continue with both even when I'm still behind the times ;) Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 1

[Pharo-project] Class>>rename:
by Fernando olivero May 17, 2010

May 17, 2010

Hi , please integrate this change to Class>>rename: rename: aString "The new name of the receiver is the argument, aString." | oldName newName | (newName := aString asSymbol) = (oldName := self name) ifTrue: [^ self]. (self environment includesKey: newName) ifTrue: [^ self error: newName , ' already exists']. name := newName. self environment renameClass: self from: oldName. (Undeclared includesKey: newName) ifTrue: [self inform: 'There are references to, ' , aString printString , ' from Undeclared. Check them after this change.']. I moved the (Undeclared..... ) statement to the end. To send #inform: after performing the actual change, and not before. In this way you can catch the ProvideAnswerNotification, and remove the modal dialog that pops up and still perform the actual class rename! For example... [ self performRefactoring: refactoring ] on: ProvideAnswerNotification do:[:err | " do not inform the user! " ]. Please let me know if you agree, and will integrate it. Saludos, Fernando

4 7

[Pharo-project] [squeak-dev] Community Supported Packages
by Torsten Bergmann May 17, 2010

May 17, 2010

Mariano Martinez Peck wrote on [1]: >I don't agree here. You DON'T necessary need to have the packages inside the >image to have a UI. Please read what I wrote. I did not say that it is impossible to build the UI when you have an external config - but "it would be easy to build a UI" when it is already in the image. I'm sure you will agree here. However - even when SqueakMap is not well maintained - it's UI was easy to use and was easy accessible and one could use it with a few clicks. Using Monticello tools, loading and evaluating by hand is currently possible - but this is a step backward in usability compared to what Squeak has/had. But this is a convenience/tool issue that has to be solved. Bye T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/026829.html -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

3 2

[Pharo-project] New inspector news :)
by StÃ©phane Ducasse May 17, 2010

May 17, 2010

> It is fixed in the last version of NewInspector (on squeaksource). > > I removed from ProtoObject the calls to methods defined only in Object. I have to replace the calls by a default behavior: there is no way to inspect inst vars of a subclass of ProtoObject (and not Object). > > But NewInspector is designed to be extensible by anyone. For example, take a new class Proxy inheriting from ProtoObject with an instance variable named #object. You can firstly redefine the label redefining the method niLabel in the Proxy class (instance side): > > Proxy>>niLabel > ^ 'Proxy on: ' , object niLabel > > But you can also add a child for inspecting the inst var object with a label beginning by 'Object: ', redefining the method niConfiguration: > > Proxy>>niConfiguration > ^ super niConfiguration > addLast: [:obj | object asNINode label: 'Object: ' , object niLabel; yourself]; > yourself > > Note that the parameter obj of the block must be written but it is not really used. I must remove it in a next version of NewInspector. Write it and forget it :) > > The description (in the right pane) and the icon (between the triangle and the name of a node in the tree) can be also redefined. See the implementors of niLabel, niConfiguration, niDescription and niIcon for examples. > > FrÃ©d > > " > > Bien Ã toi, > > FrÃ©d > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > 2010/5/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > http://code.google.com/p/pharo/issues/detail?id=1970 > > peut etre que si la superclass est pas Object > alors instVArNamed: doit etre evite je ne sais pas en fait. > > Stef >

1 0

[Pharo-project] Vertical scroll disappear with OB in Pharo 1.1
by Mariano Martinez Peck May 17, 2010

May 17, 2010

Hi Lukas. In the latest code of OB in Pharo 1.1 if the size of the System Browser is too small, the vertical scroll disappear. I tried in PharoCore and there it doesn't happen. Look the two attached screenshots. Cheers mariano

2 2

[Pharo-project] Issue 2435 - DNU in cleanUpForRelease
by Torsten Bergmann May 17, 2010

May 17, 2010

see http://code.google.com/p/pharo/issues/detail?id=2435 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2 1

Re: [Pharo-project] [squeak-dev] Re: Problem with variable capture in blocks or ? #7532
by Eliot Miranda May 17, 2010

May 17, 2010

On Sun, May 16, 2010 at 3:32 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Ken - > > Very interesting. Looks like an issue with OutOfScopeNotification. The > problem appears to be that this code: > > "..." [ :a | a ]. > "..." a. > > generates an OutOfScopeNotification that is being suppressed in workspaces > (I'm not exactly sure why that is). This is of course is interesting because > of the highly unusual situation of a temp shadowing a global instead of > another temp / ivar. For example, this wouldn't compile: > > | a | > [ :a | a ]. > > But stranglely, this does: > > [ :Object | Object ]. > > so your example code is roughly equivalent to running: > > b := [ :Object | Object ]. > c := b value: Object. > > When you run this line by line it works 'as expected' and when you run it > as a single doIt you get the result of c being a "[closure] in > UndefinedObject>>DoIt" due to the OutOfScopeNotification. > > Hope this explains the issue - as for how to fix it, I have no clue :-) > Yes, the bug is that Encoder>>encodeVariable:sourceRange:ifUnknown: doesn't continue from a caught OutOfScopeNotification by answering the ifUnknown: action. Instead it returns the out-of-scope block temp. This is a rather serious compiler bug that I'd left unfixed because it only bites in workspaces (apologies) and I didn't have a small example to analyse before (thanks Ken!). The code generated is actually equivalent to b := [ :a | a ]. c := b value: <temp 0>. Since there aren't any temps, temp 0 is top of stack, which just happens to be the closure just created by the preceding bytecode. e.g. look at bytecode 49 in the following: a := 4. b := [ :a | a ]. c := b value: a. { a. b. c } thisContext method symbolic The fix is simple. When an OutOfScopeNotification is caught the Encoder should still answer what ever it should for an out of scope variable. In Encoder>>encodeVariable:sourceRange:ifUnknown: the statements (varNode isTemp and: [varNode scope < 0]) ifTrue: [ OutOfScopeNotification signal ifFalse: [ ^self notify: 'out of scope']. ]. ^ varNode should read (varNode isTemp and: [varNode scope < 0]) ifTrue: [^OutOfScopeNotification signal ifTrue: [action value] ifFalse: [self notify: 'out of scope']]. ^varNode Find attached: !Encoder methodsFor: 'encoding' stamp: 'eem 5/16/2010 17:33'! encodeVariable: name sourceRange: range ifUnknown: action | varNode | varNode := scopeTable at: name ifAbsent: [(self lookupInPools: name ifFound: [:assoc | varNode := self global: assoc name: name]) ifTrue: [varNode] ifFalse: [^action value]]. range ifNotNil: [name first canBeGlobalVarInitial ifTrue: [globalSourceRanges addLast: { name. range. false }]]. (varNode isTemp and: [varNode scope < 0]) ifTrue: [^OutOfScopeNotification signal ifTrue: [action value] ifFalse: [self notify: 'out of scope']]. ^varNode! ! P.S. this is probably applicable to any Squeak bytecode compiler (including eToys). The only change in my closure compiler from Andreas' 2003 version was changing "name first isUppercase" to "name first canBeGlobalVarInitial". P.P.S. Again Ken, thanks for a comprehensible example. It always bit me in huge doits I was using to analyse the entire system's compiled methods, and invariably crashed the VM. I never took the time to isolate the bug, I just fixed the doit and continued. Turns out to be very simple. best Eliot > Cheers, > - Andreas > > > > On 5/16/2010 12:35 PM, Ken Causey wrote: > >> Well, it's nothing new but this one has stumped me: >> >> http://bugs.squeak.org/view.php?id=7532 >> >> Initially I (and Frank) thought the reporter was mistaken until we >> understood that the problem shows up when you execute the main code all >> in one do-it. I've since modified the original report to make this >> clearer. >> >> So here it is: >> >> a := 4. >> b := [ :a | a ]. >> c := b value: a. >> >> If you SELECT ALL OF THIS AND EXECUTE IT ALL AT ONE TIME (crucial >> detail). The result is that a is 4, b is a BlockClosure, and c is a >> BlockClosure not 4 as expected. Execute each statement separately and c >> is 4. >> >> Alternately, from a suggestion from jmckeon, if you specify a different >> symbol for the block argument: >> >> a := 4. >> b := [ :d | d ]. >> c := b value: a. >> >> when executed all at one time works as you would expect: a is 4, b is a >> BlockClosure, and c is 4. (and d is nil) >> >> So what's up? >> >> Ken >> >> >> >> > >

3 2