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

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 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.

May 13, 2011

Re: [Pharo-project] New transcript questions and notes

by Fernando Olivero

Hi Mariano and Doug, thanks for the feedback on the transcript. I will continue working on it this weekend, i'll add the requested/missing features! I'll test it even more, but the log to file checked creates and maintains a synched file with the transcript contents named Transcript.txt ( this is taken from the CUIS transcript). Fernando On Thu, May 12, 2011 at 11:39 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I have submitted issue: http://code.google.com/p/pharo/issues/detail?id=4209 > > Could you proved some of the fixes? > > for me, I miss these things (you can add them to the same issue): > > - be able to do right click and get the normal context menu you get in all > places > - the shortcuts are wrong. I do cmd+sÂ Â which previously cleaned the > transcrip and now nowthing happens, sometimes it is cleaned, sometimes it > does an undo...weird. But I mch prefer do that than clicking in "clear" > - I miss the "Transcript open" > > I want to thanks Fernando for the improvents. Maybe he or another person has > time to give it yet another push for the remaining topics ;) > > cheers > > Mariano > > > On Thu, May 12, 2011 at 7:35 AM, DougEdmunds <dougedmunds(a)gmail.com> wrote: >> >> Using Pharo1.3a >> Latest update: #13193 >> >> Are there any plans to give the new transcript window a mouseable menu? If >> not, buttons for select all and copy would be nice. >> -- >> Nothing seems to be happening when clicking 'log to file'. Â What is the >> name >> of the file? Â Where is it? >> -- >> When checking/unchecking/checking Â 'log to file' will the second checking >> add to the end of an existing file, or will it start a new one, or wipe >> out >> old one and start it over? >> -- >> This code does not work right with the new transcript: >> >> Â Â 1 to: 30 do: [: x | Â Transcript cr; show: x. (Delay forSeconds: 0.2) >> wait.]. >> >> a) Try it in 1.2 (old transcript) to see how it should work. Old >> transcript, >> there's a delay between each line printed. Â 1.3 (new transcript) there's a >> total delay first, then all the lines are immediately printed. >> >> b) If the length of the entries to the transcript exceeds the size of the >> window, the lines do not automatically scroll up to be able to see them. >> Instead, they are added outside of the visible window area. IMO, this must >> be changed so that whatever gets added to the end of the transcript is >> immediately visible. >> >> c) If cursor is at the bottom (with a vertical scroll bar visible), as >> soon >> as a new line is added, the transcript pops back to the beginning again, >> requiring scrolling to see new entries. Â This makes any kind of continual >> stream to the transcript impossible to view. Â Position the Transcript at >> the >> end of the output, then run the 1 to: 30 do: code line again -- it will >> pop >> you to the top, not the end. >> -- >> Will the vertical size of the header area (Clear, etc) be reduced? Â It is >> taller than needed. >> >> >> -- >> View this message in context: >> http://forum.world.st/New-transcript-questions-and-notes-tp3516546p3516546.… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 13, 2011

[Pharo-project] Debugger and Exceptions model

by Igor Stasenko

It would be cool to make debugger be aware of Exceptions, and then make exceptions to designate additional actions which user may perform in addition to "Proceed, Abandon, Debug, Create" Currently all this stuff is hardcoded.. But what i imagine, that if we make debugger to be aware of exceptions (of course if opening debugger is triggered by exception), a debugger could ask exception for additional actions to perform as well as whether immediately open full UI etc. For instance i always wanted that on SubclassResponsibility exception a Debugger can propose me to create a method in subclass, in same way as it proposing to create a method when you got DNU- by adding a 'Create' button. Here the changeset which allows me to do that. But it would be really nice someday to delegate such things to exceptions. -- Best regards, Igor Stasenko AKA sig.

May 13, 2011

Re: [Pharo-project] Problem with CompiledMethodTrailer

by Igor Stasenko

On 12 May 2011 20:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > could you open a ticket that we do not forget. > there is already one,where we discussing that http://code.google.com/p/pharo/issues/detail?id=4200 > Stef > >> It seems like that with this change i Â opened a can of worms. >> There are some tricky logic somewhere ,which uninstalls methods from >> classes and then adds them back. >> So, i added #dropSourcePointer at uninstalling .. then compilation >> becomes too slow (because embedding source code using #becomeForward: >> ). Then i changed #dropSourcePointer to actually erase the trailer >> without using #become .. >> but then some methods lost their source. >> >>> Decompiled code for old methods which were moved as part of a truncation, >>> where the new versions have the exact same, and correct source doesn't sound >>> like the end of the world to me. The method itself did not actually change. >>> >>> Cheers, >>> Henry >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

May 12, 2011

Re: [Pharo-project] New transcript questions and notes

by Mariano Martinez Peck

I have submitted issue: http://code.google.com/p/pharo/issues/detail?id=4209 Could you proved some of the fixes? for me, I miss these things (you can add them to the same issue): - be able to do right click and get the normal context menu you get in all places - the shortcuts are wrong. I do cmd+s which previously cleaned the transcrip and now nowthing happens, sometimes it is cleaned, sometimes it does an undo...weird. But I mch prefer do that than clicking in "clear" - I miss the "Transcript open" I want to thanks Fernando for the improvents. Maybe he or another person has time to give it yet another push for the remaining topics ;) cheers Mariano On Thu, May 12, 2011 at 7:35 AM, DougEdmunds <dougedmunds(a)gmail.com> wrote: > Using Pharo1.3a > Latest update: #13193 > > Are there any plans to give the new transcript window a mouseable menu? If > not, buttons for select all and copy would be nice. > -- > Nothing seems to be happening when clicking 'log to file'. What is the > name > of the file? Where is it? > -- > When checking/unchecking/checking 'log to file' will the second checking > add to the end of an existing file, or will it start a new one, or wipe out > old one and start it over? > -- > This code does not work right with the new transcript: > > 1 to: 30 do: [: x | Transcript cr; show: x. (Delay forSeconds: 0.2) > wait.]. > > a) Try it in 1.2 (old transcript) to see how it should work. Old > transcript, > there's a delay between each line printed. 1.3 (new transcript) there's a > total delay first, then all the lines are immediately printed. > > b) If the length of the entries to the transcript exceeds the size of the > window, the lines do not automatically scroll up to be able to see them. > Instead, they are added outside of the visible window area. IMO, this must > be changed so that whatever gets added to the end of the transcript is > immediately visible. > > c) If cursor is at the bottom (with a vertical scroll bar visible), as soon > as a new line is added, the transcript pops back to the beginning again, > requiring scrolling to see new entries. This makes any kind of continual > stream to the transcript impossible to view. Position the Transcript at > the > end of the output, then run the 1 to: 30 do: code line again -- it will pop > you to the top, not the end. > -- > Will the vertical size of the header area (Clear, etc) be reduced? It is > taller than needed. > > > -- > View this message in context: > http://forum.world.st/New-transcript-questions-and-notes-tp3516546p3516546.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 12, 2011

[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 12, 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