- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Epicea - showing latest lost changes

by Martin Dias

On Fri, Mar 3, 2017 at 1:55 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, Feb 28, 2017 at 7:04 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > >> Uko: OK, added it as: https://pharo.fogbugz.com/ >> f/cases/19768/Epicea-Lost-Changes-Detector-Add-Apply-all-but >> ton-on-top-of-the-list-of-change >> >> Stef: I see... each line should have a checkbox. I remember to see in >> Spec's FastTableModel a method to enable that... I will try. >> >> Ben: I think that's not necessary because the EpLostChangesDetector >> already opens a browser where only the "lost changes" are visible. Where >> "lost changes" means everything logged by Epicea after last Image Save. >> > > I paid particular attention this time to starting after a crash and one > thing I'm uncertain about. > Its good that the window says "Lost Changes Detected" > but its not clear the meaning at the bottom where it says "22 filtered > entries" > Does this mean these 22 entries were not lost? > Or is it some other reason? > Also, I've a (only mild) concern that I can't see what these other entries > are, since I don't know if they are important? > > Hi! you are the first one that mentions this "x filtered entries". Yes, "filtered" like "hidden by a filter". Casually, I've worked on its removal. Reasons: implementation is ugly; it difficults time optimizations; it's not standard visually (I suspected nobody undertand it). I'm also removing the "See 50 more" button, which makes the list of changes look more as a standard list, to the user eyes. I'm preparing a new release with these changes, and replacing the TreeModel by a FastTableModel which is much better to scroll on the changes freely. > Can you make it more explicit what the filter is? > Oh, after a while I realise there is a tab for this. > Perhaps at the bottom of the changes list > you could say "22 filtered entries (see Active Filters tab)" > to help slow people like me. > For the moment, I only added the number of applied filters in the Tab's title, like "Active filters (2)". > So if 'remove all filters", what is the easy way to return to > the identical previous "Lost Changes" filter. > I realise now that I've been missing the old "indication of save points" > The "save points" were deactivated as a workaround the this bug: https://pharo.fogbugz.com/f/cases/18374/ If we fix this case in another way, then we can restore the logging of image save points (EpSessionSnapshot event). Cheers MartÃn Then I guess I'd be able to select that line and filter "afterwards" > > cheers -ben > >

March 9, 2017

Fwd: Where are the Metacello ConfigurationOfYourProject supposed to be?

by Nicolas Cellier

Grrr, even the mailing list changes, the first match in gmail just bounces, ;) ---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2017-03-10 0:05 GMT+01:00 Subject: Where are the Metacello ConfigurationOfYourProject supposed to be? To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr>, The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> Hi, I must come back to one of the balkanization and lack of stability that most upset me. Imagine that you are developping a cross dialect library, say for Squeak/Pharo and why not Gemstone. Imagine that this library has a few dependencies to some other libraries, either Core like Alien/FFI or more exotic third party also available in other dialects. The question are: -1) where are you supposed to maintain your own ConfigurationOf*? -2) where are you supposed to find the ConfigurationOf* dependencies? Once upon a time, the answer would have been http://www.squeaksource.com/MetacelloRepository But now, what is it? I see surprisingly few updates here (apart from Sven and a few others). How can the Metacello feature of supporting cross-dialect work if the dialect specific configuration of dependencies are scattered all around the web? Do the CPAN or PyPI have to change their URL each time a new release of perl or python is released? Careless decisions in this area can easily sabotage the cross-dialect initiative. Maybe I'm ranting by ignorance. I wish your answers will reassure me. Nicolas

March 9, 2017

Re: [Pharo-dev] Catalog projects in Spotter

by Yuriy Tymchuk

Hi Torsten, > On 9 Mar 2017, at 23:04, Torsten Bergmann <astares(a)gmx.de> wrote: > > Uko wrote: >> If there is a rule not to duplicate preferences, why is catalog not following it? > > Because at the time when I implemented it for catalog there was no other setting. > > The enabling/disabling for all GT extension was introduced later. Also the confusing > default was introduced later (with the more hidden spotter extension disabled and > leaving the Catalog setting enabled) leading to this whole mess. > > To be honest I dont care or respond anymore on the whole issue because as we now know from > the long discussion the only outcome is that: > > <sarcasm> > - most of us should be knowledgable enough to know that two settings exist > - most of us should become experts in fixing deficencies with startup scripts > - most of us should accept that we have to hide features as deep as possible in the settings tree > - most of us should accept that we have to make it as complicated as possible to load catalog projects > - most of us should accept that we can display and access anything in spotter except catalog projects > - most of us should accept that Pharo videos get broken and never match reality > - most of us should continue to "rest in their comfort zone" > - most of us should continue to be "an egoist instead of being an adult" > - most of us should be allowed to speak up only when they presented Pharo at a university > - most of us should start working with slow networks > </sarcasm> It is really sad but a many things sound like truth. > > Fixing it by removing Spotter and Catalog completely from Pharo would possibly be the > best solution. Anyone up for a slice? While the solution is way more complicated (because we rest in our comfort zones) I will at least try to synchronize the checkboxes, so less people will be confused. Uko P.S. I know that Iâm often harsh on this topic, but it is really frustrating. The catalog search feature is the second most common thing I use spotter for after searching method code. And there are so many roadblocks to use it. First I had to find the checkbox and enable it, then I had to discover that one checkbox is not enough and enable the other checkbox. And then I donât care about freezes because I load additional packages, and a background image, and a porter plugin for querying github (it uses internet too). So when I donât have internet I get freezes and exceptions without even opening Spotter. > > Bye > T. >

March 9, 2017

Spec menu shortcut

by Martin Dias

Is it known that Spec models ignore menu shortcuts? at least some of them, TreeModel and FastTableModel. Example: | example | example := FastTableModel new. example items: (1 to: 10); menu: [ | aMenu | aMenu := MenuModel new. aMenu addGroup: [ :aGroup | aGroup addItem: [ :anItem | anItem name: 'Halt'; shortcut: $h command; action: [ 1halt ] ] ]. aMenu buildWithSpecAsPopup ]; openWithSpec. This is latest Pharo 6. Cheers, MartÃn

March 9, 2017

Re: [Pharo-dev] Catalog projects in Spotter

by Torsten Bergmann

Uko wrote: >If there is a rule not to duplicate preferences, why is catalog not following it? Because at the time when I implemented it for catalog there was no other setting. The enabling/disabling for all GT extension was introduced later. Also the confusing default was introduced later (with the more hidden spotter extension disabled and leaving the Catalog setting enabled) leading to this whole mess. To be honest I dont care or respond anymore on the whole issue because as we now know from the long discussion the only outcome is that: <sarcasm> - most of us should be knowledgable enough to know that two settings exist - most of us should become experts in fixing deficencies with startup scripts - most of us should accept that we have to hide features as deep as possible in the settings tree - most of us should accept that we have to make it as complicated as possible to load catalog projects - most of us should accept that we can display and access anything in spotter except catalog projects - most of us should accept that Pharo videos get broken and never match reality - most of us should continue to "rest in their comfort zone" - most of us should continue to be "an egoist instead of being an adult" - most of us should be allowed to speak up only when they presented Pharo at a university - most of us should start working with slow networks </sarcasm> Fixing it by removing Spotter and Catalog completely from Pharo would possibly be the best solution. Anyone up for a slice? Bye T.

March 9, 2017

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

by phil＠highoctane.be

Figuring out why my image balloons to 500+ megs and is not shrinking despite new compactor was a nice one + fact that it took 2 minutes to start. Fixed yesterday with the help of Clement and Pavel. First, there was a massive leak of memory from the devtools. https://gist.github.com/philippeback/39c63bb5aa26b79098511cdfea4fea7e fixed it (got the image back to 130 megs, which was ok given the amount of loaded code). Then looking at the startup times to find out the culprit: https://gist.github.com/philippeback/9b6645c62b4cda7c0d4559880fbbe40f Save/Stop/Start and then inspect LOG11. This gaves us entry related to FT2Settings talking the lion share of the delay. Looks like this was because it was refreshing fonts at startup. On my Windows box is was 650 font entries. On Ben's Linux this was 1500+. Ben advised to change this FTHandle>>pvtDestroyHandle, try commenting out the last statement... FT2Handle allSubInstancesDo: [ :each | (handleToRelease = each handle) ifTrue: [ each beNull ] ] This indeed made things faster even with the setting. No proof that will be not leading to more trouble b/c this code supports the workaround for FT2Handle duplicates (that FT2 bug alone deserves a cake too by itself). So, things are back to normal now in that image and nothing had to do with my own code. Thx again for the help. And compactor works wonderfully indeed. Note that current figures in the VM Stats are completely bogus at places and need to be rewritten/recomputed since we are using Spur and things are not the way they used to be. I took plenty of notes from what Clement told me. Hope to integrate that into the MemoryMonitor at one point. Phil

March 9, 2017

Re: [Pharo-dev] [Vm-dev] We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity

by Eliot Miranda

Hi Juan, Hi All, On Mon, Mar 6, 2017 at 6:06 AM, Juan Vuletich <JuanVuletich(a)zoho.com> wrote: > > I finally understood what was happening. The problem with is primitive 136: > > primSignal: aSemaphore atMilliseconds: aSmallInteger > "Signal the semaphore when the millisecond clock reaches the value of > the second argument. Fail if the first argument is neither a Semaphore nor > nil. Essential. See Object documentation whatIsAPrimitive." > <primitive: 136> > ^self primitiveFailed > Yes, but primitive 136 *should not be used* :-). You should use primitive 242: primSignal: aSemaphore atUTCMicroseconds: anInteger "Signal the semaphore when the UTC microsecond clock reaches the value of the second argument. Fail if the first argument is neither a Semaphore nor nil, or if the second argument is not an integer. Essential. See Object documentation whatIsAPrimitive." <primitive: 242> ^self primitiveFailed The use of the UTC microsecond count eliminates any and all wrapping issues for about 50,000 years [puhleaze Mr Pruitt can you try and do your bit to make it possible that we'll make it that far. hic. ed.]. The old primitive 136 primSignal:atMilliseconds: is subject to wrapping problems. I see that primSignal:atMilliseconds: is still used in Squeak 5.x but only to turn off signaling: Delay class>>shutDown "Suspend the active delay, if any, before snapshotting. It will be reactived when the snapshot is resumed." "Details: This prevents a timer interrupt from waking up the active delay in the midst snapshoting, since the active delay will be restarted when resuming the snapshot and we don't want to process the delay twice." AccessProtect wait. self primSignal: nil atMilliseconds: 0. self saveResumptionTimes. DelaySuspended := true. Delay class>>stopTimerInterruptWatcher "Reset the class variables that keep track of active Delays and re-start the timer interrupt watcher process. Any currently scheduled delays are forgotten." "Delay startTimerInterruptWatcher" self primSignal: nil atMilliseconds: 0. TimingSemaphore ifNotNil:[TimingSemaphore terminateProcess]. I will change this now. HTH > If the requested tick is already in the past, all the VMs except for > Spur-64 will signal the semaphore anyway. Spur-64 won't. Taking care of > this in the Cuis image was easy enough. > > Squeak seems not to be affected because it uses a newer primitive, that > takes the large integer microsecond ticker, that might have the older > behavior (signaling anyway). I'm not really sure, and maybe someone could > check the primitive behavior and the corresponding assumptions in Squeak. > > Older Squeak images are not affected, as they are all 32-bit. So maybe > there's no action required. In any case, making the behavior consistent > across VMs and in both primitives would be nice. > > Cheers, > > On 3/3/2017 3:55 PM, Juan Vuletich wrote: > > > > Hi Folks, > > Today, I was able to get closer to the origin of the problem. The problem > is when Morphic tries to do a Delay (inter-cycle-pause) of 1 or two > milliseconds. (Usually they are quite larger, and the problem does not > appear). With the 64-bit VM, sometimes very short delays hang the complete > system. I don't know why, but this: > > waitDelay _ Delay forMilliseconds: 50. > [ true ] whileTrue: [ > 1000 atRandom print. > waitDelay setDelay: 1; wait ]. > > is enough to hang Cuis in a short time. When trying to reproduce the > problem in Squeak I had mixed results. It doesn't seem to hang there, but > if I let this run for a couple of minutes and then try to halt with alt-. , > then the hang occurs, and Squeak becomes irresponsibe. As a workaround, in > Cuis in the inter cycle pause, I'm avoiding very short delays. > > I'm not sure if the bug is in the VM, in the image, or both, but it is > still there, and it also affects Squeak. I haven't tried it, but Pharo > might also have the problem (if not, it can show a possible solution). > > BTW, Bert, I guess Squeak never does short delays in #interCyclePause: ... > > Thanks, > > On 2/6/2017 12:28 PM, Bert Freudenberg wrote: > > > > Yes, I tried with Spur64. Have not seen it freeze yet on Mac in Squeak, > but we possibly have not replicated the test well enough yet. > > It *did* freeze in Cuis Spur64 on Mac too. > > - Bert - > > On Mon, Feb 6, 2017 at 2:08 PM, Juan Vuletich <juanvuletich(a)zoho.com> > wrote: > >> >> Were you usig Spur64? On Debian it does not freeze with CogV3 or Spur32. >> Only with Spur64. >> >> Thanks, >> Juan >> >> Sent using Zoho Mail <https://www.zoho.com/mail/> >> >> >> ---- On Mon, 06 Feb 2017 09:19:48 -0300 * bert(a)freudenbergs.de >> <bert(a)freudenbergs.de> * wrote ---- >> >> On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <lewis(a)mail.msen.com> >> wrote: >> >> It would be interesting to try reproducing this in a Squeak image, but I >> have not quite figured out how to make the Tokenish example work in >> Squeak. >> >> >> See attachment. Did not freeze on Mac with 10 Tokenish jumping. >> - Bert - >> >> >> >> > > > -- > Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smallt… > @JuanVuletich > > > > -- > Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smallt… > @JuanVuletich > > > -- _,,,^..^,,,_ best, Eliot

March 9, 2017

Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face

by stepharong

we were talking during the workshop and on the simple things to help. - watch points with history of the value. - stop if the value of an instance variable is getting irregular i.e., = you get integer and suddenly inside you get a float! 1 1 1 1 2 3 4 2 2 1 1 12 2 3 32 1 1 1 1 22 1 1 1 1 1 1 1 2 33 1.2 2 3 3 4 4 - start to monitor (put alarm/breakpoints) newly created instances from a point I hope that soon we will have instance specific features of the Ressia debugger in Pharo debuger (stop the next time this object receive a message, stop the next tie this object changes any of its instance variables).

March 9, 2017

implementors followed by rename method -> DNU

by stepharong

Hi I have the impression that if you - perform an implementor of a method (not closing the window) - then perform an rename method => you get a DNU ast Could I get some confirmation? Stef

March 9, 2017

Re: [Pharo-dev] What is the craziest bug you ever face

by Holger Freyther

> On 9 Mar 2017, at 12:36, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > During the DSU workshop we were brainstorming about what are the most difficult bugs we faced and what are the conceptual tools that would have helped you. Tracking down a problem where a header file was like this struct touch_screen_event { #ifdef SOME_FLAG ... other fields #endif int x; int y; int pressure; }; The touchscreen library was compile with -DSOME_FLAG but the code using that library didn't have the flag set. This means the code using the touchscreen events read x/y from the wrong offset in memory. The example work of the touchscreen library worked while the real user didn't. It would have helped to embed struct sizes and offsets into the shared library to find differences at link time. --- Keyboard handling in kdrive (an Xserver for embedded/mobile usage): After plugging/unplugging USB into the device, the keyboard started to generate wrong keycodes. In Linux (depending on your keyboard mode) every key event is represented as a byte(?). This worked for a long time but then keyboards started to have more keys. So a special key value is used to indicate that a multi byte sequence will follow. As it turns out plugging/unplugging generated a multi-byte keyboard event... Not sure what would have helped? :)

March 9, 2017