- Pharo-users - lists.pharo.org

Re: [Pharo-users] NeoJSON ignore some instance variables

by Sven Van Caekenberghe

> On 25 Jul 2018, at 10:17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > what is the best way to ignore instance variables when serializing with NeoJSON? > > I figured out this so far... > > (NeoJSONWriter on: stream) > for: Something > do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames \ #(unwanted) ]; > nextPut: aSomething > > Thanks, > Peter That is a better and more beautiful way to do it then I would have come up with myself ;-)

July 25, 2018

NeoJSON ignore some instance variables

by Peter UhnÃ¡k

Hi, what is the best way to ignore instance variables when serializing with NeoJSON? I figured out this so far... (NeoJSONWriter on: stream) for: Something do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames \ #(unwanted) ]; nextPut: aSomething Thanks, Peter

July 25, 2018

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