DRb for dummies !

[Svend-Erik Kjær Madsen]

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

 

[Sam Stephenson]

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)

 

[Brian Candler]

require 'drb/acl'

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]

Thanks

 

[Renald Buter]

Hello,

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]

Hi --

Hello,

I have a question about Module#dup and Module.remove_method.

Say I have the following:


"A::foo"
=> nil

But now I want to remove foo from A's duplicate:

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>

Let's test it:

NoMethodError: undefined method `foo' for A:Module
from (irb):40
irb(main):041:0>

That works. BUT:

"A::foo"
=> nil

This, I do not understand: where does B.foo live, now and why can't I
remove it?

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

 

[Renald Buter]

Hi --

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

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

 

[David A. Black]

Hi --

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


David

 

[Bertram Scharpf]

Hi,

Am Donnerstag, 10. Mär 2005, 20:12:33 +0900 schrieb David A. Black:

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

 

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

Hi,

Am Donnerstag, 10. Mär 2005, 23:47:05 +0900 schrieb 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

This functions description says: "/* :nodoc: */". That's not
much help.

Subject to my curiosity was not _where_ it happens, but
_why_ it happens.

Bertram

 

[ts]

B> Am Donnerstag, 10. Mär 2005, 23:47:05 +0900 schrieb ts:B> I don't understand this either and would like to know
B> whether this behaviour is intended
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.