|
|
Hi -
I noticed this thread from last week.
As revealed on the Squeak lists (dev and vm-dev) about a year ago, I've
been working with the .NET bridge for some time, building on Ben Schroeder
and John Pierce's original work (package DotNetBridge-jrp.25, 28 July
2005) in the context of Squeak version 3.7.
This work, done to support my own HCI research, has involved additions of
various kinds:
- various reinforcements and efficiency enhancements for the basic bridge
(detailed below)
- some specialised .NET forms for rendering web pages and HTML fragments,
and some Squeak classes for controlling such forms (collaboration with
Jun Fujima)
- some slightly scary hacks to the Squeak VM to help it support -
imperfectly - the illusion of .NET forms being embedded in the Squeak
Morphic desktop.
This year I'm planning, finally, to release this stuff to the Squeak
community. To get some initial feedback I demonstrated the running system
at the C5 conference in Kyoto last month, and was encouraged by several
key Squeakers to push ahead with releasing the system despite its current
hackiness.
I suspect that the main challenge is that the whole thing is locked in the
era of Squeak 3.7. Worse than that, there's an untidy boundary beyond
which my code depends tightly on its somewhat-customised 3.7 image, and
the packages (Comanche, Seaside, XML parsers etc) loaded into it. Porting
this to 3.10 would probably take a big chunk of time; I certainly can't
promise to do it myself this year.
To be going on with, here's a list of the main updates to the .NET bridge
beyond release 25:
Memory management
- tidying up cross-bridge allocation, registration and garbage collection
of objects
* time-multiplexing between regular and "finalising" bridge states, to
avoid untimely collection of objects that are still needed
* for the same reason, protecting the transient arguments to .NET
events with bridge-managed wrapper objects
- standardised .NET-side delegates for invoke() messages and events, to
avoid creating a new .NET assembly on every invocation
Thread management
- mechanisms to accommodate the bridge design feature whereby each Squeak
process using the bridge is given its own socket-based transport
* maintenance of a Squeak odd-job process to be used for events that
require asynchronous handling, to avoid the uncontrolled multiplication
of processes (and hence Transports) that would arise from using "fork"
* likewise a thread for all events that occur on the UI process, able
to cope with the fact that the UI process may change over time (e.g.,
because of errors resulting in walkbacks)
- Squeak-side mutex-guarded invocation of methods on .NET objects
- special handling for the threads and transports involved in long-lived
calls, such as Form.Run()
- enhanced error handling:
* introduction of thread types to help distinguish real problems from
glitches
* retry for transient "primitive failed"
* automatic re-reading on socket timeout
Efficiency
- simple speed-up of library loading when the bridge is started
- fast, invisible conversion of point/rectangle objects across the bridge
Diagnostics
- detailed logging of .NET events (periodically written to a file)
- facilities for showing on-screen telltales to reveal the bridge state
(object pool, memory etc)
Associated Squeak changes
- mutex-guarded access to key Squeak mechanisms (e.g., Transcript, World
stepList) to enable working with asynchronous calls from Squeak/.NET
processes (in my typical setups there are 30 or more running Squeak
processes)
(This isn't necessarily a complete list. I haven't trawled the changes on
the C# side.)
--
So what can I suggest...?
I'll be happy to give people access to my browser-plugin-style image and
its specialised DLLs, and to write some short explanations of what you can
do with it. This could be ready in, say, three weeks' time.
But if people want to start playing with the source code I'll need some
time to tidy and package it up - my current plan being to tackle this in
May, after getting through some major April deadlines.
In any case, feel free to contact me directly.
All the best -
Aran
--
Aran Lunzer
Hokkaido University
Sapporo, Japan
|
Locked
