November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3351 in pharo: Comments in MIMEDocument erroneously refer to MIMEObject

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.2 Comment #4 on issue 3351 by marcus.denker: Comments in MIMEDocument erroneously refer to MIMEObject http://code.google.com/p/pharo/issues/detail?id=3351 12254

Nov. 30, 2010

Re: [Pharo-project] Issue 3354 in pharo: Clean of RecentMessageList

by pharo＠googlecode.com

Updates: Status: Started Labels: Milestone-1.2 Comment #2 on issue 3354 by marcus.denker: Clean of RecentMessageList http://code.google.com/p/pharo/issues/detail?id=3354 1) can you commit to the inbox instead? 2) I can not merge the package. 'Could not find version ''RecentSubmissions-StephaneDucasse.52''. Maybe you need to add a repository?'

Nov. 30, 2010

Re: [Pharo-project] Issue 3358 in pharo: Another fix for SourceReference

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.2 Comment #1 on issue 3358 by marcus.denker: Another fix for SourceReference http://code.google.com/p/pharo/issues/detail?id=3358 12264

Nov. 30, 2010

Re: [Pharo-project] Issue 3359 in pharo: categorize some methods

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3359 by marcus.denker: categorize some methods http://code.google.com/p/pharo/issues/detail?id=3359 12264

Nov. 30, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Mariano Martinez Peck

On Sun, Nov 21, 2010 at 5:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Obviously you can't having a single object representation (a tagged > machine word with lowest bit set) > and have two different classes for it. > > Yes, that's true. The thing is that I have a big problem using SmallInteger as proxies....So far I always used a subclass of ProtoObject for the proxies. This is cool because most of the messages are not understood by ProtoObject, thus I can intercept most messages. Now, the problem using SmallInteger as proxies is that there are several methods that ARE understood by both. This is a big problem because the original CompiledMethod is not installed, and the method answers but with a different value. For example, suppose I do something like this: MyClass methodDict at: #foo put: 5. (MyClass >> #foo) size In this case, I would like that size is NOT understood by the proxy and that loads back the original compiled method. But this is not the case since SmallIngeger DOES understand the message #size. Thus, it answers...and something different than the size of the compiled method... So in summary I have problems with all methods that are understood by both, even all those in Object I think... Best regards, Mariano > On 21 November 2010 16:51, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Sun, Nov 21, 2010 at 12:13 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > >> On Sat, 20 Nov 2010, Mariano Martinez Peck wrote: > >> > >>> On Sat, Nov 20, 2010 at 5:41 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >>>> > >>>> The only problem is that you can't swap-out a method that's used by > the > >>>> swap-in code. > >>>> > >>>> > >>> Yes, but that's easy to solve. Before swapping everything, I "simulate" > >>> the > >>> swapping of a dummy CompiledMethod. During that, I mark all the > >>> CompiledMethods that were used to perform that. And then, I exclude > those > >>> objects from being swapped :) > >> > >> That won't work, because during the simulation you'll only try a single > >> execution path. Swapping in a real method may invoke methods that > weren't > >> used during the simulation. For example my implementation uses > #storeString > >> to serialize the methods and Compiler >> #evaluate: to deserialize them. > So > >> during deserialization a lot of different methods may be invoked. > > > > Ahhh I got it.... > > > > Are you using Cog? because with the SmallInteger I have the problem I > > described with #run:with:in: > > > > Last question....to use SmallIntegers, I need to put some methods in > > SmallInteger, like #run:with:in: , #doesNotUnderstand: , and all the > > methods related to writing and loading back the original compiledMethod. > Of > > course I can put all those methods under a category *MyProxyPackage ... > > but I was thinking if there is another way. I would love to have > > MySmallIntegerProxy that extends from ProtoObject (because I want my > proxy > > to understand as less messages as possible) and that is threated by the > VM > > like a SmallInetger, I mean, that it directly stores the number value in > the > > address, and put the last bit in 1. > > > > Is this possible? how much work can it be? > > > > Thanks in advance, > > > > Mariano > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Nov. 30, 2010

Re: [Pharo-project] SimpleTraits - How can we have Traits/Mixins quickly?

by Peter van Rooijen

:) On Mon, 29 Nov 2010 17:14:25 +0100, Johan Brichau <johan(a)inceptive.be> wrote: > > On 29 Nov 2010, at 16:38, Peter van Rooijen wrote: > >> Now it seems that Traits have somehow not "made it" into >> Pharo and I believe with you that it is a shame not to have it. > > there's no need to despair: traits *are* in Pharo ;-) > > > -- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048

Nov. 30, 2010

Re: [Pharo-project] <script language="smalltalk">

by Simon Denier

On 26 nov. 2010, at 19:26, Janko MivÅ¡ek wrote: > On 26. 11. 2010 18:20, csrabak(a)bol.com.br wrote: >> Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt(a)gmail.com > escreveu: > >>> A Smalltalk variant would use Smalltalk as the source language >>> instead of Java, the other parts of GWT can be reused. GWT is open >>> source (Apache 2.0 license). > >> I think we have first to evaluate to what audience/market are thinking of >> targeting this effort, then estimate the effort, in order to see if its >> worth it. > > Specially we the web guys are very interested of such a beast, because > we need to develop more in more on the client side and in JavaScript, > which is a bit hard, because of our Smalltalk habits, you know :) > > Even more, Smalltalk on the client (Clamato way) can also solve one of > the main JavaScript problems: debugging on the client side. If we can > have near the same debugger on the client as we have in our IDE's, well, > this would be a huge step forward. Well then, We have the Smalltalk IDE but nobody is interested to look at it because it's Smalltalk. We have Seaside but nobody is interested to look at it because it's Smalltalk. But maybe if someone brings a Javascript IDE built in Smalltalk, people will start to look at it :) We may even already have one edge with PetitParser. (and the trick is of course that you don't advertize Smalltalk, you advertize Javascript). Strangely, this reminds me of the story of Lucid which built a powerful C++ IDE... in Lisp. This leads to XEmacs. http://www.jwz.org/doc/lemacs.html http://dreamsongs.com/Cadillac.html -- Simon

Nov. 30, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Tudor Girba

Hi, Here is the apache2 configuration we use for the hudson.moosetechnology.org server. Perhaps it is useful: <VirtualHost *> ServerName hudson.moosetechnology.org DocumentRoot /srv/hudson.moosetechnology.org/web <Location /> Order deny,allow Allow from all </Location> RewriteEngine On RewriteRule ^/(.*)$ http://localhost:XXXX/$1 [proxy,last] ProxyPassReverse / http://localhost:XXXX/ ProxyRequests Off <Proxy http://localhost:XXXX/*> Order deny,allow Allow from all </Proxy> </VirtualHost> Doru On 30 Nov 2010, at 09:37, Marcus Denker wrote: > > On Nov 29, 2010, at 11:08 PM, Miguel CobÃ¡ wrote: > >> >> One question, you have the pharo-project.org domain, why isn't this >> hudson a subdomain of that domain. Hosted on inria, but accessible by >> the official project domain? >> > One step at a time :-) > > >> Anyway, very good news. I suppose that the download page of pharo will >> point to the latest successful build link of the hudson server very >> soon. > > > Yes... that's the goal. The artefact that people download should be generated completely > automatically. (This way we can move much faster). > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Nov. 30, 2010

Re: [Pharo-project] Issue 3172 in pharo: NewInspector really really slow while parsing XMLNode

by pharo＠googlecode.com

Comment #3 on issue 3172 by fredericpluquet: NewInspector really really slow while parsing XMLNode http://code.google.com/p/pharo/issues/detail?id=3172 The problem is that the label of each node is given by the method niLabel that calls the method printString on the object. In our example, the method printString returns a large string, taking time to be displayed in the tree. In the last version of NewInspector (just posted), I fix this problem: the maximum size of a label is limited to 500 characters. There is no more slowdown.

Nov. 30, 2010

Re: [Pharo-project] How to update Pharo

by Mariano Martinez Peck

On Mon, Nov 29, 2010 at 8:20 PM, Tony Fleig <tony.fleig(a)gmail.com> wrote: > In the document at: http://code.google.com/p/pharo/wiki/HowToContribute, > I find > > > - Download the latest Pharo image from > http://code.google.com/p/pharo/wiki/Downloads?tm=2. > - Launch the fresh image and load the latest updates by using the > option in the menu. > > > The Pharo-1.1 One-Click image has no "update" option in the menu. Should I > be using a different image? > > How would I go about updating the One-Click image "manually"? > > You cannot. The Pharo image or the one click CANNOT be updated. The only images that can be updated are the PharoCore and just inside the same version family. If you have 1.1, then the only update is Pharo 1.1.1 but it only has fixes to run with CogVM. There is no dev image for 1.2 yet....so wait :) If you want to know why you cannot update a Pharo image, check in the web interface of the mailing list and I promise there are hundreds of emails explaining. Cheers Mariano

Nov. 30, 2010