September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Brad Selfridge

"RIGHT" (window color) -- Brad Selfridge 913-269-2385

Sept. 13, 2017

[Calypso] Toolbar and Statusbar Look - voting time

by Torsten Bergmann

Hi all, as you know Denis Kudriashov does a fantastic job in implementing the new Calypso system browser. The plan is that at some point in time will be a replacement for Nautilus in the standard image. Even if not yet integrated one can already use it (either by loading from catalog or github [1]) For me the more I use it (and get used to it) the more I like Calypso and I guess others enjoy it too already. But unfortunately there is a single but very prominently visible UI thing that I dislike on the current look: For the "Pharo3Theme" (light theme) the current implementation of Calypso has a white toolbar in the middle and a white status bar at the bottom. Technically Dennis sets the colors of these morphs to transparent to have this effect (see LEFT example of the attached screenshot) To me this lookes strange and unusual because - usually (on Windows, GTK, Java Swing, Linux window managers) such areas like a status bar follow the window color and are displayed in gray when that is the default window theme color (see [2], [3], [4]) - these white bars would better fit for the "Glamorous Whitespace" theme (as this theme is already more white areas) Also the current white bars do not make a pleasant contrast to the other panes of Calypso: - there is not really a visual distinction to the package/class/protocol-tag/method panes and filters for the middle part (toolbar) - there is not really a visual distinction from the code pane for the bottom part (statusbar) - the divider line in the code pane just stops in a white area without borders To me this looks rather ugly and I would like Pharo to look more professional and clean ;) So I proposed a simple PR [5] today to change this and technically using the window color of the theme - the result can be seen on the right side of the attached screenshot and discussed with Denis on Discord. Denis on the other hand still likes the white approach on the left more while I prefer the right one. He wrote that he wants other people comment on this issue first to which I agree and therefore I write this mail to discuss it here on the dev-list and find out about what the majority in the community prefers. So it would be good if others could - comment about their personal preference - or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) in reply to this mail - or make another proposal (which is only accepted with screenshot and PR ;) Also please do not mix other UI discussions into this thread. Thanks in advance! Bye T. [1] https://github.com/dionisiydk/Calypso [2] http://cdn.osxdaily.com/wp-content/uploads/2011/08/show-status-bar-and-disk… [3] http://i.stack.imgur.com/pgt5n.png [4] http://python.zirael.org/gtk-statusbar1-1.png [5] https://github.com/dionisiydk/Calypso/pull/91

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Denis Kudriashov

So after discussion the solution would be: - ClassBinding for instance side method literals and globals dictionary (instead of GlobalVariable) - MetaclassBinding for the last literal of class side methods. It will include proper comment about where it is used and how, with description of current trick 2017-09-13 16:45 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 12 Sep 2017, at 17:33, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > I don't know... I found the idea of having a Metaclass binding strange... > > > > I mean, > > - metaclasses are not stored in any name dictionary such as Smalltalk > > - nobody references them directly in source code but by their direct > classes > > > > The metaclass binding is there just for one thing really: methods need > an association to know their class in case they have to do a super send. > And transitively this is a compiler problem also. But anybody else accesses > metaclasses' bindings. > > â > yes, we need it just for the last literal. > > We added the âif there is a method, get the binding from thereâ we adde as > else > we would compiler every class side method with a new Association instance, > which > wastes lots of space. > > Marcus >

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Marcus Denker

> On 12 Sep 2017, at 17:33, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I don't know... I found the idea of having a Metaclass binding strange... > > I mean, > - metaclasses are not stored in any name dictionary such as Smalltalk > - nobody references them directly in source code but by their direct classes > > The metaclass binding is there just for one thing really: methods need an association to know their class in case they have to do a super send. And transitively this is a compiler problem also. But anybody else accesses metaclasses' bindings. > â yes, we need it just for the last literal. We added the âif there is a method, get the binding from thereâ we adde as else we would compiler every class side method with a new Association instance, which wastes lots of space. Marcus

Sept. 13, 2017

Re: [Pharo-dev] About Git support for windows

by Ben Coman

On Tue, Sep 12, 2017 at 11:23 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Just a random idea, how about each time writing timestamps to >> a different file name "timestamps.$HashOfClassSourceFile" >> Then git would never complain of a conflict(??). >> > > If I understand your proposal correctly, that would imo result in the > following: > > accumulating endless list of timestamps.XXX files (there are no conflicts > and thus no mechanism to get rid of them) > The Smalltalk code writing the class & timestamp files would take care of removing old timestamp files, so linearly git would see one file added and one removed, or after a merge, more than one timestamp file removed.. > still having conflict, because the #sourceHash is different (any two > independent changes to a line will trigger conflict) > #sourceHash is only written to the timestamp file, so such a line is only touched once when the timestamp file is created. > plus added complexity and a lot more reading/processing CPU/disk required > yeah... :) cheers -ben

Sept. 13, 2017

Re: [Pharo-dev] Build #111

by Esteban Lorenzano

hi, for now, everything, at least 0.5.* series (but I want to port 0.6 too because of tonel and windows users) Esteban > On 13 Sep 2017, at 14:07, stephan <stephan(a)stack.nl> wrote: > > What Iceberg changes will get ported to Pharo 6? > > Stephan > >

Sept. 13, 2017

Re: [Pharo-dev] Build #111

by stephan

What Iceberg changes will get ported to Pharo 6? Stephan

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Denis Kudriashov

Yes. In fact I just want avoid usage of general Association in that places. So the question do we need two classes for instance and class side bindings? Or single ClassBinding is enough? In that case class side binding will have nil as a key (which would be the same for possible ClassSideBinding) 2017-09-13 9:43 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > At the minimum having classBinding instead of GlobalBinding would be > already a good step. > Then since the metaclass and the class are a real couple could we not > have an object shared by both (but it would cost one indirection). > > On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > I don't know... I found the idea of having a Metaclass binding strange... > > > > I mean, > > - metaclasses are not stored in any name dictionary such as Smalltalk > > - nobody references them directly in source code but by their direct > classes > > > > The metaclass binding is there just for one thing really: methods need an > > association to know their class in case they have to do a super send. And > > transitively this is a compiler problem also. But anybody else accesses > > metaclasses' bindings. > >

Sept. 13, 2017

Re: [Pharo-dev] argh, tests are failing!

by Stephane Ducasse

Nice It should be added to the doc :) On Tue, Sep 12, 2017 at 9:51 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Two other things: > > - if you choose to change the priority of the delivery process to the same > priority as the running test process (i.e., 40) you would still need to > tell the scheduler to give some chance to run to the other one. You can do > that by yielding > > Processor yield > > - About timeouts: Denis implemented not so long ago an automatic timeout > for tests. So if tests take more than a specified amount they are timed out > and failed by default. Check > > TestCase >> defaultTimeLimit > ^self class defaultTimeLimit > > TestCase class >> defaultTimeLimit > ^DefaultTimeLimit ifNil: [DefaultTimeLimit := 1 minutes] > > So you may want to use that mechanism to timeout instead of hardcoding the > timeouts of semaphores in each of the tests. > > Moreover, the mechanism created by Denis will automatically kill any > processes created during a test run, to ensure you leave the system somehow > "clean". So you may have that into account also. > > On Tue, Sep 12, 2017 at 9:46 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> But the thing is that those processes you are creating for delivery are >> running in priority 30. This means that it may happen that they may not run >> any time soon (even those 200ms) if there are processes scheduled with >> higher priorities. >> >> So, the thing is that test is not a unit test at all. It depends a lot on >> the running environment. Solutions for that: >> - you change the priority of the delivery process for test purposes >> - Or, for testing purposes you don't create a new process, you just >> execute synchronously >> >> If you want really to test the fact that you are creating and running a >> separate process, then you should also try to let explicit the processes >> you created run. This means, if the active process that is running the >> tests (usually priority 40) does not suspend itself, no processes of >> priority 30 will be able to run. Ways to suspend the active process and let >> lower priority ones run are: >> - calling suspend (Processor activeProcess suspend) but this is >> dangerous because somebody should resume it afterwards from a separate >> process >> - using a delay >> - some I/O like sockets or async files >> >> On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> >> wrote: >> >>> Hi Guillermo, >>> >>> I have not found better solution. Waiting without a timeout threshold is >>> not nice and makes it difficult to run all tests. >>> If you have better idea how to sync and test two processes, I will >>> appreciate it. >>> Otherwise I will use a higher timeout. >>> >>> Cheers, >>> Juraj >>> >>> El 11-09-2017, a las 06:55, Guillermo Polito <guillermopolito(a)gmail.com> >>> escribiÃ³: >>> >>> Hi Juraj, >>> >>> think that it may really depend on the machine and the state of the >>> system. Slower slave machines could not really work with that timeout... >>> >>> The question is how could we make such test more robust. >>> >>> On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com >>> > wrote: >>> >>>> Hi, >>>> >>>> I have checked the EventRecorderTests and it works on my computer. The >>>> only reason that it might not work on other cases is that there an assert >>>> for 'semaphore waitTimeoutMSecs: 200â. I can put higher timeout if >>>> necessary. The timeout 200 has worked for couple of years, right?. There >>>> might be another issue. >>>> >>>> Cheers, >>>> Juraj >>>> >>>> El 10-09-2017, a las 10:13, Guillermo Polito <guillermopolito(a)gmail.com> >>>> escribiÃ³: >>>> >>>> Hi all, >>>> >>>> Since a couple of builds we have consistently failing the following >>>> tests: >>>> >>>> >>>> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv >>>> eredDataShouldBeResent >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh >>>> ouldUnblockWaitingOne >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> - ReleaseTests.Categorization.ProperMethodCategorizationTest.t >>>> estHashMethodNeedsToBeInComparingProtocol >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> >>>> >>>> >>>> >>>> Green builds are the only hard metric to say if the build is healthy or >>>> not. >>>> >>>> - We should not integrate anything until the build is green again... >>>> >>>> Also, we spent with Pablo a lot of time to have a green build in all >>>> platforms... I'd like to spend my time in other fun stuff than the CI :/ >>>> >>>> -- >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> French National Center for Scientific Research - *http://www.cnrs.fr* >>>> <http://www.cnrs.fr/> >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - *http://www.cnrs.fr* >>> <http://www.cnrs.fr/> >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Stephane Ducasse

At the minimum having classBinding instead of GlobalBinding would be already a good step. Then since the metaclass and the class are a real couple could we not have an object shared by both (but it would cost one indirection). On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I don't know... I found the idea of having a Metaclass binding strange... > > I mean, > - metaclasses are not stored in any name dictionary such as Smalltalk > - nobody references them directly in source code but by their direct classes > > The metaclass binding is there just for one thing really: methods need an > association to know their class in case they have to do a super send. And > transitively this is a compiler problem also. But anybody else accesses > metaclasses' bindings.

Sept. 13, 2017