- Pharo-dev - lists.pharo.org

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

by Camillo Bruni

On 2013-06-27, at 10:37, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 27 June 2013 08:32, 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 >> >> 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 > > *cough* *cough* You mean SHA-1, I hope. ups, right :D > But also you have a good point > re comparing hashes, but let's also not forget that whitespace changes > will affect the hash. You're right: storing the metadata of the thing > separate from the thing itself allows you to add to the _description_ > of a thing without touching the thing itself. > > frank

June 27, 2013

Re: [Pharo-dev] Boolean

by Norbert Hartl

Am 27.06.2013 um 09:49 schrieb "Torsten Bergmann" <astares(a)gmx.de>: > 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", ... +1 Norbert > > https://pharo.fogbugz.com/default.asp?11036 > > Bye > T. >

June 27, 2013

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

by Frank Shearar

On 27 June 2013 08:32, 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 > > 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 *cough* *cough* You mean SHA-1, I hope. But also you have a good point re comparing hashes, but let's also not forget that whitespace changes will affect the hash. You're right: storing the metadata of the thing separate from the thing itself allows you to add to the _description_ of a thing without touching the thing itself. frank > 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 Goubier Thierry

Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>> >> >> I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need. > > yeah but you have the "wrong" hash as the source includes the category :) > I prefer storing the methods in subfolders which represent categories, so I keep > the methods sources as clean as possible. For instance this way a recategorization > is detected as a move by standard git tools. Now that I say, we should do the same > for the classes :P. In this case, how would you query git for all the versions of a method? If it is recategorized, you would not be able to see through the move, no? > Anyway, right now this is mostly a detail, more importantly we need make sure the > image-side workflow is good :), so I am really happy that you push it I think it is good that we try to see all the use cases and possible changes at the format as we use it and improve the workflow around it. There is a lot of experience to be gained there. Thierry >>> - each file-in requires another strip-the-category-path >> >> ? > > => typo, should be, strip-the-category pass :) > > -- 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] [Pharo-project] Understanding NBOpenGL

by kilon

I also tried gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) . still getting "Error during FFI call : NIL" . This is the full method : createShader: shaderType string: shaderString " create shader using its source and compile it , return shader" | shader | shader := gl createShader: shaderType . gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) . gl compileShader: shader. ^ shader . I also use gl getError to get any possible opengl error in my part , It reports that there is no such error.I am continuing investigating Nativeboost -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695575.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2013

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

by Camillo Bruni

On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>>> >>> >>> I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need. >> >> yeah but you have the "wrong" hash as the source includes the category :) >> I prefer storing the methods in subfolders which represent categories, so I keep >> the methods sources as clean as possible. For instance this way a recategorization >> is detected as a move by standard git tools. Now that I say, we should do the same >> for the classes :P. > > In this case, how would you query git for all the versions of a method? If it is recategorized, you would not be able to see through the move, no? if you store the category in the method you won't see a move of course, otherwise yes: https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe…

June 27, 2013

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

by Usman Bhatti

Its quite sometime that I sat with Ben to change the World in Pharo to make it customizable to my needs (about a year ago) but after some tries and lots of freezing, we had abandoned. Now that its been resurrected, I would like to use it. On Thu, Jun 27, 2013 at 9:46 AM, plantec <alain.plantec(a)yahoo.com> wrote: > 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] Versions Browser over gitfiletree://

by Camillo Bruni

>>> >> 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 > > But, knowing the filetree format, you could rebuilt the correct md5, no? > > Oups, finally, I'm not impressed by your idea of trying to second guess git hashing :( > > I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need. yeah but you have the "wrong" hash as the source includes the category :) I prefer storing the methods in subfolders which represent categories, so I keep the methods sources as clean as possible. For instance this way a recategorization is detected as a move by standard git tools. Now that I say, we should do the same for the classes :P. Anyway, right now this is mostly a detail, more importantly we need make sure the image-side workflow is good :), so I am really happy that you push it >> - each file-in requires another strip-the-category-path > > ? => typo, should be, strip-the-category pass :)

June 27, 2013

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

by Goubier Thierry

Le 27/06/2013 09:32, Camillo Bruni a Ã©crit : >>> 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 But, knowing the filetree format, you could rebuilt the correct md5, no? Oups, finally, I'm not impressed by your idea of trying to second guess git hashing :( I like the fact that I can do git log --pretty="%H" path_to_method_file, and I have all the hashes I need. > - 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. The version file for me is a bit strange, yes, and it tend to creates conflict when merging with git. I don't see the problem for the rest of the metadata changes, but I don't use gitk to look at the changes; I build a Pharo GUI to filter that noise out. > Anyway, most of it is future talk, I guess the current approach will work :) It works surprisingly well. I even prefer it to smalltalkhub at the moment: simpler authentification, more powerfull, probably smaller on disk, better offline behavior. > 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. We will certainly. But I don't see that as a problem now that I've put my hands into the Monticello filetree reader/writer. 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 StÃ©phane Ducasse

Cool alain I really want to see this happening. I want to pair program with ben friday. Stef On Jun 27, 2013, at 9:46 AM, plantec <alain.plantec(a)yahoo.com> wrote: > 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