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

Re: [Pharo-project] Fixing the StackInterpreterSimulator for Pharo 1.4

by Igor Stasenko

On 8 November 2012 14:16, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > On 06 Nov 2012, at 17:59, StÃ©phane Ducasse wrote: > >>> The attached change set fixes bit rot in the StackInterpreterSimulator and related classes. >>> >>> Here a brief summary: >>> >>> - VMClass>>#doOrDefer: now uses ProcessBrowser>>#isUIProcess: instead of Project >>> - it replaces the use of #asDisplayText with StringMorph>>#contents:. >>> - use of ThreadStream>>#on: is replaced with ThreadSafeTranscript>>#new >>> - Utilities is replaced by UIManager>>#default >>> - and #primitiveGetAttribute now uses the non-depricated `Smalltalk vm getSystemAttribute: attr` > > Here are more complete patch. > > > > Into which tracker should that go? > CogVM or Pharo? > the build job? https://ci.lille.inria.fr/pharo/view/Cog/job/Cog%20Git%20Tracker/ > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Best regards, Igor Stasenko.

Nov. 9, 2012

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

by Igor Stasenko

My recipe is: - simply find an offending compiled method - replace its first bytecode to "returnself" - run the image, recompile that method. done On 8 November 2012 22:11, 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. > > sebastian > > o/ > > PS: about this I won't blame smalltalk at all. This is piece of cake for > TimeMachine. Problem is that "coincidentally" I've neglected mcz commits for > the code of this image. The blame is all mine > > > > On Nov 8, 2012, at 7: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. >> >> >> > > -- Best regards, Igor Stasenko.

Nov. 9, 2012

[Pharo-project] OSProcess in Pharo 2.0

by roberto.minelli＠usi.ch

Hi, I'd like to script some shell commands in Pharo 2.0. Is there any way to do that in Pharo? It seems OSProcess class is suitable but seems it's not yet fully ported in Pharo 2.0. Thanks, Roberto

Nov. 9, 2012

Re: [Pharo-project] Pharo wiki?

by Geert Claes

Mariano Martinez Peck wrote > We have this: http://book.pharo-project.org/ true, although that's not really a wiki because you need to be a contributor to be able to edit ... not that it is hard to become one :) http://book.pharo-project.org/book/Contribute/ContributeToPharoBook/?_s=k-x… -- View this message in context: http://forum.world.st/Pharo-wiki-tp4654567p4654581.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 9, 2012

[Pharo-project] CI out of space again?

by Pavel Krivanek

Hi, we got this error in the scripts download job: ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway hudson.plugins.git.GitException: Command "git fetch -t git://gitorious.org/pharo-build/pharo-build.git +refs/heads/*:refs/remotes/origin/*" returned status code 255: stdout: stderr: error: cannot open .git/FETCH_HEAD: Read-only file system It seems that the Jenkins is out of space agin. -- Pavel

Nov. 9, 2012

Re: [Pharo-project] Pharo wiki?

by Mariano Martinez Peck

On Fri, Nov 9, 2012 at 1:33 AM, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > Hello Pharo Community, > > are there plans to host a Pharo wiki somewhere? > > (for tutorials, tips, faqs, documentation, ideas, brainstorming, etc.) > > We have this: http://book.pharo-project.org/ > Cheers, > > Sebastian > > -- Mariano http://marianopeck.wordpress.com

Nov. 9, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

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 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. > I thought I would provide that information, just in case in has a big > bearing NB/Pharo's ability and on my learning curve. > > Jimmie > -- Best regards, Igor Stasenko.

Nov. 9, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

On 8 November 2012 22:50, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > I am developing an application which needs to access a proprietary business > API to access data from their servers. > > Currently because I don't know how to do that from within Pharo, I have been > using Python/COM. But that API is deprecated and expires soon. Now I have to > move to an app which accesses via either a C/C++ app which accesses a DLL, a > .NET library or a Java jar. > > There are a number of objects that have to be created from the dll/jar, and > a number of interfaces which have to be implemented from the dll/jar. > Presently I am studying Clojure in order to work from the Java side. I do > not know Clojure or Java. If I could learn sufficient C and do this with NB > in Pharo, that would be very nice. > > I have never done anything like what NB does, so I do not know what all it > does or can do. It can do anything you can do :) > > Can Pharo implement the interfaces provided in the DLL in the Smalltalk > side? Pharo can't , you can :) But if you talk about COM interfaces, then yes. It is doable. The only problem is, that it is not done by anyone. > Or would the interfaces have to be implemented on the C side and then Pharo > access the objects? > AFAIK, COM is fairly simple. You need to do a lill parsing deciphering IDL interface, and frankly i don't remember all the details. But at the end, it is just a bunch of C calls. With NativeBoost you can do calls to C .. so it is doable. Again, Dolphin Smalltalk can use COM , so if it can be done there, i don't see why it is impossible to do the same in Pharo. > Any advise greatly appreciated. > > Thanks. > > Jimmie > -- Best regards, Igor Stasenko.

Nov. 9, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

On 11/8/2012 7:50 PM, Jimmie Houchin wrote: > I am developing an application which needs to access a proprietary > business API to access data from their servers. > > Currently because I don't know how to do that from within Pharo, I > have been using Python/COM. But that API is deprecated and expires > soon. Now I have to move to an app which accesses via either a C/C++ > app which accesses a DLL, a .NET library or a Java jar. > > There are a number of objects that have to be created from the > dll/jar, and a number of interfaces which have to be implemented from > the dll/jar. Presently I am studying Clojure in order to work from the > Java side. I do not know Clojure or Java. If I could learn sufficient > C and do this with NB in Pharo, that would be very nice. > > I have never done anything like what NB does, so I do not know what > all it does or can do. > > Can Pharo implement the interfaces provided in the DLL in the > Smalltalk side? > Or would the interfaces have to be implemented on the C side and then > Pharo access the objects? > > Any advise greatly appreciated. > > Thanks. > > Jimmie 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. I thought I would provide that information, just in case in has a big bearing NB/Pharo's ability and on my learning curve. Jimmie

Nov. 9, 2012

[Pharo-project] NB Capabilities

by Jimmie Houchin

I am developing an application which needs to access a proprietary business API to access data from their servers. Currently because I don't know how to do that from within Pharo, I have been using Python/COM. But that API is deprecated and expires soon. Now I have to move to an app which accesses via either a C/C++ app which accesses a DLL, a .NET library or a Java jar. There are a number of objects that have to be created from the dll/jar, and a number of interfaces which have to be implemented from the dll/jar. Presently I am studying Clojure in order to work from the Java side. I do not know Clojure or Java. If I could learn sufficient C and do this with NB in Pharo, that would be very nice. I have never done anything like what NB does, so I do not know what all it does or can do. Can Pharo implement the interfaces provided in the DLL in the Smalltalk side? Or would the interfaces have to be implemented on the C side and then Pharo access the objects? Any advise greatly appreciated. Thanks. Jimmie

Nov. 9, 2012