- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

June 19, 2016

[pharo-project/pharo-core] 13e616: 60098

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 13e61670de0fe81cbfa08498bf7ea898b773b1f6 https://github.com/pharo-project/pharo-core/commit/13e61670de0fe81cbfa08498… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-19 (Sun, 19 Jun 2016) Changed paths: M Kernel-Tests.package/CompiledMethodTest.class/instance/tests - testing/testContainsHalt.st A Kernel.package/CompiledMethod.class/instance/literals/symbolLiterals.st M Kernel.package/CompiledMethod.class/instance/scanning/messages.st M Kernel.package/CompiledMethod.class/instance/testing/containsHalt.st R Kernel.package/Halt.class/class/halting/halt.st R Kernel.package/Halt.class/class/halting/halt_.st M Kernel.package/Halt.class/class/halting/now.st M Reflectivity-Tools.package/HaltOnCountIconStyler.class/instance/testing/shouldStyleNode_.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/testing/shouldStyleNode_.st M Ring-Core-Kernel.package/RGMethodDefinition.class/instance/testing/containsHalt.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60097.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60098.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60097.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60098.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/initialization/initializePresenter.st Log Message: ----------- 60098 18534 add Style icons so messageBrowser https://pharo.fogbugz.com/f/cases/18534 18526 better #containsHalt https://pharo.fogbugz.com/f/cases/18526 http://files.pharo.org/image/60/60098.zip

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Peter Uhnak

On Sun, Jun 19, 2016 at 10:05:45AM +0200, Max Leske wrote: > > > On 19 Jun 2016, at 01:44, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Max Leske wrote > >> Why donât you use OSSubprocess? > > > > My scripts require this functionality to be pre-loaded in a vanilla image. > > Ok, just wanted to check. > > > Also, on a minor note, some projects use OSProcess and I thought OSSP and > > OSP are incompatible. > > Not as far as I know. OSSubProcess uses the OSProcess VM plugin but is otherwise independent. They should be incompatible at the moment. There was a discussion about this some time ago in regards to Moose where you couldn't load & run OSSubprocess because OSProcess was already installed. It was solved by replacing OSProcess with this system call Sean is proposing to have in Pharo. Peter

June 19, 2016

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

by Tudor Girba

Hi, Does anyone want to pick this up on the Pharo image side? I took a brief look at this and while playing I noticed that the errors when we send more than 15 arguments seem a bit strange. Take a look at this snippet: http://ws.stfx.eu/958BXP5GR136 (you can paste it in Spotter to get the playground) In summary: - If we compile a method with a signature containing more than 15 arguments we get: "SyntaxErrorNotification: Too many argumentsââ. This is good. - If we compile a method with a message send containing between 16-31 arguments we get: "'InMidstOfFileinNotificationââ. Ok-ish. - If we compile a method with a message send containing more than 31 arguments we get: "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to 31â" This is wrong. Did I misunderstand something? Cheers, Doru > On Jun 16, 2016, at 8:10 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > 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 ? -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

June 19, 2016

System and user processes

by Max Leske

Hi, In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. Iâd like to know your opinion on the following (rough) idea: 1. We introduce two subclasses of Process: SystemProcess and UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We introduce #newSystemProcess and #newUserProcess 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) Of the following Iâm less sure: 5. We introduce #forkSystemProcess et. al Iâve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). Iâm looking forward to your comments. Cheers, Max

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by stepharo

open a bug entry. Stef Le 19/6/16 Ã 01:44, Sean P. DeNigris a Ã©crit : > Max Leske wrote >> Why donât you use OSSubprocess? > My scripts require this functionality to be pre-loaded in a vanilla image. > Also, on a minor note, some projects use OSProcess and I thought OSSP and > OSP are incompatible. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4901727.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

June 19, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Max Leske

> On 19 Jun 2016, at 01:44, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> Why donât you use OSSubprocess? > > My scripts require this functionality to be pre-loaded in a vanilla image. Ok, just wanted to check. > Also, on a minor note, some projects use OSProcess and I thought OSSP and > OSP are incompatible. Not as far as I know. OSSubProcess uses the OSProcess VM plugin but is otherwise independent. Cheers, Max > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682p4901727.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 19, 2016

[pharo-project/pharo-core] 574a53: 60097

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 574a53b03b0d089f6d0b43aea562b56690bb78c4 https://github.com/pharo-project/pharo-core/commit/574a53b03b0d089f6d0b43ae… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-19 (Sun, 19 Jun 2016) Changed paths: M Announcements-Tests-Core.package/AnnouncementSetTest.class/instance/testing/testIncludeOnlyOnce.st M Announcements-Tests-Core.package/AnnouncementSetTest.class/instance/testing/testInstanceCreation.st M Kernel.package/Object.class/instance/deprecation/deprecated_transformWith_.st M Refactoring-Critics.package/RBBadMessageRule.class/instance/private/badSelectors.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconBlock_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60096.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60097.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60096.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60097.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeInspector.class/instance/accessing/elements.st M Spec-PolyWidgets.package/EditableList.class/instance/initialization/initializePresenter.st M Spec-PolyWidgets.package/EditableList.class/instance/private/moveElementAt_to_.st M Versionner-Spec-Browser.package/VersionnerProjectPackagesPanel.class/instance/actions/editSelectedPackageRequirements.st M Versionner-Spec-Browser.package/VersionnerProjectPanel.class/instance/actions/editSelectedProjectLoads.st M Versionner-Spec-Browser.package/VersionnerToolBar.class/instance/actions/newConfiguration.st Log Message: ----------- 60097 18520 EyeTreeInspector is broken https://pharo.fogbugz.com/f/cases/18520 18527 #halt should not be in the badSelectors rule https://pharo.fogbugz.com/f/cases/18527 18525 fix for IconStyler https://pharo.fogbugz.com/f/cases/18525 http://files.pharo.org/image/60/60097.zip

June 19, 2016

[pharo-project/pharo-core]

by GitHub

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

June 19, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Ben Coman

On Fri, Jun 17, 2016 at 11:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > >> On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> >>> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> Hi Alistair, >>> >>> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710(a)gmail.com> >>> wrote: >>>> >>>>> On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: >>>>> Hi All, >>>>> >>>>> so after fixing "git remote get-url origin" to fail over to "git remote >>>>> show origin | filter and munge" the culture shock of "git commit -a" >>>>> (git >>>>> commit does nothing ?!?!?) >>>> >>>> "git commit" will commit anything that has been "git add"ed to the >>>> index. -a is a convenience to automatically stage files that have been >>>> modified. >>> >>> >>> What I don't understand is how, or indeed why, one stages modified files. I >>> get that adding files requires informing git. But why doesn't "git commit" >>> commit modified files by default? Why do I have to use git commit -a to >>> include modified files? >> >> Because you can choose what files will be part of the commit >> (cherry-picking changes). > > Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Hi Eliot, Seems enough others must have felt the same that this was added to help... https://git-scm.com/docs/git-stage Perhaps it would be preferred to use "stage" over "add" in documenting the usual workflows for this project? cheers -ben

June 19, 2016