[Pharo-users] Pragma "only for place of definition", is there one?
Hi! I'd just like to know if there is some pragma (eg. ) 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 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
Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.
maybe my linux env is fail now. because xterm cannot use korean input. more check after report this thread. thanks for all. :D
Re: [Pharo-users] Streams for FileReference in Pharo 7
On Sat, 16 Feb 2019 at 15:49, Sven Van Caekenberghe wrote: > > > On 16 Feb 2019, at 14:35, Alistair Grant wrote: > > > > Hi Sven & Jan, > > > > On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe 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 << 16r22 << > 16rFF33 ]) 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
Re: [Pharo-users] Stability of Pharo 7 vs 6?
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=created&type=Issues cheers -ben On Sat, 16 Feb 2019 at 20:10, Tim Mackinnon 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. > >
Re: [Pharo-users] Streams for FileReference in Pharo 7
> On 16 Feb 2019, at 14:35, Alistair Grant wrote: > > Hi Sven & Jan, > > On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe 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 << 16r22 << 16rFF33 ]) 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
Re: [Pharo-users] Streams for FileReference in Pharo 7
Hi Sven & Jan, On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe 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
Re: [Pharo-users] How do I find the RPackageTag of a class?
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 : > 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 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 > > >
[Pharo-users] Pharo 7.0 image size
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
Re: [Pharo-users] Stability of Pharo 7 vs 6?
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 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 > > >
Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.
Thanks, I will test with my friend -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Stability of Pharo 7 vs 6?
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
Re: [Pharo-users] Monticello diff between image and tonel repo
Hi Ben, I am not looking at you reproducing the scenario (you asked for) as it is some work and the outcome may not be reliable as you mentioned it. Nevertheless, the steps I described will likely get you on the trouble and are easy to get in. But more on sharing experience on this topic, as I meet it several times. I think it is an important issue, I have since migrating to Tonel, and it needs to be reported. Closing Monticello windows and opening a fresh one helped to get the changes right, sometime... Other time, forcing flush cash on Monticello helps. But still, this really makes fell the environment to be fragile and inconstant for serious work. It seems Monticello is confused by two sources of package tonel, and mcz. Already meet this problem too. Hilaire PS: DrGeo is free software. Le 16/02/2019 à 10:52, Ben Coman a écrit : > That isn't even close to "steps to reproduce". > > Thats just a lot of effort for me to produce scenario B that has a > high chance of > being entirely unrelated to scenario A you presented. > -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Monticello diff between image and tonel repo
Le 16/02/2019 à 07:23, Ben Coman a écrit : > Its hard to determine what is wrong from the screen shot. > I'm probably not the one able to provide an answer, > but anyway... can you provide steps-to-reproduce in a fresh Image? On Sat, 16 Feb 2019 at 16:49, Hilaire wrote: > Hi Ben, > > The screenshot shows two things: > > 1. In the top (black background), it shows the first lines of the file > 'DrGAngle3ptsOrientedItem.class.st' from the tonel repository, in > the DrGeoII-Core tonel package. In this source, you see a > 'CostumeClasse' method. > 2. In the second half of the screenshot, in the Pharo environment, > there are three windows to look at: > 1. in the background the Monticello window with the DrGeoII-Core > package selected from the tonel repo (the same as in 1.); > 2. on top of the Monticello window, the repository is open and you > can see its packages. The DrGeoII-Core package is selected; > 3. then the foreground window shows the changes between two > packages: one is the tonel package, the other one I don't know > (HilaireFernandes.7). Importantly, it look like costumClass > method does not exist in the tonel package, which is wrong as > seen in 1. That helped my understanding a lot. Its still a static snapshot though. It would be much easier to comment if I could scroll that changes list looking for patterns. > At the minimum, the information misrepresented, or I miss use the tool. Anyway it is confusing for me or not obvious, likely more confusing for > newbie which may think the tool is unreliable, and they want to go away. > > To reproduce, create a tonel repo, add package to this repo, or repo to > the package, and test the same as explained above. > That isn't even close to "steps to reproduce". Thats just a lot of effort for me to produce scenario B that has a high chance of being entirely unrelated to scenario A you presented. To make it easiest to help you, "steps to reproduce" means you hold my hand to *exactly* reproduce your screenshot. If you code is proprietary, you need to create a non-proprietary scenario B with the same problem which you can share in full. If that is too much effort for you, then its too much effort for me to GUESS at producing scenario B that is remotely close to your problem. Anyway, I'm a sucker and went digging anyway. I'm only *guessing* this is the referenced code... https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/view/head:/src/DrGeoII-Core/DrGAngle3ptsItem.class.st What I notice is that all the "green-plus" methods are missing from there, and the "red-cross" method exists. So while I forget the semantics of each changes pane, perhaps you are reading it in reverse? "green-plus" methods are in Monticello package "red-cross" methods are missing from Monticello package HTH, YMMV, cheers -ben
Re: [Pharo-users] Quality assistant
Thanks Denis. By the way, Calypso is pretty cool. Le 15/02/2019 à 23:54, Denis Kudriashov a écrit : > > Use following script to disable it: > > ClyCriticBrowserPlugin disable > -- Dr. Geo http://drgeo.eu
Re: [Pharo-users] Monticello diff between image and tonel repo
Hi Ben, The screenshot shows two things: 1. In the top (black background), it shows the first lines of the file 'DrGAngle3ptsOrientedItem.class.st' from the tonel repository, in the DrGeoII-Core tonel package. In this source, you see a 'CostumeClasse' method. 2. In the second half of the screenshot, in the Pharo environment, there are three windows to look at: 1. in the background the Monticello window with the DrGeoII-Core package selected from the tonel repo (the same as in 1.); 2. on top of the Monticello window, the repository is open and you can see its packages. The DrGeoII-Core package is selected; 3. then the foreground window shows the changes between two packages: one is the tonel package, the other one I don't know (HilaireFernandes.7). Importantly, it look like costumClass method does not exist in the tonel package, which is wrong as seen in 1. At the minimum, the information misrepresented, or I miss use the tool. Anyway it is confusing for me or not obvious, likely more confusing for newbie which may think the tool is unreliable, and they want to go away. To reproduce, create a tonel repo, add package to this repo, or repo to the package, and test the same as explained above. Hilaire Le 16/02/2019 à 07:23, Ben Coman a écrit : > Its hard to determine what is wrong from the screen shot. > I'm probably not the one able to provide an answer, > but anyway... can you provide steps-to-reproduce in a fresh Image? > -- Dr. Geo http://drgeo.eu
