June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] looking at the code of PasteUpMorph

by plantec

Hi all, After a lot of freezes :) To create a new world and make it be the current world, thanks to PasteUpMorph>>install methods and to the MultiWorld code of sean (found in the bugtracker), I've implemented PasteUpMorph>> beCurrentWorld. Now I guess we are able to design a new clean world class and switch to it more smoothly :) PasteUpMorph subclass: #WorldMorph instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Worlds'. (Smalltalk at: #WorldMorph) new beCurrentWorld. But, I don't understand everything. maybe something is missing or bad. maybe part of this code is not useful. It would be cool is someone could comment this code that we understand and make it cleaner. Thanks Alain ---------- PasteUpMorph>> beCurrentWorld | morphs | owner := nil. morphs := World submorphs. Sensor flushNonKbdEvents; flushKeyboard; flushEvents; shutDown. self class shutDown. worldState := WorldState new. self addHand: HandMorph new. self borderWidth: 0. self viewBox: Display boundingBox. self borderWidth: 0. "default" self color: self class defaultWorldColor. self addAllMorphs: morphs. SystemWindow noteTopWindowIn: self. World := self. ActiveWorld := self. ActiveHand := self hands first. "default" ActiveEvent := nil. worldState handsDo: [:h | h releaseCachedState]. Sensor startUp. self class startUp. self displayWorldSafely. --------- Le 26 juin 2013 Ã 15:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > Hi > > I think that it would be good to have > > PasteUpMorph (a morph in which we can drop morph) > subclass World (the world = a morph in which we can drop morph and that have a worldstate) > > This would remove a lot of ifNil: everywhere. > > Stef > >

June 27, 2013

Re: [Pharo-dev] Challenges for a real debugger for Pharo :)

by StÃ©phane Ducasse

On Jun 26, 2013, at 5:11 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 25 Jun 2013, StÃ©phane Ducasse wrote: > >> Hi guys >> >> when working on a new morphic kernel, we got stuck with a really difficult to find >> bug (we are still looking for it). >> If new generation debugger lovers want to try. Here it is >> >> - load the bloc version 6 from AlainPlantec/Bloc on smalltalkHub >> >> - execute the snippet (alain will post the snippet because it is on his machine) >> >> BlProtoMorph new openInWorld >> >> (there is another one) >> >> - move the mouse and the system gets blocked. > We did a fork and killed the morph. But the debugger and system should help doing that naturally > Just type > > kill -USR1 <pid> > > and you'll be able to see where it got blocked. > > Alternatively you can run a high priority process in the image which takes snapshots of other processes (I'd choose the UI process and the finalization process, since the former gets blocked, and the latter uses a pretty much broken data structure in Pharo) every once in a while, and writes them do disk/whatever. > > > Levente > >> >> After looking for it for a couple of hours here are some wishes list. >> >> >> - would be good to be able to set a haltOnce to **all** the methods of a **particular** object :) >> >> - would be good to have the equivalent of GlobalVaHoldingOneObject haltOnce ifTrue: [â¦.] >> >> - would be nice that we can say that the object once debugged does not receive any other messages >> (imagine an object in a fast rendering loops and that one message causes problems). >> >> >> >> Stef

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

On Jun 27, 2013, at 9:32 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> without Monticello file back-end no? >> >> No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. >> >> I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. >> >> Still wondering if this is the way to go. > > I think it is a very good start :), > eventually we have to come up with second version of the filetree format as > the current one has a major limitiation: categories are stored in the method source yes :) before it stays there with JSON for the next 30 years. > Impact: > - md5 hashes of the pure ST method sources do not correspond the md5 hashes in the > git repository > - each file-in requires another strip-the-category-path what is that? > > of course there are workarounds for that. Additionally I would love to have a > filetree version that doesn't store all this MC metadata. The changes in these > files generate so much noise that is it hard to see the actual changes. > > Anyway, most of it is future talk, I guess the current approach will work :) > > Though I wonder what we will do once we have custom slots :/. I guess we need > some hacks to make that run on top of Monticello.

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

> It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( > > With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) But I save regularly on MC server or locally (after each new read and green tests is a good moment) Because having git as a backend will not give you micro commit. Then we are working on a really nice code modification logging named EPICEA to replace the old cs. Because if you crash your image between two git commit. Stef > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Camillo Bruni

>> without Monticello file back-end no? > > No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. > > I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. > > Still wondering if this is the way to go. I think it is a very good start :), eventually we have to come up with second version of the filetree format as the current one has a major limitiation: categories are stored in the method source Impact: - md5 hashes of the pure ST method sources do not correspond the md5 hashes in the git repository - each file-in requires another strip-the-category-path of course there are workarounds for that. Additionally I would love to have a filetree version that doesn't store all this MC metadata. The changes in these files generate so much noise that is it hard to see the actual changes. Anyway, most of it is future talk, I guess the current approach will work :) Though I wonder what we will do once we have custom slots :/. I guess we need some hacks to make that run on top of Monticello.

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Esteban Lorenzano

On Jun 27, 2013, at 9:24 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 27/06/2013 09:10, StÃ©phane Ducasse a Ã©crit : >>> >>> No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. >>> >>> I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. >>> >>> Still wondering if this is the way to go. >> >> I do not know. > > It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( > > With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) while I think we need to replace monticello eventually (it as became aged and accumulated patches over patches), I have to say that the workflow you are describing is perfectly doable with the state of the art versioning system, no need of git or whatever :) Esteban > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 09:10, StÃ©phane Ducasse a Ã©crit : >> >> No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. >> >> I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. >> >> Still wondering if this is the way to go. > > I do not know. It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Hi Dale, should I merge this work into the last pull request (#85) I made? I've corrected a few bugs and solved some performance issues, in addition to adding the API for querying and loading parts of a package. It's currently on a separate branch. Thierry Le 27/06/2013 01:26, Dale K. Henrichs a Ã©crit : > Cool! I plan to integrate your work soon and I expect to merge your work on the Pharo3.0 branch as well... > > Dale > > ----- Original Message ----- > | From: "GOUBIER Thierry" <thierry.goubier(a)cea.fr> > | To: "Pharo Development List â[pharo-dev@lists.pharo.org]â" <pharo-dev(a)lists.pharo.org> > | Sent: Wednesday, June 26, 2013 2:28:55 PM > | Subject: [Pharo-dev] Versions Browser over gitfiletree:// > | > | Or ... A first step towards Pharo without a changeset. > | > | Thierry > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by StÃ©phane Ducasse

> > No, in fact it's very much dependent on Monticello filetree back end. This backend has the granularity which allow a use of git querying / fetching facilities to the level associated with changesets. > > I could implement a use of a gitfiletree:// repo as a complete replacement of a live changeset + monticello repository in one, if needed. > > Still wondering if this is the way to go. I do not know. Stef

June 27, 2013

Re: [Pharo-dev] Slide share

by StÃ©phane Ducasse

Ok so they try to influence the user by giving wrong information. I will continue to upload the slides then. Stef On Jun 27, 2013, at 8:58 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jun 26, 2013, at 9:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> http://www.slideshare.net/pharoproject/ >> > > >> Do you know if there are limits on the number of presentations that we can upload, because >> I see (get public on this presentation => go pro). >> So I wonder if I want to invest in slideshare. > > I think it is not limited for number of uploads. Just size of the file that is limited (to 100MB). > > More here: > http://www.slideshare.net/business/premium/plans > > Marcus > > >

June 27, 2013