- Pharo-users - lists.pharo.org

[ANN] Iceberg v1.3.1

by Cyril Ferlicot

Hello! This week we are releasing the version v1.3 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.0 +https://github.com/pharo-vcs/iceberg/releases/tag/v1.3.1) This version will be available after we merge this PR: https://github.com/pharo-project/pharo/pull/1951 This release contains some new features such as the support of self hosted gitlab, integration with github, etc. It also contains multiple bug fixes, cleanups and enhancements. On the CI part, Guille made the Appveyor build green! This will increase the stability of the windows support. Thanks to all contributors. Enjoy! Full changelog: Features #1021 Self hosted gitlab support #1027 Improved new tag dialog to generate semantic versionning tags #1044 Show a button "View on Github" when creating a PR #1008 Add "create branch from GitHub issue" option #1048 Add commands to open remotes on Github #1010 Add menu entry in extras to force calculate diff Bug corrections #975 Metacello asks too many times what to install when there are conflicting versions #980 Iceberg should Identify better the packages and the normal files #982 The Edit Project should have a Warning if it will affect the packages #986 Iceberg does not realize changes in extended classes #999 Pulling and pushing to a gitolite server asks password #984 Conversion to Tonel generates corrupted .properties #1041 Filter in repository view don't work with capital letters #1019 Metacello Integration leaves Monticello leftover repositories #859 Creating a branch and pushing does not sets the upstream #1043 Packages starting with lowercase not recognized #991 Error on right click in the project editon wizard #775 Reviewing a PR is broken #1036 Debugger if we try to merge without selecting a branch #1064 Fix failing tests regarding clean code in Pharo Enhancements #988 Iceberg should load the packages in a single MCLoader (This will make the loads of packages atomic) #1001 Use "instance creation" instead of "instance-creation" for method protocol name #1004 Use displayScaleFactor in UI #977 Add ToolTip help to the Commands #1030 Better support for binary files #1034 SSH passphrase is now hidden Cleanups #1018 Iceberg UI relies on deprecated classes from Spec and Commander #1051 Clean useless huge hierarchy in Github plugin UI Infrastructure Enhancements #1023 Fix CI for windows -- Cyril Ferlicot https://ferlicot.fr

Nov. 5, 2018

Re: [Pharo-users] git repos cloned into unexpected directory

by Arturo Zambrano

Thanks Alistair. That solves the problem. Cheers Arturo On Fri, Nov 2, 2018 at 2:41 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Arturo, > > On Fri, 2 Nov 2018 at 12:49, Arturo Zambrano <arturo.zambrano(a)gmail.com> > wrote: > > > > Hi! > > I'm getting the following strange behavior using Iceberg in Pharo7 . > > > > My setup is like this: > > - Using Pharo Launcher > > - have several images > > > > I notice that when I clone a repository it is correctly downloaded into > pharo-local/icerberg of that image. > > > > When I load a baseline of that project, that fires the download of > several github repos, they are NOT stored in pharo-local/iceberg for the > current image. Instead, > > they stored in pharo-local of an old image. I even tried deleting the > whole old image directory (the one that pharo launcher creates). The result > is the same, all the dependencies are stored in that directory (something > recreates that). > > > > As a result several images are sharing a common iceberg location for > dependencies ... I checked that I don't have enabled "Share repositories > between images". > > > > Is there some settings file shared between all the pharo launcher > managed images? > > Thanks! > > Yes! Take a look at: > > StartupPreferencesLoader preferencesGeneralFolder > > It might be worthwhile renaming the settings folder to another > directory so that you remove all your settings and then trying again. > > Cheers, > Alistair > >

Nov. 5, 2018

Re: [Pharo-users] using latest iceberg with Pharo 6.1 / 7.0

by Sven Van Caekenberghe

> On 2 Nov 2018, at 18:24, Sanjay Minni <sm(a)planage.com> wrote: > > If I want to use iceberg then should I first update pharo image as mentioned > on github iceberg homepage (https://github.com/pharo-vcs/iceberg) If want to *use* Iceberg instead of *develop* Iceberg internals, I don't think you have to do anything, especially in Pharo 7 a stable version is already present. I assume the same in Pharo 6.1 > for 6.1: should I run the script as given on the homepage or is there an > easier way to upgrade (i.e. some UI - point and click) ? > > for 7.0: its mentioned to clone iceberg and pull changes > - i run iceberg ... > - dialog opens:repositories - there is a line "iceberg ... local > repositories missing". > how should i proceed from here ? > > I tried as follows (not sure if that is right > - double clicked on iceberg ... dialog opened: "working copy of > iceberg" ... > all lines have "local repository missing" > - clicked icon Repair > - in the dialog - selected github.com, owner:pharo-vcs, > project:iceberg as per below > <http://forum.world.st/file/t368721/iceberg01.jpg> > - then got status "uptodate" and did a fetch ... finally dialog as > below > <http://forum.world.st/file/t368721/iceberg02.jpg> > > ok ... then what do i do next ? I would say everything is loaded ... > regards > Sanjay > > > > > > ----- > --- > Regards, Sanjay > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Nov. 2, 2018

Re: [Pharo-users] git repos cloned into unexpected directory

by Alistair Grant

Hi Arturo, On Fri, 2 Nov 2018 at 12:49, Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > > Hi! > I'm getting the following strange behavior using Iceberg in Pharo7 . > > My setup is like this: > - Using Pharo Launcher > - have several images > > I notice that when I clone a repository it is correctly downloaded into pharo-local/icerberg of that image. > > When I load a baseline of that project, that fires the download of several github repos, they are NOT stored in pharo-local/iceberg for the current image. Instead, > they stored in pharo-local of an old image. I even tried deleting the whole old image directory (the one that pharo launcher creates). The result is the same, all the dependencies are stored in that directory (something recreates that). > > As a result several images are sharing a common iceberg location for dependencies ... I checked that I don't have enabled "Share repositories between images". > > Is there some settings file shared between all the pharo launcher managed images? > Thanks! Yes! Take a look at: StartupPreferencesLoader preferencesGeneralFolder It might be worthwhile renaming the settings folder to another directory so that you remove all your settings and then trying again. Cheers, Alistair

Nov. 2, 2018

using latest iceberg with Pharo 6.1 / 7.0

by Sanjay Minni

If I want to use iceberg then should I first update pharo image as mentioned on github iceberg homepage (https://github.com/pharo-vcs/iceberg) for 6.1: should I run the script as given on the homepage or is there an easier way to upgrade (i.e. some UI - point and click) ? for 7.0: its mentioned to clone iceberg and pull changes - i run iceberg ... - dialog opens:repositories - there is a line "iceberg ... local repositories missing". how should i proceed from here ? I tried as follows (not sure if that is right - double clicked on iceberg ... dialog opened: "working copy of iceberg" ... all lines have "local repository missing" - clicked icon Repair - in the dialog - selected github.com, owner:pharo-vcs, project:iceberg as per below <http://forum.world.st/file/t368721/iceberg01.jpg> - then got status "uptodate" and did a fetch ... finally dialog as below <http://forum.world.st/file/t368721/iceberg02.jpg> ok ... then what do i do next ? regards Sanjay ----- --- Regards, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 2, 2018

git repos cloned into unexpected directory

by Arturo Zambrano

Hi! I'm getting the following strange behavior using Iceberg in Pharo7 . My setup is like this: - Using Pharo Launcher - have several images I notice that when I clone a repository it is correctly downloaded into pharo-local/icerberg of that image. When I load a baseline of that project, that fires the download of several github repos, they are NOT stored in pharo-local/iceberg for the current image. Instead, they stored in pharo-local of an old image. I even tried deleting the whole old image directory (the one that pharo launcher creates). The result is the same, all the dependencies are stored in that directory (something recreates that). As a result several images are sharing a common iceberg location for dependencies ... I checked that I don't have enabled "Share repositories between images". Is there some settings file shared between all the pharo launcher managed images? Thanks!

Nov. 2, 2018

Re: [Pharo-users] glamorous toolkit alpha.2

by Hilaire

It looks great. Hilaire Le 31/10/2018 Ã 21:44, Tudor Girba a Ã©critÂ : > Glamorous Toolkit has evolved quite a bit over the past months, and we > now would like to announce that we reached alpha.2 version. It runs on > top of Pharo 7: > feenk.com/gt <http://feenk.com/gt> > -- Dr. Geo http://drgeo.eu

Nov. 1, 2018

Re: [Pharo-users] glamorous toolkit alpha.2

by john pfersich

Incroyable. /ââââââââââââââââââââ/ Encrypted email at jgpfersich(a)protonmail.com Web: www.objectnets.net and www.objectnets.org > On Oct 31, 2018, at 13:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: > feenk.com/gt > > There quite a number of new things. Some highlights are: > > - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. > <gt-tour.png> > > - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. > <gt-coder-inner-examples-execution.png> > > And this one shows how we can visualize and edit the result of querying. > <gt-coder-composite-code-search.png> > > Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. > > - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. > > > As always, we are looking forward to your feedback. > > Have fun, > The feenk team > > -- > www.feenk.com > > > -- > www.feenk.com > > "Every thing should have the right to be different." > > > > >

Nov. 1, 2018

glamorous toolkit alpha.2

by Tudor Girba

Hi, Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: feenk.com/gt There quite a number of new things. Some highlights are: - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. And this one shows how we can visualize and edit the result of querying. Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. As always, we are looking forward to your feedback. Have fun, The feenk team -- www.feenk.com -- www.feenk.com "Every thing should have the right to be different."

Oct. 31, 2018

Re: [Pharo-users] Http persistent connections

by Jimmie Houchin

On 10/31/18 8:16 AM, Sven Van Caekenberghe wrote: > Hi Jimmie, > >> On 31 Oct 2018, at 14:01, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >> Hello, >> >> I am writing an app which accesses a REST api. The documentation says this. >> >> Connection Limits >> >> To provide equal resources to all clients, we recommend limiting both the number of new connections per second, and the number of requests per second made on a persistent connection (see above/below). >> >> For new connections, we recommend you limit this to twice per second (2/s). Establishing a new TCP and SSL connection is expensive for both client and server. To allow a better experience, using a persistent connection will allow more requests to be performed on an established connection. >> >> For an established connection, we recommend limiting this to one hundred per second (100/s). Please see following section on persistent connections to learn how to maintain a connection once it is established. >> >> HTTP Persistent Connection >> >> This keeps the underlying TCP connection active for multiple requests/responses. Subsequent requests will result in reduced latency as the TCP handshaking process is no longer required. >> >> If you are using an HTTP 1.0 client, ensure it supports the keep-alive directive and submit the header Connection: Keep-Alive with your request. >> >> Keep-Alive is part of the protocol in HTTP 1.1 and enabled by default on compliant clients. However, you will have to ensure your implementation does not set the connection header to other values. >> >> >> >> I do not know how to reuse a connection. >> >> I see in ZnClient #canReuseConnection and #connectionReuseTimeout. >> >> Is the timeout from connection time or last request or access time? >> >> Does that handle everything automatically for me? >> >> I will be accessing this api multiple times a minute, sometimes multiple times a second for almost all the time. >> >> How long can I keep a persistent connection open? >> >> What are best practices? >> >> Any help and wisdom greatly appreciated. >> >> Thanks. >> >> Jimmie > Yes, Zn fully and automagically supports persistent connections. > > In a first approach, just create one ZnClient instance, configure it with your host, etc, and then keep on reusing this instance for each (subsequent) request. Zn will keep client side connections open indefinitely. But a (busy) server will kill idle connections for sure. ZnClient will always try to connect again, before giving an error, so it effectively reconnects. > > You can look at client side logging by inspecting > > ZnLogEvent announcer > > to figure out what is happening. > > One warning though: if your app is multi user / multi threaded, you will probably need an http client instance per session. It is possibly necessary to prevent mixing up authentication info as well. > > HTH, > > Sven Thanks Sven. I thought that would be how it worked. You write beautiful software. I love to try to learn from what you write. Thanks for the pointer. Jimmie

Oct. 31, 2018