- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Tx Pass

by Alain Plantec

Hello, > On 27 Apr 2015, at 15:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Just like Bloc (which has *great* class comments), I think it's crucial to > document the high level design decisions in Tx. I did a first pass and noted > some initial impressions... > > Design Questions: > - TxModel - what is the advantage of a double linked list vs the old Text > implementation? I think it facilitates the moving for one text element to another, and the implementation of new text elements. as an example, Igor added TxEmbeddedObjectSpan in one day. It allows the adding of Morps (or what ever object) as text elements. The same was done for the current Paragraph, the implementation was a messy hack. drawback, I find the model difficult to understand. > - TxLayoutViewMorph vs. TxTextEditorMorph - I'm not clear on the > purpose/relationship/pattern here? TxLayoutViewMorph: presents a sub part of the text and implements the scrolling (no need for a scroll pane). TxTextEditorMorph: owns a TxLayoutViewMorph, a controller (an editor) and a cursor to allow text editing. Thus, TxTextEditorMorph implements text editing (insert: aString ). When the text is changed, only the subpart of the text is layouted (by the TxLayoutViewMorph). Also, only the viewed sub-part of the text is re-layouted in case of scrolling, not the whole text as in Paragraph. Thus, the editing efficiency stay acceptable even for big text the drawback is for the scrollbar: its value must be approximate. > > Implementation Questions: > - TxBasicSpan#< seems overly complex. Why two-way searching. Was it the > result of profiling? Intuition? Random? > - TxTextEditorMorph>>#openInWindowWithText: says not part of API, but this > code is pretty much the only way to use it for now, right? yes, near from what is needed for real > - applyAttribute:to: sends an unimplemented message, but I'm not sure what > should be done here > - Why no strike fonts? Why is Verdana commented out in TxFontAttribute > class>>#defaultValue? I guess lack of time to integrate strike fonts properly. but do we need it ? > - TxLayoutViewMorph class>>#text: sends #asTxModel to argument, but > TxTextEditorMorph doesn't. Which one is right? I think there's not much harm > in sending it in both to make it a bit easier for usersâ¦ I think #asTxModel should be sent for both Cheers Alain > - TxBasicViewMorph>>#fullDrawOnAthensCanvas: checks if fullBounds are > visible on canvas, then checks #bounds again. Are both necessary? > > Tx already seems very usable! I'm starting to play with it in one of my > projects... I've been dreaming about this for a long time :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Tx-Pass-tp4822173.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 28, 2015

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

by Luc Fabresse

Congrats Sean for this one! It impacts on a lot of external packages... #Luc 2015-04-28 20:58 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Review-Issue-14080-Nuke-remaining-subStringXyz-s-tp48… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 28, 2015

Re: [Pharo-dev] Pharo 50 has old Rubric Repo

by Tudor Girba

Sure. Andrei only explained why it did not happen yet. Doru On Tue, Apr 28, 2015 at 7:34 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Andrei Chis wrote > > We didn't do any integration of rubric into Pharo 5 yet so the old repo > is > > still there. > > Yes, but we want new packages to go into the new repo so it should be > there! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-50-has-old-Rubric-Repo-tp4822586p4822604.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

April 28, 2015

[Review] Issue 14080: Nuke remaining subStringXyz's

by Sean P. DeNigris

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? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Issue-14080-Nuke-remaining-subStringXyz-s-tp48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 28, 2015

Re: [Pharo-dev] Idea for playground

by Andrei Chis

On Apr 28, 2015 8:45 PM, "stepharo" <stepharo(a)free.fr> wrote: > > Once we have the path it means that we can reapply it to all the elements of a collection for example :) Yes. That and generating code are our main use-cases :) Cheers, Andrei > > > Le 28/4/15 19:53, Andrei Chis a Ã©crit : >> >> It's coming :) >> >> We implemented a while back a prototype for recording/replaying all the steps in an inspection session, but because of the >> current design of glamour it was quite difficult to get it working correctly. >> >> >> Cheers, >> Andrei >> >> >> On Tue, Apr 28, 2015 at 7:16 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi, >>> >>> sometimes when I play in playground in order to achieve something I can go 10 levels deep or even more. Maybe we can implement an option to somehow construct one script from all executed parts, so then this script can be turned into a method or so on. >>> >>> >>> Uko >> >> >

April 28, 2015