Re: [Pharo-users] [Moose-dev] feenk log

[Tudor Girba]

Hi,

Bindings is an issue indeed. They are at the same level as theming and we are 
not at that level yet.

At present time we are focused on showing the breadth of what we can achieve 
with the new infrastructure. We are currently using only the Bloc keybinding 
mechanism (equivalent to Keymapping).

We did explore the use of Commander, but it was not a match for our initial 
work. This does not mean that it’s not a good library. Just that we are still 
exploring and still need to learn what we need. Our focus is on an 
infrastructure for actions that is as close as possible to Bloc, and to figure 
out which parts need to go at which level of abstraction.

Cheers,
Doru



> On Aug 17, 2018, at 5:14 PM, Stéphane Ducasse  
> wrote:
> 
> Hi Doru 
> 
> this is great. We are brainstorming to see if and how Commander should be 
> tuned to offer a smoother extensibility. 
> Julien was developing commands for all his spec tools and guille used 
> commander for Iceberg. 
> We plan to have a meeting brainstorming about commands and context when 
> guille is back from vacation (before 
> ESUG). On your side what did you use for the key binding?
> 
> I would like to able to have pluggable binding so that we can have emacs like 
> ctrl a / ctrle …
> 
> Stef
> 
>> On 17 Aug 2018, at 06:47, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> We again got carried away and forgot to update the world about what is up in 
>> our corner. Here is a summary:
>> 
>> --
>> Bloc & Brick
>> --
>> 
>> - Text editor stability has been significantly improved
>> - Improved support for selection in the text editor
>> - Support for typical editing keybindings (copy, cut, paste)
>> - Text editor debuggability:
>> https://twitter.com/feenkcom/status/1024680215379959808
>> https://twitter.com/feenkcom/status/1020768298017992704
>> - The text editor can handle emojis:
>> https://twitter.com/feenkcom/status/1021872214151507968
>> 
>> --
>> GT
>> --
>> 
>> - Inspector
>> We now have an initial version of a working inspector with resizable panes:
>> https://twitter.com/feenkcom/status/1030091849795612672
>> https://twitter.com/feenkcom/status/1030314856736538624
>> It shows a display string for the current object:
>> https://twitter.com/feenkcom/status/1024564065870512129
>> It can handle errors in the definition of views gracefully:
>> https://twitter.com/feenkcom/status/1009174937217720320
>> We now have multiple extensions expressed in the new Inspector:
>> https://twitter.com/feenkcom/status/1024321868566814720
>> https://twitter.com/feenkcom/status/1022393383850008576
>> 
>> - Documenter saw multiple enhancements.
>> We can now resize various previews live:
>> https://twitter.com/feenkcom/status/1002851190475026432
>> https://twitter.com/feenkcom/status/1001407762285375490
>> https://twitter.com/feenkcom/status/1001152789874167808
>> It now relies on the annotation mechanism from Pillar:
>> https://twitter.com/feenkcom/status/1006508725409079298
>> We can now link classes and expand their definition:
>> https://twitter.com/feenkcom/status/1014609460520775681
>> https://twitter.com/feenkcom/status/1029085603948843008
>> The preview of examples can handle errors gracefully:
>> https://twitter.com/feenkcom/status/1022123808524836864
>> We can run examples in place, enabling a smoother tutorial experience:
>> https://twitter.com/feenkcom/status/1028390957023223809
>> We have new documentation expressed in it:
>> https://twitter.com/feenkcom/status/100700881420672
>> 
>> 
>> 
>> Have fun,
>> The feenk team
>> 
>> --
>> www.feenk.com
>> 
>> "Presenting is storytelling."
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

[Pharo-users] Working with an entire project in git

[sergio ruiz]

Hey, all..

I was just checking in to see the progress of managing an entire project
with git.

The last I checked in, this was a work in progress.

My current pet project consists of a handful of classes with maybe two
handfuls of required packages.

Is the entire metacello configuration being handled on github yet?

I would like to work this into my workflow so that I can do something like:

- Grab a fresh Pharo
- Pharo.image ../scripts/setup-client-application.st where the setup script
just grabs the Configuration and loads and starts a fresh project.

Thanks!




peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

Re: [Pharo-users] [Moose-dev] feenk log

[Ben Coman]

On Fri, 17 Aug 2018 at 12:48, Tudor Girba  wrote:
>
> Hi,
>
> We again got carried away and forgot to update the world about what is up in 
> our corner. Here is a summary:

Thanks for the update.  Nice to see the progress.

>
> --
> Bloc & Brick
> --
>
> - Text editor stability has been significantly improved
> - Improved support for selection in the text editor
> - Support for typical editing keybindings (copy, cut, paste)
> - Text editor debuggability:
> https://twitter.com/feenkcom/status/1024680215379959808
> https://twitter.com/feenkcom/status/1020768298017992704

Nice demos.  If possible, it would be interesting to see movement or a
selection in the first video,
dynamically updating a treeview in a second-Inspector-pane.

cheers -ben

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

[Tim Mackinnon]

The direct link to instructions is here: 
https://exercism.io/tracks/pharo/installation 
 (not sure if you have to be 
signed up to see it otherwise its in the repo here: 
https://github.com/exercism/pharo/blob/master/docs/INSTALLATION.md 
)

Tim

> On 17 Aug 2018, at 07:17, Marcus Denker  wrote:
> 
> 
> 
>> On 17 Aug 2018, at 13:00, Tim Mackinnon > > wrote:
>> 
>> 
>> Hi Marcus - I can put an image somewhere if that helps (do you just need the 
>> .image and .changes)?
>> 
>> Or you can repro from a fresh 6.1 if you follow the exercism Pharo 
>> instructions (https://exercism.io/tracks/pharo 
>> ) to load the first hello world-world 
>> example and run the tests. This has my code changes to make create work with 
>> a nil class - but maybe we can do better?
>> 
> I will do that and have a look!
> 
>> Tim
>> 
>> 
>> Sent from my iPhone
>> 
>> On 17 Aug 2018, at 06:21, Marcus Denker > > wrote:
>> 
>>> 
>>> 
 On 10 Aug 2018, at 23:16, Tim Mackinnon >>> > wrote:
 
 Actually I think I figured that bit out - a bit clumsily - (pointers 
 appreciated)
 
 createMissingClassActionFor: aMessage in: aContext
|errorNode senderContext newClass variableNode |
senderContext := aContext sender.
errorNode := senderContext method sourceNodeExecutedForPC: 
 senderContext pc. 
variableNode := errorNode receiver receiver.

newClass := OCUndeclaredVariableWarning new node: variableNode; 
 defineClass: variableNode name.
aContext restart.
 
 However that last line is wrong, as it doesn’t restart with my newly 
 defined class - I also tried
 
 aContext restartWithNewReceiver: newClass
 
 But again, I get a debugger where my class is still bound to nil. So 
 what’s the trick to re-evaluate with the new class I’ve created? Or maybe 
 I’m totally on the wrong track (still its very interesting…)
 
>>> 
>>> 
>>> what is a bit bad is that you catch the problem “too late” (that is, the 
>>> DNU to nil, not the read of nil), so nil is already pushed on the stack at 
>>> this point.
>>> 
>>> I tried it in the inspector and at least the class binding was correct 
>>> after defining the class… do you have an image with the whole code to try?
>>> 
>>>Marcus
>>> 
>>> 
> 

Re: [Pharo-users] Trait method override

[teso...@gmail.com]

Jajajja,
 yes I like the power that there is in the language. It opens a lot of
doors and possibilities.
You can check the implementation of deep alias that rewrites the users of
the aliased method.

There is also the ability to implement new operations to traits algebra.
You can check how they are implemented and implement new operations.

Cheers

On Fri, Aug 17, 2018 at 1:23 PM Vitor Medina Cruz 
wrote:

> Hello Pablo,
>
> Don't think it is ugly, I personally think it is wonderfull how those
> extensions to the language can be done with normal messaging passing code!
> But the information about this seems scattered a bit, I found in google and
> was not certain if the information was official or correct.
>
> Also, there could be some default aliases in hand, in a way similar to
> groovy:
> http://docs.groovy-lang.org/latest/html/documentation/#_user_conflict_resolution
>
> So, if I use TraitA with a methodX, this method could be aliased by
> default with something like TraitA_methodX. Don't know if this have some
> problem, just an idea (maybe I will explore this here :) )
>
> regards,
> Vitor
>
> On Fri, Aug 17, 2018 at 4:37 AM, teso...@gmail.com 
> wrote:
>
>> Hi Vitor,
>>as Julien correctly said there is no super call in traits. Currently
>> the solution, maybe is a bit ugly, it is to use aliasing.
>> Cheers,
>> Pablo
>>
>> On Fri, Aug 17, 2018 at 12:10 AM Vitor Medina Cruz 
>> wrote:
>>
>>> Thanks Julian!
>>>
>>> On Thu, Aug 16, 2018 at 5:38 PM, Julien 
>>> wrote:
>>>
 Hello Vitor,

 Yeah, I was talking about that with Pablo (who implemented stateful
 traits) some times ago.

 He told me that aliasing was he way to go.

 There is no other option to override a trait method without aliasing it.

 Cheers,

 Julien

 ---
 Julien Delplanque
 Doctorant à l’Université de Lille
 http://juliendelplanque.be/phd.html
 Equipe Rmod, Inria
 Bâtiment B 40, Avenue Halley 59650
 
  Villeneuve
 
  d'Ascq
 
 Numéro de téléphone: +333 59 35 86 40

 Le 16 août 2018 à 19:32, Vitor Medina Cruz  a
 écrit :

 Well, found out about aliasing in
 http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Traits/, is
 that the correct way of doint it?

 On Thu, Aug 16, 2018 at 11:30 AM, Vitor Medina Cruz <
 vitormc...@gmail.com> wrote:

> Hello,
>
> In a class that uses a Trait, how can I override one of it's method by
> appending behavior to the method implemented by the Trait? In a typical
> override, this is done by calling super:
>
> method
>
>super method
>"extended behavior"
>...
>
>
> Is there a way to change "super" to a reference the Trait?
>
> Regards,
> Vitor
>



>>>
>>
>> --
>> Pablo Tesone.
>> teso...@gmail.com
>>
>
>

-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-users] Trait method override

[Vitor Medina Cruz]

Hello Pablo,

Don't think it is ugly, I personally think it is wonderfull how those
extensions to the language can be done with normal messaging passing code!
But the information about this seems scattered a bit, I found in google and
was not certain if the information was official or correct.

Also, there could be some default aliases in hand, in a way similar to
groovy:
http://docs.groovy-lang.org/latest/html/documentation/#_user_conflict_resolution

So, if I use TraitA with a methodX, this method could be aliased by default
with something like TraitA_methodX. Don't know if this have some problem,
just an idea (maybe I will explore this here :) )

regards,
Vitor

On Fri, Aug 17, 2018 at 4:37 AM, teso...@gmail.com 
wrote:

> Hi Vitor,
>as Julien correctly said there is no super call in traits. Currently
> the solution, maybe is a bit ugly, it is to use aliasing.
> Cheers,
> Pablo
>
> On Fri, Aug 17, 2018 at 12:10 AM Vitor Medina Cruz 
> wrote:
>
>> Thanks Julian!
>>
>> On Thu, Aug 16, 2018 at 5:38 PM, Julien 
>> wrote:
>>
>>> Hello Vitor,
>>>
>>> Yeah, I was talking about that with Pablo (who implemented stateful
>>> traits) some times ago.
>>>
>>> He told me that aliasing was he way to go.
>>>
>>> There is no other option to override a trait method without aliasing it.
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>> ---
>>> Julien Delplanque
>>> Doctorant à l’Université de Lille
>>> http://juliendelplanque.be/phd.html
>>> Equipe Rmod, Inria
>>> Bâtiment B 40, Avenue Halley 59650
>>> 
>>>  Villeneuve
>>> 
>>>  d'Ascq
>>> 
>>> Numéro de téléphone: +333 59 35 86 40
>>>
>>> Le 16 août 2018 à 19:32, Vitor Medina Cruz  a
>>> écrit :
>>>
>>> Well, found out about aliasing in http://pharo.gemtalksystems.
>>> com/book/LanguageAndLibraries/Traits/, is that the correct way of doint
>>> it?
>>>
>>> On Thu, Aug 16, 2018 at 11:30 AM, Vitor Medina Cruz <
>>> vitormc...@gmail.com> wrote:
>>>
 Hello,

 In a class that uses a Trait, how can I override one of it's method by
 appending behavior to the method implemented by the Trait? In a typical
 override, this is done by calling super:

 method

super method
"extended behavior"
...


 Is there a way to change "super" to a reference the Trait?

 Regards,
 Vitor

>>>
>>>
>>>
>>
>
> --
> Pablo Tesone.
> teso...@gmail.com
>

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

[Marcus Denker]

> On 17 Aug 2018, at 13:00, Tim Mackinnon  wrote:
> 
> 
> Hi Marcus - I can put an image somewhere if that helps (do you just need the 
> .image and .changes)?
> 
> Or you can repro from a fresh 6.1 if you follow the exercism Pharo 
> instructions (https://exercism.io/tracks/pharo 
> ) to load the first hello world-world 
> example and run the tests. This has my code changes to make create work with 
> a nil class - but maybe we can do better?
> 
I will do that and have a look!

> Tim
> 
> 
> Sent from my iPhone
> 
> On 17 Aug 2018, at 06:21, Marcus Denker  > wrote:
> 
>> 
>> 
>>> On 10 Aug 2018, at 23:16, Tim Mackinnon >> > wrote:
>>> 
>>> Actually I think I figured that bit out - a bit clumsily - (pointers 
>>> appreciated)
>>> 
>>> createMissingClassActionFor: aMessage in: aContext
>>>|errorNode senderContext newClass variableNode |
>>>senderContext := aContext sender.
>>>errorNode := senderContext method sourceNodeExecutedForPC: senderContext 
>>> pc. 
>>>variableNode := errorNode receiver receiver.
>>>
>>>newClass := OCUndeclaredVariableWarning new node: variableNode; 
>>> defineClass: variableNode name.
>>>aContext restart.
>>> 
>>> However that last line is wrong, as it doesn’t restart with my newly 
>>> defined class - I also tried
>>> 
>>> aContext restartWithNewReceiver: newClass
>>> 
>>> But again, I get a debugger where my class is still bound to nil. So what’s 
>>> the trick to re-evaluate with the new class I’ve created? Or maybe I’m 
>>> totally on the wrong track (still its very interesting…)
>>> 
>> 
>> 
>> what is a bit bad is that you catch the problem “too late” (that is, the DNU 
>> to nil, not the read of nil), so nil is already pushed on the stack at this 
>> point.
>> 
>> I tried it in the inspector and at least the class binding was correct after 
>> defining the class… do you have an image with the whole code to try?
>> 
>>Marcus
>> 
>> 

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

[Tim Mackinnon]

Hi Marcus - I can put an image somewhere if that helps (do you just need the 
.image and .changes)?

Or you can repro from a fresh 6.1 if you follow the exercism Pharo instructions 
(https://exercism.io/tracks/pharo) to load the first hello world-world example 
and run the tests. This has my code changes to make create work with a nil 
class - but maybe we can do better?

Tim


Sent from my iPhone

> On 17 Aug 2018, at 06:21, Marcus Denker  wrote:
> 
> 
> 
>> On 10 Aug 2018, at 23:16, Tim Mackinnon  wrote:
>> 
>> Actually I think I figured that bit out - a bit clumsily - (pointers 
>> appreciated)
>> 
>> createMissingClassActionFor: aMessage in: aContext
>>|errorNode senderContext newClass variableNode |
>>senderContext := aContext sender.
>>errorNode := senderContext method sourceNodeExecutedForPC: senderContext 
>> pc. 
>>variableNode := errorNode receiver receiver.
>>
>>newClass := OCUndeclaredVariableWarning new node: variableNode; 
>> defineClass: variableNode name.
>>aContext restart.
>> 
>> However that last line is wrong, as it doesn’t restart with my newly defined 
>> class - I also tried
>> 
>> aContext restartWithNewReceiver: newClass
>> 
>> But again, I get a debugger where my class is still bound to nil. So what’s 
>> the trick to re-evaluate with the new class I’ve created? Or maybe I’m 
>> totally on the wrong track (still its very interesting…)
>> 
> 
> 
> what is a bit bad is that you catch the problem “too late” (that is, the DNU 
> to nil, not the read of nil), so nil is already pushed on the stack at this 
> point.
> 
> I tried it in the inspector and at least the class binding was correct after 
> defining the class… do you have an image with the whole code to try?
> 
>Marcus
> 
> 

Re: [Pharo-users] Is the debugger known to be unstable on recent Pharo 7?

[Tim Mackinnon]

I forgot to give the exact image number - it was build 1167 from around 13/Aug.


Sent from my iPhone

> On 17 Aug 2018, at 06:32, Tim Mackinnon  wrote:
> 
> 
> Hi, I’m doing some travelling and had a stretch on a plane with Pharo 7 - 
> 64bit b166, and was trying out some changes to Calypso to plug in some 
> potential keyboard extensions.
> 
> Anyway, in figuring stuff out I noticed the debugger had a number of issues - 
> which I can try to investigate more but wanted to say something before 
> ploughing on.
> 
> When I hit a method invoked from the keyboard which has self halt (not a soft 
> breakpoint, as I was changing code and didn’t want to keep losing the 
> breakpoint) - when I made a change and hit save I get an extra empty predebug 
> window ? The older debug window also has a my single method but no stack and 
> is not debuggable. The upshot is that I have to start debugging all over 
> again?
> 
> I also noticed that when I hit an error and got a debugger and then fixed the 
> error, resumed but then hit another - the title of the window was still the 
> old error msg and not the new one (so quite confusing).
> 
> Has there been recent work done in the debugger that might explain these?
> 
> Tim
> 
> Sent from my iPhone
> 

[Pharo-users] Is the debugger known to be unstable on recent Pharo 7?

[Tim Mackinnon]

Hi, I’m doing some travelling and had a stretch on a plane with Pharo 7 - 64bit 
b166, and was trying out some changes to Calypso to plug in some potential 
keyboard extensions.

Anyway, in figuring stuff out I noticed the debugger had a number of issues - 
which I can try to investigate more but wanted to say something before 
ploughing on.

When I hit a method invoked from the keyboard which has self halt (not a soft 
breakpoint, as I was changing code and didn’t want to keep losing the 
breakpoint) - when I made a change and hit save I get an extra empty predebug 
window ? The older debug window also has a my single method but no stack and is 
not debuggable. The upshot is that I have to start debugging all over again?

I also noticed that when I hit an error and got a debugger and then fixed the 
error, resumed but then hit another - the title of the window was still the old 
error msg and not the new one (so quite confusing).

Has there been recent work done in the debugger that might explain these?

Tim
 
Sent from my iPhone

Re: [Pharo-users] separate native window of same Pharo image

[kmo]

Who knows whether OSWindow is maintained? Who knows if anybody cares that it
doesn't work on Windows? 

OSWindow is like lots of things that suddenly appear in the Pharo standard
image. There's no documentation. There's no plan. That's the Pharo way. Give
it a year or two and it will be superseded by another framework doing the
same thing which will also have no documentation, killer bugs, and no plan.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

[Marcus Denker]

> On 10 Aug 2018, at 23:16, Tim Mackinnon  wrote:
> 
> Actually I think I figured that bit out - a bit clumsily - (pointers 
> appreciated)
> 
> createMissingClassActionFor: aMessage in: aContext
>   |errorNode senderContext newClass variableNode |
>   senderContext := aContext sender.
>   errorNode := senderContext method sourceNodeExecutedForPC: 
> senderContext pc. 
>   variableNode := errorNode receiver receiver.
>   
>   newClass := OCUndeclaredVariableWarning new node: variableNode; 
> defineClass: variableNode name.
>   aContext restart.
> 
> However that last line is wrong, as it doesn’t restart with my newly defined 
> class - I also tried
> 
> aContext restartWithNewReceiver: newClass
> 
> But again, I get a debugger where my class is still bound to nil. So what’s 
> the trick to re-evaluate with the new class I’ve created? Or maybe I’m 
> totally on the wrong track (still its very interesting…)
> 


what is a bit bad is that you catch the problem “too late” (that is, the DNU to 
nil, not the read of nil), so nil is already pushed on the stack at this point.

I tried it in the inspector and at least the class binding was correct after 
defining the class… do you have an image with the whole code to try?

Marcus

Re: [Pharo-users] RubShoutStylerDecorator doesnotunderstand: #move:for:controller:

[Jeff Gray]

 



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] RubShoutStylerDecorator doesnotunderstand: #move:for:controller:

[Jeff Gray]

Hi all,
I was debugging my seaside application yesterday. I saved and closed the
image. Then when I opened Pharo tonight I got the RubShoutStylerDecorator
error.

If I close the error window another one immediately pops up. Any idea what I
can do? 





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] feenk log

[Marcus Denker]

Thanks, recorded for the newsletter:

http://newsletter.pharo.org

(the one after the next which is going out today, I think).

> On 17 Aug 2018, at 06:47, Tudor Girba  wrote:
> 
> Hi,
> 
> We again got carried away and forgot to update the world about what is up in 
> our corner. Here is a summary:
> 
> --
> Bloc & Brick
> --
> 
> - Text editor stability has been significantly improved
> - Improved support for selection in the text editor
> - Support for typical editing keybindings (copy, cut, paste)
> - Text editor debuggability:
> https://twitter.com/feenkcom/status/1024680215379959808
> https://twitter.com/feenkcom/status/1020768298017992704
> - The text editor can handle emojis:
> https://twitter.com/feenkcom/status/1021872214151507968
> 
> --
> GT
> --
> 
> - Inspector
> We now have an initial version of a working inspector with resizable panes:
> https://twitter.com/feenkcom/status/1030091849795612672
> https://twitter.com/feenkcom/status/1030314856736538624
> It shows a display string for the current object:
> https://twitter.com/feenkcom/status/1024564065870512129
> It can handle errors in the definition of views gracefully:
> https://twitter.com/feenkcom/status/1009174937217720320
> We now have multiple extensions expressed in the new Inspector:
> https://twitter.com/feenkcom/status/1024321868566814720
> https://twitter.com/feenkcom/status/1022393383850008576
> 
> - Documenter saw multiple enhancements.
> We can now resize various previews live:
> https://twitter.com/feenkcom/status/1002851190475026432
> https://twitter.com/feenkcom/status/1001407762285375490
> https://twitter.com/feenkcom/status/1001152789874167808
> It now relies on the annotation mechanism from Pillar:
> https://twitter.com/feenkcom/status/1006508725409079298
> We can now link classes and expand their definition:
> https://twitter.com/feenkcom/status/1014609460520775681
> https://twitter.com/feenkcom/status/1029085603948843008
> The preview of examples can handle errors gracefully:
> https://twitter.com/feenkcom/status/1022123808524836864
> We can run examples in place, enabling a smoother tutorial experience:
> https://twitter.com/feenkcom/status/1028390957023223809
> We have new documentation expressed in it:
> https://twitter.com/feenkcom/status/100700881420672
> 
> 
> 
> Have fun,
> The feenk team
> 
> --
> www.feenk.com
> 
> "Presenting is storytelling."
> 
> 

Re: [Pharo-users] Trait method override

[teso...@gmail.com]

Hi Vitor,
   as Julien correctly said there is no super call in traits. Currently the
solution, maybe is a bit ugly, it is to use aliasing.
Cheers,
Pablo

On Fri, Aug 17, 2018 at 12:10 AM Vitor Medina Cruz 
wrote:

> Thanks Julian!
>
> On Thu, Aug 16, 2018 at 5:38 PM, Julien 
> wrote:
>
>> Hello Vitor,
>>
>> Yeah, I was talking about that with Pablo (who implemented stateful
>> traits) some times ago.
>>
>> He told me that aliasing was he way to go.
>>
>> There is no other option to override a trait method without aliasing it.
>>
>> Cheers,
>>
>> Julien
>>
>> ---
>> Julien Delplanque
>> Doctorant à l’Université de Lille
>> http://juliendelplanque.be/phd.html
>> Equipe Rmod, Inria
>> Bâtiment B 40, Avenue Halley 59650
>> 
>>  Villeneuve
>> 
>>  d'Ascq
>> 
>> Numéro de téléphone: +333 59 35 86 40
>>
>> Le 16 août 2018 à 19:32, Vitor Medina Cruz  a
>> écrit :
>>
>> Well, found out about aliasing in
>> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Traits/, is
>> that the correct way of doint it?
>>
>> On Thu, Aug 16, 2018 at 11:30 AM, Vitor Medina Cruz > > wrote:
>>
>>> Hello,
>>>
>>> In a class that uses a Trait, how can I override one of it's method by
>>> appending behavior to the method implemented by the Trait? In a typical
>>> override, this is done by calling super:
>>>
>>> method
>>>
>>>super method
>>>"extended behavior"
>>>...
>>>
>>>
>>> Is there a way to change "super" to a reference the Trait?
>>>
>>> Regards,
>>> Vitor
>>>
>>
>>
>>
>

-- 
Pablo Tesone.
teso...@gmail.com