- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Sven Van Caekenberghe

> On 13 Feb 2018, at 09:51, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: >> Formulating the question helped me to find the solution after I posted: >> >> index >> ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello >> wo rld') ] >> >> :) >> > > Hi! > > Just for the record, > > There is a Pharo mustache implementation. > (https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l…) > Also, it is possible with Seaside to render raw html via the method #html: There is also ZnHtmlOutputStream (a simple helper class) for generating syntactically correct HTML. >> cheers, >> Siemen >> >> >> On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader <siemenbaader(a)gmail.com> >> wrote: >>> >>> Hi all, >>> >>> is there a way to render raw HTML from Iliad widgets, or perhaps mustache >>> templates? I'm interested in not using the builders always because I use an >>> external web editor that generates plain HTML and that has some advantages >>> in my workflow. >>> >>> Is it possible do it with Seaside & Reef instead? >>> >>> -- Siemen >> >> > > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Steven Costiou

Hi, i think just doing e html: '<some html>' also works. Elements should not be instantiated like you do, there is an interface for each element that can be called on "e". e div, e html:, e h1:, etc. The interface instantiates the right class behind. You can find this somewhere in the core classes, but i don"t remember where and i can't check right now. Steven. Le 2018-02-13 09:20, Siemen Baader a Ã©crit : > Formulating the question helped me to find the solution after I posted: > > index > ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello wo rld') ] > > :) > > cheers, > Siemen > > On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > >> Hi all, >> >> is there a way to render raw HTML from Iliad widgets, or perhaps mustache templates? I'm interested in not using the builders always because I use an external web editor that generates plain HTML and that has some advantages in my workflow. >> >> Is it possible do it with Seaside & Reef instead? >> -- Siemen -- kloum.io

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Denis Kudriashov

2018-02-13 10:25 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > Sometimes I think we should treat globals more in a âlate boundâ fashion. > > e.g. right now we say that âUndeclaredâ vars are to be avoided at any cost. > > But we could just treat them like we treat messages that are send that do > not exist. > > Forcing â#classNamed: â for all unknown globals is a bit similar than > forcing to use âperform:â for > all unknown selectors. > > e.g. why have Smalltalk at: #SomeClass and react to it if you could > instead reason on the fact that > a variable is not bound (yet). > > SomeGlobal ifUndefined: [ ]. > I really like this idea. We just need to represent undefined variable value as special object instead of nil. > > This way we would not obscure the fact that we are accessing a global and > we model explicitly the state > if it is bound or not. > > Would that no be better than hiding it behind an API to look up symbols? > > (just some thoughts, needs more thinking before action is possible) > > Marcus > > On 11 Feb 2018, at 22:12, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > > There are two use cases that come immediately to mind. They may be the two > most important. > > "As a Compiler, I need to be able to resolve a Symbol to a known Object." > "As a Browser, I need to be able to identify the possible resolutions of a > String to known Objects." > > > I can elaborate on those, but I think they are pretty clear no matter what > scopes, namespaces, environments, modules, or whatever one uses to organize > things in the image. (One can even imagine an external registry of names > that could be searched and yield up suggestions of external packages that > would be needed.) > > On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Denis >>> >>> we should introduce classNamed: now we can have traits and globals too :( >>> >> >> Yes, we need to think about it. >> >> >>> Idea? may be can still classNamed: >>> >>> Stef >>> >>> >>> On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > >>> > >>> > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com>: >>> >> >>> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >> > Hi Hernan. >>> >> > >>> >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand >>> >> > <hernan.morales(a)gmail.com>: >>> >> >> >>> >> >> Hi Denis >>> >> >> >>> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com >>> >: >>> >> >> > >>> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >>> >> >> > <stepharo.self(a)gmail.com>: >>> >> >> >> >>> >> >> >> Please to not use an unary on Symbol >>> >> >> >> Dispatch on something. >>> >> >> >> >>> >> >> >> self class environment at: #Array >>> >> >> >> is the best >>> >> >> > >>> >> >> > >>> >> >> > We should not use collection API for reflection calls. It makes >>> them >>> >> >> > very >>> >> >> > difficult to find. Let's use explicit names like: >>> >> >> > >>> >> >> >>> >> >> Sorry I do not see it. >>> >> >> >>> >> >> The Collection API is beautiful, why couldn't be used for >>> reflection? >>> >> > >>> >> > >>> >> > We have around 3000 senders of #at: message in the image. Do you >>> think >>> >> > it is >>> >> > easy to filter reflective calls? >>> >> > >>> >> >>> >> I still don't understand your use case, nor how the #at: is related >>> >> with the #asClass issue. >>> >> >>> >> Do you mean **further** filtering for relflective sends? >>> >> >>> >> Does this affects common-usage beyond Browser development? >>> > >>> > >>> > The Stef proposal was that we should never use #asClass in the code. >>> It is >>> > fine for scripting but not for the domain code by many reasons which >>> were >>> > discussed here and at the past. >>> > >>> > But I only commented the proposed replacement: >>> > >>> > self class environment at: #Object >>> > >>> > >>> > If you do not like it, it is different story. I just described problem >>> with >>> > #at: message: >>> > >>> > We already replaced many #asClass users with this code. And now it is >>> quite >>> > difficult to find such places. They all hidden inside 3000 senders of >>> #at:. >>> > If we will use #classNamed: instead of #at: then simple senders query >>> will >>> > easily detect all reflective calls. >>> > (we probably already use it but not in all places). >>> > >>> >> >>> >> >>> >> >> >>> >> >> I have no trouble finding #asClass senders, implementors, etc. >>> >> >> >>> >> >> What do you want to find? >>> >> >> >>> >> >> > self class environment classNamed: #Array >>> >> >> > >>> >> >> >>> >> >> Too much typing :) >>> >> >> >>> >> >> > >>> >> >> > From the other side we all agree that #asClass is super handy >>> method. >>> >> >> > And we >>> >> >> > can fix it to respect sender environment using thisContext. It >>> will >>> >> >> > affects >>> >> >> > performance but with our super powerful metalinks it can be >>> easily >>> >> >> > cached >>> >> >> > (#asMethodConst is implemented that way). >>> >> >> > So we can make environment completely transparent for users. >>> >> >> > >>> >> >> > Best regards, >>> >> >> > Denis >>> >> >> > >>> >> >> >> >>> >> >> >> For Modules, we made progress and got bitten by many issues and >>> >> >> >> teaching >>> >> >> >> load. >>> >> >> >> >>> >> >> >> >>> >> >> >> Stef >>> >> >> >> >>> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera >>> >> >> >> <bera.clement(a)gmail.com> >>> >> >> >> wrote: >>> >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand >>> >> >> >> > <hernan.morales(a)gmail.com> wrote: >>> >> >> >> >> >>> >> >> >> >> Hi ClÃ©ment, >>> >> >> >> >> >>> >> >> >> >> First time I read about modules in Pharo. >>> >> >> >> >> What is a module exactly? >>> >> >> >> >> >>> >> >> >> >> What's the problem to solve? >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > It's similar to namespaces with some different, arguably >>> better, >>> >> >> >> > features. >>> >> >> >> > >>> >> >> >> > Honestly I am not the expert on it so I would like some one >>> else >>> >> >> >> > to >>> >> >> >> > answer. >>> >> >> >> > >>> >> >> >> > Among other things, it solves the problem of having 2 classes >>> with >>> >> >> >> > the >>> >> >> >> > same >>> >> >> >> > name (avoiding the prefixes we have like in C). But reportedly >>> >> >> >> > that's >>> >> >> >> > just a >>> >> >> >> > side-effect and not the main problem to solve. >>> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> Cheers, >>> >> >> >> >> >>> >> >> >> >> HernÃ¡n >>> >> >> >> >> >>> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera < >>> bera.clement(a)gmail.com>: >>> >> >> >> >> > Hi, >>> >> >> >> >> > >>> >> >> >> >> > In short, everything that is not namespace/module >>> compatible >>> >> >> >> >> > will >>> >> >> >> >> > be >>> >> >> >> >> > deprecated/changed/removed in the future, so it is not >>> >> >> >> >> > recommended >>> >> >> >> >> > to >>> >> >> >> >> > use >>> >> >> >> >> > it. >>> >> >> >> >> > >>> >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals >>> >> >> >> >> > b.1) Smalltalk globals at: #Array >>> >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk >>> globals' >>> >> >> >> >> > the >>> >> >> >> >> > namespace/module when support for those will be added since >>> >> >> >> >> > Array >>> >> >> >> >> > will >>> >> >> >> >> > be in >>> >> >> >> >> > a module. >>> >> >> >> >> > Maybe you want instead to use instead: >>> >> >> >> >> > >>> >> >> >> >> > c) self class environment at: #Array >>> >> >> >> >> > => this will work in the future if your code is a class >>> which >>> >> >> >> >> > environment/namespace/module includes the Array class you >>> would >>> >> >> >> >> > expect >>> >> >> >> >> > >>> >> >> >> >> > a.1) #Array asClass >>> >> >> >> >> > b.2) Smalltalk at: #Array >>> >> >> >> >> > b.3) Smalltalk classNamed: #Array >>> >> >> >> >> > => In which namespace/module are you looking for #Array ? >>> In >>> >> >> >> >> > the >>> >> >> >> >> > future >>> >> >> >> >> > this >>> >> >> >> >> > may be removed, alternatively it will work only for >>> globals but >>> >> >> >> >> > not >>> >> >> >> >> > globals >>> >> >> >> >> > inside namespace/module which won't work since Array will >>> be in >>> >> >> >> >> > a >>> >> >> >> >> > module. >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k >>> >> >> >> >> > <i.uhnak(a)gmail.com> >>> >> >> >> >> > wrote: >>> >> >> >> >> >> >>> >> >> >> >> >> Hi, >>> >> >> >> >> >> >>> >> >> >> >> >> what is the canonical way to get a class from a symbol? >>> >> >> >> >> >> >>> >> >> >> >> >> a) Converting symbol into class via string protocol >>> >> >> >> >> >> >>> >> >> >> >> >> a.1) #Array asClass >>> >> >> >> >> >> I use this the most, because it is easy, uses unary >>> selector, >>> >> >> >> >> >> and >>> >> >> >> >> >> so >>> >> >> >> >> >> far >>> >> >> >> >> >> I've never ran into any issues. But apparently it is not >>> good >>> >> >> >> >> >> -- >>> >> >> >> >> >> why? >>> >> >> >> >> >> >>> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >>> >> >> >> >> >> >>> >> >> >> >> >> b) Retriving the class by key from the system dictionary >>> >> >> >> >> >> >>> >> >> >> >> >> b.1) Smalltalk globals at: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> b.2) Smalltalk at: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> c) something else entirely? >>> >> >> >> >> >> >>> >> >> >> >> >> I get that using #asClass wouldn't work if there was a >>> >> >> >> >> >> different >>> >> >> >> >> >> environment, however I don't even know in what situation >>> there >>> >> >> >> >> >> could >>> >> >> >> >> >> be >>> >> >> >> >> >> a >>> >> >> >> >> >> different environment, so I cannot assert how problematic >>> it >>> >> >> >> >> >> is >>> >> >> >> >> >> or >>> >> >> >> >> >> isn't. >>> >> >> >> >> >> >>> >> >> >> >> >> Thanks, >>> >> >> >> >> >> Peter >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > -- >>> >> >> >> >> > ClÃ©ment BÃ©ra >>> >> >> >> >> > Pharo consortium engineer >>> >> >> >> >> > https://clementbera.wordpress.com/ >>> >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > ClÃ©ment BÃ©ra >>> >> >> >> > Pharo consortium engineer >>> >> >> >> > https://clementbera.wordpress.com/ >>> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> >> >> >> >>> >> >> > >>> >> >> >>> >> > >>> >> >>> > >>> >>> >> > >

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Siemen Baader

Thanks! On Tue, Feb 13, 2018 at 9:51 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader <siemenbaader(a)gmail.com> > wrote: > > Formulating the question helped me to find the solution after I posted: > > > > index > > ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello > > wo rld') ] > > > > :) > > > > Hi! > > Just for the record, > > There is a Pharo mustache implementation. > (https://ci.inria.fr/pharo-contribution/view/Books/job/ > EnterprisePharoBook/lastSuccessfulBuild/artifact/ > book-result/Mustache/Mustache.pdf) > Also, it is possible with Seaside to render raw html via the method #html: > > > cheers, > > Siemen > > > > > > On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader <siemenbaader(a)gmail.com> > > wrote: > >> > >> Hi all, > >> > >> is there a way to render raw HTML from Iliad widgets, or perhaps > mustache > >> templates? I'm interested in not using the builders always because I > use an > >> external web editor that generates plain HTML and that has some > advantages > >> in my workflow. > >> > >> Is it possible do it with Seaside & Reef instead? > >> > >> -- Siemen > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > >

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Marcus Denker

Sometimes I think we should treat globals more in a âlate boundâ fashion. e.g. right now we say that âUndeclaredâ vars are to be avoided at any cost. But we could just treat them like we treat messages that are send that do not exist. Forcing â#classNamed: â for all unknown globals is a bit similar than forcing to use âperform:â for all unknown selectors. e.g. why have Smalltalk at: #SomeClass and react to it if you could instead reason on the fact that a variable is not bound (yet). SomeGlobal ifUndefined: [ ]. This way we would not obscure the fact that we are accessing a global and we model explicitly the state if it is bound or not. Would that no be better than hiding it behind an API to look up symbols? (just some thoughts, needs more thinking before action is possible) Marcus > On 11 Feb 2018, at 22:12, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > There are two use cases that come immediately to mind. They may be the two most important. > > "As a Compiler, I need to be able to resolve a Symbol to a known Object." > "As a Browser, I need to be able to identify the possible resolutions of a String to known Objects." > > > I can elaborate on those, but I think they are pretty clear no matter what scopes, namespaces, environments, modules, or whatever one uses to organize things in the image. (One can even imagine an external registry of names that could be searched and yield up suggestions of external packages that would be needed.) > > On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > 2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > Denis > > we should introduce classNamed: now we can have traits and globals too :( > > Yes, we need to think about it. > > Idea? may be can still classNamed: > > Stef > > > On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > > > > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: > >> > >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > >> > Hi Hernan. > >> > > >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand > >> > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: > >> >> > >> >> Hi Denis > >> >> > >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > >> >> > > >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse > >> >> > <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: > >> >> >> > >> >> >> Please to not use an unary on Symbol > >> >> >> Dispatch on something. > >> >> >> > >> >> >> self class environment at: #Array > >> >> >> is the best > >> >> > > >> >> > > >> >> > We should not use collection API for reflection calls. It makes them > >> >> > very > >> >> > difficult to find. Let's use explicit names like: > >> >> > > >> >> > >> >> Sorry I do not see it. > >> >> > >> >> The Collection API is beautiful, why couldn't be used for reflection? > >> > > >> > > >> > We have around 3000 senders of #at: message in the image. Do you think > >> > it is > >> > easy to filter reflective calls? > >> > > >> > >> I still don't understand your use case, nor how the #at: is related > >> with the #asClass issue. > >> > >> Do you mean **further** filtering for relflective sends? > >> > >> Does this affects common-usage beyond Browser development? > > > > > > The Stef proposal was that we should never use #asClass in the code. It is > > fine for scripting but not for the domain code by many reasons which were > > discussed here and at the past. > > > > But I only commented the proposed replacement: > > > > self class environment at: #Object > > > > > > If you do not like it, it is different story. I just described problem with > > #at: message: > > > > We already replaced many #asClass users with this code. And now it is quite > > difficult to find such places. They all hidden inside 3000 senders of #at:. > > If we will use #classNamed: instead of #at: then simple senders query will > > easily detect all reflective calls. > > (we probably already use it but not in all places). > > > >> > >> > >> >> > >> >> I have no trouble finding #asClass senders, implementors, etc. > >> >> > >> >> What do you want to find? > >> >> > >> >> > self class environment classNamed: #Array > >> >> > > >> >> > >> >> Too much typing :) > >> >> > >> >> > > >> >> > From the other side we all agree that #asClass is super handy method. > >> >> > And we > >> >> > can fix it to respect sender environment using thisContext. It will > >> >> > affects > >> >> > performance but with our super powerful metalinks it can be easily > >> >> > cached > >> >> > (#asMethodConst is implemented that way). > >> >> > So we can make environment completely transparent for users. > >> >> > > >> >> > Best regards, > >> >> > Denis > >> >> > > >> >> >> > >> >> >> For Modules, we made progress and got bitten by many issues and > >> >> >> teaching > >> >> >> load. > >> >> >> > >> >> >> > >> >> >> Stef > >> >> >> > >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera > >> >> >> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> > >> >> >> wrote: > >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand > >> >> >> > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > >> >> >> >> > >> >> >> >> Hi ClÃ©ment, > >> >> >> >> > >> >> >> >> First time I read about modules in Pharo. > >> >> >> >> What is a module exactly? > >> >> >> >> > >> >> >> >> What's the problem to solve? > >> >> >> > > >> >> >> > > >> >> >> > It's similar to namespaces with some different, arguably better, > >> >> >> > features. > >> >> >> > > >> >> >> > Honestly I am not the expert on it so I would like some one else > >> >> >> > to > >> >> >> > answer. > >> >> >> > > >> >> >> > Among other things, it solves the problem of having 2 classes with > >> >> >> > the > >> >> >> > same > >> >> >> > name (avoiding the prefixes we have like in C). But reportedly > >> >> >> > that's > >> >> >> > just a > >> >> >> > side-effect and not the main problem to solve. > >> >> >> > > >> >> >> >> > >> >> >> >> Cheers, > >> >> >> >> > >> >> >> >> HernÃ¡n > >> >> >> >> > >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > In short, everything that is not namespace/module compatible > >> >> >> >> > will > >> >> >> >> > be > >> >> >> >> > deprecated/changed/removed in the future, so it is not > >> >> >> >> > recommended > >> >> >> >> > to > >> >> >> >> > use > >> >> >> >> > it. > >> >> >> >> > > >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> >> > b.1) Smalltalk globals at: #Array > >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk globals' > >> >> >> >> > the > >> >> >> >> > namespace/module when support for those will be added since > >> >> >> >> > Array > >> >> >> >> > will > >> >> >> >> > be in > >> >> >> >> > a module. > >> >> >> >> > Maybe you want instead to use instead: > >> >> >> >> > > >> >> >> >> > c) self class environment at: #Array > >> >> >> >> > => this will work in the future if your code is a class which > >> >> >> >> > environment/namespace/module includes the Array class you would > >> >> >> >> > expect > >> >> >> >> > > >> >> >> >> > a.1) #Array asClass > >> >> >> >> > b.2) Smalltalk at: #Array > >> >> >> >> > b.3) Smalltalk classNamed: #Array > >> >> >> >> > => In which namespace/module are you looking for #Array ? In > >> >> >> >> > the > >> >> >> >> > future > >> >> >> >> > this > >> >> >> >> > may be removed, alternatively it will work only for globals but > >> >> >> >> > not > >> >> >> >> > globals > >> >> >> >> > inside namespace/module which won't work since Array will be in > >> >> >> >> > a > >> >> >> >> > module. > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k > >> >> >> >> > <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> > >> >> >> >> > wrote: > >> >> >> >> >> > >> >> >> >> >> Hi, > >> >> >> >> >> > >> >> >> >> >> what is the canonical way to get a class from a symbol? > >> >> >> >> >> > >> >> >> >> >> a) Converting symbol into class via string protocol > >> >> >> >> >> > >> >> >> >> >> a.1) #Array asClass > >> >> >> >> >> I use this the most, because it is easy, uses unary selector, > >> >> >> >> >> and > >> >> >> >> >> so > >> >> >> >> >> far > >> >> >> >> >> I've never ran into any issues. But apparently it is not good > >> >> >> >> >> -- > >> >> >> >> >> why? > >> >> >> >> >> > >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals > >> >> >> >> >> > >> >> >> >> >> b) Retriving the class by key from the system dictionary > >> >> >> >> >> > >> >> >> >> >> b.1) Smalltalk globals at: #Array > >> >> >> >> >> > >> >> >> >> >> b.2) Smalltalk at: #Array > >> >> >> >> >> > >> >> >> >> >> b.3) Smalltalk classNamed: #Array > >> >> >> >> >> > >> >> >> >> >> c) something else entirely? > >> >> >> >> >> > >> >> >> >> >> I get that using #asClass wouldn't work if there was a > >> >> >> >> >> different > >> >> >> >> >> environment, however I don't even know in what situation there > >> >> >> >> >> could > >> >> >> >> >> be > >> >> >> >> >> a > >> >> >> >> >> different environment, so I cannot assert how problematic it > >> >> >> >> >> is > >> >> >> >> >> or > >> >> >> >> >> isn't. > >> >> >> >> >> > >> >> >> >> >> Thanks, > >> >> >> >> >> Peter > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > ClÃ©ment BÃ©ra > >> >> >> >> > Pharo consortium engineer > >> >> >> >> > https://clementbera.wordpress.com/ <https://clementbera.wordpress.com/> > >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…>'Ascq <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > ClÃ©ment BÃ©ra > >> >> >> > Pharo consortium engineer > >> >> >> > https://clementbera.wordpress.com/ <https://clementbera.wordpress.com/> > >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…>'Ascq <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> > >> >> >> > >> >> > > >> >> > >> > > >> > > > > >

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Cyril Ferlicot

On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > Formulating the question helped me to find the solution after I posted: > > index > ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello > wo rld') ] > > :) > Hi! Just for the record, There is a Pharo mustache implementation. (https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l…) Also, it is possible with Seaside to render raw html via the method #html: > cheers, > Siemen > > > On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader <siemenbaader(a)gmail.com> > wrote: >> >> Hi all, >> >> is there a way to render raw HTML from Iliad widgets, or perhaps mustache >> templates? I'm interested in not using the builders always because I use an >> external web editor that generates plain HTML and that has some advantages >> in my workflow. >> >> Is it possible do it with Seaside & Reef instead? >> >> -- Siemen > > -- Cyril Ferlicot https://ferlicot.fr

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Siemen Baader

Formulating the question helped me to find the solution after I posted: index ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello wo rld') ] :) cheers, Siemen On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > Hi all, > > is there a way to render raw HTML from Iliad widgets, or perhaps mustache > templates? I'm interested in not using the builders always because I use an > external web editor that generates plain HTML and that has some advantages > in my workflow. > > Is it possible do it with Seaside & Reef instead? > > -- Siemen >

Feb. 13, 2018

[Iliad] raw HTML in Iliad

by Siemen Baader

Hi all, is there a way to render raw HTML from Iliad widgets, or perhaps mustache templates? I'm interested in not using the builders always because I use an external web editor that generates plain HTML and that has some advantages in my workflow. Is it possible do it with Seaside & Reef instead? -- Siemen

Feb. 13, 2018

Re: [Pharo-users] cancel changes in Nautilus broken on 6.1?

by Siemen Baader

Thanks for the tip! -- Siemen On Mon, Feb 12, 2018 at 11:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 13 February 2018 at 01:57, Siemen Baader <siemenbaader(a)gmail.com> > wrote: > >> Hi Stef, >> >> On Sat, Feb 10, 2018 at 6:22 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Hi Siemen >>> >>> I use often cmd-L too and may be we got a regression. >>> >> >> I'm pretty sure I started doing it after I saw you do it in the MOOC ;) >> >> And indeed I have the same behavior in Pharo 70. >>> Can you try to see how to address it? >>> >> >> Yes, I can try to look into it. I don't have any clear idea where to >> start other than browsing Nautilus code and perhaps uses of >> NautilusChanged, but perhaps it is not that hard to find. >> > > One approach would be to start with PharoLauncher to quickly open Images > from different builds, to bisect which build changed it, then review the > code modified between builds. > cheers -ben > > > >> >> -- Siemen >> >>> >>> Stef >>> >>> On Fri, Feb 9, 2018 at 8:37 PM, Siemen Baader <siemenbaader(a)gmail.com> >>> wrote: >>> > Hi all, >>> > >>> > I downloaded Pharo 6.1 for OSX and whenever I revert changes in >>> Nautilus >>> > with CMD-L, the content is reverted and the orange dirty marker >>> triangle >>> > disappears. But when I switch to a different method, Nautilus shows the >>> > 'Content has been modified. What do you want to do?' dialog, as it only >>> > should when content is actually different. >>> > >>> > I use this all the time, I can't imagine I'm the only one, but I >>> couldn't >>> > find the problem mentioned anywhere. Does anyone else have it? What to >>> do? >>> > >>> > -- Siemen >>> >>> >> >

Feb. 13, 2018

Re: [Pharo-users] cancel changes in Nautilus broken on 6.1?

by Ben Coman

On 13 February 2018 at 01:57, Siemen Baader <siemenbaader(a)gmail.com> wrote: > Hi Stef, > > On Sat, Feb 10, 2018 at 6:22 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi Siemen >> >> I use often cmd-L too and may be we got a regression. >> > > I'm pretty sure I started doing it after I saw you do it in the MOOC ;) > > And indeed I have the same behavior in Pharo 70. >> Can you try to see how to address it? >> > > Yes, I can try to look into it. I don't have any clear idea where to start > other than browsing Nautilus code and perhaps uses of NautilusChanged, but > perhaps it is not that hard to find. > One approach would be to start with PharoLauncher to quickly open Images from different builds, to bisect which build changed it, then review the code modified between builds. cheers -ben > > -- Siemen > >> >> Stef >> >> On Fri, Feb 9, 2018 at 8:37 PM, Siemen Baader <siemenbaader(a)gmail.com> >> wrote: >> > Hi all, >> > >> > I downloaded Pharo 6.1 for OSX and whenever I revert changes in Nautilus >> > with CMD-L, the content is reverted and the orange dirty marker triangle >> > disappears. But when I switch to a different method, Nautilus shows the >> > 'Content has been modified. What do you want to do?' dialog, as it only >> > should when content is actually different. >> > >> > I use this all the time, I can't imagine I'm the only one, but I >> couldn't >> > find the problem mentioned anywhere. Does anyone else have it? What to >> do? >> > >> > -- Siemen >> >> >

Feb. 12, 2018