- Pharo-dev - lists.pharo.org

[Pharo-project] odd gotcha in workspace code for squeak and pharo
by Lawson English March 3, 2012

March 3, 2012

A discussion in IRC prompted me to try several things. In a nutshell, execute these two lines with two separate doits and you get an error. Select both lines and doit and you don't: a := [^true]. a value. I assume there is a valid reason for the difference in behavior, but it DOES remind one that workspace behavior isn't always the same as method behavior, even for something as simple as the above. L.

1 0

Re: [Pharo-project] Sender of or: Boolean method
by Fernando Olivero March 3, 2012

March 3, 2012

Ciao Dario, i dont understand the question. You are stating that there's an error , because you know for sure that #or: has more then 10 senders in the Pharo1.0? Fernando pd: By the way, i advice to use a later version of Pharo, manyyy things were improved since then! On Sat, Mar 3, 2012 at 1:02 PM, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > Â Â Â Â i work with: > > Â Â Â Â Â Â Â Â Pharo-1.0 > Â Â Â Â Â Â Â Â Latest update: #10517. > > Â Â Â Â ( but i found the same answer into > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Pharo1.2.2 > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Latest update: #12353 Â ) > > > > I have a browser open on Boolean class. > > > When i select the Â Â Â Â Â Â Â Â or: Â Â Â Â Â Â method Â and click on Â the Â Â Â sender button Â the system answer only Â ten Â methods. > > > Because ? > > > Thank, > > Â Â Â Â Â Â Â Â Dario

2 1

[Pharo-project] Sender of or: Boolean method
by Dario Trussardi March 3, 2012

March 3, 2012

Ciao, i work with: Pharo-1.0 Latest update: #10517. ( but i found the same answer into Pharo1.2.2 Latest update: #12353 ) I have a browser open on Boolean class. When i select the or: method and click on the sender button the system answer only ten methods. Because ? Thank, Dario

2 1

Re: [Pharo-project] Sender of or: Boolean method
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 3, 2012, at 1:02 PM, Dario Trussardi wrote: > Ciao, > > i work with: > > Pharo-1.0 > Latest update: #10517. > > ( but i found the same answer into > Pharo1.2.2 > Latest update: #12353 ) > > > > I have a browser open on Boolean class. > > > When i select the or: method and click on the sender button the system answer only ten methods. > > > Because ? > It is compiled to jumps, the message send is optimized away. e.g "true or: [false]" is compiled to: 17 <71> pushConstant: true 18 <99> jumpFalse: 21 19 <71> pushConstant: true 20 <90> jumpTo: 22 21 <72> pushConstant: false 22 <7C> returnTop This means that then in the compiledmethod, there is no symbol needed for or: to execute the code. It is omited for space reasons (keep in mind that the original target machine of this system had 512 Kb of RAM maximum) The "senders of" iterates over all methods and looks if a symbol is there, it does not look at source code. (that's why it is so fast and works even without sources...) These days where a $25 computer is shipped witth 256MB of RAM, of course adding in 1000 methods pointers to a symbol is not that of a problem, and therefore, in 1.4, the selector of optimized-away messages is now added to the literalframe (if there is space), even though it's pure waste from the execution point of view. So now, senders of #or: gives you 1092 methods. Same for ifTrue: and all the other inlined methods. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [TODO] things tagged 1.4
by Marcus Denker March 3, 2012

March 3, 2012

Hi, Even though peope hate it, I think we just can't affort to not priorityze what we need to do... So I, evil as I am, started to remove 1.4 tags to get a feeling for what we really really need to fix and integrate... I should repeat that this un-tagging is not meant to judge on the submitter of the report, it does not mean that the issue should not be worked on at all, it just means that nobody needs to stay awake all night to fix it before we release 1.4... http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.4+&colspec… 43 issues, 30 of those open, 13 already to be integrated. It does not mean that the list is complete, nor correct, nor that we really will fix all the issues for 1.4. It meant as a tool for you and me to have a manageble list of things that need attention. I personally need this, others do not. Those are invited to look at the complete list of reports: http://code.google.com/p/pharo/issues/list?can=2&q=&colspec=ID+Type+Status+… Here 446 Issues are listed *ALL* of them important to be fixed. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 3, 2012, at 12:03 PM, Tudor Girba wrote: > Hi, > > I did not manage to explain myself, so let me try again with a longer email. > > We all want to get to a small kernel. To get there, we should have a process that makes the progress possible in small increments. At this point, I would just be interested in putting in place a simple job that takes a seed image, and builds the image in which the core team works in. > > As far as I understood, the only reason why we now have a single image is that the old Core image had poor tools, and building the Distribution was long. However, now, you do not have RB in there anymore. Removing RB was the right decision, because it means it can evolve rather independently. This also means that to do your work you would benefit from another image. > > So, the simplest thing at this point, would be to start with just making the current image to be the seed and build another one with RB (and maybe Nautilus?) inside where you do your work. And then we try to see how it goes in terms your process. If it works Ok, we can start pulling out other packages. > > For example, currently, there are at least two other parts that are not required to be in the seed image: AST and Filesystem. Of course, when OPAL will arrive, the AST will have to go in the seed image, but until then, it does not have to. The same with Filesystem: at this moment, it does not have to be in. > > One thing that we need to watch for though is the process of including something in the Distribution. The old Dev image failed because the policy was one of "it looks interesting -> it should be in". Instead, the Distribution should be focused on providing a small set of extras that make development better. > > In the end, the goal is not to come up with the kernel now, but it would be to have the infrastructure and process in place that enables us to remove things from the seed image gradually, and still get the core team to have a good toolset. > > Would that be Ok? > What we need: -> One Artefact of release. *This is Pharo* (and yes, there is a small core somewhere, but that's for specialists) - The goal in that is to have everything just once. Not a "crapy X for the Core, but everyone uses Y". - No need to manage bugs for Full and Core differently - Stable. No "Dev now is different and I don't know why, nobody changed anything" (as happend with 1.3, again...) (stable in the sense: two builds of the same version should not magically be different) -> The development happens in that one release. Developers and integrators can just use that. No thinking. -> The way to commit is the same. What killed me in the Dev image approach is that it was different and difficult *in addtion* to a difficult and boring aproach for the core. (e.g. editing Metacello config by hand for every trivial change.. and breaking something every time). -> I can press "update system to latest" to update the image, no need to always download a fresh image for every trivial change. -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

> > > For example, currently, there are at least two other parts that are not required to be in the seed image: AST and Filesystem. FileSystem is needed. It replaced the old Filesystem in some places already. e.g. in FileList. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 3, 2012, at 9:27 AM, StÃ©phane Ducasse wrote: > > On Mar 2, 2012, at 11:11 PM, Marcus Denker wrote: > >> >> On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: >>> >>> Ok. So I downloaded the first Pharo Core 1.4: >>> https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip >>> >>> but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? >> >> >> It's not possible to turn 1.4000 into the current one by loading packages in one step. >> because there are lots of objects that need to be migrated... it's a living system. >> >> There was *a lot* of manual fiddling involved, even just from one step to the next. > > but can we try and see :) > If you have a PhD student... it's a nice topic. If just making updates faster is the goal, we should think about doing the update on a server and recording the changes applied. The can load just those, with the Doits needed at the right spot... Marcus -- Marcus Denker -- http://marcusdenker.de

2 2

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 2, 2012, at 9:21 PM, Tudor Girba wrote: > > Ok. So I downloaded the first Pharo Core 1.4: > https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip > > but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? It's not possible to turn 1.4000 into the current one by loading packages in one step. because there are lots of objects that need to be migrated... it's a living system. There was *a lot* of manual fiddling involved, even just from one step to the next. Marcus -- Marcus Denker -- http://marcusdenker.de

4 5

[Pharo-project] pharo-seed and pharo
by Tudor Girba March 3, 2012

March 3, 2012

Hi, I believe everyone agrees that one important goal in Pharo is to get to a small code/kernel/seed. During the Pharo Sprint at Bern we saw that the only reason for now having a unified image is just a temporary convenience that stems from two things: 1. Until Pharo 1.3, the core team worked in the core image, and this was frustrating because they were missing proper tools 2. After 1.3, building a pharo image out of a seed image was perceived as being too long and not fitting for the process of integration It's clear that the core team needs development tools. However, we think that 2 can be actually quite cheap if the build starts from the latest seed, and not from the original seed of 1.4 as it currently seem to happen. If this would be fast, we could go back to having one seed image (I call it seed just to avoid confusion and wrong feelings, but you can call it anyway you want) out of which the Pharo distribution (like the current image is) is built. The core team would work on this distribution, and Jenkins would do the rest. By switching the distribution build to work with the latest seed, we can probably reduce the amount of build time to a couple of minutes (at least this is what we saw during a couple of quick tests). Regarding the flow of the integrator, we saw that actually, when multiple changes need to be integrated, you can base the second change on the image that already exists locally, without needing to wait until Jenkins finishes. I would be interested in providing help. So, what do you say? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

6 7