How to Display .JPG Files in a Dyalog Application?

[StefanoLanzavecchia]

Years ago I had a discussion with John Daintree about this...
Let's say you manage to get hold of some IDispose-able object in Dyalog APL. Let's say you don't own the object, but the owner is some Microsoft or third-party library which kindly let you have the object because it has some interesting methods and properties, but wants to control its lifetime. Do you really really really want Dyalog APL to call IDispose when the variable goes out of scope? The fact that it goes out of scope in the workspace doesn't mean that its lifetime in the .NET world is over...
As long as there's a bridge to cross between the AppDomain and the workspace you can never be sure when it's the right time to call Dispose....

[Azal]

As long as there's a bridge to cross between the AppDomain and the workspace you can never be sure when it's the right time to call Dispose....

I don't have a so much experience within garbage collection, but as I understand CLR environment can control a released instances. In case of no any reference for it - kill it. As much my application working as more memory leaks. I understand this is dead instances, but were exactly in code I don't know. During development I reload Dyalog APL several times a day, just to release a memory.

Let me advise what will be with instance by executing for example in workspace:
dt←⎕NEW DataTable ⍬
⎕EX 'dt'

Or in function make a local dt, assign a new instance use it and let function finish. I'm not sure that temporary variable dt still not in memory. I think classes like DataTable can hold a lot of system resources.

More complicated example. Dyalog APL.Net has a internal casting between System.String and APL character vector. In most cases it work fine, but in rare case you have to pass to .Net methods real instance of System.String. For example my favorite shared System.Format. It receive two arguments string and Object or Object[]. In common case character vector is a array of chars and String.Format can't understand what I mean. Character vector as a instance of a class System.String (Object) or System.Char[] (Object[]). In this case I make d-function like tostr←{⎕NEW #.String ,⊂⊂⍵}. This take a character vector and make System.String instances without casting. Now you can pass it to String.Format and it work fine. But tostr d-fns spawns new instances and I'm not sure about his fate.

[StefanoLanzavecchia]

Let me advise what will be with instance by executing for example in workspace:
dt←⎕NEW DataTable ⍬
⎕EX 'dt'

This is the issue! Let's say that instead of ⎕NEW'ing it yourself, you got the object from SomeObj.SomeMethod which happens to return a DataTable.

dt←SomeObj.SomeMethod ⍬

But let's say SomeObj needs the DataTable itself for its inner workings. If by ⎕EX'ing 'dt' the interpreter forced the call to Dispose (from the point of view of the interpreter there are no references left to keep "dt" alive), SomeObj would cease working, because the call to dt.Dispose has freed all the internal resources of the DataTable making it a zombie.

Dyalog APL simply cannot call dt.Dispose unless it's told that there are no external references to the DataTable...

You can even think of the issue the other way round.
You instantiate dt:
dt←⎕NEW DataTable ⍬

Then you call a method on SomeOtherObj
SomeOtherObj.SomeOtherMethod dt

and SomeOtherObj thinks that he can do whatever he wants with dt, like storing it somewhere.

Then you
⎕EX'dt'
Let's say at this point Dyalog APL calls dt.Dispose, so the table is invalid.

Then you call another method on SomeOtherObj
SomeOtherObj.SomeOtherMethod2 ⍬
Ooops... SomeOtherObj still needs "dt" but Dyalog APL has disposed of it!

Remember: the call to "Dispose" is not the same thing as the object being eligible for garbage collection: the call to Dispose instructs the object to release its tracked resources (like open files and so on) even if the obejct is still referenced by a thousand references.

[Azal]

But let's say SomeObj needs the DataTable itself for its inner workings. If by ⎕EX'ing 'dt' the interpreter forced the call to Dispose (from the point of view of the interpreter there are no references left to keep "dt" alive), SomeObj would cease working, because the call to dt.Dispose has freed all the internal resources of the DataTable making it a zombie.

There is two environments. Dyalog APL and CLR.
dt is APL variable which represent .Net instance. By []EX 'dt' interpreter has to check if there are any (internal or external) references to this object or not. In case of no reference - kill, if yes just to kill dt as APL variable, not a instance inside CLR environment. There are two kind of methods shared or method which live together with instance. If shared case - method use a external instance and we decide how long this instance will live. We can dispose it when we need. If second case - class itself has to release all resources in Disposing event.

To force delete from both environments it can be Obj.Dispose with []EX Obj.

[Dick Bowman]

This begins to sound like a Dyalog bug to me - if I've deleted the parent form (either by expunging or because it was defined as a local) I think that Dyalog should take case of releasing everything that "belongs" to it. Certainly if there's nothing left in the workspace for the APL programmer to see (via Workspace Explorer - and I'm pretty sure that cupboard was quite bare).

[Azal]

This begins to sound like a Dyalog bug to me

This is not a bug, just a issue and require from us to be more delicate with .Net. Just an example, and I don't know how it will be better by Dyalog behavior:
ADO.NET. I show just a major things, if anybody need a APL code I will provide
1. Create a connection to database []NEW SqlClient.SqlConnection
2. Create a datatable []NEW DataTable
3. Create a adapter for table []NEW SqlClient.SqlAdapter
4. Create a command to retrieve a rows for our DataTable []NEW SqlClient.SqlCommand 'SELECT * FROM MYTABLE'
5. FillSchema and Fill our datatable
6. Create command builder to get a three commands for INSERT/UDDATE/DELETE statements. []NEW SqlClient.SqlCommandBuilder
7. Reference command builder to our adapter. Assign to our adapter properties with appropriate commands. builder.Adapter<-adapter and adapter.UpdateCommand<-builder.GetUpdateCommand (the same for insert and delete command)
8. Set any value to any row in our datatable
9. Update database by calling adapter.Update
SUCCESS

take a look on builder object. This class can help to developer to write correct statements for updating our database. What we need from him - three commands only to assign it to our adapter.

Make changes. Do everything in function and make builder as a local variable. This object don't need as soon as he provide us with update statements.
Run function - SUCCESS. Like we a predict. To delete just a APL variable builder don't delete a instance builder itself.

Add a line between 7 and 8. builder.Dispose

Run function - EXCEPTION. Adapter don't has an appropriate commands. Adapter.UpdateCommand - VALUE ERROR. Opps, why? We assign a commands to adapter in line 7.

By builder.Dispose we dispose a builder itself and all his commands.

[Dick Bowman]

I disagree.

Common sense tells me that if I create a form which contains a control, use it and then delete the form. Everything contained within the form should also be removed from my workspace. Same principle as creating an array and deleting it - we don't find a few elements lingering afterwards.

For me, that's the point of using things like APL - I don't have to bother myself with computer-stuff.

[Morten|Dyalog]

Everything contained within the form should also be removed from my workspace.

And so it is - there is *nothing* left in the APL workspace. The problem is that the .NET Framework has an "improved" memory management scheme, which (unlike the APL workspace) does not use reference counting. Only when it runs out of space does it zip round the universe and determine what is no longer referenced - and can therefore be deleted. The problem is that if objects are holding on to resources like opened files, it can take an unknown amount of time until the resources are freed. The solution is for .NET applications to call the "Dispose" method for objects which need to be closed ASAP when they are no longer needed.

Unfortunatey, as others have explained, there is nothing reasonable and reliable that Dyalog APL can do to automate calling Dispose. If we "auto-disposed" objects when we released our reference to them, the situation might appear to improve for a short while, but you would then discover that things would break in inexplicable ways when you wrote non-trivial .NET applications which needed to continue to use objects that APL had created but no longer had a ref to.

This *IS* unfortunate, I agree - I was dismayed when I first read about the .NET memory manager - but it is supposed to be a big improvement over how C and C++ typically manage memory (programmers keep forgetting to free things, causing memory leaks and crashing systems). It is also supposed to provide superior performance due to very clever algorithms.

Sigh... But if you don't like this, then it is .NET (and not APL) that you need to steer clear of.

[Azal]

If we "auto-disposed" objects when we released our reference to them, the situation might appear to improve for a short while, but you would then discover that things would break in inexplicable ways when you wrote non-trivial .NET applications which needed to continue to use objects that APL had created but no longer had a ref to.

My suggestion - to make a new control structure in Dyalog APL like a VB/C# Using/End Using statement.
http://msdn.microsoft.com/en-us/library/yh598w02.aspx

[StefanoLanzavecchia]

+1 for the suggestion. (In fact, I believe I made it in the past...).
I'd recommend a syntax similar to the :AndIf so that people can write

:using this<-bla
:andusing that<-blu

:endusing

to avoid excessive nesting.

Notice that implicit in the using() {} in C# there's a try/finally block so that the dispose is called EVEN in case of untrapped errors. It would be nice if...