- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Helvetia... in Squeak
by Lukas Renggli May 13, 2011

May 13, 2011

Hi Frank, See my answers below inbetween your mail: > I've been playing around trying to get Helvetia working in Squeak. It's... > not going well. So I thought I'd try get it working in Pharo, so I could > play around with Helvetia - the point of the exercise - rather than futzing > with porting issues. I suggest that you download the one-click distribution from http://scg.unibe.ch/research/helvetia or the image from my build server (they should be identical). Loading the code manually doesn't work at the moment, because RB, OB, eCompletion and the other dependencies evolved in the meantime and are not compatible with Pharo 1.1.1 anymore. > Now I've tried loading Helvetia into a Pharo 1.1.1 image (old, I know, but > Helvetia says that it wants a 1.1 image), but things don't work too well - I > have issues like OBPluggableShoutTextMorph not understanding #setText:, > leaving me unable to open an omnibrowser. "Browser open" still works, but of > course senders-of and implementors-of are all smashed for the > afore-mentioned reason. Helvetia only works in Pharo 1.1.1 images with the dependencies that were available at that time. > Now I see you have Hudson build scripts for Helvetia, so clearly you've not > abandoned the project, so how do you do things? What base image do you use? > A Pharo 1.3? The builds are not running anymore. Helvetia is based on Pharo 1.1.1. I don't have the time to maintain the codebase. > If/when I get it working, would you be open to the idea of me working to > separate Helvetia's dependencies on things like Polymorph, OB, etc. so I can > use Helvetia in Squeak? Helvetia is all about integrating with tools, which means not only the compiler but also the editors, syntax highlighting, code completion, refactorings, etc. Moving Helvetia from Pharo 0.9 to Pharo 1.1 was a lot of work, because the loader needs to replace the compiler and introduce all kinds of subtle hooks into the running system. I doubt it is possible to get a working version of Helvetia in Squeak without a significant amount of work. After all, only outdated or forked versions of RB, OB, eCompletion, Shout, ... work in Squeak. Also --- and that would be probably the fist and most important step --- you would need to make PetitParser, RB, AST-Compiler, and QuasiQuote work in Squeak. These are the base compilation-related packages required by Helvetia. HTH, Lukas -- Lukas Renggli www.lukas-renggli.ch

3 5

Re: [Pharo-project] What we do with: "Embed source code for methods which get uninstalled from their classes" ???
by Marcus Denker May 13, 2011

May 13, 2011

On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote: > > 1) have a fast/normal recompileAll > 2) not to loose source code > > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this. > I think we should roll back the change for now... All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even on last year's cell phone 20 times larger than our complete system...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 7

[Pharo-project] 1.3-Core
by Alexandre Bergel May 13, 2011

May 13, 2011

Hi! I cannot open a remote repository apparently with the latest 1.3-core. Gofer and Monticello browser complain. I use: Pharo1.3a Latest update: #13196 I am behind a proxy, so I am not sure where the problem comes from (the image or the VM). It works well with 1.3-Oneclick however. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 13

[Pharo-project] [update 1.3] #13198
by Marcus Denker May 13, 2011

May 13, 2011

13198 ----- Issue 4213: New method in UITheme Issue 4212: RecentSubmissions updated Issue 4205: Separator is displayed even if its the last element in PluggableMenuSpec Issue 4174: Senders/implementors only get colors when clicked Issue 4150: DNU in FileList with CmdA Issue 4100: Set a backgroun picture from the settings doesnt work anymore Issue 4200: Build of Pharo Full does not terminate (workaround, issue stays open) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] What we do with: "Embed source code for methods which get uninstalled from their classes" ???
by Marcus Denker May 13, 2011

May 13, 2011

On May 13, 2011, at 3:13 PM, Mariano Martinez Peck wrote: > Ok. I will do it tonight. > I will do it now ;-) > Thanks > > On Fri, May 13, 2011 at 3:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Yes. Just remove sends of #dropSourcePointer. Everything else works fine. > > > On 13 May 2011 13:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Yes sync with igor > > > > Stef > > > > On May 13, 2011, at 10:47 AM, Mariano Martinez Peck wrote: > > > >> Me too. I would rollback until we have a better solution and very well tested. I think right now the consequences and worst than the original problem. > >> > >> On Fri, May 13, 2011 at 8:46 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> On May 13, 2011, at 12:24 AM, Mariano Martinez Peck wrote: > >> > > >> > 1) have a fast/normal recompileAll > >> > 2) not to loose source code > >> > > >> > If the only way right now is rollbacking #dropSourcePointer and rollbacking the implementation in objects as methods, please do it. Right now we are in the worst case. For example, today when I discover the bug of loosing sources...I commit my own package with a lots of methods with the decompiled source...it took time to fix it. So I think it is important to fix this. > >> > > >> I think we should roll back the change for now... > >> > >> All this shows that the source handling is *far* too complex... How would we realize source handling *today* considering today's resources? (aka: compression is free and memory even > >> on last year's cell phone 20 times larger than our complete system...) > >> > >> Marcus > >> > >> -- > >> Marcus Denker -- http://www.marcusdenker.de > >> INRIA Lille -- Nord Europe. Team RMoD. > >> > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Package validation?
by StÃ©phane Ducasse May 13, 2011

May 13, 2011

Hi guys did one of you wrote a small Package checker that would check: - that all the methods get a non nil category - methods belong to a package loaded? I experienced a lot of problem with RPackage when loading broken code and I would like to produce a little tool to validate packages so that we can identify problems and understand how to solve that in RPackage. Stef

2 4

[Pharo-project] update 13195/Remove Simple Morphic
by Torsten Bergmann May 13, 2011

May 13, 2011

Looks like #13195 removes Simple morphic. I havent seen a post on this update number here on the list, so why was it removed when it was introduced recently? Is it moved from core to dev image? Also note that empty SimpleMorphic-XXX" class categories are still there. Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 1

Re: [Pharo-project] Need help with 1.3 Full Image
by Marcus Denker May 13, 2011

May 13, 2011

On Fri, May 13, 2011 at 10:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > I'm really surprised. I'm also surprised that you say that when you did not > even tried to port your tools to 1.2 during the release candidate phase and that people > tried and failed and you started to port your tool when 1.2 was released. > As a result, we will just never do a beta/rc1/rc2/rc3 phase again. When 1.3 will be released, it will be what used to be beta. And everyone who just uses releases will be therefore tricked into using it :-) Marcus -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

2 1

Re: [Pharo-project] Need help with 1.3 Full Image
by Marcus Denker May 13, 2011

May 13, 2011

On May 13, 2011, at 9:38 AM, Lukas Renggli wrote: >> I personally think this really wants to tell us something, but that's just me. > > Yes, indeed. Thank you for fixing all the things in Pharo 1.2. This is > really important. > > I really don't understand why Pharo is pushing so hard towards Pharo > 1.3 while even Pharo 1.2.1 is not really stable for daily work yet. Keep in mind that 1.2.1 is unchanged. Fixes are added to 1.2.2a, and due to a change in 1.2 (that was *a bad idea*!!!), you need to set the version number to 1.2.2a to see any updates. The first update of 1.2.2a fixes this wrong change. We should release 1.2.2 just to get this problem fixed and update updates again. Another thing I would like is to not have one rolling release for stable. that is, there is 1.2 update 12XXX And nothing else, fixes get pushed, images build by Hudson, no releases on that level. > The number of really critical bugs that appear in Pharo 1.2 every day There is no bug reported in 1.2 that is not already in 1.1: http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.2.2 > makes me wonder how many people are just stuck with Pharo 1.1? :-( Maybe we need a dedicated stable team? From my financing, it would be hard to justify working purely on 1.2... I can work on 1.3, because we want to change the system to be something really great. But maintaining 1.2 is hard to justify as a researcher.... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] About Releasing 1.2.2
by Marcus Denker May 13, 2011

May 13, 2011

Hello, We should do a 1.2.2 release very soon. I suggest this weekend for Core, and then the Agony beginns again to find someone who is willing to fix Full... 1) One Thing to do in Core 1.2.2: - http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.2.2 Issue 3732: Change #standardWindowExtent Was: default omni browser size bigger The problem is that the RealEstateAgent is made for 1996 iMacs.. so it actually gives out very small windows up to a tiny maximum, leading for OB to open witha very, very very ugly small screen. Workaround Fix: hack to return a minum windows that is large enough (war to go, I guess) Real fix: rewrite RealEstateAgent to do something sensible for today's screens. (for later) 2) One Thing to do in Full 1.2.2: - http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2.2-DevImage Issue 4166: Failing Tests: OBFakeBrowserTest (ConfigurationOfOmniBrowser needs update) This means someone needs to update the MetaCello config to load the right versions of OB (which need to be copied to the pharo OB repo, too) Wo wants do do these? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1