Comments on: More ways to turn Internet feeds into TV feeds

By: riverbed wan acceleration

riverbed wan acceleration — Sat, 06 Dec 2008 09:07:37 +0000

Abstract: We describe the LHCb detector simulation application (Gauss) based on the Geant4 toolkit. The application is built using the Gaudi software framework, which is used for all event- processing applications in the LHCb experiment. The existence of an underlying framework allows several common basic services such as persistency, interactivity, as well as detector geometry description or particle data to be shared between simulation, reconstruction and analysis applications. The main benefits of such…

By: An Internet-to-TV feed with IronPython, XAML, and WPF « Jon Udell

An Internet-to-TV feed with IronPython, XAML, and WPF « Jon Udell — Wed, 15 Oct 2008 17:37:06 +0000

[...] data feed into a video crawl for use on a local public access cable television channel. In the last installment the solution had evolved into an IronPython script that fetches the data, writes the XAML code to [...]

By: How to wire up a timer-triggered WPF event handler in IronPython « Jon Udell

Thu, 17 Jul 2008 17:29:25 +0000

[...] this comment, Michael Foord, author of IronPython in Action and a major contributor to the IronPython Cookbook, [...]

By: Jon Udell

Jon Udell — Wed, 02 Jul 2008 13:58:41 +0000

> The *only* caveat is that IronPython does
> keep a reference to functions that you
> hook up as event handlers

Gotcha. Thanks again Michael!

Now on to the /really/ tricky part of this project. How to establish and maintain a list of trusted feeds for community events. Or actually, multiple related lists, since the community standards upheld by local TV and those upheld by a community website will differ slightly.

And then, of course, how to educate people as to how and why to publish and register feeds.

By: Michael Foord

Michael Foord — Tue, 01 Jul 2008 21:01:41 +0000

We haven’t found that IronPython leaks memory. The .NET garbage collection is very impressive, and IronPython of course uses it seamlessly.

The *only* caveat is that IronPython does keep a reference to functions that you hook up as event handlers – so that if you want to dispose of GUI components like forms these handlers can sometimes keep them alive.

Explicitly unhooking the event handlers solves the problem – and I think this may have been fixed between IronPython 1 and 2.

Michael

By: Jon Udell

Jon Udell — Tue, 01 Jul 2008 18:25:10 +0000

> To solve the delegate problem you need to
> use ‘CallTarget0′ provided in the
> IronPython project.

Ah. Thanks Michael! In this case, I’m actually thinking of leaving things as they are because of a hunch that a long-running C# program will be less likely to leak than a long-running IronPython program. But that’s just an unfounded hunch, I have no evidence. Curious what you think.

By: Michael Foord

Michael Foord — Tue, 01 Jul 2008 18:17:06 +0000

To solve the delegate problem you need to use ‘CallTarget0′ provided in the IronPython project.

I can’t off the top of my head remember where you import it from (it is different between IronPython 1 & 2 I believe) – but I’m pretty sure it is on the IronPython Cookbook.

Michael

By: Jon Udell

Jon Udell — Tue, 01 Jul 2008 18:10:15 +0000

> shouldn’t any IronPython function implicitly
> typecast to a delegate type?

For reasons that I’m probably not even qualified to understand, it seems not to work that way.

By: dbt

dbt — Tue, 01 Jul 2008 16:10:31 +0000

I don’t have a windows box handy to test this, but shouldn’t any IronPython function implicitly typecast to a delegate type successfully?