- Pharo-dev - lists.pharo.org

[Pharo-project] IMO IllegalResumeAttempt should be resumable
by Eliot Miranda Jan. 22, 2011

Jan. 22, 2011

Hi All, an attempt to resume an unresumable signal results in raising IllegalResumeAttempt; quite right: Exception>>resume "Return from the message that signaled the receiver." self resume: self defaultResumeValue However, IllegalResumeAttempt is not itself resumable. So in those rare cases (e.g. test coverage) where a knowledgeable client wants to force resumption of a non-resumable signal by catching and resuming IllegalResumeAttempt, they can't because IllegalResumeAttempt>>isResumable ^ false So take e.g. [Cogit chooseCogitClass testPCMappingSelect: [:m| true]] on: AssertionFailure do: [:ex| | ctxt | ctxt := ex signalerContext findContextSuchThat: [:ctx| ctx sender selector = #allSelect:]. Transcript ensureCr; print: (ctxt tempAt: 1); flush. [ex resume] on: IllegalResumeAttempt do: [:ex| ex resume]] where I'm trying to JIT every method in my image and catalogue those that assert-fail, proceeding through the assert failure (and AssertionFailure isn't resumable). I happen to know that proceeding from the assert-fails is safe. But I can't force resumption because IllegalResumeAttempt is itself not resumable. I propose that we make IllegalResumeAttempt resumable. Objections? Cautions? best Eliot

1 1

[Pharo-project] Some important news
by StÃ©phane Ducasse Jan. 22, 2011

Jan. 22, 2011

Hi guys some important news today, we decided that we will set up a pharo association so that we can promote pharo. We would like to be able to collect money and create bounties to improve pharo. Stef

7 6

[Pharo-project] Issue 3578 in pharo: Hudson integration: Not include MAC files in zips
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Status: Accepted Owner: marianopeck CC: marcus.d...(a)gmail.com, siguc...(a)gmail.com Labels: Milestone-1.3 New issue 3578 by marianopeck: Hudson integration: Not include MAC files in zips http://code.google.com/p/pharo/issues/detail?id=3578 Igor: All .zip files with pharo images having an annoying Apple-ism - a .DS_Store garbage file. Please use a zip archiver which includes only relevant files to archive, because obviously this garbage has no use anywhere but Macs. Mariano: Yes, when I build the dev images, I use the YemuZip that Marcus recommended. It can zip it without all that crap. Not sure if it is the best way if you want to automatize this with scrips. We need to integrate this for hudson. cheers mariano

1 2

[Pharo-project] Reminder: change the archiving tool
by Igor Stasenko Jan. 22, 2011

Jan. 22, 2011

All .zip files with pharo images having an annoying Apple-ism - a .DS_Store garbage file. Please use a zip archiver which includes only relevant files to archive, because obviously this garbage has no use anywhere but Macs. -- Best regards, Igor Stasenko AKA sig.

3 2

Re: [Pharo-project] Issue 1500 in pharo: REDO on empty History breaks the whole undo history
by pharo＠googlecode.com Jan. 22, 2011

Jan. 22, 2011

Updates: Status: Invalid Comment #3 on issue 1500 by marcus.d...(a)gmail.com: REDO on empty History breaks the whole undo history http://code.google.com/p/pharo/issues/detail?id=1500 this seems to be fixed with the new undo framwork

1 1

[Pharo-project] [update 1.3] #13016
by Marcus Denker Jan. 22, 2011

Jan. 22, 2011

13016 ----- Issue 3566: Changes needed to update Sound for 1.2 Issue 3380: UnhandleError remove dependence to UIManager -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[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