General

Profile

dbussink (Dirkjan Bussink)

  • Login: dbussink
  • Email: d.bussink@gmail.com
  • Registered on: 05/19/2009
  • Last sign in: 07/20/2015

Issues

open closed Total
Assigned issues 0 0 0
Reported issues 0 4 4

Activity

09/23/2014

06:21 PM Ruby Bug #10285: StringIO with encodings broken due to #9769
As another data point, I also tried this with writing to a file which seems to work:
~~~
File.open("out.txt", :mode => "w", :encoding => Encoding::ASCII_8BIT) do |f|
str1 = "quz \x83 mat".force_encoding(Encoding::ASCII_8BIT)
f....
dbussink (Dirkjan Bussink)
11:29 AM Ruby Bug #10285 (Closed): StringIO with encodings broken due to #9769
It looks like the change in https://bugs.ruby-lang.org/issues/9769 resulted in a behavior change with how StringIO works with different encodings.
The following snippet is broken and now raises:
~~~
test_string_io_encoding.rb:8:i...
dbussink (Dirkjan Bussink)

06/13/2014

11:31 AM Ruby Bug #9934: High memory usage from file_expand_path_*
Thanks for the fix! dbussink (Dirkjan Bussink)

06/12/2014

11:40 AM Ruby Bug #9934: High memory usage from file_expand_path_*
This does actually not fix the bug. This only works if a path expanded by File.expand_path is smaller than the string embedded length. If a string is longer than that length, it isn't made smaller and it still uses up too much memory. dbussink (Dirkjan Bussink)

01/24/2014

07:55 PM Ruby Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults
First of all thanks to Martin for working on the white list. I still believe specifying defaults here is the best of bad choices to make.
Regarding defaults on OS X, tools like RVM, rbenv and chruby are used a lot. All either build O...
dbussink (Dirkjan Bussink)

01/22/2014

10:59 AM Ruby Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults
Yusuke Endoh wrote:
> Please give us not only words but also a concrete plan.
As said in the original mailing list, I'm more than willing to maintain this list for Ruby.
> ...
Actually OpenSSL already provides information on ...
dbussink (Dirkjan Bussink)

06/10/2013

07:14 PM Ruby Bug #8399: Remove usage of RARRAY_PTR in C extensions when not needed
Eregon (Benoit Daloze) wrote:
> Could you share that benchmark?
> ...
This was not against a sole benchmark of this. What I meant with the statement is that this difference was never measurable in benchmarks of code using a C extensi...
dbussink (Dirkjan Bussink)

06/08/2013

06:47 PM Ruby Bug #8399: Remove usage of RARRAY_PTR in C extensions when not needed
I've attached an updated version of the patch that uses rb_ary_subseq instead of manually creating an array. That means it could be implemented in an efficient way under the hood here in different implementations. dbussink (Dirkjan Bussink)
05:57 PM Ruby Bug #8399: Remove usage of RARRAY_PTR in C extensions when not needed
Eregon (Benoit Daloze) wrote:
> I guess it is mostly fine, but what about the for loop instead of rb_ary_new4() (which is memcpy()).
> ...
The problem is not rb_ary_new4 itself, but that RARRAY_PTR needs to be called before. Since ther...
dbussink (Dirkjan Bussink)
01:52 AM Ruby Bug #8399: Remove usage of RARRAY_PTR in C extensions when not needed
Besides the discussion about the exact approach for the future, is it possible to merge in the originally proposed patch for racc? Or are there any reasons why this can't / should not happen? dbussink (Dirkjan Bussink)

Also available in: Atom