<unak>
brixen: so, we have to split them with discussions like today's meeting :)
<n0kada>
at least, changing behavior across patchlevels is not a spec
<n0kada>
just a bug-fix
<brixen>
emboss: absolutely
<n0kada>
bug is impl-dependent of course
<brixen>
unak: indeed :)
<nurse>
MRI is a implementation of ruby, but rubyspec pull them. this is a root of problem
<ebisawa>
それでは私は失礼致します。I am leaving now. thank you for having me on IRC (first -timer)
<_ko2>
ebisawa: thanks!
<jballanc>
_ko2: for SRFI it's more of a description
<sora_h>
ebisawa: thanks!
<tenderlove>
ebisawa: thank you!
<emboss>
ebisawa: Thanks!
<unak>
ebisawa: thanks! oyasuminasai
<brixen>
ebisawa: thank you!
<ebisawa>
I was scared to death
<brixen>
ebisawa: you were awesome!
<jballanc>
_ko2: but adopted to this process I think it would mean you could propose something before having a RubySpec
<ebisawa>
especially zen-spader was in my house
<jballanc>
but not *accepted* until RubySpec is written
<_ko2>
jballanc: yes.
<tenderlove>
ebisawa: <3<3<3
ebisawa has quit [Remote host closed the connection]
<emboss>
Does anyone have a good idea how we could avoid redundancy with existing test unit tests and their integration in rubyspecs?
<brixen>
use rubyspec :)
<asarih>
emboss: besides individual inspection, I don't see a way.
<brixen>
there are already vastly more rubyspecs in almost every area
<_ko2>
brixen: for example, the error message is spec?
<unak>
(1) first, mark "MRI dependent" flags on all of MRI's test
<brixen>
and I'm actively adding rubyspecs for 1.9 features that are missing and only in MRI's tests
<brixen>
_ko2: those are very few cases
<brixen>
rubinius has impl specific specs
<brixen>
MRI could as well
<emboss>
asarih: brixen: OK, so it comes to translating them to rubyspec in the end. Well, not all too bad, I prefer spec-style tests anyway :)
<unak>
(2) JRuby team picks what they want to accept, and mark them as "Ruby spec"
<unak>
(joke)
<_ko2>
brixen: i think it should be an implementation dependent. we need to discuss what is "Ruby" spec before.
<brixen>
unak: hehe
<brixen>
_ko2: indeed, we have to define "Ruby" independent of any implementation
<brixen>
but every implementation should be compatible on that definition
<brixen>
and that definition must be precise enough
<brixen>
or it is useless
<_ko2>
brixen: i agree > every implementation should be compatible on that definition
<tarui>
unak: where is rubinius ? :-)
<brixen>
tarui: invisible, it comes to eat you in your sleep! :)
<unak>
tarui: (3) rubinius implements the result :)
<brixen>
unak: haha
<_ko2>
brixen: i feel current rubyspec is too precise. it includes implementation (version/patch level) dependent.
<brixen>
_ko2: can you pick examples?
<nurse>
String#crypt
<brixen>
_ko2: rubyspec just describes current stable release
<jballanc>
brixen: one question -- have you considered that "Ruby" should be much much smaller than current ruby spec if mruby counts?
<brixen>
nurse: that is platform dependent
<brixen>
jballanc: mruby is a specific case that may need a subset
<_ko2>
i can't see nurse-san's comments...
<brixen>
but mruby cannot be the definition of Ruby
<brixen>
a subset that small is too small for interoperabilitiy
<brixen>
er spelled correctly
<jballanc>
well...I forget...does mruby adhere to the ISO spec?
<brixen>
the Ruby ISO standard already is the intersection of the lowest common denominaters
<brixen>
er denominators
<headius>
rubyspec and patchlevel guards may need to be replaced with something not specific to MRI version numbering?
<brixen>
it's useless as a true spec
<nurse>
I heard mruby team is making a embeded subset of ISO Ruby
<akr_>
GCD instead of LCD, I think.
<brixen>
there are no patchlevel guards except on ruby_bug afaik
<akr_>
LCD is bigger than all.
<jballanc>
brixen: I think it could be a starting point, though
<brixen>
jballanc: I don't see any value in that
<brixen>
does mruby run rails? :)
<headius>
brixen: I believe right now we assume current PL is that version, and previous PL with different behavior would be considered divergent behavior?
<unak>
of course, MRI must have it's own tests -- test unit tests -- to debug.
<brixen>
headius: I don't understand your question
<headius>
i.e. if a feature changes in 1.9.3p500, then that becomes 1.9.3 feature, and prior to 500 is MRI-specific
<unak>
yes, they're only tests, not specs.
<brixen>
unak: I debug with specs all day long
<jballanc>
brixen: well, many languages get by with smaller specs...scheme, lua...C
<brixen>
jballanc: they are different languages for sure
<marcandre>
unak: Aren't specs just complete tests?
<jballanc>
already rubyspec has core/language/library divisions
<headius>
we can't avoid features changing at MRI patchlevels…some will simply be bug fixes or clarifications
<jballanc>
why not just continue that granularity
<unak>
so, other implementations should not treat MRI's test as spec.
<headius>
but we need something better than patchlevel to capture that in rubyspec
<brixen>
headius: the goal of a definition of Ruby would avoid this question
<headius>
indeed
<brixen>
and MRI would not be changing *Ruby* behavior in patchlevels
<headius>
all I'm saying is that Ruby versioning and MRI versioning are conflated right now
<brixen>
further, rubyspec has with_feature guards
<brixen>
which make a lot more sense than a version #
<brixen>
eg encoding, which could have been a 1.8 feature
<headius>
I agree with that…ideally any changes that happen at patchlevels are only feature clarifications or fixing divergence from spec
<headius>
I'm not sure we can force that though
<brixen>
oh crap, I have to go
<jballanc>
hmm...maybe a crazy suggestion, but could we version core/language/library independently? make spec version the standard
<jballanc>
ah, another time then :)
<brixen>
later folks
<headius>
if there's a serious flaw in a feature and we have to fix it in PL timeframe, we need t hat flexibility
<headius>
brixen: ok, thanks
<asarih>
brixen good night
<brixen>
cheers, all
<emboss>
brixen: gn8
<unak>
brixen: good night
<_ko2>
brixen: good night.
<headius>
perhaps "Ruby" needs a fourth version dimension that we can *correlate* to a PL
<jballanc>
brixen: later
<headius>
1.9.3.x implemented by MRI in 1.9.3p500
<hone>
unak: hello!
<tenderlove>
unak: I want to introduce you to hone
<unak>
as the maintainer of MRI 1.9.3, I use rubyspec to keep the features.
<nurse>
what is "PL"?
<unak>
hone: hello!
<jballanc>
nurse: patch level
<tenderlove>
unak: hone works at heroku with _ko2 and Ayumu-san
<hone>
unak: ayumu reached out to us about your app
<nurse>
i see, thx
<jballanc>
headius: is there a reason to track specs on broken features?
<headius>
all features are broken…we just don't know it yet
<unak>
hone: oh, ah, よろしくおねがいします。
<jballanc>
woludn't it be better if a broken PL failed when specs were run
<headius>
if we could guarantee perfect impls of a feature the first time, and perfect specs before it shipped, that would work
<headius>
we can't guarantee either
<emboss>
headius: How should we proceed with our merging of OpenSSL tests with regard to rubyspec? Merge them first, then try to translate them to specs?
<jballanc>
why not say a version should pass 100% of spec before release, but might fail spec later on
<headius>
emboss: that won't really work…they have to be ported in the process since they have to run under mspec
<headius>
I can't speak for brixen, but 'd be happy with fast and dirty ports of missing tests so we can get them in there
<nurse>
patch level guard considered harmful. There should be a ideal 1.9.3 spec and all implementations including MRI should go there
<hone>
unak: sorry, my japanese is poor. I'm working on it.
<headius>
they won't be beautiful but the gaps are causing major pain for impls that want to rely on rubyspec alone
<headius>
I think filling the gaps takes priority over writing perfect specs
<asarih>
nurse: agreed.
<hone>
unak: but it's nice to meet you :)
<_ko2>
ahhh, breakfast is finished.
<_ko2>
@hotel
<asarih>
bugs are bugs and spec should expose, not hide, them.
<sora_h>
hone: よろしくおねがいします → "nice to meet you"
<tenderlove>
_ko2: do you like Taiwan?
<_ko2>
tenderlove: very much
<nurse>
What is the "perfect spec" is hard issue.
<_ko2>
tenderlove: you should go
<hone>
sora_h: thanks!
<_ko2>
s/go/come/
<unak>
hone: sorry, I couldn't translate the nuance. my English is poorer than your Japanese, I guess :)
<hone>
unak: haha. I have many doubts about this. :)
<asarih>
台灣!
<nurse>
usa's Japanese is difficult ;-)
<emboss>
headius: So you think it would be worth trying to develop both in parallel? My fear was just that it might be better to reach consensus between jruby-openssl and CRuby OpenSSL first before coming up with "definitive" specs...
<unak>
but heroku have many Japanese <-> English translators, I know :)
<hone>
haha yes.
<_ko2>
unak: matz
<headius>
emboss: oh sorry, I misunderstood
<tenderlove>
_ko2: I want to go someday
<headius>
emboss: yes, I think jruby openssl tests should merge into MRI first
<nurse>
matz is the best translator in Ruby world
<headius>
there's not many
<asarih>
tenderlove: don't you have enough FF miles already?
<tenderlove>
asarih: plenty of FF miles, not enough time
<asarih>
tenderlove: ha ha.
<tenderlove>
I would trade FF miles for time though
<tenderlove>
;)
<emboss>
headius: Great, I agree! So that's what I will try to do then!
<asarih>
emboss: keep up the good work, yo.
<emboss>
asarih: aight, will do ;) thx
<emboss>
ok guys, I need to go to bed. Thanks again to anyone taking part in and organizing the meeting!
<hone>
unak: i think tenderlove taught me that phrase in japan. I'm just a terrible learner.
<asarih>
night!
<emboss>
night!
emboss has quit [Quit: Leaving]
<unak>
good night
<unak>
... too late
<hone>
unak: we at heroku would love to help ruby-core where we can
<unak>
hone: thanks! of course I'm feeling heroku's support everyday.
<hone>
i've created a ruby-core organization and invited you to it
<sora_h>
hm
agarie has left #ruby-core ["Leaving..."]
<hone>
you can go ahead and transfer you app and we can scale it to 2 dynos and move the database to a crane one
<sora_h>
hone++
<unak>
hone: thank you very much!!!
<hone>
if you need help with doing that, let me know!
<hone>
or bug tenderlove
<unak>
but... how did you inivite me? :)
<hone>
unak: via the heroku email account you have on the app
<hone>
unak: I'll bug the team responsible for it. it seems like a bug. you might need to log into http://dashboard.heroku.com first then go to manager.heroku.com to bypass the weird login loop.
<nurse>
usa alwasy breaks heroku...
<unak>
not always...
<nurse>
*almost* always
jballanc has quit [Ping timeout: 252 seconds]
jballanc has joined #ruby-core
<unak>
acount1: login loop
<unak>
account2: Internal Server Error
drbrain has quit [Remote host closed the connection]
<unak>
hone: thanks for your support. I'll try again with another environment later.
<unak>
good bye, now
unak has quit [Quit: Leaving...]
ddd has quit [Quit: Leaving.]
ddd has joined #ruby-core
qmx|away is now known as qmx
Glass_saga has joined #ruby-core
headius has quit [Quit: headius]
xibbar has quit [Remote host closed the connection]
agarie has quit [Remote host closed the connection]
<znz_v>
biff: [ruby-changes:26265] ngoto:r38322 (trunk): * ext/fiddle/function.c (Fiddle::Function.new): new keyword argument :name to set the name attribute. - http://mla.n-z.jp/?ruby-changes=26265
<znz_v>
biff: [ruby-changes:26269] ngoto:r38326 (trunk): * test/dl/test_func.rb (test_name_with_block, test_bind, test_qsort1): call unbind to release the callback closure because maximum number of callbacks is limited to DL::MAX_CALLBACK (== 5) with pure DL without Fiddle. - http://mla.n-z.jp/?ruby-changes=26269
<zzak>
commit message is long o_o
asarih has joined #ruby-core
davidbalbert is now known as davidbalber|away
lopex has quit [Remote host closed the connection]
kosaki2 has quit [Read error: Connection reset by peer]
kosaki2 has joined #ruby-core
tenderlove has quit [Ping timeout: 264 seconds]
headius has joined #ruby-core
judofyr has quit [Remote host closed the connection]
kosaki2 has quit [Remote host closed the connection]
<znz_v>
biff: [ruby-changes:26271] shugo:r38328 (trunk): * eval.c (rb_using_refinement): make the method table of an iclass - http://mla.n-z.jp/?ruby-changes=26271