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

[Pharo5][Slots] emitStore: should not send writeToSlot:of:

by Marcus Denker

Hi, This small change: https://pharo.fogbugz.com/f/cases/15436 improves the code generated by Slots when using the default âreflective writeâ (instead of generating their own optimised code like InstanceVariableSlots). The helper method #writeToSlot:of: in Object was just needed as the arguments where in the wrong oder on the stack. We can use writeSlot:value: by generating code like this: emitStore: aMethodBuilder | tempName | tempName := Object new. aMethodBuilder addTemp: tempName; storeTemp: tempName; popTop; pushReceiver; pushLiteral: self; pushTemp: tempName; send: #writeSlot:value: For what needs to be done, see https://trello.com/b/d59lgZFB/slots Marcus

April 29, 2015

Re: [Pharo-dev] [Reflectivity] tiny step: conditions for links

by Marcus Denker

> > Next step: when *changing* the condition object (e.g. to true or false or a different block), we > need to re-generate code. > > ==> we need #invalidate on the MetaLink and call it on #condition:. > This is the next step for (hopefully) tomorrow. > This issue: https://pharo.fogbugz.com/f/cases/15435 <https://pharo.fogbugz.com/f/cases/15435> has the change. The idea is that all accessors in MetaLink call #invalidate which just does invalidate nodes do: [ :node | node invalidate ] With this simple change, one can now use e.g. a boolean as a link condition: haltLink := MetaLink new condition: false; metaObject: Halt; selector: #now. When installed, it does nothing. But we can afterwards change the condition: haltLink condition: true. and it will make sure to re-compile all affected code before the next execution and thus enable the link. The same is true for #selector: and #metaObject:. Marcus

April 29, 2015

Re: [Pharo-dev] [Issue tracker] what about old issues?

by Peter UhnÃ¡k

On Wed, Apr 29, 2015 at 1:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > every Fogbugz comment to come to the list > There is already separate pharo-issues mailing list ( http://forum.world.st/Pharo-Issue-Tracker-f3456798.html ) so no need to duplicate it. However it would make sense to send periodical (daily or weekly) updates - something that was proposed previously â http://forum.world.st/More-people-needed-to-review-issues-td4800916.html#a4… So maybe it could be incorporated into that. # Issues to be closed due to inactivity: - issueX - issueY etc (plus of course automted mail to the issue opener/assigned person). I don't know how friendly FogzBugz is with automating such mails. Peter

April 29, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50018 Home: https://github.com/pharo-project/pharo-core

April 29, 2015

[pharo-project/pharo-core] 4a1c70: 50018

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 4a1c703d5083b3b76c1e46f9f551a8716bb6d6cd https://github.com/pharo-project/pharo-core/commit/4a1c703d5083b3b76c1e46f9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-29 (Wed, 29 Apr 2015) Changed paths: A MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/menu spec/collectConfigurationMenuSpecs.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/menu spec/configurationMenuSpec.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/addMetacelloBaseline.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/baseLines.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/browseConfiguration.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/configurationClass.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/createDevelopmentVersion.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/createReleaseVersion.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/createVersionForBlessing_.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/dependentPackages.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/hasAnyBaseline.st R MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/metacello/lastBaseLine.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/workingCopyListMenu_.st M Morphic-Core.package/HandMorph.class/instance/halo handling/removeHalo.st A Morphic-Core.package/HandMorph.class/instance/halo handling/removeHaloAround_.st M Morphic-Core.package/Morph.class/instance/halos and balloon help/halo.st M Morphic-Core.package/Morph.class/instance/halos and balloon help/removeHalo.st M NECompletion.package/NECMenuMorph.class/class/preferences/convertToSHSymbol_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script626.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script627.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50017.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50018.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50018 15429 remove coupling from monticello GUI with metacello https://pharo.fogbugz.com/f/cases/15429 15433 issue 15426 breaks NEC-Completion https://pharo.fogbugz.com/f/cases/15433 15235 Faster Morphic>>removeHalo https://pharo.fogbugz.com/f/cases/15235 http://files.pharo.org/image/50/50018.zip

April 29, 2015

Re: [Pharo-dev] [Review] Issue 14080: Nuke remaining subStringXyz's

by Marcus Denker

> On 28 Apr 2015, at 20:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > https://pharo.fogbugz.com/default.asp?14080 > > This was a real PITA! The monkey finally passed it. All [s|S]ubStr[ing].* > methods and users have been changed to e.g. substring. I'd like to get it > integrated ASAP because this is another that touches many packages and will > be hard to keep up to date. Thanks. > > I notified the maintainers of affected external packages, except Metacello > which I included in the slice. Is that correct? > Metacello is a problemâ¦ it is supposed to stay compatible to Squeak, Pharo1.1 and strange things like thatâ¦ The version in the image is very old and needs to be updated, too. So for now I would just change it and then we see what to doâ¦ Marcus

April 29, 2015

Re: [Pharo-dev] [Issue tracker] what about old issues?

by Ben Coman

On a related topic, I'm not sure if we want every Fogbugz comment to come to the list, but can Fogbugz be configured to post just the Issue Open comment to this mail list. This should help us perform bug-report QA up front when the reporter has details to hand. If required reproducability details are not forthcoming, then we close the issue early. cheers -ben On Wed, Apr 29, 2015 at 2:17 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 28 Apr 2015, at 19:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > >> On 28 Apr 2015, at 18:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> > >> 666 open issues > >> The tracker is telling us that old issues are evil. :) > >> > > :-) > > > >> -> automatically put them on âclosed, timeoutâ > >> -> send a mail to the original submitter AND pharo-dev > >> Maybe in the opposite order? After a period [year] send mail and if no > response within a week or two then close it. > > > > it would be easier to automateâ¦. > > > > Marcus > > Yes, it should be automated (saving people's time is very important). > And yes, issue that are too old for anyone to care about should be > deactivated. > > >

April 28, 2015

Re: [Pharo-dev] Is there a way to understand why rubric (playground) does not highlight code?

by Yuriy Tymchuk

Look, the point is that if code styling is not happening, because higher priority process is running, you canât see what you are typing. There is a cause for that. Also, is there a way disable styling? Just to see what happens then? Uko > On 28 Apr 2015, at 22:50, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > RubEditingArea allInstances collect: #textColor "{Color transparent. Color transparent. Color transparent. Color transparent. Color black. Color black. Color lightGray}" > > But I haven't seen any place that would be missing color. Maybe the "EditingArea" color is not used in favor of selection/section color (or whatever the name of it in rubric is)? > > Peter > > On Tue, Apr 28, 2015 at 10:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Guys, run please âRubEditingArea allInstances collect: #textColorâ. Almost all rubric text areas have transparent text color. Is it something strange happening in my image, or you have the same? > > Uko > > > >> On 20 Apr 2015, at 14:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >> This also happened to me several times when executing (do it and go) some Roassal example with error (=it opened debugger). However the occurrence is very inconsistent so I don't know what was the trigger. >> >> Peter >> >> On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> This was just an example. The question is how do I identify what is blocking the highlighting. >> >> Uko >> >> >>> On 20 Apr 2015, at 12:19, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> Hi >>> >>> Maybe highlighting is running in process with lesser priority than default priority of #fork method. >>> >>> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes with lesser priority >>> >>> >>> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>> Open a new pharo image (Iâve used latest 5, but on 4 it should work as well). Open playground and execute: >>> >>> [ [ true ] whileTrue: [ ] ] fork >>> >>> now open a new playground and start typing. Characters are invisible. >>> Uko >>> >>>> On 20 Apr 2015, at 11:14, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >>>> >>>> Hi, >>>> >>>> I did not see this before. Could you reproduce the issue? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>> Hi. >>>> >>>> Sometimes it happens that playground does not do the syntax highlighting. This is especially frustrating when you open a new window and text is either white or transparent i.e. you cannot see what you are typing. >>>> >>>> I guess this is because some process is blocked by another one. Is there a way to check it? Because I want to understand whether it is because of me, or not. >>>> >>>> Cheers! >>>> Uko >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com <http://www.tudorgirba.com/> >>>> >>>> "Every thing has its own flow" >>> >>> >> >> > >

April 28, 2015

Re: [Pharo-dev] Is there a way to understand why rubric (playground) does not highlight code?

by Peter UhnÃ¡k

RubEditingArea allInstances collect: #textColor "{Color transparent. Color transparent. Color transparent. Color transparent. Color black. Color black. Color lightGray}" But I haven't seen any place that would be missing color. Maybe the "EditingArea" color is not used in favor of selection/section color (or whatever the name of it in rubric is)? Peter On Tue, Apr 28, 2015 at 10:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Guys, run please âRubEditingArea allInstances collect: #textColorâ. Almost > all rubric text areas have transparent text color. Is it something strange > happening in my image, or you have the same? > > Uko > > > > On 20 Apr 2015, at 14:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > This also happened to me several times when executing (do it and go) some > Roassal example with error (=it opened debugger). However the occurrence is > very inconsistent so I don't know what was the trigger. > > Peter > > On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> This was just an example. The question is how do I identify what is >> blocking the highlighting. >> >> Uko >> >> >> On 20 Apr 2015, at 12:19, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi >> >> Maybe highlighting is running in process with lesser priority than >> default priority of #fork method. >> >> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes >> with lesser priority >> >> >> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >>> Open a new pharo image (Iâve used latest 5, but on 4 it should work as >>> well). Open playground and execute: >>> >>> [ [ true ] whileTrue: [ ] ] fork >>> >>> now open a new playground and start typing. Characters are invisible. >>> Uko >>> >>> On 20 Apr 2015, at 11:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> I did not see this before. Could you reproduce the issue? >>> >>> Cheers, >>> Doru >>> >>> >>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >>>> Hi. >>>> >>>> Sometimes it happens that playground does not do the syntax >>>> highlighting. This is especially frustrating when you open a new window and >>>> text is either white or transparent i.e. you cannot see what you are typing. >>>> >>>> I guess this is because some process is blocked by another one. Is >>>> there a way to check it? Because I want to understand whether it is because >>>> of me, or not. >>>> >>>> Cheers! >>>> Uko >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> >> >> > >

April 28, 2015

Re: [Pharo-dev] Is there a way to understand why rubric (playground) does not highlight code?

by Yuriy Tymchuk

Guys, run please âRubEditingArea allInstances collect: #textColorâ. Almost all rubric text areas have transparent text color. Is it something strange happening in my image, or you have the same? Uko > On 20 Apr 2015, at 14:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > This also happened to me several times when executing (do it and go) some Roassal example with error (=it opened debugger). However the occurrence is very inconsistent so I don't know what was the trigger. > > Peter > > On Mon, Apr 20, 2015 at 1:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > This was just an example. The question is how do I identify what is blocking the highlighting. > > Uko > > >> On 20 Apr 2015, at 12:19, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi >> >> Maybe highlighting is running in process with lesser priority than default priority of #fork method. >> >> Code like "[ [ true ] whileTrue: [ ] ] fork" will block any processes with lesser priority >> >> >> 2015-04-20 12:51 GMT+03:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >> Open a new pharo image (Iâve used latest 5, but on 4 it should work as well). Open playground and execute: >> >> [ [ true ] whileTrue: [ ] ] fork >> >> now open a new playground and start typing. Characters are invisible. >> Uko >> >>> On 20 Apr 2015, at 11:14, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >>> >>> Hi, >>> >>> I did not see this before. Could you reproduce the issue? >>> >>> Cheers, >>> Doru >>> >>> >>> On Mon, Apr 20, 2015 at 11:03 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> Hi. >>> >>> Sometimes it happens that playground does not do the syntax highlighting. This is especially frustrating when you open a new window and text is either white or transparent i.e. you cannot see what you are typing. >>> >>> I guess this is because some process is blocked by another one. Is there a way to check it? Because I want to understand whether it is because of me, or not. >>> >>> Cheers! >>> Uko >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >> >> > >

April 28, 2015