Github Pharo 70 dev on the starting blocks

Hi,

in fact the development of Pharo 7 has already started. But in a limited mode.
For Pharo 7 we have the #development branch on GitHub (pharo-project/pharo)
…and we are already merging pull requests.
We currently have (mostly technical) problems with the infrastructure so the monkey is not running. But we have a temporary CI jobs that can check specific pull request (that means that we bootstrap Pharo for them and run tests for all platforms).
The latest Pharo 7 image can be found here:
The image is currently not uploaded to files.pharo.org and it is not accessible by zero-conf scripts, sorry.
If you want to try to create own pull request directly from Pharo 7, you need to do this:
– create own fork of pharo-project/pharo repository on GitHub and keep it in sync
– download Pharo 7 image
– clone pharo-project/pharo repository into the image directory, the directory with the clone MUST be named “pharo-core”
– checkout the development branch or better checkout the commit from which the Pharo 7 image was bootstrapped (SystemVersion current commitHash). Beware, in that case you will be in detached head state (you need to create own issue branch later to be able to commit something). The checkout to a particular commit cannot be done currently from Iceberg, you need to use git
– add your fork repository as a remote and mark it as default push target
– create issue on FogBugz to get issue ID
– create a branch for this issue (can be done easily from the repository context menu in Iceberg [Pharo], this option is valid only if you cloned pharo-project/pharo repository)
– commit the fix to your fork repository
– create the pull request (can be done easily from the repository context menu in Iceberg [Pharo], this option is valid only if you cloned pharo-project/pharo repository)
– add link to the pull request into the FogBugz issue entry
Pull requests can be done from Pharo 6 too. Then you do not need to have clone in “pharo-core” directory, it can be everywhere, and you mast create your branches from the master branch (and create pull requests on #development)
Because we currently have limited possibilities to check pull requests, we prefer to merge PRs needed for start of the new integration process. We really do not need to break the system in this fragile state 😉
Cheers,
— Pavel

Geo location data reading with Zinc: a Breeze

|client znResponse|
client := ZnClient new.
client host: ‘www.geoplugin.net’.
client addPathSegment: ‘json.gp’.
client queryAt: ‘ip’ put: ‘188.194.228.195’.
client contentReader: [ :entity | STONJSON fromString: entity contents ].
znResponse := client get; contents.

While waiting for the PullRequest menu in Pharo70

Hi,

Of course we just want you to have to

  • enter a bug entry
  • and create a pullrequest using a magic button to send a fix to Pharo.

Now before getting there, here is a description of what we will use.

Stef

Hi

we still do not have official guidelines but this should help you:
1) you need own fork of pharo-project/pharo repository
2) clone pharo-project/pharo into directory named “pharo-core” in your working directory. You can do it from Iceberg (Clone repository) or by this script:
Iceberg enableMetacelloIntegration: true.
target := ‘pharo-core’ asFileReference ensureCreateDirectory.
repository := IceRepositoryCreator new
remote: (IceRemote url: ‘git@github.com:pharo-project/pharo.git’);
location: target;
subdirectory:’src’;
createRepository.
repository backend checkoutBranch: ‘master’.
repository addRemote: (IceRemote name: ‘myFork’ url: ‘git@github.com:yourGitHubAccount/pharo.git’).
repository register.
Do not forget to change your fork URL. If you will do  it from Iceberg, you need to add remote manually.
3) set your fork remote as default push remote
4) create issue on FogBugz. You will obtain issue number e.g. 12345
5) in repository context menu in Iceberg and do Pharo-Create new branch from FogBugz issue, you will enter the issue number and the dialog wil fill the full branch name
6) do you changes and commit (and push) them to your fork repository
7) in repository context menu in Iceberg do: Pharo-Create pull request. Login, by default the title will be set to the branch name, let it be, comment is not needed. “From” will be your fork and your issue branch. “To” will be pharo-project/pharo and “development” branch
8) as soon as you create the pull request, add URL to this pull request to the FogBugz issue and mark it as resolved (fix review needed).
You need not to do it exactly this way, e.g. you can create the pull request from Github web interface, but the pull request name must contain the the issue number. And your issue must contain link to the pull request.
Cheers,
— Pavel

Pharo 6 snap package for Ubuntu

Hi Everyone,

I’ve updated the Pharo 6 snap package for Ubuntu.

The major advantages of using the snap package are:

– No need to install all the 32 bit dependencies on a 64 bit system,
they’re all contained and isolated within the snap package.
– Automagically distinguish between 32 bit and 64 bit images and run the
appropriate VM (as with the ZeroConf package, the 64 bit VM still
needs more testing).

To get Pharo up and running on Ubuntu 16.04 or later:

# Install Pharo
$ sudo snap install –candidate pharo –classic
# If your system isn’t configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go…
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo

If you’re on Debian or Ubuntu 14.04 you’ll need to install snapd, see
https://snapcraft.io/docs/core/install

The VM is the threaded heartbeat, dated 201705310241.

The installation flags are:

–candidate – The edge and beta channels are for development versions.
It progresses to candidate and then stable.
–classic – Snap packages are normally sandboxed for security
reasons.  Since Pharo is a development environment
in which we want to be able to run any executable,
or load any library, it is installed with access to
the entire system (as the running user).

Why use snap packages?

– They include all dependencies.  In particular, for the 32 bit
versions, this means that it isn’t necessary to install all the 32 bit
architecture and associated dependencies.
– Including dependencies means that there shouldn’t be any problems with
incompatible library versions when upgrading.

Why not use snap packages?

– It’s a relatively new technology, with a number of rough edges.
– There may still be issues with its sandboxing that I haven’t
discovered yet.
– Because the package uses classic confinement, it isn’t
cross-distribution in practice (unfortunately).

Please let me know of any other advantages or disadvantages you think
should be listed here.

If you don’t trust me to configure your system correctly (which requires
sudo):

– All the scripts that make up the sub-commands are visible, e.g.
pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG

The packaging code is at: https://github.com/akgrant43/pharo-snap

Cheers,
Alistair

Ephemeric Cloud

Hello,

I just wanted to make some clarifications on what is going on with
PharoCloud and how I see the future of the project.

PharoCloud is not closing, but just dropping VM hosting support. We will
continue to develop and maintain Ephemeric Cloud which allows you to publish
Pharo web applications online much easier than any other VM hosting can
offer. In some way PharoCloud just becomes more “cloudy” by dropping
outdated technologies off 🙂

Our plan is to make the project more community oriented. We integrated
PharoCloud with Pharo.org SSO and provide *FREE* access to all *Pharo
Association* members. You are welcome to log in to the cloud with your Pharo
Association account at:

https://www.pharocloud.com/manager/connect

We are encouraging you to migrate your applications hosted as Pharocloud VMs
to the Ephemeric Cloud. It is much more simple! We have some positive
experience already. There are some examples I moved from VM hosting to
Ephemeric Cloud:

http://pharo.pharocloud.com
http://seaside31.swarm.pharocloud.com/
http://eph-b147b6e2.swarm.pharocloud.com/
http://smalltalk.mikefilonov.ru/

Here you can find a quick start guide to Ephemeric cloud and some tips on
how to publish your app:
http://docs.swarm.pharocloud.com/article/getting_started

Also there is a REST API you can use to manage the cloud. And there is also
a Pharo wrapper around the REST-API:
http://docs.swarm.pharocloud.com/article/pharo_library_reference

We also have video guides:
quickstart (sorry for old UI of the manager)
https://www.youtube.com/watch?v=a1GfuT9M4qo
curl example: https://www.youtube.com/watch?v=9dKBCpj96cU

In case of any questions or issues with images, please feel free to contact
me.

Mike Filonov

DataFrame a really nice new collection

This is great to see all this energy flowing into Pharo.


View story at Medium.com

Not link because well wordpress eat it.

Thanks Oleksandr for this cool new collection. It was nice to talk with you at Lviv.

Powerful Pointer Finder

The pointer finder finds the shortest paths so it is good for finding the reference that is causing the memory leak.

MCHttpRepository
location: ‘http://www.smalltalkhub.com/mc/JohnBrant/ReferenceFinder/main’
user: ”
password: ‘’

Once loaded, you can evaluate something like “ReferenceFinder findPathToInstanceOf: MyClass”.  That will return a reference path or nil if no path exists from the Smalltalk global to an instance of MyClass. If you want to find a path to a particular instance, you can use “ReferenceFinder findPathTo: myInst”.

In the past, I’ve found that NECController and some compiler infrastructure (I forget the class) have been culprits for memory leaks with their caches.

John Brant