April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fix proposed to make alt+t open a transcript in PharoCore 1.3

by DougEdmunds

>We should role back to the old transcript... all of the many problems with transcript >will then be fixed. > Marcus Not too soon for me. -- View this message in context: http://forum.world.st/Fix-proposed-to-make-alt-t-open-a-transcript-in-Pharo… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2011

[Pharo-project] pseudo class

by Sean Allen

i've been poking around trying to figure out what pseudo class does in pharo and haven't really been successul. can someone give me some basic background on the role it serves?

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Eliot Miranda

with a fix for the VMs in 2379 to http://www.mirandabanda.org/files/Cog/VM/VM.r2380/. These pass Levente's shift/reset tests. Apologies for the earlier slip. On Tue, Apr 26, 2011 at 2:01 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/. These fix > shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale > plugin. > > best, > Eliot >

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Scott Gibson

I have been using and developing with it for the Mac OS. Thanks Eliot! Scott Gibson On Apr 26, 2011, at 5:01 PM, Eliot Miranda wrote: > ...to http://www.mirandabanda.org/files/Cog/VM/VM.r2379/. These fix shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale plugin. > > best, > Eliot -- Scott Gibson

April 27, 2011

Re: [Pharo-project] [Vm-dev] Re: A possible Cog bug (was: Re: [squeak-dev] Direct implementation of shift/reset in Smalltalk)

by Eliot Miranda

Hi Levente, 2011/4/26 Levente Uzonyi <leves(a)elte.hu> > > Hi Eliot, > > On Tue, 26 Apr 2011, Eliot Miranda wrote: > > Hi Levente, >> try out the latest VMs. They don't fix the bugs, but do change the >> symptoms. e.g. in >> >> c := [ 3 + PartialContinuationNotification signal ] >> on: PartialContinuationNotification >> do: [ :not | not continuation ]. >> c value: 4. "==> 7" >> >> there is now an MNU of #+ since 3 has been replaced by a MethodContext. >> >> So if I could ask you could dig in again, that would help. >> > > the symptoms are much better now. The cause of the MNU seems to be that the > copied contexts have some "junk" at their indexable slots. Implementing > ContextPart >> #copyTo: as below solves (hides) the problem. > > ContextPart >> copyTo: aContext > "Copy self and my sender chain down to, but not including, aContext. > End of copied chain will have nil sender." > > | copy | > self == aContext ifTrue: [ ^nil ]. > copy := self copy. > "Cog doesn't copy the temps properly, so copy them here." > 1 to: self size do: [ :i | copy at: i put: (self at: i) ]. > sender ifNotNil: [ copy privSender: (sender copyTo: aContext) ]. > ^copy > > To reproduce the "junk" copying bug, evaluate the following: > > | context | > context := thisContext copy. > { context. context copy } explore > > The first context's first slot will be nil, while the second context's > first slot will point to the sender context. Actually the indexable slots > are filled with the values of the fixed slots, that's why the sender context > is at the first indexable slot of the second context. Here's an example with > more indexable slots: > > | context a b c d e | > context := thisContext copy. > a := b := c := d := e := context. > { context. context copy } explore. > { a. b. c. d. e } "This is here to avoid compiler complaints." > Hmm... the above behavior is intentional and correct in that to speed up context-to-stack mapping Cog makes no guarantee to preserve the values of temporary values after a context has returned. You'll notice that the entire closure scheme is centered around this, in that temporaries that must outlive their dynamic extent for the correct working of blocks are either copied into blocks (as copied values) or stored into remote temp vectors, hence breaking any dependence on the temporaries in enclosing contexts. If you can live with this restriction then instead of stating "Cog doesn't copy the temps properly, so copy them here." in your reimplementation of copyTo: it would be more accurate to state "Cog doesn't preserve non-closed-over temps beyond their dynamic extent, so copy them here." or some such. Note that Cog /does/ preserve arguments. However, I've clearly still got some bug because look at the following. In the copy the arguments ba1 & ba2 (1 & 2) are in the wrong place on the stack. Sigh... [:ba1 :ba2| | context a b c d e | context := thisContext copy. a := b := c := d := e := context. { context. context copy } explore. { a. b. c. d. e } "This is here to avoid compiler complaints."] value: 1 value: 2 > > > Levente > > >> thanks! >> >> best, >> Eliot > > >

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by GermÃ¡n Arduino

2011/4/26 Eliot Miranda <eliot.miranda(a)gmail.com>: > ...toÂ http://www.mirandabanda.org/files/Cog/VM/VM.r2379/. Â These fix > shallowCopy and copyFrom: for contexts and (I hope) fix the linux Locale > plugin. > best, > Eliot Downloading. Thanks! -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

April 26, 2011

Re: [Pharo-project] roeltyper problem

by Lukas Renggli

Indeed, the same here. I didn't read your code and expected to see a debugger. Ask Frederic Pluquet, I think he added the support for the new blocks. There seems to be something wrong with the remote temp vectors that is beyond my scope. In the meantime you might want to try RBRefactoryTyper. It is much slower, as it is runs on the AST and thus needs to parse all methods. I think it is comparable in quality, the code can be understood quite easily, and it can even type things in collections. Lukas On 26 April 2011 22:44, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > Strange that it works for you. I just loaded your version in 1.2.1 and I still get the same problem (actually now I have only 28 classes with problems). > > What version of Pharo did you try it in? > > Cheers, > Doru > > > On 26 Apr 2011, at 21:03, Lukas Renggli wrote: > >> It works for me, please try the version here: >> http://source.lukas-renggli.ch/unsorted >> >> Lukas >> >> On 26 April 2011 20:31, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>> Hi, >>> >>> I am trying to use RoelTyper, but I encountered subscript out of bounds and empty collection errors. It looks like this problem can be reproduced on 29 classes from Pharo 1.2.1. You can test it using: >>> >>> classes := Dictionary new. >>> Object withAllSubclassesDo: [:each | >>> Â Â Â Â [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. >>> classes inspect >>> >>> I am not knowledgeable enough to dive into this. Can anyone help? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > -- Lukas Renggli www.lukas-renggli.ch

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Alexandre Bergel

I support the idea. However, I am not sure I want this from the PreDebugger. Alexandre On 26 Apr 2011, at 15:59, Mariano Martinez Peck wrote: > Hi guys...with just 2 little methods, I am able to add a button to the debuger and a button to the context of the debugger, to copy the stakctrace to clipboard. > Going to PharoDebug.log is anoying: > > 1) I never know where my image is, so I first need to do print Smalltlak imagePharo > 2) then I need to go to such folder, and open the PharoDebug.log > 3) most of the times, PharoDebug has appended a lot of other (un) issues so it is quite confusing to use such file for a bug report. Hence I need to: > 4) remove PharoDebug.log and > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > 6) finally search it again, open, and do the copy paste :) > > So....I think it should be muuuch easier from the debugger. So I added two possibilities > > 1) copy to clipboard from the "pre debugger windows" > See attached screenshot. > > 2) copy to clipboard from the debugger context menu. > See attached screenshot. > > So...do you like it? which one do you want of them ? both ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > <pre debugger .png><debugger context menu.png> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] Monticello doesn't always call all class side #initalize ?? [WAS] Re: a problem with Zinc on Pharo 1.1.1

by Alexandre Bergel

A few years ago, the situation was: If your class C defines (and not inherits) #initialize on its class side, then #initialize is executed when after being loaded by monticello. I am not sure what is the situation now. Cheers, Alexandre On 26 Apr 2011, at 16:01, Mariano Martinez Peck wrote: > > > On Tue, Apr 26, 2011 at 9:31 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote: > > > Second, I've seen that problem too. I am sure that when loading a new version of a certain package, some class side #initialize are not called. When? which ones? I have no idea. > > > > I couldn't reproduce it. Can you? > > I can't figure it out either, but I haven't really looked deeply into it. > > As far as I can tell it just doesn't work: I guess #initialize is only called when the class is new or maybe when its definition is changed, maybe when the #initialize method changes, but certainly not all the time when you load new(er) versions of methods of that class. Maybe that is too much to expect, I don't know, it would be handy. > > So when your #initialize calls say #initializeConstants and only that method is changed, you have a problem. > > Maybe somebody else knows ? > > Sven > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] out of memory - cog on windows

by Tudor Girba

Hi Alain, Thanks for the VM with more memory. I tried it, but it looks like we still get the same message. Where else can the problem be? Cheers, Doru On 21 Apr 2011, at 23:52, Alain_Rastoul wrote: > (And of course Tudor, I forgot to mention it but I can send you this vm if you need) > > "Alain_Rastoul" <alr.dev-GANU6spQydw(a)public.gmane.org> a Ã©crit dans le message de news: ioq86o$69j$1(a)dough.gmane.org... > I thought he was able to start it on a Mac that's why I suggested to this on a Mac and see if memory consumption was reduced. > BTW I have rebuild a cog vm with 2Gb ram for MAX_MEMORY and it runs ok on my 1Gb netbook > > "Mariano Martinez Peck" <marianopeck(a)gmail.com> a Ã©crit dans le message de news:BANLkTikuk1jRV34=u2pzTFx5+2qWgjrbCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org... > Alain: as far as I understood, he cannot even start the image...so he won't be able to open a workspace and evaluate something. > > Doru, if you can evaluate something in a workspace, you may also try SpaceTally new printSpaceAnalysis > and then check the STspace.text that is next to the image. That way you acn see if there are certain classes that have a lot of instances. > > Can you evaluate "Smalltalk garbageCollect " and tell me the answer? just curious.... > > thanks > > mariano > > On Thu, Apr 21, 2011 at 10:36 PM, Alain_Rastoul <alr.dev(a)free.fr> wrote: > Mmm, you are right, in old squeak versions, there was a parameter > -memory: xx (xx inMB) > but I don't know if it is still in use. > > BTW there must be some hanging references in memory and perhaps youd should > do some PointerFinder on it. > A very handy script I found (on Ramon Leon's blog or elsewhere I don't > remember) could help you. > You can try it in a workspace and see if it reduces your memory usage (after > save and quit) > comment unknown or unwanted commands : > | tasks | > tasks := OrderedCollection new > add: [MCFileBasedRepository flushAllCaches]; > add: [WARegistry clearAllHandlers]; > " add: [SMSqueakMap default clearCaches];" > add: [Smalltalk removeEmptyMessageCategories]; > add: [Workspace > allSubInstancesDo: [:each | each setBindings: > Dictionary new]]; > " add: [Undeclared removeUnreferencedKeys];" > " add: [Categorizer sortAllCategories];" > add: [ODBCConnection cleanAll]; > add: [Symbol compactSymbolTable]; > " add: [ReleaseBuilderDeveloper new fixObsoleteReferences];" > add: [Smalltalk garbageCollectMost]; > add: [Smalltalk garbageCollect ]; > add: [Smalltalk garbageCollect ]; > add: [Smalltalk garbageCollect ]; > add: [EventManager actionMaps keys do: [:each| EventManager > releaseActionMapFor: each] ]; > add: [Debugger closeAllDebuggers]; > add:[Debugger allInstances do: [ :d | d release ] ]; > > yourself. > UIManager default > informUserDuring: [:bar | tasks > do: [:block | > bar value: block printString. > [block value] > on: Error > do: [:error | Transcript show: error; > cr]]]. > > Regards > Alain > > "Tudor Girba" <tudor.girba(a)gmail.com> a Ã©crit > dans le message de news: 6AA1F065-3996-433B-AB7C-1640C08D5A7B-Re5JQEeQqe9Ui4FbrNnSJA(a)public.gmane.org > Hi, > > Should I to understand that the only way to enable more memory is to > recompile the VM? Does that mean that there is no way to pass this > information as a parameter like we can on Mac? > > The problem is that I cannot recompile the VM because I have no access to a > Windows machine. Is there one available that provides more memory? > > Cheers, > Doru > > > On 21 Apr 2011, at 22:09, Alain_Rastoul wrote: > > > Hi Tudor, > > > > There is a constant in sqWin32Alloc.h (platforms\win32\vm) : > > #define MAX_VIRTUAL_MEMORY 512*1024*1024 > > you can change it to whatever you want and rebuild the vm, > > for exzmple give all the available memory less 256 M . > > > > HTH > > > > Regards > > Alain > > > > "Tudor Girba" <tudor.girba(a)gmail.com> a > > Ã©crit > > dans le message de news: > > 03B9389F-C719-44D0-B106-2AC78B120F56-Re5JQEeQqe9Ui4FbrNnSJA-XMD5yJDbdMRG2NFembrH+g(a)public.gmane.orgorg > > Hi, > > > > We have no specific startUp: methods in Moose. In any case, the issue with > > opening the image does not seem to be related to startUp:. > > > > Is it really true that the Cog VM is limited to 512MB of memory? > > > > Cheers, > > Doru > > > > > > On 21 Apr 2011, at 14:27, Luc Fabresse wrote: > > > >> Hi Doru, > >> > >> 2011/4/21 Tudor Girba > >> <tudor.girba(a)gmail.com> > >> Hi, > >> > >> > >> > >> On Apr 21, 2011, at 14:06, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >> > >>> > >>> > >>> On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba > >>> <tudor.girba(a)gmail.com> wrote: > >>>> Hi again, > >>>> > >>>> I did not say what the problem was :). The problem was that when > >>>> opening the image on Windows, he got a Space is low message and the > >>>> image was not usable (see attachment). > >>> > >>> That's weird. Does moose have something on the startup list? something > >>> that can be bothering there? > >> > >> Not that I know of. Is there a way to check this? > >> > >> Classes should be registered using Smalltlak addToStartUpList: aClass > >> Then aClass class>>#startUp: is executed at startup. > >> So implementors of #startUp: on Moose classes should give you the answer. > >> > >> #Luc > >> > >> > >> Actually, using exactly the same process some days ago he produced an > >> image of 190MB. This one works just fine on Windows. The only difference > >> between the two is the size of the loaded data. > >> > >> It would be really bad news if the Windows vm would be so severely > >> limited > >> in terms of memory. > >> > >> Cheers, > >> Doru > >> > >> > >>> > >>> On Mac it worked just fine. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>> > >>>> > >>>> > >>>> > >>>> On 21 Apr 2011, at 12:52, Tudor Girba wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I received a question from someone running a 200MB image on Windows > >>>>> using Cog 2361. > >>>>> > >>>>> If I open the image on Mac, it works just fine. Unfortunately, I do > >>>>> not have a Windows machine around, and I cannot test but I believe it > >>>>> should be solvable by increasing the allocated memory. > >>>>> > >>>>> On Mac, I would run it with: ./Croquet -memory 1500m > >>>>> > >>>>> Can anyone help me with the right incantation for Windows? > >>>>> > >>>>> Cheers, > >>>>> Doru > >>>>> > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> > >>>>> "What we can governs what we wish." > >>>>> > >>>>> > >>>>> > >>>>> <Space is low.png> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Yesterday is a fact. > >>>> Tomorrow is a possibility. > >>>> Today is a challenge." > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > > > > -- > > www.tudorgirba.com > > > > "Beauty is where we see it." > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Live like you mean it."

April 26, 2011