- Pharo-users - lists.pharo.org

Re: [Pharo-users] AST visualization with Roassal

by Alexandre Bergel

Frankly, I often find weird to override #= Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jul 30, 2015, at 11:41 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > I think it's because somewhere in roassal > objects (in this case ast nodes) are compared by value. > > Pretty much; there is test for equality > > RTGroup>>elementFromModel: anObject > ^ self detect: [ :el | el model = anObject ] ifNone: [ nil ] > > and equality is more often than not wanted. > > So solution might be to tell Mondrian that you want to compare by identity and not equality? > > Peter

July 30, 2015

Re: [Pharo-users] AST visualization with Roassal

by Marcus Denker

> On 30 Jul 2015, at 16:47, Mark Rizun <mrizun(a)gmail.com> wrote: > > Pretty much; there is test for equality > > RTGroup>>elementFromModel: anObject > ^ self detect: [ :el | el model = anObject ] ifNone: [ nil ] > > and equality is more often than not wanted. > > So solution might be to tell Mondrian that you want to compare by identity and not equality? > > Exactly! I'd like to have an option to select how I want to compare objects. It uses already a block to do the comparisionâ¦ if you make that pluggable (add ivar, set it to [ :el | el model = anObject ] in #initialize, add accessor) then you can just provide your own block with #== instead. Marcus

July 30, 2015

Re: [Pharo-users] AST visualization with Roassal

by Mark Rizun

> > Pretty much; there is test for equality > > RTGroup>>elementFromModel: anObject > ^ self detect: [ :el | el model = anObject ] ifNone: [ nil ] > > and equality is more often than not wanted. > > So solution might be to tell Mondrian that you want to compare by identity > and not equality? > Exactly! I'd like to have an option to select how I want to compare objects.

July 30, 2015

Re: [Pharo-users] AST visualization with Roassal

by Peter UhnÃ¡k

> > I think it's because somewhere in roassal > objects (in this case ast nodes) are compared by value. Pretty much; there is test for equality RTGroup>>elementFromModel: anObject ^ self detect: [ :el | el model = anObject ] ifNone: [ nil ] and equality is more often than not wanted. So solution might be to tell Mondrian that you want to compare by identity and not equality? Peter

July 30, 2015

AST visualization with Roassal

by Mark Rizun

Hi, everyone! First of all, using Roassal is fun and effective :) But while working on AST visualization I found that sometimes Roassal builds wrong tree layout (or maybe I'm just doing something wrong). For instance, try two following scripts in playground: ************************* #1 | ast builder | ast := RBParser parseExpression: 'self foo. self foo'. builder := RTMondrian new. builder shape ellipse size: 15. builder nodes: ast allChildren. builder edges connectFrom: #parent. builder layout tree. builder build. builder view ************************* ************************* #2 | ast builder | ast := RBParser parseExpression: 'self foo. super foo'. builder := RTMondrian new. builder shape ellipse size: 15. builder nodes: ast allChildren. builder edges connectFrom: #parent. builder layout tree. builder build. builder view ************************* First script builds wrong tree. I think it's because somewhere in roassal objects (in this case ast nodes) are compared by value. That is why when we have two equal receivers in script #1 it fails to build a tree. Thanks, Mark -- View this message in context: http://forum.world.st/AST-visualization-with-Roassal-tp4840243.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 30, 2015

Re: [Pharo-users] Recoverying a crashed Moose image/Pharo5

by stepharo

I know that there is a memory leak around playground and rubric. We will have investigate it. It is Pharo 50 but also in Pharo 40. Stef Le 30/7/15 08:10, Hilaire a Ã©crit : > Hello, > > I have a Moose 6.0 image with several Playgrounds. > Since this morning, exactly when I want to make a demo[1], it crashes > immediately. I remember yesterday I got an error when saving, Pharo said > something like 'This error should not happen'. > > The OS windows open then close almost immediately (dump included). Could > it be related to Athens or FreeType plugin access? The image went about > 113MB. > The used VM works fine with a fresh Moose6.0 image. Btw, the > http://www.moosetechnology.org/ is down right now. > I would like to recover the script codes in the playgrounds, is there a > way to access it? > > Thanks > > Hilaire > > [1] Hopefully I can demo with a fresh image of Moose >

July 30, 2015

Re: [Pharo-users] FileLocator problem?

by Blondeau Vincent

Actually these folders seems to be real folders to windows but you canât access them (maybe you have not enough rights?). Anyway, it should be possible to bypass these directories. In DiskStore>>basicEntry:path:nodesDo: there is a send of the message signalDirectoryDoesNotExist:. It signals a DirectoryDoesNotExist error. This exception is resumable. If you resume it you should bypass the access to the âbad folderâ. That not the case, so there is a bug. (a ^is missing before self signalDirectoryDoesNotExist: aPath). I opened a bug: https://pharo.fogbugz.com/f/cases/16075/DiskStore-basicEntry-path-nodesDo-s… and made a slice. Vincent Blondeau De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de PBKResearch EnvoyÃ© : jeudi 30 juillet 2015 12:32 Ã : 'Any question about pharo is welcome' Objet : Re: [Pharo-users] FileLocator problem? Thanks Craig and Matthieu. However, we can now reformulate the problem: âFileLocator documents allChildrenâ does not trace the hierarchy of these directories correctly. It finds its way to C:\Users\Peter\Documents, searches for subdirectories and finds âMy Musicâ etc. among the true subdirectories. It seems that the Pharo mechanism for interrogating the Windows file system is confused by these aliases. As I said, not a great problem for me, but maybe worth noting. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Matthieu Lacaton Sent: 30 July 2015 11:16 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] FileLocator problem? Windows 7 uses "aliases" for these directories. It is the way different languages or owners are handled. For example in French you can see your music directory as "Ma Musique" but the real name used in paths is actually "Music". As Craig said, the default paths for these directories are : "C:\Users\Your_User_Name\Documents" or "C:\Users\Your_User_Name\Music" and so on. But you can always change them so the best way to see the real path of your directories is to right click on one and go to "Properties" => "Location". Note also that Windows uses "\" instead of "/" for paths. I don't know if it is relevant in Pharo though. Cheers, Matthieu 2015-07-30 11:43 GMT+02:00 PBKResearch <peter(a)pbkresearch.co.uk<mailto:peter@pbkresearch.co.uk>>: Hello Out of curiosity I tried to run the snippet which Alexandre Bergel posted yesterday under the name âScript of the dayâ. It failed, but nothing to do with the script itself. The problem is that it fails on the line: âFileLocator documents allChildren.â The debugger message is âDirectory does not exist: Path âC:â / âUsersâ / âPeterâ / âDocumentsâ / âMy Musicâ.â Tracing through the debugger output, I conclude that the same error will arise with the directories âMy Picturesâ and âMy Videosâ. One thing these directories have in common is that they are empty, so as a test I copied a small text file into âMy Musicâ, but this made no difference. I have a vague recollection that âMy Musicâ etc., although presented by Windows as conventional directories, are in fact some sort of pseudo-directories constructed as required by Windows Explorer, but I am not too sure about this. Could this be an explanation of the problem? Itâs not an urgent problem for me; it can easily be worked round by ensuring that I never try to locate files in these directories. But if it is a bug, it might be relevant to someone else. My environment is Windows 7 Professional, running Moose 5.1 (Pharo4.0 Latest update: #40613). Thanks for any help Peter Kenny ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

July 30, 2015

Re: [Pharo-users] Is RBClassNotReferencedRule ~200x slower in Pharo 4 vs Pharo 3 ?

by Marcus Denker

I added an issue: https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl… <https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl…> i think we need to put in some cashingâ¦ here if we would could all *used* classes once for an enviromentâ¦. > On 29 Jul 2015, at 17:33, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Paul DeBruicker wrote >> Hi Stef, >> >> The slowdown is dependent upon the # of classes in the package. If you >> use Fuel then you should see a slowdown of 20x. I just have a lot of >> classes in this package. The source of the slowdown is in the changes to >> RBSmallLintChecker>>#checkClass: and >> RBClassNotReferencedRule>>#checkClass: . The old versions use the linter >> to check if the literal is used anywhere and the new one uses #allCallsOn. >> >> >> Hope this helps >> >> Paul > > > and by "use Fuel" I mean: > > rule:=RBClassNotReferencedRule new. > environment:=RBBrowserEnvironment new forPackageNames: #('Fuel'). > > > AndreasSystemProfiler spyOn:[RBSmalllintChecker runRule: rule onEnvironment: > environment] > > > > > > > > -- > View this message in context: http://forum.world.st/Is-RBClassNotReferencedRule-200x-slower-in-Pharo-4-vs… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

July 30, 2015

Re: [Pharo-users] FileLocator problem?

by PBKResearch

Thanks Craig and Matthieu. However, we can now reformulate the problem: âFileLocator documents allChildrenâ does not trace the hierarchy of these directories correctly. It finds its way to C:\Users\Peter\Documents, searches for subdirectories and finds âMy Musicâ etc. among the true subdirectories. It seems that the Pharo mechanism for interrogating the Windows file system is confused by these aliases. As I said, not a great problem for me, but maybe worth noting. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Matthieu Lacaton Sent: 30 July 2015 11:16 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] FileLocator problem? Windows 7 uses "aliases" for these directories. It is the way different languages or owners are handled. For example in French you can see your music directory as "Ma Musique" but the real name used in paths is actually "Music". As Craig said, the default paths for these directories are : "C:\Users\Your_User_Name\Documents" or "C:\Users\Your_User_Name\Music" and so on. But you can always change them so the best way to see the real path of your directories is to right click on one and go to "Properties" => "Location". Note also that Windows uses "\" instead of "/" for paths. I don't know if it is relevant in Pharo though. Cheers, Matthieu 2015-07-30 11:43 GMT+02:00 PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> >: Hello Out of curiosity I tried to run the snippet which Alexandre Bergel posted yesterday under the name âScript of the dayâ. It failed, but nothing to do with the script itself. The problem is that it fails on the line: âFileLocator documents allChildren.â The debugger message is âDirectory does not exist: Path âC:â / âUsersâ / âPeterâ / âDocumentsâ / âMy Musicâ.â Tracing through the debugger output, I conclude that the same error will arise with the directories âMy Picturesâ and âMy Videosâ. One thing these directories have in common is that they are empty, so as a test I copied a small text file into âMy Musicâ, but this made no difference. I have a vague recollection that âMy Musicâ etc., although presented by Windows as conventional directories, are in fact some sort of pseudo-directories constructed as required by Windows Explorer, but I am not too sure about this. Could this be an explanation of the problem? Itâs not an urgent problem for me; it can easily be worked round by ensuring that I never try to locate files in these directories. But if it is a bug, it might be relevant to someone else. My environment is Windows 7 Professional, running Moose 5.1 (Pharo4.0 Latest update: #40613). Thanks for any help Peter Kenny

July 30, 2015

Re: [Pharo-users] FileLocator problem?

by Matthieu Lacaton

Windows 7 uses "aliases" for these directories. It is the way different languages or owners are handled. For example in French you can see your music directory as "Ma Musique" but the real name used in paths is actually "Music". As Craig said, the default paths for these directories are : "C:\Users\Your_User_Name\Documents" or "C:\Users\Your_User_Name\Music" and so on. But you can always change them so the best way to see the real path of your directories is to right click on one and go to "Properties" => "Location". Note also that Windows uses "\" instead of "/" for paths. I don't know if it is relevant in Pharo though. Cheers, Matthieu 2015-07-30 11:43 GMT+02:00 PBKResearch <peter(a)pbkresearch.co.uk>: > Hello > > > > Out of curiosity I tried to run the snippet which Alexandre Bergel posted > yesterday under the name âScript of the dayâ. It failed, but nothing to do > with the script itself. The problem is that it fails on the line: > âFileLocator documents allChildren.â The debugger message is âDirectory > does not exist: Path âC:â / âUsersâ / âPeterâ / âDocumentsâ / âMy Musicâ.â > Tracing through the debugger output, I conclude that the same error will > arise with the directories âMy Picturesâ and âMy Videosâ. One thing these > directories have in common is that they are empty, so as a test I copied a > small text file into âMy Musicâ, but this made no difference. > > > > I have a vague recollection that âMy Musicâ etc., although presented by > Windows as conventional directories, are in fact some sort of > pseudo-directories constructed as required by Windows Explorer, but I am > not too sure about this. Could this be an explanation of the problem? > > > > Itâs not an urgent problem for me; it can easily be worked round by > ensuring that I never try to locate files in these directories. But if it > is a bug, it might be relevant to someone else. > > > > My environment is Windows 7 Professional, running Moose 5.1 (Pharo4.0 > Latest update: #40613). > > > > Thanks for any help > > > > Peter Kenny >

July 30, 2015