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

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

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