June 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Environments

by ducasse

pay attention Spec2 is in pharo-spec/ and it is regularly updated in P8 alpha. We will start to work on the book We should push Commander2 and start to use it systematically. https://github.com/SquareBracketAssociates/BuildingApplicationWithSpec2 Pavel is moving back to Prague but he can tell you what is doing to port code from VW. I think that the namespace are not the main problem. We are working on Modules for Pharo now this is tricky and it can impact the complete system. Adding environment is only a tiny part of the problem. > No, I missed it. Thanks for that. > > I have a lot of algorithmic meat in domain classes. Those are easy to port, even if I must manually trip over the minor VW/Pharo differences, and fix them as I come to them, or just run my own VW script to do mass edits on file-outs. I donât mind this part of the conversion much, and it would cover most of what I have port. > > I have some special GUIs (2D and 3D) that I need to recode anyway, probably in Spec and Woden. The 3D stuff is now done in Jun OpenGL, which has seen its day, and I suppose wonât be updated to use the OGL shader model. The last update for VW, I think, is from 2015. Iâve had enough of Jun anyway, and would prefer to use Woden in Pharo, or port it to VW, and work on in there. But the GUIs in recent years are not the big issue. The domain objects are. > > Mostly, I value reading efficiency. We spend most of our time reading programs so that we can determine how to write some change or new feature without breakage or incongruity. I value reading at high rates and with high comprehension, small methods, and rigidly controlled naming conventions. The ultimate aim is to have the machine reason about my code, with the same or greater grammatical and semantic awareness. This happens now only at a superficial level with classes, methods, and referential, slot-based integrity checks. Iâm happy they are there, but they are not nearly enough to make humans extremely productive and powerful at shaping machine behaviors. I think we are overworked and that our machines are hardly being used. There is a science to increasing reading speed and comprehension in a programming context (and getting the machine to help you in the domain layer), and you canât use that science very well with speed bumps at the beginnings of all the class names. Therefore, I very much value naming classes exactly as I need. Even this is an interim approach. If things go well, classes and methods will go away in the future, but I digress from the near-term task. > > I saw the bit near the end of the slides about Spec2. Does this really use GTK to make native GUIs, and does this mean we can have real OS windows on Windows? I miss Alt-Tab-ing for navigating through windows, and would like to see it in the Pharo, but that canât happen without OS windows. Any Windows Pharo users miss Alt-tab-ing? > > Can Spec2 be tested in Pharo8 now? > > Please point me to the best resources on Spec2. It looks very interesting. I found these: > > https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ <https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/> > > â > And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately <image001.png> > Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 â independently of Gtk3 > â > > https://github.com/dionisiydk/Spec2 <https://github.com/dionisiydk/Spec2> > > I donât see Spec2 in Pharo 8. I suppose I need to load it. No it is directly in. > Is the Spec book still relevant? Not fully we will start to port the book. > Is Spec2 mostly about the back-end changes for use of GTK? No it is a massive change. - Introducing new layouts (deprecated the interpreter design) - soon using Commander2 for menus and the rest - many many cleans - Introduction of application and more. > > Shaping > > > On 2 Jun 2019, at 12:12, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org>> wrote: > > > > > > > > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. > > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. > > its something that is wanted, but priorities have taken precedence. > > A bit work being done in the background should support namespaces when there are resources to "get it right" ... > > http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t…> > > > > For the moment, best best is a few tips on converting from namespaces. > > http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> > > > > Thanks for the links. > > > > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. > > > > I can learn to deal with Iceberg. > > > > > > Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Ben Coman

On Sun, 2 Jun 2019 at 21:24, Shaping <shaping(a)uurda.org> wrote: > > https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ > > And thatâs it. Pharo 8.0 will come with Spec 2.0 and users will be able to > benefit of it immediately [image: ð] > > Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the > people that need it. We will also release Spec20 soon so that people can > try Spec 20 â independently of Gtk3 > > â > > > > https://github.com/dionisiydk/Spec2 > > > > I donât see Spec2 in Pharo 8. I suppose I need to load it. > > > > Is the Spec book still relevant? Is Spec2 mostly about the back-end > changes for use of GTK? > > > This may interest you... https://www.slideshare.net/pharoproject/spec-20-the-next-step-on-desktop-ui cheers -ben

June 2, 2019

Re: [Pharo-dev] Environments

by Shaping

Did you see the following presentation (about a VW to Pharo port): Apart Framework: Porting from VisualWorks <https://www.slideshare.net/pharoproject/apart-framework-porting-from-visual works> https://www.slideshare.net/pharoproject/apart-framework-porting-from-visualw orks <http://files.pharo.org/conferences/2019PharoDays/07%20aPart.pdf> http://files.pharo.org/conferences/2019PharoDays/07%20aPart.pdf ? No, I missed it. Thanks for that. I have a lot of algorithmic meat in domain classes. Those are easy to port, even if I must manually trip over the minor VW/Pharo differences, and fix them as I come to them, or just run my own VW script to do mass edits on file-outs. I don't mind this part of the conversion much, and it would cover most of what I have port. I have some special GUIs (2D and 3D) that I need to recode anyway, probably in Spec and Woden. The 3D stuff is now done in Jun OpenGL, which has seen its day, and I suppose won't be updated to use the OGL shader model. The last update for VW, I think, is from 2015. I've had enough of Jun anyway, and would prefer to use Woden in Pharo, or port it to VW, and work on in there. But the GUIs in recent years are not the big issue. The domain objects are. Mostly, I value reading efficiency. We spend most of our time reading programs so that we can determine how to write some change or new feature without breakage or incongruity. I value reading at high rates and with high comprehension, small methods, and rigidly controlled naming conventions. The ultimate aim is to have the machine reason about my code, with the same or greater grammatical and semantic awareness. This happens now only at a superficial level with classes, methods, and referential, slot-based integrity checks. I'm happy they are there, but they are not nearly enough to make humans extremely productive and powerful at shaping machine behaviors. I think we are overworked and that our machines are hardly being used. There is a science to increasing reading speed and comprehension in a programming context (and getting the machine to help you in the domain layer), and you can't use that science very well with speed bumps at the beginnings of all the class names. Therefore, I very much value naming classes exactly as I need. Even this is an interim approach. If things go well, classes and methods will go away in the future, but I digress from the near-term task. I saw the bit near the end of the slides about Spec2. Does this really use GTK to make native GUIs, and does this mean we can have real OS windows on Windows? I miss Alt-Tab-ing for navigating through windows, and would like to see it in the Pharo, but that can't happen without OS windows. Any Windows Pharo users miss Alt-tab-ing? Can Spec2 be tested in Pharo8 now? Please point me to the best resources on Spec2. It looks very interesting. I found these: https://pharoweekly.wordpress.com/2019/04/18/pre-ann-spec-2-0-gtk3-bindings/ " And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 - independently of Gtk3 " https://github.com/dionisiydk/Spec2 I don't see Spec2 in Pharo 8. I suppose I need to load it. Is the Spec book still relevant? Is Spec2 mostly about the back-end changes for use of GTK? Shaping > On 2 Jun 2019, at 12:12, Shaping < <mailto:shaping@uurda.org> shaping(a)uurda.org> wrote: > > > > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. > its something that is wanted, but priorities have taken precedence. > A bit work being done in the background should support namespaces when there are resources to "get it right" ... > <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t p4983800p4990734.html> http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-tp 4983800p4990734.html > > For the moment, best best is a few tips on converting from namespaces. > <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 > > Thanks for the links. > > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. > > I can learn to deal with Iceberg. > > > Shaping

June 2, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by Alistair Grant

Hi Ben, On Fri, 31 May 2019 at 07:08, Ben Coman <btc(a)openinworld.com> wrote: > > > I'm on Windows wanting to write a text file with LF endings. > The code developed on Linux is thus... > (destinationDirectory / 'README.md') ensureCreateFile > writeStreamDo: [ :stream | stream nextPutAll: class comment ] I've come across this so many times that I always add a couple of methods to my image: ZnEncodedStream>>asNewLineStream "Answer the receiver wrapped with a ZnNewLineWriterStream" ^ZnNewLineWriterStream on: self! ! ZnNewLineWriterStream>>asNewLineStream "Answer the receiver wrapped with a ZnNewLineWriterStream" ^self! ! You could then modify the example above to be: stream asNewLineStream forLf nextPutAll: class comment Cheers, Alistair > and I am stuck with CR line endings. > The specific symptom is that it screws `git diff` > Here is a simple experiment... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' ]. > testfile binaryReadStream contents at: 3 "==> Character cr " > > I think its safe to assume on Linux that will result in "==> Character lf " > but can someone please confirm? > > So my issue is that I've got > #ensureCreateFile - returns a FileReference > and > :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. > > and neither seem to have an easily accessible defaultLineEnding setting. > Indeed, line endings are not a property of FileReference > and Binary & Characters have nothing to do with line endings, > and questionable if Buffering is related. > > Its more a property of a File, but IIUC that is being deprecated (??) > > MultiByteFileStream has #lineEndConvention: > but IIUC that also is being deprecated. > > So what is the proper way to force default line endings? > > > ------ > Now while composing this email I discovered String>>withUnixLineEndings. > So I have a solution... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' withUnixLineEndings ]. > (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " > > but that seems to imply that on Windows... > 'aa > bb' at: 3 "==> Character cr " > > and on Linux (someone please confirm)... > 'aa > bb' at: 3 "==> Character lf " > > and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, > but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :)

June 2, 2019

automatic field-size adjustment to font-change not working on window open

by Shaping

Sorry, I spoke to soon. There are still reformatting problems when reopening the windows after a font change, say, the Settings window. If you choose, for example Fira Code 11 and Force All across all categories of use, you'll see the following in one stretch of Settings, which shows truncated labels under QualityAssistant. The rest of Settings has similar problems. Can this truncated-label problem be corrected now without waiting for Spec? I would think that the problem is caused by not having the internal reformatting ability already there in all GUIs or by not making a system-wide announcement to all GUIs when a font is changed, so that the resize/reformat can be triggered. Note that field-resizings are not happening even on reopen. Can someone fill me in on the problem and the anticipated fix and ETA? Shaping From: Shaping [mailto:shaping@uurda.org] Sent: Sunday, June 2, 2019 02:44 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] automatic field-size adjustment to font-change Shaping1 wrote > that Pharo labels are truncated if you switch to a monospace font Did you try doing this before opening any windows? There is a problem that sometimes already-open tools are not properly updated when the font is changed... Yes, that's the problem. All windows open before the font-change must be re-opened. The font does visibly change before the reopening, but the field-size adjustment needed to see all the text does not happen until after reopening. Will Spec fix this? Thanks. Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Sven Van Caekenberghe

Did you see the following presentation (about a VW to Pharo port): Apart Framework: Porting from VisualWorks https://www.slideshare.net/pharoproject/apart-framework-porting-from-visual… http://files.pharo.org/conferences/2019PharoDays/07%20aPart.pdf ? > On 2 Jun 2019, at 12:12, Shaping <shaping(a)uurda.org> wrote: > > > > I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. > The little I know about the topic is that its complicated since it can introduce as many problems as it solves. > its something that is wanted, but priorities have taken precedence. > A bit work being done in the background should support namespaces when there are resources to "get it right" ... > http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… > > For the moment, best best is a few tips on converting from namespaces. > http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 > > Thanks for the links. > > Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. > > I can learn to deal with Iceberg. > > > Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Shaping

I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. The little I know about the topic is that its complicated since it can introduce as many problems as it solves. its something that is wanted, but priorities have taken precedence. A bit work being done in the background should support namespaces when there are resources to "get it right" ... <http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t…> http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… For the moment, best best is a few tips on converting from namespaces. <http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334> http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 Thanks for the links. Not having a quick and easy way to create namespaces in Pharo to ease porting of VW code is my main impediment. If Pharo namespaces existed, I would just deal with all the other problems, and push on, instead of using them to justify returning to VW. I can learn to deal with Iceberg. Shaping

June 2, 2019

automatic field-size adjustment to font-change

by Shaping

Shaping1 wrote > that Pharo labels are truncated if you switch to a monospace font Did you try doing this before opening any windows? There is a problem that sometimes already-open tools are not properly updated when the font is changed... Yes, that's the problem. All windows open before the font-change must be re-opened. The font does visibly change before the reopening, but the field-size adjustment needed to see all the text does not happen until after reopening. Will Spec fix this? Thanks. Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Ben Coman

On Sun, 2 Jun 2019 at 07:01, Shaping <shaping(a)uurda.org> wrote: > > Does anyone have experience with Squeak Environments? This came up in the Cuis list. Environments are Squeakâs attempt at a module or namespace system. Does this exist for Pharo? Has anyone worked with it, and found it to be usable? I'm fairly sure Environments hasn't been ported to Pharo. Namespacing is still on open question on Pharo. The little I know about the topic is that its complicated since it can introduce as many problems as it solves. its something that is wanted, but priorities have taken precedence. A bit work being done in the background should support namespaces when there are resources to "get it right" ... http://forum.world.st/Namespaces-was-Re-Behold-Pharo-The-Modern-Smalltalk-t… For the moment, best best is a few tips on converting from namespaces. http://forum.world.st/Migration-from-VW-to-Pharo-td5098328.html#a5098334 cheers -ben

June 2, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Sean P. DeNigris

Shaping1 wrote > that Pharo labels are truncated if you switch to a monospace font Did you try doing this before opening any windows? There is a problem that sometimes already-open tools are not properly updated when the font is changed... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 2, 2019