July 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

Hi matthew There are only one class comment on the complete package. This is really sad. Could you do a pass and fix that. I would love to see a class diagram of the system editor and been able to store in the in package metadata (should work on that). 167 run, 159 passes, 0 expected failures, 2 failures, 6 errors, 0 unexpected passes commit "The mass become: is a primitive, but we execute this method with preemption disabled because we don't want another process creating new instances while we're busy converting the existing instances." | old new | [ old := WriteStream on: (Array new: migrators size). new := WriteStream on: (Array new: migrators size). migrators do: [:ea | ea migrateFrom: old to: new]. old contents elementsExchangeIdentityWith: new contents. ] valueUnpreemptively. On Jul 3, 2008, at 8:03 PM, StÃ©phane Ducasse wrote: > Matthew can you explain how you achieve atomic loading? > > I thought that what I would do is: > - create an new SystemDictionary > - compile the code to this new namespace (not sure that this is easy) > - then if nothing wrong happen, add the new name to Smalltalk. > > Stef > On Jun 27, 2008, at 11:41 AM, Matthew Fulmer wrote: > >> I am fixing bugs in a new loader for Monticello that does code >> loading in a truly atomic fashion: code is swapped into the >> system, and pointers are revised in exactly ONE primitive. I >> have it working well enough that I made it my default loader. >> It is able to load problematic packages that are sensitive to >> inconsistencies during loading, like Monticello and Morphic. >> As an Acid test, I am able to load Monticello using the new >> package loader, which has, until now, been impossible in any >> version of Monticello. The biggest remaining issue is Traits >> support; Packages with traits are not supported. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

hi Matthew I loaded HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' And I will load MC1.6. Now could you do me a favor. I ***hate*** badly formatted code writeTo: fileName in: directory fileout := fileName. dir := FileDirectory on: (FileDirectory default fullNameFor: directory). dir assureExistence. stdout ^stdout printWith: aBlock fileout ifNil: [ ^aBlock value: stdout ]. FileStream detectFile: [ dir forceNewFileNamed: fileout ] do: aBlock it should be writeTo: fileName in: directory fileout := fileName. dir := FileDirectory on: (FileDirectory default fullNameFor: directory). dir assureExistence. stdout ^stdout printWith: aBlock fileout ifNil: [ ^aBlock value: stdout ]. FileStream detectFile: [ dir forceNewFileNamed: fileout ] do: aBlock I went over all the methods of the installer and cleaned them. Could you pay attention to that? I think that uniformity is important. Of course method comments would help too. Stef On Jun 27, 2008, at 11:41 AM, Matthew Fulmer wrote: > On Fri, Jun 27, 2008 at 09:32:35AM +0200, Hilaire Fernandes wrote: >> Oh, Chris I am just a dumb developer and I don't know much about the >> tools, I just know it is a pain to get MC 1.5 working. > > Indeed. Monticello is hard to load, precisely because the loader > is being modified while loading. Thus, we have a script that is > able to reliably load Monticello 1.5 onto any image: > > http://installer.pbwiki.org/LevelPlayingField > > To run it, do this: (I just tested it and got it working in > Pharo) > > HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > > The actual job of loading Monticello is done here: > > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > Notice the technique: first a plain file-out of PackageInfo and > Monticello is loaded, next, nearly the exact same packages is > loaded via Monticello. This ensures that the changes made to > Monticello while Monticello is running are minimal. I keep that > script up-to-date as I make changes to Monticello 1.5. > > Monticello and PackageInfo have a number of improvements: > > - Packages can be loaded out-of-order, as orphaned methods and > classes are stored in an Orphanage, which is revisited when > loading later packages > - Tests can be separately packages from the main code, without > extensive repackaging: Name a package Monticello.impl to get > classes in Monticello-*, except for those that end in *-Tests, > or name a package Monticello.tests to get all packages in > categories Monticello-*-Tests > - A new dual version sorter, able to view changes between > arbitrary versions in a repository; in the right pane of the > MC browser, use the menu item "open dual changes browser" > - Working MonticelloConfigurations > - I am fixing bugs in a new loader for Monticello that does code > loading in a truly atomic fashion: code is swapped into the > system, and pointers are revised in exactly ONE primitive. I > have it working well enough that I made it my default loader. > It is able to load problematic packages that are sensitive to > inconsistencies during loading, like Monticello and Morphic. > As an Acid test, I am able to load Monticello using the new > package loader, which has, until now, been impossible in any > version of Monticello. The biggest remaining issue is Traits > support; Packages with traits are not supported. To try it > out, run this after running the LPF script above: > > Installer install: 'Monticello16-Beta' > > In the past, people have had various problems with Monticello > 1.5, such as loading FFI and strange issues with Instance > variables. Keith and I were somewhat unaware of these until they > were brought to our attention on IRC, and have since been fixed. > This product is under active development, and our goal is to get > the same very useful version of Monticello running on every > active Squeak platform, and we have done so, to the best of our > knowledge. So if you find a problem, please let us know and we > will fix it, most likely within the hour. IRC is the best way; > mailing lists are next. > > > > I realize LevelPlayingField is not the preferred mechanism to > load stuff into Pharo, and it brings along two other things > beside Monticello 1.5 (namely, Installer and Launcher). I will > try to prepare something suitable for loading Monticello 1.5 > into Pharo, but it cannot be a plain SLICE package, due to the > Monticello loading problems I explained above. I'll read up at > http://code.google.com/p/pharo/wiki/HowToContribute > > I'll also see what changes Stef and Lukas made to Monticello as > part of Pharo and attempt to merge them. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

Matthew can you explain how you achieve atomic loading? I thought that what I would do is: - create an new SystemDictionary - compile the code to this new namespace (not sure that this is easy) - then if nothing wrong happen, add the new name to Smalltalk. Stef On Jun 27, 2008, at 11:41 AM, Matthew Fulmer wrote: > I am fixing bugs in a new loader for Monticello that does code > loading in a truly atomic fashion: code is swapped into the > system, and pointers are revised in exactly ONE primitive. I > have it working well enough that I made it my default loader. > It is able to load problematic packages that are sensitive to > inconsistencies during loading, like Monticello and Morphic. > As an Acid test, I am able to load Monticello using the new > package loader, which has, until now, been impossible in any > version of Monticello. The biggest remaining issue is Traits > support; Packages with traits are not supported. Stef

July 3, 2008

[Pharo-project] About a file abstraction layer

by StÃ©phane Ducasse

Hi guys With mike we also discussed about URI and the way sophie people used to abstract away from the file system. The idea (may be I'm summarizing a bit wrong), is to use URI consistently even to access local file. He told me that with this practice they got away from platform dependent code in Sophie. Mike also rewrote and clean a large part of the network-package. We got some trouble to load it in pharo since this was not made to be loaded in pharo. Mike will work on a loadable version. Stef

July 3, 2008

[Pharo-project] About Morph cleaning and new infrastructure

by StÃ©phane Ducasse

Hi guys Here is the summary of the discussion we got with mike today. In the context of the ESUG sponsored effort mike and john will work on making the - VM sleeping correctly, - using a semaphore do avoid event polling and all the rest related to that. - fixing the event handling. Now the point is that mike will not change Morph, just clean what is needed so that the event system and the polling gets cleaned. The idea is that Morph cannot be cleaned. In parallel mike has been working on ySqueak and in this context he worked on a new morphic model. Now we should learn from squeak and make sure that we have an infrastructure that allows one to plug difference UI frameworks (no "Smalltalk isMorphic" in the future). In addition we want to make sure: - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak or something else) - kernel class do not depend on UI. So mike based on his sophie experience designed a new event model based on Announcement which support well multiple input devices, different platform key, different windowing bindings for future native support. So the idea is the following: - let make Morphic smaller and cleaner but acknowledge that Morphic is not the long term future. - mike will produce a new event model, that the other UI frameworks could use and extend. He will ask fro feedback. - Agree that we use announcement as an infrastructural foundation. - make sure (with your help and feedback) that we can plug another UI framework (in particular in the event loop handler should support a registration mechanism. - It would be nice to see how miro can use the new event model and be plug in pharo as well as the ySqueak new model. I would like to lower the frustration of people. The point is not to chose a framework against another one but to make sure that we can load and plug different frameworks. So please comment. Stef

July 3, 2008

Re: [Pharo-project] Discussions with mike (one)

by StÃ©phane Ducasse

Excellent! We should really get the NewCompiler because it will remove a lot of cruft too (SyntaxError as subclass of String and the like). I have the impression that we should prepare to load the newcompiler as soon as pharo one is ready and get the release time to really only us the NewCompiler. Stef >> hi guys (and marcus in particular) >> >> I'm at RMLL and we are discussing with mike about infrastructure >> for pharo. >> I will summarize some of the discussions in the following posts. >> >> Mike suggested that we really use the NewCompiler for Pharo. >> Marcus can you comment on that. > > What is missing is > -> bootstrapping. But this is easy to fix. > > Else there are some bugs that need to be fixed (e.g. when evaluating > in the debugger, > temps are sometimes not bound correctly). > And the error-messages of the SmaCC parser need to be carefully > evaluated of they work > on practice. (Mathieu improved them last year). > > Else we used it a lot and it seems to work. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

Re: [Pharo-project] UI plans Question

by StÃ©phane Ducasse

> Or refactor morphic and hook up to the platform host window support > in the > vm. Mike wanted to look and fix ffenestra but I imagine that he will not have the time. See another part of the answer in the next email. stef

July 3, 2008

Re: [Pharo-project] issue 26 / squeak 7073

by StÃ©phane Ducasse

Big brother :) Stef > I've uploaded a new slice which incorporates the > squeak update changes for version 7073. > > SLICE-squeakUpdate7073-noha.5 > > I can't change the status of the ticket as google is > not allowing me to do any single action today :) > First I got captchas for submitting issues and now > I'm locked out. > > "You have performed the requested action too many times in a 24-hour > time period. Or, you have performed the requested action too many > times > since the creation of your account." > > The last sentence makes me a bot afraid :) > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

Re: [Pharo-project] 3.9.1, version numbers and fixes

by StÃ©phane Ducasse

On Jul 2, 2008, at 7:50 PM, Adrian Lienhard wrote: > > On Jul 2, 2008, at 17:59 , Norbert Hartl wrote: > >> I'm a little bit confused. I started to have a look >> at the squeak fixes of 3dot10 we like to integrate. >> Looking at the version number I marked all version >> number up to 7075 as being duplicate (in the issue >> trackr) as we started from 3.9.1 which is 7075. But >> now I think I misunderstand something. > > the numbers nnnn do not seem to be unique among 3.9 and 3.10. The > reason likely is because 3.9.1 was done after 3.10 started, it > continued numbering from 3.9 creating duplicates. You can see this > in the update stream: http://ftp.squeak.org/updates/updates.list > Therefore, the number alone does not uniquely identify the change. Yes they did not let enough number for maintenance of 3.9 :( >> I tried to merge squeak version 7076 into pharo. >> I did some stuff manually to be able to merge the >> monticello packages of that release. But the changes >> are massive. It's collections, collectionstests and >> kernel. There are even changes for widestring which >> I don't found in previous updates. > > I think its easiest to load the changesets from Mantis into Pharo > and then save a slice with the modified packages to the inbox. > This will take quite some work, especially because we also need to > check whether the fix makes sense and which changeset is the correct > one if there are multiple ones etc. > > Can other people help with this? > I suggest to change the status to "Started" when you start working > on an issue to avoid conflicts. > > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

Re: [Pharo-project] Discussions with mike (one)

by Marcus Denker

On 03.07.2008, at 11:51, StÃ©phane Ducasse wrote: > hi guys (and marcus in particular) > > I'm at RMLL and we are discussing with mike about infrastructure for > pharo. > I will summarize some of the discussions in the following posts. > > Mike suggested that we really use the NewCompiler for Pharo. > Marcus can you comment on that. What is missing is -> bootstrapping. But this is easy to fix. Else there are some bugs that need to be fixed (e.g. when evaluating in the debugger, temps are sometimes not bound correctly). And the error-messages of the SmaCC parser need to be carefully evaluated of they work on practice. (Mathieu improved them last year). Else we used it a lot and it seems to work. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

July 3, 2008