October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Should literals be immutable ?

by Marcus Denker

I could imagine cases where, in very tight memory situations or with very very large literals, we could make use of modifying literals. But I'm not sure this is a significant requirement, or that it couldn't be considered if there is a significant (and rich) use case to fund the development of the slow path. Pharos does not target classic âresource constraintâ embedded scenarios. (else we would do many things a lot different) Is there a critic rule catching that sort of thing? That we could run on Squeaksource / Smalltalkhub? No, as you can hand a reference to a literal over to someone else who does not even know that it is a literalâ¦ this dreaded âam I going insane, itâs writing right hereâ bug where you change a string somewhere that actually is a string literal of some methodâ¦ Â Â Marcus

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Thierry Goubier

2014-10-27 16:22 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hey guys, > > I was discussing about methods like that with Marcus: > > MyClass>>foo > #(false) first > ifFalse: [ > 'first call since compilation' logCr. > #(false) at: 1 put: true ] > ifTrue: [ 'other calls' logCr ] > What, you can do that? > > DoIt: > 4 timesRepeat: [MyClass new foo ] > > Transcript: > 'first call since compilation' > 'other calls' > 'other calls' > 'other calls' > > In the sista image/VM, we are most probably going with Eliot to implement > a slow path when you edit the literal of a method (deoptimizing the method) > so we can consider that the literals are immutable in the generic case (and > if it's not true, execution falls back to a slow path). > > But I was thinking, does it worth it to implement the slow path ? > Couldn't we just put literals as immutable all the time ? > I would do that, yes. > The methods as the one shown before would not work any more. But does > someone use it ? > I could imagine cases where, in very tight memory situations or with very very large literals, we could make use of modifying literals. But I'm not sure this is a significant requirement, or that it couldn't be considered if there is a significant (and rich) use case to fund the development of the slow path. Is there a critic rule catching that sort of thing? That we could run on Squeaksource / Smalltalkhub? Thierry > > ... > >

Oct. 27, 2014

Re: [Pharo-dev] Should literals be immutable ?

by Craig Latta

Hoi ClÃ©ment-- In keeping with the principle of least surprise (and least time spent chasing strange bugs at 4am :), I would prefer that literals be immutable. thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Oct. 27, 2014

Should literals be immutable ?

by ClÃ©ment Bera

Hey guys, I was discussing about methods like that with Marcus: MyClass>>foo #(false) first ifFalse: [ 'first call since compilation' logCr. #(false) at: 1 put: true ] ifTrue: [ 'other calls' logCr ] DoIt: 4 timesRepeat: [MyClass new foo ] Transcript: 'first call since compilation' 'other calls' 'other calls' 'other calls' In the sista image/VM, we are most probably going with Eliot to implement a slow path when you edit the literal of a method (deoptimizing the method) so we can consider that the literals are immutable in the generic case (and if it's not true, execution falls back to a slow path). But I was thinking, does it worth it to implement the slow path ? Couldn't we just put literals as immutable all the time ? The methods as the one shown before would not work any more. But does someone use it ? ...

Oct. 27, 2014

Re: [Pharo-dev] Experience makers

by Yuriy Tymchuk

I like your ideas, but my point was different. CI is there for automatically making sure that the changes that you add to your repository donât break anything. We use it to assemble our working environment. And my point is that âourâ thing is in some repo, but to change it, we need to put it into some environment. So it would be nice if the launcher that we have now could do that. Uko > On 27 Oct 2014, at 14:16, Ben Coman <btc(a)openInWorld.com> wrote: > > Yuriy Tymchuk wrote: >> To summarise Iâd like to propose adding startup scripts manager to pharo luncher. Whatâs more, usually we are working on our one âprojectâ. And as itâs a good practice to start from a fresh image, we either have to load a configuration of it into fresh images or download pre-built image from CI. And we are too bound to CI because of image building. What I see as next step in the development workflow, is to say to the launcher: I want this Project is this Image (3.0, 4.0) with this prefs (experiences). The launcher builds the thing and you can work with it. >> In general I like your idea a lot, but letâs have a little discussion to hear what the others have to say. >> Uko > > That would be a REALLY cool. Something like like a CI builder for home? > Doubly cool if the framework could be bent to do something like the following scenarios... > > 1. A menu item "Test A Slice" that asks for a case number, creates a new image from the latest "Local" template, named like... > "Case12345-Build40230 The Case Description" > then on that image runs a script that > a. Opens Inbox repository > b. Adds slice number to filter > c. For latest slice, clicks <Changes>. "as a reference after merge" > d. For latest slice, clicks <Merge>, then waits for user interaction. > > 2. Allow user to define a test script to be run across multiple images, in a binary search pattern, to help isolate the first occurrence of a bug. > > cheers -ben > > >>> On 27 Oct 2014, at 13:13, stepharo <stepharo(a)free.fr> wrote: >>> >>> Dear experience makers (Martin, yuriy, tommaso, roberto and others,) >>> >>> you would like to have many people doing your experience.... I know you would love that. >>> Here is my suggestion: ease the use of new images. >>> Each time I want to load the projects I'm hacking and I do not have a jenkins for it, it is painful (setting up >>> the repos.... loading....). So I do not change often images and I'm reluctant to load new stuff (like your experiments) >>> >>> >>> - build a simple little tool that could be integrated in pharo and would do the following: >>> - let the user (un)/select some packages or configurations >>> - generate a script to reload these configurations really easily >>> >>> This way I can load my project and then you provide a script for your experience. >>> and after I can reload my project with your material for experience in my new image. >>> Right now I do not like to hack the preference file because I have images where I do not want any interference >>> >>> So is my proposal clear? >>> >>> Stef >>> > > >

Oct. 27, 2014

[pharo-project/pharo-core] 0879bb: 40332

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 0879bb45a9ddd06adeba5dba838d6ec1e3489c7a https://github.com/pharo-project/pharo-core/commit/0879bb45a9ddd06adeba5dba… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-27 (Mon, 27 Oct 2014) Changed paths: A OpalCompiler-Core.package/IRBlockReturnTop.class/instance/accessing/successor.st M OpalCompiler-Core.package/IRFix.class/README.md R OpalCompiler-Core.package/IRTranslatorV2.class/instance/private/popScopeIfRequired_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitBlockReturnTop_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitReturnInstVar_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitReturnLiteral_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitReturnReceiver_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitReturn_.st M OpalCompiler-Core.package/IRTranslatorV2.class/instance/visiting/visitSequence_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script332.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40332.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40332 14327 Simplification of the popScope logic in IRTranslator https://pharo.fogbugz.com/f/cases/14327 http://files.pharo.org/image/40/40332.zip

Oct. 27, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 27, 2014

Re: [Pharo-dev] convention for examples?

by Tudor Girba

Hi, We should support: <example: 'Title'> <example> (in this case, the name is by default derived from the method selector) Cheers, Doru On Mon, Oct 27, 2014 at 2:16 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Stef, > > I renamed the pragmas that we used in the inspector to <example> and > <example: 'Title'> (the method can have any name) > It will be integrated with the next GTools version and then we can iterate > (keep the pragmas, move examples to other classes, etc) > > Cheers, > Andrei > > On Mon, Oct 27, 2014 at 9:15 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi doru and others >> >> so finally what is the conventions we should use for example? >> >> exampleFooBar >> <example> >> >> Stef >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 27, 2014

Re: [Pharo-dev] Experience makers

by Tudor Girba

Thanks Stef for this proposal! This is definitely the way we should go. Doru On Mon, Oct 27, 2014 at 1:13 PM, stepharo <stepharo(a)free.fr> wrote: > Dear experience makers (Martin, yuriy, tommaso, roberto and others,) > > you would like to have many people doing your experience.... I know you > would love that. > Here is my suggestion: ease the use of new images. > Each time I want to load the projects I'm hacking and I do not have a > jenkins for it, it is painful (setting up > the repos.... loading....). So I do not change often images and I'm > reluctant to load new stuff (like your experiments) > > > - build a simple little tool that could be integrated in pharo and > would do the following: > - let the user (un)/select some packages or configurations > - generate a script to reload these configurations really > easily > > This way I can load my project and then you provide a script for your > experience. > and after I can reload my project with your material for experience in my > new image. > Right now I do not like to hack the preference file because I have images > where I do not want any interference > > So is my proposal clear? > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 27, 2014

Monticello package cache

by Christophe Demarey

Hello, I find the implementation of MCCacheRepository(class)>>defaultDirectory a bit strange: defaultDirectory | directories | directories := {('package-cache' asFileReference). (FileLocator temp). (FileLocator home)}. directories do: [ :directory | [ ^ directory ensureCreateDirectory; yourself ] on: Error do: [ "ignore and try the next directory" ] ]. Error signal: 'Can''t create a package-cache' We first search in the working directory (looks good), and then we try to use the temporary directory or the home directory without creating any directory hierarchy (e.g. pharo/package-cache). I would like to, at least, add 'pharo/package-cache' directories for temp and home. Another problem is that it is not consistent with FileLocator(class)>>cache. It points to the system cache directory that is not used by MCCacheRepository. WDYT? Christophe.

Oct. 27, 2014