- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Pillar 1.1.0 released

by Johan Brichau

Hi Cyril, You are right. Itâs better to just fix the version of Pillar for Pier and that works just fine for me now. We will see what happens later if someone has the time to look at Pier. cheers Johan > On 13 Sep 2015, at 12:22, Ferlicot Delbecque Cyril <c.ferlicot-delbecque(a)etudiant.univ-lille1.fr> wrote: > > Le 13/09/2015 10:28, Johan Brichau a Ã©crit : >> Hi, >> >> I just noticed that in the most recent version of Pillar, the instvar #embedded was removed from PRReference >> This breaks Pierâ¦ though right before this change I could make Pier3 work with Pillar just fine. >> >> The embedded var is used to specify that component references are to be embedded in the page. There are more components than Figures in Pier. >> > > Hi Johan, > > We removed that because since Figures are not link anymore we do not > need it. If the reference is a link, it is not embedded, else it is. We > plan latter to have more embedded item than Figures, maybe we can just > and a class between Reference and Figure (PREmbeddedReferences). > With that we do not need the ivar. > > But since Pier3 doesn't evolve anymore I proposed to someone to freeze > the version of Pillar needed for the stable version of Pier3. But I > didn't get an answer. > > -- > Cyril > >> I am just trying to use and work with Pier3 for Seaside book and website, so it would be great if you can consider adding the embedded variable again. >> >> thanks guys! >> Johan >> >> ps: email me directly, since I might miss replies via the mailinglist. >> >> > >

Sept. 14, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 14, 2015

[pharo-project/pharo-core] 9ea7a8: 50321

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ea7a8e991e81e8a4e60d5b9ac0c7a96dba730b6 https://github.com/pharo-project/pharo-core/commit/9ea7a8e991e81e8a4e60d5b9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-14 (Mon, 14 Sep 2015) Changed paths: M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterBlockSequence.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testFailingDoubleRWInstead.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testFailingDoubleRWInsteadSimplified.st M Reflectivity-Tests.package/ReflectivityExamples.class/definition.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleLazyInit.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkBefore_.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkInstead_.st M Reflectivity.package/RFNewValueReification.class/instance/generate/preamble_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50320.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50321.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50320.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50321.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50321 16559 fix for #instead links https://pharo.fogbugz.com/f/cases/16559 http://files.pharo.org/image/50/50321.zip

Sept. 14, 2015

Re: [Pharo-dev] Catalog does not update to include MessageFlowBrowser

by Esteban Lorenzano

crap. I will check it tomorrow. there is a broken configuration there who is messing the full list :( Esteban > On 11 Sep 2015, at 21:04, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Esteban, > > Unfortunately it is now completely broken, the JSON is not returned anymore: > > http://catalog.pharo.org/catalog/json > > gives > > MessageNotUnderstood: receiver of "repositoryUrl" is nil > > Can you have a look again? Thanks! > > Regards > Torsten > > >> Gesendet: Freitag, 11. September 2015 um 19:03 Uhr >> Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> An: "Torsten Bergmann" <astares(a)gmx.de> >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: Catalog does not update to include MessageFlowBrowser >> >> >>> On 11 Sep 2015, at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 11 Sep 2015, at 16:29, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> Hi, >>>> >>>> ConfigurationOfMessageFlowBrowser is in http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo50 >>>> for a week now but still not included in http://catalog.pharo.org >>>> >>>> According to the description there is a daily catalog job - but so far no results. It is not >>>> included although the config includes the necessary catalog methods. >>>> >>>> - Is MetaRepoForPharo50 already recognized? >>>> - Is it possible to "manually" trigger the catalog generation in case a new project is done? >>>> >>>> Anyone able to look into this? >>> >>> Iâll check the logs. >> >> fixed. >> something went wrong when updating FFI (my fault :P) and then everything stop working. Of course there is a log who tells me that something went wrong, but I forget to check them :D >> >> cheers, >> >>> >>> Esteban >>> >>>> >>>> Thx >>>> T. >>> >> >>

Sept. 13, 2015

Re: [Pharo-dev] [Pharo-users] Pillar 1.1.0 released

by Damien Cassou

Hi Johan, Ferlicot Delbecque Cyril <c.ferlicot-delbecque(a)etudiant.univ-lille1.fr> writes: > Le 13/09/2015 10:28, Johan Brichau a Ã©crit : >> I just noticed that in the most recent version of Pillar, the instvar >> #embedded was removed from PRReference This breaks Pierâ¦ though right >> before this change I could make Pier3 work with Pillar just fine. >> >> The embedded var is used to specify that component references are to >> be embedded in the page. There are more components than Figures in >> Pier. >> > We removed that because since Figures are not link anymore we do not > need it. If the reference is a link, it is not embedded, else it is. > We plan latter to have more embedded item than Figures, maybe we can > just and a class between Reference and Figure (PREmbeddedReferences). > With that we do not need the ivar. > > But since Pier3 doesn't evolve anymore I proposed to someone to freeze > the version of Pillar needed for the stable version of Pier3. But I > didn't get an answer. I totally agree with Cyril. We can't limit the development of a dependency forever because a dependent has more or less stopped evolving. Before, a figure was a link with embedded = true. This was silly because each visitor had to do something specific for figures (e.g., in html you want a <img>, in latex you want \includegraphics). This is totally different from what is expected of a link. Now a figure is not a link anymore, it is a reference. There can be multiple kinds of references but the embedded parameter what not of any use for Pillar anymore. So we decided to remove it, knowing that Pier used it to embed Pier components. So, Pier users have 2 solutions now: - either adapt Pier's configuration so that it uses an old version of Pillar; - or adapt Pier's code to rely on the new Pillar. This might require some adaptations to Pillar which we can discuss. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 13, 2015

Fwd: Re: [Pharo-users] Pillar 1.1.0 released

by Ferlicot D. Cyril

Le 13/09/2015 10:28, Johan Brichau a Ã©crit : > Hi, > > I just noticed that in the most recent version of Pillar, the instvar #embedded was removed from PRReference > This breaks Pierâ¦ though right before this change I could make Pier3 work with Pillar just fine. > > The embedded var is used to specify that component references are to be embedded in the page. There are more components than Figures in Pier. > Hi Johan, We removed that because since Figures are not link anymore we do not need it. If the reference is a link, it is not embedded, else it is. We plan latter to have more embedded item than Figures, maybe we can just and a class between Reference and Figure (PREmbeddedReferences). With that we do not need the ivar. But since Pier3 doesn't evolve anymore I proposed to someone to freeze the version of Pillar needed for the stable version of Pier3. But I didn't get an answer. -- Cyril > I am just trying to use and work with Pier3 for Seaside book and website, so it would be great if you can consider adding the embedded variable again. > > thanks guys! > Johan > > ps: email me directly, since I might miss replies via the mailinglist. > >

Sept. 13, 2015

Re: [Pharo-dev] Annotating instance variables

by Marcus Denker

> > Could you expand on how ClassVars and Globals are slot-like but not slots. > I mean in the sense that there are first class variables where I can make my own by subclassing. There is an object describing the var. For Global/Class variable this is the âbindingâ from the dictionary where they live. For class vars, in addition we have a syntax (same as slots) to declare in a class that you want to use such a âself madeâ variable. In the image there is an example (not a very useful one, more for testing the mechanism: LiteralVariable subclass: #ExampleClassVariable slots: { #state } classVariables: { } category: 'Slot-Examples' with methods: read ^state write: anObject state := anObject If you make a class with such a class var: Object subclass: #MyClass slots: { } classVariables: { #TT => ExampleClassVariable } category: âDemo' it compiles e.g. for a read: tt ^TT 21 <40> pushLit: global 22 <D1> send: read 23 <7C> returnTop > > Also, would it be fair to say that for most programming languages > variables are "dead", and it might be good to distinguish the > "liveness" of slots. Further, there may be a particular class of > early adopters who upon hearing the term "slot" that they don't know, > will be compelled to investigate > > btw, can temporary variables be Slots? Temporaries have objects describing them (created on demand). You can annotate them (property interface), when you do that, the var is kept and you get this instance. There is a reflective API (#readInContext: and #write:InContext:). It would be possible to continue the implementation to allow subclassing (and have the compiler delegated code generation to them). This can be done as soon as we have the need. I wonder if there is a use case? What is not that easy is the syntaxâ¦ of course one could have something like | #a => MyTemp . #b => MyTemp | but that is ugly. And a change to the syntax, which I want to avoid. Maybe a pragma? <tempClass: MyTemp forTemporaryNamed: #a> I think this should be use-case drivenâ¦ Marcus

Sept. 13, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Henrik Johansen

> On 13 Sep 2015, at 12:15 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I donât care about other dialects. Iâm not changing anything now. Iâm just saying: âhere is a limitation, maybe it can be solved in this wayâ. Maybe there is a real reason for that. But nobody answers. > > Uko And I'm telling you, it's not the limitation that's wrong, it's the use. If you want a hierarchy like: SelectionChanged ClassChanged ProtocolChanged MethodChanged to work, you use double dispatch. myThing when: SelectionChanged do: [:ann ann handleBy: self ] ClassChanged >> #handleBy: aResponder aResponder classChanged: ann ProtocolChanged aResponder protoclChanged: ann etc. You do *not* respond to each specifically when ClassChanged do: [:ann self classChanged: ann] Cheers, Henry

Sept. 13, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Henrik Johansen

> On 13 Sep 2015, at 12:06 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >>> >>> On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >>> >>>> >>>> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>> >>>>> >>>>> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>>> >>>>> >>>>> >>>>> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>>>> Hi, >>>>> >>>>> as NautilusMethodSelected contains also an information about protocol, class, package; >>>>> NautilusProtocolSelected contains an information about class and package; >>>>> . >>>>> . >>>>> . >>>>> >>>>> Iâve inherited NautilusClassSelected from NautilusPackageSelected and NautilusProtocolSelected from NautilusClassSelectedâ¦ to remove duplication. But as announcement subscription also includes itâs subclasses, if you subscribe to NautilusPackageSelected, you end up receiving also NautilusClassSelected, NautilusProtocolSelected and NautilusMethodSelected. >>>>> >>>>> What is a good way to resolve this (I can simply separate all the classes, but maybe there is something important from conceptual point of view)? >>>>> >>>>> I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of >>>>> subannouncements (WindowClosed/WindowOpened â¦) >>>> >>>> I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. >>> >>> That would be setting yourself up for a heap of duplicates. >>> By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of eachâ¦ >> >> My point was that maybe instead of making an implicit inheritance subscription we should make it explicit. So if you want to subscribe only to WindowAnnouncement and not to its subclasses, you can do that. If you wan to subscribe to the hierarchy you can do âWindowAnnouncement withAllSubclassesâ. Again, this is just an idea and I donât know how it impacts performance or some other things. I just see a limitation now that I cannot subscribe only to a class ignoring it subclasses without doing a check later. >> >> Uko > > If you do, you majorly break compatability with how announcements work in all other dialects. > So in that case, better rename the framework at the same time. > > Cheers, > Henry A bit harsh, perhaps. All frameworks will have considerations built into their designs. For Announcements, a few of those are: - Subscription limits are unconstrained. Which means it is *possible* for one recipient to receive multiple copies of the same announcement if that's what needed, and left to the user to avoid if not. - The Announcement class hierarchy is used to group announcements that should be delivered. When your use don't conform to those, it's usually better to rewrite your own code in consideration of how the framework works, rather than change the framework. Cheers, Henry P.S. Weren't Traits invented to reduce code duplication across classes?

Sept. 13, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Yuriy Tymchuk

I donât care about other dialects. Iâm not changing anything now. Iâm just saying: âhere is a limitation, maybe it can be solved in this wayâ. Maybe there is a real reason for that. But nobody answers. Uko > On 13 Sep 2015, at 12:06, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >>> >>> On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >>> >>>> >>>> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>> >>>>> >>>>> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>>> >>>>> >>>>> >>>>> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>>>> Hi, >>>>> >>>>> as NautilusMethodSelected contains also an information about protocol, class, package; >>>>> NautilusProtocolSelected contains an information about class and package; >>>>> . >>>>> . >>>>> . >>>>> >>>>> Iâve inherited NautilusClassSelected from NautilusPackageSelected and NautilusProtocolSelected from NautilusClassSelectedâ¦ to remove duplication. But as announcement subscription also includes itâs subclasses, if you subscribe to NautilusPackageSelected, you end up receiving also NautilusClassSelected, NautilusProtocolSelected and NautilusMethodSelected. >>>>> >>>>> What is a good way to resolve this (I can simply separate all the classes, but maybe there is something important from conceptual point of view)? >>>>> >>>>> I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of >>>>> subannouncements (WindowClosed/WindowOpened â¦) >>>> >>>> I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. >>> >>> That would be setting yourself up for a heap of duplicates. >>> By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of eachâ¦ >> >> My point was that maybe instead of making an implicit inheritance subscription we should make it explicit. So if you want to subscribe only to WindowAnnouncement and not to its subclasses, you can do that. If you wan to subscribe to the hierarchy you can do âWindowAnnouncement withAllSubclassesâ. Again, this is just an idea and I donât know how it impacts performance or some other things. I just see a limitation now that I cannot subscribe only to a class ignoring it subclasses without doing a check later. >> >> Uko > > If you do, you majorly break compatability with how announcements work in all other dialects. > So in that case, better rename the framework at the same time. > > Cheers, > Henry

Sept. 13, 2015