- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roadmap for Pharo 8.0
by Norbert Hartl Feb. 8, 2019

Feb. 8, 2019

> Am 08.02.2019 um 14:04 schrieb Alexandre Bergel via Pharo-dev <pharo-dev(a)lists.pharo.org>: > > > Von: Alexandre Bergel <alexandre.bergel(a)me.com> > Betreff: Aw: [Pharo-dev] Roadmap for Pharo 8.0 > Datum: 8. Februar 2019 um 14:04:24 MEZ > An: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Dear All, > > At the consortium meeting we discussed the possibility to have a mini-Roassal included in Pharo8. Many opportunities exist: displaying graph of commits in iceberg, displaying UML within the code browser, visualizing dependencies between packages. > > We are motivated about it, and we should produce a runnable proposal ready to be evaluated by the community within a couple of months. > Does it make sense? Any thought about it? Do you have a wishlist? > That would be nice for the delivered image. With a revamped Connectors implementation (does anyone remember?) I would only wish a format for integrating this into pillar that would make documentation super awesome. Norbert > Cheers, > Alexandre > >> On Feb 7, 2019, at 12:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi list, >> >> We started Pharo 8.0 development and we wanted to share (and discuss, if needed) what is our current Roadmap for Pharo 8.0. >> As you can see, Windows is getting some love, and also UI. >> Anyway, here it is: >> >> Image >> === >> 1) Missing parts for headless VM to work (explained a bit later) >> 2) We need to improve Epicea speed. And in general, source access speed. We want to remove the old changes file (since Epicea already does that works and a lot more). >> 3) Improve Refactors >> 4) Improve Calypso >> 5) Introduce Spec2 (our re-work on this framework). >> - We also want to migrate our tools to it (Inspector, Debugger, Spotter and Calypso are the remaining parts). We will see how much of this migration can be done. >> >> VM/Low-level side >> === >> 1) headless vm >> We want to have a real headless VM and make it our default VM. >> To it, most of the work vm-side is already made by Ronie, but there are missing parts: >> - a build on windows >> - image side capabilities: we use SDL2 to start the world, and it mostly works... but not completely. >> >> One cool thing of this is that we will -finally- be able to clean the event handling, which is ugly (and works bad). >> >> 2) Windows several missing/non working parts: >> - file primitives are slow. This is because they rely in old APIs and we need to put them in "state of the art". >> - libgit2 does not processes long paths. We workarounded the problem with tonel, but at a point we need to take care about this. Real problem with this is we need to contribute the solution to libgit2, but this is also good Open Source policy (contributing back). >> - OSSubprocess in windows. We believe we need to extend OSSubprocess (our solution to communicate with system) to windows. And we believe is possible ;) >> >> 3) ThreadedFFI. >> It is already too much time since we have this in agenda. Is time to make it real. >> >> 4) memory policies. >> Tweaking the VM to enhance its memory usage is possible, but hard. We want to adopt an scheme of "memory policies" that will allow users to pick what they need. >> >> Process >> === >> 1) We will add multiple source directories to Iceberg. This is needed to allow us to put all Pharo sub-projects into an unique project without breaking modularisations. >> >> Others >> === >> 1) Launcher >> - Launcher us getting a new UI >> - Tests >> - It needs to be more solid (in part, that's the reason why we want OSSubprocess in windows). >> 2) Cargo >> - We need to revisit cargo (a new dependency manager) and at a point decide if it will fly or not :) >> >> Nice to have (most probably not this version, but in our TODO) : >> - embedded VM >> - event driven VM >> - what happens if we split VM into main thread and vm thread? >> >> > > > >

2 1

Re: [Pharo-dev] Roadmap for Pharo 8.0
by Reg Krock Feb. 8, 2019

Feb. 8, 2019

This would be very useful. Sent from my iPhone > On Feb 8, 2019, at 8:04 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Dear All, > > At the consortium meeting we discussed the possibility to have a mini-Roassal included in Pharo8. Many opportunities exist: displaying graph of commits in iceberg, displaying UML within the code browser, visualizing dependencies between packages. > > We are motivated about it, and we should produce a runnable proposal ready to be evaluated by the community within a couple of months. > Does it make sense? Any thought about it? Do you have a wishlist? > > Cheers, > Alexandre > >> On Feb 7, 2019, at 12:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi list, >> >> We started Pharo 8.0 development and we wanted to share (and discuss, if needed) what is our current Roadmap for Pharo 8.0. >> As you can see, Windows is getting some love, and also UI. >> Anyway, here it is: >> >> Image >> === >> 1) Missing parts for headless VM to work (explained a bit later) >> 2) We need to improve Epicea speed. And in general, source access speed. We want to remove the old changes file (since Epicea already does that works and a lot more). >> 3) Improve Refactors >> 4) Improve Calypso >> 5) Introduce Spec2 (our re-work on this framework). >> - We also want to migrate our tools to it (Inspector, Debugger, Spotter and Calypso are the remaining parts). We will see how much of this migration can be done. >> >> VM/Low-level side >> === >> 1) headless vm >> We want to have a real headless VM and make it our default VM. >> To it, most of the work vm-side is already made by Ronie, but there are missing parts: >> - a build on windows >> - image side capabilities: we use SDL2 to start the world, and it mostly works... but not completely. >> >> One cool thing of this is that we will -finally- be able to clean the event handling, which is ugly (and works bad). >> >> 2) Windows several missing/non working parts: >> - file primitives are slow. This is because they rely in old APIs and we need to put them in "state of the art". >> - libgit2 does not processes long paths. We workarounded the problem with tonel, but at a point we need to take care about this. Real problem with this is we need to contribute the solution to libgit2, but this is also good Open Source policy (contributing back). >> - OSSubprocess in windows. We believe we need to extend OSSubprocess (our solution to communicate with system) to windows. And we believe is possible ;) >> >> 3) ThreadedFFI. >> It is already too much time since we have this in agenda. Is time to make it real. >> >> 4) memory policies. >> Tweaking the VM to enhance its memory usage is possible, but hard. We want to adopt an scheme of "memory policies" that will allow users to pick what they need. >> >> Process >> === >> 1) We will add multiple source directories to Iceberg. This is needed to allow us to put all Pharo sub-projects into an unique project without breaking modularisations. >> >> Others >> === >> 1) Launcher >> - Launcher us getting a new UI >> - Tests >> - It needs to be more solid (in part, that's the reason why we want OSSubprocess in windows). >> 2) Cargo >> - We need to revisit cargo (a new dependency manager) and at a point decide if it will fly or not :) >> >> Nice to have (most probably not this version, but in our TODO) : >> - embedded VM >> - event driven VM >> - what happens if we split VM into main thread and vm thread? >> >> > >

1 0

ZipArchive
by Christophe Demarey Feb. 8, 2019

Feb. 8, 2019

Hi, I did some update to ZipArchive so that it uses FileReference instead of path strings: https://github.com/demarey/pharo/commit/30120d3284cef5cd2f442f00d71da6f6aff… It also allows to use a memory file system for tests. Tests are green but Iâm not sure they cover a lot of things. If you use ZipArchive could you tell me if changes are ok for you? Thanks, Christophe

1 0

[Pharo 8.0] Build #54: CommandLineUIManager >> syntaxErrorNotificationDefaultAction comment typo
by ci-pharo-ci-jenkins2＠inria.fr Feb. 8, 2019

Feb. 8, 2019

There is a new Pharo build available! The status of the build #54 was: FAILURE. The Pull Request #2457 was integrated: "CommandLineUIManager >> syntaxErrorNotificationDefaultAction comment typo" Pull request url: https://github.com/pharo-project/pharo/pull/2457 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #52: 2338 GT Extensions should also be visible on empty directories
by ci-pharo-ci-jenkins2＠inria.fr Feb. 7, 2019

Feb. 7, 2019

There is a new Pharo build available! The status of the build #52 was: SUCCESS. The Pull Request #2339 was integrated: "2338 GT Extensions should also be visible on empty directories" Pull request url: https://github.com/pharo-project/pharo/pull/2339 Issue Url: https://pharo.fogbugz.com/f/cases/2338 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #148: Ensure subMenu is opened (backport)
by ci-pharo-ci-jenkins2＠inria.fr Feb. 6, 2019

Feb. 6, 2019

There is a new Pharo build available! The status of the build #148 was: FAILURE. The Pull Request #2376 was integrated: "Ensure subMenu is opened (backport)" Pull request url: https://github.com/pharo-project/pharo/pull/2376 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[ANN] Pharo Sprints first half 2019
by Marcus Denker Feb. 5, 2019

Feb. 5, 2019

We organise one Pharo âSprintâ per month were we meet to work on boring issue tracker entries together. Goals of the next sprints: - Fix issues for Pharo8 - Backport important fixes to Pharo7 Remotely, you can join us on Discord. During the sprint, we will try to synchronize local and remote Pharo sprinters. In the past people organised local sprints at the same time (e.g. Santiago/Chile). See here for more infos: http://pharo.org/contribute-events There will be an event on the association website for each sprint. The next dates are: - 22 Feb https://association.pharo.org/event-3253818 - 29 Mar https://association.pharo.org/event-3253842 - 26 Apr https://association.pharo.org/event-3253846 - 31 May https://association.pharo.org/event-3253848 - 28 Jun https://association.pharo.org/event-3253850 For more Pharo Event, have a look at the Events Page: https://association.pharo.org/events

1 0

Feb. 5, 2019

https://www.unocero.com/smartphones/pharo-7-internet-de-las-cosas/ <https://www.unocero.com/smartphones/pharo-7-internet-de-las-cosas/> Just presenting version 7. Couple of observations: 1. We reach farther than we think. 2. IoT has a lot of attention at this moment. Esteban

2 1

iceberg: merging branches just at the git level without changing code in the image
by Andrei Chis Feb. 5, 2019

Feb. 5, 2019

Hi, Currently in Iceberg to merge a branch into another, we need to checkout the branch into which we want to merge and then do the merge. Checking out a branch also updates the code in the image, which when needing to perform automatic releases on a branch can cause issues. Is there already a way in Iceberg to switch to a branch (for example `release`) and then merge another branch (for example `master`) into it without updating any code in the image? The use-case is that the user is on the `master` branch and needs to merge `master` into `release` without changing any code in the image. I found LGitRepository>>#merge:, but it seems not to be used anywhere in the image. Another way would be to implement something like the method below. This: - calculates what changes need to be merged - always takes what is on the left branch (in this case what is on master overrides what is on release) - does not call loadChangesInWorkingCopy: to update the working copy as the code is already in the image - refreshes the dirty packages in case there are changes between what is on the image and what is on disk ``` IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate | commitToAdvance | mergeCommit validateCanMerge. self isAlreadyMerged ifTrue: [ ^ self ]. self calculateChanges. self conflictsDo: [ :operation | operation selectLeft. ]. commitToAdvance := self updateHead. "Do not update the working copy" "repository workingCopy loadChangesInWorkingCopy: self changesToWorkingCopyTree." repository workingCopy refreshDirtyPackages. ^ commitToAdvance ``` Could something like the above solution work? Or are there other issues to take into account? Cheers, Andrei

3 2

[Pharo 7.0] Build #147: Add scrollSelectionIntoView
by ci-pharo-ci-jenkins2＠inria.fr Feb. 5, 2019

Feb. 5, 2019

There is a new Pharo build available! The status of the build #147 was: SUCCESS. The Pull Request #2428 was integrated: "Add scrollSelectionIntoView" Pull request url: https://github.com/pharo-project/pharo/pull/2428 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0