ruby-core

Hi guys, sorry that I'm posting into the core mailinglist, but in the talk mailinglist no one could'nt / didnt't want to give me some answers about some (basic ? ) ruby core questions.

6 messages 2007/11/26

[#13786] Re: C-Core-Questions — <saladin.mundi@...> 2007/11/26

I think I have explained it too confusing

[#13783] Re: C-Core-Questions — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/11/26

saladin.mundi@gmx.de schrieb:

[#13784] Re: C-Core-Questions — <saladin.mundi@...> 2007/11/26

Yes, I know that some information about C is written in the PickAxe.

[#13785] Re: C-Core-Questions — ts <decoux@...> 2007/11/26

>>>>> "s" == <saladin.mundi@gmx.de> writes:

[#13791] Re: C-Core-Questions — Ryan Davis <ryand-ruby@...> 2007/11/27

[#13782] gem_prelude.rb raises exception — "Yusuke ENDOH" <mame@...>

Hi,

3 messages 2007/11/26

[#13793] Re: gem_prelude.rb raises exception — Richard Kilmer <rich@...> 2007/11/27

[#13826] Re: gem_prelude.rb raises exception — "Yusuke ENDOH" <mame@...> 2007/11/29

> I indeed added that check to skip unless dash and also wrapped the

[#13787] Syntax error when using comment between two lines in new method chain syntax — Wolfgang Nádasi-Donner <ed.odanow@...>

Hi!

3 messages 2007/11/26

[#13788] Re: Syntax error when using comment between two lines in new method chain syntax — Wolfgang Nádasi-Donner <ed.odanow@...> 2007/11/26

Wolfgang N叩dasi-Donner schrieb:

[#13790] Re: Syntax error when using comment between two lines in new method chain syntax — murphy <murphy@...> 2007/11/26

Wolfgang N叩dasi-Donner wrote:

[#13792] Anyone tried -r debug on OSX? — Dave Thomas <dave@...>

It hangs for me here. I have to kill -9 to stop it.

8 messages 2007/11/27

[#13828] Re: Anyone tried -r debug on OSX? — murphy <murphy@...> 2007/11/29

Dave Thomas wrote:

[#13831] Re: Anyone tried -r debug on OSX? — murphy <murphy@...> 2007/11/30

murphy wrote:

[#13832] Re: Anyone tried -r debug on OSX? — Dave Thomas <dave@...> 2007/11/30

[#13836] Re: Anyone tried -r debug on OSX? — "Rick DeNatale" <rick.denatale@...> 2007/11/30

On Nov 29, 2007 9:34 PM, Dave Thomas <dave@pragprog.com> wrote:

[#13837] Re: Anyone tried -r debug on OSX? — Ryan Davis <ryand-ruby@...> 2007/11/30

[#13829] Re: Anyone tried -r debug on OSX? — Ryan Davis <ryand-ruby@...> 2007/11/30

[#13830] Re: Anyone tried -r debug on OSX? — "Laurent Sansonetti" <laurent.sansonetti@...> 2007/11/30

On Nov 27, 2007 2:27 AM, Dave Thomas <dave@pragprog.com> wrote:

[#13796] autoload reminder — Trans <transfire@...>

Just want to remind core team that #autoload does not use the normal

3 messages 2007/11/27

[#13797] Re: autoload reminder — "Felix Geller" <fgeller@...> 2007/11/27

On 11/27/07, Trans <transfire@gmail.com> wrote:

[#13827] Re: autoload reminder — Trans <transfire@...> 2007/11/29

[#13803] Hash#eql? and Hash#== in trunk — Gary Wright <gwtmp01@...>

In Ruby 1.8, Hash#== uses #== to compare values:

2 messages 2007/11/28

[#13823] Re: Hash#eql? and Hash#== in trunk — Yukihiro Matsumoto <matz@...> 2007/11/29

Hi,

[#13805] Socket.gethostbyname and Reverse Lookups: A Strange and Terrible Saga — "Bill Kelly" <billk@...>

(with apologies to Hunter Thompson ;)

4 messages 2007/11/28

[#13806] Re: Socket.gethostbyname and Reverse Lookups: A Strange and Terrible Saga — Gary Wright <gwtmp01@...> 2007/11/28

[#13807] Re: Socket.gethostbyname and Reverse Lookups: A Strange and Terrible Saga — "Bill Kelly" <billk@...> 2007/11/28

[#14193] Re: Socket.gethostbyname and Reverse Lookups: A Strange and Terrible Saga — "Roger Pack" <rogerpack2005@...> 2007/12/21

> Note, I'm not altogether surprised it worked for you on OS X,

[#13814] -v affects parse tree, causes tests to fail in ParseTree — Ryan Davis <ryand-ruby@...>

The problem is that the void_expr macro is used in void_stmts and

5 messages 2007/11/28

[#13815] Re: -v affects parse tree, causes tests to fail in ParseTree — Ryan Davis <ryand-ruby@...> 2007/11/28

[#13822] Re: -v affects parse tree, causes tests to fail in ParseTree — Nobuyoshi Nakada <nobu@...> 2007/11/29

Hi,

[#13816] Re: -v affects parse tree, causes tests to fail in ParseTree — Charles Oliver Nutter <charles.nutter@...> 2007/11/28

Ryan Davis wrote:

[#13817] Re: -v affects parse tree, causes tests to fail in ParseTree — Ryan Davis <ryand-ruby@...> 2007/11/29

[#13818] Dear Matz, — Steven Lumos <steven@...>

3 messages 2007/11/29

[#13819] Re: Dear Matz, — andrew taylor <aktxyz@...> 2007/11/29

[#13820] Re: Dear Matz, — Charles Oliver Nutter <charles.nutter@...> 2007/11/29

Steven Lumos wrote:

[#13824] Inhering from Proc in 1.9? — "Florian Frank" <flori@...>

Hi,

2 messages 2007/11/29

[#13825] Re: Inhering from Proc in 1.9? — SASADA Koichi <ko1@...> 2007/11/29

Hi,

[#13833] Bug in Signal Handling — James Edward Gray II <james@...>

I'm pretty sure we have found a bug in Ruby while working on TextMate.

3 messages 2007/11/30

[#13841] Re: Bug in Signal Handling — Joel VanderWerf <vjoel@...> 2007/12/01

James Edward Gray II wrote:

[#13929] Re: Bug in Signal Handling — James Edward Gray II <james@...> 2007/12/07

On Nov 30, 2007, at 11:47 PM, Joel VanderWerf wrote:

[#13834] warn() vs. puts() — James Edward Gray II <james@...>

Why isn't warn() as smart as puts()?

2 messages 2007/11/30

[#13838] Re: warn() vs. puts() — Ryan Davis <ryand-ruby@...> 2007/11/30

[#13835] "initialize" method in 1.9 Thread gone? — "B. Tommy Jensen" <btoj@...>

Hi,

3 messages 2007/11/30

[#13839] Re: "initialize" method in 1.9 Thread gone? — "Florian Frank" <flori@...> 2007/11/30

B. Tommy Jensen wrote:

[#13840] Re: "initialize" method in 1.9 Thread gone? — Nobuyoshi Nakada <nobu@...> 2007/11/30

Hi,

Re: Proposal of a new operator for Method and Proc

From: "Austin Ziegler" <halostatue@...>

Date: 2007-11-08 13:45:36 UTC

List: ruby-core #13295

On 11/8/07, Jordi <mumismo@gmail.com> wrote:
> == The search for events ==
>
> First, the classes below are not tested and I'm just a beginner, some
> errors are took for granted. Won't affect my discourse. I wanted to
> implement a timer, looking in google the first thing you get is
> something like this:
>
> class Timer
>
>  def start (timeout)
>    th = Thread.new do
>      loop do
>        # work done by the timer
>        sleep(timeout)
>      end
>    end
>  end
> end
>
> Let's suppose I'm only using the timer to implement some kind of counter.
> Cool, BUT I would like that the work of the timer be only time
> related! and the counter be in its relevant class.
> Also I may want to reuse this class.
>
>
> So I thought about something like this
>
> class Timer
>
>  def initialize (*arguments)
>    connections=[]
>    @arguments=arguments
>  end
>  def register_work ( pointer)
>    connections += pointer
>  end
>  def deregister_work (pointer)
>    connections -= pointer
>  end
>  def deregister_all
>    connections =[]
>  end
>  def list
>    connections.each { |l| puts "#{l}" }
>  end
>
>  def start (timeout)
>    th = Thread.new do
>      loop do
>        # work done by the timer
>        connections.each { |l| l.call(*@arguments) }
>        sleep (timeout)
>      end
>    end
>  end
>
> end
>
> I wrote pointer, I meant for instance Counter.count()
>
> This class is much more general and powerful.
> The work is done in the relevant classes and not inside the timer
> Also, we can register as many connected classes as we want.
>
>
> Seeing that this is Good (tm) I thought about how can I make any class use this.
> Of course I can make a class with the register, deregister and call
> thing and mixin it.
>
> But Wouldn't be could that these encapsulated connections are
> supported natively by ruby?
>
> About benefits of this scheme:
> http://doc.trolltech.com/4.3/signalsandslots.html
>
> About a comparison of implementations (going straight to the
> comparison table is better):
> http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html
>
>
> ==The cool stuff ==
>
> I thought about how to get this feature implemented without polluting
> the most basic class of Ruby.
> I think that the most powerful and less polluting way is adding a new
> operator to Method and Proc.
>
>
> Example.
> I have a class Page, a class Timer and a class Counter.  The Page
> instance is the parent of both instances of Timer and Counter.
>
> class Page
>
>  def initialize
>    counter = Counter.new
>    t=Timer.new
>
>    t.timeout -> counter.update
>    counter.overrun -> show_error
>
>  end
>
> end
>
> Some notes:
> We connect the timeout of the timer with the update of the counter.
> We connect the overrun of the counter with an error show by the page.
> The Timer whenever it timeouts, it just ... call to its .timeout() method.
>
> Note that the Timer class does not need to be modified to make
> something new (update the counter) . It is a real isolated software
> component.
> The same goes to the counter, it overruns and let the world know about
> it. That is its job. Don't need to know about the Page having and
> error.
>
> I  proposed "->" in my ignorance. It may appear as a redirect rather
> than "something you add". Surely something else is better.
>
>
>
> With this scheme, we have a general and easy , cool, even rubyish way
> to connect to events and to connect code arbitrarily to any class
> method!
> For instance, we need to make some clean up each time we call to
> File.close() (whatever reason)
> Previous simple way
>
> def close (file)
>  file.close
>  @filesOpened -= 1
> end
>
> new way (in the construstor):
>
> file.close -> {  @filesOpened -= 1 }
>
> {  @filesOpened -= 1 } will become a Proc called when file.close
> finish. See that the implementation in C should be efficient (a list
> of pointers to functions)
>
> Now suppose that you load a new plugin that also need to do some
> cleanup when the file open by the main class is closed. When loaded it
> will add itself whatever it needs for itself.
>
>
> i feel my examples are not very good... sorry.
>
>
> == Summary ==
>
> This addition to the language isolates software components and creates
> a new very powerful construction at a very low cost.
>
>
>
>
> --
> Jordi Polo　(ジョルデイ　ポロ）
> 奈良先端科学技術大学院大学 情報科学研究科
> 自然言語処理学講座 D1
>
>


-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca



On 11/8/07, Jordi <mumismo@gmail.com> wrote:
> On Nov 8, 2007 7:03 PM, Gonzalo Garramuño <ggarra@advancedsl.com.ar> wrote:
> > Jordi wrote:
> > >
> > > class Page
> > >
> > >  def initialize
> > >    counter = Counter.new
> > >    t=Timer.new
> > >
> > >    t.timeout -> counter.update
> > >    counter.overrun -> show_error
> > >
> > >  end
> > >
> > > end
> > >
> >
> > You probably want to learn more about ruby blocks, procs and variable
> > scopes.  Here's a way to do what you want in a ruby way.
> >
> > class Timer
> >     def callback(proc = nil, &block)
> >         @proc = proc || block
> >     end
> >
> > # protected  # but we make it public for this test
> >     def timeout
> >         @proc.call if @proc
> >     end
> > end
> >
> > class Page
> >    def show_error
> >    end
> >
> >    def initialize
> >      @counter = 0
> >      t = Timer.new
> >
> >      t.callback        { @counter += 1  }
> >      t.timeout
> >
> >      # or...
> >      t.callback( method(:show_error) )
> >      t.timeout
> >    end
> > end
> >
> > You also probably want to discuss this sort of stuff in ruby-talk until
> > you are more familiar with ruby.
> >
>
>
> As I said I'm not familiar with the syntaxis (my classes may have
> errors) but I am do familiar with the semantics (I think I pretty
> understand "rubyism").
>
> Your class have a number of problems comparing with my solution. It is
> similar to the second solution I gave.
>
> - You must add that special method callback everytime.  Of course you
> can make an special class for that and use mixins ...
> - You can only register one "signal" . My solution can have an
> arbitrary number.
> - You are adding a new method to every class
>
>
> I would like to extend my proposal to disconnection:
>
> t.timeout -> counter.update  to connect
> I can't imagine a cool operator to mean disconnect (x is graphically
> perfect though)
>
>
> An alternative proposal, more Qt-like (see reference links in the
> first email) and more verbose:
>
> Method or Proc.connect (Method or Proc)
> Method or Proc.disconnect (Method or Proc)
>
> Or a connect and disconnect in Object but I would really won't like to
> pollute it (Object has "send" method though, it is much like half of
> what I need for the connection).
>
>


-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca


On 11/8/07, Jordi <mumismo@gmail.com> wrote:
> As I said I'm not familiar with the syntaxis (my classes may have
> errors) but I am do familiar with the semantics (I think I pretty
> understand "rubyism").

Given your comments, I'm not sure that this is as clear as you think. As
an example, you use "t.timeout" to represent the timeout of the timer,
but there's nothing defined for this. "t.timeout" means sending the
#timeout message to object "t"; it doesn't mean anything to do with some
timeout (or @timeout) variable.

Why does this matter? Well:

> Your class have a number of problems comparing with my solution. It is
> similar to the second solution I gave.
>
> - You must add that special method callback everytime. Of course you
>   can make an special class for that and use mixins ...

You can make a mixin that has such registrations, but you then have to
indicate how signals will be raised.

> - You can only register one "signal" . My solution can have an
>	arbitrary number.

Implementation detail. You don't have to have a single callback
function; you can use a callback function array.

> - You are adding a new method to every class

Less of a problem than you think.

Your proposal doesn't actually suggest how these things would *work* --
how do you implement the slots and signals in general? You need to look
at this a bit deeper and see that there are already analagous things --
like Gonzalo's example of callback functions -- that can be done without
adding ugly syntax to Ruby.

  class Timer
	def initialize(timeout)
	  @callbacks = []
	  @timeout = timeout
	end
	def register(cb)
	  @callbacks << cb
	end
	def unregister(cb)
	  @callbacks.delete(cb)
	end
	def clear_callbacks
	  @callbacks.clear
	end
	def start(*args)
	  th = Thread.new do
		loop do
		  sleep(@timeout)
		  @callbacks.each { |cb| cb.call(*args) }
		end
	  end
	end
  end

  class Counter
	attr_reader :value
	def initialize(start = 0, max = nil)
	  @value = start.to_i
	  @callbacks = []
	  @max = max
	end
	def increment
	  @value += 1
	  @callbacks.each { |cb| cb.call } if @value > @max
	end
	def register(cb)
	  @callbacks << cb
	end
	def unregister(cb)
	  @callbacks.delete(cb)
	end
	def clear_callbacks
	  @callbacks.clear
	end
  end

  class Page
	def show_error; end
	def initialize
	  @counter = Counter.new
	  @timer = Timer.new

	  @timer.register(lambda { @counter.update })
	  @counter.register(lambda { this.show_error })
	end
  end

Where you call a callback isn't able to be generalized.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Thread

Prev Next

In This Thread

Prev Next