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

[pharo-project/pharo-core] 15ee0f: 50108

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 15ee0fd1df8e66f0a22de43ebc152ab8b24fe298 https://github.com/pharo-project/pharo-core/commit/15ee0fd1df8e66f0a22de43e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-12 (Fri, 12 Jun 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1217_.st A Morphic-Core.package/PasteUpMorph.class/instance/world state/startSteppingSubmorphsOf_.st R Morphic-Core.package/WorldMorph.class/instance/world state/startSteppingSubmorphsOf_.st M Rubric.package/RubMethodEditingExample.class/instance/accessing/textModel.st M Rubric.package/RubSmalltalkEditorModel.class/README.md M Rubric.package/RubSmalltalkEditorModel.class/definition.st R Rubric.package/RubSmalltalkEditorModel.class/instance/accessing/client_.st A Rubric.package/RubSmalltalkEditorModel.class/instance/accessing/interactionModel_.st M Rubric.package/RubSmalltalkEditorModel.class/instance/shout/shoutAboutToStyle_.st M Rubric.package/RubSmalltalkScriptEditorModel.class/instance/shout/hasBindingOf_.st M Rubric.package/RubSmalltalkScriptEditorModel.class/instance/shout/hasBindingThatBeginsWith_.st M Rubric.package/RubTextEditor.class/class/keymapping/buildShortcutsOn_.st M Rubric.package/RubTextEditor.class/instance/menu messages/compareToClipboard.st M Rubric.package/RubWorkspaceExample.class/instance/shout/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50107.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50108.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50107.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50108.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-ExternalBrowser.package/ExternalChangesBrowser.class/class/browsing/browseRecentLog.st Log Message: ----------- 50108 15740 openInWorld: aPasteUpMorph raises MNU PasteUpMorph>>startSteppingSubmorphsOf: https://pharo.fogbugz.com/f/cases/15740 15726 unimplemented methods for new change list https://pharo.fogbugz.com/f/cases/15726 15720 RubTextEditor references StringHolder https://pharo.fogbugz.com/f/cases/15720 http://files.pharo.org/image/50/50108.zip

June 12, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Camille

> On 12 Jun 2015, at 09:36, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > Hi, > > Did you tried to inspect the PPFailure in the Moose? There is a tab with a tree structure giving you a pretty good overview, what is going wrong... Or as an alternative, one can call: > myParser enableDebug parse:myInput > I didnât know about these features, there are cool :) Thanks! > Otherwise, PetitParser really needs some nice error reporting system. I would have integrated one, but I am not aware of any suitable solution :( I would be happy to discuss any idea youâll have on that subject :) > > Cheers, > Jan > > On Fri, Jun 12, 2015 at 8:07 AM Francisco Garau <francisco.garau(a)gmail.com <mailto:francisco.garau@gmail.com>> wrote: > > Hi Camile > > On 11 Jun 2015, at 10:47, Camille <camille.teruel(a)gmail.com <mailto:camille.teruel@gmail.com>> wrote: > >> >>> On 11 Jun 2015, at 09:30, Jan KurÅ¡ <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch>> wrote: >>> >>> That sounds really cool and useful extension. >>> >> Thank you Jan! >>> Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. >>> >>> I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? >>> >> Yes, with furthest failure I get errors from tokenization instead of my errors. >> For exemple with the calculator grammar I gave in my first mail when I parse â1+â the furthestFailure is â$- expected at 2â whereas I return âexpression expected at 2â because there's a whole expression missing. Same thing with â(1+2â that returns âdigit expected at 4â instead of â$) expected at 4â. >> >> But furthest failure gives wrong messages in other cases to. >> Consider this sequence parser: >> >> keyword := #letter asParser plus , $: asParser. >> keyword parse: âfoo' >> >> This returns 'letter expected at 3â, but no matter how many letters I add to the end Iâll still get âletter expectedâ. >> I want to get what is really missing: '$: expected at 3â. > > Any of those error messages wouldn't be too bad if the failing production rule were also mentioned. Something like "keyword rule failed with xx expected at 3" > > But yeah, that would require annotating the production rules which can pollute the clarity of the grammar definition... > > >> Maybe returning the âlatest furthest failureâ instead of the âfirst furthest failureâ could solves the problem here (i.e. replacing > with >= in PPContext>>#noteFailure:)? >>> One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ >>> >> Indeed, my hack (redefining #parseWithContext:) works only when the Pratt parser is the top parser, but a soon as I compose it Iâm screwed because only parseOn: is sent to the Pratt parser. >> Thatâs why I wonder if letting the parser decide what to return wouldnât solve the problem: by default the furthest failure but special parsers can still decide. >>> Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? >>> >> The Pratt tokens are special: a token points back to the parser that generated it (its âkindâ). >> PPTokenKind subclasses PPFlatteningParser and generates instances of PPPrattToken. >> A PPTokenKind stores the precedence, the action to be executed when a token of this kind is met at the start of an expression (for terminals and prefixes) and the action to be executed when a token is met in the middle of an expression (for postfixes and infixes). >> >> Cheers, >> Camille >>> Cheers Jan >>> >>> >>> On Wed, Jun 10, 2015, 20:52 Richard Sargent <richard.sargent(a)gemtalksystems.com <mailto:richard.sargent@gemtalksystems.com>> wrote: >>> camille teruel wrote >>> >> On 10 Jun 2015, at 19:11, Chris Cunningham < >>> >>> > cunningham.cb@ >>> >>> > > wrote: >>> >> >>> >> Inteteresting.... >>> >> >>> >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < >>> >>> > camille.teruel@ >>> >>> > <mailto: >>> >>> > camille.teruel@ >>> >>> > >> wrote: >>> >> Hello Pharoers and Moosers, >>> >> >>> >> I did a Pratt parser extension for PetitParser. >>> >> >>> >> >>> > <snip> >>> > >>> >> @PP Devs: >>> >> I had trouble with the PPContext furthestFailure that is taken into >>> >> account instead of the failures I return, so I had to redefine >>> >> #parseWithContext: to return the failures I want. The results given by >>> >> furthestFailure were not very meaningful in my case (the same is true for >>> >> PPExpressionParser btw). >>> >> But I guess it was introduced because it gives good results in other >>> >> cases. >>> >> So would it be possible to change this behavior to let the parser decide >>> >> if it returns the furthestFailure or the original failure? >>> >> >>> >> The intent behind the furthestFailure is that it give the failure that >>> >> gets the furthest into the source stream. It is most useful when there >>> >> are embedded choice operators in the parser - the original/pre furthest >>> >> behaviour would return the last failure, which depending on the incoming >>> >> stream and the order of the choice options could be significantly not >>> >> useful. >>> >> >>> >> I ran into this when working with the sql parser, which started off with >>> >> the outer choice of (by memory): >>> >> ^ selectStatement / insertStatement / updateStatement / >>> >> deleteStatement >>> >> If I was trying to part a select statement that had an error at the very >>> >> end of the statement, the parser would return an error talking about how >>> >> the incoming stream failed in deleteStatement. Not useful. >>> >> >>> >> I would be saddened if this further failure was not available. >>> > >>> > Yes in that case returning the furthest failure gives better results. >>> > However, this donât give meaningful messages in all cases. >>> > For exemple with the calculator I gave in my previous message, if I parse >>> > â1+â I want to get âexpression expected at: 2â but instead it returns â$- >>> > expected at 2'. >>> > Iâm not proposing to remove this feature but to let parsers decide to use >>> > it or not. >>> > Something like (changes in bold): >>> > >>> > PPParser>>parseWithContext: context >>> > | result | >>> > context initializeFor: self. >>> > result := self parseOn: context. >>> > >>> > "Return the furthest failure, it gives better results than the last >>> > failure" >>> > (result isPetitFailure and: [ self wantsFurthestFailure and: [ context >>> > furthestFailure notNil ] ]) >>> > ifTrue: [ ^ context furthestFailure ]. >>> > ^ result >>> >>> This screams at me. Why not just delegate to the context and use a context >>> that returns the preferred failure? e.g. end with: >>> ^context preferredResultFor: result. >>> >>> >>> > >>> > PPParser>>wantsFurthestFailure >>> > ^ true >>> > >>> > Like this, one can return the failures he wants. >>> > >>> > PPPrattParser>>wantsFurthestFailure >>> > ^ false >>> > >>> > >>> > Camille >>> > >>> >> >>> >> -cbc >>> >>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html <http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html> >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. >>> >>

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Stephan Eggermont

On 12-06-15 10:24, Esteban Lorenzano wrote: > it was just an example of why using #stable in project dependences is a bad idea :) > you made #releaseN.N to fix precisely my point. > there should exist something like I say â3.*â #'release3' always refers to the latest stable 3.*.*.* > Iâm sorry for being obvious here, I know this is knownâ¦ problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). That would be better handled with a (separate) SnapshotOf class i.m.o. Stephan

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Esteban Lorenzano

it was just an example of why using #stable in project dependences is a bad idea :) you made #releaseN.N to fix precisely my point. but since this is a convention of Seaside and not a regular practiceâ¦ who knows it? (not saying that is wrong, is in fact very good, but there should exist something like I say â3.*â) btwâ¦ IMO other frequent misunderstanding is the use of metacello as description for nightly builds. metacello (and any dependency manager) should be use *just* for releases. think other dependecy managers around: maven, npm or whateverâ¦ they are used to describe and publish projects people actually can download and use. Any version: 3.0 3.0.1 3.1 â¦ etc. is a loadable and usable version. the concept of stable/release/etc. is just incorrect: all published versions should be stable and released. we need to separate the concept of âartifact releasedâ and âdevelopment branchâ, and we need to stop using versions as commits. In my opinion development cycle should be: we release version 1.0 then we develop in bleeding edge lets say for doing a version 1.1 we want a bug fix for 1.0 while developing 1.1? then we install 1.0, make a fix, and publish 1.0.1 we continue in #bleedingEdge until we are ready to: 1.1-alpha 1.1-beta 1.1-rc1 1.1 we repeat the cycle for next version etc. Iâm sorry for being obvious here, I know this is knownâ¦ problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. cheers, Esteban > On 12 Jun 2015, at 10:04, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 12-06-15 09:34, Esteban Lorenzano wrote: >> Project A uses for instance Seaside stable which is, when Project A >> starts Seaside 3.0 >> time after owner tries to load Project Aâ¦ but since then stable from >> Seaside has move from Seaside 3.0, to 3.1.2 > > Seaside is the one example where we are using semantic versioning, > precisely because we ran into the problems you described. > We have #'release3', #'release3.0' #'release3.1' and will soon have > #'release3.2'. #'release3' points to #'release3.1', so if you don't > care about the api changes from 3.0 to 3.1 you'll just use the > latest stable. Otherwise, use #'release3.1'. > > We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo. > > So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'. > >> that of course introduces other kind of problems, like: what happens >> if I want to install Project A who depends on Seaside/3.0 and > >Project B who depends on Seaside/3.0.2 > > Yep, both should depend on #'release3.0'. That way, your code might > even run on Pharo 4, and profit from the bug fixes done between 3.0.2 > and the current 3.0.16 > > Stephan > > > >

June 12, 2015

Re: [Pharo-dev] What CodeImport is all about?

by Marcus Denker

Hi, This is a reader for .st and .cs files. Guille did it. It can -> evaluate for traditional fileIn -> load as Monticello model when falling back to .st file load (it is actually used by Monticello since last week) -> load as Ring Model > On 12 Jun 2015, at 02:43, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > I cannot figure out what this package is about. Looks like a kind of change set? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Stephan Eggermont

On 12-06-15 09:34, Esteban Lorenzano wrote: > Project A uses for instance Seaside stable which is, when Project A > starts Seaside 3.0 > time after owner tries to load Project Aâ¦ but since then stable from > Seaside has move from Seaside 3.0, to 3.1.2 Seaside is the one example where we are using semantic versioning, precisely because we ran into the problems you described. We have #'release3', #'release3.0' #'release3.1' and will soon have #'release3.2'. #'release3' points to #'release3.1', so if you don't care about the api changes from 3.0 to 3.1 you'll just use the latest stable. Otherwise, use #'release3.1'. We'll do bug fixes on the numbered versions, and make sure that they work with the latest versions. Depending on a numbered version will force you to keep up with every change in Seaside, especially because a lot of new versions are due to changes in Pharo. So, if you depend on Seaside, Grease or Magritte: you probably don't want to depend on #stable (nor #bleedingEdge), but on a #'releaseX.X'. > that of course introduces other kind of problems, like: what happens >if I want to install Project A who depends on Seaside/3.0 and >Project B who depends on Seaside/3.0.2 Yep, both should depend on #'release3.0'. That way, your code might even run on Pharo 4, and profit from the bug fixes done between 3.0.2 and the current 3.0.16 Stephan

June 12, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Jan KurÅ¡

Hi, Did you tried to inspect the PPFailure in the Moose? There is a tab with a tree structure giving you a pretty good overview, what is going wrong... Or as an alternative, one can call: myParser enableDebug parse:myInput Otherwise, PetitParser really needs some nice error reporting system. I would have integrated one, but I am not aware of any suitable solution :( Cheers, Jan On Fri, Jun 12, 2015 at 8:07 AM Francisco Garau <francisco.garau(a)gmail.com> wrote: > > Hi Camile > > On 11 Jun 2015, at 10:47, Camille <camille.teruel(a)gmail.com> wrote: > > > On 11 Jun 2015, at 09:30, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > That sounds really cool and useful extension. > > Thank you Jan! > > Regarding the furthest failure, the core of the problem is the distinction > between an error and a failure. Error reports on a problem in the input, > while failure is information for choice parser combinator. In general, the > furthest failure is a better approximation of an error than the last > failure, so we use it. > > I am not sure what exactly is the problem in case of PrattParser. I guess > the last failure gives better results for a user? > > Yes, with furthest failure I get errors from tokenization instead of my > errors. > For exemple with the calculator grammar I gave in my first mail when I > parse â1+â the furthestFailure is â$- expected at 2â whereas I return > âexpression expected at 2â because there's a whole expression missing. Same > thing with â(1+2â that returns âdigit expected at 4â instead of â$) > expected at 4â. > > But furthest failure gives wrong messages in other cases to. > Consider this sequence parser: > > keyword := #letter asParser plus , $: asParser. > keyword parse: âfoo' > > This returns 'letter expected at 3â, but no matter how many letters I add > to the end Iâll still get âletter expectedâ. > I want to get what is really missing: '$: expected at 3â. > > > Any of those error messages wouldn't be too bad if the failing production > rule were also mentioned. Something like "keyword rule failed with xx > expected at 3" > > But yeah, that would require annotating the production rules which can > pollute the clarity of the grammar definition... > > > Maybe returning the âlatest furthest failureâ instead of the âfirst > furthest failureâ could solves the problem here (i.e. replacing > with >= > in PPContext>>#noteFailure:)? > > One has to consider a pratt parser included in the normal parser, e. g. > Expressions parsed by pratt in a Java Grammar. Depending where an error > occurs, different strategy for choosing the proper failure is necessary :-/ > > Indeed, my hack (redefining #parseWithContext:) works only when the Pratt > parser is the top parser, but a soon as I compose it Iâm screwed because > only parseOn: is sent to the Pratt parser. > Thatâs why I wonder if letting the parser decide what to return wouldnât > solve the problem: by default the furthest failure but special parsers can > still decide. > > Regarding tokenization, there is a message token, that returns > PPTokenParser, which transforms a parsed input into the PPToken object. > Perhaps this might be helpful? > > The Pratt tokens are special: a token points back to the parser that > generated it (its âkindâ). > PPTokenKind subclasses PPFlatteningParser and generates instances of > PPPrattToken. > A PPTokenKind stores the precedence, the action to be executed when a > token of this kind is met at the start of an expression (for terminals and > prefixes) and the action to be executed when a token is met in the middle > of an expression (for postfixes and infixes). > > Cheers, > Camille > > Cheers Jan > > On Wed, Jun 10, 2015, 20:52 Richard Sargent < > richard.sargent(a)gemtalksystems.com> wrote: > >> camille teruel wrote >> >> On 10 Jun 2015, at 19:11, Chris Cunningham < >> >> > cunningham.cb@ >> >> > > wrote: >> >> >> >> Inteteresting.... >> >> >> >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < >> >> > camille.teruel@ >> >> > <mailto: >> >> > camille.teruel@ >> >> > >> wrote: >> >> Hello Pharoers and Moosers, >> >> >> >> I did a Pratt parser extension for PetitParser. >> >> >> >> >> > <snip> >> > >> >> @PP Devs: >> >> I had trouble with the PPContext furthestFailure that is taken into >> >> account instead of the failures I return, so I had to redefine >> >> #parseWithContext: to return the failures I want. The results given by >> >> furthestFailure were not very meaningful in my case (the same is true >> for >> >> PPExpressionParser btw). >> >> But I guess it was introduced because it gives good results in other >> >> cases. >> >> So would it be possible to change this behavior to let the parser >> decide >> >> if it returns the furthestFailure or the original failure? >> >> >> >> The intent behind the furthestFailure is that it give the failure that >> >> gets the furthest into the source stream. It is most useful when there >> >> are embedded choice operators in the parser - the original/pre furthest >> >> behaviour would return the last failure, which depending on the >> incoming >> >> stream and the order of the choice options could be significantly not >> >> useful. >> >> >> >> I ran into this when working with the sql parser, which started off >> with >> >> the outer choice of (by memory): >> >> ^ selectStatement / insertStatement / updateStatement / >> >> deleteStatement >> >> If I was trying to part a select statement that had an error at the >> very >> >> end of the statement, the parser would return an error talking about >> how >> >> the incoming stream failed in deleteStatement. Not useful. >> >> >> >> I would be saddened if this further failure was not available. >> > >> > Yes in that case returning the furthest failure gives better results. >> > However, this donât give meaningful messages in all cases. >> > For exemple with the calculator I gave in my previous message, if I >> parse >> > â1+â I want to get âexpression expected at: 2â but instead it returns >> â$- >> > expected at 2'. >> > Iâm not proposing to remove this feature but to let parsers decide to >> use >> > it or not. >> > Something like (changes in bold): >> > >> > PPParser>>parseWithContext: context >> > | result | >> > context initializeFor: self. >> > result := self parseOn: context. >> > >> > "Return the furthest failure, it gives better results than the >> last >> > failure" >> > (result isPetitFailure and: [ self wantsFurthestFailure and: [ >> context >> > furthestFailure notNil ] ]) >> > ifTrue: [ ^ context furthestFailure ]. >> > ^ result >> >> This screams at me. Why not just delegate to the context and use a context >> that returns the preferred failure? e.g. end with: >> ^context preferredResultFor: result. >> >> >> > >> > PPParser>>wantsFurthestFailure >> > ^ true >> > >> > Like this, one can return the failures he wants. >> > >> > PPPrattParser>>wantsFurthestFailure >> > ^ false >> > >> > >> > Camille >> > >> >> >> >> -cbc >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

June 12, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Esteban Lorenzano

dependency management for projects is *never* an easy task. who think that the complex on loading project X or Y is because of metacello simply does not understand the inherent complexity the task it tries to solve has. things can be improved, yesâ¦ but no matter what tools we create, this will just make a bit easier what is complex. nowâ¦ I think one of our problems is the use of #stable into configurations. I have expressed my concerns other moments, but here it is again: Project A uses for instance Seaside stable which is, when Project A starts Seaside 3.0 time after owner tries to load Project Aâ¦ but since then stable from Seaside has move from Seaside 3.0, to 3.1.2 nowâ¦ that can be ânot desiredâ at all. Project A wanted Seaside 3.0, not 3.1 (of course, if using Semantic Versioning that will mean there is just changes to the API in a compatible wayâ¦ but we all know we do not use semver correctly almost never). Soâ¦ in fact Project A cannot depend on Seaside/#stableâ¦ instead, he should depend on Seaside/3.0 directly to be sure you have the version you want. that of course introduces other kind of problems, like: what happens if I want to install Project A who depends on Seaside/3.0 and Project B who depends on Seaside/3.0.2 Wellâ¦ ideally, we need to be able to resolve those problems when loading. Also, it would be cool to specify version dependencies as âSeaside/3.*â, for instanceâ¦ but wellâ¦ thatâs another thread :) As you can seeâ¦ is not an easy task. Esteban > On 12 Jun 2015, at 02:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Absence of Metacello won't help you dealing with dependencies > and loading stuff by using hand-made scripts by dozens of people > written at different points in time and not maintained by anyone. > > It may be too complicated to use, especially at earlier stages of development, > and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge). > > But always staying on bleeding edge hurts a lot (that's why it called so) > and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. > Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. > And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. > And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there. > > -- > Best regards, > Igor Stasenko.

June 12, 2015

[pharo-project/pharo-core]

by GitHub

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

June 12, 2015

[pharo-project/pharo-core] ddfc63: 50107

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ddfc63bc91c676059adbcc0f7ff4c7525a152e36 https://github.com/pharo-project/pharo-core/commit/ddfc63bc91c676059adbcc0f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-12 (Fri, 12 Jun 2015) Changed paths: M AST-Core.package/RBConfigurableFormatter.class/instance/private/needsParenthesisFor_.st A AST-Tests-Core.package/RBFormatterTests.class/instance/testing/testShouldNotParenthesizeDynamicArrayStatements.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version051_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/README.md R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/accessing/defaultWarningLimit.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/accessing/defaultWarningLimit_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/accessing/resetDefaultWarningLimit.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/example/example.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/example/getText.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/text/ignoredCharacters.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/class/text/textSizeOf_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/definition.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/accessing/alertLimit.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/accessing/alertLimit_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/accessing/warningLimit.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/accessing/warningLimit_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/drawing/backgroundColorFor_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/drawing/basicColor.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/drawing/basicWidth.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/drawing/buildRectFrom_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/drawing/drawOn_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/private/setBalloonTextFrom_.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/private/stringColor.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/private/textSize.st R Morphic-Widgets-Pluggable.package/PluggableTextMorphWithLimits.class/instance/test/innerExtent.st M Nautilus.package/AbstractNautilusUI.class/instance/private/textMorphClass.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/buildNewSourceTextArea.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/sourceCode.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50106.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50107.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50106.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50107.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu - message/browseVersions.st A Spec-Tools.package/ChangeSorterApplication.class/instance/private/createRingMethodForRemovedSelector_inClass_.st A Spec-Tools.package/ChangeSorterApplication.class/instance/private/createRingMethodForSelector_inClass_.st A Spec-Tools.package/NewVersionBrowser.class/class/api/browseVersionsForMethod_.st M Tool-Base.package/AbstractTool.class/instance/method/browseVersionsFrom_.st M Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st Log Message: ----------- 50107 15741 PluggableTextMorphWithLimits should be removed https://pharo.fogbugz.com/f/cases/15741 15749 RB: Dont Add Parens Around Lit Array Elements https://pharo.fogbugz.com/f/cases/15749 15751 catalog (with spotter) needs to show projects after classes and packages https://pharo.fogbugz.com/f/cases/15751 15752 make browsing versions of removed methods working again https://pharo.fogbugz.com/f/cases/15752 http://files.pharo.org/image/50/50107.zip

June 12, 2015