- Pharo-dev - lists.pharo.org

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

by Mariano Martinez Peck

So....we used to have arround CM instances wrong. There was a problem with the trailer and we fix it. http://code.google.com/p/pharo/issues/detail?id=4186 Then we did: http://code.google.com/p/pharo/issues/detail?id=4192 and, dev image took hous to finish: http://code.google.com/p/pharo/issues/detail?id=4200 because the Compiler recompileAll take ages because of the becomeFordward: it does for the #dropSourcePointer then igor solve it, it took less time, but we start to loose the source pointer of COmpiledMethods while loading stuff from MC. in addition, objects as methods started to fail because they do not implement #dropSourcePointer: http://code.google.com/p/pharo/issues/detail?id=4195 so...al users of #run:with:in: should also be broken now, like TestCoverage, etc.... so...what do we do? I would like to: 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. Cheers -- Mariano http://marianopeck.wordpress.com

May 13, 2011

Re: [Pharo-project] Small question in OSProcess

by David T. Lewis

On Tue, May 10, 2011 at 04:02:02PM +0200, Adrien BARREAU wrote: > > Hi all, > > I just have a little question: > Is there a way to change the working directory of my terminal with something in OSProcess? > > I mean: > - I know I can change the working directory of the current process with "OSProcess thisOSProcess chDir: '/'" but of course it does nothing on the terminal > - "OSProcess thisOSProcess command: 'cd /'" does absolutly nothing > > I hope it's clean enough. > > Regards, > Adrien. > The Unix or Windows concept of "current working directory" does not really have any meaning in Squeak/Pharo itself. In Unix, which maintains a single tree structured view of the file system(s), you may think of it as associated with the shell that you are running. In Windows it is similar but needs to accommodate the idea of separate volumes (C:, D:, etc). The CommandShell package is a companion to OSProcess that implements a simulation of Unix and Windows shell behaviour. Try loading CommandShell in addition to OSProcess and I think that you will find what you are looking for. If your question refers to a Unix (Linux, OS X, etc) platform, and you are trying to do is change the current working directory for the terminal from which you started your Pharo image, then it's a different issue. This is basic Unix behavior - the program you are running (the VM) is a child process of the program that started it (the shell in your terminal window). A child process does not have access to its parent process to do things like change its working directory. So when you are doing things such as setting environment variables and so forth, it affects the process that you are current in (the VM process), and has no effect on the parent (the shell in your terminal window). HTH, Dave

May 12, 2011

Re: [Pharo-project] 1.3-Core

by Sven Van Caekenberghe

On 12 May 2011, at 22:50, Alexandre Bergel wrote: >> This probably has something to do with Zn now being used for HTTP, proxies should be supported, but I have not tested them myself. > >> >> 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. >> 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 ?

May 12, 2011

Re: [Pharo-project] [ANN] VB-Regex patch available

by Nicolas Cellier

2011/5/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks nicolas > I will integrate it now. > > >> Reinout Heek recently published a patch in cincom store for some Regex >> pending bugs after a recent mail on vwnc list. >> I ported this 3-methods patch on Squeak based on latest >> http://www.squeaksource.com/Regex.htm >> I have no commit right, so I posted two copies: >> >> http://source.squeak.org/inbox/VB-Regex-nice.18.mcz >> http://www.squeaksource.com/PharoInbox/VB-Regex-nice.18.mcz >> >> Note that core Pharo version of Regex is some versions ahead and the >> patch requires further porting. > > What do you mean by further porting Reinout patch is just 3 methods. But the merger pretends they are in conflict with VB-Regex-StephaneDucasse.49 And the merger is not of any help with VB-Regex-StephaneDucasse.50 because of Repackaging. Repackaging without tool support is like hell :( This is an easy 3-methods patch, but imagine you have to merge a 100 methods patch with just change sets... Argh Nicolas >> >> Nicolas >> >> >> ------------------------------------------------------------------------- >> Port fixes from Reinout Heek from VW.Regex11 >> >> Regex11(1.3.1-soops1) - introduces fix >> Regex11(1.3.3) - merge above with 1.3.2 >> >> Blessing comment: >> >> Fixed RxmBranch to do greedy matching instead of first match passes. >> This entailed adding a collection copy to #currentState, so I >> expect this to slow down Regex11 a bit (not measured yet). >> >> This fixes a bug found a Soops: >> '.*(ABCD|BC)' asRegex matches: 'fooABCD' >> and Mantis bug 5391: >> '15' matchesRegex: '[1-9]|1[0-9]' >> >> See http://bugs.squeak.org/view.php?id=5391 >> > > >

May 12, 2011

Re: [Pharo-project] 1.3-Core

by Alexandre Bergel

> This probably has something to do with Zn now being used for HTTP, proxies should be supported, but I have not tested them myself. > > 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) > > Have a look at ZnNetworkingUtils class>>#socketStreamToUrl: > Does this make the right decision in your setup ? Yes it does. ZnNetworkingUtils isProxySet => true Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 12, 2011

Re: [Pharo-project] 1.3-Core

by Sven Van Caekenberghe

Alexandre, On 12 May 2011, at 21:38, Alexandre Bergel wrote: > 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 This probably has something to do with Zn now being used for HTTP, proxies should be supported, but I have not tested them myself. Can you try a simple thing like: ZnClient get: 'http://zn.stfx.eu/zn/small.html' Have a look at ZnNetworkingUtils class>>#socketStreamToUrl: Does this make the right decision in your setup ? Sven

May 12, 2011

[Pharo-project] 1.3-Core

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 12, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSession for Pharo/Squeak and other Smalltalk implementations

by Jan van de Sandt

Hi, No the VASt plugin is not open source. It is not really a plugin. It is just Smalltalk code that calls the OpenSSL lib using external functions (the FFI of VASt). The OpenSSL library delivered with VASt is a very old version and there are some concurrency issues on windows. So I do think that Instantiations is interested in an upgrade. If technically possible than perhaps some kind of cooperation is possible. Two years ago I created an open source alternative for VASt users on windows WinHttpClient & WinCrypt. This is of no use for Zinc because it depends on windows http stack :-( Jan. [1] http://blog.doit.st/2009/06/17/introducing-winhttpclient-for-va-smalltalk/ On Thu, May 12, 2011 at 5:21 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Hi Jan, > > On 12 May 2011, at 17:07, Jan van de Sandt wrote: > > > Hello, > > > > I can help test the client part of a HTTPS implementation. Currently I > use Zinc-HTTP together with stunnel. > > > > Note that VA Smalltalk uses OpenSSL on Linux and Windows. So it is > possible to use OpenSSL on windows as well [1]. > > > > Jan. > > > > [1] http://www.openssl.org/related/binaries.html > > That is interesting. > Is the VAST plugin open source ? > > And of course, thanks for the offer, I knew you would be interested ! > > Sven > > >

May 12, 2011

[Pharo-project] [update 1.3] #13197

by StÃ©phane Ducasse

13197 ----- Issue 4204: PluggabeMenuItemSpec show submenu even is disabled. Thanks benjamin van ryseghem.

May 12, 2011

[Pharo-project] [COTDC] 63 - MimeConverter

by laurent laffont

Today: MimeConverter Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 12, 2011