February 2015 - Pharo-users

Re: [Pharo-users] Tagging packages

by Laura Risani

Ok, forget it, i've just noticed "Groups"... On Fri, Feb 13, 2015 at 8:04 PM, Laura Risani <laura.risani(a)gmail.com> wrote: > Hi all, > > What method do you use to organize/tag your packages so you can then > easily retrieve those sharing a same tag? Is there any functionality > intended for it? > > I've been trying the following ones (ordered by increasing satisfaction): > prefixing, flagging, sharing repository, pragma. But i feel like none of > these achieves a proper balance (for package tagging) between ease of > retrieving, persistence and conceptual coherence/cleanness (at least in the > way i've been using them, perhaps i ignore something). > > Love, > Laura > > > > >

Feb. 13, 2015

Re: [Pharo-users] Writing a Login Dialog using Spec in 3 methods

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Spec is not perfect, its main 'issue' is that the UI elements are called > models I appreciate the ability to easily create standard vanilla business UIs... which we did not have in the not-too-distant-past. And I'm not too worried because everything's a work in progress. But I would say that my main issues with it are discoverability and understandability. It seems that we're getting further and further from the Morphic dream of dragging something visual that "almost does what you want" and dropping it into your cool new UI, or at least digging down through halos to see how things work. And when I step through layers of symbol interpretation I feel sad. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Writing-a-Login-Dialog-using-Spec-in-3-methods-tp4805… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 13, 2015

Tagging packages

by Laura Risani

Hi all, What method do you use to organize/tag your packages so you can then easily retrieve those sharing a same tag? Is there any functionality intended for it? I've been trying the following ones (ordered by increasing satisfaction): prefixing, flagging, sharing repository, pragma. But i feel like none of these achieves a proper balance (for package tagging) between ease of retrieving, persistence and conceptual coherence/cleanness (at least in the way i've been using them, perhaps i ignore something). Love, Laura

Feb. 13, 2015

Re: [Pharo-users] Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

by Cameron Sanders

One note about the tests of *FaDemoContactsTests*: previously i thought the tests of TestCase were run in alphabetical order. So three of tests may fail if they run before #test1AddingItemsToDB has run. On subsequent runs, the tests should all go green. -cam On Fri, Feb 13, 2015 at 5:36 PM, Cameron Sanders <camsanders(a)aol.com> wrote: > Stephan, > > First let me say, if i can figure out the proper markdown to get > color-coded inset-code looking right, i would gladly improve the DebrisDB > description with more simple examples. Additionally, i am happy to answer > questions in email. I will also consider a few video tutorials soon. > > Now, most importantly: I checked in a new version. There was a gross error > (#halt) that I accidentally checked in during recent edits ... that ... > ahem, that would have caused several tests to fail. My apologies. > > I defined a new Example-Contacts that will create a folder under the user > home -- at least it works with Pharo on a Mac -- named ContactsApp/data and > in that folder will leave a file called FaContactsDB.fdb after you have run > the tests. The example consists of these classes: > > *FaContactsDB* -- the class you use to get ahold of sessions to your > application-specific conceptual DBs. It subclasses from > FaDemoContactsAppDB, which subclasses from FaClassNamedDB. The only reason > to create FaDemoContactsAppDB (or your specific version) is so that you can > redirect all of your #session requests to an entirely different lookup > mechanism. One can also redirect on a DB specific basis. > > Saying 'FaContactsDB session' is the same as '(FaDBSessionServer instance > getSession: #FaContactsDB)' ... given that FaClassNamedDB uses the > classname. At Debris, our code is a little different, and we use the > db-session lookup key of #contactsDB for this example. This becomes the > name prefix for your fuel-file by default. So we can adjust this if desired. > > *FaDemoContactsAppDataHub* -- see the class-side method #instance. Its > #login: method assumes one repo... and configuration of multiple repos is > easy, but i created several new classes in a hurry when i carved our > Glorp-like-sessions away from our main code base. The "basic hub" this one > uses is one of those "in a hurry" classes, and i like the new perspective > it has given me. Admittedly, these are not well tested, but as you can see, > simple, and the tests seem to work. > > *FaDemoContactsContact* -- this is the only application specific class in > this demo, with a very verbose name. This is the contact class that has a > name, address and phone number. > > *FaDemoContactsTests* -- this class illustrates how to interact with > glorp sessions. > > Good luck, and please don't hesitate to inquire if you need more info or > encounter more problems. > > -Cam > > > On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> Hi Cam >> >> Interesting. The brain-dead-sample is a bit difficult to get started with. >> Would you care to talk a bit more about how to do something simple with >> it? >> An addressbook, with people having addresses and phone numbers >> might be an easy to use example. >> >> Cheers, >> Stephan >> >> >

Feb. 13, 2015

Re: [Pharo-users] Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

by Cameron Sanders

Stephan, First let me say, if i can figure out the proper markdown to get color-coded inset-code looking right, i would gladly improve the DebrisDB description with more simple examples. Additionally, i am happy to answer questions in email. I will also consider a few video tutorials soon. Now, most importantly: I checked in a new version. There was a gross error (#halt) that I accidentally checked in during recent edits ... that ... ahem, that would have caused several tests to fail. My apologies. I defined a new Example-Contacts that will create a folder under the user home -- at least it works with Pharo on a Mac -- named ContactsApp/data and in that folder will leave a file called FaContactsDB.fdb after you have run the tests. The example consists of these classes: *FaContactsDB* -- the class you use to get ahold of sessions to your application-specific conceptual DBs. It subclasses from FaDemoContactsAppDB, which subclasses from FaClassNamedDB. The only reason to create FaDemoContactsAppDB (or your specific version) is so that you can redirect all of your #session requests to an entirely different lookup mechanism. One can also redirect on a DB specific basis. Saying 'FaContactsDB session' is the same as '(FaDBSessionServer instance getSession: #FaContactsDB)' ... given that FaClassNamedDB uses the classname. At Debris, our code is a little different, and we use the db-session lookup key of #contactsDB for this example. This becomes the name prefix for your fuel-file by default. So we can adjust this if desired. *FaDemoContactsAppDataHub* -- see the class-side method #instance. Its #login: method assumes one repo... and configuration of multiple repos is easy, but i created several new classes in a hurry when i carved our Glorp-like-sessions away from our main code base. The "basic hub" this one uses is one of those "in a hurry" classes, and i like the new perspective it has given me. Admittedly, these are not well tested, but as you can see, simple, and the tests seem to work. *FaDemoContactsContact* -- this is the only application specific class in this demo, with a very verbose name. This is the contact class that has a name, address and phone number. *FaDemoContactsTests* -- this class illustrates how to interact with glorp sessions. Good luck, and please don't hesitate to inquire if you need more info or encounter more problems. -Cam On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Cam > > Interesting. The brain-dead-sample is a bit difficult to get started with. > Would you care to talk a bit more about how to do something simple with it? > An addressbook, with people having addresses and phone numbers > might be an easy to use example. > > Cheers, > Stephan > >

Feb. 13, 2015

Re: [Pharo-users] Learning Spec

by Sebastian Heidbrink

Thank for clarifiying this. The the interpreter would be the arrow from the ViewModel (ComposableModel) to the Model... So Spec is the Blue stuff and the HP35 example is including the orange part. Is there already a framework available or somebody working on it to have a more detailed Model? A infrastructure that devides BusinessLogic and Data? If so then I would try to built an example based on both. If not,,... well then I still need some time to dabble around... Sebastian Am 13.02.2015 um 13:01 schrieb Johan Fabry: > To clarify: in my talk when I mention the interpreter, this has nothing to do with Spec. This is something specific to the example (= a complete IDE for a programming language for robots â¦ with its interpreter), so I did not want to talk about because in the end it has no relevance to the story. > >> On Feb 13, 2015, at 18:49, Sebastian Heidbrink<sheidev(a)yahoo.de> wrote: >> >> In the talk at 15:35 min Johan mentions the need of a interpreter and this method is mentionded several times during the talk. >> Browse your Pharo image,.... there is none! > > ---> Save our in-boxes!http://emailcharter.org <--- > > Johan Fabry -http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

Feb. 13, 2015

Re: [Pharo-users] Learning Spec

by Johan Fabry

As I say in my talk, there are a bunch of completely working examples already in the image. Please have a look at the subclasses of ComposableModel I think that there should be enough examples there to help you understand how a full application is built. > On Feb 13, 2015, at 18:49, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > This is why I think it would be very helpful for beginners to have one example, like a sushi store, where one can actually see how an application is built through all the layers.... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 13, 2015

Re: [Pharo-users] Learning Spec

by Johan Fabry

To clarify: in my talk when I mention the interpreter, this has nothing to do with Spec. This is something specific to the example (= a complete IDE for a programming language for robots â¦ with its interpreter), so I did not want to talk about because in the end it has no relevance to the story. > On Feb 13, 2015, at 18:49, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > In the talk at 15:35 min Johan mentions the need of a interpreter and this method is mentionded several times during the talk. > Browse your Pharo image,.... there is none! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 13, 2015

Re: [Pharo-users] Spec terminology: renaming some terms.

by Johan Fabry

> On Feb 13, 2015, at 19:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 13 Feb 2015, at 18:47, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 13 Feb 2015, at 18:29, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>> >>> >>> If we think about renaming things in Spec, actually Iâd rename: >>> - ComposableModel to ComposableUI >>> - all the protocols âprotocol-*â to âAPI-*â >> >> +100 >> Iâm super tired of âprotocolâ category (it is actually a protocolâ¦ as any other category under the âprotocolâ pane :P) >> api is a lot better > > I am pro too, but it does influence the docs a bit, ... I have no problem in fixing the docs, as you might well imagine :-) We should do a pass on all the Spec documentation anyway. I hope to find time somewhere in the beginning of april ... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 13, 2015

Re: [Pharo-users] Additional easy persistence: try DebrisDB for Fuel-backed Glorp interface

by Cameron Sanders

i'll be glad too. Let me check in an update with such an example. On Fri, Feb 13, 2015 at 11:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Cam > > Interesting. The brain-dead-sample is a bit difficult to get started with. > Would you care to talk a bit more about how to do something simple with it? > An addressbook, with people having addresses and phone numbers > might be an easy to use example. > > Cheers, > Stephan > >

Feb. 13, 2015