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

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 <stepharo@free.fr <mailto:stepharo@free.fr>> 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

...

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 <stepharo@free.fr <mailto:stepharo@free.fr>>:

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

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

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. <cyril.ferlicot@gmail.com> 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

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-GTSpott... 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 <issueNumberHere>".

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

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 <estebanlm@gmail.com> 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. <cyril.ferlicot@gmail.com> 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."

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

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.

...

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.

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/BaselineOfI... Peter

On Wed, Aug 31, 2016 at 9:16 PM, stepharo <stepharo@free.fr> 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/