[Caml-list] Unix.kill on Win32

[Caml-list] Unix.kill on Win32

[James Scott]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

 
Hi All, 
 
Would it be possible/sensible to have some limited implementation of
Unix.kill for Win32, so that 'kill pid 9' or 'kill pid 15' worked for
example?
 
James 

[-- Attachment #2: Type: text/html, Size: 3976 bytes --]

[Caml-list] static class member....

[Vovka]

Hi!!!!

Could you help me please. I'm newbie in ocaml programming, i used to write 
programmes in C++ , so I've faced    difficulties in introducing  static 
class member(==a common member for all objects of the same class).  Can i 
handle it in ocaml? Thanks a lot. 

-------------------
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] static class member....

[Richard Jones]

On Wed, Aug 06, 2003 at 04:57:26PM +0400, Vovka wrote:
> Hi!!!!
> 
> Could you help me please. I'm newbie in ocaml programming, i used to write 
> programmes in C++ , so I've faced    difficulties in introducing  static 
> class member(==a common member for all objects of the same class).  Can i 
> handle it in ocaml? Thanks a lot. 

This is one way to do it, there might be other easier ways:

class foo =
  let counter = ref 0 in
  object (self)
    method incr = counter := !counter + 1
    method show = Printf.printf "counter = %d\n" !counter
  end

let () =
  let obj1 = new foo in
  let obj2 = new foo in
  obj1#incr;
  obj2#incr;
  obj1#show;
  obj2#show


There is an ocaml-beginners list for these sorts of questions, and
I've written a tutorial here:

http://merjis.com/richj/computers/ocaml/tutorial/

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"My karma ran over your dogma"

-------------------
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] static class member....

[David Brown]

On Wed, Aug 06, 2003 at 03:45:23PM +0100, Richard Jones wrote:
> On Wed, Aug 06, 2003 at 04:57:26PM +0400, Vovka wrote:
> > Hi!!!!
> > 
> > Could you help me please. I'm newbie in ocaml programming, i used to write 
> > programmes in C++ , so I've faced    difficulties in introducing  static 
> > class member(==a common member for all objects of the same class).  Can i 
> > handle it in ocaml? Thanks a lot. 
> 
> This is one way to do it, there might be other easier ways:
> 
> class foo =
>   let counter = ref 0 in

But this counter will be unique for each new instance of the class.
What they are really asking for is something like

let counter = ref 0
class foo =
  ... counter ...

There is only one counter, globally.

Remember, Ocaml separates the namespace management (modules) from the
class system.  It is easy to hide "counter" with the module spec.

Dave

-------------------
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] static class member....

[Richard Jones]

On Wed, Aug 06, 2003 at 07:51:48AM -0700, David Brown wrote:
> On Wed, Aug 06, 2003 at 03:45:23PM +0100, Richard Jones wrote:
> > On Wed, Aug 06, 2003 at 04:57:26PM +0400, Vovka wrote:
> > > Hi!!!!
> > > 
> > > Could you help me please. I'm newbie in ocaml programming, i used to write 
> > > programmes in C++ , so I've faced    difficulties in introducing  static 
> > > class member(==a common member for all objects of the same class).  Can i 
> > > handle it in ocaml? Thanks a lot. 
> > 
> > This is one way to do it, there might be other easier ways:
> > 
> > class foo =
> >   let counter = ref 0 in
> 
> But this counter will be unique for each new instance of the class.

Not so. Run my code & you'll see it works.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
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] static class member....

[brogoff]

Yes, it says in the language introduction (the part on objects) 

	Let-bindings within class definitions are evaluated before the object 
	is constructed

so using a class local let bound ref works if you want the member to 
be unique on a per class basis. If you'd like the counter to apply to a class 
and everything that inherits from it, then you use module level let's like so 

module Foo =
  struct
    let counter = ref 0

    class c =
      object
        method get () = !counter
        method bump () = incr counter
      end
  end;;

A non-orthogonality of the let within a class is that let module isn't 
permitted. Is there any reason it isn't? 

As a side advice to the OP, it would be worthwhile to avoid the OOP and just 
get used to the ML part of Caml first. 

-- Brian

On Wed, 6 Aug 2003, Richard Jones wrote:

> On Wed, Aug 06, 2003 at 07:51:48AM -0700, David Brown wrote:
> > On Wed, Aug 06, 2003 at 03:45:23PM +0100, Richard Jones wrote:
> > > On Wed, Aug 06, 2003 at 04:57:26PM +0400, Vovka wrote:
> > > > Hi!!!!
> > > > 
> > > > Could you help me please. I'm newbie in ocaml programming, i used to write 
> > > > programmes in C++ , so I've faced    difficulties in introducing  static 
> > > > class member(==a common member for all objects of the same class).  Can i 
> > > > handle it in ocaml? Thanks a lot. 
> > > 
> > > This is one way to do it, there might be other easier ways:
> > > 
> > > class foo =
> > >   let counter = ref 0 in
> > 
> > But this counter will be unique for each new instance of the class.
> 
> Not so. Run my code & you'll see it works.
> 
> Rich.
> 
> -- 
> Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
> Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
> MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
> RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/
> 
> -------------------
> 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] static class member....

[Richard Jones]

On Wed, Aug 06, 2003 at 09:12:24AM -0700, brogoff@speakeasy.net wrote:
> Yes, it says in the language introduction (the part on objects) 
> 
> 	Let-bindings within class definitions are evaluated before the object 
> 	is constructed

Well I take it back. And I must admit that I always have used
let-bindings as if they are local to the instance.

The question though is why does my example work? Is this a bug
in the compiler?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

-------------------
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] static class member....

[David Brown]

On Wed, Aug 06, 2003 at 06:43:30PM +0100, Richard Jones wrote:
> On Wed, Aug 06, 2003 at 09:12:24AM -0700, brogoff@speakeasy.net wrote:
> > Yes, it says in the language introduction (the part on objects) 
> > 
> > 	Let-bindings within class definitions are evaluated before the object 
> > 	is constructed
> 
> Well I take it back. And I must admit that I always have used
> let-bindings as if they are local to the instance.
> 
> The question though is why does my example work? Is this a bug
> in the compiler?

It works because there are no arguments to the class.  In that case, the
class is evaluated once, when that part of the module is evaluated.

If there is an argument to the class, it behaves as if the entire class
definition were wrapped in a function definition.  Therefore it can't
evaluate things inside until the function is fully evaluated.

Creating objects of classes is an unusual thing in ocaml, since it is
like a function application of zero arguments.

What's scary is that I've been bitten by this several times, and still
manage to forget it.

Dave

-------------------
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] static class member....

[William Lovas]

On Wed, Aug 06, 2003 at 11:11:48AM -0700, David Brown wrote:
> On Wed, Aug 06, 2003 at 06:43:30PM +0100, Richard Jones wrote:
> > The question though is why does my example work? Is this a bug
> > in the compiler?
> [...]
> 
> Creating objects of classes is an unusual thing in ocaml, since it is
> like a function application of zero arguments.

Yes, i've just been playing around with it.  It's somewhat instructive to
limit yourself to the core language, and consider instantiation via `new'
to be something like applying a function whose first argument is ().

For a class with no arguments, e.g. something like,

    class foo =
        let counter = ref 0 in
        object
            method next () = incr counter; !counter
        end

the equivalent in the core language might be something like the following
interaction:

    # let new_counter =
        let counter = ref 0 in
        fun () -> fun () -> (incr counter; !counter);;
    val new_counter : unit -> unit -> int = <fun>
    # let count1 = new_counter ();;
    val count1 : unit -> int = <fun>
    # let count2 = new_counter ();;
    val count2 : unit -> int = <fun>
    # count1 ();;
    - : int = 1
    # count2 ();;
    - : int = 2
    # count1 ();;
    - : int = 3

where new_counter's first unit parameter is something like `new'.

But for classes that take arguments, as in

    class foo x =
        let counter = ref 0 in
        object
            method next () = incr counter; !counter
        end

the special initial unit parameter gets lifted up to the top, with the
other argument:

    # let new_counter () x =
        let counter = ref 0 in
        fun () -> (incr counter; !counter);;
    val new_counter : unit -> 'a -> unit -> int = <fun>
    # let count1 = new_counter () "(unused)";;
    val count1 : unit -> int = <fun>
    # let count2 = new_counter () "(unused)";;
    val count2 : unit -> int = <fun>
    # count1 ();;
    - : int = 1
    # count2 ();;
    - : int = 1
    # count1 ();;
    - : int = 2

(Note that the "class parameter" `x' is unused in both examples.)

When translated into this core language representation, it's syntactically
apparent why the counter is local to each "object" in one case and global
to all "objects" in the other -- in the first case, `counter's scope is the
closure that creates new "objects" (which are also closures), while in the
second, it is local to each "object" (each new closure gets its own copy).

Using this knowledge, it's possible to create a class with a parameter that
keeps the counter global to all instances:

    class foo =
        let counter = ref 0 in
        fun x ->
            object
                method next () = incr counter; !counter
            end

Maybe there's a better explanation, but viewed this way, the syntax for
class definitions -- or at least the syntactic sugar -- is somewhat
idiosyncratic.

cheers,
William

-------------------
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] static class member....

[Nicolas Cannasse]

> > Yes, it says in the language introduction (the part on objects)
> >
> > Let-bindings within class definitions are evaluated before the object
> > is constructed
>
> Well I take it back. And I must admit that I always have used
> let-bindings as if they are local to the instance.
>
> The question though is why does my example work? Is this a bug
> in the compiler?

It's not a bug.
You can see your class as function to get a better idea of what's happenning
:

let foo =
    let x = ref 0 in
    (fun () -> !x)

against :

let foo () =
    let x = ref 0 in
    !x

To answer to the original post about class static, there is no concept of
static class variables in Ocaml , but you can still write accessors to a
variable declared outside the class scope :

let counter = ref 0

class foo =
    object
        method incr = incr counter
        method print = Printf.printf "counter = %d\n" !counter
    end

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] static class member....

[Jacques Garrigue]

From: brogoff@speakeasy.net

> A non-orthogonality of the let within a class is that let module isn't 
> permitted. Is there any reason it isn't? 

This is indeed unfortunate, and I've wished for its presence several
times.
I don't think there is a theoretical reason.
However the typing of classes being done in several passes, this would
be much more difficult to implement correctly than the let module
inside usual expressions.

Jacques Garrigue

-------------------
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] static class member....

[james woodyatt]

[please reply to ocaml_beginners@yahoogroups.com]

On Wednesday, Aug 6, 2003, at 09:12 US/Pacific, on the main Ocaml 
mailing list, brogoff@speakeasy.net wrote:
>
> As a side advice to the OP, it would be worthwhile to avoid the OOP 
> and just
> get used to the ML part of Caml first.

I would strongly second this advice.  When I came to Ocaml from C++, I 
did not heed this advice-- and I wasted a lot of time learning why that 
was a mistake.

In fact, the first piece of advice I would pass along to Java/C++ 
programmers who are new to Ocaml is this:

	+ Don't use classes unless functors and module inclusion fail to
	  satisfy your requirements.

There are many fine ways to obtain the kinds of relationships in the 
Ocaml type system that C++ and Java both only use classes to offer.  In 
Ocaml, the object class and class type semantic is only one of the ways 
to skin a particular kind of cat.  It's not, in fact, the most 
straightforward one either.  Until you understand the tradeoffs for 
choosing it, I recommend avoiding it.  You can do *almost* everything 
with 'functor' and 'include' and/or phantom polymorphic variant type 
parameters on abstract types with parameter variance annotations.

That said, the class and class type semantic is an indispensable aspect 
of the language, from my point of view.  It's just not very easy 
explaining why I say that to a newbie.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
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] static class member....

[brogoff]

I think that my issue with the class system is that IMO it doesn't quite fit 
well with the rest of the language, as a class shares some properties with 
modules, and some with records, and has a few of it's own, but doesn't permit 
pattern matching syntax. 

With a few extensions to records (a new kind of records, dual to polymorphic 
variants as sum types are to records), modules (first class modules?, mixin 
modules?), and core ML (yes, I'm still rooting for G'Caml extensions :) that 
even OOP fans would find it classy sans class. 

Even without those extensions, I find the core language + modules sufficient to 
do almost everything nicely, but my pre "ML epiphany" tastes ran towards 
Modula-2/3 and Ada 95 rather than C++ so I may just be warped...

-- Brian

On Wed, 6 Aug 2003, james woodyatt wrote:

> [please reply to ocaml_beginners@yahoogroups.com]
> 
> On Wednesday, Aug 6, 2003, at 09:12 US/Pacific, on the main Ocaml 
> mailing list, brogoff@speakeasy.net wrote:
> >
> > As a side advice to the OP, it would be worthwhile to avoid the OOP 
> > and just
> > get used to the ML part of Caml first.
> 
> I would strongly second this advice.  When I came to Ocaml from C++, I 
> did not heed this advice-- and I wasted a lot of time learning why that 
> was a mistake.
> 
> In fact, the first piece of advice I would pass along to Java/C++ 
> programmers who are new to Ocaml is this:
> 
> 	+ Don't use classes unless functors and module inclusion fail to
> 	  satisfy your requirements.
> 
> There are many fine ways to obtain the kinds of relationships in the 
> Ocaml type system that C++ and Java both only use classes to offer.  In 
> Ocaml, the object class and class type semantic is only one of the ways 
> to skin a particular kind of cat.  It's not, in fact, the most 
> straightforward one either.  Until you understand the tradeoffs for 
> choosing it, I recommend avoiding it.  You can do *almost* everything 
> with 'functor' and 'include' and/or phantom polymorphic variant type 
> parameters on abstract types with parameter variance annotations.
> 
> That said, the class and class type semantic is an indispensable aspect 
> of the language, from my point of view.  It's just not very easy 
> explaining why I say that to a newbie.
> 
> 
> -- 
> j h woodyatt <jhw@wetware.com>
> that's my village calling... no doubt, they want their idiot back.
> 
> -------------------
> 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] static class member....

[John Max Skaller]

james woodyatt wrote:


> I would strongly second this advice.  When I came to Ocaml from C++, I 
> did not heed this advice-- and I wasted a lot of time learning why that 
> was a mistake.

Actaully, my advice to C++ programmers is the same :-)
Don't use classes. Plain old data structures are generally
better -- precisely because they *don't* provide encapsulation.

This saves a whole lot of time writing methods, when you could
just manipulate the data structure directly. Just kill off
stupid Visitor patterns and things and write the code you need
without encumbering yourself with attempts to abstract things
that usually aren't abstract in the first place.

In most business code, even the kinds which are in principle
abstractable are often best not abstracted simply because
there aren't enough instances of the abstraction to bother,
and the client is sure to change the rules and break your
polymorphism anyhow :-)

An example where abstraction is useful: the back end
of a code generator (such as Ocaml itself, or Ocamldoc),
can sensibly be abstracted. However getting the abstraction
just right is a non-trivial exercise and it's often better
to do case by case encoding until the actual abstraction
emerges in the code itself (and then you can encapsulate it).

To put this another way -- don't use abstractions unless you
have a strong theory that tells you what they actually are,
and even then, be circumspect ...

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
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] static class member....

[David Brown]

On Wed, Aug 06, 2003 at 04:10:51PM +0100, Richard Jones wrote:

> > > class foo =
> > >   let counter = ref 0 in

Now I remember why I thought that wouldn't work.

  class foo arg =
    let counter = ref 0 in
    ...

would get a new counter instance each time the class is invoked.  This
acts as a function wrapped around the class invocation.

Dave

-------------------
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] Unix.kill on Win32

[Jacques Garrigue]

From: "James Scott" <j.scott@runbox.com>

> Would it be possible/sensible to have some limited implementation of
> Unix.kill for Win32, so that 'kill pid 9' or 'kill pid 15' worked for
> example?

I may be wrong, but when I looked at the problem about 5 years ago, I
couldn't find any way to act on a windows process from outside it.
The process manager must be using some internal API.

The only solution I found for ocamlbrowser is to have ocamlrun create
a special thread waiting on a pipe, and break when receiving C on this
pipe, and commit suicide when receiving T! This only works if you can
modify the source of the process you want to kill, so this cannot be
in the Unix module.

Now, as it seems that you can dynamically change the dlls a running
process is accessing, I suppose you could also do it without the
source code, if you're a guru.

By the way, the comment in the microsoft documentation about Ctrl-C
handlers being activated in another thread in console applications let
me think that this is more or less the standard way to do it on
windows :-(

I hope I am wrong.

Jacques Garrigue

-------------------
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] Unix.kill on Win32

[Jacques Garrigue]

From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>

> > Would it be possible/sensible to have some limited implementation of
> > Unix.kill for Win32, so that 'kill pid 9' or 'kill pid 15' worked for
> > example?
> 
> I may be wrong, but when I looked at the problem about 5 years ago, I
> couldn't find any way to act on a windows process from outside it.
> The process manager must be using some internal API.

Just a small followup to myself: after a quick search on the web,
there seems to be two functions, TerminateProcess and
GenerateConsoleControlEvent, but making them work like signals is far
from easy. IIRC TerminateProcess on Windows95--ME may sometimes break
the OS.

Jacques Garrigue

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