November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Recovering Changes from a broken image

by StÃ©phane Ducasse

> This "tip" is very welcome, didn't know that you could import changes made from another image. Should definitely be included in the section "recovering lost changes" in the Pharo book (in case it isn't there already ;-). > > Also very welcome is a new "description of changes". Without knowing its details, may I make a suggestion? > > When recovering lost changes what we need is to quickly distinguish (i.e. "filter-out") operations on classes/methods and everything else. Having to look through all the do-its in order to see if they are "Workspace experiments" or important is very time-consuming, and there is always the possibility to miss some important "do it", and then the whole "import" is stopped. > > So it would be great if there were different "filters", and if the changes were more explicit. > > Other than that, when I needed it, I was grateful that this functionality existed at all :-) this is planned but no time. Ezequiel was working on that and soon it will get back to argentina and we need somebody else to help. > > Cheers, > > Sebastian > > > 2012/11/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Nov 8, 2012, at 9:03 PM, Sven Van Caekenberghe wrote: > > > Hi, > > > > One of the cool things of Smalltalk's images/changes file is that you can do a World Menu > Tools > Recover lost changesâ¦ to get back most [1] of your code in case your image/OS/machine suddenly crashed or you forgot to save your image or commit your Monticello packages. > > > > But we all have encountered the situation where the image is broken, saved in such a state that it no longer starts up properly. In that case your code might seem lost forever. > > > > No, it is not ! > > > > Two days ago I had this problem myself and I remembered something Marcus said some time ago: you can access the changes file of one (in casu your broken image) from another (working) image to select/recover the changes you want. It worked perfectly. > > > > The easiest procedure it to copy the .changes file from the broken image and rename its extension to .cs and then open it from a World Menu > Tools > File Browser and open a Changes browser on it. > > We should add a recover from another image shortcut. > > > > I found this very useful. This is a really important technique to be aware of. > > > > Sven > > > > [1] Sadly, not everything is logged in the changes file: creation of new classes, method deletions are not recorded. > > Yes we should change that. > Ezequiel started to work on a new description of changes. > > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > > > > > >

Nov. 9, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by StÃ©phane Ducasse

Sebastian You know we value code. So if this is a terrible problem for you, it may be wise to spend some evening listening cool music and hacking so that it is better. Because it will not magically happen. There is always a guy behind an improvement. Stef On Nov 8, 2012, at 10:30 PM, Sebastian Nozzi wrote: > Hey there Sebastian, > > I feel your pain. Unfortunately there seem to be *many* places / situations where "halting" is a very bad idea and renders your image unusable. > > That's why I think it would be a good idea to have a "list" of these places (in the documentation and in the Pharo "welcome" Workspace), and maybe the technical reasons behind them. > > Something that I did a couple (!!) of times until I learnt the lesson was to halt withing a Morph>>drawnOn:. If you do, then there goes your UI painting/event processing thread (solution: debug your Morph from outside, passing a NullCanvas). > > It was also possible for me, more than once, to "hang" the image beyond recovery (CMD-dot did not help) if "Delaying" ((Delay forMilliseconds: 200) wait) within the UI thread in an infinite recursion (by mistake). > > As for "rescuing it"... can the "recent changes" help you? In your case you would be directly reading the ".changes" file... Not really rescuing your image, but extracting and saving your work... (and migrating to a new image). > > This is very annoying, I know. Been there a couple of times (although with less serious work than yours). In my opinion something needs to change in this area. These are huge productivity losses, and I fear that many new users (*) would at this point turn their backs on Smalltalk never to look back again. > > Best regards, > > Sebastian N. > > (*) or senior developers evaluating the possibility to use Pharo in their companies. > > > 2012/11/8 Sebastian Sastre <sebastian(a)flowingconcept.com> > â¦I mean ever. > > Because you'll screw your image. > > Mostly when you also are on OS X but, for some crazy reason of the Universe, your TimeMachine was not operating normally on your laptop while coding. > > Aaaaand you weren't committing in the monticello repo because it was work in progress and you were expecting to reach some goal. > > Ever. > > Soâ¦ > > I'm in that situation with an image now :( > > I've the false good idea of putting a halt in an SomeApp class>>startUp: method and now, when I open the image, it tries to, stays for about 2 seconds and crashes. > > Any of you guys have a workaround/hack to rescue it? > > sebastian > > o/ > > PS: I've tried with startup.st with the code that removes that method but no luck. > > > >

Nov. 9, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Sebastian Sastre

okay happy ending. After many iterations to remove offending code it filed in all of it Thanks for the help guys sebastian o/ On Nov 9, 2012, at 8:21 AM, Marcus Denker wrote: > > On Nov 8, 2012, at 10:12 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> I'm currently trying Sven idea: >> >> 1. use a fresh pharo image (same base version your screwed one's changes is) >> 2. rename (a copy of) the changes file as .cs >> 3. open file browser and try to file in that .cs >> >> The first try didn't work because some compilation error. >> >> I've removed the offending code editing manually and trying again >> >> It's slow because is a lot of code >> >> lets see how it ends. >> > > I don't think that this can work... > > What sven meant is to drag the .changes on your new image, it will open a special tool > to browse the changes. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 9, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo. On 11/8/2012 11:31 PM, Igor Stasenko wrote: > On 8 November 2012 23:25, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> On a second look at the API's documentation, the DLL is C++ not C. I don't >> know, but that might have been evident by the requirement of implementing >> interfaces. > well, with C++ it is a bit worse than C: because C++ compilers use > name mangling for the function names. > Means that, if you will look for exported function 'abc()', you will > probably find it under different name, like > abc@nby_xrt How does one go about discovering these names? > apart from that, once you figure the exact correct name, you can go > and call that function. > > Things is a bit different if the exported function is a member of class. > > So, what i can say.. you can try and see if it rolls (or rocks).. and > if it not, then the best option would be to implement own wrapper > library (but this time in C). And then use that library from pharo. Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL. An example from the documentation. ''' An instance of the class implementing |IO2GSessionStatus| interface must be subscribed to the session object before calling IO2GSession <IO2GSession.html>::login <IO2GSession.login.html> method. It is accomplished by calling |IO2GSession| <IO2GSession.html>::|subscribeSessionStatus| <IO2GSession.subscribeSessionStatus.html> method. For example, ... ''' As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo. I like Pharo, but I am not sure at this point, if that is the easiest or best option. I am concerned about learning just enough C++ to shoot myself in the foot. I am also concerned that the C/C++ route will take much more significant learning than Clojure. Going with Clojure does not automatically rule out Pharo. Depending on how much I like or don't like dealing with Clojure/Java and whether or not I would want to implement the rest of my application there. I could also choose to use it to serve the API via http/websockets to a Pharo application. Thanks for your help. Jimmie

Nov. 9, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Jan Vrany

Better to replace symbol #halt with #yourself in the method litarray. Doing it uncoditionally in all compiled methods should not hurt. Easier and safer :-) Jan On 09/11/12 14:31, Henrik Sperre Johansen wrote: > On 09.11.2012 13:36, Sebastian Nozzi wrote: >> 2012/11/9 Igor Stasenko <siguctua(a)gmail.com>: >>> My recipe is: >>> - simply find an offending compiled method >>> - replace its first bytecode to "returnself" >> How do you do this? >> > One could potentially build a tool to do it :) > (with the caveat that one would need to be intimate with the > image/object format) > > - Open a "dead" image file. > - Find offsets for start of object space and symbol table (in the image > header?) > - Search for startUp/startUp:/halt in Symbol table, and record their > object header adresses > - Subtract the object space start start from these, and you'd have the > oop's of these Symbols. > - Scan the image for startUp(:) oops, check if it's the selector of a > CompiledMethod instance, and that halt is one of it's literals. > - If so, replace the first byte in the CM's bytecodes with that of > returnself. > > If you want to do so manually, better get your Neo-goggles on, or be > Igor :P > > Cheers, > Henry >

Nov. 9, 2012

Re: [Pharo-project] Don't ever ever halt in #startUp:

by Henrik Sperre Johansen

On 09.11.2012 13:36, Sebastian Nozzi wrote: > 2012/11/9 Igor Stasenko <siguctua(a)gmail.com>: >> My recipe is: >> - simply find an offending compiled method >> - replace its first bytecode to "returnself" > How do you do this? > One could potentially build a tool to do it :) (with the caveat that one would need to be intimate with the image/object format) - Open a "dead" image file. - Find offsets for start of object space and symbol table (in the image header?) - Search for startUp/startUp:/halt in Symbol table, and record their object header adresses - Subtract the object space start start from these, and you'd have the oop's of these Symbols. - Scan the image for startUp(:) oops, check if it's the selector of a CompiledMethod instance, and that halt is one of it's literals. - If so, replace the first byte in the CM's bytecodes with that of returnself. If you want to do so manually, better get your Neo-goggles on, or be Igor :P Cheers, Henry

Nov. 9, 2012

Re: [Pharo-project] [Jenkins] about Pharo ci infrastructure...

by Marcus Denker

Hi, Good idea! I will forward it to the team working on the ci platform. Marcus On Nov 9, 2012, at 10:49 AM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > Since it is still in beta testing maybe there is still time to consider some > theme-ing to change the default Jenkins look to something nicer (since it > serves more than just Pharo maybe INRIA branded?) ... and yes I know there > are more important things to be done but I wanted to suggest it anyway ;) > > http://www.amazon.com/Jenkins-Continuous-Integration-Cookbook-Alan/dp/18495… > More info on how to: "Skin Jenkins to your corporate look and feel" > > > > -- > View this message in context: http://forum.world.st/Jenkins-about-Pharo-ci-infrastructure-tp4654364p46546… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://marcusdenker.de

Nov. 9, 2012

[Pharo-project] [update 2.0] #20387

by Esteban Lorenzano

20387 ----- Issue 2178: Reverse the logic and avoid a copy in DeflateStream http://code.google.com/p/pharo/issues/detail?id=2178 Issue 6760: Traits don't get repackaged http://code.google.com/p/pharo/issues/detail?id=6760 Issue 6937: RGMonticelloTest in unsuitable package http://code.google.com/p/pharo/issues/detail?id=6937 Issue 6941: Extend Startup SafetyNet for Halt http://code.google.com/p/pharo/issues/detail?id=6941 Diff information: http://ss3.gemstone.com/ss/Pharo20/Traits-EstebanLorenzano.443.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-EstebanLorenzano.731.diff http://ss3.gemstone.com/ss/Pharo20/Ring-Tests-Monticello-EstebanLorenzano.2… http://ss3.gemstone.com/ss/Pharo20/Ring-Tests-Kernel-EstebanLorenzano.38.di… http://ss3.gemstone.com/ss/Pharo20/Compression-EstebanLorenzano.116.diff

Nov. 9, 2012

[Pharo-project] Pharo Kernel Tests failures

by Pavel Krivanek

Hi, I created a summary of tests that fail on Pharo Kernel. Currently 44 tests are failing as result of about 16 issues. https://docs.google.com/spreadsheet/ccc?key=0AjSsmZhqtUTedHBid1R4U0hFOVBWME… Keep in mind that Pharo Kernel has not complete tests coverage because some tests packages need reorganization. On the other hand the amount of loaded tests is not small. It has 7250 tests while full Pharo has 9659 tests. Help in this area is welcome ;-) We (at least I) want to have green tests for the final 2.0 release. Cheers, -- Pavel

Nov. 9, 2012

Re: [Pharo-project] [Jenkins] about Pharo ci infrastructure...

by Geert Claes

ci.inria.fr <https://ci.inria.fr> looks very nice by the way :) -- View this message in context: http://forum.world.st/Jenkins-about-Pharo-ci-infrastructure-tp4654364p46546… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 9, 2012