- Pharo-dev - lists.pharo.org

cleaning the Pharo Catalog

by Esteban Lorenzano

Hi guys, I will update the Catalog for Pharo 6 and I was wondering if we should keep the âUnsortedâ categoryâ¦ this corresponds with projects present in old MetacelloRepository repo, I added it at the beginning because I did not want those project to be lost, but in fact they are more or less abandonware and definitively, they were not very well kept (no descriptions, no tags and even worst, many of them will not load fine). So what do you think? should I keep them? Esteban

May 23, 2016

Re: [Pharo-dev] [squeak-dev] Re: From a mooc user: method source with it' take so long in Pharo 5

by Martin Dias

Hi all, On Sun, May 22, 2016 at 12:26 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Henrik, > > cc'ing squeak-dev cuz this is relevant to both communities (if and > until Pharo takes the unwise decision to double the size of the image by > keeping sources in the image). > > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no> > wrote: > > There is a method in SourceFileArray > #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which > uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray > (see #localProcessReadOnlyCopy). Changing the last line in > #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the > time to run this snippet: > > > > [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: > false ] timeProfile > > > > From ~ 10 seconds to ~ 3 seconds (Windows). > > > > However I cannot see that the file handles created by this > processLocalVariable to ever be closed, so I suspect those are leaked? In > that case there might be the need to implement some âclean upâ mechanism > for ProccessLocalVariables before they are changed/nilled when a process > changes. > > > > Another approach could be to not use a ProccessLocalVariabe at all, but > extend the SourceFilesArray class to also hold one read only handle for > each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess > that it is also necessary then to have semaphore protecting the two last > lines such that setting the position in the stream and reading from it > cannot be changed by other threads. > > > I like this approach, but it has a fatal flaw. If one is debugging file > access, then as the debugger causes the source of methods to be fetched as > the debugger displays them, so the file pointer in the read-only file the > access of which one is trying to debug will change under one's feet, and > the results will be completely wrong. > > An approach which uses a special copy for the debugger doesn't work; one > can't debug access to that file for the same reason. > > An approach that /should/ work is for the debugger to install its own copy > around file-access. This should be recursive. So around every file access > in the debugger there would need to be something like > > SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] > > which would remember the current read-only files, evaluate the block using > ensure: and have the ensure: block reinstall the previous file. > > Does this make sense? > > Interesting discussion. We could give a new try on the "local process read-only copy". It was me who started with it last year in a Pharo sprint, but disabled it due to some errors... and didn't spend more time on it afterwards. it was reported here: https://pharo.fogbugz.com/f/cases/15782 the reason to disable it: https://pharo.fogbugz.com/f/cases/15781/ none of them is very clear as documentation of the problem. > > readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock > ifAbsent: absentBlock > > > > | stream result| > > stream := self readOnlyFileAt: index. > > stream ifNil: [ ^ absentBlock value ]. "sources file > not available" > > > > position > stream size ifTrue: [ ^ absentBlock value ]. > > > > readSema critical: [ > > stream position: position. > > result := presentBlock value: stream > > ]. > > > > ^ result > > > > > > Best regards, > > Henrik > > > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *On Behalf Of *Nicolai Hess > *Sent:* Thursday, May 19, 2016 9:31 AM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] From a mooc user: method source with it' take > so long in Pharo 5 > > > > Squeak caches the opened readonly file(handle). It does not have to reopen > the file on every call for reading (readonly). > > > > 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > > I am wondering why does the search 'method source with it' take so long in > Pharo 5? On my PC, When I select the text 'menu' and search for all 'method > source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 > seconds. > > > > > > >

May 23, 2016

Re: [Pharo-dev] Random is not random at startup

by Martin McClure

On 05/21/2016 01:56 PM, stepharo wrote: > I checked and CMWC Marsaglia is part of polymath > > > PMNumberGenerator allSubclasses an > OrderedCollection(PMBernoulliGenerator PMBinomialGenerator > PMConstantGenerator PMExponentialGenerator PMGaussianGenerator > PMPoissonGenerator) > > PMRandomGenerator allSubclasses an > OrderedCollection(PMMarsagliaKissRandom PMLehmerRandomGenerator > PMLinearCongruentialRandomGenerator PMMersenneTwisterRandomGenerator > PMParkMillerMinimumRandomGenerator) > > So we could pick one of them for Pharo. > Stef > I don't see CMWC in PolyMath. The only Marsaglia algorithm I see there is KISS (which from my reading of the literature is both more complex than and inferior to CMWC). But the Mersenne Twister is there, and though complex (possibly unnecessarily so) it is good, AFAICT. Regards, -Martin

May 23, 2016

Re: [Pharo-dev] compiledcode ?

by ClÃ©ment Bera

I will do a slice today. On Mon, May 23, 2016 at 12:49 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Would it be possible to add some comments, please. > > CompiledMethod is now a subclass of the new class CompiledCode (and there > is another > class CompiledBlock). > > Can we please don't add new classes at this system level without *any* > comment. > > nicolai >

May 23, 2016

compiledcode ?

by Nicolai Hess

Would it be possible to add some comments, please. CompiledMethod is now a subclass of the new class CompiledCode (and there is another class CompiledBlock). Can we please don't add new classes at this system level without *any* comment. nicolai

May 22, 2016

Re: [Pharo-dev] Using the stack and garbage collector?

by Alexandre Bergel

Very right! I should have guessed this. Thanks! Cheers, Alexandre > On May 22, 2016, at 3:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 15000! is a huge number, this computation involves large integer arithmetic. Large integers are allocated on the heap. Try a small number (to stay within Small integer range) and you'll see there is no GC activity. > > BTW, the implementation of #factorial is not the correct algorithm when speed and efficient large integer arithmetic are required. > > Please use the pharo-user ML for these kind of general questions. > >> On 22 May 2016, at 20:12, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi! >> >> The following expression give me 102: >> -=â=-=-=â=-=-=â=-=-=â=-= >> old := Smalltalk vm parameterAt: 9. >> 15000 factorial. >> new := Smalltalk vm parameterAt: 9. >> new - old >> -=â=-=-=â=-=-=â=-=-=â=-= >> >> I find that surprising. Why is the garbage collector used if factorial solely use the stack? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 22, 2016

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

by Henrik Nergaard

If the cursor uses a solid fill (color) only it should be redrawn, and when it blinks "off" only the RubScrolledTextMorph (if it has a solid fill), and any of it submorphs which intersects with the damage area should be redrawn. (drawing is being called for the full window) The only area modified is that within the clipping rect of the canvas (damaged area). For non-complex drawing (system window only draws a rectangle with border) filling over a small area should not be noticeable performance wise (as long as the submorph tree is not too deep), but should be fixed. I think the best place to start looking at and improving is in WorldState >>#drawWorld:submorphs:invalidAreasOn: Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Sunday, May 22, 2016 9:50 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations Hi, flash damaged areas is not showing me anything :( but still, you seems to be in agreement with me and what is happening *should not* happen, isnât? (drawing is being called for the full window) btw, this is not just a rubric problem, it happens if I put a PluggableTextMorph as well. cheers! Esteban > On 22 May 2016, at 21:28, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > Hi Esteban, > > To see the damage live: > SystemSettings->Tools->Debugging->Flash damaged morphic region. > > Redrawing: > Only morphs whose area is within the visible draw region of the canvas (the damaged area) needs to be redrawn, so if a morph fullbounds is not intersecting with this area it will not be drawn, and its submorphs will not check deeper in this submorph hierarchy. > The exclusion is done in #fullDrawOn: by "(aCanvas isVisible: self fullbounds) ifFalse: [ ^self ]. > So if the cursor reports a damage rectangle only morphs intersecting with that area needs to be redrawn (there is also some layering mechanism IIRC so that it should only re-draw the visible layers in that area, and not morphs which are covered by their submorphs). > > DamageRecorder: > The damage recorder do not know about any layering of morphs when it records damage. This means that if there is two overlapping windows in the World, and the window in the back triggers an invalid area which intersects with the window above, it will have to be redraw for that area as well even though it is not necessary. > > There is also the issue where multiple small areas close to each other need multiple passes to be completed. If the damage recorder has damage in (10@10 corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 50@50) will be redrawn twice during that cycle. > > Rubric: > There is some issues with how rubric handle changes, which causes blinking the cursor to do way to much work that it actually have to do, I think it also invalidates the whole selection and needs to redraw that as well. > > > > Best regards, > Henrik > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf > Of Esteban Lorenzano > Sent: Sunday, May 22, 2016 8:36 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] weird tales about cursors and rectangle > invalidations > > Hi, > > Iâve been playing a bit today with something that is puzzling me and I need some more eyes in what Iâm doing, because it might be that Iâm understanding everything wrongâ¦ but if not, then, huston, we have a bug. > So, play with meâ¦ you need to create this: > > SystemWindow subclass: #XSystemWindow > instanceVariableNames: 'iteration' > classVariableNames: '' > package: âXXX' > > XSystemWindow>>initialize > super initialize. > iteration := 0. > > XSystemWindow>>drawOn: aCanvas > âDo not use transcript because it does even more crazy stuff" > Stdio stdout << (iteration := iteration + 1) asString; cr; lf. > super drawOn: aCanvas > > > Then execute this in a playground: > > XSystemWindow new > addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: LayoutFrame identity; > openInWorld. > > and then you can watch in your stdout how full window redraws with cursor blinking (it stops when window loses focus). > > This happens because cursor is displayed with lapsus of 700ms and is just a draw of a line with a color who is set to itâs opposite each time. Then it does "color: shownColorâ and #color: sends #changed who finalise in #invalidRect. > I always thought that this invalidation mechanism works by recording âdamaged areasâ, then collecting morphs with that area and triggering the redraw of that morph. > With this in mind, cursor should trigger an invalidation of itâs own area (a small portion of the screen, as you can see). > I could understand that a cursor triggers the text area redraw (but that would be a âdesign flawâ, IMO)â¦ now, what I cannot understand is why blink a cursor triggers the redraw of a FULL WINDOW. > When in Nautilus, that means each cursor blink triggers the redraw of one tree, four lists, some buttons and finally, the text area. > IMO, this is not acceptable. > > What do you think? > > Esteban

May 22, 2016

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

by Henrik Nergaard

I thought that they were merged into a larger one. Only if there is significant overlap between a new damage and current recorded damages, or if the amount of invalid rectangles size is >= 50. (see DamageRecorder >>#recordInvalidRect:) -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Sunday, May 22, 2016 9:49 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations Le 22/5/16 Ã 21:28, Henrik Nergaard a Ã©crit : > Hi Esteban, > > To see the damage live: > SystemSettings->Tools->Debugging->Flash damaged morphic region. > > Redrawing: > Only morphs whose area is within the visible draw region of the canvas (the damaged area) needs to be redrawn, so if a morph fullbounds is not intersecting with this area it will not be drawn, and its submorphs will not check deeper in this submorph hierarchy. > The exclusion is done in #fullDrawOn: by "(aCanvas isVisible: self fullbounds) ifFalse: [ ^self ]. > So if the cursor reports a damage rectangle only morphs intersecting with that area needs to be redrawn (there is also some layering mechanism IIRC so that it should only re-draw the visible layers in that area, and not morphs which are covered by their submorphs). > > DamageRecorder: > The damage recorder do not know about any layering of morphs when it records damage. This means that if there is two overlapping windows in the World, and the window in the back triggers an invalid area which intersects with the window above, it will have to be redraw for that area as well even though it is not necessary. > > There is also the issue where multiple small areas close to each other need multiple passes to be completed. If the damage recorder has damage in (10@10 corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 50@50) will be redrawn twice during that cycle. I thought that they were merged into a larger one. > > Rubric: > There is some issues with how rubric handle changes, which causes blinking the cursor to do way to much work that it actually have to do, I think it also invalidates the whole selection and needs to redraw that as well. > > > > Best regards, > Henrik > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano > Sent: Sunday, May 22, 2016 8:36 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] weird tales about cursors and rectangle invalidations > > Hi, > > Iâve been playing a bit today with something that is puzzling me and I need some more eyes in what Iâm doing, because it might be that Iâm understanding everything wrongâ¦ but if not, then, huston, we have a bug. > So, play with meâ¦ you need to create this: > > SystemWindow subclass: #XSystemWindow > instanceVariableNames: 'iteration' > classVariableNames: '' > package: âXXX' > > XSystemWindow>>initialize > super initialize. > iteration := 0. > > XSystemWindow>>drawOn: aCanvas > âDo not use transcript because it does even more crazy stuff" > Stdio stdout << (iteration := iteration + 1) asString; cr; lf. > super drawOn: aCanvas > > > Then execute this in a playground: > > XSystemWindow new > addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: LayoutFrame identity; > openInWorld. > > and then you can watch in your stdout how full window redraws with cursor blinking (it stops when window loses focus). > > This happens because cursor is displayed with lapsus of 700ms and is just a draw of a line with a color who is set to itâs opposite each time. Then it does "color: shownColorâ and #color: sends #changed who finalise in #invalidRect. > I always thought that this invalidation mechanism works by recording âdamaged areasâ, then collecting morphs with that area and triggering the redraw of that morph. > With this in mind, cursor should trigger an invalidation of itâs own area (a small portion of the screen, as you can see). > I could understand that a cursor triggers the text area redraw (but that would be a âdesign flawâ, IMO)â¦ now, what I cannot understand is why blink a cursor triggers the redraw of a FULL WINDOW. > When in Nautilus, that means each cursor blink triggers the redraw of one tree, four lists, some buttons and finally, the text area. > IMO, this is not acceptable. > > What do you think? > > Esteban

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by stepharo

Fun analysis :) Le 22/5/16 Ã 17:26, Eliot Miranda a Ã©crit : > Hi Henrik, > > cc'ing squeak-dev cuz this is relevant to both communities (if and > until Pharo takes the unwise decision to double the size of the image > by keeping sources in the image). > > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no > <mailto:henrik.nergaard@uia.no>> wrote: > >> There is a method in SourceFileArray >> #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: >> which uses a ProccessLocalVariable called >> ProccessAndSessionLocalSourcesFileArray (see >> #localProcessReadOnlyCopy). Changing the last line in >> #readStreamAt:ifPresent:ifAbsent: to use this local process one makes >> the time to run this snippet: >> >> [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' >> matchCase: false ] timeProfile >> >> From ~ 10 seconds to ~ 3 seconds (Windows). >> >> However I cannot see that the file handles created by this >> processLocalVariable to ever be closed, so I suspect those are >> leaked? In that case there might be the need to implement some âclean >> upâ mechanism for ProccessLocalVariables before they are >> changed/nilled when a process changes. >> >> Another approach could be to not use a ProccessLocalVariabe at all, >> but extend the SourceFilesArray class to also hold one read only >> handle for each of its files, and use these in >> readStreamAtFileIndex:::â¦ . I guess that it is also necessary then to >> have semaphore protecting the two last lines such that setting the >> position in the stream and reading from it cannot be changed by other >> threads. >> > > I like this approach, but it has a fatal flaw. If one is debugging > file access, then as the debugger causes the source of methods to be > fetched as the debugger displays them, so the file pointer in the > read-only file the access of which one is trying to debug will change > under one's feet, and the results will be completely wrong. > > An approach which uses a special copy for the debugger doesn't work; > one can't debug access to that file for the same reason. > > An approach that /should/ work is for the debugger to install its own > copy around file-access. This should be recursive. So around every > file access in the debugger there would need to be something like > > SourceFiles substituteFreshReadOnlyCopiesDuring: [...file > access...] > > which would remember the current read-only files, evaluate the block > using ensure: and have the ensure: block reinstall the previous file. > > Does this make sense? > >> readStreamAtFileIndex: index atPosition: position ifPresent: >> presentBlock ifAbsent: absentBlock >> >> | stream result| >> >> stream := self readOnlyFileAt: index. >> >> stream ifNil: [ ^ absentBlock value ]. "sources file not >> available" >> >> position > stream size ifTrue: [ ^ absentBlock value ]. >> >> readSema critical: [ >> >> stream position: position. >> >> result := presentBlock value: stream >> >> ]. >> >> ^ result >> >> Best regards, >> >> Henrik >> >> *From:*Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On >> Behalf Of *Nicolai Hess >> *Sent:* Thursday, May 19, 2016 9:31 AM >> *To:* Pharo Development List <pharo-dev(a)lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org>> >> *Subject:* Re: [Pharo-dev] From a mooc user: method source with it' >> take so long in Pharo 5 >> >> Squeak caches the opened readonly file(handle). It does not have to >> reopen the file on every call for reading (readonly). >> >> 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> I am wondering why does the search 'method source with it' take >> so long in Pharo 5? On my PC, When I select the text 'menu' and >> search for all 'method source with it', in Squeak 5 it takes 3 >> seconds. In Pharo 5 it takes 21 seconds. >>

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by stepharo

tx Le 22/5/16 Ã 17:17, Eliot Miranda a Ã©crit : > Hi Steph, > > almost certainly because in Pharo the sources file is opened once for each method whereas in squeak a read-only copy is taken and reused. > > I don't like the squeak approach: > CurrentReadOnlySourceFiles cacheDuring: > [...] > but it does play well with the debugger. So fixing this elegantly is non-trivial. I suggest you try and real squeak-dev messages talking about CurrentReadOnlySourceFiles and "read-only copies" of the sources files. > > _,,,^..^,,,_ (phone) > >> On May 18, 2016, at 10:12 AM, stepharo <stepharo(a)free.fr> wrote: >> >> I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds. >> >> >

May 22, 2016