May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reviewing Association and LookupKey

by stepharo

Le 12/5/15 20:31, Torsten Bergmann a Ã©crit : > Three questions that might end up in issues: > > > 1. Is there a reason why Association(class)>>#key:value: looks like > > key: newKey value: newValue > ... > ^(super key: newKey) value: newValue > > instead of > > key: newKey value: newValue > ... > ^(self key: newKey) value: newValue > > in case #key: will be redefined in Association class > > 2. What is the reason for LookupKey>>#canAssign. Method stamp says ajh from 2002. > This message is not sent and I guess we can remove/deprecate it. Could you open a bug entry for point 2 and 3 so that we do not forget to clean. These methods are left over an experience to have read-only bindings. > > 3. Similar question for LookupKey>>#isSpecialReadBinding from ar in 2003 > This message is not sent and I guess we can remove/deprecate it. > > Comments welcomed! > > Thanks > T. > >

May 13, 2015

Re: [Pharo-dev] Pharo Screencast By a Ruby Guy

by stepharo

Not a perfect demo (he could have run the tests from within the browser), but nice to see how (some) outsiders think about Pharo > Which brings us to the conclusion, that we have to improve improve dx for TDD :) > > Uko + 1

May 13, 2015

empty package "'a MCWorkingCopy(ConfigurationOfRubric)'"

by Nicolai Hess

Pharo 50046 contains a strange package: 'a MCWorkingCopy(ConfigurationOfRubric)'

May 13, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 13/05/2015 18:32, Sven Van Caekenberghe a Ã©crit : > Hmm, why ? I think it is more a question of (personal) style. Direct instance variable access without an accessor is a very good way to keep something private, it is faster as well. With the current tools, finding usages is very easy in both cases. > > IMO, an object should only implement the strict minimum of (public) messages, so not necessarily getters and setters for everything. Nothing is absolute though. I prefer accessors because I can put breakpoints an control access too (a matter of taste or style as you said) In fact I was surprised to see that there was no accessors at all here, but that makes sense here, as it makes sense too not to expose everything. Thank you for your answer -- Regards, Alain

May 13, 2015

Settings: Standardize Protocols

by Sean P. DeNigris

What makes the most sense here? Some classes have the pragma methods in 'settings' and the accessors in 'accessing', others (e.g. Delay) have all of the above in 'settings'. Others have methods miscategorized (e.g. NECPreferences has half its defaults in 'defaults' and half in 'settings'. I see the logic in putting the accessors in settings to more clearly identify them? Maybe 'accessing settings' or 'settings-accessing'? Anyway once we decide it would be nice to clean this up... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Settings-Standardize-Protocols-tp4826259.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 13, 2015

Re: [Pharo-dev] Issue 15523: Code Cruft Rule Only Matches One-Liners

by Sean P. DeNigris

Sean P. DeNigris wrote > https://pharo.fogbugz.com/default.asp?15523 Two human reviews and validated by the monkey. Ready to include? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-15523-Code-Cruft-Rule-Only-Matches-One-Liners-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 13, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 13/05/2015 18:45, J. Vuletich (mail lists) a Ã©crit : > > Alternatively, try getting the image file from > https://dl.dropboxusercontent.com/u/13285702/Cuis4.2-2322.image > Yes, with the image in the zip file I was able to run cuis. I run squeak from time to time to look at some code when I have no other choice -once or twice a year- may be Cuis will make me change my mind ? let's try :) thanks Juan -- Regards, Alain

May 13, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sun, May 10, 2015 at 12:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > On Sat, May 9, 2015 at 8:18 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> >>> >>> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> From my limited experience bug hunting, calling #changed: from a thread >>>> other than the UI thread is a source of evil. >>>> >>> >> 3. Thinking further on this, I suppose the main issue from the original >> example is that its running in the UI thread. In this case I guess calling >> #changed: and #refreshWorld is okay (there have been no problems in >> Squeak). So in ThreadSafe>>endEntry we could check to see if we are in the >> UI thread and only in that case issue #changed:. So only the "user >> interactive" workspace will see the "slow" behaviour (which any is too fast >> for a human to notice), and forked processes will not be slowed. >> > > So what about doing something such as remembering the last time the > transcript updated the UI, and a) not allowing #changed to update the UI if > it has been less than x milliseconds since it was last updated, and b) > scheduling a deferred ui update when #changed is filtered-out in this way > and c) cancelling the deferred ui update if another transcript update > occurs before the deferred update is processed. > > Hi Eliot, Just to let you know I've been contemplating this. It sounds a good idea, but I've been too tired the past few nights to dig into it further. Also l like Cuis' Transcript for being extremely self contained and so I guess harder to break accidentally, but it was missing editing and highlighting. So I was waiting to see if there were more opinions arising from that. cheers -ben > > >> cheers -ben >> >> >>> There are too many assumptions throughout the system that the UI is >>>> single threaded. Can anyone advise me that is not a proper belief? >>>> >>>> Then that implies that a Transcript implementation where #nextPut: >>>> direct calls #changed: >>>> is not appropriate for use with multi-threaded applications. In Pharo, >>>> #changed: is only called from #stepGlobal, which is called from >>>> doOneCycle:. (This came about as a last minute bug fix before Pharo 3 >>>> release and maybe could use some cleanup. >>>> >>>> Separating the UI from Transcript into its own viewer might be a good >>>> idea, but actually it would not solve Stef's case since his code would >>>> still be running in the UI thread -- unless the viewer ran in another >>>> thread, which would have its own complexities. >>>> >>>> I think the point about efficiency is significant. The following >>>> example... >>>> Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: >>>> 'x' ] ] >>>> on Squeak 4.5 --> 12749ms >>>> on Pharo 50029 --> 2ms >>>> >>>> This better performance helped me a lot trying to understand the high >>>> priority timerEventLoop being able to indiscriminately scatter Transcript >>>> tracing through that code. I believe its also probably beneficial for >>>> working with externally triggered semaphores and timing sensitive race >>>> conditions. >>>> >>>> So we have two mutually exclusive cases: >>>> * better interactivity, poorer system performance >>>> * faster system performance, worse interactivity >>>> >>>> Which of these is broken depends on your viewpoint. >>>> >>> >>> Something that runs fast but is incorrect is still incorrect. The fact >>> that the transcript doesn't output until a world step is possible is a >>> bug. It forces programs that use the transcript to be rewritten in order >>> to see transcript output. >>> >>> >>>> For which I see two solutions: >>>> 1. Next to the doIt menu item add a forkIt menu item -- so its >>>> optional, but not the default >>>> 2. Have a Preference that enables Transcript>>nextPut: to call >>>> #changed: >>>> >>> >>> Is this the entire solution space? >>> >> >> See (3.) above. >> 4. Run Workspaces in their own thread per VW (but that already got >> knocked down) >> >> >>> Are there not ways of engineering the transcript to update at, say, >>> 10Hz? >>> >> Can the transcript not be made to render changes much faster? >>> >> >> Still thinking about these. >> >> >>> I see terminals with performance thousands of times faster than the >>> transcript that still display output immediately. I don't understand why >>> the Squeak transcript is so slow. That's a bug also. >>> >> >> >>> >>> >>>> >>>> The first I think could be useful anyway, not having to do a cumbersome >>>> coded fork. This would also provide a measure of documentation and >>>> discoverability. There might be a submenu for forking at the different >>>> user priorities. >>>> >>>> For the second, it would be pragmatic to do what we can to facilitate >>>> VM development on Pharo. The preference can describe how it might adverse >>>> affect multithreaded applications. >>>> >>>> cheers -ben >>>> >>> >> >> >> > > > -- > best, > Eliot >

May 13, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

We use traits all over the place, for example, TSortable or TAssertable, as well as many others... > On 13 May 2015, at 18:38, Ben Coman <btc(a)openinworld.com> wrote: > > Weren't Traits one of things reported to make VM development harder, or was there a fix coming for that? > cheers -ben > > On Wed, May 13, 2015 at 11:57 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 13/05/2015 16:12, Sven Van Caekenberghe a Ã©crit : > I tried to abstract the Transcript API from the Pharo perspective in > > https://pharo.fogbugz.com/f/cases/15528/Add-TTranscript-and-DailyNonInterac… > > If the Cuis Transcript implementation conformed to this, it could become just a plugin replacement/alternative, next to others already present. > > A Trait for the Transcript is very good idea. > > Just a question I had browsing the ThreadsafeTranscript implemntation, I wonder why there is no accessor to instance variables (stream accessSemaphore etc...). > I thought the smalltalk way was to always prefer accessors, under the private protocol if private, but discourage direct access ? > > > -- > Regards, > > Alain > > >

May 13, 2015

Re: [Pharo-dev] Transcript needs your love

by J. Vuletich (mail lists)

Quoting Alain Rastoul <alf.mmm.cat(a)gmail.com>: > Le 13/05/2015 16:08, J. Vuletich (mail lists) a Ã©crit : >> Today I did a new commit to the Cuis repo. The Cuis image is now in Cog >> format (6505) instead of Closures format (6504). I hope this allows you >> to run Cuis in your system. >> >> I also addressed some of the issues you raised. I optimized the refresh, >> and avoided the "bolder text" effect. >> >> Now, >> Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' >> ] ]. >> takes 2 ms, even while updating the Display. (Hundreds of times faster). > > Thanks Juan > > It's nice to see how reactive you are :) Thanks. Also thanks for trying and reporting your experience. This lets me solve any issues! > I downloaded the Cuis-4.2-2322 image but still have the same error > message : This interpreter (vers. 6505) cannot read image file > (vers. 1007290890). > The cuis image number looks strange. > Is this image supposed to be in 6505 format ? Mhhh. Maybe it is a problem with downloading the file. I guess you cloned https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev , right? Maybe Git thinks it needs to mess with the files? Please try getting the zip file https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/archive/master.zip and unzipping it. Alternatively, try getting the image file from https://dl.dropboxusercontent.com/u/13285702/Cuis4.2-2322.image > What version of squeak vm do you use ? > I'm using a Squeak 4.5 vm who runs perfectly on this system (linux > ubuntu 14.04). > I tried with other older vms but always got this error (only the > 6505 number changed IIRC) > > > -- > Regards, > > Alain Cuis4.2-2322.image was saved with a relatively recent Windows Cog VM from Eliot's site. All previous Cuis images were saved with Squeak4.10.2-2612.exe from squeakvm.org. Always on Windows 7. I run them under Debian Jessie with Eliot's coglinux all the time without problems. The number you get 1007290890 is 16r3C0A0A0A... Those bytes are not there in the header in the image file I have. The first bytes of the image file should be 69 19 00 00 (in hex). This is 6505 in decimal. That's why I suspect of a problem with the image file itself, and maybe a problem with git. Those 0A bytes are LF characters... Maybe git is trying to be "smart" and converting or adding LF characters to what it thinks is text? Regards, Juan Vuletich

May 13, 2015