[#1884] multiple exceptions for assert_raises — nobu.nokada@...

Hi,

14 messages 2003/12/04

[#1932] --enable-pthread broken? — Nathaniel Talbott <nathaniel@...>

[ruby-talk: 87759] and the surrounding thread seem to indicate that

29 messages 2003/12/11
[#1933] Re: --enable-pthread broken? — matz@... (Yukihiro Matsumoto) 2003/12/11

Hi,

[#1934] Re: --enable-pthread broken? — Nathaniel Talbott <nathaniel@...> 2003/12/11

On Dec 11, 2003, at 11:49, Yukihiro Matsumoto wrote:

[#1935] Re: --enable-pthread broken? — ts <decoux@...> 2003/12/11

>>>>> "N" == Nathaniel Talbott <nathaniel@talbott.ws> writes:

[#1937] Re: --enable-pthread broken? — nobu.nokada@... 2003/12/11

Hi,

[#1938] Re: --enable-pthread broken? — Nathaniel Talbott <nathaniel@...> 2003/12/12

On Dec 11, 2003, at 16:10, nobu.nokada@softhome.net wrote:

[#1939] Re: --enable-pthread broken? — matz@... (Yukihiro Matsumoto) 2003/12/12

Hi,

[#1941] Re: --enable-pthread broken? — matz@... (Yukihiro Matsumoto) 2003/12/12

Hi,

[#1943] Re: --enable-pthread broken? — Nathaniel Talbott <nathaniel@...> 2003/12/12

On Dec 11, 2003, at 20:48, Yukihiro Matsumoto wrote:

[#1953] Re: --enable-pthread broken? — matz@... (Yukihiro Matsumoto) 2003/12/13

Hi,

[#1959] Re: --enable-pthread broken? — ts <decoux@...> 2003/12/14

>>>>> "Y" == Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#1961] Re: --enable-pthread broken? — matz@... (Yukihiro Matsumoto) 2003/12/15

Hi,

[#1962] Re: --enable-pthread broken? — ts <decoux@...> 2003/12/15

>>>>> "Y" == Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#1936] Can't define +@ for Symbol (plus ruby install problem) — "T. Onoma" <transami@...>

I wanted to see if the +@ problem was fixed in 1.8.1 preview 3 but when I do

11 messages 2003/12/11

[#1973] Where to install documentation — Dave Thomas <dave@...>

Folks:

48 messages 2003/12/15
[#1982] Re: Where to install documentation — Eric Hodel <drbrain@...7.net> 2003/12/15

Dave Thomas (dave@pragprog.com) wrote:

[#1984] Re: Where to install documentation — Dave Thomas <dave@...> 2003/12/15

[#1991] Re: Where to install documentation — "Gavin Sinclair" <gsinclair@...> 2003/12/16

>

[#1992] Re: Where to install documentation — Dave Thomas <dave@...> 2003/12/16

[#2000] Re: Where to install documentation — Minero Aoki <aamine@...> 2003/12/16

Hi,

[#2002] Re: Where to install documentation — Dave Thomas <dave@...> 2003/12/16

[#2037] --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...>

I've finally been able to test my application under load using the

25 messages 2003/12/23
[#2038] Re: --enable-pthread still segfaults... — matz@... (Yukihiro Matsumoto) 2003/12/23

Hi,

[#2039] Re: --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...> 2003/12/23

On Dec 23, 2003, at 14:17, Yukihiro Matsumoto wrote:

[#2040] Re: --enable-pthread still segfaults... — matz@... (Yukihiro Matsumoto) 2003/12/23

Hi,

[#2041] Re: --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...> 2003/12/23

On Dec 23, 2003, at 14:34, Yukihiro Matsumoto wrote:

[#2042] Re: --enable-pthread still segfaults... — matz@... (Yukihiro Matsumoto) 2003/12/23

Hi,

[#2043] Re: --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...> 2003/12/23

On Dec 23, 2003, at 14:44, Yukihiro Matsumoto wrote:

[#2045] Re: --enable-pthread still segfaults... — matz@... (Yukihiro Matsumoto) 2003/12/23

Hi,

[#2046] Re: --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...> 2003/12/23

> I'm afraid you're using old configure file. Can you wipe off old

[#2049] Re: --enable-pthread still segfaults... — Nathaniel Talbott <nathaniel@...> 2003/12/23

On Dec 23, 2003, at 15:18, Nathaniel Talbott wrote:

[#2050] Re: --enable-pthread still segfaults... — matz@... (Yukihiro Matsumoto) 2003/12/23

In message "Re: --enable-pthread still segfaults..."

[#2122] Bad interaction between timeout.rb and --enable-pthread — Nathaniel Talbott <nathaniel@...>

Here's a testcase that shows the problem:

13 messages 2003/12/31
[#2123] sleep is broken with --enable-pthread [Was: Bad interaction between timeout.rb and --enable-pthread] — Nathaniel Talbott <nathaniel@...> 2003/12/31

I should have reduced it more before posting...

Re: Where to install documentation

From: "Gavin Sinclair" <gsinclair@...>
Date: 2003-12-16 04:09:04 UTC
List: ruby-core #1993
>> Using the standard install.rb, anything you include in a project's
>> "data"
>> directory will be installed to /usr/share/<package> or equivalent.
>>

[Dave:]
> I have to say I really dislike this: I know it's probably "standard",
> but is ends up spraying files all over the filesystem. It would seem so
> much more sensible to store files under a common subtree, so that
> removing Ruby from a system takes no more than an rm -rf. Having used
> OSX for I while, I guess I'm spoiled, but I'd really much, much rather
> keep the files local to the Ruby tree.

A fine sentiment.  As Mr Herre wrote, Perl provides a precedent for this,
although in that case it's because 'perldoc' always generates its output
from the code.

I dislike seeing 'doc' under a 'lib' directory; they are plainly separate
concerns, but I think there's a whole lot of precedent there (I am by no
means a Unix layout expert).  So that being the case, I want to see 'doc'
put as high in the directory tree as possible, not buried within a
heirachy.

'site_ruby' implies libraries, not documentation.  Not by its name, but by
its contents.  If we were to have 'site_ruby/1.8/docs', then we should
have 'site_ruby/1.8/lib', but we don't.  So rather than force everything
into 'site_ruby', I'd like to see (using $prefix == "/usr")

   /usr/lib/ruby/site_ruby/1.8/  <all sorts of user-installed packages>
   /usr/lib/ruby/1.8/            <standard library>
   /usr/lib/ruby/gems/           <RubyGems; self-contained packages, doc>
   /usr/lib/ruby/doc/ruby-1.8/   <all sorts of "standard Ruby docs">
   /usr/lib/ruby/doc/rake-0.3.1/ <Rake documentation>
   /usr/lib/ruby/doc/dbi-0.0.20/ <DBI documentation>
   /usr/lib/ruby/doc/extmath-0.1.0/ <extmath documentation>
   /usr/lib/ruby/doc/etc.        <etc.>

The philosophy here is that Ruby documentation is a high-enough concern to
warrant a high-level directory, making it easy for the user to browse and
answer the question "what Ruby documentation do I have available?".  Also,
the "dbi-0.0.20" documentation is independent of the *Ruby* version, so it
shouldn't be buried in 'site-ruby/1.8' somewhere.  In this point of view,
Ruby itself is just another unit of Ruby documentation, so "ruby-1.6" and
"ruby-1.8" live alongside "dbi-0.0.20", etc.

All this is meant by way of discussion, by the way.  If we can converge
on, and implement, a standard here, I won't be trying to get in the way. 
I would certainly like to know what people think, however.

Gavin




In This Thread