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

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