[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

DRb for dummies !

Svend-Erik Kjær Madsen

11/28/2004 11:00:00 AM

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 ?
--
Forever Ruby newbee :-)
/Sv-e
12 Answers

Sam Stephenson

11/28/2004 11:09:00 AM

0

On Sun, 28 Nov 2004 20:02:52 +0900, Svend-Erik Kjær Madsen
<sv-erik@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

11/28/2004 11:19:00 AM

0

Sam Stephenson wrote:

> require 'drb/acl'

Well that produces:

server.rb:8: uninitialized constant DRb (NameError)


--
/Sv-e

Brian Candler

11/28/2004 1:57:00 PM

0

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

Regards,

Brian.


Svend-Erik Kjær Madsen

12/1/2004 7:15:00 AM

0

Brian Candler wrote:

>> > require 'drb/acl'
Thanks
--
/Sv-e

Renald Buter

3/9/2005 9:06:00 AM

0

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


dblack

3/9/2005 2:07:00 PM

0

Renald Buter

3/10/2005 8:23:00 AM

0

On 23:06 Wed 09 Mar , David A. Black wrote:
> 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


dblack

3/10/2005 11:13:00 AM

0

Bertram Scharpf

3/10/2005 2:35:00 PM

0

Hi,

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


ts

3/10/2005 2:47:00 PM

0

>>>>> "B" == Bertram Scharpf <lists@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



Guy Decoux