DRb for dummies !
Svend-Erik Kjær Madsen
I just cant figure out how to use ACL in my first attempt to write a little
DRb server.
My code:
<SNIP>
require 'drb'
acl = ACL.new( %w[deny all
allow 192.168.1.*
allow localhost ] )
DRb.install_acl(acl)
class LogFileServer
def readlog
logf = File.open("/var/log/apache/error.log")
return logf.read
logf.close
rescue
return "Do some error handling"
end
end
myFirstServer = LogFileServer.new
DRb.start_service('druby://localhost:9000', myFirstServer)
DRb.thread.join
</SNIP>
Produces:
server.rb:3: uninitialized constant ACL (NameError)
If i let out all the acl stuff, it works out fine.
Do I miss something, for "ACL.new" to work, or do I place the code wrong ?
--
Forever Ruby newbee :-)
/Sv-e
Sam Stephenson
<sv-...@fjernstofanet.dk> wrote:
> server.rb:3: uninitialized constant ACL (NameError)
>
> If i let out all the acl stuff, it works out fine.
>
> Do I miss something, for "ACL.new" to work, or do I place the code wrong ?
> --
require 'drb/acl'
> Forever Ruby newbee :-)
> /Sv-e
Aren't we all :)
Sam
Svend-Erik Kjær Madsen
> require 'drb/acl'
Well that produces:
server.rb:8: uninitialized constant DRb (NameError)
--
/Sv-e
Brian Candler
>
> Well that produces:
>
> server.rb:8: uninitialized constant DRb (NameError)
You need *both* require 'drb' *and* require 'drb/acl'
See also http://www.rubygarden.org/ruby?DrbTutorial
Regards,
Brian.
Svend-Erik Kjær Madsen
>> > require 'drb/acl'
Thanks
--
/Sv-e
Renald Buter
I have a question about Module#dup and Module.remove_method.
Say I have the following:
> module A
> def self.foo; puts "A::foo; end
> end
> B = A.dup
> B.foo
"A::foo"
=> nil
But now I want to remove foo from A's duplicate:
> class <<B; remove_method :foo; end
NameError: method `foo' not defined in Module
from (irb):37:in `remove_method'
from (irb):37
Ah? Well OK, let's remove it from A then.
> class <<A; remove_method :foo; end
=> #<Class:A>
Let's test it:
> A.foo
NoMethodError: undefined method `foo' for A:Module
from (irb):40
irb(main):041:0>
That works. BUT:
> B.foo
"A::foo"
=> nil
This, I do not understand: where does B.foo live, now and why can't I
remove it?
Regards,
Renald
David A. Black
B.foo lives in A (the methods don't get dup'd when the class object is
dup'd), and to remove it from B you can use undef_method.
remove_method will only operate on the module where the method was
defined, whereas undef_method will take it out of the search path of
any module that could see it before.
David
--
David A. Black
dbl...@wobblini.net
David A. Black
On Thu, 10 Mar 2005, Renald Buter wrote:
> Thank you very much for you answer, but it's still not clear to me: I
> *have* removed the method from A, yet B can still access it. How's that
> possible? Is it now a dangling method of some kind?
Now that I look at it again... I think it must be special handling of
Class objects. In the general case, a dup'd object doesn't see the
singleton methods of the original object:
irb(main):006:0> x = Object.new
=> #<Object:0x40292b40>
irb(main):007:0> def x.foo; "hi"; end
=> nil
irb(main):008:0> y = x.dup
=> #<Object:0x40288dd4>
irb(main):009:0> y.foo
NoMethodError: undefined method `foo' for #<Object:0x40288dd4>
So, if it's set up to work differently for classes, I would then
assume that your class B (the dup) is given its own reference to
A.foo, and that that reference persists even though A itself can no
longer call foo.
I don't know whether this is by design or is some kind of side-effect
of some of the other special-case handling of Class objects (such as
inheritance, which also allows one object automatic access to the
singleton methods of another).
Renald Buter
Thank you very much for you answer, but it's still not clear to me: I
*have* removed the method from A, yet B can still access it. How's that
possible? Is it now a dangling method of some kind?
Just curious...
Renald
ts
B> I don't understand this either and would like to know
B> whether this behaviour is intended
look at rb_mod_init_copy() in class.c
Guy Decoux
Bertram Scharpf
Am Donnerstag, 10. Mär 2005, 20:12:33 +0900 schrieb David A. Black:
> On Thu, 10 Mar 2005, Renald Buter wrote:
> >On 23:06 Wed 09 Mar , David A. Black wrote:
> >>On Wed, 9 Mar 2005, Renald Buter wrote:
> >>
> >>B.foo lives in A (the methods don't get dup'd when the class object is
> >>dup'd), and to remove it from B you can use undef_method.
> >
> >Thank you very much for you answer, but it's still not clear to me: I
> >*have* removed the method from A, yet B can still access it. How's that
> >possible? Is it now a dangling method of some kind?
>
> Now that I look at it again... I think it must be special handling of
> Class objects. In the general case, a dup'd object doesn't see the
> singleton methods of the original object:
I see the same behaviour:
>> q = 'probscedian'
=> "probscedian"
>> class <<q ; def snuffle ; end ; end
=> nil
>> c = q.clone ; d = q.dup
=> "probscedian"
>> [q,c,d].map do |x| x.singleton_methods end
=> [["snuffle"], ["snuffle"], []]
>> module Q ; def Q.foo ; end ; end
=> nil
>> C = Q.clone ; D = Q.dup
=> D
>> [Q,C,D].map do |m| m.singleton_methods end
=> [["foo"], ["foo"], ["foo"]]
>>
> I don't know whether this is by design or is some kind of side-effect
> of some of the other special-case handling of Class objects (such as
> inheritance, which also allows one object automatic access to the
> singleton methods of another).
I don't understand this either and would like to know
whether this behaviour is intended and if, then why.
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
Bertram Scharpf
This functions description says: "/* :nodoc: */". That's not
much help.
Subject to my curiosity was not _where_ it happens, but
_why_ it happens.
"Peña, Botp"
//That's the issue: you can't restore the old method-resolving
//behaviour in the duped object: say there is a parent of A
//that implements 'foo' also, there is now no way of calling
//that automatically in X, except through explicitly setting foo like:
^^^^^^^^^^
//
// class <<X; def foo; A.foo; end; end
//
i like that. I don't want automatic behavior. It invites trouble unseen fr a
far far away child.
//Hell, of course I can live with this, but it stil feels like
//some kind of trade-off :)
//
:-)
//Regards,
//
//Renald
kind regards -botp
ts
B> Am Donnerstag, 10. Mär 2005, 23:47:05 +0900 schrieb ts:
>> >>>>> "B" == Bertram Scharpf <li...@bertram-scharpf.de> writes:
>>
B> I don't understand this either and would like to know
B> whether this behaviour is intended
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> look at rb_mod_init_copy() in class.c
B> This functions description says: "/* :nodoc: */". That's not
B> much help.
perhaps not for you
B> Subject to my curiosity was not _where_ it happens, but
B> _why_ it happens.
Your question was "whether this behaviour is intended" : look the source
and you have the response.
--
Guy Decoux