- Pharo-users - lists.pharo.org

Glamour: opening paths in tree with filters

by Usman Bhatti

Hi, I am having trouble with opening a specific path in tree presentation (using MorphTreeMorph) when filtering nodes. What I am trying to achieve is that if a node is searched in a tree at level 4, all the parent nodes are opened to show the node searched (hence the user the does not need to open the nodes manually). In Glamour, when combined with filtering, expanding up to the root of the search node works when the parent node is already expanded, otherwise the nodes are not expanded. At the end of the mail, there are two snippets to reproduce the behavior. MorphTreeMorph>>addMorphsTo: from: withExpandedItems: atLevel: is the method responsible for this behavior in Glamour and it seems that nodes are only expanded (to show their children) if they were expanded beforehand. Is there a way to do otherwise in MorphTreeMorph (open paths with non-expanded nodes)? tx. Usman Code snippets in Glamour (Pharo 4.0): | tabulator | tabulator := GLMTabulator new column: [ :c | c row: #one ]; yourself. tabulator transmit to: #one; andShow: [:a | a tree title: 'Show filter paths'; rootsExpanded; children: [:item :x : level | (item < 5 and: [ level < 6 ]) ifTrue: [ {item + 1}] ifFalse:[#() ]]; filterOn: [:text :each | text = each asString]]. tabulator openOn: (1 to: 1) "searching for 3 does not open the path to 3 ?!?!?!" | tabulator | tabulator := GLMTabulator new column: [ :c | c row: #one ]; yourself. tabulator transmit to: #one; andShow: [:a | a tree title: 'Show filter paths'; rootsExpanded; children: [:item :x : level | (item < 3 and: [ level < 5 ]) "to stop adding infinite children" ifTrue: [ level = 4 "plug a node 5 deep down and see if we can find the path" ifTrue: [(1 to: 5)] ifFalse: [ (1 to: item * 2) ] ] ifFalse:[#() ]]; filterOn: [:text :each | text = each asString]]. tabulator openOn: (1 to: 2) "searching for 5 correctly opens the path up to 5"

June 30, 2015

Re: [Pharo-users] Interactive table support in Pharo (thanks to the new OS window architecture)

by Tudor Girba

Very cool! Doru On Tue, Jun 30, 2015 at 11:05 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Cool :) > > Thierry > > > 2015-06-30 11:03 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> spread the words ;) >> >> Interactive table support in Pharo (thanks to the new OS window >> architecture) >> https://youtu.be/0sIX3YbO-XY >> >> Thanks Thales for the sponsoring! >> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 30, 2015

Re: [Pharo-users] Interactive table support in Pharo (thanks to the new OS window architecture)

by Thierry Goubier

Cool :) Thierry 2015-06-30 11:03 GMT+02:00 stepharo <stepharo(a)free.fr>: > spread the words ;) > > Interactive table support in Pharo (thanks to the new OS window > architecture) > https://youtu.be/0sIX3YbO-XY > > Thanks Thales for the sponsoring! > >

June 30, 2015

Interactive table support in Pharo (thanks to the new OS window architecture)

by stepharo

spread the words ;) Interactive table support in Pharo (thanks to the new OS window architecture) https://youtu.be/0sIX3YbO-XY Thanks Thales for the sponsoring!

June 30, 2015

Re: [Pharo-users] Chess Game / UpdatingStringMorph

by stepharo

Le 30/6/15 10:12, Merwan Ouddane a Ã©crit : > On lun., 2015-06-29 at 14:09 -0700, Sean P. DeNigris wrote: >> MerwanOuddane wrote >>> You should just replace it with a StringMorph and figure out how to >>> update the morph right on time :) >> It seems like there should be Morph>>#addAlarm:every:, but I don't see >> anything like that... >> > Is it really usefull to have a process checking an acessor instead of > notifying changes to the StringMorph ? Merwane you are right. Polling is a bad idea from an architecture point of view. And dated :) Stef >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Chess-Game-UpdatingStringMorph-tp4834675p4834703.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > > >

June 30, 2015

Re: [Pharo-users] Chess Game / UpdatingStringMorph

by stepharo

I think that if you use StringMorph it will work. We should accept that Pharo is moving and that some old abstractions were not good. :) You do not want something doing constant polling in the UI. Stef Le 29/6/15 21:17, Volkert a Ã©crit : > I am trying to load the old chess game from Squeak [1] into Pharo 4.0. > > The game depends on the class "UpdatingStringMorph", but this is not > part of Pharo. > > What happened to it? Was it renamed? > > BW, > Volkert > > [1] http://map.squeak.org/package/cb19b6f1-e371-47b2-b814-4bad079d0fbc > > > >

June 30, 2015

Re: [Pharo-users] Chess Game / UpdatingStringMorph

by Merwan Ouddane

On lun., 2015-06-29 at 14:09 -0700, Sean P. DeNigris wrote: > MerwanOuddane wrote > > You should just replace it with a StringMorph and figure out how to > > update the morph right on time :) > > It seems like there should be Morph>>#addAlarm:every:, but I don't see > anything like that... > Is it really usefull to have a process checking an acessor instead of notifying changes to the StringMorph ? > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Chess-Game-UpdatingStringMorph-tp4834675p4834703.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 30, 2015

Re: [Pharo-users] Pharo image processing library

by Serge Stinckwich

On Tue, Jun 30, 2015 at 8:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-06-25 18:41 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >> Hi, >> >> is there any image (as in picture) processing library in the likes of >> Python's PIL(http://effbot.org/imagingbook/image.htm), >> >> or even (highly unlikely) something like OpenCV (http://opencv.org/)? > > > Not that I know of. I was interested at one time with the same topic. > Juan Vuletich had a nice PhotoSqueak project (squeak 1 or 2?) > http://www.jvuletich.org/Squeak/PhotoSqueak/PhotoSqueakGallery/PhotoSqueakG… I ask Juan about this one, but apparently this is not open-source. > There is Smagick > http://smalltalkhub.com/#!/~StefanReichhart/Smagick/ > > (not a library on its own, but an interface to imagemagick) > > I think there was another squeak/imagemagic project but I don't remember. > > It would be great to have something like imagemagick, but implemented > entirely in smalltalk. There was some experiments done by Luc : http://smalltalkhub.com/#!/~LucFabresse/OpenCV There is also some basic image processing in VirtualGPU : http://smalltalkhub.com/#!/~ronsaldo/VirtualGPU Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 30, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Luc Fabresse

2015-06-30 9:09 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > On 29-06-15 20:10, Sean P. DeNigris wrote: > >> I strongly feel we should be >> more specific and uniform by either using (<exampleInstance> & >> <exampleCode>) or (<sampleInstance> & <sampleCode>). >> > > +1 Be specific. +1 too > > > Stephan > > > >

June 30, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

I ran it in Pharo 4 (40616) because method putSource:inFile:withPreamble: no longer exists in Pharo 5 and results are: Desktop... all: 13.062 per second compile: 6,603 per second (why the hell is there comma as separator and not dot?) store: 13.431 per second add: 406.400 per second Notebook... all: 210.180 per second compile: 12,007 per second store: 454.818 per second add: 806.239 per second Jan Peter UhnÃ¡k wrote > Windows XP > 1011857707 bytecodes/sec; 132044070 sends/sec > > Debian > 1172295363 bytecodes/sec; 144744207 sends/sec > > But I think taking the compile: method apart tells a better story > > ~~~~~~~~~~~~~~~~~~~ > code := 'a'. > > method := Object compiler > source: code; > requestor: nil; > failBlock: [ ^nil ]; > compile. > > all := [ > Object compile: code. > ]. > > compile := [ > Object compiler > source: code; > requestor: nil; > failBlock: [ ^nil ]; > compile. > ]. > > store := [ > method putSource: code inFile: 2 > withPreamble: [:f | f cr; nextPut: $!; nextChunkPut: 'Behavior method'; > cr]. > ]. > > add := [ > Object addSelector: method selector withMethod: method notifying: nil. > ]. > ~~~~~~~~~~~~~~~~~~~ > > > Windows XP: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > all bench. "'183.763 per second'" > compile bench. "'10,729 per second'" > *store bench. "'286.170 per second'"* > add bench. "'697.883 per second'" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Debian > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > all bench. "'622.551 per second'" > compile bench. "'11,129 per second'" > *store bench. "'41,604 per second'"* > add bench. "'787.885 per second'" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 150x slower disk operations? -_- > > I mean for normal programming this doesn't really matter, but when we are > downloading even medium-sized package it takes ages to process... > > Peter -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 30, 2015