- Pharo-dev - lists.pharo.org

libpng fails to download
by Alistair Grant Aug. 26, 2017

Aug. 26, 2017

Hi All, Esteban, I just attempted to build the pharo vm on Win32 and it failed due to: ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng16/libpng-1.6.29.tar.gz not being available. The current version is 1.6.30, which also appears to be unavailable from this address. I successfully downloaded 1.6.29 from: http://prdownloads.sourceforge.net/libpng/libpng-1.6.29.tar.gz?download which is referenced on what appears to be the official web page: http://www.libpng.org/pub/png/libpng.html I plan to test with 1.6.30 tonight. Is there any reason not to submit a PR pointing to sourceforge? Thanks, Alistair

3 4

Re: [Pharo-dev] [Vm-dev] usage of Pharo-vm repository [was Latest Debian, Ubuntu and CentOS packages of the pharo-vm]
by Nicolas Cellier Aug. 26, 2017

Aug. 26, 2017

2017-08-23 17:14 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > > > > On 18. Aug 2017, at 23:56, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > Hi! > > Hi Holger, > > Are the packaging stuff in opensmalltalk too, or just in pharo-vm? > > It would be great to move all to opensmalltalk. > > What is specificity of pharo-vm repository now? > > the packaging bits are in the pharo-vm repository only. What is pharo > specific from a technical point of view is that I re-generate the sources > before building the source package. There is a Makefile[1] that drives > building the source package and the actual compilation is here[2]. > > Ah yes, there have been some propositions to perform this task in a specific development branch in opensmalltalk, but so far nothing has happened... As Eliot explained once, we currently have no guaranty to regenerate identical sources (mostly we observe signed/unsigned type swapping). Probably type inference depends on the order of MethodDictionary scanning which is random. Of course it should be fixed, but someone has to do it.... Untill then, generated sources have to be versionned, there is no alternative way, otherwise we don't have reproducible artefacts... A specific build could suddenly start crashing without any easy way to reproduce and debug, think of it twice before regenerating sources... Porting VM to another OS without having to regenerate still is another valuable feature. I also find the ability to track generated-source diffs valuable: it's a complementary check, especially when changing code-generation part. That's why we continue to version generated source, whatever the ready-made thinking. Once the code generation is stable, it can be done by a bot. But don't forget that not all VMMaker commit will produce interesting C sources, because a great deal of development happens in VM-Simulator, not in C - at least the major features that Eliot and Clement are after. > I don't want this to sound offensive but the non-technical part is that it > seems easier to get changes into the PharoVM than into opensmalltalk-vm. > One example could be the FilePlugin and my attempt to use inotify without > periodic polling (wastes power, adds latency and increases your bill in > cloud computing, etc). > > Backporting upstream changes between squeak/newspeak vm and pharo vm was not sustainable, and mostly one way (unfair). That's also what motivated the switch to opensmalltalk: it's dialect neutral. Of course, changes in opensmalltalk must be done with retro and cross compatibility constraints which may require a little more effort, but at worse we have dialect-specific #ifdef directives. Remember that VM stability is valued not only because there are grumpy old and conservative fellows here ;) Without VM stability, how could we have a smooth and sustainable overall development process? That said, I hate nothing much than stale pull request and it's clearly the next obstacle to contributions (in case vm contributions was easy enough). If that's the case, that's regrettable. So don't hesitate to complain here. It doesn't mean that every PR has to be accepted. Ideally, they should be closed in a reasonnable time, with comments telling why or what needs to be improved for inclusion... IMO in absence of dedicated paid staff, we should start closing old PR (exactly as Pharo is closing stale fogbugz entries). it's not satisfying, but letting a long list of open PR is worse. Non-technically speaking, Esteban is among the core developpers of opensmalltalk, so it should be as easy to integrate changes as in a pharo-vm copy, modulo cross and retro compatibility concerns. We are supposed to have non regression tests to lower the level of heroism of the poor human integrators that we all are. > I am happy to answer questions about the packaging process or the > OBS/travis-ci integration! > > holger > > Thanks! I hope someone will jump at the opportunity :) > > [1] https://github.com/pharo-project/pharo-vm/blob/master/Makefile.debian > [2] https://github.com/pharo-project/pharo-vm/blob/master/ > packaging/pharo6-vm-core/debian/rules

1 0

new chapter on double dispatch for new book :)
by Stephane Ducasse Aug. 26, 2017

Aug. 26, 2017

feedback is welcome Good reading

3 5

[Pharo6] [Issue Tracker] Help Needed: issues tagged Pharo6
by Marcus Denker Aug. 26, 2017

Aug. 26, 2017

Hi, We have 40 issues that are tagged for Pharo6: https://pharo.fogbugz.com/f/filters/1192/6-0-All <https://pharo.fogbugz.com/f/filters/1192/6-0-All> We should move as many of those to âLaterâ, so that we can focus on important fixes and back portsâ¦ sadly here we need to be realistic: We can not fix everything or even back port everythingâ¦ we need to prioritise. It would help if people could âhelp decidingâ which issues do not need the Pharo6 milestone. Marcus

3 5

[Ann] PharoThings a live programming IoT platform based on Pharo
by Denis Kudriashov Aug. 25, 2017

Aug. 25, 2017

Hi. I am glad to announce the project PharoThings <https://github.com/pharo-iot/PharoThings> which brings the live programming environment into IoT domain. It includes: - development tools to lively program, explore and debug remote boards (based on TelePharo <https://github.com/dionisiydk/TelePharo>) - board modeling library which simplifies board configuration - Raspberry driven by WiringPi library - Arduino driven by Firmata, soon - Beaglebone, soon Follow github page <https://github.com/pharo-iot/PharoThings> and videos to get a feeling of this project: - https://youtu.be/ezfjditHjq4 - https://youtu.be/5i0tsgFtlOg - https://youtu.be/0H9of7PQet0 Now PharoThings is in beta stage together with documentation and videos. I would like any feedback on how to improve them. If you are going to Esug conference you can see PharoThings in live at awards competition. Best regards, Denis

4 3

ZnEasy question
by milton mamani Aug. 25, 2017

Aug. 25, 2017

Hi to all I want to use the next instruction in my code response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/ origin/git/url/https://github.com/hylang/hy'. response. The previous code works from command line or in a webbrowser, but I does not work with ZnEasy Because it takes the previous link as: a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) Could you please tell me what can I do for this situation? Cheers, Milton

3 3

[ Pharo 70 ] Build 59 PR 201
by Marcus Denker Aug. 25, 2017

Aug. 25, 2017

New build with one trivial fix (which will be back ported to Pharo6, too): [ Pharo 70 ] Build 59 PR 201 -DarkTheme-disabledTextColor-is-too-close-of-textColor https://github.com/pharo-project/pharo/pull/201 https://pharo.fogbugz.com/f/cases/20248

1 0

Call for Spanish/ Portuguese and more subtitles for the PharoMooc
by Stephane Ducasse Aug. 25, 2017

Aug. 25, 2017

Hi guys The Pharo is a wonderful vehicule to promote Pharo and we need your help to translate the subtitles to different languages. This year we will have english voices paid by Inria (thanks) but we cannot do everything and we need your help. https://github.com/SquareBracketAssociates/PharoMooc/tree/master/Subtitles Stef

1 0

Pharo 7 provisional HOWTO
by Pavel Krivanek Aug. 24, 2017

Aug. 24, 2017

Hi, this mail describes how to start to send pull requests to Pharo 7 Github repository from Pharo 7. Preparations ===================== - you need to have a Github account and set SSH keys. See https://help.github.com/articles/connecting-to-github-with-ssh/ - create own pharo-project/pharo repository fork. Go to https://github.com/pharo-project/pharo, click on "Fork" button and follow the instructions Get Pharo 7 image ===================== The CI jobs for the Pharo 7 defelopment are currently not fully set and we still do not publish Pharo 7 image to files.pharo.org so you cannot get it using zero-conf scripts. But we have a provisional CI job that bootstraps the Pharo 7 image. https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ There download a file named like Pharo7.0-32bit-hash.zip and decompress it. Unlike Pharo 6 images, the archive contains three files. Image, changes and sources. In Pharo 7 you have the sources file for every bootstrapped version. It has a commit hash in the name and it cannot be shared between different Pharo 7 imges, however it can be shared between images that were created as snapshots with the same bootstrapped image as ancestor. Create local clone ===================== You need a local clone of the Pharo repository. Because it contains a lot of small files, it is not a good idea to have own clone for every image. You can have only one and share them between images. But because of some current Monticello constraints you need to have the clone placed in the image directory in a folder with name 'pharo-core'. In this step we will clone the Pharo repository from pharo-project/pharo Github repository and add your fork as default pull target. We will update your fork repository to contain all latest commits from the Pharo repository in the branch named 'development'. For latest stable version (Pharo 6) we use the master branch. In the end we will checkout the repository to a particular commit from which the downloaded Pharo 7 image was bootstrapped. Imagine that you have a Pharo 7 image that is several days old and the development branch has already some commits that change code. If you would take this older image, checkout to the development branch and then do your commit, your would revert all changes done in not-loaded commits. The other option is to update your image to correspond to the repository latest commit which requires packages reloading. If you checkout to a particular commit, you are in detached HEAD state. In this state you cannot do commits directly. You need to firstly create new a new branch which we will do anyway. Evaluate the following code. This functionality will be later direct part of Iceberg UI. Do not forget to change the user name. username := 'YOUR-USER-NAME'. repository := IceRepositoryCreator new url: 'git@github.com:pharo-project/pharo.git'; location: ('pharo-core' asFileReference ensureCreateDirectory); subdirectory:'src'; createRepository. repository checkoutBranch: 'development'. repository register. fork := (IceRemote name: 'myFork' url: ('git@github.com:{1}/pharo.git' format: {username})). repository addRemote: fork. repository pushRemote: fork. repository pullRemote: repository origin. "update fork" repository backend pullFrom: repository origin. "use this low-level form to prevent packages reloading" repository push. "checkout to the commit from which the image was bootstrapped" repository checkoutBranch: (SystemVersion current commitHash). Use already created clone ===================== This is alternative to the previous step. Let's suppose that you already have your local clone. You take some Pharo 7 image and you want to create commits. Then you need to create a symlink or move/copy the repository into your image directory. Remember, it must be named pharo-core (we do not use the name 'pharo' to avoid collision with VM executable). In this step we will register an existing Pharo repository clone, set your fork as the push target, update your fork and then switch to the particular commit. repository := IceRepositoryCreator new location: ('pharo-core' asFileReference); subdirectory:'src'; createRepository. repository register. fork := repository remotes detect: [ :remote | remote remoteName = #myFork ]. repository pushRemote: fork. repository pullRemote: repository origin. repository checkoutBranch: 'development'. repository backend pullFrom: repository origin. repository push. repository checkoutBranch: (SystemVersion current commitHash). Issue processing ===================== - create new case on FogBugz to get the issue number - open Iceberg and from the context menu on the 'pharo' repository do: Pharo - Create new branch from FogBugz issue, enter the issue ID and it will fill the full branch name for you - create your changes (you can do it before the creation of the branch too) - commit and push your changes in Iceberg, this way you will commit your branch to your fork repository. Remember that the Iceberg commit window has two buttons, one for local commit, the second for commit with immediate push. They can be very long because they contain the full branch (issue) name - in Iceberg in the 'pharo' repository context menu do: Pharo - Create pull request, fill your - fill your Github credentials - leave the PR title, comment is not required, check the pull request head and base. The base MUST be pharo-project/pharo development. Create the pull requests - go to https://github.com/pharo-project/pharo/pulls, check your pull requests and put URL of it into the issue record on FogBugz (as a comment). Resolve the issue as Fix review needed Cheers, -- Pavel

10 27

20294 Add FileAttributesPlugin to the linux 32 bit VM
by Alistair Grant Aug. 24, 2017

Aug. 24, 2017

Hi Esteban, It looks like there has been some recent activity with VM plugins, I would really appreciate it if you could also add #20294. This is the plugin that fixes #isSymlink and adds symlink attributes. See: https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… If there's anything I can do to help the process, please let me know. Thanks, Alistair

3 3