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

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Peter UhnÃ¡k

Ah, you are right that it might not be human-friendly. I don't want to rely on the order, but for (file) versioning it is quite valuable. (or rather changing the order can easily make versioning quite worthless). I can manually sort it, but it creates a lot of mess: (NeoJSONWriter on: stream) prettyPrint: true; for: Something do: [ :mapping | mapping mapInstVars: (mapping identifier instVarNames \ #(unwanted)) sorted ]; for: Otherthing do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames sorted ]; for: Point do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames sorted ]; nextPut: anObject. I'd much rather have the following: (NeoJSONWriter on: stream) prettyPrint: true; sorted: true; for: Something do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames \ #(unwanted) ]; mapInstVarsFor: Otherthing; mapInstVarsFor: Point; nextPut: anObject. or more fine-grained, although the above is imo nicer: (NeoJSONWriter on: stream) prettyPrint: true; for: Something do: [ :mapping | mapping mapInstVars: (mapping identifier instVarNames \ #(unwanted)) sorted ]; mapInstVarsFor: Otherthing sorted: true; mapInstVarsFor: Point sorted: true; nextPut: anObject. (or mapSortedInstVarsFor: or something).. Peter On Wed, Jul 25, 2018 at 11:20 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > From json.org > > "An object is an unordered set of name/value pairs." > > IOW, it is not in the spec, it would be dangerous to rely up it in any way > (not that you are suggesting that). It might look better sometimes, but > even then alphabetic sorting might not be the most human friendly or most > meaningful. > > Note that 'properties' in NeoJSONMapping is an OrderedCollection, so it > keeps it order. So if you add them in the right order, that would do it. > > > On 25 Jul 2018, at 11:12, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > would it be possible to provide option to automatically sort instance > variables when serializing objects? > > > > Either always sorted > > > > NeoJSONObjectMapping>>writeObject: anObject on: jsonWriter > > jsonWriter writeMapStreamingDo: [ :jsonMapWriter | > > (properties sorted: #propertyName ascending) do: [ :each | > > each writeObject: anObject on: jsonMapWriter ] ] > > > > or put it behind some sortProperties boolean flag. (atm I don't see any > downsides in having sort always enabled) > > Speed ? > A false suggestion that is part of the spec ? > > > Thanks, > > Peter > > >

July 25, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Sven Van Caekenberghe

>From json.org "An object is an unordered set of name/value pairs." IOW, it is not in the spec, it would be dangerous to rely up it in any way (not that you are suggesting that). It might look better sometimes, but even then alphabetic sorting might not be the most human friendly or most meaningful. Note that 'properties' in NeoJSONMapping is an OrderedCollection, so it keeps it order. So if you add them in the right order, that would do it. > On 25 Jul 2018, at 11:12, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > would it be possible to provide option to automatically sort instance variables when serializing objects? > > Either always sorted > > NeoJSONObjectMapping>>writeObject: anObject on: jsonWriter > jsonWriter writeMapStreamingDo: [ :jsonMapWriter | > (properties sorted: #propertyName ascending) do: [ :each | > each writeObject: anObject on: jsonMapWriter ] ] > > or put it behind some sortProperties boolean flag. (atm I don't see any downsides in having sort always enabled) Speed ? A false suggestion that is part of the spec ? > Thanks, > Peter

July 25, 2018

NeoJSON sorting instance variables/properties

by Peter UhnÃ¡k

Hi, would it be possible to provide option to automatically sort instance variables when serializing objects? Either always sorted NeoJSONObjectMapping>>writeObject: anObject on: jsonWriter jsonWriter writeMapStreamingDo: [ :jsonMapWriter | (properties sorted: #propertyName ascending) do: [ :each | each writeObject: anObject on: jsonMapWriter ] ] or put it behind some sortProperties boolean flag. (atm I don't see any downsides in having sort always enabled) Thanks, Peter

July 25, 2018

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

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

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

by Ben Coman

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-… cheers -ben

July 24, 2018

fixing font aliasing/sizing for a specific font

by Peter UhnÃ¡k

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.

July 24, 2018

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

by David T. Lewis

On Mon, Jul 23, 2018 at 07:38:16PM +0100, Denis Kudriashov wrote: > Hi. > > I wonder does not stdout and stdin are always about text input/output? No. Consider the case of reading and writing serialized objects on stdin and stdout, possibly between two images sending serialized objects to one another. > I never saw examples when somebody explicitly write raw bytes into these > streams. http://wiki.squeak.org/squeak/6176 I have not checked recently, but it should still work on Pharo with Fuel serialization. > > If I am right then it is better to introduce binaryStdout and binaryStdin > messages. And make stdout and stdin use most common encoding by default. > How it is done in Java? > You are probably right that this is the best default, since it would be the most common case. Dave > > 2018-07-23 19:19 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: > > > Hi Pavel & Sven, > > > > Thanks for writing this, it is a great quick reference. > > > > > > On Mon, 23 Jul 2018 at 12:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > > > > > > > On 23 Jul 2018, at 11:13, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > > > I like all the new code examples until "Write a UTF-8 text to STDOUT" > > > > and I wonder "Stdio stdout writeStreamDo: [ :stream | stream > > > > nextPutAll: 'a ??? b' ]" would better fit the pattern of the other new > > > > code. > > > > (presuming "Stdio stdout" returns a FileReference, oherwise maybe > > > > "Stdio stdoutRef" or "Stdio stdout asFileReference") > > > > > > 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. > > > > I've written this code enough times that I'd like to see it included. :-) > > > > Maybe > > > > Stdout utf8Stdout > > > > (following the pattern of ByteArray>>utf8Decoded, String>>utf8Encoded) > > > > ? > > > > Thanks again, > > Alistair > > > >

July 24, 2018

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

by Ben Coman

On 24 July 2018 at 02:38, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2018-07-23 19:19 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Hi Pavel & Sven, >> >> Thanks for writing this, it is a great quick reference. >> >> >> On Mon, 23 Jul 2018 at 12:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > >> > >> > > On 23 Jul 2018, at 11:13, Ben Coman <btc(a)openinworld.com> wrote: >> > > >> > > I like all the new code examples until "Write a UTF-8 text to STDOUT" >> > > and I wonder "Stdio stdout writeStreamDo: [ :stream | stream >> > > nextPutAll: 'a â b' ]" would better fit the pattern of the other new >> > > code. >> > > (presuming "Stdio stdout" returns a FileReference, oherwise maybe >> > > "Stdio stdoutRef" or "Stdio stdout asFileReference") >> > >> > 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. >> >> I've written this code enough times that I'd like to see it included. :-) >> >> Maybe >> >> Stdout utf8Stdout >> >> (following the pattern of ByteArray>>utf8Decoded, String>>utf8Encoded) >> >> ? >> >> Thanks again, >> Alistair >> > > I wonder does not stdout and stdin are always about text input/output? > I never saw examples when somebody explicitly write raw bytes into these > streams. Its done... https://subosito.com/posts/imagemagick/ but I guess its not the usual case. > If I am right then it is better to introduce binaryStdout and binaryStdin > messages. And make stdout and stdin use most common encoding by default. How > it is done in Java? > > It might be nice to further the new convention "use file references as entry points to file streams" so the new API can be reused... StdioRef stdout writeStreamDo: [ :stream | stream nextPutAll: 'a â b' ]. StdioRef stdout writeStreamEncoded: 'cp-1250' do: [ :stream | stream nextPutAll: 'PÅÃliÅ¡ Å¾luÅ¥ouÄkÃ½ kÅ¯Å ÃºpÄl ÄÃ¡belskÃ© Ã³dy.' ]. StdioRef stdout binaryWriteStreamDo: [ :stream | stream nextPutAll: #[1 2 3] ]. cheers -ben

July 23, 2018

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

by Paul DeBruicker

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. 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 23, 2018

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

by Denis Kudriashov

Hi. I wonder does not stdout and stdin are always about text input/output? I never saw examples when somebody explicitly write raw bytes into these streams. If I am right then it is better to introduce binaryStdout and binaryStdin messages. And make stdout and stdin use most common encoding by default. How it is done in Java? 2018-07-23 19:19 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Pavel & Sven, > > Thanks for writing this, it is a great quick reference. > > > On Mon, 23 Jul 2018 at 12:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > > > On 23 Jul 2018, at 11:13, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > I like all the new code examples until "Write a UTF-8 text to STDOUT" > > > and I wonder "Stdio stdout writeStreamDo: [ :stream | stream > > > nextPutAll: 'a â b' ]" would better fit the pattern of the other new > > > code. > > > (presuming "Stdio stdout" returns a FileReference, oherwise maybe > > > "Stdio stdoutRef" or "Stdio stdout asFileReference") > > > > 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. > > I've written this code enough times that I'd like to see it included. :-) > > Maybe > > Stdout utf8Stdout > > (following the pattern of ByteArray>>utf8Decoded, String>>utf8Encoded) > > ? > > Thanks again, > Alistair > >

July 23, 2018

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

by Alistair Grant

Hi Pavel & Sven, Thanks for writing this, it is a great quick reference. On Mon, 23 Jul 2018 at 12:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 23 Jul 2018, at 11:13, Ben Coman <btc(a)openinworld.com> wrote: > > > > I like all the new code examples until "Write a UTF-8 text to STDOUT" > > and I wonder "Stdio stdout writeStreamDo: [ :stream | stream > > nextPutAll: 'a â b' ]" would better fit the pattern of the other new > > code. > > (presuming "Stdio stdout" returns a FileReference, oherwise maybe > > "Stdio stdoutRef" or "Stdio stdout asFileReference") > > 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. I've written this code enough times that I'd like to see it included. :-) Maybe Stdout utf8Stdout (following the pattern of ByteArray>>utf8Decoded, String>>utf8Encoded) ? Thanks again, Alistair

July 23, 2018

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

by Johan Brichau

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> 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 23, 2018

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

by Sven Van Caekenberghe

> On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Oh, I think a clarification is needed when talking about UTF-8. Why ? > To the best of my knowledge you don't need a Byte-Order-Mark at > the beginning of a UTF-8 stream because there is no byte order > issue to result, Nothing was said about BOMs. > but apparently many Windows programs like to add one. Apparently yes. > Does/will Pharo add one when writing a UTF-8 file? No > Does/will it skip one when reading a UTF-8 file? Yes > I find the new approach produces unattractive code. I can do > all of the examples simply in a system that > (a) implements the ANSI Smalltalk FileStream class methods Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me. Do you prefer a global class side factory facade ? Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same). > (b) supports '/dev/stdin' and '/dev/stdout' as file names Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform. > (c) interprets the external type #'text' either as #'utf8' LC_CTYPE Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default. > What document should I read to get a mental model of the new > system and understand its rationale? ML discussions over the year, I guess. We are generally against big hairy complex classes and prefer simpler ones.

July 23, 2018

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

by Gabriel Cotelli

Great!! On Mon, Jul 23, 2018, 09:00 Norbert Hartl <norbert(a)hartl.name> 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 > > 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 > >

July 23, 2018