[#10492] Ruby 1.8.6 preview3 has been released — "Akinori MUSHA" <knu@...>

Hi,

26 messages 2007/03/04
[#10500] Re: Ruby 1.8.6 preview3 has been released — Hugh Sasse <hgs@...> 2007/03/05

On Mon, 5 Mar 2007, Akinori MUSHA wrote:

[#10507] Dynamic Array#join with block — <noreply@...>

Patches item #9055, was opened at 2007-03-05 19:57

12 messages 2007/03/05
[#10520] Re: [ ruby-Patches-9055 ] Dynamic Array#join with block — Nobuyoshi Nakada <nobu@...> 2007/03/06

Hi,

[#10594] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org>

In ext/thread/thread.c, remove_one leaves the list in an inconsistent state.

15 messages 2007/03/14
[#10596] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 00:15:57 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10597] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

> > The fix is in thread-mutex-remove_one.diff.

[#10598] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:19:04 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10599] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

On Wednesday 14 March 2007 17:29, MenTaLguY wrote:

[#10600] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:48:42 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10615] Multiton in standard library — TRANS <transfire@...>

Hi--

16 messages 2007/03/15
[#10619] Re: Multiton in standard library — Tom Pollard <tomp@...> 2007/03/16

[#10620] Re: Multiton in standard library — TRANS <transfire@...> 2007/03/16

On 3/15/07, Tom Pollard <tomp@earthlink.net> wrote:

[#10646] Marshal.dump shouldn't complain about singletons if the _dump method is defined — <noreply@...>

Bugs item #9376, was opened at 2007-03-19 15:58

12 messages 2007/03/19
[#10647] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Urabe Shyouhei <shyouhei@...> 2007/03/19

noreply@rubyforge.org wrote:

[#10648] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/19

On Monday 19 March 2007 18:01, Urabe Shyouhei wrote:

[#10651] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Yukihiro Matsumoto <matz@...> 2007/03/19

Hi,

[#10665] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — "Chris Carter" <cdcarter@...> 2007/03/20

On 3/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#10712] Ruby Method Signatures (was Re: Multiton in standard library) — "Rick DeNatale" <rick.denatale@...>

On 3/19/07, TRANS <transfire@gmail.com> wrote:

10 messages 2007/03/21
[#10715] Re: Ruby Method Signatures (was Re: Multiton in standard library) — Jos Backus <jos@...> 2007/03/22

On 3/19/07, TRANS <transfire@gmail.com> wrote:

[#10798] Virtual classes and 'real' classes -- why? — "John Lam (CLR)" <jflam@...>

I was wondering if someone could help me understand why there's a parallel =

12 messages 2007/03/28
[#10799] Re: Virtual classes and 'real' classes -- why? — MenTaLguY <mental@...> 2007/03/28

On Thu, 29 Mar 2007 04:44:16 +0900, "John Lam (CLR)" <jflam@microsoft.com> wrote:

Re: Bugfix: Extension Compile Error with 1.8.6

From: Lothar Scholz <mailinglists@...>
Date: 2007-03-14 11:10:54 UTC
List: ruby-core #10592
Hello Nobuyoshi,


NN> Although your compiler seems to be odd,

Well it's Microsoft, so it's odd by definition ;-)

NN> "thread" is a too common name

The german messages is telling me:
"Konstruktor mit Ergebnistyp oder unzulaessige Neudefinition eines
Klassennamens?" means "Constructor with result type or not allowed
redefinition of a classname"

and "Keine Elemente definiert, die diesen Typ verwenden" means
"no elements that use this type".

The only conclusion is that for some reasons it things that thread
is not the name part of the identifier declaration but the start of a
constructor. This is strange indeed.

But it's okay if you redefined it now. I wait for the first patch to
1.8.6


NN> anyway.  It should have been renamed as "rb_thread" or such when it'd
NN> been exposed, I guess.

NN> 
NN> Index: eval.c
NN> ===================================================================
NN> --- eval.c      (revision 12059)
NN> +++ eval.c      (working copy)
NN> @@ -244,6 +244,6 @@ static int scope_vmode;
NN>  #define SCOPE_TEST(f) (scope_vmode&(f))

NN> -VALUE (*ruby_sandbox_save)(struct thread *) = NULL;
NN> -VALUE (*ruby_sandbox_restore)(struct thread *) = NULL;
NN> +VALUE (*ruby_sandbox_save)(rb_thread_t) = NULL;
NN> +VALUE (*ruby_sandbox_restore)(rb_thread_t) = NULL;
NN>  NODE* ruby_current_node;
NN>  int ruby_safe_level = 0;
NN> @@ -9828,6 +9828,4 @@ extern VALUE rb_last_status;
NN>  #endif

NN> -/* typedef struct thread * rb_thread_t; */
NN> -
NN>  #define THREAD_RAISED 0x200     /* temporary flag */
NN>  #define THREAD_TERMINATING 0x400 /* persistent flag */
NN> @@ -9852,5 +9850,5 @@ struct thread_status_t {
NN>      int safe;

NN> -    enum thread_status status;
NN> +    enum rb_thread_status status;
NN>      int wait_for;
NN>      int fd;
NN> @@ -9954,5 +9952,5 @@ rb_trap_eval(cmd, sig, safe)
NN>  static const char *
NN>  thread_status_name(status)
NN> -    enum thread_status status;
NN> +    enum rb_thread_status status;
NN>  {
NN>      switch (status) {
NN> @@ -11012,5 +11010,5 @@ rb_thread_join(th, limit)
NN>      double limit;
NN>  {
NN> -    enum thread_status last_status = THREAD_RUNNABLE;
NN> +    enum rb_thread_status last_status = THREAD_RUNNABLE;

NN>      if (rb_thread_critical) rb_thread_deadlock();
NN> @@ -11395,5 +11393,5 @@ VALUE
NN>  rb_thread_stop()
NN>  {
NN> -    enum thread_status last_status = THREAD_RUNNABLE;
NN> +    enum rb_thread_status last_status = THREAD_RUNNABLE;

NN>      rb_thread_critical = 0;
NN> @@ -11659,5 +11657,5 @@ rb_thread_group(thread)

NN>  #define THREAD_ALLOC(th) do {\
NN> -    th = ALLOC(struct thread);\
NN> +    th = ALLOC(struct rb_thread);\
NN>  \
NN>      th->next = 0;\
NN> @@ -11824,5 +11822,5 @@ rb_thread_start_0(fn, arg, th)
NN>      volatile VALUE thread = th->thread;
NN>      struct BLOCK *volatile saved_block = 0;
NN> -    enum thread_status status;
NN> +    enum rb_thread_status status;
NN>      int state;

NN> Index: node.h
NN> ===================================================================
NN> --- node.h      (revision 12059)
NN> +++ node.h      (working copy)
NN> @@ -391,5 +391,5 @@ typedef jmp_buf rb_jmpbuf_t;
NN>  #endif

NN> -enum thread_status {
NN> +enum rb_thread_status {
NN>      THREAD_TO_KILL,
NN>      THREAD_RUNNABLE,
NN> @@ -398,8 +398,9 @@ enum thread_status {
NN>  };

NN> -typedef struct thread * rb_thread_t;
NN> +typedef struct rb_thread *rb_thread_t;
NN> +struct st_table;

NN> -struct thread {
NN> -    struct thread *next, *prev;
NN> +struct rb_thread {
NN> +    struct rb_thread *next, *prev;
NN>      rb_jmpbuf_t context;
NN>  #if (defined _WIN32 && !defined _WIN32_WCE) || defined __CYGWIN__
NN> @@ -442,5 +443,5 @@ struct thread {
NN>      int safe;

NN> -    enum thread_status status;
NN> +    enum rb_thread_status status;
NN>      int wait_for;
NN>      int fd;
NN> @@ -456,5 +457,5 @@ struct thread {
NN>      VALUE thgroup;

NN> -    st_table *locals;
NN> +    struct st_table *locals;

NN>      VALUE thread;
NN> @@ -463,6 +464,6 @@ struct thread {
NN>  };

NN> -extern VALUE (*ruby_sandbox_save)(struct thread *);
NN> -extern VALUE (*ruby_sandbox_restore)(struct thread *);
NN> +extern VALUE (*ruby_sandbox_save)(rb_thread_t);
NN> +extern VALUE (*ruby_sandbox_restore)(rb_thread_t);
NN>  extern rb_thread_t curr_thread;
NN>  extern rb_thread_t main_thread;
NN> 




-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's
 


In This Thread

Prev Next