July 2017 - Pharo-users - lists.pharo.org

NeoCSV change proposal

by Peter Uhnak

Hi, this is a continuation of an older thread about quoting fields only when necessary. ( http://forum.world.st/NeoCSVWriter-automatic-quotes-td4924781.html ) I've attached fileouts of NeoCSV packages with the addition (I don't know if Metacello can file-out only changesets). The change doesn't affect the default behavior, only when explicitly requested. Peter

July 22, 2017

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

by Hilaire

Hi Holger, With Pharo3 I was proceeding like this, by uninstallation of packages. However there is the promise of building from a minimal image, but it is not documented AFAIK. By curiosity, what is the size of your resulting image. Hilaire Le 22/07/2017 Ã 10:43, Holger Freyther a Ã©crit : > 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). -- Dr. Geo http://drgeo.eu

July 22, 2017

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

by Hilaire

You are welcome. I also wrote here a few days ago about it. The bug is Morphic specific. Hilaire Le 22/07/2017 Ã 09:03, Tudor Girba a Ã©crit : > 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. -- Dr. Geo http://drgeo.eu

July 22, 2017

Re: [Pharo-users] best naming practices for (file) format reading/writing

by Stephane Ducasse

Not really but it would be nice to collect them. On Sat, Jul 22, 2017 at 1:05 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > 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] Pharo MOOC: Difference between class methods and instance methods

by Stephane Ducasse

- class methods are sent to class - the corresponding method is lookup in the class of the receiver for example Date now now is looked up in the class of Date => Date class Stef On Sat, Jul 22, 2017 at 1:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 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

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