- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About configurationOfPharoRB

by Dale Henrichs

Stef, I think I will have to make a new release defining attributes for Pharo 1.4... This is related to Metacello Issue 146[1]. Pharo1.4 would be a good place to introduce a method to define the Metacello attributes for the platform ... I think if you arrange to hang a method off of SmallImage (?) called defaultMetacelloPlatformAttributes that returned the following collection: ^#(#squeakCommon #pharo #'pharo1.x' #'pharo1.4.x') Then I could make a quick release of Metacello 1.0-beta.1.30.1 that would use that method and you'd be in business... Dale [1] http://code.google.com/p/metacello/issues/detail?id=146 ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, August 7, 2011 1:30:14 PM | Subject: Re: [Pharo-project] About configurationOfPharoRB | | Dale | | I added | | stable: spec | <symbolicVersion: #stable> | | spec for: #'pharo1.0.x' version: '1.2.1'. | spec for: #'pharo1.1.x' version: '1.5'. | spec for: #'pharo1.2.x' version: '1.7'. | spec for: #'pharo1.3.x' version: '1.7'. | spec for: #'pharo1.4.x' version: '1.8'. | spec for: #'squeak4.x' version: '1.6'. | | and a new baseline and version but when I do | | | (ConfigurationOfRefactoringBrowser project version: #'stable') load | | I get an error. | | Do you have an idea? | | Stef | | | | version18: spec | <version: '1.8' imports: #('1.8-baseline' )> | | spec for: #'common' do: [ | spec blessing: #'release'. | spec description: 'RefactoringBrowser for pharo 1.4 alpha. For this | version we just move the place to look for Refactoring-Changes. | Now there is a project for RB for pharo: It is called PharoRB'. | spec author: 'StephaneDucasse'. | spec timestamp: '2011-08-07T21:54:25+00:00'. "DateAndTime now | asString" | ]. | | spec for: #'pharo' do: [ | spec | | package: 'AST-Core' with: 'AST-Core-lr.87'; | package: 'AST-Tests-Core' with: 'AST-Tests-Core-lr.11'; | | package: 'AST-Semantic' with: 'AST-Semantic-lr.15'; | package: 'AST-Tests-Semantic' with: 'AST-Tests-Semantic-lr.3'; | | package: 'Refactoring-Environment' with: | 'Refactoring-Environment-lr.7'; | package: 'Refactoring-Tests-Environment' with: | 'Refactoring-Tests-Environment-lr.1'; | | package: 'Refactoring-Changes' with: | 'Refactoring-Changes-GuillermoPolito.17'; | package: 'Refactoring-Tests-Changes' with: | 'Refactoring-Tests-Changes-lr.14'; | | package: 'Refactoring-Core' with: 'Refactoring-Core-lr.153'; | package: 'Refactoring-Tests-Core' with: | 'Refactoring-Tests-Core-lr.51'; | | package: 'Refactoring-Critics' with: 'Refactoring-Critics-lr.9'; | package: 'Refactoring-Tests-Critics' with: | 'Refactoring-Tests-Critics-lr.3'; | | package: 'Refactoring-Spelling' with: | 'Refactoring-Spelling-pmm.25'; | package: 'Refactoring-Tests-Spelling' with: | 'Refactoring-Tests-Spelling-lr.6'. | | ]. | | spec for: #'squeak' do: [ | spec description: 'Squeak support based on Squeak4.2-Trunk-10628'. | spec | package: 'AST-Core' with: 'AST-Core-lr.85'; | package: 'AST-Semantic' with: 'AST-Semantic-lr.15'; | package: 'Refactoring-Core' with: 'Refactoring-Core-lr.153'; | package: 'Refactoring-Environment' with: | 'Refactoring-Environment-lr.4'; | package: 'Refactoring-Critics' with: 'Refactoring-Critics-lr.4'; | package: 'Refactoring-Spelling' with: | 'Refactoring-Spelling-lr.23'; | package: 'Refactoring-Changes' with: 'Refactoring-Changes-lr.16']. | spec for: #'gemstone' do: [ | spec author: 'DaleHenrichs'. | spec project: 'GsCore' with: '0.241'. | spec | package: 'AST-Core' with: 'AST-Core-DaleHenrichs.84'; | package: 'AST-Tests-Core' with: | 'AST-Tests-Core-DaleHenrichs.11'.]. |

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by StÃ©phane Ducasse

On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: > 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi >> >> I would like that we do an analysis of what should stay in implementors >> >> Here are the menus in 1.2 and 1.4 >> > > Note that the menu titles are misleading. > In previous implementation, 'Implementors of...(m)' did mean > implementor of this message or any message called by this method. I did not pay attention to that because I always type the code but I see now. > In current implementation, 'Implementors of...(m)' does mean > implementor of this message and only this message. > Same for 'senders of ...(n)'. > > That's the main grief I got because this break the browsing chain. > If I want to see implementors/senders of a sub message, then I have to: > - select the message in text field, then click cmd+m or cmd+n this is what I do :) > - if the message is multiple keyword, then this won't work... We should fix that for any place in the system foo: #yyy to: does not find foo:to: :( > I have to open a finder, copy some text, paste in the finder then > click one of the matching methods... > That's many more clicks than previous implementation. Ok we will fix that. > > To define a "good" UI you must not only think in term of available > feature, other views matter: > - homogeneity of presentation / action > - number of clicks for accessing a feature > - auto-discovery of features rather than implicit knowledge Yes. >> Please comment so that we can add what is really used. >> As a general comment I would avoid to do everything with a single tool. >> > > Err. I think the contrary. > Every such view is a browser with a specific filter on displayed code. > The first function of a browser is browsing. > Removing browsing capabilities from these views make em become dead > ends (look and close). > To restore the navigation chain, user must pass thru textual copy/paste. > Ubiquitous browsing is a strength of Smalltalk IDE, no? Yes but do we need spawn subprotocol? and friends. All instances... So let us focus on the most 40% most important features and add them to the browsers. So there should be a reasonable amount of used functionality. So let us know what you use most of the time or less and this will be good. Stef

Aug. 9, 2011

[Pharo-project] [update 1.4] #14079

by StÃ©phane Ducasse

14079 ----- - Issue 4550: methodSymbol is a bad name for selector. Couple more fixes - Fix methodClass of RGMethodDefinition Stef

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Nicolas Cellier

2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > I would like that we do an analysis of what should stay in implementors > > Here are the menus in 1.2 and 1.4 > Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'. That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n - if the message is multiple keyword, then this won't work... I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation. To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge > Please comment so that we can add what is really used. > As a general comment I would avoid to do everything with a single tool. > Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no? > Stef > > >

Aug. 9, 2011

Re: [Pharo-project] PharoCore 1.3: Implementors browser broken

by Lukas Renggli

Created: http://code.google.com/p/pharo/issues/detail?id=4611 On 8 August 2011 22:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks > >> I just noticed that the implementors browser in Pharo Core 1.3 does >> not show any kind of warning if a variable is not declared. > > I know that I fixed a bug in 1.4 when executing a comment. > >> Also parse errors result in the fatal SyntaxError window. > > Yes I want kill that one too. Marcus told me that he has fun with petitparser and made a lot of progress for the decompiler. > So opal is getting closer and closer... I should continue to work on Rpackage argh. > >> >> I thought I report it here before I forget it again, because the bug >> tracker is in read-only mode right now. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 9, 2011

Re: [Pharo-project] Shout in Pharo 1.3

by Lukas Renggli

Done: http://code.google.com/p/pharo/issues/detail?id=4609 On 9 August 2011 13:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would like to know too. > Alain is on holiday else he could tell us. > Can you open a ticket and put alain on cc? > > Stef > > >> Does anybody has a version of Shout that correctly works in the >> traditional tools in Pharo 1.3? >> >> I tried various versions of Shout, but could not find one that worked >> correctly in the traditional tools. The problem I see is that Shout is >> not properly setup/updated anymore, i.e. it does not callback to the >> model (#shoutAboutToStyle:). When the browser/debugger changes the >> method/definition/comment highlighting is not enabled/disabled and the >> context is not changed. >> >> Does anybody have a working version of Shout and/or knows how to >> easily make it work? >> >> It works in OB because I subclassed 3 editor classes and undone the >> "new" way of how highlighting works. I thought I bring this up again, >> because as far as I see there is still the same problem ... >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 9, 2011

[Pharo-project] News about NativeBoost

by Igor Stasenko

Hello, Major news: NativeBoost now working on Macs! The main problem with Mac OS platform was that it requires a stack alignment discipline, while other platforms don't. So, i had to extend the assembler to make sure that all external calls will be made with properly aligned stack. Also, i spent time to improve error handling. Since in Cog/Stack VMs we having nice primitive error code, now it can report what caused a failure in more detail, than just failing a primitive and leaving a language side to guess what gone wrong. There's a lot of other small changes, like new tests, more examples etc.. But i don't want to describe them all (and frankly i don't remember all of them ;) Things not yet working: The callbacks to language side is not functional (i have to revise this code to synchronize it with callback machinery in Cog VMs). The callbacks to native code working well (of course, because it don't needs to deal with VM-specific stuff ;) The prebuilt VMs, which contain a NativeBoost plugin are now on Jenkins server. These VMs will be built automatically each time there is code update for Cog VMs (in same way as all continuous integration jobs). The only difference between original Cog VMs and Cog+NativeBoost VMs is that they contain NativeBoost plugin. So, you can use these VMs instead of Cog VMs if you like. You can download VMs from here: https://ci.lille.inria.fr/pharo/view/NativeBoost/ To install NativeBoost into your image follow instructions on: http://code.google.com/p/nativeboost/wiki/Installation -- Best regards, Igor Stasenko AKA sig.

Aug. 9, 2011

[Pharo-project] [Cog] New builds available on Jenkins server

by Igor Stasenko

Hello, during last couple of weeks i was busy migrating migrating VM jobs from Hudson server to more up to date Jenkins server and creating a jobs for running tests on newly built VMs. The new location for built VMs are https://ci.lille.inria.fr/pharo/view/Cog/ I disabled the old jobs on Hudson server (https://pharo-ic.lille.inria.fr/hudson/view/Cog/) and also put a comment where they moved. So, from now all VMs which are built on Jenkins server will be automatically tested. If you go to jenkins page, you could see that each job , like StackVM-Unix has a parallel job named StackVM-Unix Tests , which runs tests after successful build of corresponding VM. The image which is used to run tests is Pharo 1.4. latest build (can be found on same server - https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/) So, in this way we have a streamlined continuous integration setup, which tests every possible combination(s) of VMs and latest Pharo image, so we can easily track regressions as well as different behavior between platforms (ideally, there should be none ;)) Details about new builds: - it is a merge with VMMaker.oscog-eem.115 which contains an important fix for #become: primitive With this fix, i could say that Cog VMs are much stable! Problems, not yet solved: Windows: - there is no windows jobs yet, because we're still having problems with windows slave (it is inaccessible right now), but once it will work, i will add jobs for windows as well. Mac Cocoa builds: - i migrated the cocoa builds to jenkins server as well, but it is not yet using an updated verison of sources (we have to wait till Esteban will sync sources) - also those VMs cannot run tests because command-line interface for them is severely broken now :( -- Best regards, Igor Stasenko AKA sig.

Aug. 9, 2011

[Pharo-project] What are the useful operations of implementors/senders that you use

by StÃ©phane Ducasse

Hi I would like that we do an analysis of what should stay in implementors Here are the menus in 1.2 and 1.4 Please comment so that we can add what is really used. As a general comment I would avoid to do everything with a single tool. Stef

Aug. 9, 2011

Re: [Pharo-project] GUI failing apart

by StÃ©phane Ducasse

>> >> > > Oh, If your goal is to remain popular, then indeeed, you should keep > away from changing such parts of the system which are not shining ;). > The obvious reason is that multilayer hacks with obfuscated contracts > are not maintanable... > so it's inevitable to create bugs in the transition and harvest complaints... > > Of course, if your goal is to make the system more simple and > maintanable, I'm with you (and I know it is). Yes and this is excellent :) > But don't forget to extract the positive part of complaints that will > help you making the system better. > > Personnally, the finite state machine logic in Squeak/MouseOverHandler > is well beyond my understanding. :) me too but we will learn it. I started to read the code of the event handler last year and regularly I take notes and slowly I understand better. > So I could not clean it easily myself, > > A cosmetic cleaning was attempted in Pharo.I have nothing against that. > I just pointed a problem in current cleaning, so it just have to be finished. > The stincky ivar mutation already was in Squeak. > I just said that it should raise an alarm in coder's eyes in the > future and I hope this helps. Yes of course. My remark was not on that part of your message :) So can you open a bug entry so that we do not forget to change it. > Otherwise I can also shut up. > > The second approach suggested by Igor is more involving, consist in a > full rewrite, probably with these stages: > - gather description of the features to be supported, > - an inventory of third party interested in this kind of features, > - and from there, decline a new definition of contracts. Yes we will attack from all angles and slowly but steadily do it. For example, there is in a image a check to reduce event but this is not clear that the VM generate them. so we will check that first. > >>> But please, don't do it blindly and loose 2 third of features like the >>> new implementors window :( >> >> We are not doing things blindly: >> >> First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI >> without a decent widgets set (because he fixed them also the multiselection and others). >> Benjamin I publicly thank you for all the good stuff you did!!!! >> >> >> Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap >> Please hightlight me. >> >> Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life >> a system full of shit. Shit that was accumulated and of course stable because it did not move since years. >> In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) >> better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system >> in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them. >> >> Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because >> Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets >> is not easy, nor it is to work on bootstrapping Pharo. >> >> Stef >> >> > > Sure, I don't want to restrain goodwill. > But as a user of the service I don't see all the sweat the hardworkers > put into the system, > I just see a regression that makes my life harder (I simply cannot > track the messages with the new windows). Explain us. Because we want the tools to be excellent. > And obviously, comparing the length of old menu with new one, two > third does not seem exagerated to me. > But maybe you don't work with those tools and install OB/RB after each update... > No I always use the core image with no tool loaded. What was on the menu? What is useful? I never use the menus? > Nicolas > >>> >>> Nicolas >>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >> >> >> >

Aug. 9, 2011