February 2019 - Pharo-users

Re: [Pharo-users] Pharo 7.0 image size

by Hilaire

May be you have a lot of still open Seaside session, which if I remember correctly are automatically shutdown after 10 min when not active. Looking at Seaside session instances may give clue. Hilaire Le 16/02/2019 Ã 13:18, Trussardi Dario Romano a Ã©critÂ : > Starting from 94 MB, now after rebooting and save the image the relative size is 252 MB. > > How can I understand what is happening? -- Dr. Geo http://drgeo.eu

Feb. 17, 2019

Pragma "only for place of definition", is there one?

by Herby VojÄÃk

Hi! I'd just like to know if there is some pragma (eg. <onlyForMe>) which would say to a (class-level) method only to use the code in the case self is method definition class, otherwise just delegate to super. I only see it useful in class-side `initialize` method, as in: Foo class >> initialize self == Foo ifTrue: [ registry := Dictionary new ]. ^ super initialize would be Foo class >> initialize <onlyForMe> registry := Dictionary new Asking because I look for a way to easily subclass JS classes in Amber and such pragma would be useful in such cases, and since Amber treats Pharo as a reference, asking for the name of the pragma if there is one. Thanks, Herby

Feb. 16, 2019

Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.

by peter yoo

maybe my linux env is fail now. because xterm cannot use korean input. more check after report this thread. thanks for all. :D

Feb. 16, 2019

Re: [Pharo-users] Streams for FileReference in Pharo 7

by Alistair Grant

On Sat, 16 Feb 2019 at 15:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 16 Feb 2019, at 14:35, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven & Jan, > > > > On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi Jan, > >> > >> I like #<< too, but I think your assumption that it can print anything on a stream is generally wrong, dangerous and unreliable. > >> > >> IMHO, you better stick to #print: in that case. > >> > >> Consider the follow, that all fail: > >> > >> String streamContents: [ :s | s << 'hello' << 42.5 << $! ]. > >> > >> String streamContents: [ :s | s << 'hello' << (1@2) << $! ]. > >> > >> In other words: #<< works in bizar ways (check the implementors of #putOn:). > >> > >> I would be inclined to change > >> > >> ZnEncodedStream>>#<< collection > >> ^ self nextPutAll: collection > >> > >> to > >> > >> ZnEncodedStream>>#<< collection > >> ^ self nextPutAll: collection asString > >> > >> but it would technically not be the same as the original #<< for in-memory streams. > >> > >> Opinions ? > > > > I've often thought that this change would be nice to have. #putOn: > > doesn't really fit in with writing to text streams (text in the loose > > sense of "something that will be read"). > > > > I think an argument could be made that #printString or #displayString > > should be used, but they both have their own issues in practice. > > So... > > > > +1 to "collection asString". > > > > Cheers, > > Alistair > > I have been thinking a bit more about this, and I have a lot of problems with > > Integer>>#putOn: aStream > aStream isBinary > ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] > ifFalse: [ self asString putOn: aStream ] > > I think we should simply remove this method. It is ugly and wrong. > > #<< should simply be a shortcut for either #nextPut: and #nextPutAll: and nothing more. > > The following two are OK for me: > > String streamContents: [ :out | out << 'Hello' << $! ]. > ByteArray streamContents: [ :out | out << #[ 1 2 3 ] << 4 ]. > > But the following most definitively not: > > (ByteArray streamContents: [ :out | out << 16rFF << 16rFF11 << 16rFFFF22 << 16rFFFFFF33 ]) hex. > > When you write out an integer, you have to decide its size, that can never depend on the magnitude (because there is no way to read this back unless there is additional bracketing). > > Also, printing to a stream should be (very) efficient. Making copies of objects just for conversion purposes should be avoided. > > I think that if we remove Integer>>#putOn: I could live with > > ZnEncodedStream>>#<< anObject > anObject putOn: self > > The other solution is to define #<< as strictly the same as #nextPutAll: and remove all #putOn: implementors. My thoughts aren't fully formed on this, but: I think we can break the streams up in to three categories: - Streams of arbitrary objects, i.e. streams writing to Arrays, OrderedCollections, etc. - Streams that serialise the objects, e.g. JSON, STON, ASN.1, etc. - Streams that write to some form of text output intended for human reading. We can then group the messages used by each category: - Arbitrary object: nextPut:, nextPutAll:, putOn:, etc. - Serialising: stonOn:, etc. - Text: <<, cr, lf, etc. Following these guidelines: - I'd remove the Integer>>putOn: as you suggest. - Add the #asString to ZnEncodedStream>><< as suggested earlier. Cheers, Alistair

Feb. 16, 2019

Re: [Pharo-users] Stability of Pharo 7 vs 6?

by Ben Coman

I'm not on a Mac to test, but it might be worth browsing the top few of these.. https://github.com/search?o=desc&q=can%27t+allocate+region+securely&s=creat… cheers -ben On Sat, 16 Feb 2019 at 20:10, Tim Mackinnon <tim(a)testit.works> wrote: > Iâve actually being using both - but 32bit has generally been considered > the older more stable cousin (until Pharo 6 - where it was felt that 64bit > was now just as stable). > > I only mentioned it - because the zeroconf example that has crashed a few > of my several times - was 32 bit (but I have also had 64 bit crash too. > Probably a good experiment to try zeroconf with the 64bit variation and > load my baseline as well). > > I just think we might have an easily reproducable (and small) example that > shows this issue that many have experienced a bit more randomly. > >

Feb. 16, 2019

Re: [Pharo-users] Streams for FileReference in Pharo 7

by Sven Van Caekenberghe

> On 16 Feb 2019, at 14:35, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven & Jan, > > On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi Jan, >> >> I like #<< too, but I think your assumption that it can print anything on a stream is generally wrong, dangerous and unreliable. >> >> IMHO, you better stick to #print: in that case. >> >> Consider the follow, that all fail: >> >> String streamContents: [ :s | s << 'hello' << 42.5 << $! ]. >> >> String streamContents: [ :s | s << 'hello' << (1@2) << $! ]. >> >> In other words: #<< works in bizar ways (check the implementors of #putOn:). >> >> I would be inclined to change >> >> ZnEncodedStream>>#<< collection >> ^ self nextPutAll: collection >> >> to >> >> ZnEncodedStream>>#<< collection >> ^ self nextPutAll: collection asString >> >> but it would technically not be the same as the original #<< for in-memory streams. >> >> Opinions ? > > I've often thought that this change would be nice to have. #putOn: > doesn't really fit in with writing to text streams (text in the loose > sense of "something that will be read"). > > I think an argument could be made that #printString or #displayString > should be used, but they both have their own issues in practice. > So... > > +1 to "collection asString". > > Cheers, > Alistair I have been thinking a bit more about this, and I have a lot of problems with Integer>>#putOn: aStream aStream isBinary ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] ifFalse: [ self asString putOn: aStream ] I think we should simply remove this method. It is ugly and wrong. #<< should simply be a shortcut for either #nextPut: and #nextPutAll: and nothing more. The following two are OK for me: String streamContents: [ :out | out << 'Hello' << $! ]. ByteArray streamContents: [ :out | out << #[ 1 2 3 ] << 4 ]. But the following most definitively not: (ByteArray streamContents: [ :out | out << 16rFF << 16rFF11 << 16rFFFF22 << 16rFFFFFF33 ]) hex. When you write out an integer, you have to decide its size, that can never depend on the magnitude (because there is no way to read this back unless there is additional bracketing). Also, printing to a stream should be (very) efficient. Making copies of objects just for conversion purposes should be avoided. I think that if we remove Integer>>#putOn: I could live with ZnEncodedStream>>#<< anObject anObject putOn: self The other solution is to define #<< as strictly the same as #nextPutAll: and remove all #putOn: implementors. Sven

Feb. 16, 2019

Re: [Pharo-users] Streams for FileReference in Pharo 7

by Alistair Grant

Hi Sven & Jan, On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Jan, > > I like #<< too, but I think your assumption that it can print anything on a stream is generally wrong, dangerous and unreliable. > > IMHO, you better stick to #print: in that case. > > Consider the follow, that all fail: > > String streamContents: [ :s | s << 'hello' << 42.5 << $! ]. > > String streamContents: [ :s | s << 'hello' << (1@2) << $! ]. > > In other words: #<< works in bizar ways (check the implementors of #putOn:). > > I would be inclined to change > > ZnEncodedStream>>#<< collection > ^ self nextPutAll: collection > > to > > ZnEncodedStream>>#<< collection > ^ self nextPutAll: collection asString > > but it would technically not be the same as the original #<< for in-memory streams. > > Opinions ? I've often thought that this change would be nice to have. #putOn: doesn't really fit in with writing to text streams (text in the loose sense of "something that will be read"). I think an argument could be made that #printString or #displayString should be used, but they both have their own issues in practice. So... +1 to "collection asString". Cheers, Alistair

Feb. 16, 2019

Re: [Pharo-users] How do I find the RPackageTag of a class?

by Denis Kudriashov

Hi Tim. aPackage classTagForClass: aClass Calypso shows more kind of children than just a package tags. And it can be extended. That's the reason why you don't have raw packageTag there. Also in Pharo 6 new API was introduced to handle tags of classes and methods in similar way https://pharo.manuscript.com/f/cases/19341/New-class-and-method-tags-API. ÑÑ, 14 ÑÐµÐ²Ñ. 2019 Ð³. Ð² 13:40, Tim Mackinnon <tim(a)testit.works>: > Actually - Iâve realised that Calypso can give me the tag name from its > context - (aToolContext lastSelectedClassGroup). > > However it does highlight a very strange package/tag design. Are you not > supposed to be easily able to derive RPacakgeTags? > > Tim > > > On 14 Feb 2019, at 13:19, Tim Mackinnon <tim(a)testit.works> wrote: > > > > Iâm trying to understand how RPackage and RPackageTag work in Pharo7? It > seems different than Pharo6 at least with Nautilus (vs Calypso) - as > previously the Nautilus UI gave me the RPacakgeTag, and I could just work > with that. Calypso doesnât seem to give me the tag object, but if I have a > known class and I want to know its RPackageTag I canât see how you do it? > It all seems rather messyâ¦. > > > > I can ask a class for its category - which just gives me a symbol of the > form âmypackage-tagnameâ, and if I ask a class for its package, it will > give me an RPackage(myPackage) - but that RPackage has a set of > RPackageTags which just use the tagname (so not prefixed with > "mypackage-â)? So am I really supposed to split the category name on â-â > myself, and then select the correct RPackageTag? > > > > If I look at the RPackageTag tests - they all seem to use hard coded > values and so donât really show you how you deal with the question above? > > > > It really seems quite messy? > > > > I naively thought that if I wanted a browser extension to deal with a > selected package tag - and file out some classes in that tag (for exercism) > - I could easily get the RPackageTag from any class and then use it? > > > > Tim > > >

Feb. 16, 2019

Pharo 7.0 image size

by Trussardi Dario Romano

Ciao, i have a Pharo 7.0 alpha build 1262. I development a Seaside application. The size of the image keeps increasing, without an apparent reason. Starting from 94 MB, now after rebooting and save the image the relative size is 252 MB. How can I understand what is happening? How can I analyze the data to understand who is occupying more and more space? The other day the system generated a warning that in practice said that there was no more space and that image had to be started with a particular value. Some considerations ? Thanks, Dario

Feb. 16, 2019

Re: [Pharo-users] Stability of Pharo 7 vs 6?

by Tim Mackinnon

Iâve actually being using both - but 32bit has generally been considered the older more stable cousin (until Pharo 6 - where it was felt that 64bit was now just as stable). I only mentioned it - because the zeroconf example that has crashed a few of my several times - was 32 bit (but I have also had 64 bit crash too. Probably a good experiment to try zeroconf with the 64bit variation and load my baseline as well). I just think we might have an easily reproducable (and small) example that shows this issue that many have experienced a bit more randomly. Tim > On 16 Feb 2019, at 11:17, Hilaire <hilaire(a)drgeo.eu> wrote: > > I can't tell, but in your initial email you mentionned using the 64bits > VM, so the image is 64bits too. > > So if you are using 32bits, you can try 64bitsVM https://get.pharo.org/64/ > > Le 16/02/2019 Ã 12:01, Tim Mackinnon a Ã©crit : >> As mentioned, Iâm on OSX HighSierra I get a zero conf image (which I >> believe is the 32 bit version?) >> > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 16, 2019