[Pharo-dev] [Pharo 7.0-dev] Build #976: 22000-Click-on-the-taskbar-empty-space-should-open-the-world-menu
There is a new Pharo build available! The status of the build #976 was: SUCCESS. The Pull Request #1454 was integrated: "22000-Click-on-the-taskbar-empty-space-should-open-the-world-menu" Pull request url: https://github.com/pharo-project/pharo/pull/1454 Issue Url: https://pharo.fogbugz.com/f/cases/22000 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/976/
Re: [Pharo-dev] IMPORTANT: ML Etiquette
> Sent: Sunday, May 27, 2018 at 11:48 PM > From: "Sean P. DeNigris" > To: pharo-dev@lists.pharo.org > Subject: [Pharo-dev] IMPORTANT: ML Etiquette > > Dear all, > > There were several posts in the "Beacon for Pharo 7" thread which top-posted > on top of massive unsnipped quotes that were several-previous-posts deep. > IMHO this made the conversation impossible to follow. This issue has cropped > up from time to time in other threads. > > Please adhere to basic ML etiquette [1] to maximize our effectiveness. Two > essential guidelines are: > 1) snip quoted material to just what's necessary to understand what's > being replied to > 2) Post reply /after/ the quote from the OP, not before. 3) Use plain text. Disable any HTML formatting in your mail client. > 1. > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiquette.html#idp55179976 > > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > ___ montyos.wordpress.com
[Pharo-dev] [Pharo 7.0-dev] Build #974: 22006-add-startUsingOverlayForDevelopment-stopUsingOverlayForDevelopment
There is a new Pharo build available! The status of the build #974 was: SUCCESS. The Pull Request #1449 was integrated: "22006-add-startUsingOverlayForDevelopment-stopUsingOverlayForDevelopment" Pull request url: https://github.com/pharo-project/pharo/pull/1449 Issue Url: https://pharo.fogbugz.com/f/cases/22006 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/974/
Re: [Pharo-dev] Curious context change latency experiment results (wrt DelayScheduler)
Hi Ben, _,,,^..^,,,_ (phone) > On May 26, 2018, at 10:46 PM, Ben Coman wrote: > > > >> On 6 May 2018 at 04:20, Eliot Miranda wrote: >> Hi Ben, >> >> >>> On May 5, 2018, at 7:25 AM, Ben Coman wrote: >>> >>> >>> On 5 May 2018 at 22:10, Ben Coman wrote: One of the key parts of Delay scheduling is setting the resumption time. There are two places this could be done. a. In Delay>>#schedule, running (for example) at userSchedulingPriority=40 b. In DelayMicrosecondScheduler>>#handleTImerEvent:, running at timingPriority=80 When we were using the millisecond clock for delay scheduling, it made sense to use (b.) since the clock might(?) roll over between when resumption time was set, and when #handleTImerEvent: expires delays. This should not be a problem now that we are using the microsecond clock, so I wondered what the latency penalty might be between (a.) and (b.). I ran a little experiment that indicates the cost/latency of switching threads, and was curious if anyone can comment on the validity of the experiment and interpretation of results. I made the following three changes... DelayScheduler subclass: #DelayMicrosecondScheduler instanceVariableNames: 'latencyStart countSinceLastZero' classVariableNames: 'LatencyCounts' poolDictionaries: '' category: 'Kernel-Processes' DelayMicrosecondScheduler>>#schedule: aDelay latencyStart:= Time primUTCMicrosecondsClock. "This is position (a.)" aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has already been scheduled.']. accessProtect critical: [ scheduledDelay := aDelay. timingSemaphore signal. "#handleTimerEvent: sets scheduledDelay:=nil" ]. DelayMicrosecondScheduler>>#handleTimerEvent: microsecondNowTick | microsecondNextTick | "Process any schedule requests" "This is position (b.)" scheduledDelay ifNotNil: [ |latency| latency := Time primUTCMicrosecondsClock - latencyStart. LatencyCounts ifNil: [ LatencyCounts := Bag new ]. LatencyCounts add: latency. latency = 0 ifTrue: [ countSinceLastZero := 1 + (countSinceLastZero ifNil: [0])] ifFalse: [Transcript crShow: 'zero latency count ' , countSinceLastZero printString ; show: ' before latency ', latency printString. countSinceLastZero := 0]. "Schedule the given delay." scheduledDelay scheduler: self resumptionTime: microsecondNowTick + (1000 * scheduledDelay millisecondDelayDuration). self scheduleDelay: scheduledDelay. scheduledDelay := nil ]. rest of method unchanged Then opened the Transcript and in Playground evaluated... Delay delaySchedulerClass: DelayMicrosecondScheduler. The Transcript results are shown below with some comments inserted. Now I guess the latency is affected by garbage collection. But one thing I was curious about is why the latency's were quantised in 1000s. Another interesting thing is that vast majority of the latency's were zero, which was a nice surprise, but can it be true? Or is it a consequence of the quantitisation rounding down? It seems that the idle-ness of the image affected how often a non-zero latency occurred. After I left the house for a while, the count of zero latency was very high, but a few still occurred. It would make sense there was less GC while idle. What is a good snippet of code to stress GC. I presume the latency might increase. zero latency count 2273 before latency 1000 zero latency count 943 before latency 1000 zero latency count 3666 before latency 1000 zero latency count 1643 before latency 1000 zero latency count 27 before latency 1000 "Left house for 20 minutes" zero latency count 12022 before latency 1000 zero latency count 15195 before latency 1000 zero latency count 41998 before latency 1000 "Returned from outing" zero latency count 128 before latency 1000 zero latency count 116 before latency 1000 zero latency count 555 before latency 1000 zero latency count 2377 before latency 1000 zero latency count 5423 before latency 1000 zero latency count 3178 before latency 1000 zero latency count 47 before latency 1000 zero latency count 2276 before latency 1000 "Left house to go shopping" zero latency count 6708 before latency 3000 zero latency count 4896
[Pharo-dev] [Pharo 7.0-dev] Build #975: 21959-Package-Slot-Traits-is-empty-and-can-be-removed
There is a new Pharo build available! The status of the build #975 was: FAILURE. The Pull Request #1414 was integrated: "21959-Package-Slot-Traits-is-empty-and-can-be-removed" Pull request url: https://github.com/pharo-project/pharo/pull/1414 Issue Url: https://pharo.fogbugz.com/f/cases/21959 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/975/
[Pharo-dev] [Pharo 7.0-dev] Build #973: 22008-Move-GTPlaygroundBasicTest-cleaning-to-tearDown
There is a new Pharo build available! The status of the build #973 was: SUCCESS. The Pull Request #1451 was integrated: "22008-Move-GTPlaygroundBasicTest-cleaning-to-tearDown" Pull request url: https://github.com/pharo-project/pharo/pull/1451 Issue Url: https://pharo.fogbugz.com/f/cases/22008 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/973/
[Pharo-dev] [Pharo 7.0-dev] Build #972: 21815-shrink-for-OrderedCollection
There is a new Pharo build available! The status of the build #972 was: FAILURE. The Pull Request #1428 was integrated: "21815-shrink-for-OrderedCollection" Pull request url: https://github.com/pharo-project/pharo/pull/1428 Issue Url: https://pharo.fogbugz.com/f/cases/21815 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/972/
[Pharo-dev] [Pharo 7.0-dev] Build #971: Format methods from the suggestion menu in a debugger leads to a DNU …
There is a new Pharo build available! The status of the build #971 was: SUCCESS. The Pull Request #1423 was integrated: "Format methods from the suggestion menu in a debugger leads to a DNU …" Pull request url: https://github.com/pharo-project/pharo/pull/1423 Issue Url: https://pharo.fogbugz.com/f/cases/21377 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/971/
Re: [Pharo-dev] IMPORTANT: ML Etiquette
On 28/05/2018 12:36, Tim Mackinnon wrote: > Sent from my iPhone >> On 28 May 2018, at 17:26, Stephan Eggermont wrote: >>> Sent from my iPhone >> That supports NewsTap, which makes it easy to not top-post. I’m not sure >> why lines are not broken though. > > I’ll try my best - but the normal iPhone mail client simply doesn’t work this > way - it top posts. I'm fine with top posting. Even when a thread has both top and in-between replies. What really bothers me is that top posting "hides" the huge list of replies at the bottom. So a two line, top posted reply is a 500 lines of quoted email below. Top posting should be limited to one quoted email only. Otherwise you need to start referencing things by letters/numbers or better... reply below :) > I think we’re on a losing battle with this one. I agree. But I'm not giving it away without a fight :P Regards, -- Esteban A. Maringolo
[Pharo-dev] Horrible mess in keyboard modifiers processing
On Linux and Windows, the keyboard usage is very limited, especially in combination with the mouse. There is no way how to invoke any key corresponding to Mac command key (⌘). As result there are is no option how on these platforms select several nonadjacent methods in Calypso to display them at once and you cannot click on a method selector to reach the implementation. I tried to log modifiers on input events on all three platforms and this is the sad result: Mac: shift 0 1 1 0 ctrl 0 2 2 0 option (⌥) 0 4 4 0 command (⌘) 0 8 8 0 The numbers are in order: - modifier key pressed - mouse down - mouse up - modifier key released So on Mac the mouse events are processed correctly but the events related keyboard have no modifiers flags. Linux: shift 0 1 1 0 ctrl 0 0 2 0 win - 0 0 - alt 0 - - 0 altgr - 0 0 - So on Linux the Shift key is processed correctly, The Ctrl key does not have correct modifier flag when the mouse is pressed (which is strange because the combination of Shift+Ctrl returns 0 3 3 0). Win key changes click behavior to right mouse button. For Alt the mouse events are not detected at all and AltGr behaves as Win except the right mouse button simulation. The keyboard event modifiers are not set. Windows: shift 16 1 1 1 16 ctrl 17 2 2 2 17 win - 0 0 0 - alt 18 8 8 8 18 altgr 18 8 8 8 18 Windows as the only platform set modifiers for keyboard events. The mouse button release generates two events, Win key changes behavior to right mouse button, and Alt behaves the same way as AltGr. Cheers, -- Pavel
Re: [Pharo-dev] IMPORTANT: ML Etiquette
Sent from my iPhone > On 28 May 2018, at 17:26, Stephan Eggermont wrote: > > >> Sent from my iPhone > > That supports NewsTap, which makes it easy to not top-post. I’m not sure > why lines are not broken though. I’ll try my best - but the normal iPhone mail client simply doesn’t work this way - it top posts. I think we’re on a losing battle with this one. I do have a copy of NewsTap - I’ll try it again, but I recall mail is just more convenient. I think Stef is possibly right - if we’re arguing about top vs bottom - we’re better off writing code instead - it possibly means a thread has gone in too long. Tim
Re: [Pharo-dev] IMPORTANT: ML Etiquette
Tim Mackinnon wrote: > In a world of mobile phones, I think you have to accept top posting, it’s > just too hard to work otherwise on a small screen ... that said, quoting > a small piece to reply to - is doable, and I think we can all try to do that? I strongly prefer ML-etiquette. > Sent from my iPhone That supports NewsTap, which makes it easy to not top-post. I’m not sure why lines are not broken though. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Guillermo Polito wrote > Announcements have other problems on their own, as we were talking with > Pablo the other day. They are not reentrant (what happens if an > announcement is raised during the treatment of an announcement? Does it > loop?) What? The new event is delivered, of course. If the complaint is "When I write an infinite loop using announcements, it is an infinite loop", I don't know what to tell you... Guillermo Polito wrote > , they block the caller until all announcements are processed (not so > decoupled, huh :P), Avoiding subscribers who take too long to process the subscription, *should* be the responsibility of each subscriber. If you think announcement overhead is bad now, imagine what happens if you fork of a process for every delivery. Depending on priority, you'd still have a problem in that it either in effect will still block the sender, or not be processed at all until sender completes. Also, good luck debugging. Show me *one* other event registration framework in a green-threaded system that hasn't made the same tradeoff, and I'll buy you a beer. Guillermo Polito wrote > right now without looking at the code it's not clear to > me if they can handle the subscription of arbitrary instances instead of > just Announcement (sub)classes (announcer on: arbitraryObject send: ...). The fact you can easily search for users of a given announcement in a standard browser is one of its big advantages compared to the seaside announcements, if you ask me. However, the only hard requirement should be to implement handlesAnnouncement: on whatever is passed to when: (though, there seems to have been a late addition of #prepareForDelivery, which should be handled by announcement initialization, not the delivery mechanism, at least for the use indicated by its comment...). Which still doesn't make it a good idea to implement on arbitrary objects (though it's implemented on Symbol for backwards compatibility with the old event registration mechanism). Guillermo Polito wrote > Not even mentioning the weak/ephemeron mess :). This I can get behind though, the world would be a better place if everyone unregistered their subscriptions properly. ;) (and/or we had a working ephemeron implementation without the same self-referential pitfalls as the weak one) Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
[Pharo-dev] [Pharo 7.0-dev] Build #970: 21997 Cleanup Tool-Diff package
There is a new Pharo build available! The status of the build #970 was: SUCCESS. The Pull Request #1441 was integrated: "21997 Cleanup Tool-Diff package" Pull request url: https://github.com/pharo-project/pharo/pull/1441 Issue Url: https://pharo.fogbugz.com/f/cases/21997 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/970/
Re: [Pharo-dev] [Pharo 7.0-dev] Build #969: 21964-SmalltalkImage-transforming-deprecations-for-old-API
Hello, this puts some transformers on method on “SmalltalkImage” to force people to use “Smalltalk globals” when accessing the global environment. For now these methods are in “Deprecated70”, but we will move them to some compatibility package and not actually remove them for some time. This just forces clients to update the code so we can get rid of them eventually. Marcus > On 28 May 2018, at 13:57, ci-pharo-ci-jenki...@inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #969 was: SUCCESS. > > The Pull Request #1422 was integrated: > "21964-SmalltalkImage-transforming-deprecations-for-old-API" > Pull request url: https://github.com/pharo-project/pharo/pull/1422 > > Issue Url: https://pharo.fogbugz.com/f/cases/21964 > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/969/
Re: [Pharo-dev] IMPORTANT: ML Etiquette
On Mon, May 28, 2018 at 1:40 PM, Tim Mackinnon wrote: > In a world of mobile phones, I think you have to accept top posting, it’s > just too hard to work otherwise on a small screen ... that said, quoting a > small piece to reply to - is doable, and I think we can all try to do that? > Nice example of top-posting xD > > Tim > > >
[Pharo-dev] [Pharo 7.0-dev] Build #969: 21964-SmalltalkImage-transforming-deprecations-for-old-API
There is a new Pharo build available! The status of the build #969 was: SUCCESS. The Pull Request #1422 was integrated: "21964-SmalltalkImage-transforming-deprecations-for-old-API" Pull request url: https://github.com/pharo-project/pharo/pull/1422 Issue Url: https://pharo.fogbugz.com/f/cases/21964 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/969/
Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing
> > So what can we do with this? If you develop a compiler, it is always very > annoying that any change that you do actually breaks the compiler if you do > it wrong. Larger changes over multiple methods get quite hard to do. > > One thing that we will soon have is the “accept for test” feature that I > posted recently. > Another idea is to use the #bindings: feature of the compiler. > > I did small experiment, I added this method to the OpalCompiler class on the > class side: > ….. > > And after that, you can put a #halt deep in the compiler (or do some change > that needs multiple steps), yet compilation will not be affected. > Most tests (not all) are writing in a way that they use classes from the > package directly (they do not go via the global #compilerClass setting). > > So this means that one can now change the compiler as much as one wants, test > it by running tests and then be quite sure that it will not break anything. > > Shortcomings: > -> extensions are not treated, only the main package > -> Not used much, for sure needs testing to see if this really works. > -> Can we get rid of the #CompilerOverlay global? > I made a pull request: https://github.com/pharo-project/pharo/pull/1449 Marcus
Re: [Pharo-dev] IMPORTANT: ML Etiquette
In a world of mobile phones, I think you have to accept top posting, it’s just too hard to work otherwise on a small screen ... that said, quoting a small piece to reply to - is doable, and I think we can all try to do that? Tim Sent from my iPhone > On 28 May 2018, at 07:26, Ben Coman wrote: > > > >> On 28 May 2018 at 11:48, Sean P. DeNigris wrote: >> Dear all, >> >> There were several posts in the "Beacon for Pharo 7" thread which top-posted >> on top of massive unsnipped quotes that were several-previous-posts deep. >> IMHO this made the conversation impossible to follow. This issue has cropped >> up from time to time in other threads. >> >> Please adhere to basic ML etiquette [1] to maximize our effectiveness. Two >> essential guidelines are: >> 1) snip quoted material to just what's necessary to understand what's >> being replied to >> 2) Post reply /after/ the quote from the OP, not before. >> >> 1. >> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiquette.html#idp55179976 > > e.g... > > Because it messes up the order in which people normally read text. > >Why is top-posting such a bad thing? > >>The lost context. > >>>What makes top-posted replies harder to read than bottom-posted? > Yes. > >Should I trim down the quoted part of an email to which I'm replying? > > http://www.idallen.com/topposting.html > > > Part of the problem is the way gmail and other clients *hide* the original > text behind three ellipses dots, > so its not immediately obvious how much a thread has grown. > Its good to make a habit of clicking those dots immediately after clicking > . > > cheers -ben
[Pharo-dev] [Pharo 7.0-dev] Build #968: 21990-isProbablyPrime-and-friends-should-not-refer-to-Transcript
There is a new Pharo build available! The status of the build #968 was: FAILURE. The Pull Request #1435 was integrated: "21990-isProbablyPrime-and-friends-should-not-refer-to-Transcript" Pull request url: https://github.com/pharo-project/pharo/pull/1435 Issue Url: https://pharo.fogbugz.com/f/cases/21990 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/968/
[Pharo-dev] [Pharo 7.0-dev] Build #967: 22001 Cleanup System-Object Events package
There is a new Pharo build available! The status of the build #967 was: FAILURE. The Pull Request #1444 was integrated: "22001 Cleanup System-Object Events package" Pull request url: https://github.com/pharo-project/pharo/pull/1444 Issue Url: https://pharo.fogbugz.com/f/cases/22001 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/967/
Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing
> > Shortcomings: > -> extensions are not treated, only the main package > -> Not used much, for sure needs testing to see if this really works. —> there might be other places in addition global #compilerClass: where we need to point to the overlay version For the complete “compile a method” it works, but I think there are other cases where it is not enough. > -> Can we get rid of the #CompilerOverlay global? > I think it can be a class variable of OpalCompiler, this way we can turn the whole thing into a Setting (if it turns out to be usable) Marcus
[Pharo-dev] [Pharo 7.0-dev] Build #966: 22002 Cleanup System-Platforms
There is a new Pharo build available! The status of the build #966 was: SUCCESS. The Pull Request #1445 was integrated: "22002 Cleanup System-Platforms" Pull request url: https://github.com/pharo-project/pharo/pull/1445 Issue Url: https://pharo.fogbugz.com/f/cases/22002 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/966/
Re: [Pharo-dev] [Compiler] #bindings: improvement: Global shadowing
> On 18 May 2018, at 10:39, Marcus Denker wrote:
>
> Hi,
>
> the #binding: API until now did not allow to shadow globals. But there is
> actually no reason to forbid that
> (and it can actually be interesting, e.g. to compile code where one class ref
> is switched to another).
>
> The Pull Request does:
>
> - add comment to OCExtraBindingScope
> - categorize tests
> - change #lookupVar: to allow shadowing of Globals.
> - change test to reflect the new behaviour
>
> This means you can do:
>
> result := Smalltalk compiler
> bindings: {(#Object -> Point)} asDictionary;
> evaluate: 'Object new’.
So what can we do with this? If you develop a compiler, it is always very
annoying that any change that you do actually breaks the compiler if you do it
wrong. Larger changes over multiple methods get quite hard to do.
One thing that we will soon have is the “accept for test” feature that I posted
recently.
Another idea is to use the #bindings: feature of the compiler.
I did small experiment, I added this method to the OpalCompiler class on the
class side:
prepareForDevelopment
"this method sets up an overlay in the global var CompilerOverlay"
[Pharo-dev] [Pharo 7.0-dev] Build #965: 22003-OSWindowDriver-shutdown-throws-DNU
There is a new Pharo build available! The status of the build #965 was: SUCCESS. The Pull Request #1446 was integrated: "22003-OSWindowDriver-shutdown-throws-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/1446 Issue Url: https://pharo.fogbugz.com/f/cases/22003 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/965/
[Pharo-dev] [Pharo 7.0-dev] Build #964: 21996-SDL2-clipboard-primitives-are-wrong
There is a new Pharo build available! The status of the build #964 was: SUCCESS. The Pull Request #1440 was integrated: "21996-SDL2-clipboard-primitives-are-wrong" Pull request url: https://github.com/pharo-project/pharo/pull/1440 Issue Url: https://pharo.fogbugz.com/f/cases/21996 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/964/
