- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13198

by Marcus Denker

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.

May 13, 2011

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

by Marcus Denker

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.

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

Ok. I will do it tonight. 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

May 13, 2011

Re: [Pharo-project] 1.3-Core

by Alexandre Bergel

>>> Can you try a simple thing like: >>> >>> ZnClient get: 'http://zn.stfx.eu/zn/small.html' >> >> It returns: >> a ZnResponse(400 Bad Request text/html 3181B) > > Can you send me the #contents of that ? It should be a 3Kb HTML doc that hopefully explains why your proxy server thinks the request is not OK. It is '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>ERROR: The requested URL could not be retrieved</title> <style type="text/css"></style> </head><body> <div id="titles"> <h1>ERROR</h1> <h2>The requested URL could not be retrieved</h2> </div> <hr> <div id="content"> <p>The following error was encountered while trying to retrieve the URL: <a href="/zn/small.html">/zn/small.html</a></p> <blockquote id="error"> <p><b>Invalid URL</b></p> </blockquote> <p>Some aspect of the requested URL is incorrect.</p> <p>Some possible problems are:</p> <ul> <li><p>Missing or incorrect access protocol (should be <q>http://</q> or similar)</p></li> <li><p>Missing hostname</p></li> <li><p>Illegal double-escape in the URL-Path</p></li> <li><p>Illegal character in hostname; underscores are not allowed.</p></li> </ul> <p>Your cache administrator is <a href="mailto:root?subject=CacheErrorInfo%20-%20ERR_INVALID_URL&body=CacheHost%3A%20taltal.dcc.uchile.cl%0D%0AErrPage%3A%20ERR_INVALID_URL%0D%0AErr%3A%20%5Bnone%5D%0D%0ATimeStamp%3A%20Fri,%2013%20May%202011%2013%3A10%3A43%20GMT%0D%0A%0D%0AClientIP%3A%2010.0.115.120%0D%0A%0D%0AHTTP%20Request%3A%0D%0A%0D%0A%0D%0A">root</a>.</p> <br> </div> <hr> <div id="footer"> <p>Generated Fri, 13 May 2011 13:10:43 GMT by taltal.dcc.uchile.cl (squid/3.1.8)</p>  </div> </body></html> ' >>> Have a look at ZnNetworkingUtils class>>#socketStreamToUrl: >>> Does this make the right decision in your setup ? >> >> Yes it does. ZnNetworkingUtils isProxySet => true > > What are your proxy settings ? Just a hostname and a port ? Easy, just a hostname (proxy.dcc.uchile.cl) with a port (8000) But actually, it would equally work without the proxy. I can connect to internet without the proxy. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 13, 2011

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

by Igor Stasenko

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.

May 13, 2011

Re: [Pharo-project] Smalltalk and LibreOffice or OpenOffice

by Jan van de Sandt

The VA Smalltalk bindings were developed by Marten Feldtmann [1] and the code is available at VAStGoodies.com [2] Jan. [1] http://schrievkrom.wordpress.com [2] http://vastgoodies.com/maps/MSKOOoExamplesAndIDE On Fri, May 13, 2011 at 2:38 PM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > > 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

[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