- Pharo-users - lists.pharo.org

Re: [Pharo-users] How to intercept every instance variable write on all objects

by Peter Uhnak

Hi, 3) Metalinks - it's based on intercepting method calls, right? But I need to intercept direct instance variable write, so probably not possible no, you can attach metalink to any AST node, including an Assignment Node. Some years ago I've made a small utility for this that also auto-reinstalled when the method has changed. Should work with P6, not sure about the current P7 https://github.com/peteruhnak/metalinks-toolkit . But of course you can attach the MetaLink directly. P On Fri, Feb 1, 2019 at 12:43 AM Petr Fischer via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hello, > > is possible to intercept (before writeÃº all instance variable writes on > every existing objects? > > I found a discussion here: > > http://forum.world.st/Is-it-possible-to-follow-an-object-through-a-computat… > > Known solutions: > > 1) jugglery with object read only state + ModificationForbidden - not > ideal, it's probably slow via exceptions and every nested on:do: stop > change detection > > 2) it's possible to do it via slots - but it does not work on any existing > object (only on my specially prepared objects with slots) > > 3) Metalinks - it's based on intercepting method calls, right? But I need > to intercept direct instance variable write, so probably not possible > > Is there any way? Thanks! pf > > > >

Feb. 2, 2019

Re: [Pharo-users] PharoV50.sources in VM?

by Alistair Grant

On Sat, 2 Feb 2019 at 09:32, Hilaire <hilaire(a)drgeo.eu> wrote: > > Thanks for the update. > > By the way, is there any reason to not remove the symbols in the Windows > and Linux VM libraries? It saves several MB. At least for DrGeo > distribution, there is no use. I'm not sure what the impact of this would be, so would prefer others to comment. > Hilaire > > Le 02/02/2019 Ã 09:01, Alistair Grant a Ã©crit : > > I can't see any reason for keeping this. The sources file is now > > generated for each image, so it doesn't make sense to distribute it > > with the VM. > > > > I'll remove this in a few days if there aren't any other objections. It looks like this is a linux only issue (I downloaded Win and Mac VMs and the sources aren't present). Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/365 PR: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/366 Cheers, Alistair

Feb. 2, 2019

Re: [Pharo-users] How to intercept instvar write - MetaLinks + anonymous subclass problem

by Steven Costiou

> is possible to intercept (before writeÃº all instance variable writes on every existing objects? > > Ok, I learned more about MetaLinks and it's perfectly possible to intercept instance variable writes via. installing MetaLink into object instance (cool) - then I can intercept instvar write, but one problem immediately occurs: > when installing MetaLink into object instance, an original object class is exchanged to anonymous subclass of the original class - and because typical #= method is implemented like: > > = > self == anObject > ifTrue: [ ^ true ]. > self class = anObject class > ifFalse: [ ^ false ]. > ... > > then most of #= comparisons in application logic is broken due to "self class = anObject class" part. > > Is there any way to solve this problem? Hi, the anonymous class thing only happen when you install an object-centric metalink, i.e. on only one specific object. I also wanted to hide the anonymous class, or maybe to only make it visible for environment tools. I need to talk about that with Marcus. Why not installing your metalink on the classes of your objects, so that all instances are affected but in that case there is no anonymous class migration? If that is not possible, in your case maybe a (temporary) hack would be, in your case, to add a test in the #class method in Object (or wherever it is defined): class |myClass| myClass := self class. ^myClass isAnonymous ifTrue:[myClass superclass] ifFalse:[myClass] But i did not test that and i have no idea of the overall impact. Steven.

Feb. 2, 2019

Re: [Pharo-users] Learn Pharo - Not Working

by magicspeller

Thanks, John. It is the 64-bit version. I didn't know it was beta software. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 2, 2019

Re: [Pharo-users] Learn Pharo - Not Working

by john pfersich

Did you use the 32-bit version or the 64-bit version? I just used Pharo Launcher to start a 32-bit image. I clicked on âProfStef goâ and got a separate window with the tutorial. I didnât try the 64-bit version; itâs still beta software. /*âââââââââââââââââ-*/ Sent from my iPhone https://boincstats.com/signature/-1/user/51616339056/sig.png See https://objectnets.net and https://objectnets.org > On Feb 1, 2019, at 23:34, magicspeller <pharo(a)magicspeller.info> wrote: > > Hi, everyone. > > I'm an absolute newbie to Pharo, and to Smalltalk, and I'm trying to learn. > I just installed Pharo 7.0.1 (on Windows 10) and I immediately got stuck. > > I selected "Learn Pharo" in the outline, and it gave me a screen saying: > > You can learn Pharo by clicking on the following expression: > > ProfStef go. > > I clicked on ProfStef go and nothing happened. There are three URL links on > the same page that work like they're supposed to, but no matter how many > times I try, clicking on ProfStef go appears to do nothing at all. > > Am I misunderstanding what I'm supposed to do or what's supposed to happen? > > Thanks a lot for your help. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 2, 2019

Re: [Pharo-users] PharoV50.sources in VM?

by Hilaire

Thanks for the update. By the way, is there any reason to not remove the symbols in the Windows and Linux VM libraries? It saves several MB. At least for DrGeo distribution, there is no use. Hilaire Le 02/02/2019 Ã 09:01, Alistair Grant a Ã©critÂ : > I can't see any reason for keeping this. The sources file is now > generated for each image, so it doesn't make sense to distribute it > with the VM. > > I'll remove this in a few days if there aren't any other objections. -- Dr. Geo http://drgeo.eu

Feb. 2, 2019

Re: [Pharo-users] PharoV50.sources in VM?

by Alistair Grant

Hi Hilaire, On Fri, 1 Feb 2019 at 21:38, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > In the Linux distributed VM, I noted the file > lib/pharo/5.xxxx/PharoV50.sources. > > Can it be removed safely? What is its purpose? I can't see any reason for keeping this. The sources file is now generated for each image, so it doesn't make sense to distribute it with the VM. I'll remove this in a few days if there aren't any other objections. Cheers, Alistair

Feb. 2, 2019

Learn Pharo - Not Working

by magicspeller

Hi, everyone. I'm an absolute newbie to Pharo, and to Smalltalk, and I'm trying to learn. I just installed Pharo 7.0.1 (on Windows 10) and I immediately got stuck. I selected "Learn Pharo" in the outline, and it gave me a screen saying: You can learn Pharo by clicking on the following expression: ProfStef go. I clicked on ProfStef go and nothing happened. There are three URL links on the same page that work like they're supposed to, but no matter how many times I try, clicking on ProfStef go appears to do nothing at all. Am I misunderstanding what I'm supposed to do or what's supposed to happen? Thanks a lot for your help. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 2, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by HernÃ¡n Morales Durand

Hi Tomo, Nice to know I wasn't so wrong :) Thank you for sharing your experience. Since we are few (than other techs) it is important to communicate and let others know. Cheers, HernÃ¡n El jue., 31 ene. 2019 a las 7:06, tomo (<tomohiro.tomo.oda(a)gmail.com>) escribiÃ³: > Hernan, > > > Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. > > The first option was about splitting MyPackage into MyPackage-Common, > > MyPackage-Pharo6 and > > MyPackage-Pharo7 with corresponding methods/classes moved. > > In my project, I migrated MyPackage into Pharo 7, and create > MyPackage-Pharo6 for compatibility. > Then updated BaselineOf to conditionally load MyPackage-Pharo6. > At some point, I will drop MyPackage-Pharo6 to make migration to Pharo 8 > easier :-) > > I haven't used branch or tag to support different platform versions. > I'd prefer branch over tag if I want to keep maintaining codes for older > platforms. > I'd like to hear how people are dealing with this issue, too. > > Best Regards, > --- > tomo > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Feb. 2, 2019

Re: [Pharo-users] Porting Github packages to Pharo 7

by HernÃ¡n Morales Durand

Yes I've concluded this is the "easiest" way. Sadly it is hard to automate the porting. Thank you Guille. El jue., 31 ene. 2019 a las 6:49, Guillermo Polito (< guillermopolito(a)gmail.com>) escribiÃ³: > Well, I've said it somewhere in the mail, probably got lost in all my > blablbla, so I'll summarize. > > - I use tags to identify releases. > - A same release works in Pharo6 and Pharo7 > - In the baseline I have defined some conditional package that is loaded > in Pharo6 that provides compatibility from Pharo6 to Pharo7. > Of course, depending on the change you're doing you may want to have > one package per platform besides the core. > > When I was talking about a single branch I was talking about the so-called > master branch, not about creating a new branch (which was case 2) > > On Thu, Jan 31, 2019 at 10:29 AM HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Hi Guillermo >> >> El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (< >> guillermopolito(a)gmail.com>) escribiÃ³: >> >>> Hi HernÃ¡n, >>> >>> On Thu, Jan 31, 2019 at 8:20 AM HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>>> I would like your advice on this: What's the effortless way to migrate >>>> Github repository from Pharo 6 to Pharo 7? >>>> >>> >>> Can you give us some more detail? Do you already have your project in >>> github working for Pharo6? Or is it in Smalltalkhub and you are willing to >>> move it to github? >>> >>> >> Most of my packages are working on Pharo 6 already, and they are on >> GitHub. >> >> >> >>> I'll assume the first below :) >>> >>> >>>> >>>> I thought in the following solutions: >>>> >>>> 1) In a Pharo 6 image modify my BaselineOf, add & push a new package >>>> MyPackage-Pharo6, then load it into a Pharo 7 image, create >>>> MyPackage-Pharo7 and port as needed. The same Metacello installation script >>>> is preserved for all versions. >>>> >>>> 2) Tag repository as x.x in a Pharo 6 image, load my package & do port >>>> in a Pharo 7 image and push to master. Previous Pharo 6 version could be >>>> loaded referring to a tag (or branch maybe?) in the Metacello installation >>>> script. >>>> >>> >>> Well, it depends on what you want to provide as "support". >>> - Do you want your package to keep working on both versions? >>> >> >> Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. >> The first option was about splitting MyPackage into MyPackage-Common, >> MyPackage-Pharo6 and MyPackage-Pharo7 with corresponding methods/classes >> moved. >> >> >>> - Do you want your new features to be available also in the old version? >>> >>> >> I'm not really interested in backward compatibiilty. >> >> >>> Case 1) Usually I try (if context agrees :) to keep a single branch. And >>> I try that my project in that branch is compatible with both Pharo >>> versions. Having a single branch if possible removes part of the >>> bureaucracy of thinking about backports, patches, and so on... >>> Releases are marked as tags, but they are shared between the different >>> platforms. >>> >>> >> You're talking about branches but I've used branches for a different >> purpose (providing features for example). Wouldn't be more appropriate to >> use tags in this case? >> >> >>> We were able to do it with Iceberg for a long time (and it is an example >>> that relies on Spec, File stuff, FFI..). >>> We have lost that compatibility in the last weeks because we made a fix >>> for win64 that was not compatible with Pharo6, but I'm thinking in getting >>> that compatibility back at lest for Iceberg 1.5.*. >>> >>> >> I will check those Baselines because I need to see examples of how does >> it work. >> >> >>> To keep a single branch compatible with many Pharo versions there is no >>> magic: >>> 1) we have a forward compatibility package to Pharo 7. The idea is that >>> we write code for Pharo7 but in Pharo6 we can load a package with some >>> extensions/additions that make it compatible with Pharo7. >>> 2) we try to use compatible APIs. For example, we use FileSystem as >>> much as possible. Another example is that Iceberg relies a lot in the Path >>> class to manipulate the directory tree, and the nicest API of that class >>> changed a lot so for simplicity we used the low level API that is a bit >>> uglier and verbose, but compatible. >>> >>> Case 2) At the same time, just to set an example, we were thinking >>> version 1.5.* was going to be the last iceberg version supported for >>> Pharo6, so pharo7 and 8 were going to use 1.6.*. This means we will have >>> two different versions running side by side. >>> >>> If we want to continue applying patches and critical bugfixes in the >>> 1.5.* version, we should have two branches. >>> Notice that here I'm assuming that my 1.5.* branch will move much more >>> slowly than 1.6.*, since no real active development will be done with it. >>> >>> >> Thank you Guillermo >> >> >> >>> Probably other people can share their workflows. >>> >>> HTH, >>> Guille >>> >>> >>>> Any recommendations? Alternative paths? >>>> >>>> Cheers, >>>> >>>> HernÃ¡n >>>> >>>> >>>> >>>> >>> >>> -- >>> >>> >>> >>> 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 >>> >> > > -- > > > > 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 >

Feb. 2, 2019