- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TaskIT Revealed

by Tudor Girba

Hi, This sounds very nice! I am trying to give it a shot, but I encounter a DNU for BlockClosure>>asTask. I have loaded the latest code from all packages, but this method is not defined. Cheers, Doru On Mon, Jun 23, 2014 at 7:32 AM, Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > In general terms there are pharo processes. > > val := [2+2] shooitIt. > > val := [2+2] scheduleIt. > > val := [2+2] forkIt. > > > > All of this snippets will give you a future, all will be related with a > pharo process, but each process has different meaning. the firstone is a > common 2+2 block opened in a pharo process. the second one is a block > assigned to one of the by-default two worker pharo processes from the > thread pool. ( in this case the pharo processes do not run directly the > task, but run a process that run tasks. Then, the first one is applied just > there, the second one when is its turn. > > Finally the third one will use osprocess to open the same image (so, by > now, this will work without anyproblem if you have saved the image just > before, or if you didnt change any of the code to be executed) with the > same vm and it will give the block to be executed. In our local image, > there will be spawned a watch pharo process that will check if the third > image has finished, and deploy the future for it. > > > In the behind the scenes, each of this convenient methods is implemented > with a different kind of runner and process reification. > > > > > > > > > > > > > 2014-06-23 0:54 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > are those OS processes or Pharo processes ? >> >> >> On Mon, Jun 23, 2014 at 1:39 AM, Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> >>> Hi all, im glad to announce TaskIT. You may already knew about, after >>> all it's not confidential ;) and it has documentation on-going since some >>> months ago. >>> >>> Task IT is package that provides a cool way to deal with processes. Even >>> when this version is stable, it still in design and we want to make it >>> consistent and powerfull. >>> >>> It counts with a chapter in pharo enterprise book and some cool tests. >>> >>> We have moved the main distribution repo to CAR >>> >>> http://smalltalkhub.com/#!/~CAR/TaskIT/ >>> >>> >>> The main easy things to do with this revision are: >>> >>> " closures " >>> val := [ 2+2 ] shootIt. >>> val isKindOf: TKTFuture. >>> val onSuccess: [: rslt | rslt == 4 ] "async" >>> val value == 4. " sync " >>> >>> rslt := [ 2+2 ] shootIt asResult. >>> rslt == 4 "sync on demand" >>> >>> " objects " >>> >>> val := 2 paralellize + 2. >>> val == 4 "sync on demand" >>> >>> >>> " staying in tune " >>> >>> val := [ "some task" ] shootIt asStickyReference. >>> >>> val := nil. >>> " sticky means that if this future is taken by the GC, it will kill the >>> process" >>> >>> >>> >>> " looping " >>> >>> >>> val := server paralellize looping serveOnce: anyParameter >>> asStickyReference. >>> >>> "this will execute in a new process, in a loop, server serveOnce: >>> anyParameter." >>> >>> You can stop it by doing >>> val:= nil. >>> >>> "or using a disgusting magic variable, for that check the samples :). >>> But do not rely on that kind of things, because it will not be supported " >>> >>> >>> >>> For more advanced and cool usages, check the Doc. >>> >>> >>> FAQ: >>> >>> 1- Yes, the "sync" on demand is implemented with a proxy and a become. >>> 2- Yes, we are changing the API of the processes that persist in time. >>> >>> CREDITS >>> All CAR team in general was great inspiration, particularly, Guille >>> Polito full operational commiter and of course is always a good idea to >>> discuss with him, Nick Papoylias, is also great to discuss with him. Luc, >>> Noury, Jannik: several ideas are discussed with them as well, and they >>> always gave me support. >>> >>> and from RMOD Esteban Lorenzano, also discussing and proposing. >>> >>> Thanks all :). >>> >>> >>> OTHERS: >>> If you want to go to the darkside (dark because is not documented yet, >>> but in the case of PoolIT, that it has some doc ) you can also add to your >>> combo: >>> ActIT: a simple Actor extention for taskit. >>> ForkIT: an extention that runs blocks in background image (it adds a >>> nice button to the test runner, letting you run all your tests in a >>> background image and installing the results after the execution) >>> PoolIT: it adds a pool of workers, it consumes tasks and ensure you a >>> limited amount of threads. >>> PlanIT: a basic and not yet full developed algebra for composing >>> processes. >>> >>> >>> >>> I encourage you to use it, it is being used in PhaROS since a lot of >>> time. And please any bug and enhancements, you can contact us. Since we are >>> working on the next version is a good time to define what features are >>> really needed. >>> >>> >>> Salut. >>> >>> >>> Santiago. . >>> >>> >>> >>> >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014

New Cog VMs available

by Eliot Miranda

...in http://www.mirandabanda.org/files/Cog/VM/VM.r3021/. In particular, these fix VM crashes when running the AllocationTest in Spur. CogVM source as per VMMaker.oscog-eem.787/r3021 Fix mixup of old & young spaces in primitiveVMParameter, and comment some new parameters. Fix return types for positive[64/32]BitValueOf:. positive32BitValueOf: must answer a usqInt, positive64BitValueOf: must answer a usqLong. Use positiveMachineIntegerValueOf: to decode arg in primitiveNewWithArg and ensure positiveMachineIntegerValueOf: is inlined there-in. win32: Set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header of the Windows executables to allow e.g. Spur to allocate more than 2Gb. Spur: Fix sign and overflow issues in instantiating larger objects and determining the size of large instances. Fix some freeChunk accesses that used fetchPointer:ofObject:. Cog ARM: Fix prim return for compileInterpreterPrimitive: on RISCs. On return from interpreter prim, ret pc is in instructionPointer and must return to whence it came, which is the stack on CISC and the LinkReg on RISC. Hence restoring the receiver reg requires different offsets in the two cases. Rework the rotatable quick constant logic a little and clean up users. Fix concretizeMoveRXbrR to do byte not word loads. Fix concretizeConditionalJumpLong: to actually be conditional. Oops. Correct mistaken callersaved reg stuff for ARM Fix concretizedRetN to not over-bump the SP The method abort trampolines shouldn't pop anything, especially now we have the pushLinkreg: arg to manage the LinkReg more easily. Slang: Rip out the UseRightShiftForDivide optimization. It gets unsigned division wrong, and C compilers can and will optimize this correctly themselves. -- best, Eliot

June 29, 2014

Sharing/Versioning Data

by Sean P. DeNigris

How do we do this now with MC? Are there options other than "encode in string returned by method" like I've seen done for image data? My use case is that I have a very static domain, and so doesn't require user changes. I think the easiest way to distribute it would be to edit the data on a dev image, and then somehow save the data in a way that can be committed with MC so that loading via MetaC config loads the latest version of the data. What would be the best way to do that? Thanks. p.s. on a related note, I'm also interested in distributing static files with the code e.g. maybe a PDF readme ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > we are on github I don't think that code mirrored by a robot tells us much about the potential impact of using GitHub the way it was designed - discussions directly in commit diffs; integration of issues, commits, users; a real depiction of who contributed what and when... ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p47655… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Sean P. DeNigris

EstebanLM wrote > - better visibility +1. I found an online tool that analyzes a person's programming contributions that described me as (paraphrase): "a Javascript expert who dabbles in Smalltalk" or some such nonsense, because it could see my (very) few Amber contributions on GitHub, but was blissfully unaware of my countless MC commits. ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-get-started-with-Git-and-Pharo-tp4765096p47655… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Sean P. DeNigris

kilon alios wrote > One of things that very much annoy me with Amber is its installation , if > Pharo is installation heaven because it does not need an install , > installation of Amber is far from ideal especially if you are not familiar > with web dev Have you checked it out lately? The current procedure seems very streamlined... # Install the CLI tools (only needs to be done once per computer) sudo npm install -g amber-cli # Create the project structure mkdir example-project cd example-project/ # Create and initialixe a new Amber project amber init ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-and-Amber-relationship-tp4764889p4765519.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by phil＠highoctane.be

You just got me convinced to go with Thierry's tooling... Phil Le 28 juin 2014 17:13, "Johan Brichau" <johan(a)inceptive.be> a Ã©crit : > Stef, all, > > First, you need to know how to work with git and understand the > vocabulary. Otherwise, you _will_ get confused, and probably get disgusted. > So, beware... git was made for and by linux people, which is all I am > going to say about that... > > In my experience, tools always help and I can recommend sourcetree [1] or > git tower [2]. > Reading the links that Dale mentioned is a very good idea too. > > Next, Dale's 'getting started with github' [3] is a good intro to make > your first git project work and understand the extra steps you need to make > to manage source code. > It does not have to be a github project. > > Let me also comment a bit on why we (at Yesplan) are now trying to switch > from monticello to git for our daily work. I am using git for over a year > now and we are actively switching to use it on a daily basis. > > First of all, in our daily work, we need continuous deployment. When a > feature is ready, it must be shipped into production as soon as possible. > If you are not the only one working on a codebase, continuous deployment > requires that each feature is developed in its own branch and can only be > integrated with the main codebase when it's ready and stable. Monticello > just does not support branching well. In Git, this is natural. You can > easily create feature branches, do partial publishes, merge the changes > from the main codebase back into your feature branch, explore the version > history, etc. I must also add that github's pull request and code > commenting feature is a very productive way of working together on the same > codebase in a structured way. > > About a year ago, I almost only used git tools to merge in the changes > from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a > huge amount of package changes, which is about the worst case scenario to > understand any evolution and merge it in a port (which has code changes > itself). In about an afternoon of work, most of the dust had settled and I > was using the git merge to understand code moves and to prevent > gemstone-specific changes from being overwritten again. The best part there > was probably the sub-method-level merges. Also, the reason I did not need > any Smalltalk browser to do the merges is because filetree exports packages > and classes as directories and methods as files. If you use the column > layout of the Finder on Mac, the Finder becomes the System Browser (at > least for understanding and navigating the structure of the source code, > which is what you need at that level). Sourcetree had such a browser > internally until very recently... so I am disappointed they removed that. > > Besides numerous other projects, we have Seaside hosted in a github > repository too. The advantages are that we can test every feature branch > and every platform automatically with Travis CI. We don't use pull requests > in the community, but if we did, it would be way easier for contributors > and maintainers. Forking and pulling makes it easy for people to patch > something and contribute the code back, while at the same time, it allows > the maintainers to protect the code base from harmful changes. > > Finally, the biggest pain with filetree is that it carries the monticello > metadata. If you work together on the same branch, you _will_ get stupid > merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge > tool [5] is a wonderful tool. Since I started using that, merges of the > metadata are done by git automatically and I just forget about them. Nice > work Thierry! > > Another pain is that publishing and loading code is a two-step process: > files on disk and code in your image. You need to very carefully > synchronize these. You may switch a branch on disk but forget to load it in > the image, or start publishing code from the image to the disk where a > different branch was checked out. This is where better tools for git from > within the image will help. > > those were my 2 cents ;-) > Johan > > [1] http://www.sourcetreeapp.com > [2] http://www.git-tower.com > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… > [4] https://github.com/glassdb/Seaside31 > [5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver > > On 28 Jun 2014, at 10:12, stepharo <stepharo(a)free.fr> wrote: > > > thanks > > > > Now is there a tutorial? Beause > http://forum.world.st/Pharo-git-td4693999.html scared me. > > > > > > On 27/6/14 15:53, Goubier Thierry wrote: > >> > >> > >> Le 26/06/2014 19:11, Yuriy Tymchuk a Ã©crit : > >>> I can only suggest you to read my blogpost about configurations and > versioning: > http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… > >>> > >>> I usually mix filetree and gitfiletree. Last one is better, because > you donât have to remember to commit in git each time you commit in pharo. > >>> (Also I think that gitfiletree is not working with Pharo4) > >> > >> Now it works with Pharo4! > >> > >> Thierry > > > > > > >

June 28, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Johan Brichau

Stef, all, First, you need to know how to work with git and understand the vocabulary. Otherwise, you _will_ get confused, and probably get disgusted. So, beware... git was made for and by linux people, which is all I am going to say about that... In my experience, tools always help and I can recommend sourcetree [1] or git tower [2]. Reading the links that Dale mentioned is a very good idea too. Next, Dale's 'getting started with github' [3] is a good intro to make your first git project work and understand the extra steps you need to make to manage source code. It does not have to be a github project. Let me also comment a bit on why we (at Yesplan) are now trying to switch from monticello to git for our daily work. I am using git for over a year now and we are actively switching to use it on a daily basis. First of all, in our daily work, we need continuous deployment. When a feature is ready, it must be shipped into production as soon as possible. If you are not the only one working on a codebase, continuous deployment requires that each feature is developed in its own branch and can only be integrated with the main codebase when it's ready and stable. Monticello just does not support branching well. In Git, this is natural. You can easily create feature branches, do partial publishes, merge the changes from the main codebase back into your feature branch, explore the version history, etc. I must also add that github's pull request and code commenting feature is a very productive way of working together on the same codebase in a structured way. About a year ago, I almost only used git tools to merge in the changes from Zinc 1.7 to 2.3.2 for the Gemstone port. In that change, Sven made a huge amount of package changes, which is about the worst case scenario to understand any evolution and merge it in a port (which has code changes itself). In about an afternoon of work, most of the dust had settled and I was using the git merge to understand code moves and to prevent gemstone-specific changes from being overwritten again. The best part there was probably the sub-method-level merges. Also, the reason I did not need any Smalltalk browser to do the merges is because filetree exports packages and classes as directories and methods as files. If you use the column layout of the Finder on Mac, the Finder becomes the System Browser (at least for understanding and navigating the structure of the source code, which is what you need at that level). Sourcetree had such a browser internally until very recently... so I am disappointed they removed that. Besides numerous other projects, we have Seaside hosted in a github repository too. The advantages are that we can test every feature branch and every platform automatically with Travis CI. We don't use pull requests in the community, but if we did, it would be way easier for contributors and maintainers. Forking and pulling makes it easy for people to patch something and contribute the code back, while at the same time, it allows the maintainers to protect the code base from harmful changes. Finally, the biggest pain with filetree is that it carries the monticello metadata. If you work together on the same branch, you _will_ get stupid merge conflicts on that metadata. Here, Thierry Goubier's FileTreeMerge tool [5] is a wonderful tool. Since I started using that, merges of the metadata are done by git automatically and I just forget about them. Nice work Thierry! Another pain is that publishing and loading code is a two-step process: files on disk and code in your image. You need to very carefully synchronize these. You may switch a branch on disk but forget to load it in the image, or start publishing code from the image to the disk where a different branch was checked out. This is where better tools for git from within the image will help. those were my 2 cents ;-) Johan [1] http://www.sourcetreeapp.com [2] http://www.git-tower.com [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… [4] https://github.com/glassdb/Seaside31 [5] https://github.com/ThierryGoubier/GitFileTree-MergeDriver On 28 Jun 2014, at 10:12, stepharo <stepharo(a)free.fr> wrote: > thanks > > Now is there a tutorial? Beause http://forum.world.st/Pharo-git-td4693999.html scared me. > > > On 27/6/14 15:53, Goubier Thierry wrote: >> >> >> Le 26/06/2014 19:11, Yuriy Tymchuk a Ã©crit : >>> I can only suggest you to read my blogpost about configurations and versioning: http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo… >>> >>> I usually mix filetree and gitfiletree. Last one is better, because you donât have to remember to commit in git each time you commit in pharo. >>> (Also I think that gitfiletree is not working with Pharo4) >> >> Now it works with Pharo4! >> >> Thierry > >

June 28, 2014

Re: [Pharo-dev] [Pharo4] Slots: Code Generation and an Example

by Tudor Girba

This is really brilliant! Doru On Sat, Jun 28, 2014 at 9:34 AM, stepharo <stepharo(a)free.fr> wrote: > This is so cool. I remember when we played one afternoon in 2008 to see > if this interplay would work. > > Stef > > > > On 27/6/14 10:19, Marcus Denker wrote: > > Hi, > > So now Opal delegates code generation for read and write to the Slot meta objects. > The methods called are #emitValue: and #emitStore:, the parameter is an IRBuilder. > > With this the implementor of a Slot is free to generate whatever bytecode needed, it will > be inlined at the read or assignment site in the method. > > For the ivar Slot this is e.g. just > > emitStore: methodBuilder > > methodBuilder storeInstVar: index > > emitValue: methodBuilder > > methodBuilder pushInstVar: index. > > > Now the implementors of Slots should not need to be bothered about bytecode, therefore we have > in the superclass of all Slots defaults emit methods that implement a **reflective** read and write using > the MOP of the Slot itself (slower than code generation, but often enough): > > emitValue: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #read: > > emitStore: aMethodBuilder > aMethodBuilder > pushLiteral: self; > pushReceiver; > send: #writeToSlot:of: > > > What this means is that for someone who wants to implement a slot, you do not have to deal with bytecode at all. > > Here is a simple Slot: > > Slot subclass: #TestSlot > instanceVariableNames: 'value' > classVariableNames: '' > category: 'Slot-Scopeâ > > > read: anObject > ^ value > > write: aValue to: anObject > value := aValue > > > So this is a strange kind of Slot that stores the value in itself, which means it is shared between all objects as there is only > one Slot meta object per class per slot. (not something you want to do in real world, but a nice demo) > > Now we can create a class (not yet easily as we have not yet enabled a class template, so lets use the ClassBuilder directly): > > PharoClassInstaller make: [ :builder | > builder name: #A; > slots: { TestSlot named: #iv }; > category: #Playground ]. > > > In class A we can implement accessors: > > iv > ^iv > > iv: anObject > iv := anObject > > > They look like normal ivar accesses, but in the background, the compiler delegated to the Slot the code generation, calling emit*, which leads > to the bytecode e.g. for the read: > > 21 <20> pushConstant: iv => TestSlot > 22 <70> self > 23 <E1> send: read: > 24 <7C> returnTop > > you could override the emit* methods to generate faster code, but to get something running it is not needed. > > To test, e.g. you can set the slot from one object and read it from another: > > A new iv: 6 > A new iv > > Then inspect the slot: > > (A slotNamed: #iv) inspect > > (this should all Work in 4.0 048, the example is there as TestSlot for now) > > ...next steps: > > 1) Class Definition template for classes with Slots > 2) How do we save these classes in Monticello? > 3) Virtual Slots (Boolean and PropertySlots) > > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

June 28, 2014

Re: [Pharo-dev] How to get started with Git and Pharo?

by Dale Henrichs

Stef, Git is not perfect. Monticello is not perfect. Metacello is not perfect. GitHub is not perfect. Git and Github brings some things to the table that make Monticello and Metacello and collaborative development in Smalltalk better... Half of Metacello - the bit where you must "manually" record the version number for every .mcz file used - one of the most tedious parts - becomes unnecessary with git. With git a Metacello version references a specific commit, tag or branch. When we release a version of Seaside3 for GemStone, we just tag a repository and record the tag in the configuration of ... no need for "flattening" or meticulously recording of mcz file versions ... this simple fact by itself is almost enough to make the "complexity of git" worthwhile... Here's the complete version specification for Seaside3.1.1 in the ConfigurationOfSeaside3: spec for: #'gs3.x' do: [ spec baseline: 'Seaside3' with: [ spec repository: 'github://glassdb/Seaside31:3.1.1-gs31/repository' ] ]. That's it ... done... 95% of my git interactions are: git add ... git commit ... git push ... git pull ... This isn't that complicated to understand ... there are certainly times when it is necessary to use some of the more arcane commands, but frankly there are complicated operations in the Monticello/Metacello universe. How do you merge two Metacello versions? How do you merge changes to multiple mcz files? How do you fork/branch a large project like Seaside3 and still retain the ability to track changes from the master? I have done all of these things without git and it is not pretty .... not by a long shot...I wish we did have some arcane commands to help:) With git, all three of those operations are just part of eco-system... With github, I can merge a multiple mcz file contribution into my project ... WITH THE PUSH OF A BUTTON! GiHub arranges to run the tests using travis-ci, so before I dare push the button, I can be assured that all of the tests are passing. Before pushing the button, I can easily review all of the proposed changes and critique the proposed changes on a line by line basis and the contributor and I can engage in an online conversion ... on a line by line basis ... The contributor can make changes in her repository and they are reflected in the original pull request and the tests are automatically rerun... When the tests are green and I am satisfied with the review ... I press a button ... and the code is merged into my project and I can go back to work ... _This_ feature by itself is worth the price of admission for git ... It takes a bit of time to become comfortable with git, but if you are feeling any of pain that I have mentioned above, then it is worth taking the time to become comfortable with git ... If you are not feeling that pain, then I envy you:) and by all means ... do not learn git:) Dale On Sat, Jun 28, 2014 at 1:10 AM, stepharo <stepharo(a)free.fr> wrote: > I use git for my books. Now the simple fact that a tool has to help me to > do simple action is a sign > of strange design. This is the same as Java design and eclipse. When you > code without eclipse you will a real pain :) > I found the git API far to low level from my developer perspective and > this is what I would like the pharo abstraction to > protect our users (while getting the benefits from git). > And this is why when esteban is telling that this is what newbies expect I > cannot believe such kind of statements > because there are simply bullshit. :) > > Stef > > Stef, > > You need to cut your teeth for a decent couple hours to get to terms > with Git. > Especially when using a workflow with branches, with merges, and several > contributors. > I knew of quite a couple of SCMs (including Hg) but Git is a special beast. > > I liked Git Recipes: A Problem Solution Approach as it was very > pragmatic. > > HTH > Phil > > > On Thu, Jun 26, 2014 at 7:09 PM, stepharo <stepharo(a)free.fr> wrote: > >> I read >> >> >> http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git… >> and I found >> http://forum.world.st/Pharo-git-td4693999.html >> >> But is there something that works and it simple? >> >> Stef >> >> >> On 26/6/14 18:27, stepharo wrote: >> >>> Hi >>> >>> I do not know the dif between git file tree, file tree.... and I would >>> like to know how to get >>> started with git in Pharo? >>> >>> What should I read? >>> >>> Stef >>> >> >> >> > >

June 28, 2014