- Pharo-dev - lists.pharo.org

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

by Goubier Thierry

Le 27/06/2013 09:39, StÃ©phane Ducasse a Ã©crit : > >> 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. Yes and no. You could have micro commit, it's dead easy to implement. > 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. Micro-commit can be implemented on MC over git. It's a easy deal if you need it. I'm sure EPICEA will improve over the old cs format. Will that make it better than improving the package infrastructure? I'm not so sure. 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

Boolean

by Torsten Bergmann

ClÃ©ment Bera wrote: >MyClass>>#foo > <compilerOptions: #(- optInlineIf)> > ^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ] > >There are different options like this one. I wrote them down here to >remember (section compilerOptions): >http://clementbera.wordpress.com/2013/05/28/modular-compilation-with-opal/ >But it is not very nicely written, I've just write it to remember .. The nice thing on Smalltalk is that it is readable. I would recommond to use full names for the new compiler options: + optInlineIf => optionInlineIf + optInlineIfNil => optionInlineIfNil ... With just "opt" no one knows if it really means "option" or "optimization"/"optimized" or "object pointer", ... https://pharo.fogbugz.com/default.asp?11036 Bye T.

June 27, 2013

Fwd: You've reached 100 views on SlideShare!

by StÃ©phane Ducasse

100 looks small :) http://www.slideshare.net/pharoproject Stef Begin forwarded message: > From: SlideShare <donotreply(a)slidesharemail.com> > Subject: You've reached 100 views on SlideShare! > Date: June 26, 2013 11:32:00 PM GMT+02:00 > To: board(a)pharo-project.org > > > > > > > Congrats, you have over 100 views on SlideShare! > > People like your stuff, so we'd like to encourage you to keep on sharing. Here's your reward from us for this decent feat â one month free trial of SlideShare PRO. > > > 1 > month > free PRO coupon > Code: > 9nrnq12xjv > View PRO benefits > â¦and redeem coupon. > > > > > * Terms and conditions > > Promotional offer is applicable only on monthly Silver and Gold SlideShare PRO accounts. One promotional offer per eligible subscriber. Expires in two weeks from the date of receipt. SlideShare PRO services are sold on a subscription basis and are automatically charged to your credit card at the beginning of each subscription period. Discount applies to the first month of a SlideShare PRO account subscription. After this period, you will be charged the standard rate on your renewal date unless or until you cancel your SlideShare PRO account. > > > From SlideShare, a LinkedIn company. Click here to follow your LinkedIn contacts on SlideShare now. > > We send these emails to help you get the most out of SlideShare. > You can change your email preferences or unsubscribe from SlideShare emails anytime. > Â© 2013 SlideShare, Inc., 490 2nd St., Suite #300, San Francisco, CA 94107, USA > >

June 27, 2013

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

by Goubier Thierry

Le 27/06/2013 09:26, Esteban Lorenzano a Ã©crit : > > 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 :) Hum. Redoing / redesigning a state of the art versionning system is so large a task that I wouldn't start it unless I really have no choice :( Improving the infrastructure for supporting / interacting with versionning systems, yes! (I'm a bit fed up having to deal of a mix of RG / MC / ChangeRecords / RPackage concepts where there should be only one... Make it RG, if its complete enough). But trashing Monticello because it looks old, I don't see the point. In the meantime, git support allows me to study a few use cases we can't do any other way with the current infrastructure, so that's interesting (and make my life as a developper better :)). 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] 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