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

Re: [Pharo-dev] Transcript needs your love

by Tudor Girba

What Stef means is that ideally, we should no strive to not have code like: "Transcript show: 'my event'". Instead, we should only log events (ideally, concrete classes like MyEvent) and if we want to see the textual representation of this, we just plug a Transcript interface to the logger. Cheers, Doru On Fri, May 15, 2015 at 4:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> Le 14/5/15 15:12, Alain Rastoul a Ã©crit : >> >> Le 14/05/2015 02:08, J. Vuletich (mail lists) a Ã©crit : >>> >>>> A port of the code to Pharo is required, as Alain and Stef have shown. >>>> Besides, Cuis doesn't include support for Traits. I think your idea is >>>> very good, and I hope some Pharoer (Alain?) does it. >>>> >>> >>> Hi Juan, >>> >>> I tried Cuis, you did a very nice work here. >>> >>> About porting, I did this first raw port to allow other peoples who >>> complains about pharo transcript to have a look at Cuis Trancript more >>> easily. >>> And apart from a small window inset problem and an initial display Form >>> I probably did not get well (and/or a clip missing somewhere?), it does the >>> same thing than in Cuis. >>> >>> May be we should wait a little so that people can say their word about >>> it too and eventually/if they want/can/... investigate those two morphic >>> porting issues. >>> In the meanwhile, a simple "fix" in the Transcript could be done too >>> (see last Ben's post) with an extra system settings. >>> >>> About sluggishnesh and Transcript speedup , the changes you made in >>> Cuis, as seen in git commits, are a bit intrusive (DateAndTime, >>> AbstractFont, Strikefont ?), I don't think I know pharo enough to report >>> them. >>> >>> Also I experienced another issue that exits in Cuis too: >>> >>> The Transcript overwrite other morphs/windows when showing its contents >>> during do-it >>> >>> After end of execution, the world redisplays correctly >>> but not in Pharo >>> >>> (see attached screen shots) >>> >>> >>> >> >> > On Fri, May 15, 2015 at 3:18 AM, stepharo <stepharo(a)free.fr> wrote: > >> Thanks alain for checking. >> I think that we can offer different implementations and let people pick >> the ones they like. >> My goal is to remove direct refer to Transcript from the image so that we >> can plug an implementation and in particular >> the merge of Doru and Norbert/Mine loggers >> >> Stef >> > > I don't quite follow "remove direct refer to Transcript". Isn't > "Transcript" effectively a global variable that can already be plugged with > any implementation? > > As I've been contemplating the Transcript situation, I keep coming back to > the idea that Transcript should be a client of a broader logging framework, > but wondering how much complication that would to tracing VM simulation. > > Further, since the logging framework needs to be threadsafe, rather than > using protected access to a shared datastructure, would it be good to have > a separate "logging" process to consume log entry submissions from multiple > threads, and pass them on to output threads (including Transcript viewer). > Some possible advantages: > * Eliminate complications from priority inversion ( > http://en.wikipedia.org/wiki/Priority_inversion) > * Minimise code that log-entry-producer-thread needs to execute/debug into > -- maybe beneficial for VM simulation? > * Minimises execution time in log-entry-producer-thread. > > cheers -ben > > > > -- www.tudorgirba.com "Every thing has its own flow"

May 15, 2015

Manifest class values - instance or class side

by Kasper Osterbye

It is unclear if literal values in Manifest classes should be on the instance side or on the class side. demarey wrote in the package comments thread on May 6th: "Data is stored in raw strings in methods (instance side) of the Manifest." However, when I look in the actual manifest classes, it seems like the manifest values (from the rule checker) are stored in the class side. In our work on package comments, we want to put the package comments in the manifest classes, but we are uncertain if it should be on the instance or class side. -- View this message in context: http://forum.world.st/Manifest-class-values-instance-or-class-side-tp482644… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 15, 2015

New CogVMs available

by Eliot Miranda

at http://www.mirandabanda.org/files/Cog/VM/VM.r3343. CogVM source as per VMMaker.oscog-eem.1303/r3343 Cogit: Fix the regression with #== in the StackToRegisterMappingCogit; a spilled constant must still be dropped from the stack. (fixes the width:color: MNU) Since the method zone does not scavenge PICs, the MNU method in an MNU PIC entry cannot be young. If it is, void the cache (load 0 instead of the method). -- best, Eliot

May 15, 2015

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

by Ben Coman

On Tue, May 12, 2015 at 5:56 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 12 May 2015, at 11:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 11 May 2015, at 23:49, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> > >> > http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-in-7-minut… > > > > 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 :) > > > There have been several comments to the effect, "Everything there was pretty cool, but when you searched the documentation âby exampleâ, I literally shouted, âNo way!â, alone here in my office. Thatâs such a brilliant idea." Maybe we should transfer the Finder>Examples behaviour to GTSpotter and promote it more. (I've not got Pharo with me to check. Maybe I remember some announcement on this, but its not very visible or discoverable). Its filter might be #howto, similar to #i and #s. cheers -ben

May 15, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

> > > Le 14/5/15 15:12, Alain Rastoul a Ã©crit : > > Le 14/05/2015 02:08, J. Vuletich (mail lists) a Ã©crit : >> >>> A port of the code to Pharo is required, as Alain and Stef have shown. >>> Besides, Cuis doesn't include support for Traits. I think your idea is >>> very good, and I hope some Pharoer (Alain?) does it. >>> >> >> Hi Juan, >> >> I tried Cuis, you did a very nice work here. >> >> About porting, I did this first raw port to allow other peoples who >> complains about pharo transcript to have a look at Cuis Trancript more >> easily. >> And apart from a small window inset problem and an initial display Form I >> probably did not get well (and/or a clip missing somewhere?), it does the >> same thing than in Cuis. >> >> May be we should wait a little so that people can say their word about it >> too and eventually/if they want/can/... investigate those two morphic >> porting issues. >> In the meanwhile, a simple "fix" in the Transcript could be done too >> (see last Ben's post) with an extra system settings. >> >> About sluggishnesh and Transcript speedup , the changes you made in Cuis, >> as seen in git commits, are a bit intrusive (DateAndTime, AbstractFont, >> Strikefont ?), I don't think I know pharo enough to report them. >> >> Also I experienced another issue that exits in Cuis too: >> >> The Transcript overwrite other morphs/windows when showing its contents >> during do-it >> >> After end of execution, the world redisplays correctly >> but not in Pharo >> >> (see attached screen shots) >> >> >> > > On Fri, May 15, 2015 at 3:18 AM, stepharo <stepharo(a)free.fr> wrote: > Thanks alain for checking. > I think that we can offer different implementations and let people pick > the ones they like. > My goal is to remove direct refer to Transcript from the image so that we > can plug an implementation and in particular > the merge of Doru and Norbert/Mine loggers > > Stef > I don't quite follow "remove direct refer to Transcript". Isn't "Transcript" effectively a global variable that can already be plugged with any implementation? As I've been contemplating the Transcript situation, I keep coming back to the idea that Transcript should be a client of a broader logging framework, but wondering how much complication that would to tracing VM simulation. Further, since the logging framework needs to be threadsafe, rather than using protected access to a shared datastructure, would it be good to have a separate "logging" process to consume log entry submissions from multiple threads, and pass them on to output threads (including Transcript viewer). Some possible advantages: * Eliminate complications from priority inversion ( http://en.wikipedia.org/wiki/Priority_inversion) * Minimise code that log-entry-producer-thread needs to execute/debug into -- maybe beneficial for VM simulation? * Minimises execution time in log-entry-producer-thread. cheers -ben

May 15, 2015

Re: [Pharo-dev] [squeak-dev] Cog VM problem?

by Eliot Miranda

Hi Raymond, yes, thanks. We have a regression in the code generator due to recent changes to #== compilation. We're working on it. I hope to have a fix soon. Apologies for the inconvenience. For those of you curious why this only affects the V3 VM, not the Spur VM, the reason is that in Spur the Cogit passes up to 2 argument sends in registers but in V3 it passes only up to 1 arg sends in registers. In (borderWidth = style width and: ["Hah! Try understanding this..." borderColor == style style or: ["#raised/#inset etc" #simple == style style and: [borderColor = style color]]]) ifFalse: [style := borderColor isColor ifTrue: [BorderStyle width: borderWidth color: borderColor] ifFalse: [(BorderStyle perform: borderColor) width: borderWidth "argh."]. self setProperty: #borderStyle toValue: style]. #simple erroneously ends up getting spilled to the stack, so that when the send of width:color: to BorderStyle occurs the code generator emits code to access what it thinks is BorderWidth, but ends up accessing #simple instead. As I say we're working on it and should have a fix soon. On Thu, May 14, 2015 at 8:13 AM, Raymond Asselin <jgr.asselin(a)me.com> wrote: > Cog.app-15.19.3336.tgz > gave me a Debugger window > > > > with these artefacts > This is a MauiDomainMorph > > > > > -- best, Eliot

May 15, 2015

Default package comment

by Sergio Fedi

Hi guys, we are adding comments to packages and we would like a feedback from the community. What do you suggest for the default package comment?

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 14/05/2015 21:18, stepharo a Ã©crit : > ah, also I saw that you were discussing about do-it in separate processes. that should be easy to implment IMHO (as a test menu option to start), with some side effects sure ... I already mentioned the effectiveProcess not maintained by the inspector (see fogbuz entry https://pharo.fogbugz.com/f/cases/15491/Debugger-hangs-vm-on-step-into) there will be other but may be not that much. IMHO not only better for user experience, but also a way to explore new interesting areas -- Regards, Alain

May 14, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 14/05/2015 21:18, stepharo a Ã©crit : > Thanks alain for checking. > I think that we can offer different implementations and let people pick > the ones they like. > My goal is to remove direct refer to Transcript from the image so that > we can plug an implementation and in particular > the merge of Doru and Norbert/Mine loggers > > Stef > I did a cs that I've added in fogbugz entry, I tried to make as few modifications as possible, so that it remains like original Cuis implementation. May be a CS is not the best, but I do not know slices well, I don't know for example if they are cumulatives, and automaticallly processed as a fix when the issue is closed, that would not be good here, it is still a WIP. May be a repo on Smalltalkhub for that transcript would be better? I will also edit (or remove, but I don't know how yet) some comments I added in fogbugz entry, because the mailing list is a better place for discussions, IIUC it would be better to put only recaps in the fogbugz entry. As of today, the integration with Pharo ui is not good : it overwrites windows etc (as you may have seen in attached screenshots), some work is needed to make it better. modifications I made to the original Cuis sources : - changed all _ with := - renamed Transcript to CuisTranscript - renamed TranscriptMorph to CuisTranscriptMorph - renamed Transcriptwindow to CuisTranscriptWindow all in original st files, in order to keep the original stamp (author) filed-in those st files in pharo then in pharo: - filed-in 2 deprecated methods borrowed from squeak 4.5 (Canvas>>image:at: and Rectangle>>outsetBy: ) todo here: find the replacement - Modified 4 methods about extent, position etc, and added 2 for Cuis/Pharo compatibility : to be checked too and filed out the cs. -- Regards, Alain

May 14, 2015

Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows

by Nicolai Hess

I added an issue: 15541 <https://pharo.fogbugz.com/default.asp?15541> windows vm does not distinguish between ctrl+a and ctrl+home with a proposed solution: add $a-1 to the utf32Code field of the event struct, if the keyevent is a keystroke and the ctrl flag is set what do you think? 2014-06-30 9:31 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > There is an end key in many keyboards, but some others do not have it. Can > you (or better, How would you) have ctrl+end in keyboards that doesn't? > > Some VMs hardcoded that Ctrl+a = ctrl+home and Ctrl+d = Ctrl+end because > that's how old terminals work... Now, why have hardcoded ctrl+a = ctrl + > home, if you can just add a keybinding to ctrl + a? > > > On Mon, Jun 30, 2014 at 8:55 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hi >>> >>> hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to >>> make ctrl+home and ctrl+end working. Like you I was very surprised by such >>> keyboard events crappy state. >>> >>> >> >> So, having ctrl+end and ctrl+d working at the same time is not possible? >> >> >> >> >> >> >> >>> >>> >>> 2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>> 2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>>> >>>> There is a problem in the whole keyboard events: they treat keys as >>>>> characters and vice versa. And that's not always true: >>>>> - the backspace key is a key, but currently the image interprets it >>>>> as a character because we only use keypress events in general. >>>>> - the shift key is a key, and since current image does not use keyup >>>>> nor keydown, we cannot know if JUST a shift is pressed normally. >>>>> >>>>> >>>>> On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>>> wrote: >>>>> >>>>>> I don't know anything about event handling, but I once had a look at >>>>>> Character constants, and found this: >>>>>> >>>>>> Character class>>#home >>>>>> ^ self value: 1 >>>>>> >>>>>> How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH >>>>>> (Start of header), sometimes typed as CTRL-A. And there are other strange >>>>>> constants like that there. >>>>>> >>>>>> On 25 Jun 2014, at 08:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> >>>>>> > Hi, >>>>>> > >>>>>> > I am on Windows, using Pharo 3.0, and I am trying to get the >>>>>> keybindings to work in Rubric using Windows convention (so, Ctrl instead of >>>>>> Cmd as a modifier), >>>>>> > >>>>>> > It worked reasonably well, but the problem is that somehow Ctrl+a >>>>>> is mapped to Ctrl+Home. The problem is not specific to Rubric as I can >>>>>> detect the same behavior in the regular PluggableTextMorph. >>>>>> > >>>>>> > Does anyone have an idea of where the problem comes from? >>>>>> > >>>>>> > Doru >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > www.tudorgirba.com >>>>>> > >>>>>> > "Every thing has its own flow" >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> ctrl+a has the same strange behavior as ctrl+d >>>> ctrl+a -> ctrl+home >>>> ctrl+d -> ctrl+end >>>> >>>> look at KeyboardEvent>>#hasSpecialCTRLKeyValue >>>> I am not exactly sure why it is handled that way. >>>> Replace the method with >>>> >>>> hasSpecialCTRLKeyValue >>>> ^ self controlKeyPressed and: [ keyValue <= 26 ] >>>> >>>> now, ctr+a and ctr+d working as expected. >>>> But I don't know about the side-effects. >>>> >>>> >>>> nicolai >>>> >>>> >>> >> >

May 14, 2015