May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TEXT drag and drop

by Thierry Goubier

Le 19/05/2016 06:36, Esteban Lorenzano a Ã©crit : > I would vote yes :) Agreed. This is cool. One thing: the 'more' when longer than 8 characters is a bit confusing: I'd prefer just ... (three dots). Or, even better, allow for a longer uncut word (20 ?) and, if longer, cut in the middle with '...' (keep beginning and end of the word). Regards, Thierry >> On 18 May 2016, at 22:02, Torsten Bergmann <astares(a)gmx.de >> <mailto:astares@gmx.de>> wrote: >> >> Hi Liang Bing, >> nice! Could be a nice addition to the standard image if others like it >> too. >> Did you already sign as contributor? >> Thx >> T. >> *Gesendet:* Mittwoch, 18. Mai 2016 um 19:09 Uhr >> *Von:* lb <liangbing64(a)126.com <mailto:liangbing64@126.com>> >> *An:* pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >> *Betreff:* [Pharo-dev] TEXT drag and drop >> Hi, >> I have made a little tool for draging and dropping text selection. >> like windows Word. >> It can work in Pharo 40 50 and 60. >> Have a fun! >> LiangBing >> MCHttpRepository >> location: >> 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' >> user: '' >> password: '' >> >

May 19, 2016

Re: [Pharo-dev] TEXT drag and drop (Torsten Bergmann)

by lb

Thank you Torsten and Esteban I desire to be a contributor of Pharo. Cheers! Liang Bing

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Sven Van Caekenberghe

https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForNam… > On 19 May 2016, at 14:07, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Thu, May 19, 2016 at 1:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me. > > What about instead of turning off the network just open and listen on a local port and direct DNS there? And because there will be no response it might hangâ¦ > > just an ideaâ¦ > > Peter

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Alexandre Bergel

Or at a conference when the keynote is very boring and everybody is checking email or Facebookâ¦ :-) Alexandre > On May 19, 2016, at 10:01 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Thu, May 19, 2016 at 12:41 PM, stepharo <stepharo(a)free.fr> wrote: >> Hi guys >> >> This is hyper annoying that Spotter look for the net by default. >> >> We should turn it off. We should also improve the comment of the catalog >> setting because it is unclear >> >> that this is this setting that should be turned off. > > Yes agree especially in country in Cameroon with low internet bandwith > ... this is not good. > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 19, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60021 Home: https://github.com/pharo-project/pharo-core

May 19, 2016

[pharo-project/pharo-core] 3d437e: 60021

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3d437ebc5201100501bdb2c5443e9e2efb082f66 https://github.com/pharo-project/pharo-core/commit/3d437ebc5201100501bdb2c5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-19 (Thu, 19 May 2016) Changed paths: M Kernel.package/Context.class/class/simulation/initializePrimitiveSimulators.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60020.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60021.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60020.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60021.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-CommandLineHandler.package/PharoCommandLineHandler.class/instance/private - preferences/runPreferences.st M System-Support.package/SystemNavigation.class/instance/query/allUnimplementedCalls.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/setup/expectedFailures.st Log Message: ----------- 60021 18264 WriteBarrierTest are failing. Maybe put on "expected" for now https://pharo.fogbugz.com/f/cases/18264 16084 introduce pragma "ignoreUnimplementedCalls:" https://pharo.fogbugz.com/f/cases/16084 18262 safe usage of optional StartupPreferencesLoader in the PharoCommandLineHandler https://pharo.fogbugz.com/f/cases/18262 http://files.pharo.org/image/60/60021.zip

May 19, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Serge Stinckwich

On Thu, May 19, 2016 at 12:41 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > This is hyper annoying that Spotter look for the net by default. > > We should turn it off. We should also improve the comment of the catalog > setting because it is unclear > > that this is this setting that should be turned off. Yes agree especially in country in Cameroon with low internet bandwith ... this is not good. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 19, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Mariano Martinez Peck

On Thu, May 19, 2016 at 4:30 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Squeak caches the opened readonly file(handle). It does not have to reopen > the file on every call for reading (readonly). > > Some years ago I profiled some code of a customer, and there was a single line that was taking up 80% of the total time. Guess what? I was the opening of a temp / log file, which was opened (read only) each time... Caching the opened file was a HUGE speed up. Cheers, > 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> I am wondering why does the search 'method source with it' take so long >> in Pharo 5? On my PC, When I select the text 'menu' and search for all >> 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it >> takes 21 seconds. >> >> >> > -- Mariano http://marianopeck.wordpress.com

May 19, 2016

Re: [Pharo-dev] [ANN] Pharo Sprint 27 May

by Dimitris Chloupis

perfect, I will keep an eye on slack and I think I can spend an hour or so On Thu, May 19, 2016 at 2:00 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > On 19 May 2016, at 12:37, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > what time the sprint ends ? > > > it slows down and drops out around 17-18h local time normally. > > is the sprint only bug orientated ? what about adding class and method > comments ? > > > The idea is to do boring stuff that you canât get yourself todo normallyâ¦ > this is the > overall direction, not a strict rule. > > I can only attend remotely > > Yes, this is why we make it public: so people can join remotely. Of course > it is not the same, > but it can be fun, too. > > Marcus > > On Thu, May 19, 2016 at 11:56 AM Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> We will organize a Pharo sprint / Moose dojo Friday, 27 May, starting at >> 10:00am. (Local Time Lille). >> >> It will be at the Inria Lille, Building B, third floor (RMoD offices). >> >> Remotely, you can join us on Slack or the IRC channel #pharo on >> irc.freenode.net server. During the sprint, we will try to synchronize >> local and remote Pharo sprinters. >> >> As the building is not open to the public, please contact us before if >> you plan to come. >> >>

May 19, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

On Wed, May 18, 2016 at 9:49 PM, Martin McClure <martin(a)hand2mouse.com> wrote: > On 05/18/2016 03:17 PM, Martin McClure wrote: > >> On 05/18/2016 08:49 AM, Mariano Martinez Peck wrote: >> >>> Hi guys, >>> >>> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot >>> explain how this could happened but it does, and it happened to me a couple >>> of times (but not fully reproducible). >>> >>> >> Hmm. The schedulerResumptionTime is, somehow, being (approximately) >> doubled. It's not clear how that can happen, but I'll look a little more. >> >> > Mario, is there any chance that you might be saving the image during one > of these Delays? > > > This one smells like a race condition, and I think I see something that > *might* explain it. But I don't have any more time to spend on this one, so > I'll leave the rest to someone else. I hope this is helpful: > > The only way I immediately see for the schedulerResumptionTime to become > approximately doubled is if the Delay's resumption time is adjusted by > #restoreResumptionTimes without previously having been adjusted by > #saveResumptionTimes. > > The only time either of those are sent, that I can see, is on saving the > image. Both are normally sent, (save before the snapshot, restore > afterwards), but there may be a hole there. > > Martin, first off, thanks for the research!!! Now....your email made me remember something:* I did get VM crash when saving the image a couple of times. The VM crashed when saving the image. *If I re-opened the image, it looks like if the image was indeed saved (so the snapshot primitive itself did work), but I suspect not all shutdown code could have been run correctly. The VM crash looks like the FreeTypeFace >> pvtDestroyHandle which, as far as I know, it's a "known crash" (I attach crash dump). From what I can see, if I follow all the stack, the crash starts from the WeakArray >> startUp: . That means that...depending on the order of the startup list...the Scheduler may not have been run after the crash. Now.... WeakArray initialization does: SessionManager default registerSystemClassNamed: self name. While... Delay class >> startUp "Restart active delay, if any, when resuming a snapshot." Scheduler startUp. And the Delay registration is SessionManager default registerSystemClassNamed: self name atPriority: 20. So...that seems correct... I can verify this by: SessionManager default systemCategory prioritizedList Anyway...not sure if this adds something, but just wanted to note this. > #saveResumptionTimes is only sent (by this scheduler class) when the > accessProtect semaphore is held, but #handleTimerEvent: is executed in the > timing Process *without* the protection of accessProtect, in the case of > the VM signaling the timingSemaphore. If the VM signals the > timingSemaphore, #handleTimerEvent: could run in the middle of > #saveResumptionTimes. If some Delay expires because of that timer event, > our Delay could move from being the first suspended delay to being the > active delay. If that happens after we've adjusted the active delay, but > before we've processed the suspended delays, that Delay will not get > adjusted, and will show the symptoms that Mariano is seeing. > > Also, I'm not sure how the Heap that holds the suspendedDelays will react > to being modified in the middle of an enumeration. That might open a larger > window for the problem. > > Regards, > > -Martin > > -- Mariano http://marianopeck.wordpress.com

May 19, 2016