tl;dr: I have some ideas about more advanced Pharo tutorials, and I have an
example that I would like to have reviewed/critiqued before I develop it any further. I've been thinking lately that it would be nice to expand the number of Pharo tutorials we have available. But rather than (or along with) creating more "beginner" level tutorials, I'd like to see some good "intermediate" level Pharo tutorials. I think that programmers who already know the Pharo syntax and messaging semantics could benefit from more advanced tutorials that demonstrate how to develop "real world" Pharo code for "real world" processing needs. What I'm talking about is something that assumes you know the language, the basics of the IDE (but not necessarily how to leverage its capabilities to aid development), and the basics of the foundation classes (but not its details). I'd like a tutorial for intermediate Pharo programmers who want to become experts with Pharo. Something that can show you how to apply the tools of the IDE and the features of the language and base classes to create solutions that solve complex problems. What does the community think of this idea? -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Recently, I came up with one such project that might work here, and I spent
some time prototyping it. The project is to create an application in Pharo that can solve the "Zebra Puzzle". What's the Zebra Puzzle? It's an example of a "constraint satisfaction problem", which are also known as "logic puzzles". This particular puzzle was published in Life International Magazine in 1962 and consists of a set of constraints for allocating a set of values (properties) of attributes in a mutually-exclusive way: 1. There are five houses. 2. The Englishman lives in the red house. 3. The Spaniard owns the dog. 4. Coffee is drunk in the green house. 5. The Ukrainian drinks tea. 6. The green house is immediately to the right of the ivory house. 7. The Old Gold smoker owns snails. 8. Kools are smoked in the yellow house. 9. Milk is drunk in the middle house. 10. The Norwegian lives in the first house. 11. The man who smokes Chesterfields lives in the house next to the man with the fox. 12. Kools are smoked in the house next to the house where the horse is kept. 13. The Lucky Strike smoker drinks orange juice. 14. The Japanese smokes Parliaments. 15. The Norwegian lives next to the blue house. Now, who drinks the water? Who owns the zebra? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Having solved a number of these problems in my youth, I tried to solve this
one "by hand". But with 6 attributes of 5 properties each, the "bookkeeping" task was too difficult to deal with while trying to find a consistent solution. It turns out that it's very easy to make an inconsistent conclusion, and it's also difficult to 'unwind' a mistake (if you can figure out where you made your mistake.) After I failed and restarted the puzzle several times in a row, I thought about one of my mantras: "Let humans do the things that humans are good at, and computers do the things that computers are good at." After all, computers are designed to good at processing large amounts of data without confusion or mistakes (assuming the software developers are competent -- and use good tools). So why not a computer program that can solve this puzzle? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
So I decided to write an application to solve the Zebra Puzzle, by solving
this type of problem in general. In Pharo, of course. I worked out a few basic algorithms for making deductions and inferences, and coded them, along with tests, in Pharo 8. Now I've reached the point of having a working "proof of concept" or prototype. It can't (yet) solve the Zebra Puzzle without some "human assistance", but it does keep track of the solution state as it progresses, it handles the bookkeeping, makes the basic deductions/inferences, and produces reports. And I've used it to quickly solve the Zebra Puzzle. I coded the solution as a separate class/method, with extra rules inserted that I was able to infer by iterating to partial solutions, so that it solves the entire thing. It will interesting to develop the remaining algorithms, and it would be nice to eventually create a nice, interactive user interface for it as well. Since I want to fashion this into an intermediate-level tutorial, I need feedback on what I have so far. I don't want my inexperience to lead to me teaching the wrong techniques, etc. to other developers who are learning Pharo. What I have can no doubt be improved, but I need to hear from the master craftsman in this community what parts are compromised and how (and why) it can be made a better example of "how to program in Pharo" properly. If anyone has the time and is willing to help, the code (complete with class & method comments, test classes/methods, and the Zebra Puzzle example) is here: https://github.com/tbrunz/logic-puzzle and I'm available to answer questions about it, of course. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Back on the 'Intermediate Tutorials' question... I would love to see intermediate tutorials on Spec2 and Seaside.... and perhaps how to best adapt an (Sp)Application to serve both 'presenters' with guidelines on what responsibility goes where on the presenter/component, application, and model(s). What I found most useful in tutorials is specific examples. To me, generic examples can be too easily misunderstood - making them difficult to (re)apply. A specific example, even if silly, can really make a difference... i.e. I'm never going to create a GUI based on the Class/method hierarchy and I find it very difficult to apply those examples (although they are slick) to my application needs. I love looking at how other people approach problems, identify solutions (I can't wait to dig into the logic-puzzle code). This mailing list is great, but more - and more advanced - tutorials would be very much appreciated! Thanks! Russ On Mon, Jul 27, 2020 at 11:45 PM tbrunz <[hidden email]> wrote: So I decided to write an application to solve the Zebra Puzzle, by solving Russ Whaley [hidden email] |
I also would love to see intermediate tutorials on Spec2 and Seaside. (And
Zinc and Teapot, too, for that matter.) And the example/tutorial I'm working on really *should* have a Spec2 _and_ a Seaside/Teapot interface. But that's a bit over my head... Which is frustrating; I want to know how to do it. (I want to know it well enough to *teach* it.) I would need help for that, but I know everyone is so busy, and this particular app won't necessarily appeal to many. I'm working towards doing just what you're describing, Russ -- *specific* examples, that use "typical" constructs in Pharo for "typical" processing situations. Because I know also that these are really helpful for learning. Eventually I'd like to have/help create a series of "intermediate-level" tutorials, with not just example code, but with instructions/examples of how to work with the tools in the IDE to implement, test, debug, etc. Let me know what you think of the code so far -- feedback is needed & appreciated! -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by Russ Whaley
Hi Russ,
I added an "Examples" package tag, with several methods that lead through the Zebra Puzzle solution, step by step. It still doesn't do the entire solution by itself, but each example method displays the solution state up to that point, allowing you to examine the results and infer additional rules to add. The last example method combines the puzzle rules + the additional rules you infer, and displays the complete solution. I plan to make the code "smarter" over time, so that it can eventually solve the whole thing by itself. Let me know what you think... -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by tbrunz
After I did learning OOP and Pharo with style so that I do not have to talk about it again. So definitively. -------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
In reply to this post by Russ Whaley
Now for the seaside tutorials please ask seasiders because what is killing me is to have to deeply learning something before writing may be one person can write some blog posts. For Spec2 we will but I’m waiting for esteban to write and I do a pass after.
Did you see
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
EXACTLY!, Stéphane, thank you! I will go through this tutorial today. Has anyone written any documentation or maybe a tool that would help understand what each ‘widget’ is capable of? I review all example code, read all class comments and peruse the class hierarchy, but when a widget capability doesn’t work for me, I don’t know whether I’m using it incorrectly, in the wrong place, or if it’s a bug.. I.e filter/sort, TransmitTo:, drag and drop, double-click, right-click, presenter management (modal, etc), and how to force the display to refresh, etc. Your thoughts? I appreciate (and admire) all the work you and everyone put into the documentation and tutorials - and I am voracious in consuming them. I hope to build my skills to be able to contribute for the community. Thanks! Russ On Sun, Aug 2, 2020 at 5:07 AM Stéphane Ducasse <[hidden email]> wrote:
Russ Whaley [hidden email] |
Same feeling for me. This is why I would like - to have the time to propose a way to mark API elements so that we can build a little tools to show the API of each widget We did this in Spec1 and it supported the auto documentation of the system. - to have better method comments, and class comments. - that esteban write more doc. I decided that I will not write anything before (because I’m TIRED to learn by try and error to be able to write documentation). I will never do that again. It is not fun and I prefer to focus on my stupid projects because I know them. So if you want to help me. Ask for them :)
If you find typos or strange english let us know. Because this is already a contribution
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
In reply to this post by Stéphane Ducasse
>> I've been thinking lately that it would be nice to expand the number of
>> Pharo tutorials we have available. But rather than (or along with) >> creating >> more "beginner" level tutorials, I'd like to see some good "intermediate" >> level Pharo tutorials. > >Me too :) Let's do it, then. I'll volunteer to do most of the work. :^) My hope is that participating in this will make me capable of creating advanced tutorials all by myself. >> I think that programmers who already know the Pharo >> syntax and messaging semantics could benefit from more advanced tutorials >> that demonstrate how to develop "real world" Pharo code for "real world" >> processing needs. > >Yes yes I would love that. That was part of my motivation for creating a Pharo app to solve the Zebra Puzzle. First, of course, I wanted to solve it. ;^) >> What I'm talking about is something that assumes you know the language, >> the >> basics of the IDE (but not necessarily how to leverage its capabilities >> to >> aid development), and the basics of the foundation classes (but not its >> details). I'd like a tutorial for intermediate Pharo programmers who >> want >> to become experts with Pharo. Something that can show you how to apply >> the >> tools of the IDE and the features of the language and base classes to >> create >> solutions that solve complex problems. > >do you have ideas? I do! As I started building the Logic Puzzle app, it occurred to me that I could probably find several different, common structures in OOP (specifically, Pharo) to add to the solution. And then each would be its own example of "what real Pharo code looks like". I.e., be good examples. But first, I needed to explore "how to do it in Pharo" for myself, which naturally would have me working the IDE strongly. Then I thought, the entire application can/should be an example, so it should be a tutorial. That means that I need more than just a completed application (that's "just an example"). To be a *tutorial*, it means starting from scratch, showing how to approach the solution, how to start a Pharo app, how to use the IDE, how to write tests, how to refactor code, etc. Then I thought, this needs a GUI. Either a Spec2 UI or a web app UI (with Seaside or Teapot). But I would need help with that! So I'll start by creating a message-based solution, and maybe get help to add a UI later. I did some prototyping, then got what I think might be a good code structure (by version 4; it took a while to "think pure OOP"; old habits are hard to fight against). It runs, it works. But.. Is it "good Pharo code"? I'm not experienced enough to answer that question. I need a code review, criticism, guidance. Point me in the right direction and I'll keep working on it, and start thinking about how to express the "meta" elements (how to use the IDE to make/test the code, etc.). >> What does the community think of this idea? > >I love it. I did Pharo by example so that I can get of rid of the beginner parts. >After I did learning OOP and Pharo with style so that I do not have to talk about it >again. > >So definitively. Okay, great. I'll do most of the work. But I need help... I don't want to go any further without someone much more experienced than I am to review what I have and let me know what I'm doing right & what I'm doing "no quite so right". Yes, it runs, it works -- but that's *not* good enough. The goal here isn't to "hack out a solution and move on", the goal is to "create an example and tutorial that's high enough quality to use to teach Pharo to other people". I don't want to be teaching *my* bad habits! Also, I know next to nothing about Spec2 or Seaside/Teapot. I just know that I need to learn it, and I need to use it to give my tutorial a UI (or two). Newcomers will show up wanting to learn Pharo, and they need to be reassured that they can create nice (enough) UIs without a huge effort. (Not everyone is a command line hacker, and end-users certainly don't want to be.) The more I learn (from you), the more I can be independent, and the more tutorials I could produce -- without a lot of help. I'm willing to do the work, because that will help make me a Pharo "master programmer". (I don't want to be a hack, and I can't really be a trainer if I'm just a hack myself.) I'll pay back the community by helping to attract and advance more developers' skills. I just have to have the more advanced knowledge & skills myself. So, train the (future) trainer, anyone?? -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
>> Let's do it, then. I'll volunteer to do most of the work. :^)
> >I will review anything you write :) I'll write well and add lots of comments to make that easy for you. :^D >> My hope is that participating in this will make me capable of creating >> advanced tutorials all by myself. > >I usually like to write to learn and dump what I learned. That describes me very well, too. Teaching others (who want to learn) is fun. That often provides just the motivation I need to make something, do it right, and then publish the results (including my own insights). And you learn best when you're teaching others. I see that all the time. So I don't really understand all these people who don't want to learn anything -- don't want to learn something new, or don't want to learn better ways of doing what they're already doing. Maybe most of them are "too busy". I'm too busy, but I work at it. (?) >>>> I think that programmers who already know the Pharo >>>> syntax and messaging semantics could benefit from more advanced >>>> tutorials >>>> that demonstrate how to develop "real world" Pharo code for "real >>>> world" >>>> processing needs. >>> >>> Yes yes I would love that. >> >> That was part of my motivation for creating a Pharo app to solve the >> Zebra >> Puzzle. First, of course, I wanted to solve it. ;^) > >I will send you some feeedback and PR. Thanks! -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
In reply to this post by Stéphane Ducasse
Here are a couple of items with my first 5 minutes with the TODO tutorial... TODOListPresenter >> initializePresenters todoListPresenter := self newTable addColumn: ((SpCheckBoxTableColumn evaluated: [:task | task isDone]) width: 20); addColumn: (SpStringTableColumn title: 'Title' evaluated: [:task | task title]); yourself. self layout: (SpBoxLayout newVertical add: todoListPresenter; yourself) In this portion (Showing Tasks) - it does not define todoListPresenter.... is it a local or a missed instVar. I tried it first as a local to enable save, but then... TODOListPresenter >> updatePresenter todoListPresenter items: TODOTask selectAll asOrderedCollection todoListPresenter isn't available for updatePresenter... so I'm assuming it must be an instvar? I created accessors, then changed all the todoListPresenter references to use the accessors (below). TODOListPresenter >> initializePresenters self todoListPresenter: (self newTable addColumn: ((SpCheckBoxTableColumn evaluated: [:task | task isDone]) width: 20); addColumn: (SpStringTableColumn title: 'Title' evaluated: [:task | task title]); yourself). self layout: (SpBoxLayout newVertical add: self todoListPresenter; yourself) and... TODOListPresenter >> updatePresenter self todoListPresenter items: TODOTask selectAll asOrderedCollection Also, in the first example - task isDone needs to be defined (and might be defined later in the tutorial) - I'm assuming SpCheckBoxTableColumn>>evaluated: is expecting a boolean, or do I need to convert this somehow? I can check all these things out - but just curious if I'm missing something? TODOTask >> done ^ done TODOTask >> isDone ^ self done I'll go through a bit more and update you on my progress. Ted, I also hope to get to take a look at Zebra today :) On Sun, Aug 2, 2020 at 2:07 PM Stéphane Ducasse <[hidden email]> wrote:
Russ Whaley [hidden email] |
Well, the very next step in the tutorial says: How does this look?Now we can open our task list manager as follows: TODOApplication new run. However, TODOApplication has not yet been connected to anything... displaying the UI that is depicted in the tutorial is not achievable at this point... So, at this point I have to stop. I've had similar issues with IMDB and other tutorials where very important steps have been left out and I cannot achieve the results depicted. Some I'm able to figure out, many others I'm just not experienced enough to know how best to proceed... sorry. Another item I noticed - as I was interested in the onActivation / onDeactivation... there appears to be a misspelling in the instvar in the SpCheckBoxTableColumn class - it says onDesactivation instead of onDeactivation - there is an added 's'. For now, I can change the tutorial to match the class - however, if you attempt to save the code in the tutorial, it would error. I'm really looking forward to completing this tutorial - there looks to be some great things I want to learn... but I can't get past the first few issues :( Russ On Sun, Aug 2, 2020 at 2:22 PM Russ Whaley <[hidden email]> wrote:
Russ Whaley [hidden email] |
In reply to this post by Russ Whaley
Hi
Thanks I was planning to implement it. I asked Esteban to take the time to integrate my PR. Now can you send some PRs to the version of esteban like that we will get a better version. And you can open issues on his repo We will fix them. S
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
In reply to this post by Stéphane Ducasse
I wrote a "theory of operation" document for my app,
https://github.com/tbrunz/logic-puzzle But then I realized, "Where do I put it??" I thought of a few possibilities: * Commit it to the git repo, but then it wouldn't be easy to access from Pharo, * Add it to a top-level Pharo class comment, * Make it into a string in Pharo, put it in a method in a class. What's the standard practice for "attaching" non-code documents to Pharo applications? -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
I would put it in class comment.
We are about to release a nicer rendering of comments. S.
-------------------------------------------- Stéphane Ducasse 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France |
Okay, I'll do that. But this brings up a more general question...
If I wanted to add a diagram, or maybe a document with equations (rendered in LaTex), then a class comment wouldn't work. ...Unless that's intended to be part of the newer format?? -t > I would put it in class comment. > > We are about to release a nicer rendering of comments. > > S. > > > On 4 Aug 2020, at 06:46, tbrunz <wild.ideas@> wrote: > > > > I wrote a "theory of operation" document for my app, > > https://github.com/tbrunz/logic-puzzle > > > > But then I realized, "Where do I put it??" > > > > I thought of a few possibilities: > > > > * Commit it to the git repo, but then it wouldn't be easy to access from > > Pharo, > > * Add it to a top-level Pharo class comment, > > * Make it into a string in Pharo, put it in a method in a class. > > > > What's the standard practice for "attaching" non-code documents to Pharo > > applications? > > > > -t > > > -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Free forum by Nabble | Edit this page |