- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] File List -- MNU: RubTextEditor>>doIt

by Martin McClure

On 05/29/2016 12:52 PM, HernÃ¡n Morales Durand wrote: > In Windows if you select a file with Smalltalk code and right click > you get > > MessageNotUnderstood: FileList class>>allRegisteredServices > > without menu at all. > > I think you have to open a Workspace with contents and then you can > evaluate. > > I don't see any "do-it" right clicking on the file from the FileList. > > Cheers, > > HernÃ¡n > Thanks for the reply, HernÃ¡n. I'm sorry if I wasn't clear -- what I'm doing in the file browser is selecting a file, selecting some text in the text pane, and selecting "Do it" from the right-click menu in the text pane. I'm still seeing the MNU in 50760. Regards, -Martin > > 2016-05-18 2:42 GMT-03:00 Martin McClure <martin(a)hand2mouse.com > <mailto:martin@hand2mouse.com>>: > > So I open Pharo 5, and the *very* *first* thing I do is to open a > file list, select a file that contains the Metacello expression to > load my project, and select "Do it" from the menu. > > And get MNU: RubTextEditor>>doIt > > :-( > > This was on Linux, in case that makes a difference. > > I couldn't quickly track down how this is *supposed* to work. > > Regards, > > -Martin > >

July 17, 2016

100 factorial asMethodConst

by Denis Kudriashov

Hi. As continue to Marcus cool features around haltOnce I implement analogue of Dolphin ##() syntax. Slice is inbox (18768 <https://pharo.fogbugz.com/f/cases/18768/Inlined-method-const-could-be-imple…>). So it will be available soon. Idea is to send message #asMethodConst to result of expression which you want to cache. At first call it will replace full message send node with result as literal. And following method call will use this precomputed value. You can read details in my blog http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html. Best regards, Denis

July 17, 2016

Re: [Pharo-dev] how to update monticello cypress repository downloaded from github?

by Peter UhnÃ¡k

> > Metacello new > baseline: 'FileDialog'; > repository: 'github://peteruhnak/file-dialog/repository'; > get; > load. Using #get indeed downloads a fresh copy, however the code in Pharo is _not_ reloaded. Is this a bug? Or do I need to do yet something more to reload that too? Peter

July 17, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] file dialog replacement experiment

by Peter UhnÃ¡k

On Sat, Jul 16, 2016 at 11:04 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > This is excellent !!! > > We should change the default file browser to be this one ! > I wonderâ¦ does Pharo support such workflow that it would pull the code from github? I.e. the development would continue on GitHub and Pharo would just pull the updates. I believe there are some upstream projects already (GT mostly), but those are on smalltalkhub, and from what I've heard it's a major PITA. Peter

July 17, 2016

Re: [Pharo-dev] Pharo minimal & bootstrapping - Time & DelayScheduler

by stepharo

Hi Ben Le 17/7/16 Ã 14:06, Ben Coman a Ã©crit : > A question on the minimization of the Pharo image and bootstrapping... > Is there a desire to ultimately get down to the point of starting > without the Time class and/or without the DelayScheduler class? Right now I do not think that we are targeting such situation. > > DelayScheduler currently depends on Time, only due to calling > "Time microsecondClockValue' which is <primitive: 240> > so this dependency could be removed by copying #microsecondClockValue > to DelayScheduler. > > How a bad is it to have one primitive invoked from two different methods? This is not that bad. > > cheers -ben > >

July 17, 2016

Pharo minimal & bootstrapping - Time & DelayScheduler

by Ben Coman

A question on the minimization of the Pharo image and bootstrapping... Is there a desire to ultimately get down to the point of starting without the Time class and/or without the DelayScheduler class? DelayScheduler currently depends on Time, only due to calling "Time microsecondClockValue' which is <primitive: 240> so this dependency could be removed by copying #microsecondClockValue to DelayScheduler. How a bad is it to have one primitive invoked from two different methods? cheers -ben

July 17, 2016

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

by Ben Coman

On Wed, Jul 13, 2016 at 12:30 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, May 18, 2016 at 11:39 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Thu, May 19, 2016 at 8:49 AM, 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. >> > >> > #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. >> >> A quick experiment to test this might be in shutDown/#startUp trying... >> [ self saveResumptionTimes ] valueAt: Processor timingPriority >> [ self resumeResumptionTimes ] valueAt: Processor timingPriority >> >> > >> > 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 >> > >> >> Even if not directly related to Mariano's problem, I agree with your >> general assessment. I'm not comfortable with the way that >> #save/#restoreResumptionTimes (which manipulate suspendedDelays) are >> called from user priority code via #shutDown/#startUp. Per the >> original code**, accessProtect can't be used inside the timing >> priority #handleTimerEvent since accessProtect is held by the user >> priority #schedule when it uses "timingSemaphore signal" to invoke >> invokes #handleTimerEvent. accessProtect never protected >> timingPriority manipulation of suspendedDelays by #handleTimerEvent, >> nor expired delays waking up. But ahhh... the disabling of >> accessProtect previously prevented new delays being scheduled between >> a #save and #restore. If a new delay is scheduled after the #save, >> when it is #restore'd its resumptionTime would be wrong. >> >> Waiting in the wings for Pharo 6 I have changes that should help: >> * have #save/#restoreResumptionTimes *only* called from timing >> priority event loop (i.e. #handleTimerEvent) >> * shutDown/startUp suspends/resumes the timing priority event loop, >> instead of trying to block signals to timingSemaphore >> >> I haven't touched it for a few months so I'll need to chase it up to >> provide a preview. >> >> >> >> Mariano, can you try DelayMillisecondScheduler (which however is >> missing some fixes for other issues). >> > > > Ben, > > Did you find a chance to do something else with this? I am still finding > lookups every in a while even with the DelayMillisecondScheduler :( Hi Mariano, Sorry for the delay attending to this. I got a bit twisted up on whether I'm complicating things too much with my DelayScheduler refactoring for Pharo 6 (I should just put it out for early review), but then I had to get through a Netflix addiction to the Star Trek prequel Enterprise, and family time over my kids school holidays. I'm back looking at it now - and taking a step back to see what is the minimum change required to fix this. Do you have some test code or a test image I could run to reproduce the problem? Now I have one thing for you to try. In the move of DelaySchedulerXxx from milliseconds to microseconds, the code for dealing with clock wrap-around was removed, but I wonder if it was also covering clock jitter as a side effect. Could you try again the SpinScheduler but restore this code... >From handletTimerEvent... "Check for clock wrap-around." millisecondNowTick < activeDelayStartTime ifTrue: [ "clock wrapped" self saveResumptionTimes. self restoreResumptionTimes ]. activeDelayStartTime := millisecondNowTick. >From runTimerEventLoop... Time millisecondClockValue < millisecondNowTick ifTrue:[ timingSemaphore signal ]. "retry" >From startup... activeDelayStartTime := Time millisecondClockValue. cheers -ben

July 17, 2016

Re: [Pharo-dev] how to update monticello cypress repository downloaded from github?

by Dale Henrichs

On 7/16/16 10:26 AM, Peter UhnÃ¡k wrote: > Hi, > > how can one update a cypress github repository? > > e.g. I install it like this > > Metacello new > baseline: 'FileDialog'; > repository: 'github://peteruhnak/file-dialog/repository'; > load. > > And then later I want to pull latest changes > > as the repo itself doesn't contain commits I cannot do it from > Monticello Browser. > > The only way I found was to > > 1. delete github-cache folder in the image folder > 2. unload all the loaded packages > 3. execute this script again > > This is really heavy-handed approach. > > Maybe the class BaselineOf could contain method #update or something > like that that will automatically do this? > > Or is there a better way? > Reloading the baseline using the #get message will cause a fresh download from github, so the following should do the trick: Metacello new baseline: 'FileDialog'; repository: 'github://peteruhnak/file-dialog/repository'; get; load. Dale

July 17, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Sean P. DeNigris

EstebanLM wrote > just submit an SLICE, for nowâ¦ I will sync the repository. Great. Done. Slice in inbox: SLICE-Issue-18757-Simple-Shell-Command-Eval-for-50-SeanDeNigris.1 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4906799.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 17, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] file dialog replacement experiment

by Johan Fabry

This is excellent !!! We should change the default file browser to be this one ! -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jul 16, 2016, at 13:05, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Couple more updates: > > > If you truncate, you could put the full, non truncated path in a pop over, that would be a cheap way to solve that problem, no ? In any case, in my testing there was enough space. > > Fixed > > > Maybe also add a trailing / to indicate that it represents the directory and not the selection ? > > Fixed > > > the path is initially blank, it only fills when I start clicking. > > Fixed > > > And related to github filetree, what is the proper way to get a new version once you loaded the code ? > > What seems to work is to delete github-cache folder in image directory and unload both file-dialog and BaselineOfFileDialog packages, and then reexecute the load script again. > As this is really stupid, I'll have to ask Thierry or someone. > > And couple of more fixes based on Torsten's feedback: > > 1. the Open/Cancel buttons are swapped on Windows > 2. the FileSystem bookmark has been replaced with available disks on Windows (C:, D:, ...) > 3. Added basic entry completion when saving; note that Dark Theme and the EntryCompletion popup do not like each other --- this has to be fixed inside Pharo. > > <completion.png> > â > > One more thing I want to add really soon: clicking on a file would open a GTInspector on the side (as part of the window), so you can see the preview of text/image/etc > > Peter > > On Sat, Jul 16, 2016 at 2:25 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > On Fri, Jul 15, 2016 at 2:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> On 14 Jul 2016, at 23:49, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> Hi Sven, >> >> What I am missing in the UI is some indication of the path that leads to the current selected file. Right now, I am wondering where exactly I am, I feel a bit lost (this is of course from the technical standpoint of a path in a tree). This could be done with a popup, a trail, a pop-over. >> >> I've added this couple of days ago (as I was missing this too), I just forgot to push the update to github (one downside compared to smalltalkhub :)). >> >> The only problem is that the image directory name is usually really long (the longest I have is 110 characters as it includes the build's name), so it doesn't exactly fit in. >> There is some shortening happening based on the window's width but it's not perfect. > > I had another look. Yes, this is cool. > > If you truncate, you could put the full, non truncated path in a pop over, that would be a cheap way to solve that problem, no ? In any case, in my testing there was enough space. > > If Spec supports it, then it should be easy. > > > Maybe also add a trailing / to indicate that it represents the directory and not the selection ? > > Originally I wanted to make it bold, but again, Spec doesn't support Text properly; trailing slash might be a compromise for now > > > <Screen Shot 2016-07-15 at 13.58.27.png> > > Also when I tested it, using > > FDOpenFileDialog new openModal. > > the path is initially blank, it only fills when I start clicking. > > That's a bug, I'll fix that. > > > BTW, could it be that FDMorphicUIManager becomes default automatically ? > > That seems quite aggressive, I don't feel it's stable enoughâ¦ I could add something like #load, and #loadDefault to the load scriptâ¦ but then you might as well execute the beDefault. I'm not sure yet. > > > And related to github filetree, what is the proper way to get a new version once you loaded the code ? > > I don't know, but it should be the same as with any other (e.g. smalltalkhub) project, since it's both monticello, no? I've never done this, so I don't know. (Usually when I am updating I look at the individual commits because I want to know what has changed.) > > Peter >

July 16, 2016