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

[Pharo-project] Issue 3377 in pharo: AppRegistry remoce dependence to UIManager
by pharo＠googlecode.com Jan. 28, 2011

Jan. 28, 2011

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo Labels: Type-Seed New issue 3377 by Benjamin.VanRyseghem.Pharo: AppRegistry remoce dependence to UIManager http://code.google.com/p/pharo/issues/detail?id=3377 fix but using a not so pretty way. I've to discuss with Steph about extensions Attachments: AppRegistryRemoveDependenceToUIManager.1.cs 1.8 KB

1 1

[Pharo-project] Issue 3379 in pharo: ToolSet remove dependence to UIManager
by pharo＠googlecode.com Jan. 28, 2011

Jan. 28, 2011

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo Labels: Type-Seed New issue 3379 by Benjamin.VanRyseghem.Pharo: ToolSet remove dependence to UIManager http://code.google.com/p/pharo/issues/detail?id=3379 fix Attachments: ToolSetRemoveDependenceToUIManager.1.cs 859 bytes

1 2

[Pharo-project] Issue 3489 in pharo: Pharo 1.2-dev still uses Preferences in BaseSoundSystem
by pharo＠googlecode.com Jan. 27, 2011

Jan. 27, 2011

Status: Accepted Owner: Torsten....(a)astares.de New issue 3489 by Torsten....(a)astares.de: Pharo 1.2-dev still uses Preferences in BaseSoundSystem http://code.google.com/p/pharo/issues/detail?id=3489 Evaluate "Beeper beep" and you get a DNU since BaseSoundSystem>>beep calls Preferences>>soundsEnabled which is not there.

1 20

[Pharo-project] Issue 3335 in pharo: [Kernel Dependencies] Number>>@
by pharo＠googlecode.com Jan. 25, 2011

Jan. 25, 2011

Status: Accepted Owner: Benjamin.VanRyseghem.Pharo New issue 3335 by Benjamin.VanRyseghem.Pharo: [Kernel Dependencies] Number>>@ http://code.google.com/p/pharo/issues/detail?id=3335 If you fill an issue for the first time, please read "How to report bugs" at http://www.pharo-project.org/community/issue-tracking Pharo image: <core, dev or web> Pharo core version: <copy from World/System/About> Virtual machine used: <ex: pharo-vm-0.15.2f-linux> Class browser used if applicable: <ex: O2PackageBrowserAdaptor. If you don't know, print "SystemBrowser default"> Steps to reproduce: 1. 2. 3. Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image):

1 3

Re: [Pharo-project] Issue 2360 in pharo: nil out locals in a block if readBeforeWritten
by pharo＠googlecode.com Jan. 25, 2011

Jan. 25, 2011

Comment #6 on issue 2360 by marcus.denker: nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 Next action: - take the code here and make a .cs or Slice out of it

1 5

[Pharo-project] Issue 3380 in pharo: UnhandleError remove dependence to UIManager
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo Labels: Type-Seed New issue 3380 by Benjamin.VanRyseghem.Pharo: UnhandleError remove dependence to UIManager http://code.google.com/p/pharo/issues/detail?id=3380 fix Attachments: UnhandleErrorExtension.1.cs 231 bytes

1 1

[Pharo-project] Issue 3427 in pharo: two methods from BlockContext to BlockClosure
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: FixedWaitingToBePharoed Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3427 by stephane.ducasse: two methods from BlockContext to BlockClosure http://code.google.com/p/pharo/issues/detail?id=3427 Levente Uzonyi uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ul.519.mcz ==================== Summary ==================== Name: Kernel-ul.519 Author: ul Time: 8 December 2010, 2:52:41.144 am UUID: 630c1710-46b8-5248-bdb8-e08d99d6d9c0 Ancestors: Kernel-ul.518 - copied another two methods from BlockContext to BlockClosure. One of them fixes http://bugs.squeak.org/view.php?id=7579 . =============== Diff against Kernel-ul.518 =============== Item was added: + ----- Method: BlockClosure>>newProcessWith: (in category 'scheduling') ----- + newProcessWith: anArray + "Answer a Process running the code in the receiver. The receiver's block + arguments are bound to the contents of the argument, anArray. The + process is not scheduled." + <primitive: 19> "Simulation guard" + ^Process + forContext: + [self valueWithArguments: anArray. + Processor terminateActive] asContext + priority: Processor activePriority! Item was added: + ----- Method: BlockClosure>>valueWithExit (in category 'evaluating') ----- + valueWithExit + self value: [ ^nil ]!

1 1

Re: [Pharo-project] Issue 3227 in pharo: Remove all MethodFinder
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Updates: Labels: -Milestone-1.2 Milestone-1.3 Comment #3 on issue 3227 by siguctua: Remove all MethodFinder http://code.google.com/p/pharo/issues/detail?id=3227 (No comment was entered for this change.)

1 1

Re: [Pharo-project] Issue 3172 in pharo: NewInspector really really slow while parsing XMLNode
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Updates: Cc: jaa...(a)zoho.com Comment #2 on issue 3172 by laurent.laffont: NewInspector really really slow while parsing XMLNode http://code.google.com/p/pharo/issues/detail?id=3172 From jaayer: Hi Laurent. First, thank you for your screencasts. I am writing to you concerning this issue: http://code.google.com/p/pharo/issues/detail?id=3172&q=xml&colspec=ID%20Typ… I only discovered the above last night, as I am not a Pharo core developer and only check the issue tracker occasionally. I am a maintainer of XML-Support, however, so feel free to mail me directly with any issues you have in the future, or at the very least, please post them to the Pharo-Project, Squeak-dev or Moose-dev lists. Now, in your video, which was made back in August, you used version .74 of XML-Parser. If you look at the changelogs of XML-Parser, it is clear that much has changed since that time. It would not be unreasonable to assume that one or more of those changes is responsible for the difficulties you experienced inspecting that XML document. However, if you load version .74, the same version used in your screencast, into a Pharo 1.1 image, the problem is still there (and is in fact much worse), meaning that whatever has changed since August to bring this about, I can say with some confidence that it is not in XML-Parser. Using the latest version of XML-Parser and ignoring the question of causality for a moment, the bottleneck we're observing is in XMLNode>>printOn:. The proof is that disabling XMLNode>>printOn: makes our problem go away. Why then is XML generation suddenly such a bottleneck? The main reason appears to be that the document being inspected is, when printed, roughly 40K in size, and by inspecting it you are causing it to be printed over and over again. I tracked sends of #printOn: and found that inspecting the document and navigating to the "title" element results in #printOn: being sent 300-400 times. The recipients were the document object and the root "feed" element ~350 times. By the time you've navigated to the "feed" element and clicked the "Elements" entry to display its children, #printOn: has already been sent ~150 times. That means the remaining 150-250 sends come when you click on the "title" element or some other child element of the root, and that single additional click results in the generation of roughly 6-10 MBs of XML (150 * 40K to 250 * 40K). *That* is why it's so slow. Now, why does NewInspector cause #printOn: to be sent so much? I honestly don't know. I will forward this to the maintainers of NewInspector to get their input. Maybe NewInspector can be changed to not print inspected objects so often, or to provide them with some way to suppress its printing behavior. It must be pointed out that Pharo also comes with an object explorer that is designed specifically for this usecase of browsing deep object hierarchies. I tried exploring the document with cmd-I (capital i) and encountered no trouble.

1 2

Re: [Pharo-project] Issue 3179 in pharo: Failing Tests for Monticello
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Comment #1 on issue 3179 by marcus.denker: Failing Tests for Monticello http://code.google.com/p/pharo/issues/detail?id=3179 Current state: >>> Tests.Monticello.MCChangeNotificationTest.testExtMethodModified 0.0050 >>> 50 >>> Tests.Monticello.MCPackageTest.testUnload 0.636 50 The Tests.Monticello.MCPackageTest.testUnload only fails on Hudson.

1 8