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

[Pharo-project] [Fwd: Re: [ANN] Preference pragmas]
by Alain Plantec March 6, 2009

March 6, 2009

Here is a comments of Andreas. He compares our two different approaches Cheers Alain

1 0

[Pharo-project] can't load seaside 2.9a2
by Sebastian Sastre March 6, 2009

March 6, 2009

hi there, first of all thanks for making Pharo. I can see there is a lot to do but I'm so glad to see an open smalltalk evoluting in such a direction. I wanted to give a try with a web app I'm porting to seaside 2.9a2 but it won't load (I mean seaside 2.9a2). It's complaining about problems related to MIMEDocuments. Looks like the ones in squeak 3.10.2 are first class objects instead of strings, the mime database and such. I'm missing some update? thanks and all the best sebastian

4 4

[Pharo-project] Fwd: [squeak-dev] An old gripe (or: SystemChangeNotifier + Announcements = Sanity?)
by CÃ©drick BÃ©ler March 6, 2009

March 6, 2009

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

1 0

[Pharo-project] mar visits callbackEnter/callbackLeave
by John M McIntosh March 6, 2009

March 6, 2009

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 = = = ========================================================================

1 0

[Pharo-project] can't load seaside 2.9a2
by Torsten Bergmann March 6, 2009

March 6, 2009

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

2 1

[Pharo-project] my .changes are big what to do?
by Sebastian Sastre March 6, 2009

March 6, 2009

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

2 1

[Pharo-project] Fonts in Linux
by Robert Roland March 6, 2009

March 6, 2009

Hi all, I feel dumb asking this question, but I've been using the Pharo image mostly on a Mac, with the FT2Plugin installed, so I've gotten spoiled by having nice fonts in the image. I've started wanting to use my Linux desktop (Ubuntu 8.10) too, but there doesn't appear to be a Linux FT2Plugin, so I seem to be stuck with one font only - Accuny. I haven't seen any other posts in this list related to that, so I'm assuming everyone's on a different platform, found a way to fix this, or likes Accuny. Having been spoiled by staring at Lucida Grande and Monaco, my eyes aren't too happy with Accuny as my only option. I've only recently begun using the Squeak VM, but compared to the older Squeak images, the Pharo image is worlds ahead. I'm looking forward to participating more, but this font issue is going to nag me. :) Thanks for any help, Robert -- View this message in context: http://n2.nabble.com/Fonts-in-Linux-tp2427790p2427790.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

6 9

[Pharo-project] Preference Implementation collaboration ? (Fwd: [squeak-dev] Re: [ANN] Preference pragmas)
by CÃ©drick BÃ©ler March 5, 2009

March 5, 2009

---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: 2009/3/5 Subject: [squeak-dev] Re: [ANN] Preference pragmas To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Igor Stasenko wrote: > > http://n2.nabble.com/Preference-refactoring-again-tt2403814.html Oh. That is indeed quite similar. Two comments: * There is really no need to specify a #setter: in the pragma - the name of the setter can be derived from the getter (read-only preferences would be pointless, no? ;-) * There is really no need to specify the default explicitly - it can be derived from the current value when the preference is registered. Other than that it looks good. It would be trivial to adjust my version to use this pragma pattern but I would still prefer it if we could collaborate on the implementation. Cheers, Â - Andreas > 2009/3/5 Andreas Raab <andreas.raab(a)gmx.de>: >> >> Edgar J. De Cleene wrote: >>> >>> I trust you and your implementation should go to current .image ASAP. >>> If at some point some guy of different secta come with a better code, we >>> don >>> reject for "heretic" =:) >> >> To the contrary. Let's give collaboration a chance. It would be stupid if we >> ended up with just enough difference to make us incompatible at such a >> superficial level. At the very least we should be waiting for a week or two >> to see if there's any reaction from the Pharo folks. Even if there is no >> reaction we should try to make it compatible at the interface (pragma) >> level. I'd be willing to do at least that but I'd need to know what their >> pragma spec actually looks like (can anyone subscribed to Pharo post an >> example or point me to ti?) >> >> Cheers, >> Â - Andreas >> >> > > > -- CÃ©drick

2 1

Re: [Pharo-project] OT Tools for remote browsing/debugging (Was: Re: OTChasingInspector preview)
by Dale Henrichs March 5, 2009

March 5, 2009

----- "Igor Stasenko" <siguctua(a)gmail.com> wrote: | Dale, i wanted to ask you, how easy OB-Tools could be targeted to | make | own remote debugger/browser? | And is your code free for use (under MIT)? | I'm just considering the how much of my blood could take to implement | these tools for use them in Hydra... :) Igor, OB-Tools is under the MIT license - all of the hard work was done by Lukas. For GLASS, the work involved adapting the debugger commands to the GemStone Process/Context model. In GLASS, the debugger runs on the server-side and we use Morphic on the client-side to display all of the OB windows, so it wasn't necessary to anything (okay just a bit of process fiddling:) to get the Debugger windows to display on the remote client. For Hydra, I would think that remote access to the process/context model would be the ticket - and this would be straightforward with the OTDebugger. With that said, I'm not too familiar with the inter-vm communication model. If I had another debugger to do, I would definitely start with the OTDebugger:) Dale

1 0

[Pharo-project] OT Tools for remote browsing/debugging (Was: Re: OTChasingInspector preview)
by Igor Stasenko March 5, 2009

March 5, 2009

2009/3/5 Dale Henrichs <dale.henrichs(a)gemstone.com>: > 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 > Dale, i wanted to ask you, how easy OB-Tools could be targeted to make own remote debugger/browser? And is your code free for use (under MIT)? I'm just considering the how much of my blood could take to implement these tools for use them in Hydra... :) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

1 0