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

Re: [Pharo-users] Using Icerberg programmatically.

by Guillermo Polito

Hi Arturo, First, I would not recommend too much to use the version on Pharo 6.1. That version is a preview version that is >6 months older than the new one in Pharo 7. This does not mean you cannot write a script, but we do not guarantee it will work in more recent version :). If you then settle for the version on Pharo7, something you have to also care about is that while most of the basic API is stable enough, some others will evolve in the near future. There are many missing features, and we are trying to keep it as simple as possible so it can easily evolve... Just a note about what you want to do: Be careful with programmatic pulling. A pull is a fetch + a merge. If you did not commit in your branch, the merge will be a simple fast-forward and you will have no further problems. But if you did commit, you will have a merge, with potentially conflicts. And conflicts have so far to be manually resolved. Guille On Wed, Jul 25, 2018 at 9:51 AM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi Arthur, > > The starting point is the IceRepository. > You can build you own repository with IceRepositoryCreator or get an > existing one from IceRepository registry. > Then on the repository you can call #pull. > > Christophe > > > Le 24 juil. 2018 Ã 20:09, Arturo Zambrano <arturo.zambrano(a)gmail.com> a > Ã©crit : > > > > Hi All, > > the new Iceberg is really cool. I'm using it in Pharo 6.1. > > > > Is there some documentation or script examples on how to use Iceberg > programmatically? I would like to write an script to pull changes to an > existing repository, before doing some other stuff. I can do it with the > UI, but I would like to automatize it. Any pointer is welcome. > > > > Thanks in advance. > > Arturo > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 25, 2018

Re: [Pharo-users] Using Icerberg programmatically.

by Christophe Demarey

Hi Arthur, The starting point is the IceRepository. You can build you own repository with IceRepositoryCreator or get an existing one from IceRepository registry. Then on the repository you can call #pull. Christophe > Le 24 juil. 2018 Ã 20:09, Arturo Zambrano <arturo.zambrano(a)gmail.com> a Ã©crit : > > Hi All, > the new Iceberg is really cool. I'm using it in Pharo 6.1. > > Is there some documentation or script examples on how to use Iceberg programmatically? I would like to write an script to pull changes to an existing repository, before doing some other stuff. I can do it with the UI, but I would like to automatize it. Any pointer is welcome. > > Thanks in advance. > Arturo

July 25, 2018

Re: [Pharo-users] [ANN] Cryptography package on github

by Norbert Hartl

> Am 23.07.2018 um 20:40 schrieb Paul DeBruicker <pdebruic(a)gmail.com>: > > Hi Norbert, > > > I'm glad you're doing this. You might post this announcement to the > Cryptography list: > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography > & Squeak Dev. > > > And Dale Henrich did a port to GemStone here: > https://github.com/gsdevkit/cryptography > > But I'm not sure if he did any structural changes to the packaging. > Ay ay sir! Wrote to cryptography list and Dale. Norbert > > > > > NorbertHartl wrote >> After several attempts to solve the Cryptography package problems over the >> years I decided to move it on my own to github. >> >> What I did: >> >> - researched all authors and used the git migration tool to get the >> package from smalltalkhub to github >> - released a version 0.1 that should be exactly the same as the code on >> smalltalkhub for people that want to change >> - fixed an occurrence of IfNotNilDo: in the Cryptography package to make >> it load in pharo7 >> - added a metacello baseline >> - added a group âall" that loads everything like it is now with one >> package >> - added travis files and enable travis checks for pull requests >> - released a version 0.2 that contains the original code plus travis and >> metacello >> - Started to cut off the ASN1, PKCS12 and X509 classes in separate >> packages >> - Added to each new package a -Tests package containing tests >> - constructed all dependencies in the baseline >> - added a core group that loads the now slimmed down package solely >> >> I must say this was really great with the help of promote-demote package >> tag functionality and the dependency browser. The only thing missing is >> kind of a tool to construct the metacello baseline. I miss Versionner >> here. >> >> What I didnât do: >> >> - checking all the other packages in the repo. There are packages with old >> style ffi calls and things that seem to be squeak dependent. >> >> I hope with the time and peopleâs complaints we can figure out what is >> obsolete and what needs to be adjusted. >> >> The repository is now at >> >> https://github.com/zweidenker/Cryptography >> <https://github.com/zweidenker/Cryptography> >> >> but Iâm happy to move it to a better place if someone has an idea. >> >> Pull requests and tickets are welcome. >> >> Hope you like it, >> >> Norbert > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 24, 2018

Using Icerberg programmatically.

by Arturo Zambrano

Hi All, the new Iceberg is really cool. I'm using it in Pharo 6.1. Is there some documentation or script examples on how to use Iceberg programmatically? I would like to write an script to pull changes to an existing repository, before doing some other stuff. I can do it with the UI, but I would like to automatize it. Any pointer is welcome. Thanks in advance. Arturo

July 24, 2018

Cyclomatic complexity for Smalltalk

by Julien

Hello, I need to compute the cyclomatic complexity of Pharo methods. There is a tool to do that in Moose but its implementation is quite unreliable since it explicitly lists the branching selectors and loop selectors. Even the comment in the method says the implementation is wrong. The problem is that in Smalltalk, potentially any selector can branch or perform loop. And you can not know it in advance. Anyone here already tried to address this problem? Thanks in advance, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

July 24, 2018

Re: [Pharo-users] [Pharo-dev] fixing font aliasing/sizing for a specific font

by Sven Van Caekenberghe

> On 24 Jul 2018, at 11:30, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi Peter, > > Thanks for the question and motivation to do a text rendering quality comparison. > > I think you forgot that Pharo does not support "retina" or "hi-dpi" displays. Imagine you have a laptop screen with the resolution of (3840x2160). Pixels are so small, that UI gets almost unreadable. Therefore OS has to scale the whole interface with for example scale factor 2 (can be changed in settings). Interesting is that now programs think the resolution is 1920x1080. Pharo thinks same too, so it renders the whole UI in 1080p and then it gets upscaled to 4K which results in the blurry interface. > > Programs have to support "hi-dpi" screens explicitly. Bloc for example, when opened in SDL2 native window supports retina screens and delivers very beautiful graphics. > The process is quite simple: SDL2 windows provide two types of extent: > â¢ window extent - scaled window size in dp (in our example it would be 1080p) > â¢ canvas extent - real canvas size in px (in our example it would be 4K) > we can get scale factor by dividing canvas extent / window extent. Next we create a Bloc canvas of size equal to window canvas extent (4K) provided by SDL2 and scale the whole graphic scene by previously computed scale factor 2 while actually rendering everything in window extent coordinates (1080p). It can be easily done since Bloc is vector graphics. I would like to emphasise that everything in bloc is based on dp and not px. > > 1dp = 1px * scaling factor. > > Coming back to the text rendering issue :) > The correct experiment would be to take a non-retina monitor and do the comparison, then take a retina monitor and repeat the same comparison process making sure that all tested programs have support of retina screens. This way we compare Bloc with web browsers in the same environment. > > Below are the results: > > (non-retina) > <Text Rendering Non-Retina.png> > > (retina) > <Text Rendering Retina.png> > > When zoomed-in (download pictures, they are .png) we can see that the text rendering quality in Bloc is as good as in other modern web-browsers. Indeed, there are very minor differences between all of them, but perceived quality is on the same level, especially in "retina" case. Looks really impressive! > P.S. Compared on OSX with Arial font. > > Cheers, > Alex > > On 24 July 2018 at 10:09, Ben Coman <btc(a)openinworld.com> wrote: > > > On 24 July 2018 at 15:07, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > I'm trying to understand how exactly Pharo renders fonts and aliases them. > > I want to use Segoe UI (which is the default Windows 10 font for UI), however when rendered in Pharo it is blurry, and for size 9 and light hinting it actually produces incorrect size. > > Here is a comparsion (100%) > > <image.png> > and 300% > > <image.png> > > You can see how blurry and bold the fonts are compared to MS word/Chrome/Firefox. Even Bloc should use the same rendering engine as Firefox, but seems to suffer from the same^1. > (Note that fonts size 7 and 8 is ok... the font starts at size 8.) > > I've tried digging through the settings and FreeTypeSettings methods, but couldn't find anything that would help me fix this. > > Any pointers appreciated. > > Thanks, > Peter > > ^1 Note for Bloc: I couldn't figure out how to specify the font size in points instead of pixels, so maybe that's why it is much more compact horizontally. > > Could you clarify... are "light" "normal" "full" and "none" done through Morphic without Bloc ? > > Are you on a high-dpi screen? I'm not very familiar with this, but you could try experimenting... > http://windows10_dpi_blurry_fix.xpexplorer.com/ > https://www.howtogeek.com/175664/how-to-make-the-windows-desktop-work-well-… > > cheers -ben >

July 24, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Alistair Grant

On Tue., 24 Jul. 2018, 10:13 Sven Van Caekenberghe, <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Stdio stdout and friends just return a binary stream, hence they need > wrapping for encoding. > > > > Maybe > > > > Stdio stdoutAsText > > > > might be an idea, but this is so uncommon that I am not sure this is a > good idea. > > Given all remarks and comments (thanks BTW), I now think that > > - textual stdio streams are the more common case > - binary stdio streams are the primitive ones that are seldom used > - another encoding than UTF-8 seems uncommon > - these are streams that exist and need no real opening/closing > > So, > > Stdio stdout > > should return return a character write stream with UTF-8 encoding while > > Stdio binaryStdout > > should be the lower level binary one. > This would be more in line with the other streams. > A non-UTF-8 encoding can be used as per Pavel's example. > +1 I didn't suggest this earlier because it isn't backward compatible. But I do think it is the better solution. Cheers, Alistair (on phone)

July 24, 2018

Re: [Pharo-users] [Pharo-dev] fixing font aliasing/sizing for a specific font

by Aliaksei Syrel

Hi Peter, Thanks for the question and motivation to do a text rendering quality comparison. I think you forgot that Pharo does not support "retina" or "hi-dpi" displays. Imagine you have a laptop screen with the resolution of (3840x2160). Pixels are so small, that UI gets almost unreadable. Therefore OS has to scale the whole interface with for example scale factor 2 (can be changed in settings). Interesting is that now programs think the resolution is 1920x1080. Pharo thinks same too, so it renders the whole UI in 1080p and then it gets upscaled to 4K which results in the blurry interface. Programs have to support "hi-dpi" screens explicitly. Bloc for example, when opened in SDL2 native window supports retina screens and delivers very beautiful graphics. The process is quite simple: SDL2 windows provide two types of extent: - window extent - scaled window size in dp (in our example it would be 1080p) - canvas extent - real canvas size in px (in our example it would be 4K) we can get scale factor by dividing canvas extent / window extent. Next we create a Bloc canvas of size equal to window canvas extent (4K) provided by SDL2 and scale the whole graphic scene by previously computed scale factor 2 while actually rendering everything in window extent coordinates (1080p). It can be easily done since Bloc is vector graphics. I would like to emphasise that everything in bloc is based on dp and not px. 1dp = 1px * scaling factor. Coming back to the text rendering issue :) The correct experiment would be to take a non-retina monitor and do the comparison, then take a retina monitor and repeat the same comparison process making sure that all tested programs have support of retina screens. This way we compare Bloc with web browsers in the same environment. Below are the results: *(non-retina)* *(retina)* When zoomed-in (download pictures, they are .png) we can see that the text rendering quality in Bloc is as good as in other modern web-browsers. Indeed, there are very minor differences between all of them, but perceived quality is on the same level, especially in "retina" case. P.S. Compared on OSX with *Arial* font. Cheers, Alex On 24 July 2018 at 10:09, Ben Coman <btc(a)openinworld.com> wrote: > > > On 24 July 2018 at 15:07, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> I'm trying to understand how exactly Pharo renders fonts and aliases them. >> >> I want to use Segoe UI (which is the default Windows 10 font for UI), >> however when rendered in Pharo it is blurry, and for size 9 and light >> hinting it actually produces incorrect size. >> >> Here is a comparsion (100%) >> >> >> and 300% >> >> >> >> You can see how blurry and bold the fonts are compared to MS >> word/Chrome/Firefox. Even Bloc should use the same rendering engine as >> Firefox, but seems to suffer from the same^1. >> (Note that fonts size 7 and 8 is ok... the font starts at size 8.) >> >> I've tried digging through the settings and FreeTypeSettings methods, but >> couldn't find anything that would help me fix this. >> >> Any pointers appreciated. >> >> Thanks, >> Peter >> >> ^1 Note for Bloc: I couldn't figure out how to specify the font size in >> points instead of pixels, so maybe that's why it is much more compact >> horizontally. >> > > Could you clarify... are "light" "normal" "full" and "none" done through > Morphic without Bloc ? > > Are you on a high-dpi screen? I'm not very familiar with this, but you > could try experimenting... > http://windows10_dpi_blurry_fix.xpexplorer.com/ > https://www.howtogeek.com/175664/how-to-make-the-windows- > desktop-work-well-on-high-dpi-displays-and-fix-blurry-fonts/ > > cheers -ben >

July 24, 2018

Re: [Pharo-users] Grease stream tests failing on Pharo7

by Johan Brichau

Hi, I reported the issue here: https://pharo.fogbugz.com/f/cases/22281/ReadWriteStream-broken <https://pharo.fogbugz.com/f/cases/22281/ReadWriteStream-broken> Johan > On 23 Jul 2018, at 20:12, Johan Brichau <johan(a)inceptive.be> wrote: > > Hi Richard, > > Thanks for pointing out the difference between #on: and #with: instance creation methods. > > This lead me to discover that ReadWriteStream>>on: strangely sets the readLimit instvar to the endâ¦ which is not what I would expect. > Removing that method and reversing the change in the commit I mentioned fixes all the tests on ReadWriteStream in Grease. > > The Grease tests have been written to test the ANSI behavior and, afaik, they make sense. > > Johan > > >> On 23 Jul 2018, at 17:51, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> wrote: >> >> (ReadWriteStream on: 'abc') contents >> ==> 'abc' in GNU Smalltalk and Dolphin >> ==> '' in Squeak 6.0 and ST/X >> >> Here I think we see why ANSI Smalltalk defined #with: >> for {Read,}WriteStreams but not #on:. >> >> When you recall that ReadWriteStream is a subclass of >> WriteStream in most Smalltalks, and that >> (WriteStream on: (String new: 20)) >> or whatever is normally used with the argument of #on: >> expected to provide *workspace*, not *content*, >> >> why on earth would you expect >> (ReadWriteStream on: 'abc') contents >> to be different from >> (WriteStream on: 'abc') contents >> which is ''? >> >> >> On 23 July 2018 at 21:50, Johan Brichau <johan(a)inceptive.be <mailto:johan@inceptive.be>> wrote: >> Hi, >> >> As Iâm diving into the changes and why it fails: >> >> (ReadWriteStream on: âabcâ) contents >> -> = âabcâ on Pharo 6 >> -> = ââ on Pharo 7 >> >> That seems wrong to me. >> >> (Iâve also sent this question via github on the commit itself https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f3… <https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f3…> ) >> >> cheers >> Johan >> >>> On 22 Jul 2018, at 10:52, Johan Brichau <johan(a)inceptive.be <mailto:johan@inceptive.be>> wrote: >>> >>> Hi, >>> >>> I am taking a look at making Grease and Seaside work correctly on Pharo7. >>> >>> There have been a number of changes to the ReadWriteStream implementation in Pharo that break Grease tests: https://travis-ci.org/SeasideSt/Grease/jobs/406766720 <https://travis-ci.org/SeasideSt/Grease/jobs/406766720> >>> It seems ReadWriteStream is broken: the readLimit is almost always wrong meaning that the stream `atEnd`, `contents` etc.. return wrong values >>> >>> Before I dive into this, I wanted to inquire if anyone is working on this as I cannot seem to find any open cases on this on the issue tracker. >>> >>> cheers >>> Johan >>> >>> >> >> >

July 24, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

> On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Stdio stdout and friends just return a binary stream, hence they need wrapping for encoding. > > Maybe > > Stdio stdoutAsText > > might be an idea, but this is so uncommon that I am not sure this is a good idea. Given all remarks and comments (thanks BTW), I now think that - textual stdio streams are the more common case - binary stdio streams are the primitive ones that are seldom used - another encoding than UTF-8 seems uncommon - these are streams that exist and need no real opening/closing So, Stdio stdout should return return a character write stream with UTF-8 encoding while Stdio binaryStdout should be the lower level binary one. This would be more in line with the other streams. A non-UTF-8 encoding can be used as per Pavel's example.

July 24, 2018