May 2015 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Default package comment

by Eliot Miranda

Hi Sergio, On Fri, May 15, 2015 at 6:28 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > Ok, I came up with this default comment. > > Let's see what you guys think of it: > > > *This is a default comment for a package.* > > *To create a new one follow these guidelines:* > > * - Make the first line a one line description of the package and its > purpose.* > * - Describe with a more detailed description the problem solved and how > the package works* > * - Describe how to use the package with code snippets and what classes > are the ones you'll use normally* > * - Mention any side effect that may come from installing or uninstalling > the package* > * - Write information from the package like author, contact, repository, > date of creation, etc.* > I would add: - describe how to load the package, including any additional dependencies, version requirements, etc. PD: I know the above should be modelled in the Manifest of the Package, but > it's better to have it in the comment while we don't have implemented them. > -- best, Eliot

May 15, 2015

Re: [Pharo-dev] New CogVMs available

by Eliot Miranda

Bonjour Seb, et bienvenue! Je suit Anglais et ma Francais et absolument degoutant, donc je lesse pour autres d'aide vous. Mais c'est bon d'avoire un autre person entre notre communite. Bon chance! 2015-05-15 0:59 GMT-07:00 seb NZOGANG <sebnzogang(a)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 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. > > 2015-05-15 6:17 UTC+02:00, Eliot Miranda <eliot.miranda(a)gmail.com>: > > at http://www.mirandabanda.org/files/Cog/VM/VM.r3343. > > > > CogVM source as per VMMaker.oscog-eem.1303/r3343 > > > > Cogit: > > Fix the regression with #== in the StackToRegisterMappingCogit; > > a spilled constant must still be dropped from the stack. (fixes the > > width:color: MNU) > > > > Since the method zone does not scavenge PICs, the MNU method in an MNU > PIC > > entry > > cannot be young. If it is, void the cache (load 0 instead of the > method). > > -- > > best, > > Eliot > > > > -- best, Eliot

May 15, 2015