November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cleanup of debug requests API

by Denis Kudriashov

I clean and refactor all but lowSpaceWatcher. It is in slice 17069. In my image it is not broke stuff. So I hope it is safe change. 2015-11-20 12:18 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > I try to investigate how debugger opens and who initiates it. > I want to cleanup this logic and simplify current debugger API. > > I found that basic error debugging starts with UIManager then UIManager > calls SpecDebugger, then SpecDebugger calls UIManager and again... At the > end of this chain debugger is opened by #openFullSuspendLabel: or > #openNotifierContents:label: > > There are two places where opening debugger initiated differently: > - Low space watcher calls SpecDebugger class>>openInterrupt:onProcess: > - Warning default action calls SpecDebugger > class>>openContext:label:contents: (And it not uses UIManager. I guess non > interactive mode not working here). > > In latest Pharo image it is only users of this methods. Is anybody know > anyone else? > > I almost cleaned basic errors debugging. And I want use it for this two > cases too. But they implements very specific logic. They both contains > primitive simulation guard 19 and some kind of recursion tracking. > I understand that low space watcher requires something clever. But why > Warning not opens debugger with way Error does it? > > Any suggestions? > > Best regards, > Denis >

Nov. 20, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by Denis Kudriashov

2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > epicea data is not stored forever. It is seasion based and the shipped > image is > clean. > But current source of this info is changes file (maybe sources). And I remember you planned to store current sources in image. And such information can be there too. Maybe I miss something?

Nov. 20, 2015

Re: [Pharo-dev] Issue with large file path on windows

by Esteban Lorenzano

yes it was. latest win vm should have long paths. Esteban > On 20 Nov 2015, at 12:27, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hello, > > I would like to read from Pharo a file with a long name (so more than 255 chars) under Windows. > A thread from last month (13 oct): âRe: [Pharo-dev] [Vm-dev] Re: issue with large file path on windowsâ, talks about a patch. > Does it has been integrated? > If it has, which VM should I take to have the patch? > My current one is http://files.pharo.org/vm/pharo/win/494.zip <http://files.pharo.org/vm/pharo/win/494.zip> > > Thanks, > > Vincent Blondeau > > > > 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.

Nov. 20, 2015

Re: [Pharo-dev] Recovering _lost_ changes

by Skip Lentz

Hi, > On Nov 20, 2015, at 5:52 PM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > For example, right now you will get an error when you redo (or undo) a class comment change. I will try to fix this bug right now. I committed a bug fix for this to Epicea now.

Nov. 20, 2015

Re: [Pharo-dev] Smalltalkhub is very instable this afternoon

by Blondeau Vincent

Thx Esteban ! De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Esteban Lorenzano EnvoyÃ© : vendredi 20 novembre 2015 17:50 Ã : Pharo Development List Objet : Re: [Pharo-dev] Smalltalkhub is very instable this afternoon done On 20 Nov 2015, at 11:41, Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: Hello, Can Smalltalkhub be restarted (or other) because it is impossible to work by getting continuously errors 500, 503, 403, 401â¦. while loading or committing? TIA Cheers, Vincent BLONDEAU ________________________________ 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. ________________________________ 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.

Nov. 20, 2015

Re: [Pharo-dev] Case 16725: why no reaction?

by webwarrior

So now we stil have 2 subissues, that need discussion. They break backwards compatibility (basically it's about using Spec models instead of morphs in some methods). However it's not clear if these methods are widely used. So maybe transition will be painless, maybe not so much. We need to decide if it's worth it. If you wonder about my opinion, I'd say integrate the changes. -- View this message in context: http://forum.world.st/Case-16725-why-no-reaction-tp4858968p4862263.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Ben Coman

So you can try the following... $ curl get.pharo.org/50+vm | bash $ ./pharo Pharo.image eval "Delay delaySchedulerClass: DelayExperimentalSemaphoreScheduler. CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests') btw, these are named "experimental" only because they were integrated a week before the Pharo 4 release (delayed due to some conflict with the CI system). For me they had been stable for months before that (only some CI conflicts delayed integration.) I believe these are ready for wider community testing by promoting an "experimental" delay scheduler to be default. Probably leave its name unchanged for now. There is some refactoring I want to do to clean up its hierarchy that will be simplified by leaving the name as it is for now. cheers -ben On Fri, Nov 20, 2015 at 11:43 PM, Ben Coman <btc(a)openinworld.com> wrote: > Could you try the various DelayExperimentalXXXSchedulers? Under > System > Settings > System > Delay Scheduler. > > I believe there's a good chance one of them may fix also the problem. > I had planned to push one of these as the default in Pharo 5 but > hadn't decided which, got distracted and stretched a bit thin IRL. I > believe these experimental schedulers are better than the current > mutex based scheduler, since passing Delays from your normal-priority > process to the timing-priority delay scheduling process is a > signalling paradigm more than a shared memory paradigm. I came to > this conclusion reading [2] which says... > > "The correct use of a semaphore is for signalling from one task to > another. A mutex is meant to be taken and released, always in that > order, by [the same task using] the shared resource it protects. By > contrast, tasks that use semaphores either signal or waitânot both. > ... Another important distinction between a mutex and a semaphore is > that the proper use of a mutex to protect a shared resource can have a > dangerous unintended side effect ... any two tasks that operate at > different priorities and coordinate via a mutex, create the > opportunity for priority inversion ... Fortunately ... semaphores ... > do not cause priority inversion when used for signalling." > > A mutex makes DelayXXXScheduler>>#schedule: susceptible to > priority inversion since it is used by many processes at different > priority levels. Using a signalling-semaphore might avoid the > problem. > > The experimental delay schedulers were developed to address the > problem reported in the "super fast delay" [2], but there may also > have been a fix for that through another means. > > [1] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore > [2] http://forum.world.st/Super-fast-delay-td4787257.html > > cheers -ben > > On Fri, Nov 20, 2015 at 8:03 PM, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: >> >> >> 2015-11-20 12:46 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: >>> >>> Hi! >>> >>> With Guille and Pablo this morning we found what is the problem and >>> apparently fixed it. The problem is that there is a process in priority 10 >>> that takes the delay lock (accessProtect semaphore) and go to sleep. Then >>> the #benchFor: launches another process in priority 79 that tries to take >>> the delay lock but, since it's taken by the other process, it goes to sleep. >>> But the UI process is in priority 40 so it will always have priority over >>> the one that has the lock. Consequence: the process in priority 10 has the >>> delay lock and will never be awaken until the UI process gets suspended. >> >> >> I believe this is a text book example of priority inversion. >> >> Kudo's for finding it! >> >> Thierry >> >>> >>> >>> More in detail, the following method makes the assumption that once the >>> delay process finishes the handling of the delay to schedule, it will return >>> to same process. But that is not true if there is another process with more >>> priority. >>> >>> schedule: aDelay >>> | scheduled | >>> scheduled := false. >>> aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has >>> already been scheduled.']. >>> accessProtect critical: [ >>> scheduledDelay := aDelay. >>> timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" >>> scheduled := (scheduledDelay == nil). >>> ]. >>> ^scheduled. >>> >>> Our solution is to run the critical section in a higher priority to ensure >>> that always comes back to the same process to release the delay lock. >>> >>> schedule: aDelay | scheduled | scheduled := false. aDelay >>> schedulerBeingWaitedOn ifTrue: [ ^ self error: 'This Delay has already been >>> scheduled.' ]. [ accessProtect critical: [ scheduledDelay := aDelay. >>> timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" >>> scheduled := scheduledDelay == nil ]. ^ scheduled ] valueAt: Processor >>> timingPriority - 1 >>> >>> Also, to not have interference with the benchmarking process we reduce the >>> priority of the process used in benchFor: >>> >>> benchFor: duration >>> "Run me for duration and return a BenchmarkResult" >>> "[ 100 factorial ] benchFor: 2 seconds" >>> | count run started | >>> count := 0. >>> run := true. >>> [ duration wait. run := false ] forkAt: Processor timingPriority - 2. >>> started := Time millisecondClockValue. >>> [ run ] whileTrue: [ self value. count := count + 1 ]. >>> ^ BenchmarkResult new >>> iterations: count; >>> elapsedTime: (Time millisecondsSince: started) milliSeconds; >>> yourself >>> >>> >>> We will create an entry in fogbugz and submit the change. >>> >>> Regards, >>> Martin, Guille and Pablo >>> >>> >>> >>> On Wed, Nov 18, 2015 at 8:33 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> I went ahead and implemented a simple fix for the styler. Not sure how >>>> well it performs but in my simple experiments it seems to work fine. Please >>>> test it and let me know what you think. >>>> >>>> >>>> https://pharo.fogbugz.com/f/cases/17050/SHTextStyler-styleInBackgroundProce… >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> > On 18 Nov 2015, at 19:02, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: >>>> > >>>> > >>>> > >>>> > Am 18.11.15 um 11:48 schrieb Andrei Chis: >>>> >> Can you try the script below in the latest Pharo image and let me know >>>> >> how much does it take to execute on your machine: >>>> >> >>>> >> |duration benchmarkResult| >>>> >> 100 timesRepeat: [ >>>> >> RubScrolledTextMorph new >>>> >> model: (RubScrolledTextModel new setInitialText: '1+1'; yourself); >>>> >> beForSmalltalkScripting; >>>> >> yourself >>>> >> ] . >>>> >> >>>> >> duration := 100 milliSeconds. >>>> >> benchmarkResult := [ 100 factorial ] benchFor: duration. >>>> >> >>>> >> In my case it takes around 1 minute. The inner loop finishes >>>> >> immediately and then most time is spend executing the benchmark. >>>> >> >>>> >> At the end I get the following result: >>>> >> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 >>>> >> milliseconds. 30,525 per second)" >>>> >> >>>> >> So the benchmark is executed for over one minute before the delay >>>> >> expires. >>>> >> >>>> >> >>>> >> >>>> > "a BenchmarkResult(1,263,573 iterations in 37 seconds 689 milliseconds. >>>> > 33,526 per second)" >>>> > (HP Z420 with Xeon E5-1620 under OpenIndiana). >>>> > >>>> > Regards >>>> > Andreas >>>> >>>> >>> >>

Nov. 20, 2015

Re: [Pharo-dev] Recovering _lost_ changes

by Skip Lentz

Hi, > On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > is Epicea integrated already? No, not yet I think. > If so, is it possible to apply all the changes to code (without doits) since the last image save? I think that it should be really helpful because searching for changes and cherry-picking them is a pain. You can see the lost changes in the âOld sessionsâ browser (in the World menu). You have to then open the appropriate session, the timestamp shows when they were last modified. Open the one when you crashed the image, or whatever happened. This will open the log browser. As of now you have to manually select all events (using shift you can select a range of events in the log).Then you have to redo them in one go by right clicking the selection. Double check the changes for the time being as the redoing and undoing functionality is still being tested. For example, right now you will get an error when you redo (or undo) a class comment change. I will try to fix this bug right now. > Later this can be improved, so before the changes are applied you see the condensed diff. Yea that would be nice.. Also functionality for in the special case of recovering changes should really be there.. Skip

Nov. 20, 2015

Re: [Pharo-dev] Smalltalkhub is very instable this afternoon

by Esteban Lorenzano

done > On 20 Nov 2015, at 11:41, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hello, > > Can Smalltalkhub be restarted (or other) because it is impossible to work by getting continuously errors 500, 503, 403, 401â¦. while loading or committing? > > TIA > > Cheers, > > Vincent BLONDEAU > > > 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.

Nov. 20, 2015

Re: [Pharo-dev] Refactoring and traitsâ¦

by webwarrior

Definitely had this (new methods are compiled in concrete classes instead of changing the trait method) several times, although I'm not sure if it was after refactoring, or something else (loading packages?). -- View this message in context: http://forum.world.st/Refactoring-and-traits-tp4862223p4862258.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2015