- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec #subMenu is broken

by Benjamin

On 05 Mar 2014, at 08:41, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > where? because I wanted to integrate it and I could not find the slice in the inbox. PharoInbox, slice number 13040 Itâs weird you do no find it :S > > did you fix also the menu title rendering (when putting a title it was not used and rendered) > because I was hacking a solution in the âMenuAdapterâ but I do not remember > where I put the code. I do not remember such an issue :( > I will dig the code and publish it, if it is not fixed. Cool, tell me :) Ben

March 5, 2014

Re: [Pharo-dev] [ANN] Creativity - a Smalltalk usability experiment on browsing code and productivity

by Goubier Thierry

Le 05/03/2014 08:48, Pharo4Stef a Ã©crit : > > Iâm thinking that may be using as scope the result of a query could be nice. > Imagine that we have a little button close to the search bar that says scoped and spawn a new scoped browser > and that we could remove/add extra package in the scope This is what AltBrowser does at the moment. If you use it, do a search in the Finder plugin, it will open a browser scoped on the query result. And, in a scoped browser, finder searches are scoped, of course :) As well for : implementors, senders, class hierarchy, smart suggestions searches, etc... This is why I'm asking those questions: I'm getting used to it, but, still, I'd like to find just about the right balance between scoped searches and global searches. > it can be really handy. This was the idea of the groups originally. It is handy :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 5, 2014

Re: [Pharo-dev] [ANN] Creativity - a Smalltalk usability experiment on browsing code and productivity

by Pharo4Stef

On 04 Mar 2014, at 14:14, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 04/03/2014 14:02, Alexandre Bergel a Ã©crit : >> I usually never switch between Log and other packages / classes, except if those packages are related (i.e., from the same application). When I need to see other classes that have nothing to do with my application, I usually open a new browser. > > Ok, then another question: > - When working on one application, would you prefer all searches and refactorings be: > a) scoped to your application > b) system wide > c) both (:)) it depends :) so probably c :) > I implemented a) for classes and packages, but I'm wondering if this is the right balance: a) is very convenient, but at times I want b), which means c). me too so I think that the solution is to have a really fast way to create a scope and that it is obvious and apparent. > I also have a problem of a good GUI representation of the fact the browser is scoped, and which scope exactly it is. Why? > > Because, when scoping is easy, then you can drill down through code by scoping over scoping: first a package / then a class / then a group of methods... And then explaining what the scope is at that point is... not easy. oh I get it perfectly :) > > Thierry > >> Alexandre >> >> >> On Mar 4, 2014, at 9:29 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>>> Now in Nautilus I often type Log to only the Log package so what display >>>> your search bar >>> >>> Hi Stef, >>> >>> when you do that, do you usually: >>> - work only with Log in that Nautilus instance (i.e. your package search entry is staying with Log all the time) >>> - Or switch between Log and other packages / classes (i.e. you write Log multiple times in the search bar) >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 5, 2014

Re: [Pharo-dev] publishing ConfigurationOf...

by Pharo4Stef

I added you to the repo. can you check? Stef On 04 Mar 2014, at 20:30, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Perhaps my user needs to receive some blessing? :D > > Iâve pushed it here as workaround: > http://smalltalkhub.com/#!/~sebastianconcept/OmniBase > > Iâm about to update it thou > > > > > > On Mar 4, 2014, at 4:22 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Thatâs weirdâ¦ In what repo is it? If itâs read accessible I can copy it to Meta for you. >> >> Cheers, >> Max >> >> >> On 04.03.2014, at 19:00, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> hi guys >>> >>> I could not save a ConfigurationOfOmniBase into MetaRepoForPharo30 >>> >>> where should I save it? >>> >>> sebastian >>> >>> o/ >>> >>> >>> >>> >>> >> >

March 5, 2014

Re: [Pharo-dev] [ANN] Creativity - a Smalltalk usability experiment on browsing code and productivity

by Pharo4Stef

On 04 Mar 2014, at 13:29, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 04/03/2014 13:18, Pharo4Stef a Ã©crit : >> nice :) >> Now in Nautilus I often type Log to only the Log package so what display >> your search bar > > Hi Stef, > > when you do that, do you usually: > - work only with Log in that Nautilus instance (i.e. your package search entry is staying with Log all the time) > - Or switch between Log and other packages / classes (i.e. you write Log multiple times in the search bar) I was for example working with SimpleLog and SystemLogger so I type Log and I only see all the log packages and this is quite cool Now it happens that I look for something else. And I open another browser in such case. > Why am I asking that? > > One of my experiments at the moment is systematic scoped browsing, and so I tried: double click on a package -> new browser instance scoped on that package. > > But I'm not using that feature that much. I'd like to ask others what would they do with such a feature. Iâm thinking that may be using as scope the result of a query could be nice. Imagine that we have a little button close to the search bar that says scoped and spawn a new scoped browser and that we could remove/add extra package in the scope it can be really handy. This was the idea of the groups originally. Stef > > Thierry > >> Stef >> On 04 Mar 2014, at 01:15, Sebastian Sastre <sebastian(a)flowingconcept.com >> <mailto:sebastian@flowingconcept.com>> wrote: >> >>> Hi Smalltalker! >>> >>> After a talk with Thierry I was encouraged to publish this weekendâs >>> experiment, so there it is: >>> https://github.com/sebastianconcept/Creativity >>> >>> Creativity is the prototype of a Smalltalk browser biased on: >>> >>> * productivity and >>> * the development experience and >>> * the creative flow >>> <http://en.wikipedia.org/wiki/Flow_(psychology)> of the software >>> developer >>> >>> >>> Iâm releasing it in the open so the idea can spread its own wings >>> >>> I wish I could dedicate more to this because it provides the feeling >>> and the UX of the tool we would use to code every day regardless of >>> the Smalltalk dialect of your choice. >>> >>> For the tests Iâve done, the designâs results are promising, needs >>> more work thou >>> >>> It would be great to have your feedback/input >>> >>> sebastian <https://about.me/sebastianconcept> >>> >>> o/ >>> >>> >>> >>> >>> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

March 5, 2014

Re: [Pharo-dev] Spec #subMenu is broken

by Pharo4Stef

Hi ben where? because I wanted to integrate it and I could not find the slice in the inbox. did you fix also the menu title rendering (when putting a title it was not used and rendered) because I was hacking a solution in the âMenuAdapterâ but I do not remember where I put the code. I will dig the code and publish it, if it is not fixed. Stef > I proposed a new update for Spec with this fix in it :) > > Ben > > On 04 Mar 2014, at 18:38, roberto.minelli(a)usi.ch wrote: > >> Cool Ben! >> >> P.s. Should I wait until the fix will be integrated in Pharo? >> >> Cheers, >> R >> >> On Mar 4, 2014, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> Thanks for the report :) >>> >>> Fixed in commit df6e44a :) >>> >>> Ben >>> >>> On 04 Mar 2014, at 16:57, roberto.minelli(a)usi.ch wrote: >>> >>>> Hi, >>>> >>>> It seems that Specâs #subMenu functionality is broken. >>>> >>>> I opened an entry here: https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken >>>> >>>> Cheers, >>>> RM >>> >> >> >

March 5, 2014

files.pharo.org/platform - why empty

by Torsten Bergmann

The folder http://files.pharo.org/platform/ is empty for whatever reason. If this is by intention I dont think this is a good idea - as the URL is referred to in many posts, wesbites and blog entries to easy download a one click for platforms. Thx T.

March 5, 2014

Re: [Pharo-dev] Spec #subMenu is broken

by Benjamin

I proposed a new update for Spec with this fix in it :) Ben On 04 Mar 2014, at 18:38, roberto.minelli(a)usi.ch wrote: > Cool Ben! > > P.s. Should I wait until the fix will be integrated in Pharo? > > Cheers, > R > > On Mar 4, 2014, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> Thanks for the report :) >> >> Fixed in commit df6e44a :) >> >> Ben >> >> On 04 Mar 2014, at 16:57, roberto.minelli(a)usi.ch wrote: >> >>> Hi, >>> >>> It seems that Specâs #subMenu functionality is broken. >>> >>> I opened an entry here: https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken >>> >>> Cheers, >>> RM >> > >

March 5, 2014

Re: [Pharo-dev] strange time / delay problems on pharo-contribution-linux64-4.ci.inria.fr

by Eliot Miranda

On Tue, Mar 4, 2014 at 2:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Mar 2014, at 22:34, Max Leske <maxleske(a)gmail.com> wrote: > > > Phew! I already thought I was crazy :) > > > > In that case here are two more tidbits: > > - I tried to log 'DateAndTime now' in a different test simultaneously. > The timestamp produced there was different, suggesting that the clock does > move from time to time. > > - FileSystemTests>>testEntryAt exhibits that problem. But the tests run > on the main Pharo machines are fine (that's why I thought it might be the > system clock). > > - the same test only fails in the Pharo3 image, not in Pharo2, but both > use the stable PharoVM for building. > > There is a big difference in how DateAndTime class>>#now works in 2.0 vs > 3.0. The former uses #millisecondClockValue while the latter uses > #microsecondClockValue. Furthermore 2.0 does all kind of crazy stuff with a > loop and Delays to try to improve the accuracy, we threw all that out. > > Yeah, I guess the clock is just being updated slowly, maybe under heavy > load. The question is where that happens. I think in the virtualised OS. > That makes sense. In the VM the microsecond clock is updated on every heartbeat and the heartbeat should be running at about 500Hz. Can anyone with hardware confirm that in 3.0 the time on linux does indeed increase at about 500Hz? Note that even in 2.0 the time is being derived from the same basis. In Cog, the effective time basis is the 64-bit microsecond clock maintained by the heartbeat and even the secondClock and millisecondClock are derived from this. So its still confusing why there should be such a difference between 2.0 and 3.0. > > > Hope that helps. > > > > On 04.03.2014, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> Hey Max, > >> > >> Great catch, I saw some weird stuff too, and we had this conversation : > >> > >>> may be just = > >>> and time does not pass fast enough/ > >>> > >>>> On 03 Mar 2014, at 22:22, no-reply(a)ci.inria.fr wrote: > >>>> > >>>>> > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/labe… > >>>>> > >>>>> 1 regressions found. > >>>>> KernelTests.Chronology.DateAndTimeTest.testMonotonicity > >>>> > >>>> How the hell can this fail ? > >>>> The clock moving backwards ?? > >>>> > >>>> testMonotonicity > >>>> > >>>> | t1 t2 t3 t4 | > >>>> t1 := DateAndTime now. > >>>> t2 := DateAndTime now. > >>>> (Delay forMilliseconds: 1000) wait. > >>>> t3 := DateAndTime now. > >>>> t4 := DateAndTime now. > >>>> > >>>> self > >>>> assert: (t1 <= t2); > >>>> assert: (t2 < t3); > >>>> assert: (t3 <= t4). > >> > >> > >> So you proofed Stef's assumption of time standing still ;-) > >> > >> But there were earlier problems as well. > >> > >> Thx ! > >> > >> On 04 Mar 2014, at 21:43, Max Leske <maxleske(a)gmail.com> wrote: > >> > >>> There seems to be a problem on > pharo-contribution-linux64-4.ci.inria.fr AFAICT. I can reproduce the > following to phenomena: > >>> > >>> 1. '(Delay forSeconds: 10) wait' does not wait. > >>> 2. 'DateAndTime now' does not change for long intervals. > >>> > >>> For instance, the following code: > >>> > >>> (FileSystem disk workingDirectory / 'foo.log') writeStreamDo: [ > :stream | > >>> stream nextPutAll: DateAndTime now asString;crlf. > >>> stream nextPutAll: ([(Delay forSeconds: 10) wait] timeToRun / > 1000) asString; crlf. > >>> stream nextPutAll: DateAndTime now asString ]. > >>> > >>> produces this output: > >>> > >>> 2014-03-04T21:32:21.396669+01:00 > >>> 0:00:00:00 > >>> 2014-03-04T21:32:21.396669+01:00 > >>> > >>> Too me (and my untrained eye) this looks like a system clock problem. > Could somebode take a look at the server in question? > >>> > >>> Cheers, > >>> Max > >> > >> > > > > > > > -- best, Eliot

March 5, 2014

Re: [Pharo-dev] strange time / delay problems on pharo-contribution-linux64-4.ci.inria.fr

by Sven Van Caekenberghe

On 04 Mar 2014, at 22:34, Max Leske <maxleske(a)gmail.com> wrote: > Phew! I already thought I was crazy :) > > In that case here are two more tidbits: > - I tried to log âDateAndTime nowâ in a different test simultaneously. The timestamp produced there was different, suggesting that the clock does move from time to time. > - FileSystemTests>>testEntryAt exhibits that problem. But the tests run on the main Pharo machines are fine (thatâs why I thought it might be the system clock). > - the same test only fails in the Pharo3 image, not in Pharo2, but both use the stable PharoVM for building. There is a big difference in how DateAndTime class>>#now works in 2.0 vs 3.0. The former uses #millisecondClockValue while the latter uses #microsecondClockValue. Furthermore 2.0 does all kind of crazy stuff with a loop and Delays to try to improve the accuracy, we threw all that out. Yeah, I guess the clock is just being updated slowly, maybe under heavy load. The question is where that happens. I think in the virtualised OS. > Hope that helps. > > On 04.03.2014, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hey Max, >> >> Great catch, I saw some weird stuff too, and we had this conversation : >> >>> may be just = >>> and time does not pass fast enough/ >>> >>>> On 03 Mar 2014, at 22:22, no-reply(a)ci.inria.fr wrote: >>>> >>>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/labe… >>>>> >>>>> 1 regressions found. >>>>> KernelTests.Chronology.DateAndTimeTest.testMonotonicity >>>> >>>> How the hell can this fail ? >>>> The clock moving backwards ?? >>>> >>>> testMonotonicity >>>> >>>> | t1 t2 t3 t4 | >>>> t1 := DateAndTime now. >>>> t2 := DateAndTime now. >>>> (Delay forMilliseconds: 1000) wait. >>>> t3 := DateAndTime now. >>>> t4 := DateAndTime now. >>>> >>>> self >>>> assert: (t1 <= t2); >>>> assert: (t2 < t3); >>>> assert: (t3 <= t4). >> >> >> So you proofed Stef's assumption of time standing still ;-) >> >> But there were earlier problems as well. >> >> Thx ! >> >> On 04 Mar 2014, at 21:43, Max Leske <maxleske(a)gmail.com> wrote: >> >>> There seems to be a problem on pharo-contribution-linux64-4.ci.inria.fr AFAICT. I can reproduce the following to phenomena: >>> >>> 1. '(Delay forSeconds: 10) waitâ does not wait. >>> 2. âDateAndTime nowâ does not change for long intervals. >>> >>> For instance, the following code: >>> >>> (FileSystem disk workingDirectory / 'foo.log') writeStreamDo: [ :stream | >>> stream nextPutAll: DateAndTime now asString;crlf. >>> stream nextPutAll: ([(Delay forSeconds: 10) wait] timeToRun / 1000) asString; crlf. >>> stream nextPutAll: DateAndTime now asString ]. >>> >>> produces this output: >>> >>> 2014-03-04T21:32:21.396669+01:00 >>> 0:00:00:00 >>> 2014-03-04T21:32:21.396669+01:00 >>> >>> Too me (and my untrained eye) this looks like a system clock problem. Could somebode take a look at the server in question? >>> >>> Cheers, >>> Max >> >> > >

March 4, 2014