- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] games in pharo

by stepharo

> Ceci n'est pas un endroit pour rÃ©soudre vos tpe Exactly :) But what would be cool is to extend the current tetris to improve its gameplay. - adding obstacles - two player mode - fight against time. - better diffculty raising - different and strange shapes. Stef > > Le 15 mai 2015 10:20, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> a Ã©crit : > > > > 2015-05-15 9:59 GMT+02:00 seb NZOGANG <sebnzogang(a)gmail.com > <mailto:sebnzogang@gmail.com>>: > > Bonjour je suis nouveau dans la Programmation OrientÃ©e Objet sur > pharo.j'utilise la version 4.0 de pharo et j'ai une > connaissance assez > avancÃ©e dans la programmation mais ce langage qui viens juste > de nous > Ãªtre enseignÃ© est assez nouveau pour moi.et <http://moi.et> > c'est dans l'optique de > cet enseignement qu'il nous a Ã©tÃ© demandÃ© de programmer le jeu > tÃ©tris > et je ne sai par ou commencer.merci de m'aider SVP. > > > > > Welcome, > > There is a thread about some simple games (tetris for example) > done pharo: > http://forum.world.st/Published-some-old-games-tp4804446.html > > > > cheers > nicolai > > > > > -- > Kenfack Valmy-Roi > IngÃ©nieur des travaux en Informatique de Gestion/ Analyste Programmeur > Institut SupÃ©rieur du Sahel > Email : roykenvalmy(a)gmail.com <mailto:roykenvalmy@gmail.com> > Tel: 22 11 01 87/ 76 94 23 01 / 99 04 0612

May 15, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by stepharo

Class side because we do not want to create instances of manifest. Stef Le 15/5/15 07:30, Kasper Osterbye a Ã©crit : > It is unclear if literal values in Manifest classes should be on the instance > side or on the class side. > demarey wrote in the package comments thread on May 6th: > "Data is stored in raw strings in methods (instance side) of the > Manifest." > > However, when I look in the actual manifest classes, it seems like the > manifest values (from the rule checker) are stored in the class side. > > In our work on package comments, we want to put the package comments in the > manifest classes, but we are uncertain if it should be on the instance or > class side. > > > > -- > View this message in context: http://forum.world.st/Manifest-class-values-instance-or-class-side-tp482644… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 15, 2015

Re: [Pharo-dev] Pharo Screencast By a Ruby Guy

by stepharo

> There have been several comments to the effect, "Everything there was > pretty cool, but when you searched the documentation âby exampleâ, I > literally shouted, âNo way!â, alone here in my office. Thatâs such a > brilliant idea." > Maybe we should transfer the Finder>Examples behaviour to GTSpotter > and promote it more. (I've not got Pharo with me to check. Maybe I > remember some announcement on this, but its not very visible or > discoverable). Its filter might be #howto, similar to #i and #s. I mentioned the idea that Spotter should directly allows one to type examples and get the answer during the Pharo days. And I guess that andrei already implemented it :) > cheers -ben

May 15, 2015

Re: [Pharo-dev] Default package comment

by Sean P. DeNigris

Sergio Fedi wrote > But for now, until the author and other data is not in differente methods, > don't you think it's better to have it in the comment rather than nowhere > else? You're inventing it, why not invent it as meta-data. At the start of something, there is a unique opportunity because no one has habits around it yet. If you establish "throw it all in the comment", that's what everyone will get used to. What's the downside of putting no-op or sample methods in the superclass to show the API? Just like the catalog methods for the whole project... which brings an interesting point. Since presumably the project will store this info, does it belong at the package level? - For example, what does it mean to be the author of a package? The original author? The author of the idea? - What about the creation timestamp? We have this info in MC, so do you mean the date of the initial commit? - Contact probably belongs at the project level - Repository is somewhat dangerous because it duplicates domain info in text, which will usually be out of date. It would be better to somehow get this from MC. Do many people really pass around MC files? Presumably if you have the mcz you know where it lives. Unless we could *set* this info from MC so it would always be in sync... Anyway, I agree that anything is better than what we have now (i.e. nothing!) but also that we should take a moment to really think about a new feature because we may have to live with these decisions for a long time... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Default-package-comment-tp4826400p4826549.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 15, 2015

Reef: Initialization with default parameters

by Thomas Heniart

Hi, Currently, I am playing with Reef and it is a cool framework but I have a little problem... I want to initialize a REForm with a parameter I need in initializeContents So I have something but it doesn't seem to be the right way... WAMyObject>>renderContentOn: html html render: (myReefForm new param1: self paramNeed) But during initialization of myReefForm, initializeContents is called before param1 initialization... If someone know what I should do :) An other question : Where can I find documentations on Reef ? The only things I have found are on http://smallworks.eu/web/projects/reef Cheers, Thomas

May 15, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Having said that, maybe we should strive for consistency to facilitate the next iteration: The refactoring which will convert one-class per Package to one-object per Package. â

May 15, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

I think the ambiguity comes from the fact that a manifest, when modelled as a class, es a singleton. So it really doesn't matter where the methods are; they will work. If this where modelled properly, a single class which would hold the Package data, then we would have only one class (Package) and several instances, each with its own variables: author, comment, creationDate, etc. So for now, maybe it's irrelevant the distinction. Because where the methods are do not really reflect anything on the reality we are modelling.

May 15, 2015

Re: [Pharo-dev] Default package comment

by Sergio Fedi

> I would add: > > - describe how to load the package, including any additional dependencies, version requirements, etc. Even though to read the comment you have to already have done all of that? (i.e. to read the comment you have to have the package already loaded in the image) The dependencies, requirements, etc could be calculated from the Metacello dependencies.

May 15, 2015

Re: [Pharo-dev] Default package comment

by Sergio Fedi

> > Let's see what you guys think of it: > > Why not?! I'm sure we'll tweak it as we start using it. The only thing is > that maybe specific meta info like author, contact, website, repository, and > date of creation should go in separate methods so that they can be dealt > with programatically (e.g. send an email to the contact person). We can have > them appended to the appropriate place when the comment is shown in a tool. I know, that's what I commented in the PD. But for now, until the author and other data is not in differente methods, don't you think it's better to have it in the comment rather than nowhere else?

May 15, 2015

Re: [Pharo-dev] FreeType fonts and underline/strikethrough emphasis

by Nicolai Hess

Thanks for the feedback, Sean. Meanwhile, I think I found the reason. I think it got lost during the merge of Display- and MultiDisplayScanner. I upload a fix, ready for review. Nicolai Am 15.05.2015 5:21 nachm. schrieb "Sean P. DeNigris" <sean(a)clipperadams.com >: > Nicolai Hess wrote > > I think this worked in pharo 1 and pharo 2. Now I have to find out why it > > does not work anymore. > > Off the top of my head, I remember having a problem when the font I > requested didn't exist. I would get a fallback font without any of the > emphases I requested. HTH. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/FreeType-fonts-and-underline-strikethrough-emphasis-t… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 15, 2015