- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 9 November 2012 21:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 November 2012 09:36, Sebastian Nozzi <sebnozzi(a)gmail.com> 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? >> > simply open "same" image and look for unique bytecode sequence among > potential call stack in startup code. > then "disable" the method by setting its first bytecode to > "returnself" bytecode. > err.. i mean, take similar image.. find method and then seek same bytecode sequence in image. if there is only one byte sequence in dead image, that should be the method which you need to disable. easy! :) > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Nov. 10, 2012

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

by Igor Stasenko

On 9 November 2012 09:36, Sebastian Nozzi <sebnozzi(a)gmail.com> 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? > simply open "same" image and look for unique bytecode sequence among potential call stack in startup code. then "disable" the method by setting its first bytecode to "returnself" bytecode. -- Best regards, Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Igor Stasenko

On 9 November 2012 16:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > I think that the approach of camillo is the right one. > Examples, examples, examples and a bit more of working examples. > I agree. P.S. Sorry guys it was a tough day for me. Sleepless night + sick + presentation.. > Stef -- Best regards, Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

On 9 November 2012 09:55, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Fernando olivero-2 wrote >> Hi, i wanted to give my opinion on this, since i've encountered some of >> the >> problems you mention. >> >> Sometimes to benefit from the simplicity of Smalltalk while coexisting >> with >> other tools, we must cope with low level technology "glue code". >> >> NB made it easy to do so, compared to Alien,FFI, writing plugins in C. >> When >> i first started with Squeak and the Pharo1.0, it was a real pain >> interfacing with external libraries, THANKS Igor! >> >> Still someones needs to do it, hence why a lot of people of >> this community spent loads of time coding this "extra work" to be able to >> do their "real work". >> >> I wouldn't say that you need to be extremely bright to built a wrapper >> library using NB, once you know what api you want to call, and the type of >> arguments. >> >> There's plenty of examples out there, and Igor always responds with tough >> questions! >> >> Give a try! maybe its easier than you think. >> >> Fernando > > just to clarify, I was not referring to interfacing to c library which is > rather well covered by NB, but to COM. > it should not be hard. there is a standard way how to discover/load interface.. i can't promise anything but i'll try to look at docs to point you to right one -- Best regards, Igor Stasenko.

Nov. 9, 2012

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

by Camillo Bruni

On 2012-11-09, at 20:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. already happened ;) https://code.google.com/p/pharo/issues/detail?id=6941 so this won't happen so easily again :) > Stef > > On Nov 8, 2012, at 10:30 PM, Sebastian Nozzi wrote:

Nov. 9, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by StÃ©phane Ducasse

Igor I think that the approach of camillo is the right one. Examples, examples, examples and a bit more of working examples. Stef On Nov 9, 2012, at 11:49 AM, Igor Stasenko wrote: > Just to make it clear (to everyone): > if you first asking me how to call a function which takes array of > pointers, the question won't left without answer. > but if your next question after my answer is "what is array of pointers" ... > sorry , but you can keep me as arrogant nerd, but i won't answer it. > > -- > Best regards, > Igor Stasenko. >

Nov. 9, 2012

Re: [Pharo-project] PluggableListMorph error, how to debug ?

by StÃ©phane Ducasse

Neat trick! > Suppose I have a reference (in a Workspace/Inspector) for my buggy morph, called "m": > > m drawOn: (NullCanvas new). > > This should trigger the debugger and show you the error. You can then debug, explore, fix, change, etc. Repeat as needed. Even if the bug is fixed, the Morph stays in this "erroneous" state. That's why when the bug is fixed you should call "resumeAfterDrawError" on your Morph: > > m resumeAfterDrawError. > > And it will re-draw it again.

Nov. 9, 2012

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