February 2017 - Pharo-dev - lists.pharo.org

Catalog loading in Spotter

by Torsten Bergmann

In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load from catalog, perform a search and just hit ENTER to easily install the project. This was following the Spotter idea that it is easy to access most informations of Pharo with the Spotter tool. There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter". This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference scripts if this is problematic for someone. Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog integration is DISABLED BY DEFAULT. This leads to several effects: 1. While in the past it was possible in a fresh Pharo image to search and install out of the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly start by searching and installing from catalog using Spotter. 2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search in Spotter gives no results. Most people will not not know about the second setting and easily get lost and think this behavior is just broken. Also this second setting for the Spotter extension is much more hidden between all the other Spotter extension enablements very and hard to find. 3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess, MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will follow these will not only be confused - but also stuck in trying Pharo when he learns from these videos. I was asked several times on Slack and via Mail from people who were not able to reproduce ... this is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy not complicated. To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions with slow internet connection. I understand that we would like to support these Pharo users too as best as possible in their out of the box experience ... but (without being able to prove) I think that 90% or more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates, project loading, PharoLauncher, STHub or Iceberg/GitHub. Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow connections and less processing power). I do not know about all others from the community. I invested hours in the past in developing and introducing the initial configuration browser to Pharo, later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested hours in udpating configs or pushing you to put things into catalog. Because accessibility is key. Only when things are easy to access and understandable people will enjoy Pharo. Currently in an out-of the box image this easy access to the projects via Spotter is blocked. Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting leaving an unpleasant feeling how many others unknown to me will struggle with this issue. I see two solutions: A) We enable both settings by DEFAULT to bring back the Spotter search and installation of catalog items - with the clear benefit of having - the previous behavior in Pharo back - the out of the box ability to search for catalog projects in any fresh image - no confusion among the user base anymore regarding the settings - we have unbroken Youtube videos that newbees can continue to follow - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can just tell him "search in Spotter and you should be fine" as most of them have a config in the catalog. Remember that not all of us know about all the github pages or nice Metacello expressions. So the easier things are found and accessible the better it is. B) If A is still a "No go" for the community we should at a minimum switch the defaults of the two settings: => we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true) => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false) With this at least we have no confusion among the user base anymore regarding the settings. I would clearly and strongly vote for option A as my preferred one. I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art technologies where loading/installation megabytes from the web is often not seen as an issue. There are many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker. Shuffling megabytes around is a reality in todays technologies. So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth situations. Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will be pushed out of the door. Keeping it like it is without further actions would be really stupid. Thanks for you comments, ideas or votes. Thanks T.

Feb. 19, 2017

Re: [Pharo-dev] FileTree

by Dale Henrichs

Guille, You should be able to read (not load) Monticello packages into an image as a snapshot and then write that snapshot out in FileTree format ... There isn't a direct way for doing this type of thing in Monticello itself, but it can be put together without too much trouble. I've written code to do just that in tODE[1]. I've extracted the code in this mail and you should be able get something functional without too much trouble: mccopy: versionName fromRepository: sourcRepository to: destinationRepoDescriptions "destinationRepoDescriptions may include repository descriptions or object references (@xxx)" | version repo repositoryList | version := self versionFor: versionName inRepository: sourcRepository. repositoryList := OrderedCollection new. destinationRepoDescriptions do: [ :repoSpec | | repoOrList | repoOrList := self resolveRepositoryReference: repoSpec. "just need a FileTree repository instance here" repoOrList isCollection ifTrue: [ repositoryList addAll: repoOrList ] ifFalse: [ repositoryList add: repoOrList ] ]. ^ self mccopyVersion: version to: repositoryList versionFor: versionName inRepository: repo | reference version | reference := GoferResolvedReference name: versionName repository: repo. ^ reference version mccopyVersion: version to: repositoryList ^ repositoryList collect: [ :repo | self storeVersion: version inRepository: repo ] Dale [1] https://github.com/dalehenrich/tode/blob/master/repository/Topez-Server-Cor… On 2/18/17 4:20 AM, Guillermo Polito wrote: > We could try that... The thing is that it contains definitions of a > Smalltalk kernel, so there are alternative Boolean classes, String > classes, and so on... We would like to avoid conflicts in the image. > > On Sat, Feb 18, 2017 at 1:17 PM, <serge.stinckwich(a)gmail.com > <mailto:serge.stinckwich@gmail.com>> wrote: > > I don't understand because you can load your project in a Pharo > image and save it as with FileTree. > > EnvoyÃ© de mon iPhone > > Le 18 fÃ©vr. 2017 Ã 13:09, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> a > Ã©crit : > >> Hi Serge, >> >> Jonathan is trying to convert some old code I have in here: >> >> https://github.com/guillep/PharoCandle >> <https://github.com/guillep/PharoCandle> >> >> to Filtree. >> >> The thing is that at that moment I started that, FileTree was not >> there, So I made my own format and my own parser based and >> PetitParser and the Smalltalk petit parser that produced my own >> little meta-model :P. >> >> But now we want to move to the standard tools of today. >> >> What we would like to know is what should we use to write >> FileTree from something that is not Monticello, what is the class >> to look at, and the API to use. >> >> ANY information is welcome :) >> >> Thanks, >> Guille >> >> On Fri, Feb 17, 2017 at 5:22 PM, Jonathan Khalil <jonathan(a)esp.sn >> <mailto:jonathan@esp.sn>> wrote: >> >> Oh really ? My school is Ecole SupÃ©rieur Polytechnique (ESP). >> >> I want to rewrite the pharoCandle in the FileTree format but >> i don't know where to start. >> >> Jonathan >> >> 2017-02-17 16:37 GMT+01:00 Serge Stinckwich >> <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>>: >> >> On Fri, Feb 17, 2017 at 3:06 PM, Jonathan Khalil >> <jonathan(a)esp.sn <mailto:jonathan@esp.sn>> wrote: >> > Hi everyone, >> > >> > I'm Jonathan, student in master, from Dakar, SÃ©nÃ©gal >> and i will be working >> > with stephane ducasse's team for my internship. >> >> Great Jonathan. Where are you located ? My research team >> is working in >> Senegal in Dakar and St-Louis. >> >> > I need some lectures on FileTree. >> > Someone know how can i get it ? >> >> What kind of information you are looking for FileTree ? >> I'm not sure that there is that much information about it >> except the code :-) >> >> https://github.com/dalehenrich/filetree >> <https://github.com/dalehenrich/filetree> >> >> Regards, >> -- >> Serge Stinckwich >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> Every DSL ends up being Smalltalk >> http://www.doesnotunderstand.org/ >> <http://www.doesnotunderstand.org/> >> >> >> >

Feb. 19, 2017

Re: [Pharo-dev] Development dashboard for pharo-project repositories

by Ben Coman

Cool. Thanks Rafael. cheers -ben On Sun, Feb 19, 2017 at 8:02 PM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > Hi guys! > > I've just created a development analytics dashboard for the pharo-project > organization at GitHub using Cauldron [1], a proof-of-concept by Bitergia, a > University spin-off here in Madrid. > > You can play with the dashboard at: > https://cauldron.io/dashboards/pharo-project > > I expect you enjoy it and get insights about the Pharo community. > > [1] https://cauldron.io/ > > -- > Rafael Luque > > > > >

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by Ben Coman

On Sun, Feb 19, 2017 at 1:26 AM, stepharong <stepharong(a)free.fr> wrote: > > Hi guys > > I'm working on an introduction chapter for my future book and I do not like > the behavior I see in latest pharo 60. > > And I do not understand the behavior of print-it > > (MFDirectory new name: 'comics') > comics/ > > > (MFDirectory new name: 'comics') printString >>>> >>>> 'comics/' > > > > Why print it does not produce ''? > > > Stef > > > printIt > | printString | > self > evaluateSelectionAndDo: [ :result | > printString := [ result printString ] > on: Error > do: [ '<error in printString: try ''Inspect > it'' to debug>' ]. > self afterSelectionInsertAndSelect: printString ] btw, the code you reference there does not get executed from Playground. This does... (GLMGenericAction new) title: 'Print it'; action: [ :aPresentation | aPresentation printSelection ]; keymap: PharoShortcuts current printItShortcut; yourself. from GLMRubricSmalltalkCodePresentation>>executionSelectionActions which announces GLMPrintSelection leading to GLMMorphicPharoScriptRenderer>>evaluateAndPopPrintHighlight GLMPrintPopper installAlarm: #popupPrint for: self GLMMorphicPharoCodeRenderer>>popupPrint "Evaluates selected code and prints it in a popper" textMorph textArea editor highlightEvaluateAndDo: [ :result | textMorph shoutStyler style: textMorph text. GLMPrintPopper new openFromRubric: textMorph textArea withResult: result ] cheers -ben

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by stepharong

On Sun, 19 Feb 2017 16:04:31 +0100, stepharong <stepharong(a)free.fr> wrote: > Hi doru > > Yes I know. I did not imply anything.I think that the current status is > bogus. > I do not see any scenario that makes printString not returning and > displaying a string good. Yes there is one: the self evaluating objects 1 printIt >>> 1 true printIt >>> true true printString printIt >>> 'true' now I'm confused because there is something that does not work. > > I do not get why'comics' printString should double quote it.to me > 'comics' printString >>>> > 'comics' > > > 'comics' printIt >>>> > 'comics' > > as well as > (#AAA asClass new name: 'comics') PrintIt > > > I just to not get what is the benefit not to have in the workspace or > any users of printIt no single quote > > > I agree that for a list of items > you do not want to have > 'astroboy' 'tintin' > > but instead astroboy > tintin > > I see that lot of people got confused about that. Just look at the > cuboid videos of Roassal you get comboboxes full of ' ' while there > should not have any. > Now to me this is the job of displayString. > displayString is not the same as printString. > printString should return a string and I should see a string in the REPL > > Currently in the REPL because this is what we are talking aboutobtaining > a non string is confusing. > Am I clear? > Stef > >> Hi Stef, >> >> Just a clarification. I do not argue here. I just explain what I see. I >> think it was like this since a long time. I even checked in an old VW I >> have around and it seems to have the same behavior. >> >> But, I do agree that it is not straightforward at all. It took me a >> while to figure this out and it is still confusing sometimes. In fact, >> this is why we have a String presentation in the String object - I >> >>needed something that clarifies situations like these. That does not >> mean it is the best solution :). >> >> >>> On Feb 19, 2017, at 11:42 AM, stepharong <stepharong(a)free.fr> wrote: >>> >>> On Sun, 19 Feb 2017 11:40:04 +0100, Sven Van Caekenberghe >>> <sven(a)stfx.eu> wrote: >>> >>>> Ah, you're right: there is a difference between printing a textual >>>> representation on a stream / window and doing the same with the >>>> actual (print)string. I was not yet >>>>fully awake I guess. >>> >>> So >>> 'comics' >>> >>> comics whatever it means >>> but >>> (#AAA asClass new name: 'comics') >>> >>> âcomics' >> >> Itâs the other way around :). >> >> Example A: >> 'comics' >> >>print it>> âcomicsâ In this case we have a string object and we send >> printString to it which in String>>storeOn: adds the quotes as part of >> the contents of the new string. >> >> Example B: >> (#AAA asClass new name: 'comics') >> >>print it>> comics Here we have an non-string object and we sent >> printString to it which creates a string with the contents of the >> stream. As no String>>storeOn: is invoked in this case, there are no >> >>quotes. >> >> So, the two resulting print it strings do not have the same contents. >> >> Maybe another case: >> >> Example C: >> (#AAA asClass new name: 'comicsâ) printString >> >>print it>> âcomicsâ >> This is equivalent to Example A. We send printString to a string >> object and we get the quotes. >> >> The issue is that when we send printString to a string, we produce a >> new string with escaped quotes: >> 'comics' = (String streamContents: [:s | s << 'comicsâ]) contents. >> "true" >> 'comics' = (String streamContents: [:s | s << 'comics']) contents >> printString. "false" >> >> >>> I'm sorry but I do not get it at all. >>> Especially since we always wrote that printIt is sending printString. >>> I find that totally broken and I do not understand why this is good. >> >> Another thing to keep in mind is: >> >> Example D: >> Object new >> >>print it>> an Object >> This is essentially equivalent with Example A >> >> If Example B would produce >>print it>> âcomicsâ >> it would mean that Example D would produce >> >>print it>> âan Objectâ >> >> Ugh, I already got dizzy with so many quotes :). >> >> One problem is that when you look at a string, you do not know how many >> String>>storeOn: commands it went through. So, here is an idea: what if >> String>>printString would produce a >>EscapedString, which behaves like >> an operator? In this case, we would see better how many levels of >> String>>storeOn: are being displayed. >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> Stef >>> >>> >>> >>> >>>> >>>>> On 19 Feb 2017, at 10:59, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Hmm, I think I do not see it :). >>>>> >>>>> Letâs take it slowly. From what I see, the behavior is the same >>>>> since at least Pharo 3. >>>>> >>>>> Here is a script that seems to reproduce your situation: >>>>> >>>>> Object subclass: #AAA >>>>> instanceVariableNames: 'name' >>>>> classVariableNames: '' >>>>> package: 'AAA'. >>>>> #AAA asClass compile: 'printOn: aStream >>>>> aStream << name'. >>>>> #AAA asClass compile: 'name: aString >>>>> name := aString'. >>>>> #AAA asClass new name: 'comics' >>>>> >>>>> In Pharo 6, we have in a Playground: >>>>> >>>>> <Screen Shot 2017-02-19 at 10.48.55 AM.png> >>>>> >>>>> In Pharo 3, we have this in a Workspace: >>>>> >>>>> <Screen Shot 2017-02-19 at 10.49.26 AM.png> >>>>> >>>>> Calling Print It on an object produces a string out of the contents >>>>> of the stream, and displaying it shows the contents of the stream >>>>> (so, no quotes). >>>>>Calling Print It on a string produces a string >>>>> of the string, and displaying it shows the quotes of the first >>>>> string. >>>>> >>>>> You can see this in the String tab of the inspector: >>>>> >>>>> <p1.png> >>>>> >>>>> >>>>> <p2.png> >>>>> >>>>> Does this make sense? >>>>> >>>>> I think this is not inconsistent, but maybe there is a better way. >>>>> In any case, the behavior seems to exist since a long time. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Feb 19, 2017, at 9:06 AM, stepharong <stepharong(a)free.fr> wrote: >>>>>> >>>>>> Hi doru >>>>>> >>>>>> may be I do not see the obvious. >>>>>> I defined a class >>>>>> >>>>>> Object subclass: #MFElement >>>>>> instanceVariableNames: 'name parent' >>>>>> classVariableNames: '' >>>>>> package: 'MyFS2' >>>>>> >>>>>> printOn: aStream >>>>>> parent isNil ifFalse: [ parent printOn: aStream ]. >>>>>> aStream << name >>>>>> >>>>>> name: aString >>>>>> name := aString >>>>>> >>>>>> >>>>>> MFDirectory new name: 'comics'. >>>>>> >>>>>> >>>>>> And when I do >>>>>> >>>>>> >>>>>> (MFDirectory new name: 'comics') >>>>>> comics/ >>>>>> >>>>>> >>>>>> (MFDirectory new name: 'comics') printString >>>>>>>>> 'comics/' >>>>>> >>>>>> >>>>>> Hi Stef, >>>>>> >>>>>> I think I do not understand the issue. >>>>>> >>>>>> Here is the screenshot of a Playground. >>>>>> >>>>>> âcomicsâ -> print-it -> âcomics' >>>>>> >>>>>> <Mail Attachment.png> >>>>>> >>>>>> What am I missing? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>>> On Feb 18, 2017, at 6:26 PM, stepharong <stepharong(a)free.fr> wrote: >>>>>>> >>>>>>> >>>>>>> Hi guys >>>>>>> >>>>>>> I'm working on an introduction chapter for my future book and I do >>>>>>> not like the behavior I see in latest pharo 60. >>>>>>> >>>>>>> And I do not understand the behavior of print-it >>>>>>> >>>>>>> (MFDirectory new name: 'comics') >>>>>>> comics/ >>>>>>> >>>>>>> >>>>>>> (MFDirectory new name: 'comics') printString >>>>>>>>>> 'comics/' >>>>>>> >>>>>>> >>>>>>> Why print it does not produce ''? >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> printIt >>>>>>> "Treat the current text selection as an expression; evaluate it. >>>>>>> Insert the >>>>>>> description of the result of evaluation after the selection and >>>>>>> then make >>>>>>> this description the new text selection." >>>>>>> >>>>>>> | printString | >>>>>>> self >>>>>>> evaluateSelectionAndDo: [ :result | >>>>>>> printString := [ result printString ] >>>>>>> on: Error >>>>>>> do: [ '<error in printString: try ''Inspect it'' to debug>' ]. >>>>>>> self afterSelectionInsertAndSelect: printString ] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.feenk.com >>>>>> >>>>>> "It's not how it is, it is how we see it." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>>> <MFElement.st> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Problem solving should be focused on describing >>>>> the problem in a way that makes the solution obvious." >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> --Using Opera's mail client: http://www.opera.com/mail/ >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> > > > > --Using Opera's mail client: http://www.opera.com/mail/ -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by stepharong

Hi John > The tools aren't the ones putting the quotes around the string. Calling > #printString on a String puts the quotes around the string. If you were > to put quotes around other printString's then you would need to special > case String to not put the quotes around twice. I do not understand your printString point. to me printString contract is: return a string to represent the receiver (not talking about self evaluating objects here). so why when I have (MFDirectory new name: 'comics') printIt I do not get why I do not get 'comics' but comics since printIt invokes printString? Now I probably broke myself this contract when I introduced self-evaluating objects. true printIt >>> true is probably wrong. May be printIt is the wrong name. May be this is displayResult I do not know there is something confusing. I'm confuse ;( > The current implementation looks right to me. #printString returns a > string to help developers. #printString on some objects returns a string > that when evaluated creates an equivalent object (e.g., String, Point, > etc.). I did the self-evaluating behavior and I'm thinking that may be this is wrong and that we should always get a string not matter what happens. > However, on other objects it returns a string that only helps the > developer see what the object is (e.g., OrderedCollection). The trick is > to know which object's printString can be evaluated and which are only > for display. This is where I think that displayString is different than printString and that printString no matter what should be consitent I should return a string and the tools like the repl should display such as a string. This is also where > Of course, if you want a string that you can evaluate, you should use > #storeString. > > > John Brant > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by stepharong

Hi doru Yes I know. I did not imply anything. I think that the current status is bogus. I do not see any scenario that makes printString not returning and displaying a string good. I do not get why 'comics' printString should double quote it. to me 'comics' printString >>> 'comics' 'comics' printIt >>> 'comics' as well as (#AAA asClass new name: 'comics') PrintIt I just to not get what is the benefit not to have in the workspace or any users of printIt no single quote I agree that for a list of items you do not want to have 'astroboy' 'tintin' but instead astroboy tintin I see that lot of people got confused about that. Just look at the cuboid videos of Roassal you get comboboxes full of ' ' while there should not have any. Now to me this is the job of displayString. displayString is not the same as printString. printString should return a string and I should see a string in the REPL Currently in the REPL because this is what we are talking about obtaining a non string is confusing. Am I clear? Stef > Hi Stef, > > Just a clarification. I do not argue here. I just explain what I see. I > think it was like this since a long time. I even checked in an old VW I > have around and it seems to have the same behavior. > > But, I do agree that it is not straightforward at all. It took me a > while to figure this out and it is still confusing sometimes. In fact, > this is why we have a String presentation in the String object - I > >needed something that clarifies situations like these. That does not > mean it is the best solution :). > > >> On Feb 19, 2017, at 11:42 AM, stepharong <stepharong(a)free.fr> wrote: >> >> On Sun, 19 Feb 2017 11:40:04 +0100, Sven Van Caekenberghe >> <sven(a)stfx.eu> wrote: >> >>> Ah, you're right: there is a difference between printing a textual >>> representation on a stream / window and doing the same with the actual >>> (print)string. I was not yet >>>fully awake I guess. >> >> So >> 'comics' >> >>> comics whatever it means >> but >> (#AAA asClass new name: 'comics') >> >>> âcomics' > > Itâs the other way around :). > > Example A: > 'comics' > >>print it>> âcomicsâ In this case we have a string object and we send > printString to it which in String>>storeOn: adds the quotes as part of > the contents of the new string. > > Example B: > (#AAA asClass new name: 'comics') > >>print it>> comics Here we have an non-string object and we sent > printString to it which creates a string with the contents of the > stream. As no String>>storeOn: is invoked in this case, there are no > >quotes. > > So, the two resulting print it strings do not have the same contents. > > Maybe another case: > > Example C: > (#AAA asClass new name: 'comicsâ) printString > >>print it>> âcomicsâ > This is equivalent to Example A. We send printString to a string object > and we get the quotes. > > The issue is that when we send printString to a string, we produce a new > string with escaped quotes: > 'comics' = (String streamContents: [:s | s << 'comicsâ]) contents. > "true" > 'comics' = (String streamContents: [:s | s << 'comics']) contents > printString. "false" > > >> I'm sorry but I do not get it at all. >> Especially since we always wrote that printIt is sending printString. >> I find that totally broken and I do not understand why this is good. > > Another thing to keep in mind is: > > Example D: > Object new > >>print it>> an Object > This is essentially equivalent with Example A > > If Example B would produce >>print it>> âcomicsâ > it would mean that Example D would produce > >>print it>> âan Objectâ > > Ugh, I already got dizzy with so many quotes :). > > One problem is that when you look at a string, you do not know how many > String>>storeOn: commands it went through. So, here is an idea: what if > String>>printString would produce a >EscapedString, which behaves like > an operator? In this case, we would see better how many levels of > String>>storeOn: are being displayed. > > What do you think? > > Cheers, > Doru > > >> Stef >> >> >> >> >>> >>>> On 19 Feb 2017, at 10:59, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> Hmm, I think I do not see it :). >>>> >>>> Letâs take it slowly. From what I see, the behavior is the same since >>>> at least Pharo 3. >>>> >>>> Here is a script that seems to reproduce your situation: >>>> >>>> Object subclass: #AAA >>>> instanceVariableNames: 'name' >>>> classVariableNames: '' >>>> package: 'AAA'. >>>> #AAA asClass compile: 'printOn: aStream >>>> aStream << name'. >>>> #AAA asClass compile: 'name: aString >>>> name := aString'. >>>> #AAA asClass new name: 'comics' >>>> >>>> In Pharo 6, we have in a Playground: >>>> >>>> <Screen Shot 2017-02-19 at 10.48.55 AM.png> >>>> >>>> In Pharo 3, we have this in a Workspace: >>>> >>>> <Screen Shot 2017-02-19 at 10.49.26 AM.png> >>>> >>>> Calling Print It on an object produces a string out of the contents >>>> of the stream, and displaying it shows the contents of the stream >>>> (so, no quotes). >>>>Calling Print It on a string produces a string >>>> of the string, and displaying it shows the quotes of the first string. >>>> >>>> You can see this in the String tab of the inspector: >>>> >>>> <p1.png> >>>> >>>> >>>> <p2.png> >>>> >>>> Does this make sense? >>>> >>>> I think this is not inconsistent, but maybe there is a better way. In >>>> any case, the behavior seems to exist since a long time. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Feb 19, 2017, at 9:06 AM, stepharong <stepharong(a)free.fr> wrote: >>>>> >>>>> Hi doru >>>>> >>>>> may be I do not see the obvious. >>>>> I defined a class >>>>> >>>>> Object subclass: #MFElement >>>>> instanceVariableNames: 'name parent' >>>>> classVariableNames: '' >>>>> package: 'MyFS2' >>>>> >>>>> printOn: aStream >>>>> parent isNil ifFalse: [ parent printOn: aStream ]. >>>>> aStream << name >>>>> >>>>> name: aString >>>>> name := aString >>>>> >>>>> >>>>> MFDirectory new name: 'comics'. >>>>> >>>>> >>>>> And when I do >>>>> >>>>> >>>>> (MFDirectory new name: 'comics') >>>>> comics/ >>>>> >>>>> >>>>> (MFDirectory new name: 'comics') printString >>>>>>>> 'comics/' >>>>> >>>>> >>>>> Hi Stef, >>>>> >>>>> I think I do not understand the issue. >>>>> >>>>> Here is the screenshot of a Playground. >>>>> >>>>> âcomicsâ -> print-it -> âcomics' >>>>> >>>>> <Mail Attachment.png> >>>>> >>>>> What am I missing? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Feb 18, 2017, at 6:26 PM, stepharong <stepharong(a)free.fr> wrote: >>>>>> >>>>>> >>>>>> Hi guys >>>>>> >>>>>> I'm working on an introduction chapter for my future book and I do >>>>>> not like the behavior I see in latest pharo 60. >>>>>> >>>>>> And I do not understand the behavior of print-it >>>>>> >>>>>> (MFDirectory new name: 'comics') >>>>>> comics/ >>>>>> >>>>>> >>>>>> (MFDirectory new name: 'comics') printString >>>>>>>>> 'comics/' >>>>>> >>>>>> >>>>>> Why print it does not produce ''? >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> printIt >>>>>> "Treat the current text selection as an expression; evaluate it. >>>>>> Insert the >>>>>> description of the result of evaluation after the selection and >>>>>> then make >>>>>> this description the new text selection." >>>>>> >>>>>> | printString | >>>>>> self >>>>>> evaluateSelectionAndDo: [ :result | >>>>>> printString := [ result printString ] >>>>>> on: Error >>>>>> do: [ '<error in printString: try ''Inspect it'' to debug>' ]. >>>>>> self afterSelectionInsertAndSelect: printString ] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "It's not how it is, it is how we see it." >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>> <MFElement.st> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Problem solving should be focused on describing >>>> the problem in a way that makes the solution obvious." >>>> >>>> >>>> >>>> >>>> >>> >> >> >> --Using Opera's mail client: http://www.opera.com/mail/ > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by John Brant

On 02/19/2017 04:37 AM, stepharong wrote: > I do not say that it is a problem of playground. I'm saying that our > tools are breaking an important invariant. > Printit should not produce "strings" that are not objects. > > What I'm saying it that > - axiom one printString returns a string. > - printIt send printString to the object and why does it no > display a string > except for objects whose representation is themselves. > > The problem not to put '' around string is that we get a broken things. The tools aren't the ones putting the quotes around the string. Calling #printString on a String puts the quotes around the string. If you were to put quotes around other printString's then you would need to special case String to not put the quotes around twice. The current implementation looks right to me. #printString returns a string to help developers. #printString on some objects returns a string that when evaluated creates an equivalent object (e.g., String, Point, etc.). However, on other objects it returns a string that only helps the developer see what the object is (e.g., OrderedCollection). The trick is to know which object's printString can be evaluated and which are only for display. Of course, if you want a string that you can evaluate, you should use #storeString. John Brant

Feb. 19, 2017

Re: [Pharo-dev] confused about printString and printIt

by Tudor Girba

Hi Stef, Just a clarification. I do not argue here. I just explain what I see. I think it was like this since a long time. I even checked in an old VW I have around and it seems to have the same behavior. But, I do agree that it is not straightforward at all. It took me a while to figure this out and it is still confusing sometimes. In fact, this is why we have a String presentation in the String object - I needed something that clarifies situations like these. That does not mean it is the best solution :). > On Feb 19, 2017, at 11:42 AM, stepharong <stepharong(a)free.fr> wrote: > > On Sun, 19 Feb 2017 11:40:04 +0100, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Ah, you're right: there is a difference between printing a textual representation on a stream / window and doing the same with the actual (print)string. I was not yet fully awake I guess. > > So > 'comics' > >>> comics whatever it means > but > (#AAA asClass new name: 'comics') > >>> âcomics' Itâs the other way around :). Example A: 'comics' >>print it>> âcomicsâ In this case we have a string object and we send printString to it which in String>>storeOn: adds the quotes as part of the contents of the new string. Example B: (#AAA asClass new name: 'comics') >>print it>> comics Here we have an non-string object and we sent printString to it which creates a string with the contents of the stream. As no String>>storeOn: is invoked in this case, there are no quotes. So, the two resulting print it strings do not have the same contents. Maybe another case: Example C: (#AAA asClass new name: 'comicsâ) printString >>print it>> âcomicsâ This is equivalent to Example A. We send printString to a string object and we get the quotes. The issue is that when we send printString to a string, we produce a new string with escaped quotes: 'comics' = (String streamContents: [:s | s << 'comicsâ]) contents. "true" 'comics' = (String streamContents: [:s | s << 'comics']) contents printString. "false" > I'm sorry but I do not get it at all. > Especially since we always wrote that printIt is sending printString. > I find that totally broken and I do not understand why this is good. Another thing to keep in mind is: Example D: Object new >>print it>> an Object This is essentially equivalent with Example A If Example B would produce >>print it>> âcomicsâ it would mean that Example D would produce >>print it>> âan Objectâ Ugh, I already got dizzy with so many quotes :). One problem is that when you look at a string, you do not know how many String>>storeOn: commands it went through. So, here is an idea: what if String>>printString would produce a EscapedString, which behaves like an operator? In this case, we would see better how many levels of String>>storeOn: are being displayed. What do you think? Cheers, Doru > Stef > > > > >> >>> On 19 Feb 2017, at 10:59, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Hmm, I think I do not see it :). >>> >>> Letâs take it slowly. From what I see, the behavior is the same since at least Pharo 3. >>> >>> Here is a script that seems to reproduce your situation: >>> >>> Object subclass: #AAA >>> instanceVariableNames: 'name' >>> classVariableNames: '' >>> package: 'AAA'. >>> #AAA asClass compile: 'printOn: aStream >>> aStream << name'. >>> #AAA asClass compile: 'name: aString >>> name := aString'. >>> #AAA asClass new name: 'comics' >>> >>> In Pharo 6, we have in a Playground: >>> >>> <Screen Shot 2017-02-19 at 10.48.55 AM.png> >>> >>> In Pharo 3, we have this in a Workspace: >>> >>> <Screen Shot 2017-02-19 at 10.49.26 AM.png> >>> >>> Calling Print It on an object produces a string out of the contents of the stream, and displaying it shows the contents of the stream (so, no quotes). Calling Print It on a string produces a string of the string, and displaying it shows the quotes of the first string. >>> >>> You can see this in the String tab of the inspector: >>> >>> <p1.png> >>> >>> >>> <p2.png> >>> >>> Does this make sense? >>> >>> I think this is not inconsistent, but maybe there is a better way. In any case, the behavior seems to exist since a long time. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Feb 19, 2017, at 9:06 AM, stepharong <stepharong(a)free.fr> wrote: >>>> >>>> Hi doru >>>> >>>> may be I do not see the obvious. >>>> I defined a class >>>> >>>> Object subclass: #MFElement >>>> instanceVariableNames: 'name parent' >>>> classVariableNames: '' >>>> package: 'MyFS2' >>>> >>>> printOn: aStream >>>> parent isNil ifFalse: [ parent printOn: aStream ]. >>>> aStream << name >>>> >>>> name: aString >>>> name := aString >>>> >>>> >>>> MFDirectory new name: 'comics'. >>>> >>>> >>>> And when I do >>>> >>>> >>>> (MFDirectory new name: 'comics') >>>> comics/ >>>> >>>> >>>> (MFDirectory new name: 'comics') printString >>>>>>> 'comics/' >>>> >>>> >>>> Hi Stef, >>>> >>>> I think I do not understand the issue. >>>> >>>> Here is the screenshot of a Playground. >>>> >>>> âcomicsâ -> print-it -> âcomics' >>>> >>>> <Mail Attachment.png> >>>> >>>> What am I missing? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Feb 18, 2017, at 6:26 PM, stepharong <stepharong(a)free.fr> wrote: >>>>> >>>>> >>>>> Hi guys >>>>> >>>>> I'm working on an introduction chapter for my future book and I do not like the behavior I see in latest pharo 60. >>>>> >>>>> And I do not understand the behavior of print-it >>>>> >>>>> (MFDirectory new name: 'comics') >>>>> comics/ >>>>> >>>>> >>>>> (MFDirectory new name: 'comics') printString >>>>>>>> 'comics/' >>>>> >>>>> >>>>> Why print it does not produce ''? >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> printIt >>>>> "Treat the current text selection as an expression; evaluate it. Insert the >>>>> description of the result of evaluation after the selection and then make >>>>> this description the new text selection." >>>>> >>>>> | printString | >>>>> self >>>>> evaluateSelectionAndDo: [ :result | >>>>> printString := [ result printString ] >>>>> on: Error >>>>> do: [ '<error in printString: try ''Inspect it'' to debug>' ]. >>>>> self afterSelectionInsertAndSelect: printString ] >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "It's not how it is, it is how we see it." >>>> >>>> >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>>> <MFElement.st> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving should be focused on describing >>> the problem in a way that makes the solution obvious." >>> >>> >>> >>> >>> >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Feb. 19, 2017

Development dashboard for pharo-project repositories

by Rafael Luque

Hi guys! I've just created a development analytics dashboard for the pharo-project organization at GitHub using Cauldron [1], a proof-of-concept by Bitergia, a University spin-off here in Madrid. You can play with the dashboard at: https://cauldron.io/ dashboards/pharo-project I expect you enjoy it and get insights about the Pharo community. [1] https://cauldron.io/ -- Rafael Luque

Feb. 19, 2017