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

Re: [Pharo-project] 1.3-Core

by Sven Van Caekenberghe

On 13 May 2011, at 15:24, Alexandre Bergel wrote: > I use a core 13197. Running Zinc tests gives me: > 146 run, 118 passes, 0 expected failures, 28 failures, 0 errors, 0 unexpected passes For all tests to pass, you need the very latest version (160) where the proxy is bypassed for localhost. Also, make sure no other ZnServers are running (they would block the 1701 port needed by the tests). Sven

May 13, 2011

Re: [Pharo-project] 1.3-Core

by Sven Van Caekenberghe

On 13 May 2011, at 15:25, Alexandre Bergel wrote: > Where am I supposed to find your Zinc-HTTP-SvenVanCaekenberghe.160 ? > In squeaksource.com/Pharo it not there and squeaksource.com/Zinc does not exist. Long answer: http://zn.stfx.eu Short answer: http://www.squeaksource.com/ZincHTTPComponents Sven

May 13, 2011

Re: [Pharo-project] 1.3-Core

by Alexandre Bergel

Where am I supposed to find your Zinc-HTTP-SvenVanCaekenberghe.160 ? In squeaksource.com/Pharo it not there and squeaksource.com/Zinc does not exist. Cheers, Alexandre On 13 May 2011, at 05:09, 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 13, 2011

Re: [Pharo-project] 1.3-Core

by Alexandre Bergel

Hi Sven, First of all, thanks for caring about the problem I encounter. > OK, here is a quick fix/patch: > > ZnRequestLine>>writeOn: stream > | writeStream | > writeStream := ZnBivalentWriteStream on: stream. > writeStream nextPutAll: self method; space. > ZnNetworkingUtils default isProxySet > ifTrue: [ self uri printOn: writeStream ] > ifFalse: [ self uri printPathQueryFragmentOn: writeStream ]. > writeStream space; nextPutAll: self version; nextPutAll: String crlf #default is not defined on 'ZnNetworkingUtils class'. I removed the call to #default, and it works. Printing the expression gave me a ZnResponse(200 OK text/html;charset=utf-8 113B) which looks good > 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. Yes it works. > 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. I use a core 13197. Running Zinc tests gives me: 146 run, 118 passes, 0 expected failures, 28 failures, 0 errors, 0 unexpected passes Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 13, 2011

[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