hsbt_away changed the topic of #ruby-core to: check the latest release candidate for 1.9.1 release ftp.ruby-lang.org:/home/yugui/ruby-1.9.1-r26021+1.tar.bz2
kosaki2 has joined #ruby-core
nokada has joined #ruby-core
<nokada> drbrain: do you have test cases?
<drbrain> nokada: yes!
<drbrain> I can commit them, too
<drbrain> nokada: but I think you should review to see if my new behavior for bad input is OK
shiba___ has joined #ruby-core
hsbt has quit [Ping timeout: 258 seconds]
<drbrain> oh, I forgot to submit the tests
hsbt has joined #ruby-core
<drbrain> nokada: I added the correct patch, including tests: http://bugs.ruby-lang.org/attachments/3940/optparse.rb.accept.2.patch
tenderlo_ has quit [Remote host closed the connection]
<nokada> DecimalInteger needs parentheses?
shiba___ has quit [Ping timeout: 264 seconds]
<drbrain> nokada: it allows --decimal-integer 1234xyz to have the value 1234
<drbrain> since the regular expression does not use \z
<drbrain> it seemed that allowing 1234xyz as input was intentional
<nokada> hmmm?
<nokada> I can't remember...
<drbrain> it is a very old bug :D
nagachika has joined #ruby-core
<nokada> it doesn't seem intentional
<drbrain> I think each regexp should use \z, then
<nokada> indeed
charliesome has joined #ruby-core
hsbt has quit [Read error: Connection reset by peer]
hsbt_ has joined #ruby-core
<drbrain> bus time, later‼
nari has joined #ruby-core
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<_ko1> charliesome: r42836
<_ko1> ah, seq is uniq for each class
charliesome has joined #ruby-core
<znz_jp> biff: [ruby-changes:30762] charliesome:r42841 (trunk): * vm_insnhelper.c (vm_getivar): use class sequence to check class - http://mla.n-z.jp/?ruby-changes=30762
Domon has joined #ruby-core
headius has quit [Quit: headius]
shinnya has quit [Ping timeout: 268 seconds]
tylersmith has joined #ruby-core
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
charliesome has joined #ruby-core
soraher is now known as sorah_
sorah_ is now known as soraher
<nokada> drbrain: seems fine, and add tests 1234xyz fails, plz
hsbt_ has quit [Ping timeout: 268 seconds]
hsbt_ has joined #ruby-core
headius has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
<znz_jp> biff: [ruby-changes:30763] mrkn:r42842 (trunk): * configure.in (with_gmp): set with_gmp no if it is empty. - http://mla.n-z.jp/?ruby-changes=30763
kosaki2 has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
Domon has quit [Remote host closed the connection]
Domon has joined #ruby-core
Domon has quit [Ping timeout: 264 seconds]
<drbrain> nokada: OK!
<znz_jp> biff: [ruby-changes:30764] charliesome:r42843 (trunk): * include/ruby/ruby.h: add RSTRING_FSTR flag - http://mla.n-z.jp/?ruby-changes=30764
<znz_jp> biff: [ruby-changes:30765] drbrain:r42844 (trunk): * lib/optparse.rb: The Integer acceptable now allows binary and - http://mla.n-z.jp/?ruby-changes=30765
<znz_jp> biff: [ruby-changes:30766] nobu:r42845 (trunk): * properties. - http://mla.n-z.jp/?ruby-changes=30766
Domon has joined #ruby-core
corundum has quit [Quit: okay bye]
hsbt_ has quit [Ping timeout: 268 seconds]
hsbt_ has joined #ruby-core
DanKnox is now known as DanKnox_away
headius has quit [Quit: headius]
tylersmith has quit [Remote host closed the connection]
tylersmith has joined #ruby-core
tylersmith has quit [Read error: Connection reset by peer]
tylersmith has joined #ruby-core
tylersmith has quit [Ping timeout: 268 seconds]
marcandre has quit [Remote host closed the connection]
hsbt_ has quit [Ping timeout: 240 seconds]
hsbt_ has joined #ruby-core
hsbt_ is now known as hsbt_away
hsbt_away is now known as hsbt
hsbt has quit [Quit: Tiarra 0.1+svn-39209: SIGTERM received; exit]
hsbt has joined #ruby-core
corundum has joined #ruby-core
<_ko1> charliesome: hello
<charliesome> _ko1: howdy
<_ko1> i read your last commit "foo"f.object_id == "foo"f.object_id
<charliesome> _ko1: yep
<_ko1> when I read it, i think it is Symbol
<_ko1> I'm afraid that similar two features confuse users.
<_ko1> What do you think about?
<charliesome> i see your concern
<_ko1> IMO, best solution is to merge Symbol and String
<_ko1> and remove "foo"f and use :foo
<charliesome> but I'm not sure if users will be that confused
<charliesome> "foo"f.object_id == "foo"f.object_id is an implementation detail
<_ko1> i see.
<nokada> agree that it is a detail
<charliesome> it doesn't affect behaviour if the object ids are not equal
<charliesome> but if we can deduplicate frozen strings, it may lower memory usage in some cases
<nokada> so I thought it doesn't need testing
<charliesome> especially in larger rails apps
<charliesome> nokada: maybe we should have "implementation detail" tests
<charliesome> because I want to test that MRI does this, but maybe other implementations do not care about it
<nokada> well, we've such "tests" much already
<nokada> now I think it's bad
<charliesome> i agree that it is confusing what is spec and what is implementation detail
<charliesome> but i think we should test implementation details in MRI, even if it is not spec
<charliesome> for example if I write code that deduplicates strings, I want to know if I have accidentally broken it
<_ko1> charliesome: i understand.
<_ko1> nobu's concern is spec or not.
<_ko1> my concern is to introduce suffix f syntax (confusing or not)
<_ko1> what do you think about merging Symbol and String?
<_ko1> if we can, we only need :foo
<_ko1> such proposal (merging Symbol and String) was rejected with trial.
<charliesome> _ko1: I'm not sure about merging symbol and string
<charliesome> for two reasons:
<charliesome> ("foo" + "bar").object_id != "foobar".object_d
<_ko1> yes
<charliesome> oops
<charliesome> ("foo" + "bar").freeze.object_id != "foobar"f.object_id
<_ko1> ah, yes.
<charliesome> also
<_ko1> %f(foo)
<charliesome> lots of libraries use symbols and strings to mean different things
<_ko1> sorry, mis typing
<charliesome> for example bundler supports 'source :rubygems' and 'source "http://rubygems.org"'
<charliesome> the :rubygems symbol is a symbolic representation of a string
<_ko1> i see
<nokada> what does 'source :rubygems'?
<charliesome> nokada: 'source :rubygems' in bundler means the same as 'source "http://rubygems.org"'
<nokada> `source :foo' means 'source "http://foo.org"' ?
<charliesome> nokada: no, :rubygems is special case
<nokada> it's fine
<_ko1> charliesome: let us back to the basic. your concern is to improve performance.
<_ko1> by reducing generating String objects
<charliesome> _ko1: yes
<_ko1> did you measure performance?
<charliesome> _ko1: not directly, but I often see many string objects on the heap with identical contents
<_ko1> I see.
<charliesome> let me check
<_ko1> There are two main reasons
<dbussink> btw, rubinius does sharing of strings, i guess kind of how mri does for array's
<dbussink> so we only dup actual string contents if it changes etc.
<dbussink> just fyi
<charliesome> _ko1: on the github app:
<charliesome> ObjectSpace.each_object(String).to_a.uniq.count # => 148114
<charliesome> ObjectSpace.each_object(String).count # => 386809
<_ko1> (1) object counts -> affect GC count
<_ko1> (2) duplicate String body (RSTRING_PTR(str)) -> memory consumption
<_ko1> f suffix solve (1) and (2)
<charliesome> yes
<_ko1> CoW sharing string ptr (we already use on String#dup) solve (2)
<_ko1> and RGenGC reduce impact of (1)
<_ko1> only *reduce*.
<_ko1> we planned to make more aggressive (2)
<_ko1> BTW.
<_ko1> so, my opinion is
<_ko1> if impact of (1) is small, then frozen suffix is overkill
<_ko1> > I'm afraid that similar two features confuse users.
<_ko1> tradeoff: (a) performance improvement and (b) beutiful syntax
<dbussink> isn't this something where it's good to say to measure is to know?
<dbussink> how big is the advantage and is that worth it?
<_ko1> i agreed your proposal because I don't notice the disadvantage of (b)
<_ko1> s/don't/didn't/
<_ko1> dbussink: more easy sentense please!!
<dbussink> _ko1: well, what i'm saying is that if the goal is performance
<dbussink> that should be measured
<_ko1> i agree.
<_ko1> easy English yay!
<charliesome> _ko1: i think most of the benefit of frozen strings will not be in user code, but in generated code
<charliesome> like erb
<_ko1> i see.
<charliesome> erb templates have a lot of static strings that have to be duped every time
<charliesome> _ko1: even with CoW sharing solving (2), it is still significantly faster to use f-strings instead of relying on CoW
<charliesome> twice as fast in my measurements
<charliesome> with GC.disable so we do not care about extra GC time
<_ko1> ERb simulation benchmark
<_ko1> CoW is worst LoL
<charliesome> interesting results
<charliesome> brb
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<_ko1> "same object" simulates f string
<_ko1> x1.5 for specific application
<_ko1> however, ERb can make same optimization w/o f string
<_ko1> this is weak point for your opinion
<_ko1> but easy way to make such optimization
<_ko1> with f literal
<_ko1> same result of "same object"
<_ko1> ruby 2.1.0dev (2013-09-05 trunk 42845) [x86_64-linux]
<_ko1> user system total real
<_ko1> normal literal 4.290000 0.010000 4.300000 ( 4.306291)
<_ko1> f literal 3.370000 0.010000 3.380000 ( 3.377195)
<_ko1> same object 3.430000 0.000000 3.430000 ( 3.429297)
<_ko1> 26% faster on x64 Linux
<_ko1> Anyway, I'll post this discussion on ruby-core mailing list
<_ko1> ah, charliesome is not available
<znz_jp> biff: [ruby-changes:30767] nobu:r42846 (trunk): string.c: reduce objects in rb_fstring - http://mla.n-z.jp/?ruby-changes=30767
harrow has quit [Ping timeout: 245 seconds]
harrow has joined #ruby-core
closer has joined #ruby-core
nari has quit [Ping timeout: 264 seconds]
closer009 has quit [*.net *.split]
wudofyr has quit [Ping timeout: 245 seconds]
<dbussink> _ko1: can i ask you a question about RTYPEDDATA?
<dbussink> especially about how it relates to DATA_PTR
wudofyr has joined #ruby-core
charliesome has joined #ruby-core
<_ko1> dbussink: sure
<dbussink> _ko1: so, there's RDATA() and RTYPEDDATA() to get the internal structs
<dbussink> but doing RDATA() on something that is a typed data is invalid right?
<_ko1> yes
<_ko1> ah
<_ko1> wait
<_ko1> #define DATA_PTR(dta) (RDATA(dta)->data)
<dbussink> right
<dbussink> i think it works kind of by accident because the third element is the data for both types
<_ko1> now,
<_ko1> it is compatibile
<_ko1> s/it is/they are/
<dbussink> i'm working on adding this to the rubinius c-api
<_ko1> you are right.
<_ko1> it is intentional
<dbussink> ok, so it means i probably have to make DATA_PTR point to a function in rubinius
<dbussink> because we can't do it like this because of type checks
<dbussink> and have the function check both the data and typed data type
<_ko1> maybe people use DATA_PTR()
<_ko1> #define DATA_PTR(dta) (RDATA(dta)->data)
<_ko1> i see
<dbussink> i'll probably do something like #define DATA_PTR(dta) (capi_rdata_data_ptr(dta) and implement the logic in capi_rdata_data_ptr then
<dbussink> to support the different types
<dbussink> _ko1: is there a reason that there is no RUBY_T_TYPEDDATA ?
<dbussink> but that uses the same type as DATA?
<_ko1> i don't want to increase another type
<dbussink> ok :s
<dbussink> since it behaves differently in all other places
<_ko1> and i think all of T_DATA should move to T_TYPEDDATA
<_ko1> the purpose of T_DATA and T_TYPEDDATA is same
<_ko1> exntended version of T_DATA
<dbussink> _ko1: is there a way to see the difference between a T_DATA or T_TYPEDDATA for a given object?
<dbussink> whether it's one or the other?
<_ko1> so T_TYPEDDATA is a part of T_DATA
<dbussink> if you don't know the type in the code that calls it?
<znz_jp> biff: [ruby-changes:30768] charliesome:r42847 (trunk): * string.c (fstring_cmp): take string encoding into account when - http://mla.n-z.jp/?ruby-changes=30768
<_ko1> #define RTYPEDDATA_P(v) (RTYPEDDATA(v)->typed_flag == 1)
<dbussink> right, but that would reinterpret the struct right?
<_ko1> re-interpret
<dbussink> but it assumes that for RDATA the free function never would have 1 as the value right
<_ko1> ?
<_ko1> yes.
<_ko1> your are right
<dbussink> :(
<dbussink> random reinterpretations like that make it really hard to support this stuff :(
<_ko1> sorry i don't know what is "random reinterpretations"
<dbussink> well, you interpret something that is an RDATA struct as a RTYPEDATA Struct
<dbussink> which puts restrictions on what they can be
<dbussink> so it makes it harder to support the same api in rubinius
<_ko1> i recommend that
<dbussink> recommend what?
<_ko1> only support getter for free/mark/type
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<_ko1> for T_DATA (and T_TYPEDDATA)
<_ko1> ah. and getter for data.
<dbussink> not sure what you mean
<dbussink> not support RTYPEDDATA_P?
<dbussink> problem is that we can't really decide that
<dbussink> since it's in mri people use it
<dbussink> so we have to support it
<dbussink> it's often not a choice for us
<_ko1> ah, i see
<_ko1> and i don't understand your problem yet.
<_ko1> what the problem checking it in dynamic
<dbussink> well, it means we also have to create compatible struct layouts
<dbussink> and can't use something that would work better for us
<_ko1> yes/
<_ko1> why you cant use same definition?
<dbussink> because rdata and rtypeddata are different but also not
<dbussink> well, i have to now
<dbussink> i was looking at something else that was easier for us to implement this
<_ko1> i feel current MRI implementation is easy.
<_ko1> maybe some problem are there in rubinius to support it.
<dbussink> well, i guess it's easy for mri yes
<dbussink> but reinterpreting types etc. in general will often lead to problems i think
<dbussink> because it makes things not explicit
<dbussink> and forces certain models to be followed
<_ko1> maybe we don't share the type/data model.
<dbussink> exactly, but these details force a compatibility layer for that
<dbussink> that's exactly my point :)
<dbussink> ideally i would wish the RDATA or RDATATYPED struct was not part of the api at all
<dbussink> and everything would work through just using functions
<dbussink> so the implementation details stay hidden
<_ko1> i can undersntad.
<_ko1> sorry i need to go meeting
<_ko1> maybe i need to know more.
<dbussink> no problem, thanks for the answers!
soba has quit [Ping timeout: 245 seconds]
wudofyr has quit [Ping timeout: 264 seconds]
shiba___ has joined #ruby-core
wudofyr has joined #ruby-core
nari has joined #ruby-core
shiba___ has quit [Ping timeout: 246 seconds]
Domon has quit [Remote host closed the connection]
Domon has joined #ruby-core
Domon has quit [Ping timeout: 240 seconds]
marcandre has joined #ruby-core
closer has quit [Ping timeout: 260 seconds]
closer has joined #ruby-core
nagachika has quit [Remote host closed the connection]
hsbt has quit [Ping timeout: 264 seconds]
nokada has quit [Remote host closed the connection]
nokada has joined #ruby-core
hsbt has joined #ruby-core
nagachika has joined #ruby-core
enebo has joined #ruby-core
ahegyi_ has joined #ruby-core
corundum has quit [Read error: Connection reset by peer]
charliesome has joined #ruby-core
nari has quit [Ping timeout: 264 seconds]
ahegyi_ has quit [Ping timeout: 276 seconds]
ahegyi_ has joined #ruby-core
<znz_jp> biff: [ruby-changes:30769] nobu:r42848 (trunk): class.c: remove recursion - http://mla.n-z.jp/?ruby-changes=30769
<znz_jp> biff: [ruby-changes:30770] svn:r42849 (trunk): * 2013-09-06 - http://mla.n-z.jp/?ruby-changes=30770
headius has joined #ruby-core
shinnya has joined #ruby-core
corundum has joined #ruby-core
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
charliesome has joined #ruby-core
tylersmith has joined #ruby-core
tylersmith has quit [Remote host closed the connection]
enebo has quit [Quit: enebo]
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
charliesome has joined #ruby-core
hsbt has quit [Ping timeout: 260 seconds]
hsbt has joined #ruby-core
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
DanKnox_away is now known as DanKnox
nagachika has quit [Remote host closed the connection]
hsbt has quit [Ping timeout: 276 seconds]
hsbt has joined #ruby-core
<znz_jp> biff: [ruby-changes:30771] tenderlove:r42850 (trunk): * ext/psych/lib/psych/visitors/yaml_tree.rb: use double quotes when - http://mla.n-z.jp/?ruby-changes=30771
DanKnox is now known as DanKnox_away
r0bgl33s0n has quit [Quit: WeeChat 0.4.1]
DanKnox_away is now known as DanKnox
tenderlove has joined #ruby-core
enebo has joined #ruby-core
rrpy has joined #ruby-core
rrpy is now known as rrmartins
corundum has quit [Read error: Connection reset by peer]
pumper has joined #ruby-core
pumper has left #ruby-core ["Leaving"]
rrmartins has quit [Remote host closed the connection]
tenderlove has quit [Remote host closed the connection]
nokada has quit [Remote host closed the connection]
marcandr_ has joined #ruby-core
marcandre has quit [Read error: Connection reset by peer]
marcandr_ has quit [Read error: Connection reset by peer]
marcandre has joined #ruby-core
DanKnox is now known as DanKnox_away
tenderlove has joined #ruby-core
ahegyi_ has quit [Read error: Operation timed out]
r0bgleeson has joined #ruby-core
tylersmith has joined #ruby-core
enebo has quit [Quit: enebo]
corundum has joined #ruby-core
corundum has quit [Quit: seeya]
corundum has joined #ruby-core
DanKnox_away is now known as DanKnox
samsaffron has joined #ruby-core
<samsaffron> does anyone know how memsize_of is meant to work ?
<samsaffron> irb(main):005:0> ObjectSpace.memsize_of("hello")
<samsaffron> => 0
<drbrain> samsaffron: I think you need to compile with a flag to enable it
<samsaffron> aha
<samsaffron> oddly though:
<samsaffron> irb(main):011:0> ObjectSpace.memsize_of(String)
<samsaffron> => 6248
<drbrain> maybe I'm thinking of a different thing then
<drbrain> I'm thinking of CALC_EXACT_MALLOC_SIZE which may do something different
enebo has joined #ruby-core
<samsaffron> its embedded strings
<samsaffron> irb(main):032:0> ObjectSpace.memsize_of("a"*23)
<samsaffron> => 0
<samsaffron> => 24
<samsaffron> irb(main):033:0> ObjectSpace.memsize_of("a"*24)
<drbrain> oh, right!
<samsaffron> though embedded strings still take up memory, so I need to estimate something there
<drbrain> you need to know the size of a struct RObject { }
<drbrain> you can probably use a fixed value based on ObjectSpace.memsize_of("a"*23)
<drbrain> if you can embed 23 characters you have a 64 bit machine, otherwise 32 bit
marcandre has quit [Remote host closed the connection]
nari has joined #ruby-core
nari has quit [Ping timeout: 264 seconds]
<samsaffron> oh my
<samsaffron> can no think of any other way of getting the size of RVALUE
<drbrain> samsaffron: you can calculate it from C and pick the 64 bit or 32 bit size based on how much string you can embed
<samsaffron> I am not sure I want to ship a c extension with my memory profiler :(
<drbrain> you don't need to
<drbrain> it's going to be the same size on all platforms, you compute it today and stick it in a constant
headius has quit [Quit: headius]
headius has joined #ruby-core
tenderlove has quit [Remote host closed the connection]
headius has quit [Quit: headius]
nokada has joined #ruby-core
enebo has quit [Quit: enebo]
nari has joined #ruby-core