[#3113] Problem in RSS library, or problem in my blog :) — Dave Thomas <dave@...>
I've been trying to use the new RSS library to parse a number of
7 messages
2004/07/01
[#3136] Wrong rdoc formatting in {array,pack}.c — Johan Holmberg <holmberg@...>
7 messages
2004/07/05
[#3162] Re: [doc-patch] Wrong rdoc formatting in {array,pack}.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/09
Hello.
[#3170] Another rdoc formatting error in array.c
— Johan Holmberg <holmberg@...>
2004/07/10
[#3172] Re: [doc-patch] Another rdoc formatting error in array.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/12
Hello.
[#3141] rexml/validation/validationexception is missing. — nobu.nokada@...
Hi,
5 messages
2004/07/06
[#3154] Nonblocking socket connect - Win32 - 181 — "Jean-Francois Nadeau" <jean-francois.nadeau@...>
Hi,
4 messages
2004/07/08
[#3167] Inconsistent "call-seq" usage etc. — Johan Holmberg <holmberg@...>
7 messages
2004/07/09
[#3168] Re: [doc] Inconsistent "call-seq" usage etc.
— Dave Thomas <dave@...>
2004/07/09
[#3171] binding a URL to a label in RDoc — Ian Macdonald <ian@...>
Hello,
6 messages
2004/07/12
[#3199] Trying to understand \G — Dave Thomas <dave@...>
I'm being silly again, but I can't get \G to work with String.index. If
12 messages
2004/07/16
[#3213] Typo and grammar/style fixes for ext/win32ole/win32ole.c — Jos Backus <jos@...>
The attached patch attempts to create a more consistent style for error
4 messages
2004/07/19
[#3216] Re: Incident Analysis of the intrusion on helium.ruby-lang.org May 2004 — "Sean E. Russell" <ser@...>
Hi,
6 messages
2004/07/21
[#3228] Core support for Gems, and namespace — "Luke A. Kanies" <luke@...>
Hi all,
21 messages
2004/07/27
[#3229] Re: Core support for Gems, and namespace
— Dave Thomas <dave@...>
2004/07/27
[#3232] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Tue, 27 Jul 2004, Dave Thomas wrote:
[#3233] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/27
On Wednesday, July 28, 2004, 12:48:07 AM, Luke wrote:
[#3235] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Wed, 28 Jul 2004, Gavin Sinclair wrote:
[#3230] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/27
On Tue, 27 Jul 2004 11:39:08 +0900, Luke A. Kanies <luke@madstop.com> wrote:
[#3234] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Tue, 27 Jul 2004, Austin Ziegler wrote:
[#3238] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/27
On Wed, 28 Jul 2004 00:14:29 +0900, Luke A. Kanies <luke@madstop.com> wrote:
[#3243] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/28
On Wednesday, July 28, 2004, 3:23:46 AM, Austin wrote:
[#3248] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/28
On Wed, 28 Jul 2004 11:29:53 +0900, Gavin Sinclair
[#3249] Re: Core support for Gems, and namespace
— Mauricio Fern疣dez <batsman.geo@...>
2004/07/28
On Wed, Jul 28, 2004 at 11:29:53AM +0900, Gavin Sinclair wrote:
Re: [Patch] Move all stack info to gc.c
From:
nobu.nokada@...
Date:
2004-07-02 01:32:23 UTC
List:
ruby-core #3115
Hi,
At Fri, 2 Jul 2004 01:12:45 +0900,
Mathieu Bouchard wrote in [ruby-core:03114]:
> On Fri, 25 Jun 2004, Michal Rokos wrote:
> > On Thursday 24 of June 2004 22:23, Mathieu Bouchard wrote:
> > > On Wed, 23 Jun 2004, Yukihiro Matsumoto wrote:
> > > > I don't think so. Go ahead, or we will know if there's unseen
> > > > reason.
> > > If it's going to be global, it'd be better to have it start with the
> > > "rb_" prefix...
> > I assume you're talking about _stacksize...
>
> Oh yes, sorry for my un-clarity...
Ruby source never use it, but C runtime does. So it must be
exact that name and be kept unchanged.
> Another outstanding issue is that Ruby's support for embedding has a
> problem with ruby_init being done on a non-empty stack. It took me months
> to figure it out, and then I posted a fix a year ago... has anything been
> done about it while I was not looking? At least I can fix it from inside
> my own software using Init_stack and some black magic...
Do you mean [ruby-core:01229]? This is another easy way I'm
using, which works just for glibc, win32 (including cygwin) and
human68k.
Index: configure.in
===================================================================
RCS file: /cvs/ruby/src/ruby/configure.in,v
retrieving revision 1.240
diff -U2 -p -d -r1.240 configure.in
--- configure.in 28 Jun 2004 05:58:09 -0000 1.240
+++ configure.in 28 Jun 2004 14:13:59 -0000
@@ -390,4 +390,16 @@ AC_STRUCT_ST_BLOCKS
AC_STRUCT_ST_RDEV
+AC_CACHE_CHECK(for stack end address, rb_cv_stack_end_address,
+[rb_cv_stack_end_address=no
+for addr in __libc_stack_end _SEND; do
+ AC_TRY_LINK(
+ [extern void *$addr;],
+ [if (!$addr) return 1;],
+ [rb_cv_stack_end_address="$addr"; break])
+done])
+if test $rb_cv_stack_end_address != no; then
+ AC_DEFINE_UNQUOTED(STACK_END_ADDRESS, $rb_cv_stack_end_address)
+fi
+
dnl Checks for library functions.
AC_TYPE_GETGROUPS
Index: gc.c
===================================================================
RCS file: /cvs/ruby/src/ruby/gc.c,v
retrieving revision 1.180
diff -U2 -p -d -r1.180 gc.c
--- gc.c 29 Jun 2004 01:31:32 -0000 1.180
+++ gc.c 29 Jun 2004 15:45:13 -0000
@@ -45,4 +45,8 @@ extern unsigned long __libc_ia64_registe
#endif
+#if defined _WIN32 || defined __CYGWIN__
+#include <windows.h>
+#endif
+
void re_free_registers _((struct re_registers*));
int rb_io_fptr_finalize _((struct OpenFile*));
@@ -1409,7 +1413,14 @@ Init_stack(addr)
VALUE *addr;
{
-#if defined(__human68k__)
- extern void *_SEND;
- rb_gc_stack_start = _SEND;
+#if defined(_WIN32) || defined(__CYGWIN__)
+ MEMORY_BASIC_INFORMATION m;
+ memset(&m, 0, sizeof(m));
+ VirtualQuery(&m, &m, sizeof(m));
+ rb_gc_stack_start =
+ STACK_UPPER((VALUE *)&m, (VALUE *)m.BaseAddress,
+ (VALUE *)((char *)m.BaseAddress + m.RegionSize) - 1);
+#elif defined(STACK_END_ADDRESS)
+ extern void *STACK_END_ADDRESS;
+ rb_gc_stack_start = STACK_END_ADDRESS;
#else
if (!addr) addr = (VALUE *)&addr;
--
Nobu Nakada