March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] OB

by CÃ©drick BÃ©ler

yes confirmed (nb I like having buttons there). Cheers, 2009/3/6 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: > Hi David, > > it seems that your last improvement of OB (especially the one defining > the width of the mercury input field) does not work properly. The > input field is above the buttons. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- CÃ©drick

March 6, 2009

[Pharo-project] Fwd: [squeak-dev] An old gripe (or: SystemChangeNotifier + Announcements = Sanity?)

by CÃ©drick BÃ©ler

another change in the air ;) http://www.nabble.com/-squeak-dev--An-old-gripe-(or%3A-SystemChangeNotifier… ---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/3/6 Subject: [squeak-dev] An old gripe (or: SystemChangeNotifier + Announcements = Sanity?) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Folks - While doing some preferences stuff I ran into one of my "most-hated" issues in Squeak. Anyone who has ever encountered SystemChangeNotifier must have noticed how terrible it is to use it. I mean, just look at this code: prefEvent: anEvent Â Â Â Â "Check if this system event defines or removes a preference." Â Â Â Â (anEvent itemKind = SystemChangeNotifier classKind and: [anEvent isRemoved]) ifTrue:[...]. Â Â Â Â anEvent itemKind = SystemChangeNotifier methodKind ifTrue:[ Â Â Â Â Â Â Â Â (anEvent isRemoved or:[anEvent isModified]) ifTrue:[...] Â Â Â Â Â Â Â Â (anEvent isAdded or:[anEvent isModified]) ifTrue:[...] Â Â Â Â ]. just needless, pointless lines of case statements. How do people feel about replacing that mess with Announcements? If you really want to have all events you register for SystemEvent and if you'd like to be more specific you go for more specifically for ClassEvent or even more specifically for ClassAddedEvent. It would also remove the need for all of these weird tests like Â Â Â Â anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] and just replace them with something like "anEvent isMethodRemoval". It would likely be faster too, since most places aren't really interested in *all* events either. It would mean that Announcents would have to go core but this cleanup alone seems worth it. I also suspect that adding Announcements and fixing SystemChangeNotifier may remove more code than it would add. How do people feel about that? Cheers, Â - Andreas -- CÃ©drick

March 6, 2009

[Pharo-project] OB

by Alexandre Bergel

Hi David, it seems that your last improvement of OB (especially the one defining the width of the mercury input field) does not work properly. The input field is above the buttons. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 6, 2009

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