- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SqueakSource
by Marcus Denker April 27, 2011

April 27, 2011

On Apr 27, 2011, at 12:49 PM, Sven Van Caekenberghe wrote: > > On 27 Apr 2011, at 12:08, Fabrizio Perin wrote: > >> Ok Squeaksource is up again. I did run a script that should load the missing commits if they have been store on the disk. Please check if they are there otherwise you just have to commit them again. > > Thanks for effort, Fabrizio, it is not a very thankful job. > > Sadly, my commits are not back. > I can check if they are on disk. What exactly are the files missing? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Hudson version 2.0 is available
by Marcus Denker April 27, 2011

April 27, 2011

On Apr 26, 2011, at 6:03 PM, Henrik Sperre Johansen wrote: > On 26.04.2011 17:32, DougEdmunds wrote: >> Pharo is being developed on a Hudson 1.358 server (2010/05/14). >> Hudson has recently released version 2.0 (2011/04/21). >> http://hudson-ci.org/ >> >> -- >> View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > Takes some time to get INRIA operations to approve and do installation of new versions apparently :) Yes. I will ask again... > Anyways, I suspect the next installed version will be of Jenkins, not Hudson. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2

Re: [Pharo-project] Pharo 1.2.1 to Pharo 1.2.2
by Marcus Denker April 27, 2011

April 27, 2011

Hello, In 1.2 we did a bad change: updating is not possible as soon as there is no letter in the version name. This means that you need to change the version number before you can updated. I fixe that in 1.2.2, though, so this is the last time this is needed. On Apr 26, 2011, at 2:09 AM, Miguel CobÃ¡ wrote: > El lun, 25-04-2011 a las 11:00 -0500, Miguel CobÃ¡ escribiÃ³: >> How will this upgrade path will be handled? >> >> In some email of previous week this is mentioned: >> >> SystemVersion newVersion: 'Pharo1.2.2a'. > > I meant: > > SystemVersion newVersion: 'Pharo1.2.1a'. > > >> >> But evaluated in a Pharo 1.2.1 update 12345 starts updating from 12342 >> and stops on 12345, so I think that is wrong. >> >> Evaluating >> >> SystemVersion newVersion: 'Pharo1.2.2a' >> >> begin the update from 12346 and stops on 12350 so I think that is the >> correct one, right? >> >> Or should users begin with: >> >> https://gforge.inria.fr/frs/download.php/28436/PharoCore-1.2.2a-12345.zip >> >> and update from there? (This implies migrate to a new image, not so much >> a update from 1.2.1 to 1.2.2 but a migration). >> >> Thanks in advance. >> >> > > Anyone? > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-project] Hudson version 2.0 is available
by Marcus Denker April 27, 2011

April 27, 2011

On Apr 27, 2011, at 4:49 PM, Esteban Lorenzano wrote: > Hi, > In case we upgrade, maybe we better move on to jenkins, since hudson was forked because some license issues (which I don't understand, but I think jenkins is better :) ) > Yes, we will move to Jenkins. > Cheers, > Esteban > > El 27/04/2011, a las 11:05a.m., Marcus Denker escribiÃ³: > >> >> On Apr 26, 2011, at 6:03 PM, Henrik Sperre Johansen wrote: >> >>> On 26.04.2011 17:32, DougEdmunds wrote: >>>> Pharo is being developed on a Hudson 1.358 server (2010/05/14). >>>> Hudson has recently released version 2.0 (2011/04/21). >>>> http://hudson-ci.org/ >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Hudson-version-2-0-is-available-tp3475761p3475761.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> Takes some time to get INRIA operations to approve and do installation of new versions apparently :) >> >> Yes. I will ask again... >> >>> Anyways, I suspect the next installed version will be of Jenkins, not Hudson. >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] why getting the right infrastructure is the way to go!
by StÃ©phane Ducasse April 27, 2011

April 27, 2011

all that for getting a method definition hidden by another one :(. We should definitively changes the sources and changes absence of structure. changeRecordForOverriddenMethod: aMethodReference | sourceFilesCopy method position | method := aMethodReference actualClass compiledMethodAt: aMethodReference methodSymbol. position := method filePosition. sourceFilesCopy := SourceFiles collect: [ :x | x isNil ifTrue: [ nil ] ifFalse: [ x readOnlyCopy ] ]. [ | file prevPos prevFileIndex chunk stamp methodCategory tokens | method fileIndex == 0 ifTrue: [ ^ nil ]. file := sourceFilesCopy at: method fileIndex. [ position notNil & file notNil ] whileTrue: [ file position: (0 max: position - 150). "Skip back to before the preamble" [ file position < (position - 1) ] whileTrue: [ chunk := file nextChunk ]. "then pick it up from the front" "Preamble is likely a linked method preamble, if we're in a changes file (not the sources file). Try to parse it for prior source position and file index" prevPos := nil. stamp := ''. (chunk findString: 'methodsFor:' startingAt: 1) > 0 ifTrue: [ tokens := Scanner new scanTokens: chunk ] ifFalse: [ tokens := Array new "ie cant be back ref" ]. ((tokens size between: 7 and: 8) and: [ (tokens at: tokens size - 5) = #methodsFor: ]) ifTrue: [ (tokens at: tokens size - 3) = #stamp: ifTrue: [ "New format gives change stamp and unified prior pointer" stamp := tokens at: tokens size - 2. prevPos := tokens last. prevFileIndex := sourceFilesCopy fileIndexFromSourcePointer: prevPos. prevPos := sourceFilesCopy filePositionFromSourcePointer: prevPos ] ifFalse: [ "Old format gives no stamp; prior pointer in two parts" prevPos := tokens at: tokens size - 2. prevFileIndex := tokens last ]. (prevPos = 0 or: [ prevFileIndex = 0 ]) ifTrue: [ prevPos := nil ] ]. ((tokens size between: 5 and: 6) and: [ (tokens at: tokens size - 3) = #methodsFor: ]) ifTrue: [ (tokens at: tokens size - 1) = #stamp: ifTrue: [ "New format gives change stamp and unified prior pointer" stamp := tokens at: tokens size ] ]. methodCategory := tokens after: #methodsFor: ifAbsent: [ 'as yet unclassifed' ]. (self includesMethodCategory: methodCategory ofClass: aMethodReference actualClass) ifTrue: [ methodCategory = (Smalltalk globals at: #Categorizer ifAbsent: [ Smalltalk globals at: #ClassOrganizer ]) default ifTrue: [ methodCategory := methodCategory , ' ' ]. ^ ChangeRecord new file: file position: position type: #method class: aMethodReference classSymbol category: methodCategory meta: aMethodReference classIsMeta stamp: stamp ]. position := prevPos. prevPos notNil ifTrue: [ file := sourceFilesCopy at: prevFileIndex ] ]. ^ nil ] ensure: [ sourceFilesCopy do: [ :x | x notNil ifTrue: [ x close ] ] ]

2 1

[Pharo-project] [update 1.2] #12351
by Marcus Denker April 27, 2011

April 27, 2011

12351 ----- Issue 4078: New TextEditor mouse selection broken -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Backward compatibility [WAS] Re: [Pharo-users] [ANN] PharoDev-1.3-13173
by Mariano Martinez Peck April 27, 2011

April 27, 2011

On Wed, Apr 27, 2011 at 11:25 AM, Ted F.A. van Gaalen <tedvga(a)gmail.com>wrote: > Hi Marcus > As I wrote, I am thinking from the perspective > of an application developer, a typical pharo-user ? > imagine that I/we have hundreds of > apps written, will they run unchanged > say 5 years from now? > Probably not. We would like to improve the system and clean it. Unfortunately, sometimes there is no other way than loosing backward compatibility. What do you prefer? Pharo choose a better system. If you/companies do not even collaborate with updating your code (don't say even fixing bugs or submitting code) ...then don't expect anything from Pharo. Pharo is open-source, free and it is build in the free time. And I think Pharo is not the only one....out there most of the languages change a lot between versions, Python, blah. Cheers Mariano > > Regards > Ted > > On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote: > > > >> Good morning Mariano > >> > >> This is something I wrote to Adrian Lienhard, > >> when an image did not run, straight out of the box > >> so to speak, because of VM differences > >> Some thoughts about reliability, and, very important > >> IMHO, upward compatibility. > >> > >> Thanks & Regards > >> Ted > >> > >>>>> > >> ? > >> I did expect that, nota bene working with > >> the Seaside supplied one-click image and > >> the virtual machine supplied with it, > >> provided on the Seaside.st site itself, > >> that everything is (and remains) > >> 100% upward compatible, > >> no matter what VM is or will be used in the future. > > > > This is impossible and, in the end, not a good idea. > > > > We can not be compatible forever, was this would mean > > that we can not improve anything. > > > > e.g. imagine someone would fix the VM to be better. > > (e.g. a modern object format). > > > > Do you really request to then *not* do this change because > > this VM could not run old images? (and new images would > > not run on old VMs?). > > > > Do you want to have a Future or be compatible to the Past? > > > > Marcus > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > -- Mariano http://marianopeck.wordpress.com

1 0

Re: [Pharo-project] [Pharo-users] [ANN] PharoDev-1.3-13173
by Mariano Martinez Peck April 27, 2011

April 27, 2011

On Wed, Apr 27, 2011 at 10:59 AM, Ted F.A. van Gaalen <tedvga(a)gmail.com>wrote: > Good morning Mariano > > This is something I wrote to Adrian Lienhard, > when an image did not run, straight out of the box > so to speak, because of VM differences > Some thoughts about reliability, and, very important > IMHO, upward compatibility. > > Good morning > Thanks & Regards > Ted > > >>> > ? > I did expect that, nota bene working with > the Seaside supplied one-click image and > the virtual machine supplied with it, > provided on the Seaside.st site itself, > that everything is (and remains) > 100% upward compatible, > no matter what VM is or will be used in the future. > > Unfortunatly that's now of the the goals of Pharo. You have two real/practical ways: 1) don't make progress, stay in the museum (like stef says), and live happy with that. 2) Improve, make progress, and unfortunatly, make some incompatibility to the past. Pharo choose 2). Please, for further discussion, use another thread with a clear subject, not this one. > So, that application builders are assured that > the things they create will run unchanged > for even years to come. In an industrial > environment, this is vital. > Not necessary. Several mainstream languages changes a lot among different versions and people just update their code. > > For example: on IBM mainframes. many > Cobol or PL/1 programs/modules made more than > 30 years ago run unchanged and without recompilation/linking. > This is actually an industrial requirement, without it e.g. > the complete IT environment of banks etc. would collapse. > Even your bank account very probably relies on modules > programmed way back in the seventies.. > ( i won't mention the chaos with years of legacy code here, > but this could also occur years later with Smalltalk apps) > > but back to image compatibility > As a workaround, wouldn't it be a good idea: > - if some shell script on the Seaside hosting site somehow scans/checks > the image and start it with an appropriate VM either COG or another? > or: > provide a standard unchanged clean Seaside image in the file directory > as default, so the only thing one has to do is to load Monticello > package(s) into it? > yes, maybe. Ask seaside people :) Pharo images can be used iwth both VMs > > This is written from the somewhat traditional, industrial > and pragmatic perspective of a typical application developer, > who is not really involved in the more underlying system "details" :o) > > It would be almost a night mare in a large production environment > if e.g. classes are removed where applications rely on. > It would mean and unnecessary rewriting of a lot of code. > > That's the problem. It is not "unnecessary". In fact, it IS necessary if you want to make progress, clean, improve, etc. > Please observe: No pun or harsh negative criticism intended here, > I do really appreciate what is currently > going on with Smalltalk! > > No problem, any feedback is welcome :) we can always discuss. > I''ll copy this to Pharo-users, > currently seen that Mariano is touching a bit similar things. > > > On Wed, Apr 27, 2011 at 10:36 AM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Thanks, Mariano! > > > > We will move the latest Moose development build to this Pharo version > next week. > > > > Cheers, > > Doru > > > > > > On 27 Apr 2011, at 10:21, Mariano Martinez Peck wrote: > > > >> Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that > doesn't happens automagically. We all need to start using and testing the > image before they are release. It is for the better of all of us. The more > we test the more stable will be the release. So...we need your help. What > you can do? > >> > >> 1) test test test test test. Use it. Take this image and use it for your > regular work. > >> 2) report bugs: http://www.pharo-project.org/community/issue-tracking > >> 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > >> 4) Fix errors/failures tests > >> 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is > released and then ask "uuhh what happened to XXX? you removed? ohhh but I > use it". > >> 6) Do you maintain Metacello configurations? ok, if you test your > project and works correctly in Pharo 1.3, please update (or create if you > don't yet have it) the #stable, > >> 7) Do you maintain packages included in Pharo? please check we are > using the correct versions > >> 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, > DBXTalk, Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > >> > >> Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I > recommend to download the last one from Eliot's page: > http://www.mirandabanda.org/files/Cog/VM/ > >> > >> Two little warnings: > >> - The Transcript is read only....and it will probably be roll backed to > the previous one > >> - if text editing looks weird....it is Lukas's fault ;) > http://www.youtube.com/watch?v=fTMX1f8Lu5w > >> > >> Ok, the image is here: > https://gforge.inria.fr/frs/download.php/28517/Pharo-1.3-13173.zip > >> > >> And it was build by Hudson: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ > >> > >> Best regards, > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > -- > > www.tudorgirba.com > > > > "Sometimes the best solution is not the best solution." > > > > > > > > -- Mariano http://marianopeck.wordpress.com

1 0

Re: [Pharo-project] [Pharo-users] [ANN] PharoDev-1.3-13173
by Marcus Denker April 27, 2011

April 27, 2011

On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote: > Good morning Mariano > > This is something I wrote to Adrian Lienhard, > when an image did not run, straight out of the box > so to speak, because of VM differences > Some thoughts about reliability, and, very important > IMHO, upward compatibility. > > Thanks & Regards > Ted > >>>> > ? > I did expect that, nota bene working with > the Seaside supplied one-click image and > the virtual machine supplied with it, > provided on the Seaside.st site itself, > that everything is (and remains) > 100% upward compatible, > no matter what VM is or will be used in the future. This is impossible and, in the end, not a good idea. We can not be compatible forever, was this would mean that we can not improve anything. e.g. imagine someone would fix the VM to be better. (e.g. a modern object format). Do you really request to then *not* do this change because this VM could not run old images? (and new images would not run on old VMs?). Do you want to have a Future or be compatible to the Past? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

April 27, 2011

Hi guys in RPackage there is a method named withOrganizer:do: defined as follows and I would like to test it to understand really if it does what it says. withOrganizer: aNewOrganizer do: aBlock "Perform an action locally to aNewOrganizer. Does not impact any other organizers." | old shouldRegisterAtTheEnd| [ old := self organizer. shouldRegisterAtTheEnd := false. old hasRegistered ifTrue: [ old unregister. shouldRegisterAtTheEnd := true. ]. self organizer: aNewOrganizer. aBlock cull: aNewOrganizer.] ensure: [ self organizer: old. shouldRegisterAtTheEnd ifTrue: [ self organizer register. ]. aNewOrganizer unregister. ] So I wrote two tests testWithDoIsCorrectlyReinstallingDefault "self debug: #testWithDoIsCorrectlyReinstallingDefault" | current empty | current := RPackageOrganizer default. empty := RPackageOrganizer basicNew initialize. RPackage withOrganizer: empty do: [ self assert: (SystemAnnouncer announcer hasSubscriber: empty). self deny: (SystemAnnouncer announcer hasSubscriber: current)]. self assert: (SystemAnnouncer announcer hasSubscriber: current). self deny: (SystemAnnouncer announcer hasSubscriber: empty) and testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt "self debug: #testWithDoIsCorrectlyReinstallingDefaultEvenIfHalt" | current empty | current := RPackageOrganizer default. empty := RPackageOrganizer basicNew initialize. RPackage withOrganizer: empty do: [ self error. self assert: (SystemAnnouncer announcer hasSubscriber: empty). self deny: (SystemAnnouncer announcer hasSubscriber: current)]. self assert: (SystemAnnouncer announcer hasSubscriber: current). self deny: (SystemAnnouncer announcer hasSubscriber: empty) Now I would like to make sure that I raise an error or whaever to make sure that the ensure: block argument is executed. Does anybody have an idea how I can do that. because self error does not work. Stef

3 18