- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 44801d: 60175

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 44801dd18088fe36485d2b5f19dcfb5754824c53 https://github.com/pharo-project/pharo-core/commit/44801dd18088fe36485d2b5f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-09 (Tue, 09 Aug 2016) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F23_.st M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/README.md M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/instance/bytecode generation/genPushNClosureTemps_.st M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/instance/extended bytecode generation/genPushFullClosure_numCopied_receiverOnStack_outerContextNeeded_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60174.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60175.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60174.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60175.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/whenSelectedItemChangesOnListModel.st M Tools-Test.package/MethodFinderTest.class/instance/test examples/testGreaterThanANumber.st M Tools-Test.package/MethodFinderTest.class/instance/test examples/testSearchForOne.st M UnifiedFFI.package/FFIExternalPackedStructure.class/class/private/compileFields_withAccessors_.st M UnifiedFFI.package/FFIExternalStructure.class/class/private/compileFields_withAccessors_.st M UnifiedFFI.package/FFIExternalStructureFieldParser.class/instance/parsing/parseFields_structure_.st M UnifiedFFI.package/FFIExternalType.class/class/accessing/pointerSize.st M UnifiedFFI.package/FFIExternalUnion.class/class/private/compileFields_withAccessors_.st Log Message: ----------- 60175 18891 MethodFinderTest>>#testGreaterThanANumber is dependent on order https://pharo.fogbugz.com/f/cases/18891 18889 CriticsBrowser "BlockCannotReturn" https://pharo.fogbugz.com/f/cases/18889 18896 add support for ignored fields in structures https://pharo.fogbugz.com/f/cases/18896 18898 Sista Encoder update for release. https://pharo.fogbugz.com/f/cases/18898 http://files.pharo.org/image/60/60175.zip

Aug. 9, 2016

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

by Martin Dias

Ah, you can try: Metacello new smalltalkhubUser: 'MartinDias' project: 'Epicea'; configuration: 'Epicea'; version: '7.98'; load. you should be working in a Pharo 6 that has an old Epicea version. Martin On Tue, Aug 9, 2016 at 11:19 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > I'm looking at it. Vincent reported it a couple of weeks ago and I fixed > it (apparently not?!) > > Martin > > On Tue, Aug 9, 2016 at 8:56 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> I just tried to replay a change today in Pharo60 and I got an error in >> epicea. >> >> EpRedoVisitor>>visitEvent: aChange >> ^ self error: 'Should not be reached'. >> >> EpRedoVisitor>>visitCodeChange: aChange >> "Default behavior for any change." >> >> ^ self visitEvent: aChange >> >> EpRedoVisitor>>visitBehaviorChange: aChange >> ^ self visitCodeChange: aChange >> >> EpRedoVisitor>>visitProtocolChange: aProtocolAddition >> ^ self visitBehaviorChange: aProtocolAddition. >> >> >> visitProtocolAddition: aProtocolAddition >> ^ self visitProtocolChange: aProtocolAddition >> >> >> Apparently it was a >> >> EpProtocolAddition >> >> >> And the RedoVisitor does not handle them. >> >> I do not have the time to check further - I just want to rescue my code >> for now. >> >> >> Stef >> >> >> >

Aug. 9, 2016

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

by Martin Dias

Hi, I'm looking at it. Vincent reported it a couple of weeks ago and I fixed it (apparently not?!) Martin On Tue, Aug 9, 2016 at 8:56 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I just tried to replay a change today in Pharo60 and I got an error in > epicea. > > EpRedoVisitor>>visitEvent: aChange > ^ self error: 'Should not be reached'. > > EpRedoVisitor>>visitCodeChange: aChange > "Default behavior for any change." > > ^ self visitEvent: aChange > > EpRedoVisitor>>visitBehaviorChange: aChange > ^ self visitCodeChange: aChange > > EpRedoVisitor>>visitProtocolChange: aProtocolAddition > ^ self visitBehaviorChange: aProtocolAddition. > > > visitProtocolAddition: aProtocolAddition > ^ self visitProtocolChange: aProtocolAddition > > > Apparently it was a > > EpProtocolAddition > > > And the RedoVisitor does not handle them. > > I do not have the time to check further - I just want to rescue my code > for now. > > > Stef > > >

Aug. 9, 2016

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

by stepharo

Hi doru I think that this is particularly true (having a themer per widget) when the themer is more a skinner (it changes behavior of the widgets), else we could have addressed the problem with a solution close to setting. Two years ago I played with theming and widgets hierarchy and I came to the same conclusion (that your blog entries). Do you know how they do it in JavaFX? I agree also that we should extract the Palette. Now I'm really curious to see the CSS of Glenn in Bloc2. Stef Le 4/8/16 Ã 12:52, Tudor Girba a Ã©crit : > Hi Esteban, > > Sorry for the delayed response. > > There are two parts in your mail: > 1. the decomposition of theme to have one themer per widget > 2. a centralized catalog of values > > I certainly agree with 2. In fact, when I refactored the theme colors > a long time ago, I introduced a rudimentary reuse mechanism on the > class side of the Theme class. So, now, we should extract those > separately. > > About 1., I have a different opinion. The hierarchy you mention > already exists in the Theme class as well, only it is hidden, and it > is very hard to see what each methods impacts. > > Here is how I reached this conclusion. Take a look at this picture I > produced before we started with Brick (the one from Morphic). The gray > circles are methods in UITheme, and the red circles are typical Morphs > (like TextMorph, ListMorph). The gray lines show self calls inside the > UITheme, and the red lines shod calls from the morph to the UITheme > methods. What you see here is a very strong clustering of the methods > around the widgets, and this indicates that having a theme object per > widget is appropriate. > > > > > A further constrain is that we want to be able to change the > appearance of a widget on an instance basis (that is, overriding the > default theme setting), and having a per-widget themer object, we can > achieve that as well. > > A similar design appears in Bloc as well, and I think it is actually > more scalable then the current UITheme, provided that you indeed have > a way to either centralize the definitions of colors (and other > properties), or inject those properties from the outside. > > All in all, letâs go ahead and extract the palette :). > > Cheers, > Doru > > >> On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> Hi, >> >> For one of my side-projects, I made a new theme for Pharo (still no >> name, I was planing to call it âDark Metalâ or something like that. >> Is a variation on the Dark Theme but âourâ dark theme is more brown >> and this one is more blue (see attached)â¦ I wanted to publish it to >> push it but then I arrived to an unexpected problem: For Spotter and >> GTTools in general, theming is not done following current theming >> approach. Instead, they made a full hierarchy of objects. >> >> IMO this is plain bad. I understand the attempt to decouple, but now >> that means if I want to create a new theme, I need to create my theme >> object with colors I want and then also I need to create an >> undetermined number of classes (at least one for each tool, but there >> is also a hierarchy of things there)â¦ anyway, this DOES NOT scale. >> Because each tool will have to have a âtheme classâ for each existing >> themeâ¦ >> How themes (skins, bah) work in all word is to have a color palette >> and then tools takes them (they can âplayâ a bit with this palette, >> but need to always respect the palette). >> >> Then, I will commit a SLICE modifying the âthemerâ classes to take >> colors from the current theme (instead of have them hardcoded). >> But of course, how theme work now is not good because they mix >> âthemeâ (how they display) and âskinâ (color palette). I will also >> extract the palette to where should have always been (some kind of a >> style sheet object)â¦ who also should have been editable in settings >> so people can tweak their configuration. >> >> I didnât wanted to touch this before, because this will supposedly >> change with brick, but honestly this will not be ready for Pharo 6 >> and this is annoying (also, I want to publish my theme and I do not >> want to add overrides all around :P) >> >> cheers, >> Esteban >> >> >> <Screen Shot 2016-08-01 at 11.00.15.png> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." >

Aug. 9, 2016

Re: [Pharo-dev] Pharo5 Jenkins build crash

by Cyril Ferlicot Delbecque

On 09/08/2016 14:01, Yann Dubois wrote: > Hi, > > Since Sunday, all build launched for Pharo 5 crashed > Hi, Those are known bugs. It happen on all Jenkins. There is a fogbugs issue for it. > > I think that the problem is in command line handler but I'm not sure. You can see the complete log, for example, at https://ci.inria.fr/pharo-contribution/job/Pillar/1715/PHARO=50,VERSION=sta… > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Peter UhnÃ¡k

> I can not tell if it would work on Pharo 5.0. I using IceBerg on Pharo 5. On Tue, Aug 9, 2016 at 2:10 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I've checked again on pharo6 and get the same error. > > - downloaded pharo6 > > - Metacello new > baseline: 'Iceberg'; > repository: 'github://npasserini/iceberg:stable'; > load. > > - openend UI via tools/Iceberg > > - click "Clone new repository" > > Same error as in pharo5. Cannot parse URL > > I've created an issue > > Norbert > > Am 09.08.2016 um 14:00 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Hi Norbert, > > Up to date, Iceberg has only been developed/used/tested on Pharo 6.0, > please look at the prerrequisites in https://github.com/npasserini/iceberg. > I can not tell if it would work on Pharo 5.0. > > Either way, if you could submit a bug report I will happily pay a look at > it. > > On Tue, Aug 9, 2016 at 1:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> >> >> On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I'm using pharo5 and I wonder we is this version marked as stable >> >> >> The readme states: >> >> "This is still a prototype and is not yet ready for production, but you >> are invited to try it and provide feedback. " >> >> Note however that I've successfully started using it for smaller >> project(s) that are hosted on GitHub. Of course there's a lot of issues >> https://github.com/npasserini/iceberg/issues , but it can be forced to >> work if you are willing to live on the edge. :) >> >> Regarding your error, it would be best to submit a bug report. >> >> Peter >> > > >

Aug. 9, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 9, 2016

[pharo-project/pharo-core] 3c4689: 60174

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3c46899a2ee045db8515d52e3e13ed1c340a7e56 https://github.com/pharo-project/pharo-core/commit/3c46899a2ee045db8515d52e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-09 (Tue, 09 Aug 2016) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st A AST-Core.package/RBSequenceNode.class/instance/adding nodes/addFaultyNode_.st M AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testParseUnfinishedBlockWithFaultyBody.st M Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedClassMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/data/expectedMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/testing/testClassMethodDefinition.st M Monticello-Tests.package/MCStWriterTest.class/instance/testing/testMethodDefinition.st M OpalCompiler-Core.package/extension/Context/instance/isBlockReturn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60173.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60174.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60173.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60174.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60174 18890 Parser cant not parse faulty or unfinished blocks with return caret https://pharo.fogbugz.com/f/cases/18890 18893 MCStWriterTest>>#expectedClassMethodDefinition will always fail on bootstrapped image https://pharo.fogbugz.com/f/cases/18893 18892 simplify isBlockReturn: to use encoder https://pharo.fogbugz.com/f/cases/18892 http://files.pharo.org/image/60/60174.zip

Aug. 9, 2016

Re: [Pharo-dev] Iceberg in general

by Norbert Hartl

I've checked again on pharo6 and get the same error. - downloaded pharo6 - Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg:stable'; load. - openend UI via tools/Iceberg - click "Clone new repository" Same error as in pharo5. Cannot parse URL I've created an issue Norbert > Am 09.08.2016 um 14:00 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Hi Norbert, > > Up to date, Iceberg has only been developed/used/tested on Pharo 6.0, please look at the prerrequisites in https://github.com/npasserini/iceberg <https://github.com/npasserini/iceberg>. I can not tell if it would work on Pharo 5.0. > > Either way, if you could submit a bug report I will happily pay a look at it. > > On Tue, Aug 9, 2016 at 1:55 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > On Tue, Aug 9, 2016 at 1:39 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > I'm using pharo5 and I wonder we is this version marked as stable > > The readme states: > > "This is still a prototype and is not yet ready for production, but you are invited to try it and provide feedback. " > > Note however that I've successfully started using it for smaller project(s) that are hosted on GitHub. Of course there's a lot of issues https://github.com/npasserini/iceberg/issues <https://github.com/npasserini/iceberg/issues> , but it can be forced to work if you are willing to live on the edge. :) > > Regarding your error, it would be best to submit a bug report. > > Peter >

Aug. 9, 2016

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

by stepharo

Le 7/8/16 Ã 17:01, webwarrior a Ã©crit : > stepharo wrote >> ... >> >> In June we spent three days to understand if we should merge Bloc2 >> into Bloc and we decided the inverse because >> his implementation is based on SDL and a separate window) it does >> not suffer from the morphic plague. So for example >> the event bubbling is nice and clean. The idea is to be able to use >> one window (morphic) to develop >> all the widgets and displayed in the SDL window needed up to the >> point where we can remove morphic. >> >> ... > Does that mean that Bloc will only work in separate window until Morphic is > fully replaced and removed from the image? Yes. > That would take many years I guess. Not really. Once we have nice widgets we can go fast. Especially since we started to do it by using things like Spec. > And before that, all tools like debugger etc. will open themselves in host > (Morphic) window? Yes. I can tell you that it was not an easy solution when I see the pain that alain got to make Bloc worked within morphic but the pay load was too high. Stef > > > > > -- > View this message in context: http://forum.world.st/Bloc-Bloc-2-and-Brick-tp4909112p4909861.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 9, 2016