May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Smalltalk and LibreOffice or OpenOffice

by Friedrich Dominicus

Just wondering if anyone has used Smalltalk for "scripting" this office Suite. The only I could find about it was VASmalltalk bindings dated back to 2008.... Regards Friedrich

May 13, 2011

Re: [Pharo-project] Package validation?

by StÃ©phane Ducasse

Ideally I would love to remove class categories and only have packages. Stef > One more thought about RPackage. I think one of the things that everybody confuse, even myself are packages vs categories. > And it is not only us, but the system it self. > > There is a package called Tools. > So..why PACKAGEInfo let me do this: (PackageInfo named: 'Tools-Base') classes > that should be an error. 'Tools-Base' is NOT a package, it is a category. In RPackage you will not have that problem. > > I don't know how RPackage deals with it, but I just mention... > > cheers > > Mariano

May 13, 2011

Re: [Pharo-project] update 13195/Remove Simple Morphic

by StÃ©phane Ducasse

It was removed because fernando told us that this is an old version. He is working to make sure that we can get the latest CUIS version in Pharo. In parallel and to help him we are working on removing Toolbuilder and the old StringHolder hierarchy. BTW anybody is welcomed to help Stef > 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 >

May 13, 2011

Re: [Pharo-project] 1.3-Core

by StÃ©phane Ducasse

tx I will merge it in core once this is ok :) Stef On May 13, 2011, at 11:09 AM, Sven Van Caekenberghe wrote: > > On 13 May 2011, at 10:24, Sven Van Caekenberghe wrote: > >> The problem was that for an HTTP request through a proxy, the url in the request line must be absolute. >> >> Let me know if this works for you. >> >> There is another problem as well: access to, at least localhost, should not go through the proxy. >> I am fixing that right now. >> I want you to be able to run all Zn unit tests with a proxy set, but half of them are accessing localhost. >> Anyway, the full fixes will be committed to the Zn repos first, and will have to be migrated to Pharo next. > > Here is the official fix, all Zn units tests should now be green, please confirm. > > ==================== Summary ==================== > > Name: Zinc-HTTP-SvenVanCaekenberghe.160 > Author: SvenVanCaekenberghe > Time: 13 May 2011, 11:07:48 am > UUID: 619a8697-4d71-4c1c-a99e-fe5e07f3dbb4 > Ancestors: Zinc-HTTP-NickAger.159 > > fixing support for HTTP proxies (thanks Alexandre Bergel for reporting this) > requests to localhost are excluded from being proxied > - ZnRequestLine>>#writeOn: now outputs absolute URLs when proxying > - added ZnNetWorkingUtils class #isProxySet #shouldProxyUrl: and #httpProxy > - added ZnUrl>>#isLocalHost > - changed ZnUrl>>#host: to lowerCase its argument >

May 13, 2011

Re: [Pharo-project] What we do with: "Embed source code for methods which get uninstalled from their classes" ???

by StÃ©phane Ducasse

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 >

May 13, 2011

Re: [Pharo-project] Package validation?

by Mariano Martinez Peck

One more thought about RPackage. I think one of the things that everybody confuse, even myself are packages vs categories. And it is not only us, but the system it self. There is a package called Tools. So..why PACKAGEInfo let me do this: (PackageInfo named: 'Tools-Base') classes that should be an error. 'Tools-Base' is NOT a package, it is a category. I don't know how RPackage deals with it, but I just mention... cheers Mariano On Sun, May 8, 2011 at 6:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On May 8, 2011, at 6:09 PM, Mariano Martinez Peck wrote: > > > Stef, off-topic question.... When I rename a package from the > SystemBrowser, the extension methods' categories are not updated. This is a > known problem. I don't know where the rename happens if it is UI or > model....but in case it is the model (PackageInfo or RPackage) I would love > to have that fixed in RPackage. > > Yes it will because this is a pain. > Probably we should solve it also in MC. May be this is fixed in Squeak. Did > you check? > I should go over the MC change made by chris but I should find time to do > it. > > Stef > > > > cheers > > > > Mariano > > > > On Sun, May 8, 2011 at 5:48 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > 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 > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

May 13, 2011

[Pharo-project] update 13195/Remove Simple Morphic

by Torsten Bergmann

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

May 13, 2011

Re: [Pharo-project] 1.3-Core

by Sven Van Caekenberghe

On 13 May 2011, at 10:24, Sven Van Caekenberghe wrote: > The problem was that for an HTTP request through a proxy, the url in the request line must be absolute. > > Let me know if this works for you. > > There is another problem as well: access to, at least localhost, should not go through the proxy. > I am fixing that right now. > I want you to be able to run all Zn unit tests with a proxy set, but half of them are accessing localhost. > Anyway, the full fixes will be committed to the Zn repos first, and will have to be migrated to Pharo next. Here is the official fix, all Zn units tests should now be green, please confirm. ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.160 Author: SvenVanCaekenberghe Time: 13 May 2011, 11:07:48 am UUID: 619a8697-4d71-4c1c-a99e-fe5e07f3dbb4 Ancestors: Zinc-HTTP-NickAger.159 fixing support for HTTP proxies (thanks Alexandre Bergel for reporting this) requests to localhost are excluded from being proxied - ZnRequestLine>>#writeOn: now outputs absolute URLs when proxying - added ZnNetWorkingUtils class #isProxySet #shouldProxyUrl: and #httpProxy - added ZnUrl>>#isLocalHost - changed ZnUrl>>#host: to lowerCase its argument

May 13, 2011

Re: [Pharo-project] What we do with: "Embed source code for methods which get uninstalled from their classes" ???

by Mariano Martinez Peck

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

May 13, 2011

Re: [Pharo-project] Need help with 1.3 Full Image

by StÃ©phane Ducasse

;) Stef On May 13, 2011, at 10:35 AM, Marcus Denker wrote: > 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 >

May 13, 2011