[#19731] use of require thread safety — "Roger Pack" <rogerpack2005@...>

I'm sure this has been discussed before, but...should there be

56 messages 2008/11/08
[#19796] Re: use of require thread safety — Nobuyoshi Nakada <nobu@...> 2008/11/11

Hi,

[#21651] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2009/01/29

Nobuyoshi Nakada wrote:

[#19798] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/11/11

> While a thread is requiring a given file, another thread which

[#20732] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/12/20

> Currently with 1.8.7 (for me) the secondmost thread continues

[#20737] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/20

Roger Pack wrote:

[#20769] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/21

Charles Oliver Nutter wrote:

[#20795] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/12/22

On Mon, Dec 22, 2008 at 03:05:07AM +0900, Charles Oliver Nutter wrote:

[#19821] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/11/11

On Tue, Nov 11, 2008 at 10:51:45AM +0900, Nobuyoshi Nakada wrote:

[#19829] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Paul Brannan wrote:

[#19759] Proposal: Method#get_args — "Yehuda Katz" <wycats@...>

I'd like to propose a way to introspect into the arguments of a method

97 messages 2008/11/09
[#19787] Re: Proposal: Method#get_args — "Roger Pack" <rogerpack2005@...> 2008/11/11

The only question I have is why would one want to know the names of

[#19789] Re: Proposal: Method#get_args — Trans <transfire@...> 2008/11/11

On Nov 10, 7:18=A0pm, "Roger Pack" <rogerpack2...@gmail.com> wrote:

[#19818] Re: Proposal: Method#get_args — Mikael Hlund <mikael@...> 2008/11/11

Allow me to throw in my ~.116892074 DKK;

[#19837] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Mikael H淡ilund wrote:

[#19838] Re: Proposal: Method#get_args — Dave Thomas <dave@...> 2008/11/11

[#19870] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Wed, Nov 12, 2008 at 04:48:03AM +0900, Dave Thomas wrote:

[#19874] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Wed, Nov 12, 2008 at 06:01:40PM +0900, Brian Candler wrote:

[#19881] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19887] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Thu, Nov 13, 2008 at 02:06:15AM +0900, Charles Oliver Nutter wrote:

[#19889] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19892] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19893] Re: Proposal: Method#get_args — Jim Deville <jdeville@...> 2008/11/12

> -----Original Message-----

[#19894] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Thu, Nov 13, 2008 at 04:33:07AM +0900, Jim Deville wrote:

[#19895] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19896] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Jim Weirich wrote:

[#19899] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

On Nov 12, 2008, at 4:12 PM, Charles Oliver Nutter wrote:

[#19915] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/13

On Thu, Nov 13, 2008 at 07:02:25AM +0900, Jim Weirich wrote:

[#19927] Re: {Proc,Method}#parameters (Re: Proposal: Method#get_args) — Nobuyoshi Nakada <nobu@...> 2008/11/14

Hi,

[#19784] Status of copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

22 messages 2008/11/10
[#19799] Re: Status of copy-on-write friendly garbage collector — "Narihiro Nakamura" <authornari@...> 2008/11/11

Hi.

[#19812] Re: Status of copy-on-write friendly garbage collector — "Yehuda Katz" <wycats@...> 2008/11/11

Narihiro,

[#19823] Re: Status of copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/11/11

Hi,

[#19845] [Bug #743] Socket.gethostbyname returns odd values — Roger Pack <redmine@...>

Bug #743: Socket.gethostbyname returns odd values

11 messages 2008/11/11

[#19846] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...>

Bug #744: memory leak in callcc?

142 messages 2008/11/11
[#21394] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2009/01/17

Issue #744 has been updated by Roger Pack.

[#21429] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/19

[#21441] Re: [Bug #744] memory leak in callcc? — Nobuyoshi Nakada <nobu@...> 2009/01/19

Hi,

[#21483] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/21

[#21487] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/01/21

On Wednesday 21 of January 2009 10:21:19 Brent Roman wrote:

[#21711] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/02/01

[#22062] Re: [Bug #744] memory leak in callcc? — Roger Pack <rogerdpack@...> 2009/02/14

>> I've tried that myself but it didn't work very well

[#22265] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/02/19

On Saturday 14 of February 2009 08:17:22 Roger Pack wrote:

[#21514] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/22

[#19945] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2008/11/15

Issue #744 has been updated by Roger Pack.

[#19968] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19969] Re: [Bug #744] memory leak in callcc? — Martin Duerst <duerst@...> 2008/11/17

At 12:54 08/11/17, Brent Roman wrote:

[#19970] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19972] Re: [Bug #744] memory leak in callcc? — Kurt Stephens <kurt@...> 2008/11/17

A common technique is to allocate a reasonably sized array (256-bytes)

[#20149] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/28

[#20517] Re: Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/13

> I implemented a scheme for recording the maximum depth of the C stack in

[#20534] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/13

[#20750] [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20751] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Ezra Zygmuntowicz <ezmobius@...> 2008/12/21

[#20752] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20781] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/22

First thanks for doing all that hard work. I'm sure it's not pleasant

[#20783] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/22

[#20903] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/26

Seems to overall be a tidge slower for "micro" stuff--5 or 10%.

[#20914] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/27

[#20922] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/27

> You ran this benchmark suite, correct?

[#20931] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/28

[#20995] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/30

Hmm interesting.

[#21261] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Stephen Sykes" <sdsykes@...> 2009/01/11

Brent,

[#20168] Re: Promising C coding techniques to reduce MRI's memory use — Nobuyoshi Nakada <nobu@...> 2008/11/30

Hi,

[#20175] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/11/30

The problem can be demonstrated with a very simple program (attached), and

[#20178] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/30

[#20185] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/12/01

> What I did come up with was not ugly at all. Factor the unwieldy switch

[#19938] Fibers in 1.8 — "Aman Gupta" <rubytalk@...1.net>

Are there any plans to backport Fiber to ruby 1.8?

13 messages 2008/11/15

[#20008] [Bug #766] 'Not enough space' error on windows — Ittay Dror <redmine@...>

Bug #766: 'Not enough space' error on windows

17 messages 2008/11/20

[#20092] [Bug #797] bug or feature: local method ? — Francois Proulx <redmine@...>

Bug #797: bug or feature: local method ?

23 messages 2008/11/25
[#20097] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20098] Re: [Bug #797] bug or feature: local method ? — Dave Thomas <dave@...> 2008/11/25

[#20100] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20127] Re: [Bug #797] bug or feature: local method ? — Francoys <francois.pr@...> 2008/11/26

Yukihiro Matsumoto wrote:

[ruby-core:19701] Re: [Feature #695] More flexibility when combining ASCII-8BIT strings with other encodings

From: "Michael Selig" <michael.selig@...>
Date: 2008-11-05 05:03:38 UTC
List: ruby-core #19701
Hi,

I decided to put in a couple of hours to see if I could do a quick patch,  
and the result is attached.

The patch makes "ASCII-8BIT" like a "wild-card" encoding - compatible with  
any other encoding as long as it is valid if forced to that encoding. I  
added a warning that is displayed (with -w) when this happens.

I know I seem to be in the minority with this issue, but I think there are  
a lot of benefits:

- Less need to worry about the encoding of output strings from libraries  
and methods like "Array#pack"
- Less need to worry how "\xNN" string literals are handled
- In most cases simple, encoding-unaware scripts should work without the  
need for "force_encoding"
- Better compatibility with 1.8 scripts

As there seems to be a good likelihood that the patch will be rejected, I  
haven't tested it thoroughly, so I may have missed some things, in  
particular with REGEXPs.
Also I have not attempted to separate ASCII-8BIT & BINARY so that strings  
which are forced to BINARY cannot be converted. This may be a good idea.

Examples with the patch applied:

RUBYOPT=-w irb
/usr/local/lib/ruby/1.9.0/irb/context.rb:166: warning: method redefined;  
discarding old irb_name
irb(main):001:0> su = "abc\u0639"
=> "abc惺"
irb(main):002:0> sn = "abc\xD8\xB9"
=> "abc\xD8\xB9"
irb(main):003:0> su + sn
(irb):3: warning: Assuming ASCII-8BIT string is UTF-8
=> "abc惺abc惺"
irb(main):004:0> sn + su
(irb):4: warning: Assuming ASCII-8BIT string is UTF-8
=> "abc惺abc惺"
irb(main):005:0> sn == su
=> true
irb(main):006:0> su << sn
(irb):6: warning: Assuming ASCII-8BIT string is UTF-8
=> "abc惺abc惺"
irb(main):007:0> sn << su
=> "abc\xD8\xB9abc\xD8\xB9abc\xD8\xB9"

I am happy to put in more effort into this if I get positive feedback.
I think it is important because without something like this, there could  
be justifiable criticisms of the need for "force_encoding" and of poor  
backward compatibility with 1.8.

Cheers
Mike.


On Fri, 31 Oct 2008 15:42:55 +1100, Nobuyoshi Nakada <nobu@ruby-lang.org>  
wrote:

> Hi,
>
> At Fri, 31 Oct 2008 07:14:21 +0900,
> Michael Selig wrote in [ruby-core:19646]:
>> Feature #695 was closed & marked done, but unfortunately it does not  
>> seem
>> to have been implemented :-(
>
> Martin kindly replied already, so I don't have to add his post
> so much.
>
>> If you agree that this is a good idea, I don't mind trying to produce a
>> patch for it myself. Please let me know.
>
> I don't agree, but feel free to post your patch, of course.
>
------------32fHXckHKr4KOkSKFCDLAF
Content-Disposition: attachment; filename=ascii-8bit.pat
Content-Type: application/octet-stream; name=ascii-8bit.pat
Content-Transfer-Encoding: Base64

SW5kZXg6IGVuY29kaW5nLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZW5jb2Rp
bmcuYwkocmV2aXNpb24gMjAxMTIpCisrKyBlbmNvZGluZy5jCSh3b3JraW5nIGNv
cHkpCkBAIC02MTksNiArNjE5LDE2IEBACiAJcmJfcmFpc2UocmJfZUVuY0NvbXBh
dEVycm9yLCAiaW5jb21wYXRpYmxlIGNoYXJhY3RlciBlbmNvZGluZ3M6ICVzIGFu
ZCAlcyIsCiAJCSByYl9lbmNfbmFtZShyYl9lbmNfZ2V0KHN0cjEpKSwKIAkJIHJi
X2VuY19uYW1lKHJiX2VuY19nZXQoc3RyMikpKTsKKyAgICBlbHNlIGlmIChSVEVT
VChydWJ5X3ZlcmJvc2UpKSB7CisJaW50IGlkeDEgPSByYl9lbmNfZ2V0X2luZGV4
KHN0cjEpOworCWludCBpZHgyID0gcmJfZW5jX2dldF9pbmRleChzdHIyKTsKKwor
CWlmIChpZHgxICE9IGlkeDIgJiYgKGlkeDEgPT0gRU5DSU5ERVhfQVNDSUkgfHwg
aWR4MiA9PSBFTkNJTkRFWF9BU0NJSSkKKwkgICAgJiYgKHJiX2VuY19zdHJfY29k
ZXJhbmdlKHN0cjEpICE9IEVOQ19DT0RFUkFOR0VfN0JJVCB8fAorCQlyYl9lbmNf
c3RyX2NvZGVyYW5nZShzdHIyKSAhPSBFTkNfQ09ERVJBTkdFXzdCSVQpKQorCSAg
ICByYl93YXJuaW5nKCJBc3N1bWluZyBBU0NJSS04QklUIHN0cmluZyBpcyAlcyIs
CisJCQlyYl9lbmNfbmFtZShyYl9lbmNfZ2V0KGlkeDIgPT0gRU5DSU5ERVhfQVND
SUkgPyBzdHIxIDogc3RyMikpKTsKKyAgICB9CiAgICAgcmV0dXJuIGVuYzsKIH0K
IApAQCAtNjgwLDYgKzY5MCwxMyBAQAogCX0KIAlpZiAoY3IxID09IEVOQ19DT0RF
UkFOR0VfN0JJVCkKIAkgICAgcmV0dXJuIGVuYzI7CisKKwlpZiAoaWR4MSA9PSBF
TkNJTkRFWF9BU0NJSSAmJgorCQlyYl9lbmNfc3RyX3ZhbGlkX2VuY29kaW5nKHN0
cjEsIGVuYzIpID09IFF0cnVlKQorCSAgICByZXR1cm4gZW5jMjsKKwlpZiAoaWR4
MiA9PSBFTkNJTkRFWF9BU0NJSSAmJiBCVUlMVElOX1RZUEUoc3RyMikgPT0gVF9T
VFJJTkcgJiYKKwkJcmJfZW5jX3N0cl92YWxpZF9lbmNvZGluZyhzdHIyLCBlbmMx
KSA9PSBRdHJ1ZSkKKwkgICAgcmV0dXJuIGVuYzE7CiAgICAgfQogICAgIHJldHVy
biAwOwogfQpJbmRleDogc3RyaW5nLmMKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g
c3RyaW5nLmMJKHJldmlzaW9uIDIwMTEyKQorKysgc3RyaW5nLmMJKHdvcmtpbmcg
Y29weSkKQEAgLTMyNSw2ICszMjUsMTMgQEAKICAgICByZXR1cm4gY3I7CiB9CiAK
K1ZBTFVFCityYl9lbmNfc3RyX3ZhbGlkX2VuY29kaW5nKFZBTFVFIHN0ciwgcmJf
ZW5jb2RpbmcgKmVuYykKK3sKKyAgICBpbnQgY3IgPSBjb2RlcmFuZ2Vfc2NhbihS
U1RSSU5HX1BUUihzdHIpLCBSU1RSSU5HX0xFTihzdHIpLCBlbmMpOworICAgIHJl
dHVybiBjciA9PSBFTkNfQ09ERVJBTkdFX0JST0tFTiA/IFFmYWxzZSA6IFF0cnVl
OworfQorCiBpbnQKIHJiX2VuY19zdHJfYXNjaWlvbmx5X3AoVkFMVUUgc3RyKQog
ewpAQCAtMTcxNSwxMCArMTcyMiwxNyBAQAogICAgIGlmIChzdHJfZW5jaW5kZXgg
IT0gcHRyX2VuY2luZGV4ICYmCiAgICAgICAgIHN0cl9jciAhPSBFTkNfQ09ERVJB
TkdFXzdCSVQgJiYKICAgICAgICAgcHRyX2NyICE9IEVOQ19DT0RFUkFOR0VfN0JJ
VCkgeworCS8qIFRyZWF0IEFTQ0lJLThCSVQgc3BlY2lhbGx5ICovCisJaWYgKHB0
cl9hOCAmJiBjb2RlcmFuZ2Vfc2NhbihwdHIsIGxlbiwgcmJfZW5jX2Zyb21faW5k
ZXgoc3RyX2VuY2luZGV4KSkgIT0gRU5DX0NPREVSQU5HRV9CUk9LRU4pIHsKKwkg
ICAgcmJfd2FybmluZygiQXNzdW1pbmcgQVNDSUktOEJJVCBzdHJpbmcgaXMgJXMi
LAorCQkJcmJfZW5jX25hbWUocmJfZW5jX2Zyb21faW5kZXgoc3RyX2VuY2luZGV4
KSkpOworCX0KKwllbHNlIGlmICghc3RyX2E4KSB7CiAgICAgICBpbmNvbXBhdGli
bGU6Ci0gICAgICAgIHJiX3JhaXNlKHJiX2VFbmNDb21wYXRFcnJvciwgImluY29t
cGF0aWJsZSBjaGFyYWN0ZXIgZW5jb2RpbmdzOiAlcyBhbmQgJXMiLAotICAgICAg
ICAgICAgcmJfZW5jX25hbWUocmJfZW5jX2Zyb21faW5kZXgoc3RyX2VuY2luZGV4
KSksCi0gICAgICAgICAgICByYl9lbmNfbmFtZShyYl9lbmNfZnJvbV9pbmRleChw
dHJfZW5jaW5kZXgpKSk7CisJICAgIHJiX3JhaXNlKHJiX2VFbmNDb21wYXRFcnJv
ciwgImluY29tcGF0aWJsZSBjaGFyYWN0ZXIgZW5jb2RpbmdzOiAlcyBhbmQgJXMi
LAorCQlyYl9lbmNfbmFtZShyYl9lbmNfZnJvbV9pbmRleChzdHJfZW5jaW5kZXgp
KSwKKwkJcmJfZW5jX25hbWUocmJfZW5jX2Zyb21faW5kZXgocHRyX2VuY2luZGV4
KSkpOworCX0KICAgICB9CiAKICAgICBpZiAoc3RyX2NyID09IEVOQ19DT0RFUkFO
R0VfVU5LTk9XTikgewpAQCAtMjA0OCw2ICsyMDYyLDggQEAKICAgICBpZHgxID0g
RU5DT0RJTkdfR0VUKHN0cjEpOwogICAgIGlkeDIgPSBFTkNPRElOR19HRVQoc3Ry
Mik7CiAgICAgaWYgKGlkeDEgPT0gaWR4MikgcmV0dXJuIFF0cnVlOworICAgIC8q
IEFsbG93IGNvbXBhcmlzb25zIGJldHdlZW4gQVNDSUktOEJJVCAmIG90aGVyIGVu
Y29kaW5ncyAqLworICAgIGlmIChpZHgxID09IDAgfHwgaWR4MiA9PSAwKSByZXR1
cm4gUXRydWU7CiAgICAgcmMxID0gcmJfZW5jX3N0cl9jb2RlcmFuZ2Uoc3RyMSk7
CiAgICAgcmMyID0gcmJfZW5jX3N0cl9jb2RlcmFuZ2Uoc3RyMik7CiAgICAgaWYg
KHJjMSA9PSBFTkNfQ09ERVJBTkdFXzdCSVQpIHsK

------------32fHXckHKr4KOkSKFCDLAF--


In This Thread

Prev Next