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

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Tudor Girba

Thanks for reporting. I guess it is because the new Transcript is not yet 100% compatible with the old one. If you still want to try Moose, please just comment the Transcript open part and let us know what happens. Cheers, Doru On 27 Apr 2011, at 21:56, Casimiro de Almeida Barreto wrote: > In PharoDev-1.3.-13173 > > While loading Moose there's a 'Transcript open' in loadDefault. This > image's Transcript does not understand #open. It's preventing clear > installation of moose. > > Best regards, > > CdAB > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

April 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Camillo Bruni

Lukas once implemented a small MC Repository type that simple stores the source.st in a git repository. Due to changes in the recent pharo versions some of the git code didn't work anymore. So that's fixed now and you can use git for storing monticello versions. The following uses a local git repos as a monticello repository: MCGitRepository directory: 'test_git' Of course it is not fully useful since it uses a single file to store everything, rendering normal git tools unusable. Hence I will experiment tomorrow a bit on how to split up methods and classes into something more representable. I guess the trickiest part will be to tell git how methods and classes changed when they are renamed, but even that should not be such a problem.. In short, I will use github and share my code with the rest of the world ;). camillo On 2011-04-27, at 21:50, Tudor Girba wrote: > Hi, > > I am not sure I understand the implication. Could you explain, please? :) > > Cheers, > Doru > > > On 27 Apr 2011, at 21:37, Camillo Bruni wrote: > >> Thanks for your help :) >> >> So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;) >> >> On 2011-04-27, at 19:14, Max Leske wrote: >> >>> Concerning 2: >>> No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil. >>> >>> I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug... >>> >>> >>> On 27.04.2011, at 16:21, Camillo Bruni wrote: >>> >>>> Hi Max, >>>> >>>> I took another effort to work on the git bindings of MC. >>>> However I ran into troubles with FSGitFilesystem on commiting. >>>> >>>> 1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet... >>>> >>>> 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature >>>> does not throw an exception but simply returns nil? does this make sense? >>>> >>>> >>>> maybe you have a clue how to solve this faster than I do :-) >>>> >>>> camillo >>> >>> >> >> > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > >

April 27, 2011

Re: [Pharo-project] squeaksource is down - a different perspective

by Marcus Denker

On Apr 27, 2011, at 10:00 PM, StÃ©phane Ducasse wrote: > >>> squeaksource.com is down a lot. People get frustrated at times. >> >> Yes, and unfortunately it looks like people love to be frustrated. >> >> Otherwise people would give Tobias more feedback on SqueakSource3 (see [1]) which IMHO could overtake the job in the future and replace the >> problematic image? > > I do not know. > Do SS3 has a migration process? > How easy is it to install on an old machine? > Does gemstone run on a old mac g3? I think we could ask SCG for running it on one of the newer machines (64bit Linux). > Should we install glass? > I do not know. > Migration of existing data is the largest problem... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Sven Van Caekenberghe

On 27 Apr 2011, at 20:35, Henrik Sperre Johansen wrote: > Implementing use of CLDR data is the way to go if you want something that is > both reliable and works. This was mentioned by others too ( http://cldr.unicode.org/ ). That would indeed be a nice project, and no ugly plugins would be needed, pure Smalltalk only, that we all can understand and debug. Sven

April 27, 2011

Re: [Pharo-project] [ANN] PharoDev-1.3-13173

by Casimiro de Almeida Barreto

In PharoDev-1.3.-13173 While loading Moose there's a 'Transcript open' in loadDefault. This image's Transcript does not understand #open. It's preventing clear installation of moose. Best regards, CdAB

April 27, 2011

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

by Alain_Rastoul

Hi Tudor, Sad that it didn't help you :-(. You should contact Igor and see if he is still ok to play with your image, he may certainly be able to find something. I will try to find this too, because I experienced a similar problem loading an image saved with the vm I sent you (2G) in the standard vm (512M) after I've loaded data from odbc , the saved image was about 300 Mo and I had a memory error loading it with the standard vm. Unfortunatly I didn't keep this image, I reopend it with the 2G vm, found the hanging references and reduced it to 40M, but I think I could reproduce it. You can also send me your image (upload at at http://dl.free.fr with a notification email - see the web page) , I'll have a try with your image too. Cheers, Alain. "Tudor Girba" <tudor.girba(a)gmail.com> a Ã©crit dans le message de news: 3D8DCC66-E9DD-4AEB-AEC0-E10C615387C7(a)gmail.com... 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@mail.gmail.com... > 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 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Tudor Girba

Hi, I am not sure I understand the implication. Could you explain, please? :) Cheers, Doru On 27 Apr 2011, at 21:37, Camillo Bruni wrote: > Thanks for your help :) > > So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;) > > On 2011-04-27, at 19:14, Max Leske wrote: > >> Concerning 2: >> No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil. >> >> I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug... >> >> >> On 27.04.2011, at 16:21, Camillo Bruni wrote: >> >>> Hi Max, >>> >>> I took another effort to work on the git bindings of MC. >>> However I ran into troubles with FSGitFilesystem on commiting. >>> >>> 1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet... >>> >>> 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature >>> does not throw an exception but simply returns nil? does this make sense? >>> >>> >>> maybe you have a clue how to solve this faster than I do :-) >>> >>> camillo >> >> > > -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

April 27, 2011

Re: [Pharo-project] GitFs / MCGit

by Camillo Bruni

Thanks for your help :) So Lukas Git Repository for Monticello works again. ByeBye sqeaksource for me... ;) On 2011-04-27, at 19:14, Max Leske wrote: > Concerning 2: > No, it doesn't make sense at all to return nil. The reason that no exception is signalled is simply that that case should never be possible (not really an argument, I know :D). The method #packedObjectWithSignature is only sent if no loose object could be found. Then the packs are scanned and if the object isn't found in the packs the method returns nil. > > I think an exception would make a lot of sense but I didn't implement an exception handling mechanism for FSGit so a user will get slapped in the face with a debugger. Better though than having to track down that nil bug... > > > On 27.04.2011, at 16:21, Camillo Bruni wrote: > >> Hi Max, >> >> I took another effort to work on the git bindings of MC. >> However I ran into troubles with FSGitFilesystem on commiting. >> >> 1. I fail when saving the repos in GitCommit >> parents when it starts to lazily load the object which does not exist yet... >> >> 2. GitRespository >> packedObjectWithSignature: aGitObjectSignature >> does not throw an exception but simply returns nil? does this make sense? >> >> >> maybe you have a clue how to solve this faster than I do :-) >> >> camillo > >

April 27, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Henrik Sperre Johansen

On 27.04.2011 20:37, Henrik Sperre Johansen wrote: > Don't tell me you didn't have an idea this would happen :) > Or was it Igor I talked to it about in Lille? > > -- > View this message in context: http://forum.world.st/new-Cog-VMs-uploaded-tp3476543p3479109.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > Mmmhmm, that came out abit more distasteful in text than when phrased internally... The correct phrasing would be: "Sorry I haven't found time to finish the rewrite I talked about, during which I discovered this (didn't compile to see if it would cause an issue for Cog though), but probably neglected to tell you. For the reasons LocalePlugin is inadequate for those primitives as mentioned in other mail, I doubt I'll find motivation to finish it rather than do other things later on either." So, thanks for taking the effort of updating from trunk, sorry I couldn't be of any help. Cheers, Henry

April 27, 2011

Re: [Pharo-project] Bug while updating PharoCore

by Marcus Denker

I added a tracker entry: http://code.google.com/p/pharo/issues/detail?id=4104 I will see how to fix that. On Apr 27, 2011, at 5:59 PM, Casimiro de Almeida Barreto wrote: > While loading 13171-Pha-CleanupsFinderSearch debugger is raised with > Message not understood: Receiver of "load" is nil > > and: > > DoIt > | t1 | > t1 := MCHttpRepository > location: 'http://www.squeaksource.com/Pharo/' > user: '' > password: ''. > (t1 loadVersionFromFileNamed: 'ScriptLoader13-MarcusDenker.191.mcz') > load. > ^ ScriptLoader new update13171 > > Meaning ScriptLoader13-MarcusKender.191.mcz is not there or squeaksource > is down... > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 27, 2011