- Pharo-users - lists.pharo.org

Pharo MOOC: Difference between class methods and instance methods

by Michel Marinier

I am an absolute beginner at Pharo and IÂm working my way through Pharo by Example as well as the MOOC online. While coding the TinyBlog example in the MOOC, I got stuck until I kind of ÂguessedÂ the difference between ÂTBPost >> methodNameÂ and ÂTBPost class >> methodNameÂ. I didnÂt know I had to click on the Class button to access the class methods and coded all the methods as instance methods. As a result, the system complained when the code tried create a new instance from a method such as Âtitle: text:Â. I suppose I might have missed the place where this was explained in the MOOC, although IÂm not sure it was emphasized early on in the lessons. However, a suggestion would be that if you ever update the exercises that a notice be added warning students of the difference, at least in the first few exercises where there is so much to learn and remember. IÂm doing it in French, so it might look like this: Â NÂoubliez pas la diffÃ©rence entre ÂTBPost >>Â et ÂTBPost class >>Â. Le premier indique quÂil sÂagit dÂune mÃ©thode dÂinstance. Le second indique quÂil sÂagit dÂune mÃ©thode de classe. Vous devez cliquer le bouton ÂClassÂ pour accÃ©der Ã la section correspondante. Dans la section pour lÂinstance, la dÃ©finition dÃ©bute par ÂObject subclass: #TBPostÂ alors que dans la section pour la classe, la dÃ©finition dÃ©bute par ÂTBPost classÂ. Â By the way, congrats on the great work providing those resources. I love the advice to poke around the system with the Browser and the Finder to find out stuff. Thanks.

July 21, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Hilaire

The problem is explained in the ticket: there is a bug in the position where the drgeo menu shows up when encapsulated in the Playground. It is not related to Glamour however. I may just decide to remove the Dr. Geo menu to avoid the bug. Le 21/07/2017 Ã 20:50, Tudor Girba a Ã©crit : > Can you detail your needs regarding the integration with Playground? -- Dr. Geo http://drgeo.eu

July 21, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Tudor Girba

Hi, Can you detail your needs regarding the integration with Playground? Cheers, Doru > On Jul 21, 2017, at 11:19 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hello people, > > Here are a few critical issues due to bugs or lack of information or feature for porting Dr. Geo to P6. There were others critical issues from P6 but were resolved and will be hopefully integrated, when ? > > â¢ Minimal Dr. Geo image > â¢ Integration with Playground > â¢ Export bitmap to clipboard <-- it will be really cool to have. > â¢ Universal package for 64 bits > Other issues: https://launchpad.net/drgeo/+milestone/17.09 > > My initial plane and need is to finish the porting and test by the end of August. Not sure it sounds realistic. > > Hilaire > > -- > Dr. Geo > > http://drgeo.eu -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

July 21, 2017

Iceberg + github without github account

by Herby VojÄÃk

Hello! I use Iceberg with metacelloIntegration: true to have gitlocal:// protocol available to load local git repos. Problem I encountered (while trying to load Mocketry) that Iceberg hijacks github:// protocol and it seems it needs ssh credentials that actually allows access to github. But I don't have (and don't plan to have, because reasons) a github account. For the moment I work it around this way (the script I use to build my work image): ---- BEGIN | hereRef | hereRef := Smalltalk imageDirectory asFileReference. (IceRepositoryCreator new location: hereRef; subdirectory: 'src'; createRepository) register. "BEGIN WORKAROUND" IceGithubRepositoryType class compile: 'type ^ ''github+rw'''. "Work around github:// needing access" "END WORKAROUND" Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Towergame'; repository: 'gitlocal:///', (hereRef / 'src') fullName; load. Towergame configure. Smalltalk snapshot: true andQuit: true. ---- END Questions: Is there some more canonical way to get there? Will Iceberg include something to make it easier to have readonly-github repos / integrate only gitlocal://? Thanks, Herby

July 21, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Hilaire

Hi Stefane, Did you read the bug tickets in my previous email? Hilaire Le 21/07/2017 Ã 18:08, Stephane Ducasse a Ã©crit : > I do not understand what the issues that you need in Pharo 60. -- Dr. Geo http://drgeo.eu

July 21, 2017

Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work?

by Tim Mackinnon

Paul - this is very helpful, gosh you learn a lot from what seemed like simple question. Your suggestion along with Subbuâs gives an easy workable solution - I also wonder if the method should be in the image along with the comment explaining half open intervals like you have. Do you think there is another name for that end method - displayEnd sounds like it actively displays - I wonder if boundedEnd or completeEnd or finiteEnd might be correct alternatives (or is displayEnd a decent convention that everyone understands?) I really have to learn how to submit pull requests (although it seems rather complicated at the moment while the full git integration process is being sorted out). Thanks everyone Tim > On 21 Jul 2017, at 16:40, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Tim Mackinnon wrote >> I am also wondering if the issue with Timespan is concerning - I was >> surprised that putting a start and end date left me something that didnât >> answer my end date presumably down to rounding when itâs converted down to >> a duration (making me wonder if its better to keep a start and end date >> and calculate the duration on the fly). >> >> Tim > > > The Timespans are half open intervals. > (https://en.wikipedia.org/wiki/Interval_(mathematics)) > > Friday July 21st ends at 11:59:59.99999999999... etc etc etc ...9999PM and > the 22nd starts at 12:00AM > > > If Timespans were closed intervals like you expect then we'd be out of whack > with our corner of the universe. That extra clock tick adds complexity. > > But I add a method to my image called #displayEnd because I also want them > to print 3PM-4PM and not 3PM-3:59:59.999999999PM and use that in my print > statements and rendering for Seaside. > > displayEnd > ^ start + duration > > > > > > > > > -- > View this message in context: http://forum.world.st/How-to-calculate-someone-s-age-elegantly-Does-Duratio… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 21, 2017

Re: [Pharo-users] How to calculate someone's age elegantly? Does Duration work?

by Tim Mackinnon

As an aside - there is another way of doing it - but Iâm not sure if its clearer (or more efficient): ^ ((aDate year * 10000 + (aDate monthIndex * 100) + aDate dayOfMonth - (self year * 10000 + (self monthIndex * 100) + self dayOfMonth)) / 10000) truncated > On 21 Jul 2017, at 12:54, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > On Friday 21 July 2017 03:01 PM, Tim Mackinnon wrote: >> Actually that simplification doesnât work - someone born on 1/Mar/2000 should be 11 on 1/Mar/2011 and this answers 10 (the previous version did work). > > You're right. The simplification does not take into account leap days. Mea culpa. Original code (dropping +1) is readable and simple. > > Regards .. Subbu > >> This does make me think its tricky enough to put this in the core - I may submit it along with the unit tests I borrowed from Stack Overflow (the shame)â¦ >> Its a good problem though. Thanks for discussing it with me. >> Tim >>> On 21 Jul 2017, at 10:09, K K Subbu <kksubbu.ml(a)gmail.com <mailto:kksubbu.ml@gmail.com>> wrote: >>> >>> ^aDate year - self year - >>> (aDate dayOfYear < self dayOfYear) ifTrue: [ 1 ] ifFalse: [ 0 ]) > >

July 21, 2017

Beyond Live Coding

by Jimmie Houchin

Pharo (Smalltalk) is much more than simply live coding. All of us here dearly love live coding. Kilon states it is possible to do live coding in other languages. I have no experience doing so in any other language. I will say that I know of no other language that it is integral to development in that language. Pharo is a live object environment. It has objects that would take someone with a better understanding of the entire image than myself to tell when the object was created. But suffice it to say that Pharo (Smalltalk) have some very old objects, possibly back to 1980 or 1972? The live environment supports live objects, not just live coding as understood by someone who may attempt live coding in some language that does not by nature do live coding. Objects have state and behavior. Objects in Pharo grow and shrink in behavior and state as messages are sent to them. They evolve, they dynamic not static. Pharo's environment can survive crashes. Yes, I know, there are times when some unrecoverable event happens and you can not recover lost changes. But the community attempts to fix anything that would cause such an event. Other languages, do not have such. Segfaulting is normal, to be expected. You go back to your dead code editor and fix what caused the segfault and start up again, clean without the state your objects were in when it happened or even before. They do autopsies on their core dumps to attempt to discover what went wrong. Yes, you can explicitly choose to run a debugger on your app to watch its state and behavior. Pharo's environment survives shutdown of its environment and shutdown or restart of an operating system. Once restarted your Pharo environment is exactly as it was with all it's live objects and live code. It survives change of operating systems and computers. All the image needs is the appropriate vm for the image and the operating system currently running. Pharo can survive stupid programmer errors. I have written infinite loops and lived to tell about it. My objects and environment survived. I have written code which took hours to execute over a large set of data only to discover I had an error in my code on the last method or so that executed and it raised a debugger. I fixed it and continued. Nice. In some other language, you fix and start over executing that multiple hour process and hope there are no more errors. I know of no other language that facilitates this behavior. The editing of the code is in a different environment from the execution of the code. The state of the objects in the executing code disappears when the code ceasing execution whether by choice or error. And yes, some of that is and can be mitigated by files and databases. Live debugging of code is by executing an application (debugger) on the application you want to debug. This all by nature is static and dead. Only to discover problems in my fixed in time code and objects. You can't fix the debugger while debugger some program. I don't know that you necessarily fix the program outside of discover of where to fix it in the separate editing process. Then you start all over again. Even if you can overcome ever single one of my perceived technical difficulties. And I may be in error. I do not program in those environments and have little experience there. One thing that is indisputable at least to my understanding is this. Whatever language you may overcome all of this in, you are quite possibly doing it alone or at best in very small groups. There is no community or cultural support. Pharo has a community, a culture which supports the artifact which provides this live object environment. This is of tremendous value. Pharo has a culture which supports live objects and live coding. It has a culture that says your stupid code should not crash the environment. If it does, we need to fix it. Pharo is not perfect. Its community is not perfect. But I have not found anything or place better. So I am learning C, and dead programming hopefully sufficiently enough that I can bridge the gap where Pharo does it well or where Pharo could use a little outside help. But I still get to live in my nice live object environment. I have nothing against other languages. I would love it if there were other languages which had this ability and culture. But I don't find them anywhere. I have programmed in Python, Lua, played with PicoLisp. Pharo is home. :) And to top it all off, Stef's Pharo 7 and 8 roadmap looks pretty sweet. I just wanted to say that Pharo (Smalltalk) is so much more than what I perceive other languages understanding of live coding to be. And that I know of no other language or community which approaches what is done by nature in Pharo (Smalltalk). All the above is my naive opinion. Do with it as you will. Have a great day! Jimmie

July 21, 2017

Re: [Pharo-users] Why does debugger browse open on Object?

by Stephane Ducasse

Sure propose a fix. On Thu, Jul 20, 2017 at 12:31 AM, Tim Mackinnon <tim(a)testit.works> wrote: > It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need). > > Not sure how you get an icon on the button (create doesn't either). > > Maybe I can propose it for 7. > > Possibly call it "browse receiver"? (A bit long though) > > Tim > > Sent from my iPhone > >> On 19 Jul 2017, at 19:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi, >> >>> On 19 Jul 2017, at 19:56, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> Hi Tim, all >>> >>> 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >>>> Hi - I've always meant to ask this question as it often catches me out. >>>> >>>> When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. >>>> >>>> It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... >>>> >>>> But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. >>> >>> Yesterday I was going to ask about this behavior, which has been >>> nagging me for some time. I feel better reading it isn't only me who's >>> sensitive to this friction. >>> >>> I don't understand why it is like this, but I assume it is because of >>> a common behavior of browsing the receiver object in the stack frame >>> without considering particular cases like Object>>doesNotUnderstand: >>> >>> I'll be happy if you find a way to implement it, as a System Option or >>> via a shortcut modifier. >> >> In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. >> Maybe now is time to retry ;) >> >> Esteban >> >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >> >> > >

July 21, 2017

Re: [Pharo-users] Critical issues for Dr. Geo on P6

by Stephane Ducasse

Hilaire I do not understand what the issues that you need in Pharo 60. Stef On Fri, Jul 21, 2017 at 11:19 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hello people, > > Here are a few critical issues due to bugs or lack of information or feature > for porting Dr. Geo to P6. There were others critical issues from P6 but > were resolved and will be hopefully integrated, when ? > > Minimal Dr. Geo image > Integration with Playground > Export bitmap to clipboard <-- it will be really cool to have. > Universal package for 64 bits > > Other issues: https://launchpad.net/drgeo/+milestone/17.09 > > My initial plane and need is to finish the porting and test by the end of > August. Not sure it sounds realistic. > > Hilaire > > -- > Dr. Geo > http://drgeo.eu

July 21, 2017