[#83328] tcltklib and not init'ing tk — aakhter@... (Aamer Akhter)

Hello,

13 messages 2003/10/01

[#83391] mixing in class methods — "Mark J. Reed" <markjreed@...>

Okay, probably a dumb question, but: is there any way to define

22 messages 2003/10/01
[#83392] Re: mixing in class methods — Ryan Pavlik <rpav@...> 2003/10/01

On Thu, 2 Oct 2003 06:02:32 +0900

[#83397] Re: mixing in class methods — Gavin Sinclair <gsinclair@...> 2003/10/01

On Thursday, October 2, 2003, 7:08:00 AM, Ryan wrote:

[#83399] Re: mixing in class methods — "Mark J. Reed" <markjreed@...> 2003/10/02

On Thu, Oct 02, 2003 at 07:37:25AM +0900, Gavin Sinclair wrote:

[#83404] Re: mixing in class methods — "Gavin Sinclair" <gsinclair@...> 2003/10/02

> On Thu, Oct 02, 2003 at 07:37:25AM +0900, Gavin Sinclair wrote:

[#83416] C or C++? — "Joe Cheng" <code@...>

I'd like to start writing Ruby extensions. Does it make a difference

32 messages 2003/10/02
[#83435] Re: C or C++? — "Aleksei Guzev" <aleksei.guzev@...> 2003/10/02

[#83448] xml in Ruby — paul vudmaska <paul_vudmaska@...> 2003/10/02

The biggest problem i have with Ruby is the sleepness

[#83455] Re: xml in Ruby — Chad Fowler <chad@...> 2003/10/02

On Thu, 2 Oct 2003, paul vudmaska wrote:

[#83464] Re: xml in Ruby or no xml it's just a question — paul vudmaska <paul_vudmaska@...> 2003/10/02

>>--------

[#83470] Re: xml in Ruby — paul vudmaska <paul_vudmaska@...>

>>>

15 messages 2003/10/02

[#83551] xml + ruby — paul vudmaska <paul_vudmaska@...>

>>---------

20 messages 2003/10/03
[#83562] Re: xml + ruby — Austin Ziegler <austin@...> 2003/10/03

On Fri, 3 Oct 2003 16:11:46 +0900, paul vudmaska wrote:

[#83554] hash of hashes — Paul Argentoff <argentoff@...>

Hi all.

18 messages 2003/10/03

[#83675] fox-tool - interactive gui builder for fxruby — henon <user@...>

hi fellows,

15 messages 2003/10/05

[#83730] Re: Enumerable#inject is surprising me... — "Weirich, James" <James.Weirich@...>

> Does it surprise you?

17 messages 2003/10/06
[#83732] Re: Enumerable#inject is surprising me... — nobu.nokada@... 2003/10/07

Hi,

[#83801] Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...>

OK. So I'm going to write a text editor for my masters' thesis. The

35 messages 2003/10/08
[#83803] Re: Extension Language for a Text Editor — Ryan Pavlik <rpav@...> 2003/10/08

On Thu, 9 Oct 2003 05:06:32 +0900

[#83806] Re: Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...> 2003/10/08

* Ryan Pavlik <rpav@mephle.com> [Oct, 08 2003 22:30]:

[#83812] Re: Extension Language for a Text Editor — Ryan Pavlik <rpav@...> 2003/10/08

On Thu, 9 Oct 2003 06:09:29 +0900

[#83955] Re: Extension Language for a Text Editor — Nikolai Weibull <ruby-talk@...> 2003/10/09

* Ryan Pavlik <rpav@mephle.com> [Oct, 09 2003 09:10]:

[#84169] General Ruby Programming questions — Simon Kitching <simon@...>

21 messages 2003/10/15
[#84170] Re: General Ruby Programming questions — Florian Gross <flgr@...> 2003/10/15

Simon Kitching wrote:

[#84172] Re: General Ruby Programming questions — Simon Kitching <simon@...> 2003/10/15

Hi Florian..

[#84331] Re: Email Harvesting — Greg Vaughn <gvaughn@...>

Ryan Dlugosz said:

17 messages 2003/10/21
[#84335] Re: Email Harvesting — Hugh Sasse Staff Elec Eng <hgs@...> 2003/10/21

On Wed, 22 Oct 2003, Greg Vaughn wrote:

[#84343] Re: Email Harvesting — Ruben Vandeginste <Ruben.Vandeginste@...> 2003/10/22

On Wed, 22 Oct 2003 08:35:32 +0900, Hugh Sasse Staff Elec Eng

[#84341] Ruby-oriented Linux distro? — Hal Fulton <hal9000@...>

There's been some talk of something like this in the past.

15 messages 2003/10/22
[#84348] Re: Ruby-oriented Linux distro? — Gavin Sinclair <gsinclair@...> 2003/10/22

On Wednesday, October 22, 2003, 6:01:16 PM, Hal wrote:

[#84351] Re: Ruby-oriented Linux distro? — Andrew Walrond <andrew@...> 2003/10/22

On Wednesday 22 Oct 2003 11:02 am, Gavin Sinclair wrote:

[#84420] Struggling with variable arguments to block — "Gavin Sinclair" <gsinclair@...>

Hi -talk,

18 messages 2003/10/24
[#84428] Re: Struggling with variable arguments to block — matz@... (Yukihiro Matsumoto) 2003/10/24

Hi,

[#84604] ruby-dev summary 21637-21729 — Takaaki Tateishi <ttate@...>

Hello,

21 messages 2003/10/30
[#84787] Re: ruby-dev summary 21637-21729 — Paul Brannan <pbrannan@...> 2003/11/06

On Fri, Oct 31, 2003 at 07:01:28AM +0900, Takaaki Tateishi wrote:

[#84789] Re: ruby-dev summary 21637-21729 — matz@... (Yukihiro Matsumoto) 2003/11/06

Hi,

[#84792] Re: ruby-dev summary 21637-21729 — Paul Brannan <pbrannan@...> 2003/11/06

On Thu, Nov 06, 2003 at 11:17:59PM +0900, Yukihiro Matsumoto wrote:

[#84794] Re: ruby-dev summary 21637-21729 — matz@... (Yukihiro Matsumoto) 2003/11/06

Hi,

ruby-dev summary 21531-21607

From: Kazuo Saito <ksaito@...>
Date: 2003-10-15 12:07:15 UTC
List: ruby-talk #84138
Hello all,

This is a summary of ruby-dev mailing list.


[ruby-dev:21531] O_ACCMODE

 Tanaka Akira added a constant Fcntl::O_ACCMODE defined
 in POSIX fcntl.h to ext/fcntl module.


[ruby-dev:21538] rb_frame_last_func for alias method

 In the method called with an alias name, rb_frame_last_func()
 returns an ID of the alias name in 1.8.0 release.  In 1.6.0,
 it returns an ID of the original name.

 Kazuhiro Yoshida asked how to get original name ID.
 Matz recommended to include "env.h" and get the ID from
 ruby_frame->orig_func.


[ruby-dev:21543] Enumerator
 (Thanks knu for writing this summary)

 Akinori MUSHA asks again if there is any objection to
 adding Enumerator to the standard distribution, which was
 once nominated before the 1.8.0 release.  None is raised.

 Koji Arai suggests adding more libraries from the "rough"
 module so people start to try them out.

 They discuss the issue on and agree that it would be fine
 to include and develop new libraries in the development 
 branch of ruby, because the main ruby module is much more
 exposed, popular and appealing than the "rough" module.
 The branch is meant to be the best test bed.

 MUSHA, on the other hand, notes that once a new library is
 added to a stable version of ruby, developers must be 
 careful not to break backward compatibility on that branch
 and they should keep distributing it stand-alone for users
 that use old releases.

 He also points out that in order to make the "rough" module
 work better as a farm for (really) rough rubies, we should
 try to get people to know about it and provide a handy 
 installer to make it easier for them to try it out.


[ruby-dev:21590] extend with marshal_dump/marshal_load

 Note:
 Currently, these method's implementation is being heavily
 changed. Check the source first if you try to use them.
 It may be different from our summary.


 NAKAMURA, Hiroshi and Matz is talking about keeping 'extend'
 information of marshaled object.  It is dumped by default,
 but when each user defines his/her original marshal_dump
 and marshal_load, the default behavior is ignored so s/he
 is responsible for supporting the information by themselves.

 Matz showed us in [ruby-dev:21593] an example how to dump
 and load such objects correctly.  In following example, 
 objects of class Quux can be dumped and loaded.  Note that
 class Foo and Bar does not needed to concern about 
 marshaling 'extend' information.

 This example is already applied some patches by NaHi in
 [ruby-dev:21595] to original one:

----
class Foo
  def initialize
    @data_a = 1
    @r, @w = IO.pipe
  end
  def marshal_dump
    @data_a
  end
  def marshal_load(obj)
    @data_a = obj
    @r, @w = IO.pipe
  end
end

class Bar < Foo
  def initialize
    super
    @data_b = 2
  end
  def marshal_dump
    [super, @data_b]
  end
  def marshal_load(data)
    super(data[0])
    @data_b = data[1]
  end
end

module ExtendMarshal
  def marshal_dump
    base_data = super
    extends = (class << self; self; end).ancestors - self.class.ancestors - 
[ExtendMarshal]
    data = {:modules => extends, :base => base_data}
    extends.each do |m|
      m.instance_method(:marshal_dump_extend).bind(self).call(data)
    end
    data
  end
  def marshal_load(data)
    extends = data[:modules]
    extends.reverse_each do |m|
      self.extend(m)
      m.instance_method(:marshal_load_extend).bind(self).call(data)
    end
    super(data[:base])
  end
end

module Baz
  include ExtendMarshal
  def marshal_dump_extend(data)
    data[:Baz] = 42
  end
  def marshal_load_extend(data)
    @baz_data = data[:Baz]
  end
end

class Quux<Bar
  include ExtendMarshal
end
o1 = Quux.new
o1.extend(Baz)
o2 = Marshal.load(Marshal.dump(o1))
p o1
p o2

----

Kazuo Saito <ksaito@uranus.dti.ne.jp>

In This Thread

Prev Next