- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo MOOC: Difference between class methods and instance methods

by Stephane Ducasse

Hello Michel did you have a look at the mooc videos? C019-W3S06-BasicClassMethods.pdf and W5S02-UnderstandingClassMethods.pdf In Pharo there is only one method lookup. a method is looked up in the class of the receiver and if not found up in superclass hierarchy. This exactly the same for class methods: On Fri, Jul 21, 2017 at 10:38 PM, Michel Marinier <mobimich(a)gmail.com> wrote: > 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 22, 2017

best naming practices for (file) format reading/writing

by Peter Uhnak

Hi, I've seen (and I use) different naming conventions when reading/writing from files/streams... e.g. MyReader new readFromStream: aStream. "-> aModel" MyWriter new writeToStream: aModel. "-> aStream" or (MyReader new on: aStream) upToEnd. "-> aModel" (MyWriter new on: aStream) nextPut: aModel. "-> aStream" or MyReader new fromString: aString. "-> aModel" MyReader new toString: aModel. "-> aString" etc. (optionally with class-side methods for convenience). Do we have some best practices/recommendations/conventions regarding this? Thanks, Peter

July 22, 2017

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

by Stephane Ducasse

Hi holger "the growth from Pharo3->Pharo6" us too :) this is why we invested in the bootstrap and this is why we will remove (and we started) packages and classes. And this is also why we will continue to repackage the system. Stef On Sat, Jul 22, 2017 at 10:43 AM, Holger Freyther <holger(a)freyther.de> wrote: > >> On 21. Jul 2017, at 11:19, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Hello people, > > Hi! > > >> 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 > > I am concerned with the growth from Pharo3->Pharo6 as well and triggered by your mail looked at it again. In contrast to ImageCleaner>>#cleanUpForRelease I want to keep the Monticello/Metacello packages for now (and don't want to unload them after test). > > I call this with "pharo Image eval clean.st" and for whatever reason if I pass --save bad things (can't talk to mongod) happen during my system test but that is another story (maybe the save is executed at the _next_ image start again). > > > World closeAllWindowsDiscardingChanges. > (RPackage organizer packages select: [:package | package packageName includesSubstring: 'Test']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName beginsWith: 'Versionner']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName beginsWith: 'ProfStef']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName beginsWith: 'Ice']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName beginsWith: 'BaselineOf']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName beginsWith: 'ConfigurationOf']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName endsWith: '-Help']) > do: [:each | each removeFromSystem ]. > (RPackage organizer packages select: [:package | package packageName endsWith: 'Examples']) > do: [:each | each removeFromSystem ]. > > ImageCleaner new cleanUpForRelease. > Smalltalk snapshot: true andQuit: true.

July 22, 2017

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

by Stephane Ducasse

Yes but there are not concrete enough for me :) On Fri, Jul 21, 2017 at 7:37 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > 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 22, 2017

Re: [Pharo-users] Beyond Live Coding

by Stephane Ducasse

Thanks Jimmie. Do not hesitate to improve Pharo, because Pharo is what we have and each we can make it better. BTW: it was not my roadmap it is the result of everybody in the team brainstorming. On Fri, Jul 21, 2017 at 6:35 PM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > 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 22, 2017

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

by Holger Freyther

> On 21. Jul 2017, at 11:19, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hello people, Hi! > 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 I am concerned with the growth from Pharo3->Pharo6 as well and triggered by your mail looked at it again. In contrast to ImageCleaner>>#cleanUpForRelease I want to keep the Monticello/Metacello packages for now (and don't want to unload them after test). I call this with "pharo Image eval clean.st" and for whatever reason if I pass --save bad things (can't talk to mongod) happen during my system test but that is another story (maybe the save is executed at the _next_ image start again). World closeAllWindowsDiscardingChanges. (RPackage organizer packages select: [:package | package packageName includesSubstring: 'Test']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName beginsWith: 'Versionner']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName beginsWith: 'ProfStef']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName beginsWith: 'Ice']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName beginsWith: 'BaselineOf']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName beginsWith: 'ConfigurationOf']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName endsWith: '-Help']) do: [:each | each removeFromSystem ]. (RPackage organizer packages select: [:package | package packageName endsWith: 'Examples']) do: [:each | each removeFromSystem ]. ImageCleaner new cleanUpForRelease. Smalltalk snapshot: true andQuit: true.

July 22, 2017

Re: [Pharo-users] Beyond Live Coding

by Dimitris Chloupis

Live coding as a concept does not exist in most languages. The reason why they can do live coding is because out of necessity . Take exceptions for example , almost never you will find any mention about live coding but you will read about code exiting elegantly or not exiting at all and reloading modules etc. In the end all coders need a lot of flexibility during execution , especially during the process of debugging. Even in Pharo live coding shines the most during debugging process this is why they go hand in hand. The moment you have live code and state having live objects is just a consequence of having live code. If you approach it from a pure object orientated approach that is not unique either. Because nowadays we have many extremely popular languages like Python and Ruby . Python for example suppose to be a hybrid procedural and OOP language but that is a lie because in Python functions are objects. Ruby is almost Smalltalk. So both Python and Ruby are pure object orientated. Pharo crash prone behavior is not extensive. Live state will be lost for data living outside Pharo. If the data is accessed or copied from Pharo the copy will be retained through saving the image but if you don't save the live state of Pharo will be lost. Even if you do save the image the live state on the C side won't be stored so it's up to you to restore if you have the means to do so and already took the appropriate measures. This is why I made a big deal for memory mapped files because essentially they store using an auto save feature live c and C++ state. Another huge problem for Pharo is that crashes can corrupt the image which means you will have to rebuild it from scratch which can be so tedious if you have lost a lot of live state. Recovery of code is not a big deal for other programming languages cause unlike Smalltalk they are based on source code files and most modern IDEs will auto save your source code file. If you use version control that becomes unnecessary if you commit often like I do because essentially you become unable to lose code. Smalltalk and Pharo shines in the idea of a single IDE but the community is too small to afford to be fragmented between many different IDEs. In other languages some IDEs are closed source , some are open source but the trend for the past decade is toward open source IDEs. For example I code in Python and by far the most popular IDE is PyCharm , it's closed source but it has a free edition called "Community Edition" that contains most of of the commercial features (80%) it's one source and free and hosted in Github https://github.com/JetBrains/intellij-community/tree/master/python The idea of self contained environments is no big deal either because we have git forks , Python even comes with another features that allow you to create isolate environments that like Pharo contain your code, the language and any library used. Smalltalk was a bIg deal decades ago but no longer is because coders themselves may not be aware of either Smalltalk or Lisp but language and IDE designers and library developers are very much aware as both languages are considered the golden standard and very much respected. Pharo is important because is a modern implementation of Smalltalk and tries to push its concepts further. Unlike other language it's not just about copying Smalltalk or canibalizing it's ideas. It's crucial that Smalltalk continues to evolve because afterall is a language of innovation. None the less we live in a time that modern technology is very close to Smalltalk and most of its features have infected modern coding. They are fragmented or not that obvious or out of the box offered but they are there and experienced coders already rely on them to speed up their workflow. Languages like C distance themselves from Smalltalk because they prioritize performance. It's the usual case of not having your cake and eat it too. But since every language including Smalltalk is based on C for performance you can implement many of the features. Problem is that you will be reducing performance so in that case it takes more sense to use Pharo or Python or what else. In any case Pharo is a great environment to work with many flaws and unique advantages in the end Pharo is Pharo offering its own unique experience we all love and respect. Emulation is never the same as the actual thing. On Fri, 21 Jul 2017 at 19:36, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > 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 22, 2017

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

by Tudor Girba

Aha. Thanks for the clarification. Doru > On Jul 21, 2017, at 8:59 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > 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 > > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

July 22, 2017

Re: [Pharo-users] Iceberg + github without github account

by Herby VojÄÃk

Peter Uhnak wrote: > In Iceberg (Version Control) settings, there should be an option "enable Metacello (or Monticello?) integration" that should disable this iirc. > > On Fri, Jul 21, 2017 at 08:35:23PM +0200, Herby VojÄÃk wrote: >> 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. This line adds that programmatically. But the metacello integration integrates _both_ gitlocal:// support and the rewritten github:// support. The workaround above rewrites 'type' of the github (eg. scheme) that Iceberg version hooks itself on, effectively removing it from 'github://' style urls (so the inherited, zip-based read-only one is used). So if I disable it (as is the default case) I lose the gitlocal:// support (I am enabling it because of that). The question here is, is there better / will there be official possibility to only integrate one without the other (or integrate github so it works without having the account there)? Herby >> 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] Iceberg + github without github account

by Peter Uhnak

In Iceberg (Version Control) settings, there should be an option "enable Metacello (or Monticello?) integration" that should disable this iirc. On Fri, Jul 21, 2017 at 08:35:23PM +0200, Herby VojÄÃk wrote: > 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