- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Startup Error: SyntaxErrorNotification: Cannot store into

by Nicolai Hess

which configuration are you trying to load? 2014-09-01 18:20 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > By the way, is there any way to check which is the problematic method? > Because I failed to find it in log. > > Uko > > > On 01 Sep 2014, at 17:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 01 Sep 2014, at 17:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > This this started at 29th and crashes image while loading configuration. > Any idea whatâs wrong? > > > This means that you load code that assigns to arguments (method arguments). > The new compiler allowed it (an oversight), the old one did notâ¦. now it > is again not allowed. > > (for bock arguments, it is still allowed). > > ==== Startup Error: SyntaxErrorNotification: Cannot store intoOCSemanticError>>notify:at: > OCSemanticError>>defaultAction > [ :ex | > ex defaultAction. > ^ self compilationContext failBlock value ] in OpalCompiler>>doSemanticAnalysis in Block: [ :ex | ... > BlockClosure>>cull: > [ self exceptionHandlerBlock cull: exception ] in Context>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] > BlockClosure>>ensure: > Context>>handleSignal: > OCSemanticError(Exception)>>signal > OCASTSemanticAnalyzer>>storeIntoSpecialVariable: > OCASTSemanticAnalyzer>>lookupVariableForWrite: > OCASTSemanticAnalyzer>>visitAssignmentNode: > RBAssignmentNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > [ :each | self visitNode: each ] in OCASTSemanticAnalyzer>>visitSequenceNode: in Block: [ :each | self visitNode: each ] > OrderedCollection>>do: > OCASTSemanticAnalyzer>>visitSequenceNode: > RBSequenceNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>visitMethodNode: > RBMethodNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>analyze: > RBMethodNode>>doSemanticAnalysis > RBMethodNode>>doSemanticAnalysisInContext: > [ ast doSemanticAnalysisInContext: self compilationContext ] in OpalCompiler>>doSemanticAnalysis in Block: [ ast doSemanticAnalysisInContext: self compilatio...etc... > BlockClosure>>on:do: > OpalCompiler>>doSemanticAnalysis > [ > ast := self parse. > self doSemanticAnalysis ] in [ > [ > ast := self parse. > self doSemanticAnalysis ] > on: OCSourceCodeChanged > do: [ :notification | > self source: notification newSourceCode. > notification retry ]. > cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... > BlockClosure>>on:do: > [ > [ > ast := self parse. > self doSemanticAnalysis ] > on: OCSourceCodeChanged > do: [ :notification | > self source: notification newSourceCode. > notification retry ]. > cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ...Got startup errors: SyntaxErrorNotification: Cannot store into > > > > Cheers > Uko > > > >

Sept. 1, 2014

Re: [Pharo-dev] Spec license

by S Krish

Thx.. Here I repost, an alternative framework to wire up Morphic UI: * Implicit spec, full layout described spec and table layout based spec options: http://skrishnamachari.wordpress.com/2014/09/01/reviving-pharo-morphic-view/ Model / View / Controller hooks exists, the additional parts of the 2012 works, needs to be refactored for Pharo 3.0 and will be posted later. Specially the ValueHolder capability for all morph widgets. The framework works on 3 base and minimal support classes on top of the existing morphic framework. On Fri, Aug 29, 2014 at 1:43 PM, stepharo <stepharo(a)free.fr> wrote: > Hi skri > > Glenn is also working for a company and building an alternative to Spec to > support mobile and others. What is important is that > > - we should continue to clean and improve spec and its documentation. > - understand and push alternative solutions > - so I suggest that you should make sure that other people can use > what you are doing and continue to > push it. > > Nothing is curved on stones. > I clean Morphic regularly but I will be happy to through away all my work > if something better is coming (bloc for example). > > Stef > > > > On 28/8/14 15:21, S Krish wrote: > > > Will there be any interest in alternative declarative framework, mostly > fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et > als in 3.0 > > > http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework… > > I can push this in with the required MIT license sign off as reqd. > > More importantly, move this framework to a more refactored cleaner state > if there is a slight interest in alternatives. > > > > On Thu, Aug 28, 2014 at 5:51 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> No, it doesn't. >> >> We can improve Spec in the core, why wouldn't we be able to? >> We use it in a lot of the tools, so, there are plenty of samples and >> documentation exists. >> >> One can make sense of what's going on under the hood. >> >> Have a look at: (this is for Pharo 3.0) >> >> SpecInterpreter>>interpretASpec:selector: and ComposableModel + >> NewValueHolder. >> WindowModel is interesting to look into as well. >> >> The "famous" NewValueHolder is of interest too. >> >> >> then implementors of defaultSpec provide a lot of specs to give to the >> SpecInterpreter. >> >> Then one wants to look into the Spec-MorphicAdapters to see how Spec >> maps its view on things with underlying Morphs (e.g. check the >> MorphicDiffAdapter). >> >> We can only benefit by caring about this piece on our side, as there is >> tremendous potential in being able to change the underlying system (e.g. >> from Morphic to Bloc for example) in a piecemeal way, without breaking all >> of the tools. >> >> Phil >> >> >> On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> >>> Does it really matter? >>> If the external repository gets successfully relicensed, or Benjamin >>> publishes new improvements as a separate, GPL-licensed change set, the end >>> result is the same; >>> no improvement he makes will make its way back into the versions in Core. >>> >>> I may not know his reasons, but I can certainly respect his wish that no >>> further contributions are included in a core distribution. >>> >>> Whether to maintain/improve the current, MIT-licensed versions in Core >>> without him, or unload it all and point potential users to the external >>> library, is a separate decision. >>> Though, from previous attempts, Iâd say the chances of success of an >>> external UI-builder framework seeing actual use are rather slim. >>> >>> Cheers, >>> Henry >>> >>> On 28 Aug 2014, at 12:16 , Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> > >>> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f39… >>> > >>> > I think the license might need further improvements. >>> > I've taken a look at the commit history, and it looks >>> > to me like there is a licensing problem there. >>> > I am no lawyer, so don't know what the >>> > exact consequences of that are. >>> > >>> > The (MIT licensed) Pharo code was copied >>> > to the repository without including the copyright >>> > notice, as is required by the MIT license. >>> > >>> > For new contributions, you now have the >>> > license agreements, and with git it is >>> > perfectly clear what is new, and under >>> > the new license, and what is old, and >>> > can therefore also be used under the >>> > old license. And AFAIK MIT license >>> > is compatible with GPL. >>> > >>> > I have no clue as to the license status of >>> > changes between the copying and the >>> > relicensing. >>> > >>> > Of course copyright holding contributors can >>> > decide to relicense. The contributors to the >>> > Spec-* packages in the Pharo/Pharo30 repo >>> > seem to be: >>> > >>> > AlainPlantec >>> > AndreiChis >>> > BenComan >>> > BenjaminVanRyseghem >>> > BernardoContreras >>> > CamilloBruni >>> > CamilleTeruel >>> > ChristopheDemarey >>> > ClementBera >>> > DamienCassou >>> > ErwanDouaille >>> > EstebanLorenzano >>> > GabrielOmarCotelli >>> > GuillermoPolito >>> > HernanMoralesDurand >>> > IgorStasenko >>> > LeoGassman >>> > MarcusDenker >>> > MartinDias >>> > NicolaiHess >>> > PabloHerrero >>> > PavelKrivanek >>> > PhilippeBack >>> > RobertoMinelli >>> > SeanDeNigris >>> > SebastianTleye >>> > StephaneDucasse >>> > SvenVanCaekenberghe >>> > TorstenBergmann >>> > TudorGirba >>> > YuriyTymchuk >>> > >>> > Stephan >>> > >>> > >>> > >>> > >>> >>> >> > >

Sept. 1, 2014

Re: [Pharo-dev] Startup Error: SyntaxErrorNotification: Cannot store into

by Yuriy Tymchuk

By the way, is there any way to check which is the problematic method? Because I failed to find it in log. Uko On 01 Sep 2014, at 17:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 01 Sep 2014, at 17:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> This this started at 29th and crashes image while loading configuration. Any idea whatâs wrong? >> > > This means that you load code that assigns to arguments (method arguments). > The new compiler allowed it (an oversight), the old one did notâ¦. now it is again not allowed. > > (for bock arguments, it is still allowed). > >> ==== Startup Error: SyntaxErrorNotification: Cannot store into >> OCSemanticError>>notify:at: >> OCSemanticError>>defaultAction >> [ :ex | >> ex defaultAction. >> ^ self compilationContext failBlock value ] in OpalCompiler>>doSemanticAnalysis in Block: [ :ex | ... >> BlockClosure>>cull: >> [ self exceptionHandlerBlock cull: exception ] in Context>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] >> BlockClosure>>ensure: >> Context>>handleSignal: >> OCSemanticError(Exception)>>signal >> OCASTSemanticAnalyzer>>storeIntoSpecialVariable: >> OCASTSemanticAnalyzer>>lookupVariableForWrite: >> OCASTSemanticAnalyzer>>visitAssignmentNode: >> RBAssignmentNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> [ :each | self visitNode: each ] in OCASTSemanticAnalyzer>>visitSequenceNode: in Block: [ :each | self visitNode: each ] >> OrderedCollection>>do: >> OCASTSemanticAnalyzer>>visitSequenceNode: >> RBSequenceNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>visitMethodNode: >> RBMethodNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>analyze: >> RBMethodNode>>doSemanticAnalysis >> RBMethodNode>>doSemanticAnalysisInContext: >> [ ast doSemanticAnalysisInContext: self compilationContext ] in OpalCompiler>>doSemanticAnalysis in Block: [ ast doSemanticAnalysisInContext: self compilatio...etc... >> BlockClosure>>on:do: >> OpalCompiler>>doSemanticAnalysis >> [ >> ast := self parse. >> self doSemanticAnalysis ] in [ >> [ >> ast := self parse. >> self doSemanticAnalysis ] >> on: OCSourceCodeChanged >> do: [ :notification | >> self source: notification newSourceCode. >> notification retry ]. >> cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... >> BlockClosure>>on:do: >> [ >> [ >> ast := self parse. >> self doSemanticAnalysis ] >> on: OCSourceCodeChanged >> do: [ :notification | >> self source: notification newSourceCode. >> notification retry ]. >> cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... >> Got startup errors: >> SyntaxErrorNotification: Cannot store into >> >> >> Cheers >> Uko >

Sept. 1, 2014

Re: [Pharo-dev] Startup Error: SyntaxErrorNotification: Cannot store into

by Yuriy Tymchuk

Thanks Marcus! On 01 Sep 2014, at 17:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 01 Sep 2014, at 17:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> This this started at 29th and crashes image while loading configuration. Any idea whatâs wrong? >> > > This means that you load code that assigns to arguments (method arguments). > The new compiler allowed it (an oversight), the old one did notâ¦. now it is again not allowed. > > (for bock arguments, it is still allowed). > >> ==== Startup Error: SyntaxErrorNotification: Cannot store into >> OCSemanticError>>notify:at: >> OCSemanticError>>defaultAction >> [ :ex | >> ex defaultAction. >> ^ self compilationContext failBlock value ] in OpalCompiler>>doSemanticAnalysis in Block: [ :ex | ... >> BlockClosure>>cull: >> [ self exceptionHandlerBlock cull: exception ] in Context>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] >> BlockClosure>>ensure: >> Context>>handleSignal: >> OCSemanticError(Exception)>>signal >> OCASTSemanticAnalyzer>>storeIntoSpecialVariable: >> OCASTSemanticAnalyzer>>lookupVariableForWrite: >> OCASTSemanticAnalyzer>>visitAssignmentNode: >> RBAssignmentNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> [ :each | self visitNode: each ] in OCASTSemanticAnalyzer>>visitSequenceNode: in Block: [ :each | self visitNode: each ] >> OrderedCollection>>do: >> OCASTSemanticAnalyzer>>visitSequenceNode: >> RBSequenceNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>visitMethodNode: >> RBMethodNode>>acceptVisitor: >> OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>analyze: >> RBMethodNode>>doSemanticAnalysis >> RBMethodNode>>doSemanticAnalysisInContext: >> [ ast doSemanticAnalysisInContext: self compilationContext ] in OpalCompiler>>doSemanticAnalysis in Block: [ ast doSemanticAnalysisInContext: self compilatio...etc... >> BlockClosure>>on:do: >> OpalCompiler>>doSemanticAnalysis >> [ >> ast := self parse. >> self doSemanticAnalysis ] in [ >> [ >> ast := self parse. >> self doSemanticAnalysis ] >> on: OCSourceCodeChanged >> do: [ :notification | >> self source: notification newSourceCode. >> notification retry ]. >> cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... >> BlockClosure>>on:do: >> [ >> [ >> ast := self parse. >> self doSemanticAnalysis ] >> on: OCSourceCodeChanged >> do: [ :notification | >> self source: notification newSourceCode. >> notification retry ]. >> cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... >> Got startup errors: >> SyntaxErrorNotification: Cannot store into >> >> >> Cheers >> Uko >

Sept. 1, 2014

Re: [Pharo-dev] Startup Error: SyntaxErrorNotification: Cannot store into

by Marcus Denker

On 01 Sep 2014, at 17:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > This this started at 29th and crashes image while loading configuration. Any idea whatâs wrong? > This means that you load code that assigns to arguments (method arguments). The new compiler allowed it (an oversight), the old one did notâ¦. now it is again not allowed. (for bock arguments, it is still allowed). > ==== Startup Error: SyntaxErrorNotification: Cannot store into > OCSemanticError>>notify:at: > OCSemanticError>>defaultAction > [ :ex | > ex defaultAction. > ^ self compilationContext failBlock value ] in OpalCompiler>>doSemanticAnalysis in Block: [ :ex | ... > BlockClosure>>cull: > [ self exceptionHandlerBlock cull: exception ] in Context>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] > BlockClosure>>ensure: > Context>>handleSignal: > OCSemanticError(Exception)>>signal > OCASTSemanticAnalyzer>>storeIntoSpecialVariable: > OCASTSemanticAnalyzer>>lookupVariableForWrite: > OCASTSemanticAnalyzer>>visitAssignmentNode: > RBAssignmentNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > [ :each | self visitNode: each ] in OCASTSemanticAnalyzer>>visitSequenceNode: in Block: [ :each | self visitNode: each ] > OrderedCollection>>do: > OCASTSemanticAnalyzer>>visitSequenceNode: > RBSequenceNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>visitMethodNode: > RBMethodNode>>acceptVisitor: > OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: > OCASTSemanticAnalyzer>>analyze: > RBMethodNode>>doSemanticAnalysis > RBMethodNode>>doSemanticAnalysisInContext: > [ ast doSemanticAnalysisInContext: self compilationContext ] in OpalCompiler>>doSemanticAnalysis in Block: [ ast doSemanticAnalysisInContext: self compilatio...etc... > BlockClosure>>on:do: > OpalCompiler>>doSemanticAnalysis > [ > ast := self parse. > self doSemanticAnalysis ] in [ > [ > ast := self parse. > self doSemanticAnalysis ] > on: OCSourceCodeChanged > do: [ :notification | > self source: notification newSourceCode. > notification retry ]. > cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... > BlockClosure>>on:do: > [ > [ > ast := self parse. > self doSemanticAnalysis ] > on: OCSourceCodeChanged > do: [ :notification | > self source: notification newSourceCode. > notification retry ]. > cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... > Got startup errors: > SyntaxErrorNotification: Cannot store into > > > Cheers > Uko

Sept. 1, 2014

Startup Error: SyntaxErrorNotification: Cannot store into

by Yuriy Tymchuk

This this started at 29th and crashes image while loading configuration. Any idea whatâs wrong? ==== Startup Error: SyntaxErrorNotification: Cannot store into OCSemanticError>>notify:at: OCSemanticError>>defaultAction [ :ex | ex defaultAction. ^ self compilationContext failBlock value ] in OpalCompiler>>doSemanticAnalysis in Block: [ :ex | ... BlockClosure>>cull: [ self exceptionHandlerBlock cull: exception ] in Context>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: Context>>handleSignal: OCSemanticError(Exception)>>signal OCASTSemanticAnalyzer>>storeIntoSpecialVariable: OCASTSemanticAnalyzer>>lookupVariableForWrite: OCASTSemanticAnalyzer>>visitAssignmentNode: RBAssignmentNode>>acceptVisitor: OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: [ :each | self visitNode: each ] in OCASTSemanticAnalyzer>>visitSequenceNode: in Block: [ :each | self visitNode: each ] OrderedCollection>>do: OCASTSemanticAnalyzer>>visitSequenceNode: RBSequenceNode>>acceptVisitor: OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTSemanticAnalyzer>>visitMethodNode: RBMethodNode>>acceptVisitor: OCASTSemanticAnalyzer(RBProgramNodeVisitor)>>visitNode: OCASTSemanticAnalyzer>>analyze: RBMethodNode>>doSemanticAnalysis RBMethodNode>>doSemanticAnalysisInContext: [ ast doSemanticAnalysisInContext: self compilationContext ] in OpalCompiler>>doSemanticAnalysis in Block: [ ast doSemanticAnalysisInContext: self compilatio...etc... BlockClosure>>on:do: OpalCompiler>>doSemanticAnalysis [ ast := self parse. self doSemanticAnalysis ] in [ [ ast := self parse. self doSemanticAnalysis ] on: OCSourceCodeChanged do: [ :notification | self source: notification newSourceCode. notification retry ]. cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... BlockClosure>>on:do: [ [ ast := self parse. self doSemanticAnalysis ] on: OCSourceCodeChanged do: [ :notification | self source: notification newSourceCode. notification retry ]. cm := ast generate: self compilationContext compiledMethodTrailer ] in OpalCompiler>>compile in Block: [ ... Got startup errors: SyntaxErrorNotification: Cannot store into Cheers Uko

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by kilon alios

Oh this is great, I am so glad I was wrong :) Looks like the design of Spec is much better than I first thought. How do I change the color of the button I tried using the color: message from ButtonModel superclass AbstractWidgetModel but button remains grey. On Mon, Sep 1, 2014 at 4:15 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Err..., not really longer nor lots of methods. > > ButtonModel new > label: 'Click me'; > whenActionPerformedDo: [Transcript show: 'Clicked!' ]; > openWithSpec. > > Bear in mind that Spec is based on models, not actual "Morphs". > The ComposableModel idea is key here. > > HTH > > > Phil > > > On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> Lets take a very simple example of creating a UI that contains one very >> simple button in Morphic I would do: >> >> button := PluggableButtonMorph new. >> button label: 'Button'. >> button openInWindow . >> >> According to Spec to do the same I would need several methods just for >> initialization and a separate class to host these methods. >> >> >> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… >> >> I would need initializeWidgets , defaultSpec , list and title . Unless I >> am reading the documentation wrong. >> >> >> On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> >>> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>> Personally there are two thing I dont like about Spec >>>> >>>> a) There is quite a lot of setup just to start adding things together >>>> making quite verbose for small GUIs. It may be just my lack of >>>> understanding but I find Morphic much easier to use. >>>> >>> >>> Can you give me an example of this setup for a small GUI? The examples >>> I have seen so far only use some lines of code in #defaultSpec and some >>> lines of code >>> for wiring up the different models (like onSelectedDo, onChangedDo, ...) >>> All of that are things you would do anyway. >>> >>> nicolai >>> >>> >>> >>>> >>>> b) I have a deep dislike about the use of pragmas. I know they are >>>> useful for primitives that cant be pure smalltalk objects like for example >>>> Nativeboost but I still feel they brake the uniformity of smalltalk syntax >>>> at least in my eyes. >>>> >>>> On the other hand having something that can quickly produce guis is >>>> essential. But personal I prefer lego-like approaches which is what Morphic >>>> uses. As side note I think designing GUI via code is a bad idea, at least >>>> in my eyes, we need a designer for that, afterall most of the powerful IDEs >>>> out there have GUI designers. Nonetheless wishful thinking is not >>>> productive , Spec is here, it is certainly helpful and I hope it continues >>>> to evolve and improve. >>>> >>>> >>>> On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be >>>> > wrote: >>>> >>>>> When one looks at the implementers of "defaultSpec" (lots of Adapters, >>>>> tools), I find it more understandable to figure out how a tool is laid out. >>>>> >>>>> How to follow what messages are sent around, err... much less >>>>> understandable indeed (So, sharing Sean's pain). >>>>> >>>>> Of course, this is different from inspecting morphs. But it shouldn't >>>>> be so. If Morphs where isofunctional with the Adapters, it would be much >>>>> more regular. >>>>> >>>>> It is glaring that the Morphs all have their own little view of the >>>>> world with no unified set of protocols, which isn't helping. >>>>> >>>>> An example: MorphicRadioButtonAdapter >>>>> >>>>> defaultSpec >>>>> <spec> >>>>> ^ {#CheckboxMorph. >>>>> #on:selected:changeSelected:. #model. #state. #state:. >>>>> #label:. { #model. #label }. >>>>> #labelClickable:. { #model. #labelClickable}. >>>>> #beRadioButton. >>>>> #hResizing:. #shrinkWrap. >>>>> #vResizing:. #shrinkWrap. >>>>> #setBalloonText:. #(model help). >>>>> #dragEnabled:. #(model dragEnabled). >>>>> #dropEnabled:. #(model dropEnabled). >>>>> #dragEnabled:. #(model dragEnabled). >>>>> #dropEnabled:. #(model dropEnabled). >>>>> "#borderWidth:. #(model borderWidth). >>>>> #borderColor:. #(model borderColor)"} >>>>> >>>>> A halo that would outline the SpecLayout bits and pieces would go a >>>>> long way in helping people figure out what's going on. A project in itself. >>>>> >>>>> Now, can we both have a declarative UI and an easy to debug UI? As the >>>>> declarative things has its own interpreter and engine? >>>>> >>>>> Phil >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>> >>>>>> +1 to both of you :) >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>>> Hi sean >>>>>>> >>>>>>> >>>>>>> I've been mulling this over for a while, and since we've been having >>>>>>>> conversations about Spec's place in our future... >>>>>>>> >>>>>>> :) >>>>>>> Good. This is important that everybody express itself. >>>>>>> >>>>>>> >>>>>>>> DISCLAIMER: this is a visceral experience I've been having over a >>>>>>>> long >>>>>>>> period of time, so it may not be factually "true" or current, but I >>>>>>>> present >>>>>>>> it as a contribution, if only by someone saying "you're full of crap >>>>>>>> because..." and we all learn something. >>>>>>>> >>>>>>>> The purpose of Spec as I understand it is to both come up with a >>>>>>>> nice >>>>>>>> streamlined UI API, and to make multiple targets (e.g. Morphic, >>>>>>>> html) >>>>>>>> possible with the same codebase. These are both important goals. >>>>>>>> And it >>>>>>>> seems we've made some progress at least in the first case. I >>>>>>>> definitely >>>>>>>> enjoy working with Spec's API far more that e.g. PolyMorph. >>>>>>>> >>>>>>>> Spec could be a very valuable application-level tool. If I want to >>>>>>>> write a >>>>>>>> business application, I can write once via a nice API and deploy >>>>>>>> "anywhere". >>>>>>>> Life is good. >>>>>>>> >>>>>>>> My discomfort is with making *all* our core tools Spec-based. >>>>>>>> >>>>>>> >>>>>>> I agree this is why I started to write some little tool to be able >>>>>>> to browse the system >>>>>>> when Spec is shaking. >>>>>>> >>>>>>> Now when you see the code of the old browser this is not nice either. >>>>>>> So we will see and learn. But I can tell you that nothing is curved >>>>>>> in stone. >>>>>>> We will introduce GT but again you will get the same because GT is a >>>>>>> frameworks. >>>>>>> >>>>>>> >>>>>>> While it is great from an "eating our own dog food perspective", >>>>>>>> one of the great >>>>>>>> principles of Morphic is exploration and discoverability. Many >>>>>>>> times before >>>>>>>> Spec I was able to poke around a tool, figure out how it worked, >>>>>>>> and apply >>>>>>>> that lesson to my own UI. However, with Spec I find it extremely >>>>>>>> difficult >>>>>>>> to figure out WTH is going on. Parsing of arrays of symbols seems >>>>>>>> to have >>>>>>>> replaced Smalltalk code, and each field/model piece of a Spec UI >>>>>>>> seems to be >>>>>>>> buried behind multiple ValueHolder/Adapter/whatever levels. >>>>>>>> Granted, now >>>>>>>> that we have e.g. specialized inspectors, we might be able to >>>>>>>> alleviate >>>>>>>> this. >>>>>>>> >>>>>>> >>>>>>> We should iterate on it. >>>>>>> May be another framework will be better in the future >>>>>>> >>>>>>> >>>>>>>> My 2c. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Cheers, >>>>>>>> Sean >>>>>>>> -- >>>>>>>> View this message in context: http://forum.world.st/When- >>>>>>>> all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html >>>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>>>> Nabble.com. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>> >>> >> >

Sept. 1, 2014

pharo4 ci build queue now has download links on top

by Marcus Denker

Hi, I added download links on top of https://ci.inria.fr/pharo/ (they download from files.pharo.org) Marcus

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by Sven Van Caekenberghe

On 01 Sep 2014, at 15:15, phil(a)highoctane.be wrote: > Err..., not really longer nor lots of methods. +1 It can't get much shorter than this... > ButtonModel new > label: 'Click me'; > whenActionPerformedDo: [Transcript show: 'Clicked!' ]; > openWithSpec. > > Bear in mind that Spec is based on models, not actual "Morphs". > The ComposableModel idea is key here. > > HTH > > > Phil > > > On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Lets take a very simple example of creating a UI that contains one very simple button in Morphic I would do: > > button := PluggableButtonMorph new. > button label: 'Button'. > button openInWindow . > > According to Spec to do the same I would need several methods just for initialization and a separate class to host these methods. > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > I would need initializeWidgets , defaultSpec , list and title . Unless I am reading the documentation wrong. > > > On Mon, Sep 1, 2014 at 12:26 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > Personally there are two thing I dont like about Spec > > a) There is quite a lot of setup just to start adding things together making quite verbose for small GUIs. It may be just my lack of understanding but I find Morphic much easier to use. > > Can you give me an example of this setup for a small GUI? The examples I have seen so far only use some lines of code in #defaultSpec and some lines of code > for wiring up the different models (like onSelectedDo, onChangedDo, ...) All of that are things you would do anyway. > > nicolai > > > > b) I have a deep dislike about the use of pragmas. I know they are useful for primitives that cant be pure smalltalk objects like for example Nativeboost but I still feel they brake the uniformity of smalltalk syntax at least in my eyes. > > On the other hand having something that can quickly produce guis is essential. But personal I prefer lego-like approaches which is what Morphic uses. As side note I think designing GUI via code is a bad idea, at least in my eyes, we need a designer for that, afterall most of the powerful IDEs out there have GUI designers. Nonetheless wishful thinking is not productive , Spec is here, it is certainly helpful and I hope it continues to evolve and improve. > > > On Mon, Sep 1, 2014 at 10:32 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > When one looks at the implementers of "defaultSpec" (lots of Adapters, tools), I find it more understandable to figure out how a tool is laid out. > > How to follow what messages are sent around, err... much less understandable indeed (So, sharing Sean's pain). > > Of course, this is different from inspecting morphs. But it shouldn't be so. If Morphs where isofunctional with the Adapters, it would be much more regular. > > It is glaring that the Morphs all have their own little view of the world with no unified set of protocols, which isn't helping. > > An example: MorphicRadioButtonAdapter > > defaultSpec > <spec> > ^ {#CheckboxMorph. > #on:selected:changeSelected:. #model. #state. #state:. > #label:. { #model. #label }. > #labelClickable:. { #model. #labelClickable}. > #beRadioButton. > #hResizing:. #shrinkWrap. > #vResizing:. #shrinkWrap. > #setBalloonText:. #(model help). > #dragEnabled:. #(model dragEnabled). > #dropEnabled:. #(model dropEnabled). > #dragEnabled:. #(model dragEnabled). > #dropEnabled:. #(model dropEnabled). > "#borderWidth:. #(model borderWidth). > #borderColor:. #(model borderColor)"} > > A halo that would outline the SpecLayout bits and pieces would go a long way in helping people figure out what's going on. A project in itself. > > Now, can we both have a declarative UI and an easy to debug UI? As the declarative things has its own interpreter and engine? > > Phil > > > > > On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > +1 to both of you :) > > Doru > > > On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> wrote: > Hi sean > > > I've been mulling this over for a while, and since we've been having > conversations about Spec's place in our future... > :) > Good. This is important that everybody express itself. > > > DISCLAIMER: this is a visceral experience I've been having over a long > period of time, so it may not be factually "true" or current, but I present > it as a contribution, if only by someone saying "you're full of crap > because..." and we all learn something. > > The purpose of Spec as I understand it is to both come up with a nice > streamlined UI API, and to make multiple targets (e.g. Morphic, html) > possible with the same codebase. These are both important goals. And it > seems we've made some progress at least in the first case. I definitely > enjoy working with Spec's API far more that e.g. PolyMorph. > > Spec could be a very valuable application-level tool. If I want to write a > business application, I can write once via a nice API and deploy "anywhere". > Life is good. > > My discomfort is with making *all* our core tools Spec-based. > > I agree this is why I started to write some little tool to be able to browse the system > when Spec is shaking. > > Now when you see the code of the old browser this is not nice either. > So we will see and learn. But I can tell you that nothing is curved in stone. > We will introduce GT but again you will get the same because GT is a frameworks. > > > While it is great from an "eating our own dog food perspective", one of the great > principles of Morphic is exploration and discoverability. Many times before > Spec I was able to poke around a tool, figure out how it worked, and apply > that lesson to my own UI. However, with Spec I find it extremely difficult > to figure out WTH is going on. Parsing of arrays of symbols seems to have > replaced Smalltalk code, and each field/model piece of a Spec UI seems to be > buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now > that we have e.g. specialized inspectors, we might be able to alleviate > this. > > We should iterate on it. > May be another framework will be better in the future > > > My 2c. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nai… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > >

Sept. 1, 2014

Re: [Pharo-dev] Experiments in Code Typography

by Stephan Eggermont

The performance of this can easily be made fast enough. I've used Think Pascal on a 25 MHz 68LC040 and that was fast enough for normal sized methods. 20 years of hardware improvement should be enough. Squeak was not fast enough on that machine, b.t.w. Stephan

Sept. 1, 2014