Re: [Pharo-dev] About Pharo 60

[Serge Stinckwich]

On Wed, Aug 31, 2016 at 9:16 PM, stepharo  wrote:
> In squeak by example
>
> we could tag in the document code snippet as text and a perl script
>
> turn the expression into Sunit method and run the tests
>
> We lost that.

Yes I remember this was very nice.

We should have a look to the org-babel env that I demonstrate shortly
during the ESUG "show us your project" session.
This based also on a markup language (org-mode) and you could use for
doing literate programming:
http://orgmode.org/worg/org-contrib/babel/

Some lessons should be extracted from that in order to enhance Pillar
in this direction also.

-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] About Pharo 60

[stepharo]

In squeak by example

we could tag in the document code snippet as text and a perl script

turn the expression into Sunit method and run the tests

We lost that.

Stef


Le 31/8/16 à 12:21, Peter Uhnak a écrit :

On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote:

Ok, now I know what I want.

I want a better way to document. Because I’m trying to write a documentation 
about my stuff, but there are too many disconnected ways to do that. I’m trying 
to always have reasonable class comments. But sometimes you need a more general 
description, so you write help topics which are disconnected from class 
comments. Yes, we can add help topics generated from class comments but that’s 
too weak. Additionally I version my projects on github, so I want t doc there 
in readme, or on a wiki. What’s more I think that it’s a good idea to export 
doc to the web. Because when someone mentioned package manifest I started to 
google for it and could not find anything.

My suggestions:
- write comments in pillar and slowly add pillar support to enrich comment 
(documentation) styles
- add a possibility to reference classes/methods and help topics from pillar 
comments
- have exporters to generate html documentation about a project based on 
comments and help topics
- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

This way we will have interconnected documentation in the image, and if it 
should be placed somewhere else we export it.

+14.

Knowing that I cannot verify that the documentation is sync with code is very 
discouraging to even start writing the docs. When I was writing a chapter for 
agile visualization, I had the examples as independent scripts which I could 
execute (I believe Pillar has added executable examples since then).

But there are more things than examples, e.g. a Travis could run "docs 
verification" that would look at all the code (so even method and class name 
references) and made sure they exist and are not, say, deprecated. As Pillar provides you 
with a real syntax tree this might not be so hard.

At least personally the above could be a real value for me with Pillar, because 
up until now it was just another document format (and there's a lot of better 
ones) with poor infrastructure. But deep integration with Pharo could make it 
really valuable, and we are getting there.


- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

so close :) 
https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOfIconFactory.package/BaselineOfIconFactory.class/class/updateReadme.st

Peter

Re: [Pharo-dev] About Pharo 60

[Peter Uhnak]

On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote:
> Ok, now I know what I want.
> 
> I want a better way to document. Because I’m trying to write a documentation 
> about my stuff, but there are too many disconnected ways to do that. I’m 
> trying to always have reasonable class comments. But sometimes you need a 
> more general description, so you write help topics which are disconnected 
> from class comments. Yes, we can add help topics generated from class 
> comments but that’s too weak. Additionally I version my projects on github, 
> so I want t doc there in readme, or on a wiki. What’s more I think that it’s 
> a good idea to export doc to the web. Because when someone mentioned package 
> manifest I started to google for it and could not find anything.
> 
> My suggestions:
> - write comments in pillar and slowly add pillar support to enrich comment 
> (documentation) styles
> - add a possibility to reference classes/methods and help topics from pillar 
> comments
> - have exporters to generate html documentation about a project based on 
> comments and help topics
> - then I will be able to add a hook to Icebeg telling it: ok, on commit also 
> generate a doc and export it as MarkDown (because we can) and commit it as a 
> README or as a wiki entry or whatever.
> 
> This way we will have interconnected documentation in the image, and if it 
> should be placed somewhere else we export it.

+14.

Knowing that I cannot verify that the documentation is sync with code is very 
discouraging to even start writing the docs. When I was writing a chapter for 
agile visualization, I had the examples as independent scripts which I could 
execute (I believe Pillar has added executable examples since then).

But there are more things than examples, e.g. a Travis could run "docs 
verification" that would look at all the code (so even method and class name 
references) and made sure they exist and are not, say, deprecated. As Pillar 
provides you with a real syntax tree this might not be so hard.

At least personally the above could be a real value for me with Pillar, because 
up until now it was just another document format (and there's a lot of better 
ones) with poor infrastructure. But deep integration with Pharo could make it 
really valuable, and we are getting there.

> - then I will be able to add a hook to Icebeg telling it: ok, on commit also 
> generate a doc and export it as MarkDown (because we can) and commit it as a 
> README or as a wiki entry or whatever.

so close :) 
https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOfIconFactory.package/BaselineOfIconFactory.class/class/updateReadme.st

Peter

Re: [Pharo-dev] About Pharo 60

[Yuriy Tymchuk]

Ok, now I know what I want.

I want a better way to document. Because I’m trying to write a documentation 
about my stuff, but there are too many disconnected ways to do that. I’m trying 
to always have reasonable class comments. But sometimes you need a more general 
description, so you write help topics which are disconnected from class 
comments. Yes, we can add help topics generated from class comments but that’s 
too weak. Additionally I version my projects on github, so I want t doc there 
in readme, or on a wiki. What’s more I think that it’s a good idea to export 
doc to the web. Because when someone mentioned package manifest I started to 
google for it and could not find anything.

My suggestions:
- write comments in pillar and slowly add pillar support to enrich comment 
(documentation) styles
- add a possibility to reference classes/methods and help topics from pillar 
comments
- have exporters to generate html documentation about a project based on 
comments and help topics
- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

This way we will have interconnected documentation in the image, and if it 
should be placed somewhere else we export it.

Cheers.
Uko

> On 24 Aug 2016, at 06:59, stepharo  wrote:
> 
> Hi
> 
> We have some ideas (because people are working on items) for the Pharo 6 
> roadmap
> 
> and we will consolidate them soon and propose them to you.
> 
> but I would like to know two kinds of points
> 
>- what are the points you are working on and that would deserve more focus 
> and help from the community?
> 
>(these points are important because like that you could go faster and 
> this is a good feeling to get done for example)
> 
>- what would be points where (if magically we would get more resources - 
> to not dream if this is not you
> 
>there is a high chance that we will not make it) it would be nice to 
> get some changes
> 
> 
> Please pay attention that if you type too fast and come up with a christmas 
> list well it will stay a christmas list and will just make the thread larger 
> for nothing.
> 
> Stef
> 
> 

Re: [Pharo-dev] About Pharo 60

[stepharo]

Additionally I would like to see:

  - investigation in the Win Pharo VM for being able to run again as 
a Windows Service
(as it was possible for Squeak) to be able to easily provide, 
deploy and administrate a web

app on Windows

Definitively. Thanks for mentionning it. It will be done by PharoPro :)


  - image size management under control (as Philip already suggested)

  - better support for REST based systems (as Philip already suggested)
Can you be clearer? Because I thought that Seaside-REST was good and you 
can apply to non Seaside Application.

Then there is Teapot.
As Pharo core I do not see why Zinc is not enough. Now fr Pharo Pro I 
could see.


  - modern "Material style" UI (as Philip already suggested) but 
additionally with

better out of the box Spec support and examples for regular widgets
(Accordion, draggable Toolbars, calendar widget, date/time 
picker, ...)


  - clear rules to not accept undocumented classes/packages in the image
And a clear separation in packages between CORE/BASE stuff and 
TESTS on top.


Tests are already separated. Do you have some places where this is not 
the case?
Because TEST are usually only for development and for 
production/deployment of an app

TESTS usually should be thrown out.

Christmas list would include:
  - 64 Bit support

This is not a christmas list. It should be threr for September.



  - an out of the box Pharo Pi VM + image on the website

Bye
T.

Re: [Pharo-dev] About Pharo 60

[stepharo]

Thanks

we are currently brainstorming with esteban on the pharo pro offer and 
this is nice to have your feedback.


Stef


Le 28/8/16 à 15:33, Torsten Bergmann a écrit :

what are the points you are working on and that would deserve more focus and 
help from the community?

I once started with a refactored version of GetText, covered with tests and 
tools.
Code status I reached so far is here:

   http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext

Idea was to be lean, no dependency on Seaside or others and get a well 
documented easy to use I18N solution.
This would open up the possibility for more internationalized Pharo image and 
Pharo based apps. Would be nice
if this could be completed and become part of our infrastructure to get a wider 
audience and globally usable
applications.

Additionally I would like to see:

  - investigation in the Win Pharo VM for being able to run again as a Windows 
Service
(as it was possible for Squeak) to be able to easily provide, deploy and 
administrate a web
app on Windows

  - image size management under control (as Philip already suggested)

  - better support for REST based systems (as Philip already suggested)

  - modern "Material style" UI (as Philip already suggested) but additionally 
with
better out of the box Spec support and examples for regular widgets
(Accordion, draggable Toolbars, calendar widget, date/time picker, ...)

  - clear rules to not accept undocumented classes/packages in the image
And a clear separation in packages between CORE/BASE stuff and TESTS on top.
Because TEST are usually only for development and for production/deployment 
of an app
TESTS usually should be thrown out.

Christmas list would include:
  - 64 Bit support
  - an out of the box Pharo Pi VM + image on the website

Bye
T.

Re: [Pharo-dev] About Pharo 60

[Torsten Bergmann]

> what are the points you are working on and that would deserve more focus and 
> help from the community?

I once started with a refactored version of GetText, covered with tests and 
tools. 
Code status I reached so far is here:

  http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext

Idea was to be lean, no dependency on Seaside or others and get a well 
documented easy to use I18N solution. 
This would open up the possibility for more internationalized Pharo image and 
Pharo based apps. Would be nice
if this could be completed and become part of our infrastructure to get a wider 
audience and globally usable
applications.

Additionally I would like to see:

 - investigation in the Win Pharo VM for being able to run again as a Windows 
Service 
   (as it was possible for Squeak) to be able to easily provide, deploy and 
administrate a web 
   app on Windows

 - image size management under control (as Philip already suggested)

 - better support for REST based systems (as Philip already suggested)

 - modern "Material style" UI (as Philip already suggested) but additionally 
with
   better out of the box Spec support and examples for regular widgets 
   (Accordion, draggable Toolbars, calendar widget, date/time picker, ...)

 - clear rules to not accept undocumented classes/packages in the image
   And a clear separation in packages between CORE/BASE stuff and TESTS on top.
   Because TEST are usually only for development and for production/deployment 
of an app
   TESTS usually should be thrown out.

Christmas list would include:
 - 64 Bit support
 - an out of the box Pharo Pi VM + image on the website

Bye
T.

Re: [Pharo-dev] About Pharo 60

[Tudor Girba]

Hi,

The answer was that Spotter is not different in any way than any other global 
shortcut. This means that if we want to have an interactive solution, we should 
do it at the level of the Keymapping framework not at the level of individual 
tools.

In the meantime, how do we manage this? Inspect:
KMRepository default




If you want to remove all of them you can do:
KMRepository default globalCategories removeAll

Given that producing an end-user image should rely on a script, I think this 
solution pragmatic enough. 

Or do I miss something?

Cheers,
Doru


> On Aug 27, 2016, at 2:32 PM, Esteban Lorenzano  wrote:
> 
> yes, some years ago I made a package for this. 
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to 
> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
> have a setting, no idea who answered you that but he is wrong), and image is 
> not prepared for that.
> 
> of course is still possible :)
> 
> anyway, today I would tackle a solution in a different way: I would open my 
> app morph on an SDL2 window and not touch the word at all (opening a headless 
> image). This is not possible in windows because when you do “headless” it 
> just laugh at you, but is doable in the not-so-long term.
> 
> Esteban
> 
>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:
>> 
>> Le 27/08/2016 à 13:18, stepharo a écrit :
>>> 
>>> 
>>> YES!!!
>>> 
>>> Do you know how Settings works?
>>> We can adapt it this way.
>> 
>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not needed.".
>> 
>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>> 
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
>> 
>>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>>> was not good because it was not modular. Now each part of the system
>>> should be
>>> defined in way that it can be set just as a setting.
>>> We should not have
>>> 
>>> World
>>>   User current = ifTrue
>>> 
>>> But
>>> 
>>> World use: userSetting
>>> 
>>> and World should handle it.
>>> There is way more to do :)
>>> When you deploy on linux you should be able to say beSilent to the
>>> system (do not write on places that you cannot).
>>> Valentin works on it and we should continue
>>> 
>>> Stef
>>> 
>> 
>> The fact that there is much more to do is the main reason for Pharo to
>> do it and not the developer. The developer cannot know all the system
>> and will not be able to protect the code of his company well because he
>> will forget something as to disable ctrl+o+p (or he is a god developer!
>> But everyone is not).
>> 
>> This is a large thing to do, so it would be cool that everyone keep that
>> in mind to allow it little by little (as with the work of Valentin).
>> 
>> -- 
>> Cyril Ferlicot
>> 
>> http://www.synectique.eu
>> 
>> 165 Avenue Bretagne
>> Lille 59000 France
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

> On 28 Aug 2016, at 00:55, Cyril Ferlicot D.  wrote:
> 
> Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this. 
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to 
>> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
>> have a setting, no idea who answered you that but he is wrong), and image is 
>> not prepared for that.
>> 
> 
> I checked the issue tracker and it was closed because people though that
> we need a better way to disable shortcuts in general and that it is not
> specific to Spotter.
> 
> https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter
> 
> But we still cannot disable/enable Spotter without hacking into KM :(
> I think that sometimes it is good to think about a generic solution, but
> we still can get a temporary one because everyone cannot wait 3 years
> that the good one works. We can still let a flag "Remove this temporary
> solution after we finish ”.

ok, I will re-open it because this is not about shourtcuts, is about enabling 
or disabling a tool. The fact that this tool is called with a shortcut is just 
a detail… and also is incomplete: a good setting should also remove spotter 
from world menu, for example.

Esteban

> 
> 
>> of course is still possible :)
>> 
>> anyway, today I would tackle a solution in a different way: I would open my 
>> app morph on an SDL2 window and not touch the word at all (opening a 
>> headless image). This is not possible in windows because when you do 
>> “headless” it just laugh at you, but is doable in the not-so-long term.
>> 
>> Esteban
>> 
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

Re: [Pharo-dev] About Pharo 60

[stepharo]

Thanks Cyril

Now we have to check what is synectique specific from what should be 
pushed to Pharo.



Since we moved to a Seaside application not so long after I joined
Synectique we only disable some basic things.

If I don't say anything wrong here is what we did:
- Remove repositories containing "Synectique" in the name
- Reset all passwords (MCHttpRepository clearPasswords)
- Install a custom world menu (WorldState desktopMenuPragmaKeyword: 'XXX')
- Remove Halos (At the time I created an issue to be able to do `Morph
halosEnabled: false`, but it would be useful to make that a setting)
- Remove Spotter ((KMRepository default globalCategories detect: [ :each
| each isKindOf: GTSpotterGlobalShortcut ]) allEntries keymaps do:
#disable)
- Usman also added a transparent Morph that could catch some shortcuts I
think and that would block some actions. We could disabled it with a
dialog and a password.


Now this is important to see that if people for which the value is high
do not work on something
why others would do it.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not
needed.".

I do not know how to do it either. So we should document that.

What I did:

(KMRepository default globalCategories detect: [ :each | each isKindOf:
GTSpotterGlobalShortcut ]) allEntries keymaps do: #disable

Ugly I know but it worked and was only called once in the CI.


People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

No you should care because one day you will come with a new requirement :)
I understand what you mean but the point is that Pharo is our common
architecture
so we should just all pay attention and we cannot ask people to do
everything because
we all have 24 h a day. So we should be smart, share and build together.

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
> yes, some years ago I made a package for this. 
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to 
> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
> have a setting, no idea who answered you that but he is wrong), and image is 
> not prepared for that.
> 

I checked the issue tracker and it was closed because people though that
we need a better way to disable shortcuts in general and that it is not
specific to Spotter.

https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter

But we still cannot disable/enable Spotter without hacking into KM :(
I think that sometimes it is good to think about a generic solution, but
we still can get a temporary one because everyone cannot wait 3 years
that the good one works. We can still let a flag "Remove this temporary
solution after we finish ".


> of course is still possible :)
> 
> anyway, today I would tackle a solution in a different way: I would open my 
> app morph on an SDL2 window and not touch the word at all (opening a headless 
> image). This is not possible in windows because when you do “headless” it 
> just laugh at you, but is doable in the not-so-long term.
> 
> Esteban
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 14:39, stepharo a écrit :
> Cyril what would be good is to share what you are disabling and to tunr
> such points into points that can be turned
> but inside Pharo like that you push the logic to the system.
> 

Since we moved to a Seaside application not so long after I joined
Synectique we only disable some basic things.

If I don't say anything wrong here is what we did:
- Remove repositories containing "Synectique" in the name
- Reset all passwords (MCHttpRepository clearPasswords)
- Install a custom world menu (WorldState desktopMenuPragmaKeyword: 'XXX')
- Remove Halos (At the time I created an issue to be able to do `Morph
halosEnabled: false`, but it would be useful to make that a setting)
- Remove Spotter ((KMRepository default globalCategories detect: [ :each
| each isKindOf: GTSpotterGlobalShortcut ]) allEntries keymaps do:
#disable)
- Usman also added a transparent Morph that could catch some shortcuts I
think and that would block some actions. We could disabled it with a
dialog and a password.

> Now this is important to see that if people for which the value is high
> do not work on something
> why others would do it.

>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not
>> needed.".
> 
> I do not know how to do it either. So we should document that.

What I did:

(KMRepository default globalCategories detect: [ :each | each isKindOf:
GTSpotterGlobalShortcut ]) allEntries keymaps do: #disable

Ugly I know but it worked and was only called once in the CI.

>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>>
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
> No you should care because one day you will come with a new requirement :)
> I understand what you mean but the point is that Pharo is our common
> architecture
> so we should just all pay attention and we cannot ask people to do
> everything because
> we all have 24 h a day. So we should be smart, share and build together.
>

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

> On 27 Aug 2016, at 14:40, stepharo  wrote:
> 
> Hi esteban
> 
> I think that we should identify the main hook points and slowly prepare them.
> 
> The system should be prepared for that so that we just need to pass a context 
> to configure it.

.. I should have that old package somewhere… it will not work, and it was not 
very subtle… but it has to be somewhere :)

Esteban 

> 
> Stef
> 
> 
> Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this.
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to 
>> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
>> have a setting, no idea who answered you that but he is wrong), and image is 
>> not prepared for that.
>> 
>> of course is still possible :)
>> 
>> anyway, today I would tackle a solution in a different way: I would open my 
>> app morph on an SDL2 window and not touch the word at all (opening a 
>> headless image). This is not possible in windows because when you do 
>> “headless” it just laugh at you, but is doable in the not-so-long term.
>> 
>> Esteban
>> 
>>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  
>>> wrote:
>>> 
>>> Le 27/08/2016 à 13:18, stepharo a écrit :
 
 YES!!!
 
 Do you know how Settings works?
 We can adapt it this way.
>>> When I improved the deployment of Synectique Tools I asked to get a
>>> simple way to disable Spotter via a setting but I got as answer "No
>>> because you can do it by removing a global shortcut so it is not needed.".
>>> 
>>> People in companies don't have the time to learn how shortcuts work and
>>> how to remove one without impacting something else. And they don't have
>>> the time to check Spotter code to know how it is call.
>>> 
>>> If the image is able to have a deployment mode then I don't care how
>>> Spotter is disabled (setting or removing a shortcut). But for now we
>>> don't have it. :)
>>> 
 I mean the User approach that Benjmain proposed and was pushed in Pharo
 was not good because it was not modular. Now each part of the system
 should be
 defined in way that it can be set just as a setting.
 We should not have
 
 World
User current = ifTrue
 
 But
 
 World use: userSetting
 
 and World should handle it.
 There is way more to do :)
 When you deploy on linux you should be able to say beSilent to the
 system (do not write on places that you cannot).
 Valentin works on it and we should continue
 
 Stef
 
>>> The fact that there is much more to do is the main reason for Pharo to
>>> do it and not the developer. The developer cannot know all the system
>>> and will not be able to protect the code of his company well because he
>>> will forget something as to disable ctrl+o+p (or he is a god developer!
>>> But everyone is not).
>>> 
>>> This is a large thing to do, so it would be cool that everyone keep that
>>> in mind to allow it little by little (as with the work of Valentin).
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> 
>>> http://www.synectique.eu
>>> 
>>> 165 Avenue Bretagne
>>> Lille 59000 France
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] About Pharo 60

[stepharo]

Hi esteban

I think that we should identify the main hook points and slowly prepare 
them.


The system should be prepared for that so that we just need to pass a 
context to configure it.


Stef


Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :

yes, some years ago I made a package for this.
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” 
a lot of things…  (not just the spotter… which by the way, NEEDS to have a 
setting, no idea who answered you that but he is wrong), and image is not 
prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app 
morph on an SDL2 window and not touch the word at all (opening a headless 
image). This is not possible in windows because when you do “headless” it just 
laugh at you, but is doable in the not-so-long term.

Esteban


On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:

Le 27/08/2016 à 13:18, stepharo a écrit :


YES!!!

Do you know how Settings works?
We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)


I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World
User current = ifTrue

But

World use: userSetting

and World should handle it.
There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef


The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

Re: [Pharo-dev] About Pharo 60

[stepharo]

Cyril what would be good is to share what you are disabling and to tunr 
such points into points that can be turned

but inside Pharo like that you push the logic to the system.

Now this is important to see that if people for which the value is high 
do not work on something

why others would do it.

YES!!!

Do you know how Settings works?
We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".


I do not know how to do it either. So we should document that.

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

No you should care because one day you will come with a new requirement :)
I understand what you mean but the point is that Pharo is our common 
architecture
so we should just all pay attention and we cannot ask people to do 
everything because

we all have 24 h a day. So we should be smart, share and build together.




I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World
 User current = ifTrue

But

World use: userSetting

and World should handle it.
There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef


The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

yes, some years ago I made a package for this. 
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” 
a lot of things…  (not just the spotter… which by the way, NEEDS to have a 
setting, no idea who answered you that but he is wrong), and image is not 
prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app 
morph on an SDL2 window and not touch the word at all (opening a headless 
image). This is not possible in windows because when you do “headless” it just 
laugh at you, but is doable in the not-so-long term.

Esteban

> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:
> 
> Le 27/08/2016 à 13:18, stepharo a écrit :
>> 
>> 
>> YES!!!
>> 
>> Do you know how Settings works?
>> We can adapt it this way.
> 
> When I improved the deployment of Synectique Tools I asked to get a
> simple way to disable Spotter via a setting but I got as answer "No
> because you can do it by removing a global shortcut so it is not needed.".
> 
> People in companies don't have the time to learn how shortcuts work and
> how to remove one without impacting something else. And they don't have
> the time to check Spotter code to know how it is call.
> 
> If the image is able to have a deployment mode then I don't care how
> Spotter is disabled (setting or removing a shortcut). But for now we
> don't have it. :)
> 
>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>> was not good because it was not modular. Now each part of the system
>> should be
>> defined in way that it can be set just as a setting.
>> We should not have
>> 
>> World
>>User current = ifTrue
>> 
>> But
>> 
>> World use: userSetting
>> 
>> and World should handle it.
>> There is way more to do :)
>> When you deploy on linux you should be able to say beSilent to the
>> system (do not write on places that you cannot).
>> Valentin works on it and we should continue
>> 
>> Stef
>> 
> 
> The fact that there is much more to do is the main reason for Pharo to
> do it and not the developer. The developer cannot know all the system
> and will not be able to protect the code of his company well because he
> will forget something as to disable ctrl+o+p (or he is a god developer!
> But everyone is not).
> 
> This is a large thing to do, so it would be cool that everyone keep that
> in mind to allow it little by little (as with the work of Valentin).
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 13:18, stepharo a écrit :
> 
> 
> YES!!!
> 
> Do you know how Settings works?
> We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

> I mean the User approach that Benjmain proposed and was pushed in Pharo
> was not good because it was not modular. Now each part of the system
> should be
> defined in way that it can be set just as a setting.
> We should not have
> 
> World
> User current = ifTrue
> 
> But
> 
> World use: userSetting
> 
> and World should handle it.
> There is way more to do :)
> When you deploy on linux you should be able to say beSilent to the
> system (do not write on places that you cannot).
> Valentin works on it and we should continue
> 
> Stef
> 

The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About Pharo 60

[stepharo]

Hi!

There is one thing I would like, but maybe not for Pharo6 since there is
a lot to do, but I would like people to have this in mind: A way to
deploy commercials apps.


YES!!!



I would like to be able to say something like "Smalltalk
lockForDeployment" and "Smalltalk prepareForDeployment" for example.

The first one could just lock the access to the image and let a way to
get them back if you have a password. The second could unload everything
that you don't want for production if you don't plan to debug the image
if there is a problem.

Do you know how Settings works?
We can adapt it this way.
I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system 
should be

defined in way that it can be set just as a setting.
We should not have

World
User current = ifTrue

But

World use: userSetting

and World should handle it.

At Synectique when we had a desktop application it was really hard to
lock everything :(
- Disable Halo
- Disable Spotter
- Disable the shortcuts to open a playground, a Nautilus, anything else
that the application
- Remove the private repositories and credentials just in case the
client find a way to get through and get a Monticello
- …

We should not have to do all that. Else Pharo will only be used to build
commencial web applications where the image is on the company's server
and not on the client's server. :(

There is way more to do :)
When you deploy on linux you should be able to say beSilent to the 
system (do not write on places that you cannot).

Valentin works on it and we should continue

Stef

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 24/08/2016 à 06:59, stepharo a écrit :
> Hi
> 
> We have some ideas (because people are working on items) for the Pharo 6
> roadmap
> 
> and we will consolidate them soon and propose them to you.
> 
> but I would like to know two kinds of points
> 
> - what are the points you are working on and that would deserve more
> focus and help from the community?
> 
> (these points are important because like that you could go
> faster and this is a good feeling to get done for example)
> 
> - what would be points where (if magically we would get more
> resources - to not dream if this is not you
> 
> there is a high chance that we will not make it) it would be
> nice to get some changes
> 
> 
> Please pay attention that if you type too fast and come up with a
> christmas list well it will stay a christmas list and will just make the
> thread larger for nothing.
> 
> Stef
> 
> 


Hi!

There is one thing I would like, but maybe not for Pharo6 since there is
a lot to do, but I would like people to have this in mind: A way to
deploy commercials apps.

I would like to be able to say something like "Smalltalk
lockForDeployment" and "Smalltalk prepareForDeployment" for example.

The first one could just lock the access to the image and let a way to
get them back if you have a password. The second could unload everything
that you don't want for production if you don't plan to debug the image
if there is a problem.

At Synectique when we had a desktop application it was really hard to
lock everything :(
- Disable Halo
- Disable Spotter
- Disable the shortcuts to open a playground, a Nautilus, anything else
that the application
- Remove the private repositories and credentials just in case the
client find a way to get through and get a Monticello
- …

We should not have to do all that. Else Pharo will only be used to build
commencial web applications where the image is on the company's server
and not on the client's server. :(

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About Pharo 60

[Dimitris Chloupis]

My Christmas list is divided to 2 sections a) What I want from you b) What
I am going to deliver

*What I want from you*


The things I want from Pharo are centered on the high priorities

a) 64 bit version
b) Bloc /SDL
c) FFI documentation / stabilization

Its fine if you deliver after christmas or even a year later, I am in no
hurry.

*What I am going to deliver ( Unreal 4 for Pharo)*


Because previously I wanted to target the iOS and Android markets for my
games, I could not included Pharo in my plans because both iOS and Android
demands a single executable and no DLLs .

However I discovered that as a market Steam alone is as large , so I will
be targeting Steam instead since my games are more suited for  PC (strategy
/ adventure / rpg) anyway. Windows and Macos will be my focus.

This means I can now use Pharo with Unreal (One also big reason to choose
Steam and drop iOS and Android) , which further means that around Christmas
Ephestos v1 most likely will be released which will allow for Pharo to be
used as a scripting engine for Unreal for people who want to create games
or other kind of interactive graphics / multimedia.

But I make no promises because I am still learning Unreal , however because
already my socket bridge worked well for using python libraries from Pharo,
I will do something similar for Unreal too.

In long term I am considering also a Pharo to C++ transpiler but that is a
low priority for now.

Essentially Ephestos will be the basis upon which I will be building my
commercial games so its a very long term project.

Disclaimer: Knowledge of Unreal will be required



On Wed, Aug 24, 2016 at 8:00 AM stepharo  wrote:

> Hi
>
> We have some ideas (because people are working on items) for the Pharo 6
> roadmap
>
> and we will consolidate them soon and propose them to you.
>
> but I would like to know two kinds of points
>
>  - what are the points you are working on and that would deserve
> more focus and help from the community?
>
>  (these points are important because like that you could go
> faster and this is a good feeling to get done for example)
>
>  - what would be points where (if magically we would get more
> resources - to not dream if this is not you
>
>  there is a high chance that we will not make it) it would be
> nice to get some changes
>
>
> Please pay attention that if you type too fast and come up with a
> christmas list well it will stay a christmas list and will just make the
> thread larger for nothing.
>
> Stef
>
>
>

Re: [Pharo-dev] About Pharo 60

[stepharo]

Le 26/8/16 à 14:40, Norbert Hartl a écrit :

Hi,

the things I want to have are 64bit, bootstrap and vector graphic 
backend because these are so disruptive that it takes some time to 
stabilize the whole system. But there is a roadmap for this which is 
ok for me.


For me we really need to focus on stabilizing a few things which are 
(to me) very annoying:


- cannot escape execution with cmd-. sometimes.

Yes we should check that with denis
- endless loop in Context with DNU for sending the same message again 
(https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop)
- spotter opening is too slow. You open spotter and when you type too 
early it shows nothing and you need to close it

- unifying keyboard shortcuts
- tiny and misplaced buttons in GTDebugger

:) I fully agree on this one.
- tree view in GTInspector. It is absolutely terrible that if you try 
to uncollapse a tree node on the right pane and you did not hit 
exactly the pane moves to the left. That is sooo…..!"!§$"%§%§%
- Nautilus method caching. You can have code views that get not 
updated when the method changes and not even sometimes when you close 
and reopen the browser.
Do you have a scenario? I would like to see what I can do. I would like 
to do another pass.
- good integration of epicea. The old changes mechanism was just 
broken so I'm glad epicea is in place now


The other big thing for me is that we need to do project dependencies 
right. I think the bootstrap guys know.

at least we will fix the ones in the image :)
The way we reference metacello projects from other projects quickly 
produces a situation that you load the maximum set in your image. We 
should have guidelines how to do configurations or any other mechanism 
so that not only the bootstrap can load cleanly but business project 
images as well. Let's call it dependency management
I think that the dependencies should be computed for us from a tool like 
the dependency browser and proposed

to us.


my christmas list would be:

- runtime adaptable behaviour. Be it runtime traits, talents, etc…
- environments to separate graphs for certain dimensions like code 
version, etc.

- magritte replacement with slots


These ones are more researchy but I was recently rereading talents.
Do you have a scenario for talents?



Norbert


Am 24.08.2016 um 06:59 schrieb stepharo >:


Hi

We have some ideas (because people are working on items) for the 
Pharo 6 roadmap


and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

   - what are the points you are working on and that would deserve 
more focus and help from the community?


   (these points are important because like that you could go 
faster and this is a good feeling to get done for example)


   - what would be points where (if magically we would get more 
resources - to not dream if this is not you


   there is a high chance that we will not make it) it would be 
nice to get some changes



Please pay attention that if you type too fast and come up with a 
christmas list well it will stay a christmas list and will just make 
the thread larger for nothing.


Stef

Re: [Pharo-dev] About Pharo 60

[stepharo]

List:

* image size management under control
Yes it requires to write a new GC so I hope that the VM team with get 
the ressources.



* no more gradients in that UI (even in the light theme)
* modern "Material style" UI
* FASTER Nautilus

what is the problem?

* better console support (in/out)

stdout and friends do not work?


* Pharo VM as something I can embed in other programs
* something like npm.js for the packages list along with external 
package manager to build my images

We will have that with Cargo

* integration with Hadoop ecosystem
* super easy to write REST clients and servers (including Swagger support)

I think that this is not the roadmap for Pharo 60 but for the community.



Phil


On Fri, Aug 26, 2016 at 10:15 AM, stepharo > wrote:


Thanks Peter


I cannot find the list, but there were some things we discussed
during consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec
  * Roadmap so we know where we are going,
  * with clean API,
  * so we can build really live UIs (where you can drag windows
around, close them, dock them, etc.
  * so we are ready for Bloc (can be for Easter too :))
* Stability
  * I crash daily

Obviously I can and I try to help with Spec, but I do not have
the time or resources to lead it, and since we don't have any
roadmap it's hard to go forward.


I should say that I'm a bit stuck to understand where to start
and what we want to achieve.
The firs things I would do
- Reading all the code to get a feel.
- I would like to rename the class consistently a Model
should be named Presenter and the Model whose name do not contain
Model should still be renamed to contain Presenter.

I need to review the changes made by marion and that have been
published.

Stef

Re: [Pharo-dev] About Pharo 60

[Norbert Hartl]

Hi,

the things I want to have are 64bit, bootstrap and vector graphic backend 
because these are so disruptive that it takes some time to stabilize the whole 
system. But there is a roadmap for this which is ok for me.

For me we really need to focus on stabilizing a few things which are (to me) 
very annoying:

- cannot escape execution with cmd-. sometimes. 
- endless loop in Context with DNU for sending the same message again 
(https://pharo.fogbugz.com/f/cases/16877/another-endless-debugger-loop 
)
- spotter opening is too slow. You open spotter and when you type too early it 
shows nothing and you need to close it
- unifying keyboard shortcuts
- tiny and misplaced buttons in GTDebugger
- tree view in GTInspector. It is absolutely terrible that if you try to 
uncollapse a tree node on the right pane and you did not hit exactly the pane 
moves to the left. That is sooo…..!"!§$"%§%§%
- Nautilus method caching. You can have code views that get not updated when 
the method changes and not even sometimes when you close and reopen the 
browser. 
- good integration of epicea. The old changes mechanism was just broken so I'm 
glad epicea is in place now

The other big thing for me is that we need to do project dependencies right. I 
think the bootstrap guys know. The way we reference metacello projects from 
other projects quickly produces a situation that you load the maximum set in 
your image. We should have guidelines how to do configurations or any other 
mechanism so that not only the bootstrap can load cleanly but business project 
images as well. Let's call it dependency management

my christmas list would be:

- runtime adaptable behaviour. Be it runtime traits, talents, etc…
- environments to separate graphs for certain dimensions like code version, etc.
- magritte replacement with slots


Norbert


> Am 24.08.2016 um 06:59 schrieb stepharo :
> 
> Hi
> 
> We have some ideas (because people are working on items) for the Pharo 6 
> roadmap
> 
> and we will consolidate them soon and propose them to you.
> 
> but I would like to know two kinds of points
> 
>- what are the points you are working on and that would deserve more focus 
> and help from the community?
> 
>(these points are important because like that you could go faster and 
> this is a good feeling to get done for example)
> 
>- what would be points where (if magically we would get more resources - 
> to not dream if this is not you
> 
>there is a high chance that we will not make it) it would be nice to 
> get some changes
> 
> 
> Please pay attention that if you type too fast and come up with a christmas 
> list well it will stay a christmas list and will just make the thread larger 
> for nothing.
> 
> Stef
> 
> 

Re: [Pharo-dev] About Pharo 60

[p...@highoctane.be]

List:

* image size management under control
* no more gradients in that UI (even in the light theme)
* modern "Material style" UI
* FASTER Nautilus
* better console support (in/out)
* Pharo VM as something I can embed in other programs
* something like npm.js for the packages list along with external package
manager to build my images
* integration with Hadoop ecosystem
* super easy to write REST clients and servers (including Swagger support)

Phil


On Fri, Aug 26, 2016 at 10:15 AM, stepharo  wrote:

> Thanks Peter
>
> I cannot find the list, but there were some things we discussed during
> consortium call a month or so ago. Maybe Esteban can find it?
>
> I want for Christmas
>
> * Better Spec
>   * Roadmap so we know where we are going,
>   * with clean API,
>   * so we can build really live UIs (where you can drag windows around,
> close them, dock them, etc.
>   * so we are ready for Bloc (can be for Easter too :))
> * Stability
>   * I crash daily
>
> Obviously I can and I try to help with Spec, but I do not have the time or
> resources to lead it, and since we don't have any roadmap it's hard to go
> forward.
>
>
> I should say that I'm a bit stuck to understand where to start and
> what we want to achieve.
> The firs things I would do
> - Reading all the code to get a feel.
> - I would like to rename the class consistently a Model should be
> named Presenter and the Model whose name do not contain Model should still
> be renamed to contain Presenter.
>
> I need to review the changes made by marion and that have been
> published.
>
> Stef
>
>
>
>
>
>
>

Re: [Pharo-dev] About Pharo 60

[stepharo]

Thanks Peter

I cannot find the list, but there were some things we discussed during 
consortium call a month or so ago. Maybe Esteban can find it?


I want for Christmas

* Better Spec
  * Roadmap so we know where we are going,
  * with clean API,
  * so we can build really live UIs (where you can drag windows 
around, close them, dock them, etc.

  * so we are ready for Bloc (can be for Easter too :))
* Stability
  * I crash daily

Obviously I can and I try to help with Spec, but I do not have the 
time or resources to lead it, and since we don't have any roadmap it's 
hard to go forward.


I should say that I'm a bit stuck to understand where to start and 
what we want to achieve.

The firs things I would do
- Reading all the code to get a feel.
- I would like to rename the class consistently a Model should 
be named Presenter and the Model whose name do not contain Model should 
still be renamed to contain Presenter.


I need to review the changes made by marion and that have been 
published.


Stef

Re: [Pharo-dev] About Pharo 60

[Peter Uhnák]

I cannot find the list, but there were some things we discussed during
consortium call a month or so ago. Maybe Esteban can find it?

I want for Christmas

* Better Spec
  * Roadmap so we know where we are going,
  * with clean API,
  * so we can build really live UIs (where you can drag windows around,
close them, dock them, etc.
  * so we are ready for Bloc (can be for Easter too :))
* Stability
  * I crash daily

Obviously I can and I try to help with Spec, but I do not have the time or
resources to lead it, and since we don't have any roadmap it's hard to go
forward.

Peter


On Wed, Aug 24, 2016 at 6:59 AM, stepharo  wrote:

> Hi
>
> We have some ideas (because people are working on items) for the Pharo 6
> roadmap
>
> and we will consolidate them soon and propose them to you.
>
> but I would like to know two kinds of points
>
> - what are the points you are working on and that would deserve more
> focus and help from the community?
>
> (these points are important because like that you could go faster
> and this is a good feeling to get done for example)
>
> - what would be points where (if magically we would get more resources
> - to not dream if this is not you
>
> there is a high chance that we will not make it) it would be nice
> to get some changes
>
>
> Please pay attention that if you type too fast and come up with a
> christmas list well it will stay a christmas list and will just make the
> thread larger for nothing.
>
> Stef
>
>
>

[Pharo-dev] About Pharo 60

[stepharo]

Hi

We have some ideas (because people are working on items) for the Pharo 6 
roadmap


and we will consolidate them soon and propose them to you.

but I would like to know two kinds of points

- what are the points you are working on and that would deserve 
more focus and help from the community?


(these points are important because like that you could go 
faster and this is a good feeling to get done for example)


- what would be points where (if magically we would get more 
resources - to not dream if this is not you


there is a high chance that we will not make it) it would be 
nice to get some changes



Please pay attention that if you type too fast and come up with a 
christmas list well it will stay a christmas list and will just make the 
thread larger for nothing.


Stef