- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 19 June 2017

by Francisco Ortiz PeÃ±aloza

Great news Esteban, thanks! On Mon, Jun 26, 2017 at 10:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Jun 26, 2017 at 2:00 PM, <estebanlm(a)gmail.com> wrote: > >> Hello! >> >> This is my weekly ChangeLog, from 19 June 2017 to 25 June 2017. >> You can see it in a better format by going here: >> http://log.smallworks.eu/web/search?from=19/6/2017&to=25/6/2017 >> >> ChangeLog >> ========= >> >> 21 June 2017: >> ------------- >> >> * Succeed!! >> >> I made [iceberg](http://github.com/pharo-vcs/iceberg) to work on >> 64bits! >> >> Now, I need to promote a new VM as stable (and probably backported it >> to Pharo 6.0) >> >> * After 1.5 days still working on 64bits version of [iceberg]( >> http://github.com/pharo-vcs/iceberg) and that >> annoying malloc crash. Last idea was the believing something is wrong >> with sizes and marshallings so I >> verified all: >> >> * I reviewed all structures and callbacks. >> * I took a look to each function call. >> >> I got some differences that needed to be fixed and perticularly a lot >> of +size_t+ that were wrongly >> mapped as +FFIUInt32+ and I have some movement: it is not crashing >> anymore on malloc (which is a >> relief), but is still crashing someplace later. > > > Great news. Thanks for your persistence. > > cheers -ben > > P.S. And shows the benefit in an open source project of having paid > engineers to work on the hard stuff. >

June 26, 2017

Re: [Pharo-dev] Saving a setting in Pharo

by Myroslava Romaniuk

Thanks Juraj, it should be exactly what I need. I'll check it out. On 25 June 2017 at 13:36, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi Myroslava, > > it should be possible by > > SystemSettingsPersistence storeIdentifier: #settingId > > Maybe the easiest way to pick your id is to look at the setting file. I do > not remember how it is generated. > > There are a few more methods, depending on what object you have in hand. > Check storing protocol. > > Regards, > Juraj > > > El 24-06-2017, a las 13:50, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> > escribiÃ³: > > > > For my GSoC project I've been working on the rule toggle so I created a > setting that bans a rule for the whole image. > > > > But I'm thinking that some of you might want to disable a certain rule > for all the following images too. > > > > Hence my question: how to save a setting programatically so that the > same setting would immediately work for the next image as well? > > > > For now I only know how to do it manually but I need a more elegant way > to do this: > > <image.png> > > > > Any help or advice would be much appreciated. > > > > Regards, > > Myroslava. > > > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

June 26, 2017

[ANN] Dates Pharo Sprints

by Marcus Denker

Hi, I have added Events for all the next Pharo Sprint Dates in the Events page: https://association.pharo.org/events There is one for each month with the exception of August (holidays, ESUG the week after). Marcus

June 26, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 19 June 2017

by Ben Coman

On Mon, Jun 26, 2017 at 2:00 PM, <estebanlm(a)gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 19 June 2017 to 25 June 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=19/6/2017&to=25/6/2017 > > ChangeLog > ========= > > 21 June 2017: > ------------- > > * Succeed!! > > I made [iceberg](http://github.com/pharo-vcs/iceberg) to work on > 64bits! > > Now, I need to promote a new VM as stable (and probably backported it > to Pharo 6.0) > > * After 1.5 days still working on 64bits version of [iceberg]( > http://github.com/pharo-vcs/iceberg) and that > annoying malloc crash. Last idea was the believing something is wrong > with sizes and marshallings so I > verified all: > > * I reviewed all structures and callbacks. > * I took a look to each function call. > > I got some differences that needed to be fixed and perticularly a lot > of +size_t+ that were wrongly > mapped as +FFIUInt32+ and I have some movement: it is not crashing > anymore on malloc (which is a > relief), but is still crashing someplace later. Great news. Thanks for your persistence. cheers -ben P.S. And shows the benefit in an open source project of having paid engineers to work on the hard stuff.

June 26, 2017

Re: [Pharo-dev] [Vm-dev] Reviving the Android VM

by Ben Coman

On Sat, Jun 17, 2017 at 3:48 AM, Michael Rueger <lists(a)andience.co.nz> wrote: > > Hi all, > > long time no see :-) > > Recently I spent a bit of time trying to piece together an Android VM > using the up to date versions of AndroidStudio, SDK and NDK. Once things > are building and running, I was planning to fold everything back into the > proper build process. > > Current (somewhat messy) state of things here > https://github.com/mrueger42/st-android > > It has been quite a long time since I looked at building VMs, so forgive > me if I'm just being stupid here... > > I was able to get the original port from Andreas to build and run, but it > is a very outdated version. Still nice to have it as a piece of history, I > think (AndroidVM in the above repo). > > Some puzzle pieces later I have something running that is based on recent > CogSpur opensmalltalk code and bits and pieces I found. Unfortunately > CogSpur doesn't seem to play well with the setjmp/longjmp used in the code > (CogDroid in the above repo). > > Plus, the VM is running on the UI thread, not something that is viewed > well on mobile. Actually it makes Android just kill the app if you block > the UI thread for too long. > Maybe of interest is Ronnie's work towards an embeddable VM... http://forum.world.st/Removing-most-of-the-windowing-code-td4924496.html cheers -ben

June 26, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60502 Home: https://github.com/pharo-project/pharo-core

June 26, 2017

[pharo-project/pharo-core] 9233b8: 60502

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9233b82ca99c4b742cb0902f6faad3e0dd3f7e20 https://github.com/pharo-project/pharo-core/commit/9233b82ca99c4b742cb0902f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-26 (Mon, 26 Jun 2017) Changed paths: R Kernel-Tests.package/AllocationTest.class/instance/testing/testOutOfMemorySignal.st M Morphic-Core.package/Morph.class/instance/debug and other/buildDebugMenu_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60501.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60502.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60501.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60502.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Profilers.package/SpaceTally.class/class/fileout/printSpaceAnalysis.st Log Message: ----------- 60502 20110 AllocationTest>>#testOutOfMemorySignal not well suited to 64-bit https://pharo.fogbugz.com/f/cases/20110 20096 Add script pragma to SpaceTally>>printSpaceAnalysis https://pharo.fogbugz.com/f/cases/20096 20174 In the debug halo of a morph: clicking on "inspect morph" and "explore morph" bring up the same window. https://pharo.fogbugz.com/f/cases/20174 http://files.pharo.org/image/60/60502.zip

June 26, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 19 June 2017

by Gabriel Cotelli

Great! Thanks Esteban for the hard work :) On Mon, Jun 26, 2017 at 3:00 AM, <estebanlm(a)gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 19 June 2017 to 25 June 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=19/6/2017&to=25/6/2017 > > ChangeLog > ========= > > 21 June 2017: > ------------- > > * Succeed!! > > I made [iceberg](http://github.com/pharo-vcs/iceberg) to work on > 64bits! > > Now, I need to promote a new VM as stable (and probably backported it > to Pharo 6.0) > > * After 1.5 days still working on 64bits version of [iceberg]( > http://github.com/pharo-vcs/iceberg) and that > annoying malloc crash. Last idea was the believing something is wrong > with sizes and marshallings so I > verified all: > > * I reviewed all structures and callbacks. > * I took a look to each function call. > > I got some differences that needed to be fixed and perticularly a lot > of +size_t+ that were wrongly > mapped as +FFIUInt32+ and I have some movement: it is not crashing > anymore on malloc (which is a > relief), but is still crashing someplace later. > > I'm now reviewing that. > > > 19 June 2017: > ------------- > > * I spent the full day trying to get [iceberg](http://github.com/ > pharo-vcs-iceberg) to work on 64bits. > > Is almost working... if it wouldn't be because I'm having a random > crash while trying to +malloc+ > something random. > > We'll see tomorrow. > > > cheers! > Esteban > >

June 26, 2017

Pharo 7 provisional HOWTO

by Pavel Krivanek

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

June 26, 2017

FileReference>>/ and path canonicalisation

by Alistair Grant

Pharo's FileSystem behaviour is currently somewhat inconsistent in its treatment of path strings. To be able to demonstrate the limitations and fixes, I'm assuming that the following files and directories have been created (/dev/shm is a memory based file system in Ubuntu): cd /dev/shm mkdir -p d1/d2/d3/d4 touch d1/t1.txt d1/d2/t2.txt d1/d2/d3/t3.txt d1/d2/d3/d4/t4.txt pushd d1 && ln -s d2/d3 ./s3 && popd 1. Path's are canonicalised during initial creation, but are not when extending the path, i.e. sending #/ E.g. '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/t1.txt" '/dev/shm/d1/' asFileReference / 'd2/../t1.txt' " File @ /dev/shm/d1/d2/../t1.txt" Automatic canonicalisation is problematic as the code doesn't handle symbolic links in the path name: ('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists " true (correct answer)" '/dev/shm/d1/s3/../t2.txt' asFileReference exists " false (wrong answer)" 2. In an attempt to be completely general, the argument to #/ is assumed to be a single directory / file. This is incorrect as the path delimiter is not allowed to be part of the file name. The result is that path comparisons and operations such as #parent give unexpected results. E.g. ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') exists " true" ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1" My PR modified FileSystem so that: 1. Canonicalisation is separated out as an operation that has to be manually requested: '/dev/shm/d1/d2/../t1.txt' asFileReference " File @ /dev/shm/d1/d2/../t1.txt" '/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize " File @ /dev/shm/d1/t1.txt" 2. The argument to #/ can be either a single file / directory name or a path. ('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent " File @ /dev/shm/d1/d2/d3" 3. Adds unit tests to cover the changed behaviour. While I believe that these changes improve Pharo overall, making it more intuitive and consistent, modifying the path creation to remove canonicalisation is not backward compatible and requires a change to PathTest>>testRelativeFromStringNormalization and PathTest>>testRelativeFromStringNormalizationParent to manually canonicalise the paths. Before I submit the patch, does anyone have any strong objections to the changes as described above? Thanks, Alistair

June 26, 2017