August 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Magritte moved to github

by Sean P. DeNigris

NorbertHartl wrote > https://github.com/magritte-metamodel/magritte I'm trying to get my fork [1] back in sync with the upstream now that you've ported the code there. Conceptually, I'd like to replay the changes in my Magritte fork on top the last commit that is content-equivalent between the two. After some digging, this appears to be the upstream's commit `51f648b`, which is equivalent to the fork's `47df0a5` (both titled "[FIX]: Respect action shortcuts if specified. Otherwise, default to tâ¦") This is the process I've followed so far. Feedback appreciated. 1. I created an "original_master" branch to preserve the fork's original history. Maybe this is not necessary long-term? 2. I created a "new_master" branch to merge both histories, based off upstream/master 3. I reverted that branch to the shared base commit, `51f648b` 4. I started a `cherry-pick 47df0a5..eedd386`. A few SO threads said this is the best way, but cautioned that the commits will have different SHA's i.e., A..D will become A'..D'. Maybe this is a good thing if we want to preserve the original history as well (although do we, see #1 above)? OTOH, issues that referenced commits will now point to old_master, and not masterâ¦ On step #4, I've run into merge hell due to metadata. I guess I committed at that time with metadata and upstream is metadata-less. How do I dig myself out without manually approving each file for potentially hundreds of commits?! Thanks 1. https://github.com/seandenigris/Magritte3 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 8, 2018

Re: [Pharo-users] [ANN] Magritte moved to github

by Norbert Hartl

Forgot a link to the repo https://github.com/magritte-metamodel/magritte <https://github.com/magritte-metamodel/magritte> > Am 08.08.2018 um 18:46 schrieb Norbert Hartl <norbert(a)hartl.name>: > > I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. > > Please let us work on github for magritte and update smalltalkhub when necessary. > > Hope you like it! Travis build has also been added. > > Norbert > >

Aug. 8, 2018

[ANN] Magritte moved to github

by Norbert Hartl

I moved magritte code today from smalltalkhub to github. I also changed the dependencies of magritte for grease and seaside to be the github repositories and not smalltalkhub. Please let us work on github for magritte and update smalltalkhub when necessary. Hope you like it! Travis build has also been added. Norbert

Aug. 8, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Herbert VojÄÃk

Damien Pollet wrote on 8. 8. 2018 13:53: > First of all, quick stupid question: I'm currently loading my code with > gitlocal://./src as the repository URL (my workflow starts in a terminal > rather than in a Pharo image) > Should I just remove the /src part, now that my repo has the project > metadata? > > Also, are more features planned for the .project file? E.g. what about > storing a default selection for Calypso and the Test Runner in there? > > On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>> wrote: > > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this > however. I keep frontend and backend code in some repositories > together so the source is in my case in backend/source. What does it > mean for users not using the âstandardâ name? > > > Sure there can. Look at any ruby or maven project, they all have strong > conventions for organizing projects and standard config files for > deviating from those conventions. > I would have preferred if Iceberg picked one convention (arbitrarily) in > the absence of a .project file instead of forcing its explicit presence. > IMHO the choice of default directory per se (be it ./, ./src, ./source > or whatever) matters less than the fact that there is a convention in place. > > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment > already but the .project file manifests this. So it should not be > supported to have more source dirs in one git repo? It might be not > a good idea that the client has to write the source dir but it opens > the possibility that there can be more than one. > > > I see your point here, but by using separate source directories you're > sort of creating a hydra projectâ¦ What I mean here is that the source > directories are separate, but their histories are tangled. If you want > separate source dirs it kinda means that you want separate change > histories, doesn't it? What if the same class has diverging definitions > in separate directories (I wonder what maven does in that caseâ¦)? There are monorepos. Some people / companies love them. > On the other hand, separate source directories would be helpful to work > with git-subrepo and similar toolsâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 8, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Herbert VojÄÃk

Norbert Hartl wrote on 8. 8. 2018 10:27: > > >> Am 07.08.2018 um 16:00 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >> >> Hi, >> >> I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). >> >> First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. >> >> One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). >> >> This has some bad consequences: >> - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. >> - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") >> >> Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). >> >> So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. >> The idea is that: >> >> - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. >> - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory >> - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file >> - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) >> - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). >> >> # About defaults values / forcing the user to define a project >> >> First, notice that even when the repositories you load are just marked as "dirty". >> This is because in memory we add a project to your repository. >> But you're not forced to commit it. >> Actually, you can still load packages and baselines from that repository without committing. >> >> This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. >> >> If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. >> To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. >> This could work, but right now all projects use different names for their source directories. >> So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). >> However, not much repositories use 'src' so it will still produce a lot of "noise"... >> >> But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... >> >> Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. >> > I think I can see what is the rationale behind it but Iâm not sure this can be the way to go: > > - I donât think there can be a âstandard wayâ of defining source directory. And I donât think that a tool should enforce this however. I keep frontend and backend code in some repositories together so the source is in my case in backend/source. What does it mean for users not using the âstandardâ name? > - I donât see why there needs to be a 1:1 relationship between a repository and working copy in pharo. It is like this at the moment already but the .project file manifests this. So it should not be supported to have more source dirs in one git repo? It might be not a good idea that the client has to write the source dir but it opens the possibility that there can be more than one. Sacrificing very old project (ones not having .properties anywhere) there's a way where you search in the working tree to find all dirs with .properties and treating them as (parallel) source roots. > - My mode of working is to have an eye on dirty repositories because that shows what the impact of your work is. If I have a lot of dirty repositories in my repository list it does not feel good and I donât want that. Especially for projects I donât have write access to. How can I change this? Iâm not sure that assuming everyone will add these files is a likely one. In Amber I had similar problem with local.amd.json metadata file. As it wasn't feasible to think other projects like jquery add one just for Amber to be happy, I allowed to specify "foreign" metadata as well - so I can add jquery.amd.json to "inject" metadata to foreign project if it doesn't have its own. So, yes, there can be .project.Foreign-Name or something in the root of your project. As a "transitional" solution until Foreign-Name maintainers add their own .project, which then takes precedence. And Foreign-Name's packages / repos won't be dirty (only yours, and only once). > Norbert Herby

Aug. 8, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Damien Pollet

First of all, quick stupid question: I'm currently loading my code with gitlocal://./src as the repository URL (my workflow starts in a terminal rather than in a Pharo image) Should I just remove the /src part, now that my repo has the project metadata? Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name> wrote: > - I donât think there can be a âstandard wayâ of defining source > directory. And I donât think that a tool should enforce this however. I > keep frontend and backend code in some repositories together so the source > is in my case in backend/source. What does it mean for users not using the > âstandardâ name? > Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. > - I donât see why there needs to be a 1:1 relationship between a > repository and working copy in pharo. It is like this at the moment already > but the .project file manifests this. So it should not be supported to have > more source dirs in one git repo? It might be not a good idea that the > client has to write the source dir but it opens the possibility that there > can be more than one. > I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 8, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

> Am 07.08.2018 um 16:00 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi, > > I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). > > First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. > > One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). > > This has some bad consequences: > - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. > - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") > > Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). > > So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. > The idea is that: > > - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. > - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory > - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file > - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) > - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). > > # About defaults values / forcing the user to define a project > > First, notice that even when the repositories you load are just marked as "dirty". > This is because in memory we add a project to your repository. > But you're not forced to commit it. > Actually, you can still load packages and baselines from that repository without committing. > > This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. > > If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. > To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. > This could work, but right now all projects use different names for their source directories. > So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). > However, not much repositories use 'src' so it will still produce a lot of "noise"... > > But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... > > Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. > I think I can see what is the rationale behind it but Iâm not sure this can be the way to go: - I donât think there can be a âstandard wayâ of defining source directory. And I donât think that a tool should enforce this however. I keep frontend and backend code in some repositories together so the source is in my case in backend/source. What does it mean for users not using the âstandardâ name? - I donât see why there needs to be a 1:1 relationship between a repository and working copy in pharo. It is like this at the moment already but the .project file manifests this. So it should not be supported to have more source dirs in one git repo? It might be not a good idea that the client has to write the source dir but it opens the possibility that there can be more than one. - My mode of working is to have an eye on dirty repositories because that shows what the impact of your work is. If I have a lot of dirty repositories in my repository list it does not feel good and I donât want that. Especially for projects I donât have write access to. How can I change this? Iâm not sure that assuming everyone will add these files is a likely one. Norbert

Aug. 8, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by H. Hirzel

Jupyter notebooks are not limited to Python, there are more than 40 https://github.com/jupyter/jupyter/wiki/Jupyter-kernels Pharo Smalltalk is one of them https://github.com/jmari/JupyterTalk I'd like to get it up and running.... On 8/7/18, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Grafoscopio exists due to various limitations of Jupyter, particularly the > lack of real support for objects in its core language - Python. JSON is not > equivalent to STON even in terms of storing JavaScript, it's mainly a data > format. > > ï»¿On 8/7/18, 2:14 PM, "Pharo-users on behalf of Sean P. DeNigris" > <pharo-users-bounces(a)lists.pharo.org on behalf of sean(a)clipperadams.com> > wrote: > > Hannes Hirzel wrote > > P.S. Some notes and links how Jupyter notebooks relate to the > Dynabook > > idea here > > http://wiki.squeak.org/squeak/1318 > > From the swiki: "A Jupyter Notebook isâ¦ similar to Active Essays kept in > a > Smalltalk based Dynabook." > > I've understood a key point of the Dynabook dream (and Smalltalk as > prototype Dynabook software) is that as you drill down to something > facing > the end user, you keep the full power of the computer. For example, > when > Alan Kay presents, he doesn't use Powerpoint, but Squeak. Hence, the > slides > are each fully functioning World where one can e.g. bring up halos, > inspectors, class browsers. > > Is that the case with Jupiter Notebooks? I assumed not since the > notebooks > seem to be saved as JSON, unless maybe it's used for object > serialization > like STON? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > >

Aug. 8, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by Andrew Glynn

Grafoscopio exists due to various limitations of Jupyter, particularly the lack of real support for objects in its core language - Python. JSON is not equivalent to STON even in terms of storing JavaScript, it's mainly a data format. ï»¿On 8/7/18, 2:14 PM, "Pharo-users on behalf of Sean P. DeNigris" <pharo-users-bounces(a)lists.pharo.org on behalf of sean(a)clipperadams.com> wrote: Hannes Hirzel wrote > P.S. Some notes and links how Jupyter notebooks relate to the Dynabook > idea here > http://wiki.squeak.org/squeak/1318 From the swiki: "A Jupyter Notebook isâ¦ similar to Active Essays kept in a Smalltalk based Dynabook." I've understood a key point of the Dynabook dream (and Smalltalk as prototype Dynabook software) is that as you drill down to something facing the end user, you keep the full power of the computer. For example, when Alan Kay presents, he doesn't use Powerpoint, but Squeak. Hence, the slides are each fully functioning World where one can e.g. bring up halos, inspectors, class browsers. Is that the case with Jupiter Notebooks? I assumed not since the notebooks seem to be saved as JSON, unless maybe it's used for object serialization like STON? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 7, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by Sean P. DeNigris

Hannes Hirzel wrote > P.S. Some notes and links how Jupyter notebooks relate to the Dynabook > idea here > http://wiki.squeak.org/squeak/1318 >From the swiki: "A Jupyter Notebook isâ¦ similar to Active Essays kept in a Smalltalk based Dynabook." I've understood a key point of the Dynabook dream (and Smalltalk as prototype Dynabook software) is that as you drill down to something facing the end user, you keep the full power of the computer. For example, when Alan Kay presents, he doesn't use Powerpoint, but Squeak. Hence, the slides are each fully functioning World where one can e.g. bring up halos, inspectors, class browsers. Is that the case with Jupiter Notebooks? I assumed not since the notebooks seem to be saved as JSON, unless maybe it's used for object serialization like STON? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 7, 2018

Dynabook and learning by doing

by Hilaire

How could Dynabook and learning by doing could be related? http://blog.drgeo.eu/post/2018/Learning-by-doing Hilaire -- Dr. Geo http://drgeo.eu

Aug. 7, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by tesonep＠gmail.com

Only adding a small detail, the Metacello expression is used to generate the project that is offered. Also I see it as the Detached head status for projects that are loaded using Metacello. Maybe we should display the dirtiness in other way, but I think that is not a problem. It is normal that a project is marked dirty while used. Cheers On Tue, Aug 7, 2018 at 4:01 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, > > I'll write down some of the reasons of the project's design, like that I > can afterwards copy paste it in the wiki :). > > First, this design did not came up from an egg. We worked on it for about > two months. And it is thought to be backwards compatible and manage lots of > metacello particularities. It may have things that are perfectible, sure, > so let's discuss it. > > One of the main problems we saw in metacello, and that Iceberg inherited, > was the "source subdirectory" thing. This source directory had to be > specified in the CLIENT, meaning that every time we clone a repository we > should know by heart the directory chose by its developer. Moreover, we > lack a standard way to do it, so everybody does as he feels (root > directory, src, source, repository, mc....). > > This has some bad consequences: > - once a repository is referenced by some other project, it is more > complicated to change its source directory. Imagine that tomorrow we set as > standard that all git repos should have the code in src. Then voyage should > change. And all its clients too. > - Making a typo in the code subdirectory means sometimes super ugly > errors from metacello that are difficult to debug and understand (e.g., > "Cannot resolve BaselineOfMetacello WTF") > > Moreover, there was another problem that people started stumbling on: the > fact that iceberg got confused sometimes thinking that an empty project was > in filetree (to keep backwards compatibility with projects without a > .properties). > > So we decided that for this release we wanted to revert a bit that > situation. Think object: let's put the meta-data used to interpret a > project's structure inside the project itself. > The idea is that: > > - each project should contain both a .project and a .properties file. The > first can contain arbitrary project meta-data (such as the source > directory). The second contains the cypress properties, which are needed to > correctly interpret the code inside the source directory. > - a project without a .project file is an old project and cannot be > interpreted, because we don't know the source directory > - a project without a .properties file is an old project and is by > default transformed in a project with a #filetree properties file > - an old project cloned from iceberg detects the missing .project file > and gives the user the opportunity to declare it (and then commit it > explicitly) > - an old project cloned and loaded from a Metacello expression defining a > source directory will honnor the source directory defined in the Metacello > expression (for backwards compatibility, and we have ~500 tests about this). > > # About defaults values / forcing the user to define a project > > First, notice that even when the repositories you load are just marked as > "dirty". > This is because in memory we add a project to your repository. > But you're not forced to commit it. > Actually, you can still load packages and baselines from that repository > without committing. > > This is in line with Iceberg's "explicitness". We try to not do any > destructive operation without asking the user first (that's why we have > several preview windows for pushing, pulling, checkout, merge..., and why > contrastingly with monticello we show the committed changes on the commit > window...). So, instead of transparently "adding the file" we have decided > to modify the project in memory and let the user the responsibility to > commit that file. > > If there's a drawback, is that the repository is marked as dirty. Which is > a bit noisy, yes, but still I think it's not so bad compared with the > previous drawbacks. > To solve this, we could have some default values, yes, and only mark it as > dirty if the project does not follow the default value. > This could work, but right now all projects use different names for their > source directories. > So the question is, what would be a good default? I'd like to use 'src' > since this is short, well known and less alien (all these in the sense that > we do not lose anything and we have a lot to gain by using it). > However, not much repositories use 'src' so it will still produce a lot of > "noise"... > > But still! Committing that file is a one-time operation. Once people fix > their repositories adding the project meta-data, you will not see them > dirty anymore. So we can see this as a transition noise too... > > Of course, new ideas are welcome. I'll let Pablo and Esteban add their > points of view on this too. > Guille > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Guillermo Polito

Hi, I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :). First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it. One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....). This has some bad consequences: - once a repository is referenced by some other project, it is more complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too. - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF") Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties). So we decided that for this release we wanted to revert a bit that situation. Think object: let's put the meta-data used to interpret a project's structure inside the project itself. The idea is that: - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory. - a project without a .project file is an old project and cannot be interpreted, because we don't know the source directory - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly) - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this). # About defaults values / forcing the user to define a project First, notice that even when the repositories you load are just marked as "dirty". This is because in memory we add a project to your repository. But you're not forced to commit it. Actually, you can still load packages and baselines from that repository without committing. This is in line with Iceberg's "explicitness". We try to not do any destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file. If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks. To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value. This could work, but right now all projects use different names for their source directories. So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). However, not much repositories use 'src' so it will still produce a lot of "noise"... But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too... Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too. Guille

Aug. 7, 2018

Re: [Pharo-users] Pharo Launcher & Stored Settings

by werner kassens

On 08/07/2018 02:15 AM, Evan Donahue wrote: > Yes, that's right. As long as I don't "store settings" everything is > ok, but if I do find myself wanting to change a global setting of some > kind, and I hit "store," it /also/ stores the metacello paths, which > will then be incorrect for the next new image I create. Also, even if > I delete them, it seems to autogenerate one (but not both) of the > paths incorrectly (with that crazy /build) path. > > More generally though, all I was trying to do was use Pharo launcher > and keep repositories separate, which I was advised to do by the list. Hi Evan, yes exactly. the defaultÂ if i dont change & _store_ settings is: i make via launcher a pharo6.1blabla, it has its own repository-directory; i make the next one, pharo6.1blabla-01, open monticello and it has another package-cache. i did not test this, but i guess it could be possible that if you store settings just once even _without_ changing anything, the local cache directory will be stored, as the class-var-accessor produced a valid path, and from then on this setting will not change anymore for new builds via launcher. you either reset the settings via deleting the monticello records in the settings file found via StartupPreferencesLoader preferencesVersionFolder. or if you need to store changed settings in a general way eg for all 6.1 versions, you do that deleting afterwards. i agree that the 2 monticello-settings behave differently and that this is either irritating or probably a bug (because the second behaviour can make storing other settings difficult), but then <shrugging shoulders> i have to admit i was never bothered by this behaviour. werner

Aug. 7, 2018

Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Tim Mackinnon

Hi guys - Iâve been hammering on the exercism project to get pharo shining over thereâ¦ its been a good side distraction (there is lots of energy in that community to) and its made me really push my use of Iceberg & git as well as learn some fo the newish file reference stuff (still getting good at that - but like the approach), Anyway - Iâve got an Alpha working, and users can pull down a zero conf pharo image and eval a little script that will get them up and running (which is pretty slick). So the story then goes - Exercism is trying to simulate TDD and help you learn a new language (aka Pharo or Go or Python etc). To this end, theyâve got an active community building up little test exercises with suites of tests that new users can run to help them learn the syntax/essence of the language track theyâve signed up to. You run the tests, develop your solution and then submit it to a community to get feedback and then progress. Pretty standard - we can play in this pond too - and it turns out that Tonel actually makes it pretty easy to submit readable solutions that will fit on their website. YAY. The trouble is - when you pull down a new exercise - I use the TonelReader to pull the code into your image - and I thought it would be cute to just pull in the TestCase so that users can simulate the full TDD cycle - where you can create things in the debuggerâ¦ this is where it all began right? So you hit a clanger when you do this - and in a way its a bit of a legacy thing weâve carried around (and possibly should fix better). When Tonel reads in the TesCase, it normally will reference a class this isnât there (Iâve deliberately left the solution out). It does the right thing and put a nil placeholder in the code so that it can read it in. HOWEVER - when you run your test and hit that nil class placeholder we do a very bad job of dealing with this in the debugger. And if you think about it - we also do a bad job when typing in code too - we essentially insist that declare a class then and there - unlike a selector which can happily be late bound. So back to my TDD example - user gets a debugger with a nil class error - the create button is actually not helpful for you as it only creates methods. So our âlive in the debuggerâ mantra is a bit less obvious here. What you had to do is make a change to the source (like a space) so that you can reserve the method - which then causes you to get the âcreate class promptâ. So we have the ability - just donât expose it very well - however now you have a missing method - but again its not so obvious that you have to resume your debugger (it hasnât resumed when you created the class) - and then you will get another error for the missing method that the create button will now resolve. This feels very clunky to me - and makes me feel like Iâm mis-selling smalltalk where we have a bullet point about âAmazing for debuggingâ¦â. This feels fixable though right? Iâm wondering about thoughts though before jumping inâ¦ Tim p.s. - weâre building some exercises for exercism and getting that process streamlined so hopefully many more people can help - and maybe we can augment the great learning courses/videos/books that we already have.

Aug. 7, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

Forgot one thing. I find the new project feature quite intrusive. It will add those file to all repos unasked. So I have a lot of dirty projects I have no write access to. How is this supposed to work. Isnât it better to assume defaults and add an option to add project files? Norbert > Am 07.08.2018 um 12:05 schrieb tesonep(a)gmail.com: > > New Iceberg Version 1.2.1 [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0> + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1>] > Thanks to all brave users, issue reporters, and contributors :). > > This version includes the implementation of projects. > Projects are a way of defining basic metadata of the repository. > Now, this metadata just includes the source directory. > > This means that people do not need anymore to provide ALL THE TIME the source directory. > Instead, every repository includes a project file that provides it. > Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). > > This version is integrated in the latest Pharo 7 images. > > #New Features > > - #866 Introduce first version of Projects > > #Infrastructure > > - #870 Improving tests of Metacello Integration > - #903 Split basic tests from metacello tests in CI > - #914 Sync Wiki with documentation directory automatically > - #934 Manually check metacello integration dialogs > - #935 Try to refrite the metacello integration tests. > - #940 Installation in new Pharo should also bootstrap pharo repository > > #Enhancements > > - #675 The History of a Method in Calypso should show a progress bar. > - #788 Show progress during network operations (fetch,push, ...) Libgit. > - #875 Tonel plugin does not delete .filetree Migration > - #897 Update to OSSubprocess 1.0.1 > - #911 Repair Checkout branch should appear in "no project found" > - #933 Fix Edit repository dialog > - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor > - #944 Extract pharo repository bootstrap code into iceberg > > #Bug Fixes > > - #828 Convert sources to tonel raises an Exception > - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong > - #849 VM crash while saving credentials Credential Manager > - #851 .properties file is not create if project is imported and not cloned. > - #869 Error msg after an http timeout is unreadable > - #873 Error with credential provider Credential Manager > - #874 The integration with Metacello does not work when there is a src directory, but not project file. > - #880 Putting "." in project src field gives dnu > - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists > - #886 Edit Project Dialog does not allow to select the root of the repository as source directory > - #888 Could not locate repository does not have subdirectory anymore. > - #889 Loading an unborn project through metacello does not work > - #894 GitHubAPI fails when the API responds with a 204 No Content > - #901 I get a DNU projectName.... > - #902 Edit project metadata does not detect default format > - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages > - #928 Pull request cancel > - #930 Changed ivar/slot name in stateful trait not recognized as a change > - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed > - #932 Pharo repository forgets packages > - #938 Do not catch assertion failures > - #941 Iceberg pre-installed repository has wrong repair action > - #946 Fixing Metacello Integration Tests > - #948 Cloning from github creates an invalid remote > - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug > - #951 New project window should be coherent on the vocabulary UI enhancement > - #953 Make remote request anonymous enhancement > - #952 Cannot Clone Pharo Repository Pharo plugin bug > - #955 Repair actions for repositories with fetch required are wrong UI bug > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2018

Re: [Pharo-users] [Pharo-dev] New Iceberg Version 1.2.1

by Norbert Hartl

Great, thanks! I used 1.2.0 a few days ago and I had some problems: - some repos like voyage had a .properties file in the repo with content â{}â. This made the repo unusable. The only thing noticed is that in the repo view in iceberg the packages were named Voyage-Core.package instead of Voyage-Core - I had a problem that I cherry picked changes in my project and commited but then all other changes were gone, too. I need to revert and then reapply the changes with epicea in order to have it in iceberg. It can be it was influenced by the above problem but I need to check again which I will. Norbert > Am 07.08.2018 um 12:05 schrieb tesonep(a)gmail.com: > > New Iceberg Version 1.2.1 [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0> + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 <https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1>] > Thanks to all brave users, issue reporters, and contributors :). > > This version includes the implementation of projects. > Projects are a way of defining basic metadata of the repository. > Now, this metadata just includes the source directory. > > This means that people do not need anymore to provide ALL THE TIME the source directory. > Instead, every repository includes a project file that provides it. > Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). > > This version is integrated in the latest Pharo 7 images. > > #New Features > > - #866 Introduce first version of Projects > > #Infrastructure > > - #870 Improving tests of Metacello Integration > - #903 Split basic tests from metacello tests in CI > - #914 Sync Wiki with documentation directory automatically > - #934 Manually check metacello integration dialogs > - #935 Try to refrite the metacello integration tests. > - #940 Installation in new Pharo should also bootstrap pharo repository > > #Enhancements > > - #675 The History of a Method in Calypso should show a progress bar. > - #788 Show progress during network operations (fetch,push, ...) Libgit. > - #875 Tonel plugin does not delete .filetree Migration > - #897 Update to OSSubprocess 1.0.1 > - #911 Repair Checkout branch should appear in "no project found" > - #933 Fix Edit repository dialog > - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor > - #944 Extract pharo repository bootstrap code into iceberg > > #Bug Fixes > > - #828 Convert sources to tonel raises an Exception > - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong > - #849 VM crash while saving credentials Credential Manager > - #851 .properties file is not create if project is imported and not cloned. > - #869 Error msg after an http timeout is unreadable > - #873 Error with credential provider Credential Manager > - #874 The integration with Metacello does not work when there is a src directory, but not project file. > - #880 Putting "." in project src field gives dnu > - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists > - #886 Edit Project Dialog does not allow to select the root of the repository as source directory > - #888 Could not locate repository does not have subdirectory anymore. > - #889 Loading an unborn project through metacello does not work > - #894 GitHubAPI fails when the API responds with a 204 No Content > - #901 I get a DNU projectName.... > - #902 Edit project metadata does not detect default format > - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages > - #928 Pull request cancel > - #930 Changed ivar/slot name in stateful trait not recognized as a change > - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed > - #932 Pharo repository forgets packages > - #938 Do not catch assertion failures > - #941 Iceberg pre-installed repository has wrong repair action > - #946 Fixing Metacello Integration Tests > - #948 Cloning from github creates an invalid remote > - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug > - #951 New project window should be coherent on the vocabulary UI enhancement > - #953 Make remote request anonymous enhancement > - #952 Cannot Clone Pharo Repository Pharo plugin bug > - #955 Repair actions for repositories with fetch required are wrong UI bug > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Aug. 7, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Henrik Sperre Johansen

Guillermo Polito wrote > On Tue, Jul 31, 2018 at 6:29 PM Damien Pollet < > damien.pollet+pharo@ > > > wrote: > >> Hi Svenâ¦ a couple questions: >> >> - is there a preferred order of composition between the encoding and >> buffering streams ? If yes, it the same for read and write stream, or >> reversed ? >> E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, >> but buffering it as well would be a problem for interactive applications. >> > > Well, I'd say that we could check if performance-wise there is a > difference... I don't think there will be much of a difference, but, who > knows ^^. It can be a world of difference, depending on what operations are expensive on the terminal stream. For example, with a buffer size N, file <-> buffer <-> utf8 encoding does 1 N-byte write/read whenever buffer fills/need filling, file <-> utf8 encoding <-> buffer does N 1-4 byte writes/reads whenever buffer fills/need filling. TLDR; Always put the buffering between where small reads/writes occur (encoding, code doing looped #nextPut:'s), and where reads/writes are expensive (files, sockets, etc). Guillermo Polito wrote >> >> - what's your opinion on convenience composition messages, e.g. >> aBinaryStream buffered decoded: 'utf-8' ? >> > > Check what we did in FileReference & co. > Opening a File reference returns by default a utf8 buffered stream (in > that > order). And we have convenience methods to specify other encodings and to > get directly the binary stream (which will be buffered). > > The idea is that FileSystem (among others like managing memory file > systems) provides a high level API with convenience methods to avoid > putting the burden of the composition in the user. > The File package stays small and flexible providing direct access to the > physical file system. > > Following this same idea, to me Clap should define several convenient ways > to access standard input/output. > Like that, other Stdio users can define their own too. > > Also, maybe Clap can provide the same API as FileSystem > (#writeStreamEncoded:do:, #readStreamEncoded:do: & co) just for coherence? The problem with using buffered write stream composition in a non-scoped manner, is you have to remember to explicitly #close the streams in order for buffers to flush correctly. That is, unless one could have a #finalize on buffered streams; and ensure it runs before finalizer on the wrapped stream (which would cause the terminal to close, and subsequent #flush to fail), I'm not sure if that's possible/how it already works... Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 7, 2018

New Iceberg Version 1.2.1

by tesonep＠gmail.com

New Iceberg Version 1.2.1 [ https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1] Thanks to all brave users, issue reporters, and contributors :). This version includes the implementation of projects. Projects are a way of defining basic metadata of the repository. Now, this metadata just includes the source directory. This means that people do not need anymore to provide ALL THE TIME the source directory. Instead, every repository includes a project file that provides it. Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). This version is integrated in the latest Pharo 7 images. #New Features - #866 Introduce first version of Projects #Infrastructure - #870 Improving tests of Metacello Integration - #903 Split basic tests from metacello tests in CI - #914 Sync Wiki with documentation directory automatically - #934 Manually check metacello integration dialogs - #935 Try to refrite the metacello integration tests. - #940 Installation in new Pharo should also bootstrap pharo repository #Enhancements - #675 The History of a Method in Calypso should show a progress bar. - #788 Show progress during network operations (fetch,push, ...) Libgit. - #875 Tonel plugin does not delete .filetree Migration - #897 Update to OSSubprocess 1.0.1 - #911 Repair Checkout branch should appear in "no project found" - #933 Fix Edit repository dialog - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor - #944 Extract pharo repository bootstrap code into iceberg #Bug Fixes - #828 Convert sources to tonel raises an Exception - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong - #849 VM crash while saving credentials Credential Manager - #851 .properties file is not create if project is imported and not cloned. - #869 Error msg after an http timeout is unreadable - #873 Error with credential provider Credential Manager - #874 The integration with Metacello does not work when there is a src directory, but not project file. - #880 Putting "." in project src field gives dnu - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists - #886 Edit Project Dialog does not allow to select the root of the repository as source directory - #888 Could not locate repository does not have subdirectory anymore. - #889 Loading an unborn project through metacello does not work - #894 GitHubAPI fails when the API responds with a 204 No Content - #901 I get a DNU projectName.... - #902 Edit project metadata does not detect default format - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages - #928 Pull request cancel - #930 Changed ivar/slot name in stateful trait not recognized as a change - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed - #932 Pharo repository forgets packages - #938 Do not catch assertion failures - #941 Iceberg pre-installed repository has wrong repair action - #946 Fixing Metacello Integration Tests - #948 Cloning from github creates an invalid remote - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug - #951 New project window should be coherent on the vocabulary UI enhancement - #953 Make remote request anonymous enhancement - #952 Cannot Clone Pharo Repository Pharo plugin bug - #955 Repair actions for repositories with fetch required are wrong UI bug -- Pablo Tesone. tesonep(a)gmail.com

Aug. 7, 2018

Re: [Pharo-users] BS Web and Pharo

by Marcus Denker

Hi, I have removed it. > On 2 Aug 2018, at 18:15, Tim Mackinnon <tim(a)testit.works> wrote: > > > Hey guys - when reading about the BS web (great article btw - https://pxlnv.com/blog/bullshit-web/ <https://pxlnv.com/blog/bullshit-web/> ) it reminded me about the constant pestering to sign up for the Pharo newsletter. > > Given I am signed up - how can I stop it always popping up? > > Itâs in the list of the BS web... so do we really need it to do this? At least it should be a cookie that if I have it it goes away, or better still - just put it as a menu entry and let people sign up if they like out stuff? > > Given our community fights the BS can't we lead better? > > Tim > > Sent from my iPhone

Aug. 7, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by Serge Stinckwich

On Tue, Aug 7, 2018 at 9:24 AM Tim Mackinnon <tim(a)testit.works> wrote: > Somewhat related - but the Pharo equivalent (said naively - as Iâve only > seen demos of Jupyter and not used it in anger myself) is gtDocumentor > which looks to be the concept reimagined in Smalltalk. Apologies if you > already know about it - but its so cool its worth checking out if you > havenât - https://github.com/feenkcom/gtoolkit-documenter (note - take > note of the bottom comment and load all of glamourous toolkit to get the > full impression). > > Thank you Tim. Yes i know about GTDocumenter and really like the idea. Nevertheless, this is still interesting to have Jupyter support in Pharo because it allows you to run Pharo in a browser and share notebooks with other people. Be able to run Pharo in Jupyter notebook is also interesting to have a wider audience. I would like to see in the future more connections between GTDocumenter and Jupyter. Cheers, -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

Aug. 7, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by Tim Mackinnon

Somewhat related - but the Pharo equivalent (said naively - as Iâve only seen demos of Jupyter and not used it in anger myself) is gtDocumentor which looks to be the concept reimagined in Smalltalk. Apologies if you already know about it - but its so cool its worth checking out if you havenât - https://github.com/feenkcom/gtoolkit-documenter <https://github.com/feenkcom/gtoolkit-documenter> (note - take note of the bottom comment and load all of glamourous toolkit to get the full impression). Tim > On 7 Aug 2018, at 08:11, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > P.S. Some notes and links how Jupyter notebooks relate to the Dynabook idea here > > http://wiki.squeak.org/squeak/1318 > > My aim is to use nteract as client (https://nteract.io/ ) together > with a Pharo based Smalltalk "kernel" (i.e. server acting as the > "scripting engine") > > On 8/7/18, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Thank you, Evan, for an alternative load script. >> >> Unfortunately it gives the same error message. >> >> I use a recent, pristine Pharo 6.1 installation on a 64bit Ubuntu based >> Linux. >> >> >> On 8/4/18, Evan Donahue <emdonahu(a)gmail.com> wrote: >>> Try: >>> >>> Metacello new >>> githubUser: 'jmari' project: 'JupyterTalk' commitish: 'master' >>> path: >>> 'repository'; >>> baseline: 'JupyterTalk'; >>> load >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >

Aug. 7, 2018

Re: [Pharo-users] Pharo Launcher & Stored Settings

by Tim Mackinnon

The settings that you save will apply to all images - so you need to clear out those settings for shared repoâs etc. I think what is confusing is that using the Save button - means apply the settings to all images. If you change the setting locally in your image and donât press save, it persists just in that image (is you can try something out). If you want most images to share a setting and just a few to not do it - then you would save the main setting - and just adjust locally when needed - or could have some startup script that recognised certain image names and applied something programmatically. Tim > On 7 Aug 2018, at 02:03, Evan Donahue <emdonahu(a)gmail.com> wrote: > > Hmm, the only things I'm trying to accomplish are 1) use Pharo Launcher and > 2) have each new image keep its repositories separate, as advised by others > on the list, so that different images can check out different branches. Does > that set up require custom scripting to adjust the repo path? > > The cache path does seem to do the required adjusting on its own, but the > 'metacello default directory' path defaults to that crazy thing that's not a > path on my computer: > > /builds/workspace/Pharo-6.0-Update-Step-1-Tracker > > PS, Is the 'store settings' button in the settings menu the standard way to > configure cross-image preferences, because that seems to also save things > like these paths that should be generated anew with each new image. Maybe I > should stick with one single place for repos and just configure these paths > to be global? > > Thanks > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Aug. 7, 2018

Re: [Pharo-users] Morph reacting to Window being closed

by Peter UhnÃ¡k

Thank you Henrik, #outOfWorld: was the best solution to me, as I can use it even when I don't control the window/container the morph is embedded in. Peter On Sun, Jul 29, 2018 at 10:16 PM, Henrik-Nergaard <draagren(a)outlook.com> wrote: > Hi Peter, > > There are two methods which can be used for this purpose. > #outOfWorld: > #announceDeleted > > Both are called recursively down the morph tree from the window. > > If you need to stop the window or provide a dialog then you should create a > subclass of Model and use that to keep references to things that need > cleanup and control the closing and other events. > > Best regards, > Henrik > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Aug. 7, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by H. Hirzel

P.S. Some notes and links how Jupyter notebooks relate to the Dynabook idea here http://wiki.squeak.org/squeak/1318 My aim is to use nteract as client (https://nteract.io/ ) together with a Pharo based Smalltalk "kernel" (i.e. server acting as the "scripting engine") On 8/7/18, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Thank you, Evan, for an alternative load script. > > Unfortunately it gives the same error message. > > I use a recent, pristine Pharo 6.1 installation on a 64bit Ubuntu based > Linux. > > > On 8/4/18, Evan Donahue <emdonahu(a)gmail.com> wrote: >> Try: >> >> Metacello new >> githubUser: 'jmari' project: 'JupyterTalk' commitish: 'master' >> path: >> 'repository'; >> baseline: 'JupyterTalk'; >> load >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Aug. 7, 2018