[Caml-list] OCam'OLE pre-release

[Caml-list] OCam'OLE pre-release

[Nicolas Cannasse]

Hi list !

I'm pleased to announce the .pre release of OCam'OLE, an OLE binding for
OCaml.

OCam'OLE enable you to control remote COM objects with OCaml and is provided
with
OLEGen, a program that generate ML/MLI static type interface from the OLE
Type Libraries.

The current distribution include a sample that demonstrate the combined
usage of
OCam'OLE and OLEGen to enable the creation and the control of an MS Excel
sheet in a few
lines of OCaml code.

This release is ".pre" because it hasn't been heavily tested, so some bugs
could remain
and are waiting for some serious users to discover them :)

You can download it at http://tech.motion-twin.com

I would like to thanks Lexifi (www.lexifi.com) for supporting this project

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] OCam'OLE pre-release (mirror)

[Nicolas Cannasse]

The server is actually really getting slow, so I put a mirror on
http://warplayer.free.fr/files/ocamole-pre.zip for people interested in
downloading the release.

NC

-------------

OCam'OLE enable you to control remote COM objects with OCaml and is provided
with OLEGen, a program that generate ML/MLI static type interface from the
OLE Type Libraries.

The current distribution include a sample that demonstrate the combined
usage of OCam'OLE and OLEGen to enable the creation and the control of an MS
Excel sheet in a few lines of OCaml code.

This release is ".pre" because it hasn't been heavily tested, so some bugs
could remain and are waiting for some serious users to discover them :)

You can download it at http://tech.motion-twin.com

I would like to thanks Lexifi (www.lexifi.com) for supporting this project

Nicolas Cannasse




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release (mirror)

[Samuel Lacas]

Nicolas Cannasse a écrit 1.1K le Wed, Jul 31, 2002 at 02:06:15PM +0200:
# -------------
# 
# OCam'OLE enable you to control remote COM objects with OCaml and is provided
# with OLEGen, a program that generate ML/MLI static type interface from the
# OLE Type Libraries.
# 
# The current distribution include a sample that demonstrate the combined
# usage of OCam'OLE and OLEGen to enable the creation and the control of an MS
# Excel sheet in a few lines of OCaml code.
# 
# This release is ".pre" because it hasn't been heavily tested, so some bugs
# could remain and are waiting for some serious users to discover them :)
# 

Hi,

Excuse me for my naive question, but is it possible to have something
as a "binary" distribution, as least for the "cpp" file ?

I mean, I do not have MSVC at hand, and I suppose I'm not the only
one on the list. Ocaml, yes, MSVC, no :) I assume that a DLL/binary
version for a "windows platform" is as well-defined as "linux
distribution" (that is, there are no two installation alike), so may
be it is not possible for you to provide a compiled "ocamole.cpp" for
poor people like me...

Thanks anyway,

sL
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release (mirror)

[Nicolas Cannasse]

> # OCam'OLE enable you to control remote COM objects with OCaml and is
provided
> # with OLEGen, a program that generate ML/MLI static type interface from
the
> # OLE Type Libraries.
> #
> # The current distribution include a sample that demonstrate the combined
> # usage of OCam'OLE and OLEGen to enable the creation and the control of
an MS
> # Excel sheet in a few lines of OCaml code.
> #
> # This release is ".pre" because it hasn't been heavily tested, so some
bugs
> # could remain and are waiting for some serious users to discover them :)
> #
>
> Hi,
>
> Excuse me for my naive question, but is it possible to have something
> as a "binary" distribution, as least for the "cpp" file ?

The MIRROR url have been updated and now include the file "ocamole.dll"
which is the compiled version of ocamole.cpp. Others files are OCaml-only
and don't require MSVC.

NC

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release (mirror)

[Samuel Lacas]

Nicolas Cannasse a écrit 0.9K le Wed, Jul 31, 2002 at 03:13:02PM +0200:
# The MIRROR url have been updated and now include the file "ocamole.dll"
# which is the compiled version of ocamole.cpp. Others files are OCaml-only
# and don't require MSVC.
# 
# NC

Thank you very much.

sL
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[kyra]

Dear Nicolas!

Great job! Thanks.

I believe, OCam'OLE strikes a very important win32 real-world target: COM
Automation client.

But I must point out typical error (I saw exactly the same error in Haskell
HDirect/COM library): ocaml finalization and com release are _essentially
different_ entities! Sorry for not being sufficiently verbose - i have not
enough time right now. If You doubt this is an issue - I will definitely
clarify my point. Now only a few words: I've built native olegen version
(having replaced CoInitialize/CoUninitialize call in DllMain with a call in
a static dummy class instance constructor/destructor), and discovered this
olegen causes segmentaion fault! It turned out to be sufficient simply to
comment out "i->Release();" in "com_finalize" to make it work.

Regards,
Kyra


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[Nicolas Cannasse]

 > But I must point out typical error (I saw exactly the same error in
Haskell
> HDirect/COM library): ocaml finalization and com release are _essentially
> different_ entities! Sorry for not being sufficiently verbose - i have not
> enough time right now. If You doubt this is an issue - I will definitely
> clarify my point.

Yes, i would actually ear your arguments about that point, because it does
not seems clear to me : the AddRef/Release semantic of COM is a reference
counting to enable the sharing of object and thus determine its time-life
 the last Release() call will trigger effective memory release of the
object ).

For OLE , Release() doesn't not close the Application if it has been put
Visible to the user, but CoUninitiliaze will break the DDE and close it.
That's why i added the primitive "do_not_close" which prevent CoUninitialize
from being called, to enable Applications to remains open even if the ocaml
exit.

> Now only a few words: I've built native olegen version
> (having replaced CoInitialize/CoUninitialize call in DllMain with a call
in
> a static dummy class instance constructor/destructor), and discovered this
> olegen causes segmentaion fault! It turned out to be sufficient simply to
> comment out "i->Release();" in "com_finalize" to make it work.

That behavior should be explained by the following : Release() is called by
the GC, and OCamole perform a full_major cycle on "at_exit" of OCaml. But if
you call CoUnitialize perform having all the COM objects being properly
Released, it can freeze, or simply go on... but then a call to Release()
will cause a seg_fault.

Simply modify ocamole in order to not call "i->Release()" if CoUninitialize
had been made, or ( better ) GC'd all your COM objects before calling
ComUninit.

Nicolas Cannasse


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] OCam'OLE pre-release

[Quetzalcoatl Bradley]

It is not safe to use any COM object, including calling Release on it, after
calling CoUninitialize.  Also in my experience there is much danger in
relying on the order of constructor and destructor call of static variables
to manage lifetime of COM objects or CoInitialize/CoUnitialize call.

Move your CoUnitialize call out of a static variable and into the last
statement of your program.  Since the GC will not run after your
CoUnitialize call, no Release calls will be made on any COM object after
CoUnitialize.  Alternatively, do whatever is necessary to make sure that all
your COM objects are released before your program exits (perhaps by making
sure there is no reachable COM object and then doing a "full major" garbage
collection?)

Quetzalcoatl Bradley
qbradley@blackfen.com


-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of kyra
Sent: Friday, August 02, 2002 4:26 PM
To: Nicolas Cannasse; OCaml
Subject: Re: [Caml-list] OCam'OLE pre-release


> Yes, i would actually ear your arguments about that point, because it does
> not seems clear to me : the AddRef/Release semantic of COM is a reference
> counting to enable the sharing of object and thus determine its time-life
>  the last Release() call will trigger effective memory release of the
> object ).

But ocaml variable and COM reference are merely different things.

> Simply modify ocamole in order to not call "i->Release()" if
CoUninitialize
> had been made, or ( better ) GC'd all your COM objects before calling
> ComUninit.

This does not work. Even not to call CoUninitialize does not work. There is
the same access violation (not segfault as i've early mentioned) error
everywhere: "The object invoked has disconnected from its clients". I am in
no way ocaml or COM expert, but it seems this is because ocaml not only GCs
_unneeded variable_ but also Releases _still needed_ interface.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[kyra]

> Yes, i would actually ear your arguments about that point, because it does
> not seems clear to me : the AddRef/Release semantic of COM is a reference
> counting to enable the sharing of object and thus determine its time-life
>  the last Release() call will trigger effective memory release of the
> object ).

But ocaml variable and COM reference are merely different things.

> Simply modify ocamole in order to not call "i->Release()" if
CoUninitialize
> had been made, or ( better ) GC'd all your COM objects before calling
> ComUninit.

This does not work. Even not to call CoUninitialize does not work. There is
the same access violation (not segfault as i've early mentioned) error
everywhere: "The object invoked has disconnected from its clients". I am in
no way ocaml or COM expert, but it seems this is because ocaml not only GCs
_unneeded variable_ but also Releases _still needed_ interface.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[kyra]

Again. Ocaml can GC any variable thas is no longer used 'as an ocaml
variable'. But it turns out the underlying object is still used 'as COM
object'. In the case of olegen may this be a bad design of oleaut32 server?
Anyway, 'automatic' solution does not exist, so if we map ocaml 'finalize'
to COM 'Release', we must maintain some 'discipline' trying to reference
ocaml variable somewhere if we know it is still used as COM object. Hmm. If
so, where in olegen.ml is this problem buried?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[kyra]

From: "Quetzalcoatl Bradley" <qbradley@mail.newheights.com>
>
> It is not safe to use any COM object, including calling Release on it,
after
> calling CoUninitialize.  Also in my experience there is much danger in
> relying on the order of constructor and destructor call of static
variables
> to manage lifetime of COM objects or CoInitialize/CoUnitialize call.
>
> Move your CoUnitialize call out of a static variable and into the last
> statement of your program.  Since the GC will not run after your
> CoUnitialize call, no Release calls will be made on any COM object after
> CoUnitialize.  Alternatively, do whatever is necessary to make sure that
all
> your COM objects are released before your program exits (perhaps by making
> sure there is no reachable COM object and then doing a "full major"
garbage
> collection?)

Errors mentioned have HOTHING with improper CoUnitialize call. I' have
already written they persist even if I _remove_ CoUnitialize totally. Errors
are because of COM interface is called _after_ being entirely Released.
Moreover, not only native olegen but also native excel1 works just fine with
my modifications. My static object destructor call of CoUninitialize does
not check 'uninit' flag and so 'do_not_close()' has no impact on
CoUninitialize call, but I see no any freezings or something like this.

I am too bad com or ocaml expert, but i'd prefer to unbind Release from
com_finalize, and to have an option to call Release explicitly.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[Nicolas Cannasse]

> Again. Ocaml can GC any variable thas is no longer used 'as an ocaml
> variable'. But it turns out the underlying object is still used 'as COM
> object'. In the case of olegen may this be a bad design of oleaut32
server?
> Anyway, 'automatic' solution does not exist, so if we map ocaml 'finalize'
> to COM 'Release', we must maintain some 'discipline' trying to reference
> ocaml variable somewhere if we know it is still used as COM object. Hmm.
If
> so, where in olegen.ml is this problem buried?

True.
The job of the GC is to release unreferenced objects.
But I don't see how this can cause a bug : it seems that your crash is due
to a call of a COM method on a object AFTER it has been released... if it
has been Release, then it is no longer referenced by Ocaml... so , how can u
ever call a method on it ???

>I am too bad com or ocaml expert, but i'd prefer to unbind Release from
>com_finalize, and to have an option to call Release explicitly.

This solution is not an acceptable one.
You still can choose to modify OCam'OLE on your own....

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[Xavier Leroy]

> The job of the GC is to release unreferenced objects.
> But I don't see how this can cause a bug : it seems that your crash is due
> to a call of a COM method on a object AFTER it has been released... if it
> has been Release, then it is no longer referenced by Ocaml... so , how can u
> ever call a method on it ???

Because the COM object can still be referenced from C.  You probably
forgot to do an AddRef somewhere, e.g. when extracting a COM object
reference from its Caml wrapper.

Reference count management sure is tricky...

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[Nicolas Cannasse]

> > The job of the GC is to release unreferenced objects.
> > But I don't see how this can cause a bug : it seems that your crash is
due
> > to a call of a COM method on a object AFTER it has been released... if
it
> > has been Release, then it is no longer referenced by Ocaml... so , how
can u
> > ever call a method on it ???
>
> Because the COM object can still be referenced from C.  You probably
> forgot to do an AddRef somewhere, e.g. when extracting a COM object
> reference from its Caml wrapper.
>
> Reference count management sure is tricky...

True.
If you're using OCamole to manipulate COM objects and then passing them back
to C, your C code need to call AddRef on the retreived COM object since
OCamole GC'ed process does not respect the COM spec (caller is responsible
from Release, callee call AddRef )

Simply use the following function :

IUnknown *get_com_object( value v ) {
    IUnknown *o = IUnknown_val(v);
    o->AddRef();
    return o;
}

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[kyra]

> > Because the COM object can still be referenced from C.  You probably
> > forgot to do an AddRef somewhere, e.g. when extracting a COM object
> > reference from its Caml wrapper.
> >
> > Reference count management sure is tricky...
>
> True.
> If you're using OCamole to manipulate COM objects and then passing them
back
> to C, your C code need to call AddRef on the retreived COM object since
> OCamole GC'ed process does not respect the COM spec (caller is responsible
> from Release, callee call AddRef )
>
> Simply use the following function :
>
> IUnknown *get_com_object( value v ) {
>     IUnknown *o = IUnknown_val(v);
>     o->AddRef();
>     return o;
> }
>
> Nicolas Cannasse
>
I'd want to remind that original subject was 'olegen' application. Being
compiled natively it _does not work_. The error is access violation, caused
by "The object invoked has disconnected from its clients". I believe this is
because of Released COM object is invoked from _another COM object_. In my
first post on this topic I had conjectured this was design flaw - binding
Release with finalize. The main reason was:  _one cannot guarantee_ that
there are not other references to COM object from another COM objects. May
be one can suppose, but cannot guarantee. If I'm wrong, we must follow X.
Leroy and try to find the error in ocamole.cpp. If I'm wrong again, why does
olegen not work???

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCam'OLE pre-release

[Nicolas Cannasse]

> > > Because the COM object can still be referenced from C.  You probably
> > > forgot to do an AddRef somewhere, e.g. when extracting a COM object
> > > reference from its Caml wrapper.
> > >
> > > Reference count management sure is tricky...
> >
> > True.
> > If you're using OCamole to manipulate COM objects and then passing them
> back
> > to C, your C code need to call AddRef on the retreived COM object since
> > OCamole GC'ed process does not respect the COM spec (caller is
responsible
> > from Release, callee call AddRef )
> >
> > Simply use the following function :
> >
> > IUnknown *get_com_object( value v ) {
> >     IUnknown *o = IUnknown_val(v);
> >     o->AddRef();
> >     return o;
> > }
> >
> > Nicolas Cannasse
> >
> I'd want to remind that original subject was 'olegen' application. Being
> compiled natively it _does not work_. The error is access violation,
caused
> by "The object invoked has disconnected from its clients". I believe this
is
> because of Released COM object is invoked from _another COM object_. In my
> first post on this topic I had conjectured this was design flaw - binding
> Release with finalize. The main reason was:  _one cannot guarantee_ that
> there are not other references to COM object from another COM objects. May
> be one can suppose, but cannot guarantee. If I'm wrong, we must follow X.
> Leroy and try to find the error in ocamole.cpp. If I'm wrong again, why
does
> olegen not work???

Sorry but I didn't get this in your previous emails.
I'm currently investigating the native compilation issues.
Please consider that only bytecode compilation is available in the .pre
Release.
If you're experiencing any problem/bug with OCamole and/or OLEGen, please
send me a report in order to fix it.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners