April 2010 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Traits versus packages

by Johan Fabry

Indeed. Maybe hook into Monticello to detect that a publish will be done and then do an unload, and after the publish a load. This system is getting to be a bit fiddly, but I see no fundamental solution. That is until the entire package mechanism becomes more powerful in this regard. On 30 Apr 2010, at 09:06, Tudor Girba wrote: > Hi, > > Let me explain: I have ClassX that is extended to use TraitX. Now, I want to add an instance variable to the main class while the extension is loaded. > > You would go to ClassX and edit it: > > Object subclass: #ClassX > uses: TraitX > instanceVariableNames: 'newInstanceVariable' > classVariableNames: '' > poolDictionaries: '' > category: 'Base-Category' > > Now, if you save, the uses: clause will go in the base class. So, if I publish the package that only contains the base class I will have an unwanted side effect: the base version of ClassX will use TraitX. > > Cheers, > Doru > > > On 29 Apr 2010, at 18:01, Johan Fabry wrote: > >> >> Not necessarily ;-) if the browser displays the uses: TraitX (because it was added by the extension) and you add an instance var, you are going to do that with the uses: TraitX because that's what's displayed in the pane where you add the instance vars. Unless you manually remove it because you are a nasty person... and then you are just shooting yourself in the foot anyway. :-) >> >> Now on traits unload this has to be done in a clever way, not simply reverting to the state before traits load to avoid losing any other changes made. -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

April 30, 2010

Re: [Pharo-users] Traits versus packages

by Tudor Girba

Hi, Let me explain: I have ClassX that is extended to use TraitX. Now, I want to add an instance variable to the main class while the extension is loaded. You would go to ClassX and edit it: Object subclass: #ClassX uses: TraitX instanceVariableNames: 'newInstanceVariable' classVariableNames: '' poolDictionaries: '' category: 'Base-Category' Now, if you save, the uses: clause will go in the base class. So, if I publish the package that only contains the base class I will have an unwanted side effect: the base version of ClassX will use TraitX. Cheers, Doru On 29 Apr 2010, at 18:01, Johan Fabry wrote: > > Not necessarily ;-) if the browser displays the uses: TraitX > (because it was added by the extension) and you add an instance var, > you are going to do that with the uses: TraitX because that's what's > displayed in the pane where you add the instance vars. Unless you > manually remove it because you are a nasty person... and then you > are just shooting yourself in the foot anyway. :-) > > Now on traits unload this has to be done in a clever way, not simply > reverting to the state before traits load to avoid losing any other > changes made. > > On 29 Apr 2010, at 10:15, Tudor Girba wrote: > >> Sure, but if I had the extension loaded and I would want to work on >> the base class and add an instance variable, I would have a >> problem, no? :) >> >> Doru >> >> >> On 29 Apr 2010, at 16:10, Johan Fabry wrote: >> >>> >>> Not necessarily, the browser should display uses: TraitX, like it >>> does now. So when browsing the code there is no perceived >>> difference. >>> >>> On 29 Apr 2010, at 03:07, Tudor Girba wrote: >>> >>>> It also should be noted that it is completely obscure when trying >>>> to understand a piece of code :) >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: >>>> >>>>>> Or can we make a traits installer, that performs the >>>>>> redefinition of target classes? First check if the target >>>>>> classes already declare a uses:, and if not add it. Sounds like >>>>>> simple metaprogramming ... >>>>>> >>>>>> Any comments on this 'solution'? >>>>> >>>>> Although not perfect, it is easy and efficient. >>>>> >>>>> Alexandre >>>> >>> >>> -- >>> Johan Fabry >>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "One cannot do more than one can do."

April 30, 2010

Re: [Pharo-users] Error:invalid utf8 input detected.

by Mariano Martinez Peck

On Wed, Apr 28, 2010 at 4:16 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > We were using Pharo1.0-10440-BETAdev09.09, the beta one :P, because the > course began before the 1.0 was released. > Two weeks ago we told students to download the VM and image separatedly, > and I think that solved the loading image issue. > > There is a way to reproduce it, on windows, and that version of the > OneClic: > - Save the image you are loading with save as. > - Close Pharo and try to load the image you'v recently saved dragging the > .image on Pharo.exe. > > Ok...I have been doing some tests and this is what I came up to: 1) I could reproduce the problem and happen even with the same image. No need to do the "save us" and use another image 2) If you double click the Pharo.exe in the one click image, it automatically loads the Pharo 1.0 image. How this is done? It is configure in Pharo.ini conf file which is in the same directory as Pharo.exe. As you can see in that file (is a text file so you can open it easily) this line: ImageFile=Contents\Resources\Pharo-1.0.image So....in summary: if you ALREADY have defined a image in such file, then you cannot drag another image. If you want to be able to drag the image, you have to remove that line from the conf file. With that, when you double click Pharo.exe it will prompt the file dialog of the OS to ask you the image file. In addition, you can drag and run it without problem. More in details, the problem is that when you pass an image, it is interpreted as "SmalltalkImage current getSystemAttribute: 1" When you drag a second file (in your case a second image) it is interpreted as source file, not image, and thus the error with the encoding. Put a breakpoint in the method startUpAfterLogin if you want to experiment a bit. At least with this, you know why it was the problem and how to avoid it. Maybe we should raise a better error or even better, if I have already defined an image in the ini file, but I drag another one, override the first one and take the dragged one. I will ask in Pharodev mailing list. Cheers Mariano > When you do that, the error is showed and looking at the title bar you can > see the image loaded is not the one you dragged. > > In the 1.0 version it happens too, in the same way. > Also, I've been told that in linux environments this doesn't happen (when > dragging to the .sh). > > I'm attaching the log file. (It's very odd, there aren't line separations > xP) > > Thanks, > Guille > > > On Wed, Apr 28, 2010 at 5:19 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Que haces Guille!! como va? ;) >> >> The error "invalid utf8 input detected" was a known problem for a while, >> but it is supposed to be fixed in the latest versions. Look for example this >> issue (although there are even more for the same topic): >> >> http://code.google.com/p/pharo/issues/detail?id=370 >> >> >> http://code.google.com/p/pharo/issues/list?can=1&q=invalid+utf8+input+detec… >> >> Which PharoOneClick are you using? Can you try the last one? >> >> https://gforge.inria.fr/frs/download.php/26828/Pharo-1.0-OneClick.zip >> >> If it happens there, do you know an exactly way to reproduce it ? >> >> Cheers >> >> Mariano >> >> On Wed, Apr 28, 2010 at 3:04 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Hi there! >>> >>> We are using Pharo to teach OOP in UTN university, Argentina. Some >>> times students have the error Invalid utf8 input detected when loading an >>> image or doing a file out of a category. >>> I think it happens mostly (or always, i'm not sure) in the >>> OneClicImage, when running on windows. >>> >>> Is it a known issue? >>> >>> Thanks! >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

April 30, 2010

Re: [Pharo-users] Traits versus packages

by Alexandre Bergel

One of the thing that it may hamper readibility, is when browsing the code through a Monticello Browser or a webbrowser. Alexandre On 29 Apr 2010, at 10:10, Johan Fabry wrote: > > Not necessarily, the browser should display uses: TraitX, like it > does now. So when browsing the code there is no perceived difference. > > On 29 Apr 2010, at 03:07, Tudor Girba wrote: > >> It also should be noted that it is completely obscure when trying >> to understand a piece of code :) >> >> Cheers, >> Doru >> >> >> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: >> >>>> Or can we make a traits installer, that performs the redefinition >>>> of target classes? First check if the target classes already >>>> declare a uses:, and if not add it. Sounds like simple >>>> metaprogramming ... >>>> >>>> Any comments on this 'solution'? >>> >>> Although not perfect, it is easy and efficient. >>> >>> Alexandre >> > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 30, 2010

Re: [Pharo-users] Traits versus packages

by Johan Fabry

Not necessarily ;-) if the browser displays the uses: TraitX (because it was added by the extension) and you add an instance var, you are going to do that with the uses: TraitX because that's what's displayed in the pane where you add the instance vars. Unless you manually remove it because you are a nasty person... and then you are just shooting yourself in the foot anyway. :-) Now on traits unload this has to be done in a clever way, not simply reverting to the state before traits load to avoid losing any other changes made. On 29 Apr 2010, at 10:15, Tudor Girba wrote: > Sure, but if I had the extension loaded and I would want to work on the base class and add an instance variable, I would have a problem, no? :) > > Doru > > > On 29 Apr 2010, at 16:10, Johan Fabry wrote: > >> >> Not necessarily, the browser should display uses: TraitX, like it does now. So when browsing the code there is no perceived difference. >> >> On 29 Apr 2010, at 03:07, Tudor Girba wrote: >> >>> It also should be noted that it is completely obscure when trying to understand a piece of code :) >>> >>> Cheers, >>> Doru >>> >>> >>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: >>> >>>>> Or can we make a traits installer, that performs the redefinition of target classes? First check if the target classes already declare a uses:, and if not add it. Sounds like simple metaprogramming ... >>>>> >>>>> Any comments on this 'solution'? >>>> >>>> Although not perfect, it is easy and efficient. >>>> >>>> Alexandre >>> >> >> -- >> Johan Fabry >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

April 29, 2010

Re: [Pharo-users] Traits versus packages

by Tudor Girba

Sure, but if I had the extension loaded and I would want to work on the base class and add an instance variable, I would have a problem, no? :) Doru On 29 Apr 2010, at 16:10, Johan Fabry wrote: > > Not necessarily, the browser should display uses: TraitX, like it > does now. So when browsing the code there is no perceived difference. > > On 29 Apr 2010, at 03:07, Tudor Girba wrote: > >> It also should be noted that it is completely obscure when trying >> to understand a piece of code :) >> >> Cheers, >> Doru >> >> >> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: >> >>>> Or can we make a traits installer, that performs the redefinition >>>> of target classes? First check if the target classes already >>>> declare a uses:, and if not add it. Sounds like simple >>>> metaprogramming ... >>>> >>>> Any comments on this 'solution'? >>> >>> Although not perfect, it is easy and efficient. >>> >>> Alexandre >> > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "It's not how it is, it is how we see it."

April 29, 2010

Re: [Pharo-users] Traits versus packages

by Johan Fabry

Not necessarily, the browser should display uses: TraitX, like it does now. So when browsing the code there is no perceived difference. On 29 Apr 2010, at 03:07, Tudor Girba wrote: > It also should be noted that it is completely obscure when trying to understand a piece of code :) > > Cheers, > Doru > > > On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: > >>> Or can we make a traits installer, that performs the redefinition of target classes? First check if the target classes already declare a uses:, and if not add it. Sounds like simple metaprogramming ... >>> >>> Any comments on this 'solution'? >> >> Although not perfect, it is easy and efficient. >> >> Alexandre > -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

April 29, 2010

Re: [Pharo-users] Traits versus packages

by Tudor Girba

It also should be noted that it is completely obscure when trying to understand a piece of code :) Cheers, Doru On 28 Apr 2010, at 20:03, Alexandre Bergel wrote: >> Or can we make a traits installer, that performs the redefinition >> of target classes? First check if the target classes already >> declare a uses:, and if not add it. Sounds like simple >> metaprogramming ... >> >> Any comments on this 'solution'? > > Although not perfect, it is easy and efficient. > > Alexandre > >> >> On 28 Apr 2010, at 01:56, StÃ©phane Ducasse wrote: >> >>> so far (and similarly to instance variable) you cannot with the >>> current definition syntax >>> declare a trait (add instance) to a class from a package that does >>> not define the class. >>> You can do that in the initialize of a class loaded in a package >>> but there is no think like >>> >>> MyClass addInstanceVariable: 'x' >>> MyOtherClass addTrait: >>> >>> at the similar syntax level than >>> >>>> FAMIXScopingEntity subclass: #FAMIXNamespace >>>> uses: TAMStructuralZoom >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'Famix-Core' >>> >>> this is why one day packages will have to be a bit better >>> supported and more important >>> we will have fix the "semantics" of changeset to be something >>> than a simple side effect of 'oh this is easy' just save the class >>> def and the method definition (because a class is a complex object). >> >> -- >> Johan Fabry >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

April 29, 2010

Re: [Pharo-users] Traits versus packages

by Alexandre Bergel

> Or can we make a traits installer, that performs the redefinition of > target classes? First check if the target classes already declare a > uses:, and if not add it. Sounds like simple metaprogramming ... > > Any comments on this 'solution'? Although not perfect, it is easy and efficient. Alexandre > > On 28 Apr 2010, at 01:56, StÃ©phane Ducasse wrote: > >> so far (and similarly to instance variable) you cannot with the >> current definition syntax >> declare a trait (add instance) to a class from a package that does >> not define the class. >> You can do that in the initialize of a class loaded in a package >> but there is no think like >> >> MyClass addInstanceVariable: 'x' >> MyOtherClass addTrait: >> >> at the similar syntax level than >> >>> FAMIXScopingEntity subclass: #FAMIXNamespace >>> uses: TAMStructuralZoom >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Famix-Core' >> >> this is why one day packages will have to be a bit better supported >> and more important >> we will have fix the "semantics" of changeset to be something than >> a simple side effect of 'oh this is easy' just save the class def >> and the method definition (because a class is a complex object). > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 28, 2010

Re: [Pharo-users] Traits versus packages

by StÃ©phane Ducasse

On Apr 28, 2010, at 7:03 PM, Johan Fabry wrote: > > Booh. So far for the traits implementation of AspectMaps then :-( I dont want to break the modularity of the AspectMaps package by requireing a special version of other packages for the traits to work. > > Or can we make a traits installer, that performs the redefinition of target classes? First check if the target classes already declare a uses:, and if not add it. Sounds like simple metaprogramming ... > > Any comments on this 'solution'? should work. sometimes we did that for adding a new instance variable to a class when loading a package > > On 28 Apr 2010, at 01:56, StÃ©phane Ducasse wrote: > >> so far (and similarly to instance variable) you cannot with the current definition syntax >> declare a trait (add instance) to a class from a package that does not define the class. >> You can do that in the initialize of a class loaded in a package but there is no think like >> >> MyClass addInstanceVariable: 'x' >> MyOtherClass addTrait: >> >> at the similar syntax level than >> >>> FAMIXScopingEntity subclass: #FAMIXNamespace >>> uses: TAMStructuralZoom >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Famix-Core' >> >> this is why one day packages will have to be a bit better supported and more important >> we will have fix the "semantics" of changeset to be something than a simple side effect of 'oh this is easy' just save the class def and the method definition (because a class is a complex object). > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

April 28, 2010