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

Re: [Pharo-project] [Pharo-users] [COTDC] 92 - TSortable

by StÃ©phane Ducasse

I represent a set of methods related to element sorting. My public api is composed of messages sort, isSorted, isSortedBy:, sort: To get the behavior I define, my users should implement - isEmpty - size - first - at: Stef On Dec 6, 2011, at 4:09 PM, sean(a)clipperadams.com wrote: > 92 classes done > 793 classes remaining > Continuing in Collections... > > Today: TSortable > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Eliot Miranda

On Tue, Dec 6, 2011 at 1:07 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> Hi, >>> >>> I want make a little report about progress with making of Fedora >>> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by >>> Jaroslav Å karvada. >>> >>> Currently there are three packages in Fedora repositories - squeak-vm, >>> squeak-image and squeak-vm-nonXOplugins (that contains plugins like >>> OSProcess). It uses resources from the Squeak site. >>> >>> Red Hat has quite restrictive demands on packages and it is a small >>> miracle that they tolerate current squeak packages :-). The conditions >>> simply do expect that a program is a set of source codes and not a >>> system of communicating objects. One problem is that Squeak VM is one >>> of few metacircular packages that are needed for their own building. >>> Because binary executables are prohibited, it would require a special >>> bureaucratically problematic exception. Fortunately for virtual >>> machine generation we may use the current squeak packages - more >>> precisely their updated versions. The next issue for virtual machine >>> generation may be the fact, that some packages used for VM generation >>> are in repositories with public read&write permissions. >>> >>> Because image can be likened to *.jar files that are prohibited and >>> must be recompiled during package generation, we are lucky that >>> squeak-image package is currently accepted. If someone starts >>> tinkering, we are in big trouble. >>> >>> There is a little issue with *.sources placement. The current VM >>> package contains symlinks from VM path to sources files that are >>> present in package with the image. This is really ugly solution. >>> Squeak and Pharo uses this sequence for sources lookup: vm path, image >>> path, current path. So I think that the best solution will be to have >>> sources file in the image package, do not have symlinks in vm package >>> and to create symlink to sources together with changes in the image >>> path via mysqueak initialization script. >>> >>> Btw., Jaroslav told me that he saw a lot of creepy projects but >>> nothing like Squeak VM :-) >>> >>> And there is a mess in VM versioning. What is the latest CogVM/StackVM >>> version number? >>> >> >> How so? My latest version is SVN >> http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello >> package http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. >> > > But where is such information stored? > Then, the VMMaker package version says nothing, because to buiyld the VM > you need more packages than VMMaker, so you have to guess which version to > use. > Moreoever, there is also ANOTHER version in VM which is VMMaker > class>>versionString which is different from that. > Then from the image or from a log we get: VM: Mac OS - intel - 1068 - > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog > 3.0.0 > so where it is the svn version? > (1007 to: 1009) collect: [:n| Smalltalk getSystemAttribute: n] #('CoInterpreter VMMaker.oscog-eem.138 uuid: f9a63bdf-7bbc-4ae5-9634-ecd6fd814c9d Nov 18 2011' 'StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: c2849383-9768-4948-b9b2-a5c22d482b07 Nov 18 2011' 'r2519 http://www.squeakvm.org/svn/squeak/branches/Cog') Good enough? In fact, only the last is required since the VM and plugin source is included in http://www.squeakvm.org/svn/squeak/branches/Cog/src. > So...all in all, I think that indeed, it is quite a mess. But it is also > complicated to manage and I don't really know what to suggest. > With ConfigurationOfCog at least with one number we group all image side > related packages. > Then we only need svn/git version. Moreover, we can store this svn/git as > the description in each version of ConfigurationOfCog. That way, you know > *exactly* what do you need. > > Cheers > > > >> >> >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by StÃ©phane Ducasse

In january we will brand our VM and build VM tests. We should improve on that and we should be more to work there and not only igor. Stef

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Mariano Martinez Peck

On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> Hi, >> >> I want make a little report about progress with making of Fedora >> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by >> Jaroslav Å karvada. >> >> Currently there are three packages in Fedora repositories - squeak-vm, >> squeak-image and squeak-vm-nonXOplugins (that contains plugins like >> OSProcess). It uses resources from the Squeak site. >> >> Red Hat has quite restrictive demands on packages and it is a small >> miracle that they tolerate current squeak packages :-). The conditions >> simply do expect that a program is a set of source codes and not a >> system of communicating objects. One problem is that Squeak VM is one >> of few metacircular packages that are needed for their own building. >> Because binary executables are prohibited, it would require a special >> bureaucratically problematic exception. Fortunately for virtual >> machine generation we may use the current squeak packages - more >> precisely their updated versions. The next issue for virtual machine >> generation may be the fact, that some packages used for VM generation >> are in repositories with public read&write permissions. >> >> Because image can be likened to *.jar files that are prohibited and >> must be recompiled during package generation, we are lucky that >> squeak-image package is currently accepted. If someone starts >> tinkering, we are in big trouble. >> >> There is a little issue with *.sources placement. The current VM >> package contains symlinks from VM path to sources files that are >> present in package with the image. This is really ugly solution. >> Squeak and Pharo uses this sequence for sources lookup: vm path, image >> path, current path. So I think that the best solution will be to have >> sources file in the image package, do not have symlinks in vm package >> and to create symlink to sources together with changes in the image >> path via mysqueak initialization script. >> >> Btw., Jaroslav told me that he saw a lot of creepy projects but >> nothing like Squeak VM :-) >> >> And there is a mess in VM versioning. What is the latest CogVM/StackVM >> version number? >> > > How so? My latest version is SVN > http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello > package http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. > But where is such information stored? Then, the VMMaker package version says nothing, because to buiyld the VM you need more packages than VMMaker, so you have to guess which version to use. Moreoever, there is also ANOTHER version in VM which is VMMaker class>>versionString which is different from that. Then from the image or from a log we get: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog 3.0.0 so where it is the svn version? So...all in all, I think that indeed, it is quite a mess. But it is also complicated to manage and I don't really know what to suggest. With ConfigurationOfCog at least with one number we group all image side related packages. Then we only need svn/git version. Moreover, we can store this svn/git as the description in each version of ConfigurationOfCog. That way, you know *exactly* what do you need. Cheers > > >> >> Cheers, >> -- Pavel >> >> > > > -- > best, > Eliot > > -- Mariano http://marianopeck.wordpress.com

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Eliot Miranda

On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi Eliot, > > On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek < > pavel.krivanek(a)gmail.com> > > wrote: > >> > >> Hi, > >> > >> I want make a little report about progress with making of Fedora > >> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by > >> Jaroslav Å karvada. > >> > >> Currently there are three packages in Fedora repositories - squeak-vm, > >> squeak-image and squeak-vm-nonXOplugins (that contains plugins like > >> OSProcess). It uses resources from the Squeak site. > >> > >> Red Hat has quite restrictive demands on packages and it is a small > >> miracle that they tolerate current squeak packages :-). The conditions > >> simply do expect that a program is a set of source codes and not a > >> system of communicating objects. One problem is that Squeak VM is one > >> of few metacircular packages that are needed for their own building. > >> Because binary executables are prohibited, it would require a special > >> bureaucratically problematic exception. Fortunately for virtual > >> machine generation we may use the current squeak packages - more > >> precisely their updated versions. The next issue for virtual machine > >> generation may be the fact, that some packages used for VM generation > >> are in repositories with public read&write permissions. > >> > >> Because image can be likened to *.jar files that are prohibited and > >> must be recompiled during package generation, we are lucky that > >> squeak-image package is currently accepted. If someone starts > >> tinkering, we are in big trouble. > >> > >> There is a little issue with *.sources placement. The current VM > >> package contains symlinks from VM path to sources files that are > >> present in package with the image. This is really ugly solution. > >> Squeak and Pharo uses this sequence for sources lookup: vm path, image > >> path, current path. So I think that the best solution will be to have > >> sources file in the image package, do not have symlinks in vm package > >> and to create symlink to sources together with changes in the image > >> path via mysqueak initialization script. > >> > >> Btw., Jaroslav told me that he saw a lot of creepy projects but > >> nothing like Squeak VM :-) > >> > >> And there is a mess in VM versioning. What is the latest CogVM/StackVM > >> version number? > > > > > > How so? My latest version is SVN > > http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello > package > > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. > > What is the relation between this SVN repository and Git repository > used by the CI server (https://git.gitorious.org/cogvm/blessed.git)? > Not anything to do with me. > What is the reason to exclude fbdev? > What's fbdev? > > -- Pavel > > >> Cheers, > >> -- Pavel > >> > > > > > > > > -- > > best, > > Eliot > > > > -- best, Eliot

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Pavel Krivanek

Hi Eliot, On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: >> >> Hi, >> >> I want make a little report about progress with making of Fedora >> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by >> Jaroslav Å karvada. >> >> Currently there are three packages in Fedora repositories - squeak-vm, >> squeak-image and squeak-vm-nonXOplugins (that contains plugins like >> OSProcess). It uses resources from the Squeak site. >> >> Red Hat has quite restrictive demands on packages and it is a small >> miracle that they tolerate current squeak packages :-). The conditions >> simply do expect that a program is a set of source codes and not a >> system of communicating objects. One problem is that Squeak VM is one >> of few metacircular packages that are needed for their own building. >> Because binary executables are prohibited, it would require a special >> bureaucratically problematic exception. Fortunately for virtual >> machine generation we may use the current squeak packages - more >> precisely their updated versions. The next issue for virtual machine >> generation may be the fact, that some packages used for VM generation >> are in repositories with public read&write permissions. >> >> Because image can be likened to *.jar files that are prohibited and >> must be recompiled during package generation, we are lucky that >> squeak-image package is currently accepted. If someone starts >> tinkering, we are in big trouble. >> >> There is a little issue with *.sources placement. The current VM >> package contains symlinks from VM path to sources files that are >> present in package with the image. This is really ugly solution. >> Squeak and Pharo uses this sequence for sources lookup: vm path, image >> path, current path. So I think that the best solution will be to have >> sources file in the image package, do not have symlinks in vm package >> and to create symlink to sources together with changes in the image >> path via mysqueak initialization script. >> >> Btw., Jaroslav told me that he saw a lot of creepy projects but >> nothing like Squeak VM :-) >> >> And there is a mess in VM versioning. What is the latest CogVM/StackVM >> version number? > > > How so? Â My latest version is SVN > http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Â Monticello package > http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)? What is the reason to exclude fbdev? -- Pavel >> Cheers, >> -- Pavel >> > > > > -- > best, > Eliot >

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by Eliot Miranda

On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > I want make a little report about progress with making of Fedora > pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by > Jaroslav Å karvada. > > Currently there are three packages in Fedora repositories - squeak-vm, > squeak-image and squeak-vm-nonXOplugins (that contains plugins like > OSProcess). It uses resources from the Squeak site. > > Red Hat has quite restrictive demands on packages and it is a small > miracle that they tolerate current squeak packages :-). The conditions > simply do expect that a program is a set of source codes and not a > system of communicating objects. One problem is that Squeak VM is one > of few metacircular packages that are needed for their own building. > Because binary executables are prohibited, it would require a special > bureaucratically problematic exception. Fortunately for virtual > machine generation we may use the current squeak packages - more > precisely their updated versions. The next issue for virtual machine > generation may be the fact, that some packages used for VM generation > are in repositories with public read&write permissions. > > Because image can be likened to *.jar files that are prohibited and > must be recompiled during package generation, we are lucky that > squeak-image package is currently accepted. If someone starts > tinkering, we are in big trouble. > > There is a little issue with *.sources placement. The current VM > package contains symlinks from VM path to sources files that are > present in package with the image. This is really ugly solution. > Squeak and Pharo uses this sequence for sources lookup: vm path, image > path, current path. So I think that the best solution will be to have > sources file in the image package, do not have symlinks in vm package > and to create symlink to sources together with changes in the image > path via mysqueak initialization script. > > Btw., Jaroslav told me that he saw a lot of creepy projects but > nothing like Squeak VM :-) > > And there is a mess in VM versioning. What is the latest CogVM/StackVM > version number? > How so? My latest version is SVN http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello package http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. > > Cheers, > -- Pavel > > -- best, Eliot

Dec. 6, 2011

Re: [Pharo-project] Squeak/Pharo in Fedora

by StÃ©phane Ducasse

> Hi, > > I want make a little report about progress with making of Fedora > pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by > Jaroslav Å karvada. Thanks!!!! > > Currently there are three packages in Fedora repositories - squeak-vm, > squeak-image and squeak-vm-nonXOplugins (that contains plugins like > OSProcess). It uses resources from the Squeak site. > > Red Hat has quite restrictive demands on packages and it is a small > miracle that they tolerate current squeak packages :-). The conditions > simply do expect that a program is a set of source codes and not a > system of communicating objects. One problem is that Squeak VM is one > of few metacircular packages that are needed for their own building. > Because binary executables are prohibited, it would require a special > bureaucratically problematic exception. Fortunately for virtual > machine generation we may use the current squeak packages - more > precisely their updated versions. The next issue for virtual machine > generation may be the fact, that some packages used for VM generation > are in repositories with public read&write permissions. > > Because image can be likened to *.jar files that are prohibited and > must be recompiled during package generation, we are lucky that > squeak-image package is currently accepted. If someone starts > tinkering, we are in big trouble. > > There is a little issue with *.sources placement. The current VM > package contains symlinks from VM path to sources files that are > present in package with the image. This is really ugly solution. > Squeak and Pharo uses this sequence for sources lookup: vm path, image > path, current path. So I think that the best solution will be to have > sources file in the image package, do not have symlinks in vm package > and to create symlink to sources together with changes in the image > path via mysqueak initialization script. > > Btw., Jaroslav told me that he saw a lot of creepy projects but > nothing like Squeak VM :-) ;) > And there is a mess in VM versioning. totally > What is the latest CogVM/StackVM > version number? > > Cheers, > -- Pavel >

Dec. 6, 2011

Re: [Pharo-project] [squeak-dev] could you test the attached?

by StÃ©phane Ducasse

> this shows that squeak related fix should be applied with care and that we should understand deeply our system. > > Not really. That was not a fix. It was a potential fix that I was asking people to test. sorry sorry that I was confused. > Marcus found a test case that demonstrated a problem with my fix. With Marcus' case I was able to correct my fix and today Levente committed my revised fix to Squeak and Marcus has updated Pharo. So things worked well. I found a bug, developed a partial fix, asked for testing help, got it, revised my fix. And this in a very difficult to understand part of the system. oh yes. I would really like to spend time reading this codeâ¦.. but no time. > I'm trying but I'm not happy with my knowledge on certain parts. But since there is little documentation and some abstractions > are not aligned, this makes everything more challenging. > > When I see the senders, I think that it will be delicate to fix > > Process>>terminate > "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." > > | ctxt unwindBlock oldList | > self isActiveProcess > ifTrue: [ > ctxt := thisContext. > [ ctxt := ctxt findNextUnwindContextUpTo: nil. > ctxt isNil ] whileFalse: > [ (ctxt tempAt: 2) ifNil: > [ ctxt tempAt: 2 put: nil. > unwindBlock := ctxt tempAt: 1. > thisContext terminateTo: ctxt. > unwindBlock value ]]. > thisContext terminateTo: nil. > self suspend ] > ifFalse: [ > "Always suspend the process first so it doesn't accidentally get woken up" > oldList := self suspend. > suspendedContext ifNotNil:[ > "Figure out if we are terminating the process while waiting in Semaphore>>critical: > In this case, pop the suspendedContext so that we leave the ensure: block inside > Semaphore>>critical: without signaling the semaphore." > (oldList class == Semaphore and:[ > suspendedContext method == (Semaphore compiledMethodAt: #critical:)]) ifTrue:[ > suspendedContext := suspendedContext home.]. > > "If we are terminating a process halfways through an unwind, try to complete that unwind block first." > (suspendedContext findNextUnwindContextUpTo: nil) ifNotNil: [ :outer | > (suspendedContext findContextSuchThat: [ :c | c closure == (outer tempAt: 1)]) > ifNotNil: [ :inner | > "This is an unwind block currently under evaluation" > suspendedContext runUntilErrorOrReturnFrom: inner ]]. > ctxt := self popTo: suspendedContext bottomContext. > ctxt == suspendedContext bottomContext ifFalse: [ > self debug: ctxt title: 'Unwind error during termination']] ]. > > Process>>complete: aContext > "Run self until aContext is popped or an unhandled error is raised. Return self's new top context, unless an unhandled error was raised then return the signaler context (rather than open a debugger)." > > | ctxt pair error | > ctxt := suspendedContext. > suspendedContext := nil. "disable this process while running its stack in active process below" > pair := ctxt runUntilErrorOrReturnFrom: aContext. > suspendedContext := pair first. > error := pair second. > error ifNotNil: [^ error signalerContext]. > ^ suspendedContext > > > > > > On Wed, Nov 16, 2011 at 8:58 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Hi All, > >> > >> I've found a bug in ContextPart>>#runUntilErrorOrReturnFrom: that in a > >> certain rare circumstance causes the method to peel back too much of the > >> stack. This method is used in the debugger (e.g. completeStep: et al) but > >> also in Process termination. So it is right at the heart of the system. > >> I'm loath to simply commit it I'd really appreciate y'all testing with the > >> fix and reporting any changes you see. It does not affect the trunk test > >> suite (there is a test, WeakSetInspectorTest, which is unreliable, but apart > >> form that no observed effects). So, brave souls, please try with the > >> attached and see if you come to grief or not. > >> -- > >> thanks, > >> Eliot > >> > > > > > > > > -- > > -- > > Marcus Denker -- denker(a)acm.org > > http://www.marcusdenker.de > > > > > > > > -- > best, > Eliot >

Dec. 6, 2011

[Pharo-project] keymapping problem: pasting in a pluggable text morph

by Tudor Girba

Hi, I am trying to handle pasting in a PluggableTextMorph, but there seems to be a problem induced by Keymapping. Consider the following simple case: morph := (PluggableTextMorph on: StringHolder new text: #contents accept: #acceptContents:) autoAccept: true; color: Color white; yourself. morph openInWindow In the regular Pharo image it behaves as expected: - If you type some text, it gets auto accepted (there is no orange triangle on the top right) - If you use Ctrl+v, it auto accepts - If you use Cmd+v (on Mac) or Alt+v (on Windows), it also auto accepts. When Keymapping is loaded we have a problem: - If you type some text, it gets auto accepted (there is no orange triangle on the top right) - If you use Ctrl+v, it auto accepts ===> But if you use Cmd+v (on Mac) or Alt+v (on Windows), the orange triangle appears. If you inspect the contents, indeed they are not updated. I tried to look into this, but I did not manage to get to the bottom of this. Can anyone help? Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Dec. 6, 2011