- Pharo-dev - lists.pharo.org

Re: [Pharo-project] OTChasingInspector preview

by Alexandre Bergel

> http://source.lukas-renggli.ch/omnibrowser Ok, I found it. >>> I made a blood sacrifice to the OB gods yesterday and they led me to >>> an acceptable (initial) implementation of a chasing inspector:) >>> >>> The code is in OB-Tools-dkh.66 (make sure you've loaded OmniBrowser- >>> dr.442 as well). It'll need a couple more sacrifices to the OB gods >>> before it's really ready (primarily reducing the text pane screen >>> real estate), but you can take it for a spin, if you're interested: >>> >>> OTChasingInspector openOn: { >>> #key->('Smalltalk'->Smalltalk). >>> Dictionary with: #blue->'1' with: #green->'2' }. >>> >>> I'll be using it in GLASS, but if there's interest in a Pharo/Squeak >>> version I'll make sure to keep it up to snuff. Having tooltip for the *, 1, # buttons will definitely help. Alternatively, the title of the window may reflect what is currently displayed. It looks very good Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 6, 2009

Re: [Pharo-project] OTChasingInspector preview

by Lukas Renggli

http://source.lukas-renggli.ch/omnibrowser On Fri, Mar 6, 2009 at 9:24 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I have no idea where to load this OB-Tools-dkh.66 from. it does not > seem to be present on wiresong, and neither in squeaksource. > > Cheers, > Alexandre > > > On 5 Mar 2009, at 17:48, Dale Henrichs wrote: > >> I made a blood sacrifice to the OB gods yesterday and they led me to >> an acceptable (initial) implementation of a chasing inspector:) >> >> The code is in OB-Tools-dkh.66 (make sure you've loaded OmniBrowser- >> dr.442 as well). It'll need a couple more sacrifices to the OB gods >> before it's really ready (primarily reducing the text pane screen >> real estate), but you can take it for a spin, if you're interested: >> >> Â Â OTChasingInspector openOn: { >> Â Â Â Â #key->('Smalltalk'->Smalltalk). >> Â Â Â Â Dictionary with: #blue->'1' with: #green->'2' }. >> >> I'll be using it in GLASS, but if there's interest in a Pharo/Squeak >> version I'll make sure to keep it up to snuff. >> >> Dale >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 6, 2009

Re: [Pharo-project] soap and Pharo

by Alexandre Bergel

I have been using http://www.squeaksource.com/XMLSupport.html and I am quite happy with it Alexandre On 5 Mar 2009, at 18:45, Michael Rueger wrote: > CÃ©drick BÃ©ler wrote: >> Do you know if soap(core) load in Pharo ? >> >> There's a dependancy on Yaxo which doesn't load because of some >> mimetype problem. >> Maybe I'm wrong but there is already xml support in Pharo but not >> trough Yaxo... ? > > Oh, Yaxo needs to work on Pharo, need to check. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 6, 2009

Re: [Pharo-project] OTChasingInspector preview

by Alexandre Bergel

I have no idea where to load this OB-Tools-dkh.66 from. it does not seem to be present on wiresong, and neither in squeaksource. Cheers, Alexandre On 5 Mar 2009, at 17:48, Dale Henrichs wrote: > I made a blood sacrifice to the OB gods yesterday and they led me to > an acceptable (initial) implementation of a chasing inspector:) > > The code is in OB-Tools-dkh.66 (make sure you've loaded OmniBrowser- > dr.442 as well). It'll need a couple more sacrifices to the OB gods > before it's really ready (primarily reducing the text pane screen > real estate), but you can take it for a spin, if you're interested: > > OTChasingInspector openOn: { > #key->('Smalltalk'->Smalltalk). > Dictionary with: #blue->'1' with: #green->'2' }. > > I'll be using it in GLASS, but if there's interest in a Pharo/Squeak > version I'll make sure to keep it up to snuff. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 6, 2009

[Pharo-project] Cog Closure Compiler

by Lukas Renggli

Hi, I finally found out where to get the image level code for the Cog Closure Image. http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ I used the latest Squeak 4.0 VM from John and I tried to load the change-sets into the latest Pharo, as well as into the latest Squeak 3.9.1. In both cases it breaks pretty early on. It is easy to add empty dummy classes that the script tries to patch (e.g. DecompilerTest) but then there are dozens of undeclared variables reported on transcript and the file-in eventually dies. The fact that debugger, compiler, browser and compiled methods are then in a strange state doesn't make it easier ... Has anybody had more success with this? Anybody willing to help making this thing work in Pharo? I desire fast closures so badly ... ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 6, 2009

[Pharo-project] mar visits callbackEnter/callbackLeave

by John M McIntosh

A few weeks back Esteban Lorenzano of Mars fame http://news.squeak.org/2009/01/08/squeak-goes-to-mars/ asked about the SqueakProxy and Objective C Bridge I've been working on, could he use it to get a callback for oh say windowShouldClose: from an NSWindow instance then have some smalltalk code run, and determine YES or NO? Well that sounds simple, should only take a bit of time,... time passes (lots) and lots of iChat and email pass by too. Now it seems the issue is that on OSX and the iPhone UI related things can only run on the main thread, so let's talk a bit about that history. When the Carbon Squeak VM was ported from OS-9 we actually started the interpreter on a background thread. This worked fine until Apple started enforcing the rule about UI related things can only be run on the main thread as they quickly revised the operating system. The VM was patched to ensure any UI related things were performed on the main thread via a cross thread callback. This worked fine until the Sophie team started to exploit Quicktime for audio/video and graphics. It turned out QuickTime calls *really* needed to be on the UI thread. We could funnel *ALL* the FFI calls to the main thread, but that is expensive. So the carbon VM was changed to co-execute interpreter() on the UI thread via polling logic, where the interpreter runs and polls for UI events to service. This solved the problem of deciding should this FFI call be on the UI thread or the background squeak thread, plus then ensured any plugins etc would always have logic that ran on the main UI thread without having the developers worry their brains over it. The curious might note this explains the odd behaviour of the carbon VM when you toast the morphic event polling process, then it fails to service macintosh menus because it's really waiting for some squeak process to invoke get next event so it can service the pending menu interaction. Now the Unix os-x vm using cocoa is less affected by this, but it will NOT run FFI based quicktime calls, also the iPhone VM is *extremely* broken if you do any UIKit stuff (even allocating UIKit objects) from a background thread. For the iPhone VM you *must* remember to execute objective C calls either on the main UI thread, or the background thread. We have to run the iPhone VM on a background thread because the trick we use for the carbon VM to make it run on the foreground thread is broken on the iPhone. Plus if you don't service UI events fast enough on the foreground thread, then the iPhone watchdog will kill you with exception code 0x0badf00d (yes really). Ok, but given the Squeak VM is running on the UI thread then why can we just deal with the windowShouldClose: Well good question, and days of work. Now it seems when get next event is called, we ask the operating system if there are any pending UI events, if so we ask the operating system to service them. Fine, now the SqueakProxy object enters the mix. On the windowShouldClose: the SqueakProxy instance at some point into this operating system call stack gets the windowShouldClose: message. So what does it want to do, well it wants to let the Squeak interpreter *run* so it can convert the NSInvocation instance into a squeak message send, send a windowShouldClose: to the Smalltalk SqueakProxy instance and set the return value, then of course return back to the caller which is 238 levels (well maybe 10) down from the Interpreter's call to the operating system request to service the UI event. Well see the problem I'm already buried in the Interpreter, but need to go back. Now fortunately others have had this *same* issue. http://bugs.squeak.org/view.php?id=6669 I note the Smalltalk code has been integrated into VMMaker many months/ years ago, but the virtualMachine.c/h has not been updated. I further note it works just like advertised. So now when the UI thread enters the SqueakProxy objective-c instance I just do if (isCarbonVM) interpreterProxy->callbackEnter(&callbackid); The simplistic viewpoint is that this call lurches the interpeter() awake (well and lots of other stuff). The smalltalk code runs, and then invokes a primitive to do the interpreterProxy->callbackLeave(callbackid) which longjmps me back to the original point of the callbackEnter() so I continue the flow of finishing up servicing the windowShouldClose: And everyone is happy. Well assuming this stuff actually works, and there isn't some pending callbackEnter/callbackLeave VM changes that have never flowed into the mix, and where how does the Alien support collide, or not collide with all this trickery. Anyway it seems Esteban might get his windowShouldClose: tomorrow. Certainly he can be the first beta tester. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 6, 2009

Re: [Pharo-project] can't load seaside 2.9a2

by MichaelA

Thanks Torsten! That worked! Torsten Bergmann wrote: > > Dont know if 2.9a2 is currently loading, but I use the following > steps to get a more recent version for development: > > - update Pharo to latest core image (as of today #10246) > - run "ScriptLoader loadSuperOB" to get a good OB browser, > when you open a browser use the OBPackageBrowserAdapter as default > browser > - run "ScriptLoader loadSeaside29" to get the latest seaside stuff > (currently this loads the seaside load order test), answer the > questions > - add a comanche adaptor on port 8080 in the appearing seaside console > - point browser to http://localhost:8080/seaside > > This gives you a base and you can load more packages from Monticello > browsers squeaksource.com/Seaside29 repository if required. > > Bye > T. > > > -- > Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL > fÃ¼r nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- View this message in context: http://n2.nabble.com/can%27t-load-seaside-2.9a2-tp2432310p2434067.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 6, 2009

Re: [Pharo-project] {Spam?} Re: [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Schwab,Wilhelm K

Bryce, The vm appears to work on Linux. The machine I am using is not the fastest in the world (1.8G,500M), but it was handy when the old one went on to its reward. The virtual keys are better in this vm; home and end work, which is a nice start. The numeric pad delete does not work and a couple of the other (forget what they are called) are non-mapped or do weird things. I'll see what I can find on how to handle them. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Thursday, March 05, 2009 4:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] {Spam?} Re: [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting Bryce, The v-keys are well-supported in the Windows VM, and are heavily entrenched in my typing skills. If it's not already improved, I will try to find something on how to process them. IIRC, Windows sends separate messages for them, so it could easily be different on Linux. Is there a chance that Sophie would contain relevant changes? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of bryce(a)kampjes.demon.co.uk Sent: Thursday, March 05, 2009 4:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] {Spam?} Re: [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting Schwab,Wilhelm K writes: > Bryce, > > I don't think the plugin locations (internal vs. external) matter. Having how it works documented somewhere easy to find is probably a lot more important than "fixing it." > > Time permitting, I will kick the tires tonight. My present gripe with Linux (perhaps just because my VM is too old) is poor coverage of the virtual keys (arrows, end, etc.). If you got that too, I'll be REALLY happy :) > > Aside from running Pharo, what do I need to do to test for you? Nothing really. I've no idea what virtual key support is like, I don't tend to use them. The Linux VM is my regular VM. Bryce _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 6, 2009

Re: [Pharo-project] my .changes are big what to do?

by Rob Rothwell

I know I have had some rather large changes files after loading lots of things, unloading them, trying again, etc... If you wait too long, Squeak WILL warn you that you need to take action! Smalltalk condenseChanges usually works for me... Rob On Thu, Mar 5, 2009 at 8:12 PM, Sebastian Sastre <ssastre(a)seaswork.com>wrote: > hi there, > after porting the app and all my .changes file of that image is about 28MB > I've heard that squeak can't have a changes file bigger than about 32. What > truth in that? what measures should I take? > thanks > sebastian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 6, 2009

Re: [Pharo-project] Fonts in Linux

by Mariano Martinez Peck

Ahh okok. Thanks! Good to know about the project. Cheers, Mariano On Thu, Mar 5, 2009 at 6:29 PM, <bryce(a)kampjes.demon.co.uk> wrote: > Mariano Martinez Peck writes: > > What is the exupery vm ? and which are the differences to to standard > squeak > > vm ? > > A standard VM with the extensions required to run Exupery, a JIT > written in Smalltalk. You're not going to notice the Exupery > extensions unless you also load the compiler into the image and > start it running. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 6, 2009