June 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] bb0fa8: 60087

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: bb0fa85d8aaca8d147b33817bd7483295b96138d https://github.com/pharo-project/pharo-core/commit/bb0fa85d8aaca8d147b33817… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-16 (Thu, 16 Jun 2016) Changed paths: M Kernel.package/CompiledMethod.class/class/instance creation/headerFlagForEncoder_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickMethodPrim.st A OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickPrimSpecialConstants.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60086.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60087.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60086.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60087.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60087 18497 EncoderForSistaV1: last integration to be usable. https://pharo.fogbugz.com/f/cases/18497 http://files.pharo.org/image/60/60087.zip

June 16, 2016

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Serge Stinckwich

On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff <timfelgentreff(a)gmail.com> wrote: > Hi all, Very impressive work, Tim&Fabio ! The power of full-automation ! > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was > migrated to GitHub. Automatic builds are running > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files) About uploading binary artifacts, this is something I asked and this nice that Fabio make it work :-) Apparently there is some problems with some artifacts that have a double .zip extension. > Right now we have enabled all platform, object memory and bytecode set > combinations that I found build scripts for - most work, but OS X 64-bit > Sista is failing right now (32-bit works). At some point we'll have to > decide which combinations to put into the CI config as "allowed failures" to > get a green badge :) > > Another thing for those not familiar with Git: Right now the entire > repository is 360MB, including all history. Most of that is old images that > were at one point committed to SVN and that have been pulled into the > repository. We could clean those out (removing them from the history) to > make the repository smaller, but I felt ~400MB is still ok (albeit > technically over the Github quota. We'll see of they complain). I would like > to ask everyone to stop committing large binary files into the repository, > however. Git is simply not very suited to dealing with binaries. If there is > a need for that, Github has support for git-lfs, which offers 1GB of free > storage with a 1GB bandwith limit per month. If we need more, we can look at > the different billing levels. > > If you're familiar with Git, the only new thing to watch out for is the > updateSCSSVersions script as described in the README. It's not relevant for > the CI, but your own binaries will only show correct versions if this script > runs at appropriate times. > > If you are not familiar with Git and don't care, there are scripts for > committing that should take care of everything as described in the README. > Again, let us know if anything doesn't work. The only difference vs SVN to > watch out for for you will be that the old scripts/svnci would commit your > changes to the server, whereas the scripts/gitci script only commits them > locally. You'll have to run `git pull` and `git push` to get them up to the > server. > > If you have any questions regarding the repository setup please don't > hesitate to ask. You shouldn't be able to break anything, since we've > disabled force pushes to both master and Cog (and thus any chance of > destroying history). What is favorite way of contributing for people outside the vm team ? pull-requests ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 16, 2016

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Tim Felgentreff

Hi all, as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 was migrated to GitHub. Automatic builds are running ( https://ci.appveyor.com/project/timfel/vm/branch/Cog, https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are uploaded ( https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files) Right now we have enabled all platform, object memory and bytecode set combinations that I found build scripts for - most work, but OS X 64-bit Sista is failing right now (32-bit works). At some point we'll have to decide which combinations to put into the CI config as "allowed failures" to get a green badge :) Another thing for those not familiar with Git: Right now the entire repository is 360MB, including all history. Most of that is old images that were at one point committed to SVN and that have been pulled into the repository. We could clean those out (removing them from the history) to make the repository smaller, but I felt ~400MB is still ok (albeit technically over the Github quota. We'll see of they complain). I would like to ask everyone to stop committing large binary files into the repository, however. Git is simply not very suited to dealing with binaries. If there is a need for that, Github has support for git-lfs, which offers 1GB of free storage with a 1GB bandwith limit per month. If we need more, we can look at the different billing levels. If you're familiar with Git, the only new thing to watch out for is the updateSCSSVersions script as described in the README. It's not relevant for the CI, but your own binaries will only show correct versions if this script runs at appropriate times. If you are not familiar with Git and don't care, there are scripts for committing that should take care of everything as described in the README. Again, let us know if anything doesn't work. The only difference vs SVN to watch out for for you will be that the old scripts/svnci would commit your changes to the server, whereas the scripts/gitci script only commits them locally. You'll have to run `git pull` and `git push` to get them up to the server. If you have any questions regarding the repository setup please don't hesitate to ask. You shouldn't be able to break anything, since we've disabled force pushes to both master and Cog (and thus any chance of destroying history). Thanks, Tim & Fabio On 15 June 2016 at 19:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi all, > > we are all finished importing the VM repository to Github, migrating the > scripts, and setting up automatic builds and hosting of binaries. We > want to switch over from SVN tomorrow morning at 7am UTC. At that point, > Tim and Fabio will merge any remaining commits on the SVN repository between > now and that time and any further development will take place on Github. > If possible, you may refrain from committing to SVN, as this will mean > less work for Tim and Fabio. > > The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch > is the new default branch and is still called Cog, this is the main focus > of development. The old trunk branch has been renamed to "oldTrunk". The > master branch will track the Cog branch and will be the repository > integrated into for releases. > > To get started, please refer to the updated README > <https://github.com/OpenSmalltalk/vm/blob/Cog/README.md> that is shown on the > Github page. > > _,,,^..^,,,_ > best, Eliot, Tim & Fabio > >

June 16, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > We can, but I remember there were some discussions and it was decided to > use meta everywhere. > > Cheers, > Andrei > If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. What are the arguments for using meta for dive-in/out shortcuts ? > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> >>> During Pharo 5 most shortcuts from tools were changed to use "meta" >>> instead of cmd. >>> >>> Cheers, >>> Andrei >>> >> >> Can we change this for spotter ? cmd instead of meta >> >> ctrl left/right is often used for text components to move to >> next/previous word. >> >> >> >>> >>> On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> >>>>> Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" < >>>>> henrik.nergaard(a)uia.no>: >>>>> > >>>>> > IIRC the shortcut is not changed, it still is meta+right(+shift). >>>>> Only the tooltip was changed to display the system specific key instead of >>>>> âcmdâ so for Windows/Linux this would be âctrlâ. >>>>> >>>>> No, it changed >>>>> >>>> In #40624, for example, it was cmd (alt-key on windows ) right/shift >>>> right >>>> >>>> >>>>> > >>>>> > >>>>> > >>>>> > Best regards, >>>>> > >>>>> > Henrik >>>>> > >>>>> > >>>>> > >>>>> > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>> Behalf Of Nicolai Hess >>>>> > Sent: Tuesday, June 7, 2016 12:56 PM >>>>> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>> > Subject: [Pharo-dev] GT-Spotter dive in shortcut >>>>> > >>>>> > >>>>> > >>>>> > Why did the shortcut for dive-in element/category changed from >>>>> > >>>>> > cmd+right >>>>> > >>>>> > cmd+shift+right >>>>> > >>>>> > to >>>>> > >>>>> > ctrl+right >>>>> > ctrl+shift+right >>>>> > >>>>> > I know there were some discussions about this and that the behavior >>>>> changed some >>>>> > >>>>> > time ago, but I don't know the rational behind this. >>>>> > >>>>> > thanks >>>>> > >>>>> > nicolai >>>>> > >>>>> > >>>>> >>>> >>>> >>> >> >

June 16, 2016

Methods with more than 15 args sketch

by ClÃ©ment Bera

Hi everyone. It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks. I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change. The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. The normal calling convention in the Smalltalk bytecode is as follows: push receiver push arg 1 push arg 2 .... push arg N send selector N is limited to 15 arguments due compiled method header & bytecode encoding. In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors. The convention will look like that: push receiver push arg 1 push arg 2 .... push arg N popIntoArray N-15 values send selector The compilation of a method with more than 15 arguments is then changed: - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg. - the compiled method header is still marked with 15 arguments In addition one needs to change CompiledMethod to: - allow larger frames (instead of 56 we could allow 128 or 256) - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon. And to change the fall-back of a couple primitives, such as: - Object>>perform: withArgs: - Object>>perform: withArgs:inSupedClass: - BlockClosure>>valueWithArgs: This design would allow methods to up to 141 arguments. What do you guys think ?

June 16, 2016

[ Pharo 5.0 ] [ Soup stable ] Zinc-Resource-Meta-Core-TheIntegrator.58 (modified)

by Bernardo Ezequiel Contreras

" [ Pharo 5.0 ] [ Soup stable ] Zinc-Resource-Meta-Core-TheIntegrator.58 (modified) Hi, this package Zinc-Resource-Meta-Core-TheIntegrator.58 is dirty after installing a stable version of Soup. Pharo image: Pharo5.0#50760 Virtual machine used: CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Platform Name: unix Class browser used (if applicable): Nautilus Steps to reproduce: #. World>>Tool>>Catalog Browser #. In the search input type Soup and press Enter #. right click >> Install stable version Actual Result: #. 'Zinc-Resource-Meta-Core-TheIntegrator.58 (modified)' Expected Result: #. no dirty packages. it seems that package 'Soup-Zinc-SeanDeNigris.1' has an extension ZnUrl>>asUrl ""Make ZnUrl polymorphic with String and Url"" ^ self. that it is already in the image. thanks " -- Bernardo E.C. Sent from a cheap desktop computer in South America.

June 16, 2016

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Tudor Girba

Thanks a lot! Doru > On Jun 15, 2016, at 7:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > whoohoo! > > thank you very much :) > > Esteban > >> On 15 Jun 2016, at 19:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. >> >> To get started, please refer to the updated README that is shown on the Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

June 15, 2016

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Esteban Lorenzano

whoohoo! thank you very much :) Esteban > On 15 Jun 2016, at 19:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi all, > > we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. > > The new repository is at https://github.com/OpenSmalltalk/vm <https://github.com/OpenSmalltalk/vm>. The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. > > To get started, please refer to the updated README <https://github.com/OpenSmalltalk/vm/blob/Cog/README.md> that is shown on the Github page. > > _,,,^..^,,,_ > best, Eliot, Tim & Fabio

June 15, 2016

Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Eliot Miranda

Hi all, we are all finished importing the VM repository to Github, migrating the scripts, and setting up automatic builds and hosting of binaries. We want to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and Fabio will merge any remaining commits on the SVN repository between now and that time and any further development will take place on Github. If possible, you may refrain from committing to SVN, as this will mean less work for Tim and Fabio. The new repository is at https://github.com/OpenSmalltalk/vm. The Cog branch is the new default branch and is still called Cog, this is the main focus of development. The old trunk branch has been renamed to "oldTrunk". The master branch will track the Cog branch and will be the repository integrated into for releases. To get started, please refer to the updated README <https://github.com/OpenSmalltalk/vm/blob/Cog/README.md> that is shown on the Github page. _,,,^..^,,,_ best, Eliot, Tim & Fabio

June 15, 2016

Re: [Pharo-dev] [Moose-dev] how to modify playground storage

by Tudor Girba

Hi, The code from the Playground gets automatically saved every time the text changes. You can find the script in play-cache. Does this behavior fit your needs? Indeed, there is not versioning. At least not yet. We would like to add this in the future. The only thing you can set for now is the target directory of the play-cache. Is this enough? Cheers, Doru > On Jun 15, 2016, at 4:59 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a way to customize the save/restore mechanism of Playground? > Because Playground is #1 place where I consistently lose code. > If the image crashes (rare) or freezes (quite common) then I almost never get the code back which is quite annoying. > Right now I have an external text editor to which I copy&paste the code frequentlyâ¦ which is _very_ stupid. > > I would like to have it persisted on the disk at least every time the contents gets evaluated, optimally every time I have a usable code. > > Ideally if this would be done on Playground side; but if that's a long shot, is there a way to hook into the saving mechanism and implement it myself? > That would also allow some platform-specific customizations, like storing every change to /dev/shm (ramdisk) so I can do a meaningful undo/redo. > > Thanks, > Peter > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

June 15, 2016