- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Learning Spec

by Sebastian Heidbrink

Hi Sven, I am still a little confused about the terminologies so please give one last kick into the right direction. I have loaded the Calculator and try to map thingssaid to the implementation. Am 13.02.2015 um 11:04 schrieb Sven Van Caekenberghe: > > > 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! > The class is called SpecInterpreter. But this is an implementation detail, not related to application logic. Well, no he did not mean the SpecInterpreter he ment the receiver/interpreter of an action like a mouse click here. And exactly this link is missing through out the examples.... and makes SPEC so hrad to understand. > >> And last but not least, the all examples have no interpreter/control or real model layer.... > But you are looking too far: your domain model is just an object, its behaviour is the control layer, it uses announcements to signal changes. Looking at the HP35CalculatorModel implementation I think that is what you mean. But I honestly would have expected a class naming like HP35CalculatorApplicationFunction, HP35CalculatorController, or HP35CalculatorComponent or just HP35Calculator instead of HP35CalculatorModel... For me a model is a stupid structure. Somehting that knows what it contains and how to describe itself,... but has no real functionality or mechnisms in it. Extreem example is a DataModel,.... Now since Spec is more a MVVM framework, I assumed that I have to make the distinction between Control/Businesslogic and Model on my own. I prefer this distinction because once a project grows it is much eaiser to navigate, maintian and even port to different architectures like webclient, server app, desktop app.... > > ing like the HPCalculator! > I understand the need. I did my part with the HP35, with a clear model and 2 UI's sharing 1 specification as well as unit tests on 2 levels. > > But like I said, there are lots of real world examples inside and outside the image. How can one find them? I was not aware of the fact that the spec example HP53 was on smaltlakhub. Somehow it is very difficult to find projects on Smalltakhub.... all the projects have tags, but somehow I can't find a search or tool that allows me to search smalltalkhub for certain tags. > You could just start a new repo on smalltalkhub.com or even github.com Well, I would love, too once I know that I have somehow understood the basics ;-) I simply do not want to run into the wrong direction and realize that all my efforts where for nothing. And I, and that is even more importatn, do not want to tell newcomers how to do it and send them into the wrong direction... Give me some time and I'll try to come up with a little application that we could use to discuss on. sebastian

Feb. 13, 2015

Re: [Pharo-users] Learning Spec

by Sven Van Caekenberghe

> On 13 Feb 2015, at 18:49, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > Hallo Sven, > > thank you for the video link, google linked me to a video from 2013 that was not recorded in a way that once could follwo the presentation. > This one is super. > > Well, I think I am slowly getting there and I can more and more provide you with the uneccessary barries of Spec that I encountered. > > 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! The class is called SpecInterpreter. But this is an implementation detail, not related to application logic. > So what is misleading in the current Spec implementation and the examples is the follwong fact. > The developer is confronted with Model classes that actually are ViewModels. > Actions for buttons are implemented in Blocks which gives the developer intially the feeling that Control Layer and Model/ViewModel layer are one. > The SpecDefinitions do not work properly in my case and Stephan just found out some issues with font sizes,.... well I have Moose and Roassal in my image and my fonts are no more default .... well my fault. I just hope I will still be able to somehow find a solution for this issue. Specs certainly work. The font stuff also works, it is just not complete (enough) (yet), but it is good enough. > And last but not least, the all examples have no interpreter/control or real model layer.... But you are looking too far: your domain model is just an object, its behaviour is the control layer, it uses announcements to signal changes. > 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.... But again, there is no 'one' thing, there are many options, styles. > Sushi store?! Well, That was an example for a demo that show cases a whole technology. > And I meant exactly some thing like the HPCalculator! I understand the need. I did my part with the HP35, with a clear model and 2 UI's sharing 1 specification as well as unit tests on 2 levels. But like I said, there are lots of real world examples inside and outside the image. > Well, I need to do some tests based on what I 've learnt now,.... I have no idea about adaptors, yet, but it seems they need to be understod a little later.... > Is there a project/repository where one could push code to give other the chance to review and chance it before it is published as a "demo" or example? You could just start a new repo on smalltalkhub.com or even github.com > Sebastian > > > Am 13.02.2015 um 01:12 schrieb Sven Van Caekenberghe: >> Hi, >> >> >> From now on it is forbidden to complain about Spec in general, unspecific terms unless you have taken the time to learn about it. Here is a guide to documentation about Spec, most recent first. >> >> >> There is an excellent presentation by Johan Fabry did during the last Pharo Days, 'Using Spec to Build a UI'. *MUST WATCH* (the video is not yet fully public, but soon will be, the link should work though): >> >> http://youtu.be/OL23s9ZUIR0?list=PL4actYd6bfnz98ngrKALwwStl3C3odEKG >> >> The slides are also not yet available, but soon will be (the talk is much better that the slides on their own). >> >> >> This draft chapter 'Spec: a framework for describing user interfaces' for an upcoming book: >> >> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >> >> >> Look in the image. >> >> Browse the hierarchy below AbstractWidgetModel in the category Spec-Core-Widgets in Pharo 4, look at the protocols called 'protocol' & 'protocol-events' mainly. Look for references to each class. Trace senders of methods until you arrive at examples. Study the examples, play with them, change them. >> >> The UI of most tools in Pharo is also implemented using Spec. Browse the hierarchy below ComposableModel to find them. (Komitter, Versionner, Critics, Metacello, the old Eye Inspectors, ..). Watch and learn. >> >> >> The cool Spec website: >> >> http://spec.st >> >> >> Read some cool articles like: >> >> https://medium.com/concerning-pharo/rediscovering-the-ux-of-the-legendary-h… >> >> See the section 'HP35CalculatorModel' for the Spec part. >> >> >> The following papers (some older ones refer to API that has changed): >> >> 'Seamless Composition and Reuse of Customizable User Interfaces with Spec' >> >> http://rmod.lille.inria.fr/archives/papers/Ryse13a-SCICO-Spec.pdf >> >> 'Spec - A Framework for the Specification and Reuse of UIs and their Models' >> >> http://rmod.lille.inria.fr/archives/papers/Ryse12b-Spec-IWST12-Final.pdf >> >> 'Spec â Technical Report' >> >> http://rmod.lille.inria.fr/archives/reports/Ryse12a-SpecTechReport.pdf >> >> >> Use the image to build a couple of simple UIs using Spec. You will be surprised to learn that it is not that difficult. Just go with the flow, don't try to enforce your world view on it, wait until you are further along. >> >> >> Have fun ! >> >> >> Sven >> >> >> PS: Once you have done all the above, you are most welcome to help improve Spec by discussing specific, concrete issues. >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> > >

Feb. 13, 2015