March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Round 4 Results Are In

by tbrunz

Hi Richard, I think this revelation points to another important impact that your competition can have on spreading the use of Pharo in the community -- beyond the obvious one of raising awareness. You now have a golden opportunity to collect valuable inputs from a large group who are getting starting with Pharo. They have a unique perspective regarding the language & IDE learning process. What helped them learn? What hindered them? What resources were useful, and why? How did their impressions of Pharo change from when they were first introduced to the language/IDE? What suggestions do they have for other newcomers? Your one group found the class library intractable... That's probably not surprising; I tell those I'm introducing to Smalltalk that the hardest part of learning any OOP language is learning the foundation class library (as this is what you will build your code on top of). And of course it's intimidating. I try to reassure them by pointing out that the developers of Smalltalk realized this and have been contributing and improving tools specifically designed to help programmers find the classes & methods they need. Which then leads to demonstrations of those tools. Written documentation should help, of course, but what kind? The class comment type of documentation (much like Linux man pages) works well as a reference and clarification for those already somewhat familiar with the classes and their uses. Does it work well for those unfamiliar with the language? Are they sufficiently easy to find? The GNU Smalltalk reference addresses this by grouping them together into one document. Perhaps some automation to extract these from Pharo and group/title them would be a way to start? (Better: Have an application that can "go both directions" so that edits to either set of docs can be used to update the other. Think how important a tool that would be!) How to improve on class comments as a means of learning (besides just writing more class comments)? The Pharo booklet series are a *big* help, as are tutorials such as the MOOC. Personally, I like to study examples of well-written code to learn techniques, style, and structure. Pharo complicates this, however, due to the fact that the language and IDE are intertwined. It's also complicated because you don't have the typical "synoptic view" that most text-based languages provide. And there's more to learn than just language syntax (which is "the easy part"); my point about how to find resources is an example of this. In a way, we need Pharo booklets on subjects such as "How to use the Pharo toolset to find classes you need", "Techniques for structuring & expressing common operations in Pharo", etc. I'm thinking that your groups could help with identifying where the cognitive stumbling blocks are and inspire thinking about how best to address them. After all, your contestants currently are experts on the subject of learning Pharo and applying it to solve a real-world problem for the first time. They're acutely aware of what helped & what hindered. We need to target the problem areas to make things easier for those coming after. I don't think it's as simple as "write more documentation"; the question is "which kind of documentation" and "what types of learning tools" will help most? I'm very curious to see the "robot mind" code, so I hope some of them get published. (That will serve another purpose, by indicating how those who are new to Smalltalk reason with its syntax and semantics for the first time.) It will be helpful to see the code for the "Organizer", too. Not so that we can duplicate it, but to help us with learning how to architect applications like these. The game itself can be a learning tool for more than just the students in the competition! Thanks, -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 1, 2020

[pharo8-api-change] GLMCompositePresentation did not understand #wrapper

by Hilaire

Hi, GLMCompositePresentation does not understand #wrapper anymore in P8 (valid in P7). More, the class GLMWrapper vanished (present in P7). In DrGeo a custom script browser is build to edit script, in this browser when clicking on a script there is now this error. I tool a look to the I don't understand much this framework. How should the code bellow be rewritten to work on P8? |methodsIn: composite Â composite /*wrapper*/ title: 'Methods' translated; Â show: [ :wrapper | Â Â wrapper fastList Â Â Â display: [ :aClass | aClass methods collect: [ :m | m asRingDefinition ]]; Â Â Â format: [ :aCompiledMethod | aCompiledMethod selector asString ] ]. Â composite /*wrapper*/ title: 'Script data' translated; Â show: [ :wrapper | Â Â wrapper fastList Â Â Â display: [ :aClass | aClass class methods collect: [ :m | m asRingDefinition ]]; Â Â Â format: [ :aCompiledMethod | aCompiledMethod selector asString ] ]. Â composite Â updateOn: MethodModified from: [ SystemAnnouncer uniqueInstance ]; Â updateOn: MethodAdded from: [ SystemAnnouncer uniqueInstance ]. Â composite onChangeOfPort: #activePresentation act: [ :presentation | Â (presentation pane port: #activePresentation) value ifNotNil: [ :activePresentation | Â Â ((browser paneNamed: #methods) port: #selection) value: (activePresentation /*defaultPane*/ port: #selection) value ] ]. | | | -- Dr. Geo http://drgeo.eu

March 1, 2020

Re: [Pharo-users] [pharo8-api-change] newTextEditor

by Hilaire

Ok, never mind I figure out. Announcement framework is neat. They were a couple of errors with the Rub** related to the change of #contents to #text message, which is more meaningful. Le 01/03/2020 Ã 11:44, Hilaire a Ã©critÂ : > *Question.* > > In RubPluggableTextMorph why the access to the announcer instance is > different in this two methods (quoted message of mine below) > > Am I missing something? -- Dr. Geo http://drgeo.eu

March 1, 2020

Re: [Pharo-users] [pharo8-api-change] newTextEditor

by Hilaire

*Question.* In RubPluggableTextMorph why the access to the announcer instance is different in this two methods (quoted message of mine below) *self textArea announcer* ... and in the other place *self announcer* ... >From my understanding the former is the announcer attached as a property of the text area morph and the later the announcer attached to the RubPluggableTextMorph. Am I missing something? Hilaire Le 29/02/2020 Ã 20:00, Hilaire a Ã©critÂ : > For the latter how should it be rewritten? > > I read these > > self textArea announcer when: RubTextChanged send: > #whenTextChangedInTextArea: to: self. > > and > > whenTextChangedInTextArea: anAnnouncement > Â Â Â self announcer announce: anAnnouncement -- Dr. Geo http://drgeo.eu

March 1, 2020

Re: [Pharo-users] [ANN] COVID-19 analysis in Pharo

by Tomohiro Oda

HernÃ¡n, ððð --- tomo 2020å¹´3æ1æ¥(æ¥) 16:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > Hello, > > I have set up a new Pharo project for the analysis of COVID-19 outbreak: > > https://github.com/hernanmd/COVID-2019 > > Thanks to the ObjectProfile for Roassal and PolyMath contributors for the DataFrame package. > > Cheers, > > HernÃ¡n >

March 1, 2020

[ANN] COVID-19 analysis in Pharo

by HernÃ¡n Morales Durand

Hello, I have set up a new Pharo project for the analysis of COVID-19 outbreak: https://github.com/hernanmd/COVID-2019 Thanks to the ObjectProfile for Roassal and PolyMath contributors for the DataFrame package. Cheers, HernÃ¡n

March 1, 2020