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

[Pharo-project] ANyone have a fix for Scanner isLiteralSymbol: #<=?

by Eliot Miranda

Hi All, In trunk Scanner isLiteralSymbol: #<= answers false ?!?! This is breaking my Cog generated code disassembly decoration so that instead of 000a572c: movl $0x0045a458=#<=, %ecx : B9 58 A4 45 00 000a5731: call .+0xfff5ad5a (0x00000490=ceSend1Args) : E8 5A AD F5 FF I'm merely getting 000a572c: movl $0x0045a458, %ecx : B9 58 A4 45 00 000a5731: call .+0xfff5ad5a (0x00000490=ceSend1Args) : E8 5A AD F5 FF Anyone have a fix? best Eliot

Nov. 18, 2010

Re: [Pharo-project] XOR: don't recieve a block

by Marcus Denker

On Nov 18, 2010, at 6:58 PM, Levente Uzonyi wrote: > On Thu, 18 Nov 2010, Marcus Denker wrote: > >> >> On Nov 18, 2010, at 6:34 PM, StÃ©phane Ducasse wrote: >> >>> & | don't >>> Do not cnfuse lazy and the others. >> >> >> true xor: [false] >> >> --> walkback. >> >> false xor: [false] >> >> --> [false] >> >> There is a call to #value missing (which will keep it working with booleans, too, as they understand >> #value, too (returning self)). > > That's a possible solution, but xor can't be lazy, so the block is just pointless. > So the question is if we do it for consistency... (between or:, and:, xor:. They are so close that it's strange to have different parameters for them. On the negative side, it does cost a send of #value (quick return self) for the case that one calls it on a boolean... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 18, 2010

Re: [Pharo-project] Howto measure memory footprints of functions/objects/libraries in Pharo?

by Alexandre Bergel

Hi Max, Sorry to have taken some time to reply. You helped us to find a bug. This is now fixed (I never redefine #= that is why I did not see it before). Try the following: repo := FSGitRepository on: FSDiskFilesystem current working / 'foo'. MemoryProfiler viewProfiling: [ repo tagNames ] inPackage: 'FS-Git' And you will immediately spot the methods that consume memory :-) Cheers, Alexandre On 12 Nov 2010, at 17:40, Max Leske wrote: > Hi Alexandre > > The weird behaviour seems to be related to inline compilation in workspaces. I moved the execution into a method, now everything's back to normal. > > In the meantime I verified the previously described scenarios with a fresh one-click image (Pharo 1.1). > One really dramatic example is this: > > repo := FSGitRepository on: FSDiskFilesystem current working / 'foo'. > MessageTally spyOn: [ repo tagNames ] > > ---> 3ms for a huge repository with 10 tags. > > > MemoryProfiler > viewProfiling: [ repo tagNames ] > > ---> low space warning (same repository etc.) > > > I hope you might have an idea what's going wrong. > > Cheers, > Max > > > > > Hi again. > Please ignore the last e-mail for the moment. There's something weird going on in my image. I'll run some tests on a fresh official image first and then post back. > Max > > > --------------------------------- > Thanks Alexandre. > Now I tried out your example and they worked perfectly. I have run into two problem though which I don't know how to deal with: > 1. When I run anything else than what you suggested, I do get the window for the profiling view but it is empty. E.g when I run this: > > MemoryProfiler > viewProfiling: [ 1 to: 100000 do: [ :i | > (FSMemoryFilesystem new root / ('foo', i asString)) > writeStreamDo: [ :stream | stream nextPutAll: 'foo' ] ] ] > 2. When I run the code I am actually interested I get a low space warning. Example: > repo := FSGitRepository on: FSMemoryFilesystem new root / 'foo' > MemoryProfiler > viewProfiling: [ repo head ] > > I'll be happy to run any tests you suggest. If you'd like to run the code yourself, get the packages from Gofer: > Gofer new > squeaksource: 'GitFS'; > package: 'FS-Git'; > package: 'Filesystem'; > load. > Cheers, > Max > > > On 09.11.2010, at 22:42, Alexandre Bergel wrote: >> Hi Max, >> >>> Um... I should be able to get a visualisation by running somthing like this right (I only installed it, didn't subclass anything)? >>> >>> MemoryProfiler >>> >> viewProfiling: [ FSDiskFilesystem current working / foo ]. >>> >>> I get a window but there's nothing in it... >> >> The piece of code you want to profile needs is executed twice, and it needs "to be time consuming" (~ 1 second). >> For example, try: >> >> MemoryProfiler >> viewProfiling: [ >> | view | >> >> view := MOViewRenderer new. >> view nodes: (1 to: 5000). >> view root applyLayout ] >> >> or >> >> MemoryProfiler >> viewProfiling: [ (1 to: 2) collect: [ :i | ConfigurationOfMetacello project currentVersion ] ] >> >> to get a nice picture >> >>> Also, is selecting the expression in the block above, right clicking and selecting "memory profile it" equivalent to sending #viewProfiling: ? >> >> yes >> >>> Reading your paper I get the idea that this should work, when looking at the instructions on the moose site it rather seems that I need to subclass MemoryProfiler to actually profile anything. >> >> No need to subclass. >> >> Cheers, >> Alexandre >> >>> >>> >>> >>> On 09.11.2010, at 15:02, Alexandre Bergel wrote: >>> >>>> Ok, but please, provide feedback. >>>> >>>> Alexandre >>>> >>>> >>>> On 9 Nov 2010, at 10:40, Max Leske wrote: >>>> >>>>> Sounds like what I just needed! I'll try it out. >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> On 09.11.2010, at 12:42, Alexandre Bergel wrote: >>>>> >>>>>> Hi Guido, >>>>>> >>>>>> We wrote a profiler to keep track of memory consumption. >>>>>> >>>>>> http://bergel.eu/download/papers/Berg10g-MemoryProfiling.pdf >>>>>> >>>>>> It will be presented at Smalltalks next week. >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> On 8 Nov 2010, at 23:47, Guido Stepken wrote: >>>>>> >>>>>>> E.g.: Three different solutions for a Euler problem: >>>>>>> >>>>>>> (1 to: 999) inject: 0 into: [:sum :i | (i \\ 3 = 0) | (i \\ 5 = 0) >>>>>>> >> ifTrue: [sum + i] >>>>>>> >> ifFalse: [sum]] >>>>>>> >>>>>>> >>>>>>> (1 to: 999) detectSum: [:i | (i \\ 3 = 0) | (i \\ 5 = 0) ifTrue: [i] ifFalse: [0]] >>>>>>> >>>>>>> (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)] >>>>>>> >>>>>>> How do i measure the exact memory footprint of each solution? >>>>>>> >>>>>>> Pharo claims having reduced memory footprint at many places. Can that be proofed, e.g. with one comparable demo app, once run in old squeak, once in Pharo 1.1/1.2? >>>>>>> >>>>>>> And no, MessageTally spyOn: does not do right! >>>>>>> >>>>>>> Tnx in advance, Guido Stepken >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 18, 2010

Re: [Pharo-project] XOR: don't recieve a block

by Levente Uzonyi

On Thu, 18 Nov 2010, Marcus Denker wrote: > > On Nov 18, 2010, at 6:34 PM, StÃ©phane Ducasse wrote: > >> & | don't >> Do not cnfuse lazy and the others. > > > true xor: [false] > > --> walkback. > > false xor: [false] > > --> [false] > > There is a call to #value missing (which will keep it working with booleans, too, as they understand > #value, too (returning self)). That's a possible solution, but xor can't be lazy, so the block is just pointless. Levente > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Nov. 18, 2010

Re: [Pharo-project] Pharo beginner bugs ....

by Levente Uzonyi

On Thu, 18 Nov 2010, Guido Stepken wrote: > Beginners Bugs in Pharo 1.1 on Linux: > > In System Browser i choose Tools-Base->Workspace->initization->initialize > > and see code > > os := (Smalltalk platformName) > > hmmm. > > I open Shout Workspace, type Smalltalk pl ... and i get 'platformFamily' > suggested. No 'platformName' offered by Shout completion mode. By default OCompletion only knows about methods in Kernel* and Collection* packages. SmalltalkImage is in System*. You can add extra packages by evaluating [OCompletionTable initializeWithPackages]. You could even write * as the filter, but it's very slow in Pharo 1.1 and OCompletion will lose most entries, because it only caches 40 methods per two letter prefix. I'm thinking about increasing that, because it's sometimes really annoying. > > And: I cannot choose from other offers in suggestion list by clicking with > mouse. Why? When you're typing you rarely use the mouse. The arrows are more conventional. If you need that feature, then open an issue on the Pharo tracker. > > Linux Problem? > > Next example: In Shout Workspace i enter: TTSampleFontMorph new openInWorld. > <ALT-P> > > I get an error and a ghostframe, that i cannot delete. And: Completion mode You could use the halos to delete it, but they are disabled in Pharo by default. > when i enter TTSample ... does not work. Fuck! TTSamlpe* is in Morphic* (see above why that matters). > > What are you guys thinking of your work on Pharo, e.g. quality testing? > > Did you never notice, that even the basics of completion mode in Shout > Browser are buggy? Shout doesn't do code completion. If you're talking about the Alt-Q (Cmd-Q) completion, then it's really bugged in Pharo. If you think that you've found a bug in OCompletion, then open an issue in the Pharo issue tracker. > > Then i open in World Menu: Tools->Filebrowser i get Error:Invalid utf8 input > detected > > We need a perfectly running Pharo on Linux/Wine (Ubuntu 9.10). And no, no MAC > here anywhere in schools in germany. > > Can you imagine, that a teacher and his pupils drive mad on such simple bugs? > > So i have to teach with SCRATCH or BYOB in class. No serious bugs, no > problems. Are those bad? Levente > > regards, Guido Stepken > >

Nov. 18, 2010

[Pharo-project] Issue 3270 in pharo: fix xor: to work with blocks and booleans

by pharo＠googlecode.com

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3270 by marcus.denker: fix xor: to work with blocks and booleans http://code.google.com/p/pharo/issues/detail?id=3270 ... so that it works like or: (calling #value on the argument. This means it will continue to work with booleans, too). Attachments: XOr.1.cs 903 bytes

Nov. 18, 2010

Re: [Pharo-project] XOR: don't recieve a block

by Marcus Denker

On Nov 18, 2010, at 6:34 PM, StÃ©phane Ducasse wrote: > & | don't > Do not cnfuse lazy and the others. true xor: [false] --> walkback. false xor: [false] --> [false] There is a call to #value missing (which will keep it working with booleans, too, as they understand #value, too (returning self)). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 18, 2010

Re: [Pharo-project] XOR: don't recieve a block

by Diogenes Moreira

Oki. Sorry. On Thu, Nov 18, 2010 at 2:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > & | Â don't > Do not cnfuse lazy and the others. > > Stef > > On Nov 18, 2010, at 6:24 PM, Diogenes Moreira wrote: > >> Hi folks.. >> >> i found today, that xor: don't recieve a block and recibe aBoolean >> >> i can guess, Â it is wrong, because, the other logic operations >> recieve blocks like parameters.. >> >> I this a bug? >> >> >> Best Regards >> > > >

Nov. 18, 2010

Re: [Pharo-project] XOR: don't recieve a block

by StÃ©phane Ducasse

& | don't Do not cnfuse lazy and the others. Stef On Nov 18, 2010, at 6:24 PM, Diogenes Moreira wrote: > Hi folks.. > > i found today, that xor: don't recieve a block and recibe aBoolean > > i can guess, it is wrong, because, the other logic operations > recieve blocks like parameters.. > > I this a bug? > > > Best Regards >

Nov. 18, 2010

Re: [Pharo-project] Not happy with the issues feed from Google

by StÃ©phane Ducasse

+1 Sorry guys this is not optimal but after been against when I see it in squeak, I'm in favor because it helps understanding what is happening. Sorry to be blunt but ****YOU**** yes you guys do not look at the bug or bug fixes in general. So often ME myself and I, have to send email about point from the archive to the mailing-list. Often I do not even see that a bug has been posted and YES I have 5 rss feed and I read them all. What is the last time you read the bug archives to see what is happening there? So if you do not read the archive then how can you help? how can we make sure that people are aware? What is the last time you look at the code of the fixes that got integrated? Because if you do not read it how can we do quality control? So if I could I would send the diff of all the package in the mailing-lits as this is done in squeak. Now what we can do to please some of you so far 4, we could create a mailing-list where such mails would be sent. But let us see so far who is really against. Stef > Remember that most email client support filters. You can easily create one. > > Cheers > > Mariano

Nov. 18, 2010