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
hsbt is now known as hsbt_away
hsbt_away is now known as hsbt
kosaki2 has joined #ruby-core
shinnya has quit [Ping timeout: 248 seconds]
charliesome has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kosaki2 has quit [Remote host closed the connection]
charliesome has joined #ruby-core
nagachika has joined #ruby-core
nagachika has quit [Remote host closed the connection]
nagachika has joined #ruby-core
charliesome has quit [Remote host closed the connection]
charliesome has joined #ruby-core
kosaki2 has joined #ruby-core
kosaki2 has quit [Remote host closed the connection]
<_ko1>
However, I'm afraid that people use f suffix everywhere for (few) performance improvement.
<_ko1>
Because they are not a specialist of Ruby.
<_ko1>
some blog may say "how to improve perofrmance" tips.
<_ko1>
`freeze_string' style approach is good for people to make more solid program.
<charliesome>
I like freeze_string, but I still think f-suffix has merit
<charliesome>
I don't think we should be concerned about people using f-suffix too much
<_ko1>
how about `'foo'.frozen' instead of f suffix
<_ko1>
?
<_ko1>
charliesome: i think language should be educational
<charliesome>
with an opt_frozen instruction?
<_ko1>
charliesome: for example, Yes.
DanKnox is now known as DanKnox_away
<charliesome>
what about "a #{1}".frozen
<charliesome>
should that dedupe "a 1"?
knu has quit [Ping timeout: 248 seconds]
<znz_jp>
biff: [ruby-changes:31037] naruse:r43116 (trunk): * vm_core.h: use __has_attribute() instead of __clang__major__ because - http://mla.n-z.jp/?ruby-changes=31037
<_ko1>
charliesome: yes
<charliesome>
ah I see
<charliesome>
so String#frozen dedupes
<charliesome>
but then opt_frozen is used when recv is a NODE_LIT string
<_ko1>
yes
<_ko1>
[ruby-core:57579] [ruby-trunk - Feature #8977][Open] String#frozen that takes advantage of the deduping
<dbussink>
so i saw that frozen idea, isn't this basically semantically almost the same as symbols?
<dbussink>
and why can't symbols be used in that case?
<_ko1>
dbussink: i like this idea
<dbussink>
since it also needs a symbol table like structure to keep the strings
<charliesome>
dbussink: symbols aren't strings and shouldn't be confused with strings IMO
<dbussink>
well, feels to me like two almost exactly the same semantics but slightly different
<charliesome>
Symbol#to_s allocates a new string, which loses the performance gain of using frozen strings
<dbussink>
but why can't symbols be used in the case he shows
<dbussink>
if it's because they can't be gc'ed, that seems like what needs fixing
<_ko1>
dbussink: in ruby3, i want to unify string and symbol
<dbussink>
and not adding another feature like this that is almost the same but not exactlyt
<dbussink>
right
<_ko1>
dbussink: but there are many issues
<dbussink>
so why add more features related to this at this moment?
<dbussink>
it's just that it feels like copy pasting a bunch of code with slightly different semantics
<charliesome>
i don't think strings and symbols should be unified - they are semantically different
<dbussink>
and that never really worked well when i did that before
<nurse>
ruby 3 will be released the year 2030 or something...
<charliesome>
maybe they could be unified internally, but they should remain separate classes IMO
<dbussink>
charliesome: right, but why can't symbols be used there for that rubygems example then if the duplication in memory is so big?
<charliesome>
dbussink: for that specific example, they could be
<charliesome>
but we should consider the general case
<_ko1>
dbussink: what should return -> "foo" == :foo
<dbussink>
charliesome: well, what i wonder is how much general case is left after looking at each case
<dbussink>
so whether that makes it worth adding the complexity
<charliesome>
_ko1: i think that should return false
<nurse>
it will break all desctructive methods for strings
<charliesome>
_ko1: many libraries (especially DSLs) use symbols and strings for different things
<charliesome>
_ko1: my favourite example is in bundler. source "http://rubygems.org" vs. source :rubygems
<_ko1>
charliesome: currently yes. so ruby3 is good chance to change it
<_ko1>
charliesome: but i know compatibility is also important
<_ko1>
charliesome: big issue
DanKnox is now known as DanKnox_away
<charliesome>
dbussink: here is an example where there is a heavily duplicated string that doesn't make sense as a symbol: https://github.com/github/rails/pull/19
<_ko1>
charliesome: BTW, rb_fstring() should be renamed with tha method name of String#frozen
<_ko1>
for example, rb_str_frozen()
<_ko1>
if it is String#dedup, then rb_str_dedup()
schaerli has joined #ruby-core
<_ko1>
String#to_fstr # bad idea
<dbussink>
charliesome: right, but doesn't that pull request have a better fix than this feature would have?
<_ko1>
String#dedup is clear?
<charliesome>
_ko1: agree
<charliesome>
dbussink: so the fix i went with was possible because we never call those methods in our app so we can straight up delete the method
<charliesome>
dbussink: rails core wouldn't want to do that though
<charliesome>
they still want to show a deprecation warning
<charliesome>
and as far as i'm concerned, that's a concrete use case for deduplicated strings that aren't symbols