[Pharo-users] [ANN] 15/2: Pharo TechTalk: Contributing to Pharo 7

2018-02-13 Thread Marcus Denker
Pharo TechTalk: Contributing to Pharo 7

 When? 15 Feb 2018 5:00 PM - 7:00 PM (UTC+01:00)
 What? Contributing to Pharo7

We will show:
- How to submit issue tracker entries to the Pharo Issue Tracker
- How to do a Pull Request if you want to do a fix or enhancment
- How to review and comment other peoples fixes.

https://association.pharo.org/event-2797065





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

2018-02-13 Thread Cyril Ferlicot
On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader  wrote:
> Formulating the question helped me to find the solution after I posted:
>
> index
> ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello
> world') ]
>
> :)
>

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 
> 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



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

2018-02-13 Thread Sean P. DeNigris
Sven Van Caekenberghe-2 wrote
> There is also ZnHtmlOutputStream (a simple helper class) for generating
> syntactically correct HTML.

Yes, it's nice. I've used it in images when I needed to work with HTML
without Seaside loaded.



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



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

2018-02-13 Thread Herbert Vojčík



Denis Kudriashov wrote:


2018-02-13 10:25 GMT+01:00 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: [  ].


I really like this idea. We just need to represent undefined variable
value as special object instead of nil.


I don't like it for precisely this. In JS, there is undefined and null, 
and everyone hates that (despite maybe good intentions to split the two 
meanings).


#SomeGlobal inContextOf: self ifUndefined: [ ... ]

Maybe this could go if enough magic is done, though:

[ 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
> 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
> wrote:



2018-02-11 21:08 GMT+01:00 Stephane Ducasse
>:

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
> wrote:
>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand
>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov
>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > >:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov
>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > >:
>> >> >>
>> >> >> 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
 

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

2018-02-13 Thread Sven Van Caekenberghe


> On 13 Feb 2018, at 13:12, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> There is also ZnHtmlOutputStream (a simple helper class) for generating
>> syntactically correct HTML.
> 
> Yes, it's nice. I've used it in images when I needed to work with HTML
> without Seaside loaded.

It is way simpler though, Seaside's model is much better (but consists of lots 
of classes). YMMV


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

2018-02-13 Thread Sean P. DeNigris
Marcus Denker-4 wrote
> Sometimes I think we should treat globals more in a “late bound” fashion.

Late bound = power. I remember being very disappointed when I realized that
classes are early bound by methods (resolved in literals). This makes things
like class-side stubbing very difficult without jumping through hoops (e.g.
process variables).



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



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

2018-02-13 Thread 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 
>  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  > wrote:
> 
> 
> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse  >:
> 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  > wrote:
> >
> >
> > 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand  > >:
> >>
> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov  >> >:
> >> > Hi Hernan.
> >> >
> >> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
> >> > >:
> >> >>
> >> >> Hi Denis
> >> >>
> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov  >> >> >:
> >> >> >
> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
> >> >> > >:
> >> >> >>
> >> >> >> 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 

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

2018-02-13 Thread Denis Kudriashov
2018-02-13 10:25 GMT+01:00 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: [  ].
>

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  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 
> wrote:
>
>>
>>
>> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse :
>>
>>> 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 
>>> wrote:
>>> >
>>> >
>>> > 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <
>>> hernan.mora...@gmail.com>:
>>> >>
>>> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov :
>>> >> > Hi Hernan.
>>> >> >
>>> >> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>>> >> > :
>>> >> >>
>>> >> >> Hi Denis
>>> >> >>
>>> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov >> >:
>>> >> >> >
>>> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>>> >> >> > :
>>> >> >> >>
>>> >> >> >> 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 

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

2018-02-13 Thread Ben Coman
On 13 February 2018 at 17:25, Marcus Denker  wrote:

> Sometimes I think we should treat globals more in a “late bound” fashion.
>
>
This may remove a big reason for needing asClass, which was introduced so
you could DoIt
on a script to load a package and then operate on a class from that package
before that class was defined.



> 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.
>

I guess its partially a compiler issue.  One way would be for the compiler
to wrap the reference
to SomeGlobal in an instance of UnknownGlobal.  When a message is sent to
that instance,
it can check whether SomeGlobal is now defined (i.e. loaded earlier in the
script) and forward the message to SomeGlobal.



>
> Would that no be better than hiding it behind an API to look up symbols?
>
>
yes.

cheers -ben


> (just some thoughts, needs more thinking before action is possible)
>
> Marcus
>
> On 11 Feb 2018, at 22:12, 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 
> wrote:
>
>>
>>
>> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse :
>>
>>> 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 
>>> wrote:
>>> >
>>> >
>>> > 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <
>>> hernan.mora...@gmail.com>:
>>> >>
>>> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov :
>>> >> > Hi Hernan.
>>> >> >
>>> >> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>>> >> > :
>>> >> >>
>>> >> >> Hi Denis
>>> >> >>
>>> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov >> >:
>>> >> >> >
>>> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>>> >> >> > :
>>> >> >> >>
>>> >> >> >> 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, 

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

2018-02-13 Thread Siemen Baader
Thanks!

On Tue, Feb 13, 2018 at 9:51 AM, Cyril Ferlicot 
wrote:

> On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader 
> wrote:
> > Formulating the question helped me to find the solution after I posted:
> >
> > index
> > ^ [ :e | e add: (ILRawHtmlElement new contents: 'hello
> > world') ]
> >
> > :)
> >
>
> 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 
> > 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
>
>


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

2018-02-13 Thread 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


Re: [Pharo-users] Roassal to ODG

2018-02-13 Thread Alexandre Bergel
> So I want to re post my question:
>  "What is  the best option to generate an editable flow chart from Pharo 
> (Roassal)?”  

There are none as far as I know. However, this is something that can be done 
(rather easily I would say).

Alexandre


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

2018-02-13 Thread Siemen Baader
Thanks for the tip!

-- Siemen

On Mon, Feb 12, 2018 at 11:34 PM, Ben Coman  wrote:

>
>
> On 13 February 2018 at 01:57, Siemen Baader 
> wrote:
>
>> Hi Stef,
>>
>> On Sat, Feb 10, 2018 at 6:22 PM, Stephane Ducasse <
>> stepharo.s...@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 
>>> 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
>>>
>>>
>>
>


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

2018-02-13 Thread Steven Costiou
Hi, 

i think just doing 

e 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 
> world') ] 
> 
> :) 
> 
> cheers, 
> Siemen 
> 
> On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader  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 

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

2018-02-13 Thread Sven Van Caekenberghe


> On 13 Feb 2018, at 09:51, Cyril Ferlicot  wrote:
> 
> On Tue, Feb 13, 2018 at 9:20 AM, Siemen Baader  wrote:
>> Formulating the question helped me to find the solution after I posted:
>> 
>> index
>>^ [ :e | e add: (ILRawHtmlElement new contents: 'hello
>> world') ]
>> 
>> :)
>> 
> 
> 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:

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 
>> 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
> 




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

2018-02-13 Thread Siemen Baader
Formulating the question helped me to find the solution after I posted:

index
^ [ :e | e add: (ILRawHtmlElement new contents: 'hello
world') ]

:)

cheers,
Siemen


On Tue, Feb 13, 2018 at 9:14 AM, Siemen Baader 
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
>


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

2018-02-13 Thread Marcus Denker


> On 13 Feb 2018, at 11:32, Ben Coman  wrote:
> 
> 
> 
> On 13 February 2018 at 17:25, Marcus Denker  > wrote:
> Sometimes I think we should treat globals more in a “late bound” fashion.
> 
> 
> This may remove a big reason for needing asClass, which was introduced so you 
> could DoIt 
> on a script to load a package and then operate on a class from that package 
> before that class was defined.
> 
>  
> 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.
> 
> I guess its partially a compiler issue.  One way would be for the compiler to 
> wrap the reference
> to SomeGlobal in an instance of UnknownGlobal.  When a message is sent to 
> that instance, 
> it can check whether SomeGlobal is now defined (i.e. loaded earlier in the 
> script) and forward the message to SomeGlobal.
> 
The current Undeclared mechanism should make it easy: for every Undeclared, we 
do have a binding in Undeclared that binds the name
to nil. Could be another value (some first class object). Maybe it could even 
put as the value the binging itself, which is already
a subclass of Association called UndeclaredVariable.

Marcus




Re: [Pharo-users] Roassal to ODG

2018-02-13 Thread Arturo Zambrano
On Tue, Feb 13, 2018 at 7:27 AM, Alexandre Bergel 
wrote:

> > So I want to re post my question:
> >  "What is  the best option to generate an editable flow chart from Pharo
> (Roassal)?”
>
> There are none as far as I know. However, this is something that can be
> done (rather easily I would say).
>

Thanks, any direction?



>
> Alexandre
>


Re: [Pharo-users] Pillar questions

2018-02-13 Thread Guillermo Polito
Hi,



On Tue, Feb 13, 2018 at 4:21 PM, Arturo Zambrano 
wrote:

> Hi All,
>  Q1
>   Is there a way of adding page headers/footers in pillar?
>   header = image + short legend.
>   footer = line  + section name +  page number.
>

In html generation or pdf generation?

Usually all this is handled by the latex/html templates.


>
>   Q2
>My plan is to use Pillar programmatically, are you aware of some
> projects that use Pillar in that way?  Most of the documentation I found is
> regarding Pillar syntax.
>  The testcases are good examples, but I would like to see something more
> complex if possible.
>

There is ecstatic that is a little project that uses pillar programatically

https://github.com/guillep/ecstatic/

Otherwise, I'd recommend to use the latest pillar version in this branch:

https://github.com/pillar-markup/pillar/tree/newpipeline


>
>  Thanks!
> Arturo
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13


[Pharo-users] Pillar questions

2018-02-13 Thread Arturo Zambrano
Hi All,
 Q1
  Is there a way of adding page headers/footers in pillar?
  header = image + short legend.
  footer = line  + section name +  page number.

  Q2
   My plan is to use Pillar programmatically, are you aware of some
projects that use Pillar in that way?  Most of the documentation I found is
regarding Pillar syntax.
 The testcases are good examples, but I would like to see something more
complex if possible.

 Thanks!
Arturo


Re: [Pharo-users] [ANN] 15/2: Pharo TechTalk: Contributing to Pharo 7

2018-02-13 Thread Marcus Denker


> On 13 Feb 2018, at 13:03, Marcus Denker  wrote:
> 
> Pharo TechTalk: Contributing to Pharo 7
> 
> When? 15 Feb 2018 5:00 PM - 7:00 PM (UTC+01:00)
> What? Contributing to Pharo7
> 
> We will show:
>   - How to submit issue tracker entries to the Pharo Issue Tracker
>   - How to do a Pull Request if you want to do a fix or enhancment
>   - How to review and comment other peoples fixes.
> 
> https://association.pharo.org/event-2797065
> 
> 
Future TechTalks:

• March 29: Report 2017 Pharo Consortium and Association. 
https://association.pharo.org/event-2797067 

**DATE CHANGED from 22 to 29**

• April 12: Pillar.
https://association.pharo.org/event-2797068 


• May 17:   TBA 

• June 14 TBA

TBA —> Open Slot. Please send suggestions!


Marcus

Re: [Pharo-users] Pillar questions

2018-02-13 Thread Arturo Zambrano
Hi Stef

On Tue, Feb 13, 2018 at 2:18 PM, Stephane Ducasse 
wrote:

> Hi arturo
>
> Pillar is based on templates so you edit the template and add more
> variables.
>

got it


> In pillar 5 these variables are metadata so you should add a new one
> in the metadata declaration.
> Let me know if you need some screen sharing or some help.
>

I will play a bit and come back with more questions.

I assume that this is the main documentation source
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html

If there is more documentation to read, please let me know.

Thanks.
Best Regards




> stef
>
> On Tue, Feb 13, 2018 at 4:21 PM, Arturo Zambrano
>  wrote:
> > Hi All,
> >  Q1
> >   Is there a way of adding page headers/footers in pillar?
> >   header = image + short legend.
> >   footer = line  + section name +  page number.
> >
> >   Q2
> >My plan is to use Pillar programmatically, are you aware of some
> projects
> > that use Pillar in that way?  Most of the documentation I found is
> regarding
> > Pillar syntax.
> >  The testcases are good examples, but I would like to see something more
> > complex if possible.
> >
> >  Thanks!
> > Arturo
>
>


Re: [Pharo-users] Pillar questions

2018-02-13 Thread Arturo Zambrano
On Tue, Feb 13, 2018 at 12:25 PM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Hi,
>
>
>
> On Tue, Feb 13, 2018 at 4:21 PM, Arturo Zambrano <
> arturo.zambr...@gmail.com> wrote:
>
>> Hi All,
>>  Q1
>>   Is there a way of adding page headers/footers in pillar?
>>   header = image + short legend.
>>   footer = line  + section name +  page number.
>>
>
> In html generation or pdf generation?
>

any format, as I consider them an intermediate format
somehow, at end I will need Word document :(


>
> Usually all this is handled by the latex/html templates.
>

great!  thanks!.


>
>>
>>   Q2
>>My plan is to use Pillar programmatically, are you aware of some
>> projects that use Pillar in that way?  Most of the documentation I found is
>> regarding Pillar syntax.
>>  The testcases are good examples, but I would like to see something more
>> complex if possible.
>>
>
> There is ecstatic that is a little project that uses pillar programatically
>
> https://github.com/guillep/ecstatic/
>
> Otherwise, I'd recommend to use the latest pillar version in this branch:
>
> https://github.com/pillar-markup/pillar/tree/newpipeline
>
>

Thanks again Guillermo!

>
>>  Thanks!
>> Arturo
>>
>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>


Re: [Pharo-users] Pillar questions

2018-02-13 Thread Stephane Ducasse
Hi arturo

Pillar is based on templates so you edit the template and add more variables.
In pillar 5 these variables are metadata so you should add a new one
in the metadata declaration.
Let me know if you need some screen sharing or some help.

stef

On Tue, Feb 13, 2018 at 4:21 PM, Arturo Zambrano
 wrote:
> Hi All,
>  Q1
>   Is there a way of adding page headers/footers in pillar?
>   header = image + short legend.
>   footer = line  + section name +  page number.
>
>   Q2
>My plan is to use Pillar programmatically, are you aware of some projects
> that use Pillar in that way?  Most of the documentation I found is regarding
> Pillar syntax.
>  The testcases are good examples, but I would like to see something more
> complex if possible.
>
>  Thanks!
> Arturo



Re: [Pharo-users] Pillar questions

2018-02-13 Thread Stephane Ducasse
You have a booklet
https://github.com/SquareBracketAssociates/Booklet-PublishingAPillarBooklet
it is about Pillar 70 (mainly about book publishing) all the rest is
compatible with Pillar 50.

Stef


On Tue, Feb 13, 2018 at 6:34 PM, Arturo Zambrano
 wrote:
> Hi Stef
>
> On Tue, Feb 13, 2018 at 2:18 PM, Stephane Ducasse 
> wrote:
>>
>> Hi arturo
>>
>> Pillar is based on templates so you edit the template and add more
>> variables.
>
>
> got it
>
>>
>> In pillar 5 these variables are metadata so you should add a new one
>> in the metadata declaration.
>> Let me know if you need some screen sharing or some help.
>
>
> I will play a bit and come back with more questions.
>
> I assume that this is the main documentation source
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>
> If there is more documentation to read, please let me know.
>
> Thanks.
> Best Regards
>
>
>
>>
>> stef
>>
>> On Tue, Feb 13, 2018 at 4:21 PM, Arturo Zambrano
>>  wrote:
>> > Hi All,
>> >  Q1
>> >   Is there a way of adding page headers/footers in pillar?
>> >   header = image + short legend.
>> >   footer = line  + section name +  page number.
>> >
>> >   Q2
>> >My plan is to use Pillar programmatically, are you aware of some
>> > projects
>> > that use Pillar in that way?  Most of the documentation I found is
>> > regarding
>> > Pillar syntax.
>> >  The testcases are good examples, but I would like to see something more
>> > complex if possible.
>> >
>> >  Thanks!
>> > Arturo
>>
>



[Pharo-users] [ANN] Pharo Consortium New Platinum Member: ENSTA Bretagne

2018-02-13 Thread Marcus Denker
The Pharo Consortium is very happy to announce that ENSTA Bretagne
has joined the Consortium as a Platinum Member.

About
- ENSTA Bretagne: http://www.ensta-bretagne.fr
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to
support the ongoing development and future of Pharo.

Individuals can support Pharo via the Pharo Association:

- http://association.pharo.org