Index

Show enters and exits. Hide enters and exits.

02:02:11Defilerevan: Let's say I wanted to write some code to see which method dispatches in my program are dynamic; meaning that during a run of the program, there is some call site where the receiver has a different type sometimes
02:02:28DefilerWhere does that kind of fun happen these days?
02:54:19benblackanyone have matt bauer's bdb gem working?
03:06:07rueUmm...I would almost bet that no-one has tried
03:06:18ruebenblack: Except maybe you? Did you get an error?
03:09:32benblackyes, hell of error
03:09:32benblackhttp://github.com/mattbauer/bdb/
03:09:32benblackthe gem in question
03:09:32benblackgive it a whirl
03:10:33rueI am going to bed, 's just past 5 :) Pastie up the error, though, or add a ticket on Github
03:11:12rueIt could simply be something missing in the C API or perhaps an extconf convolution
03:11:38rueMention OS/arch/etc. too
03:16:16benblackhttps://gist.github.com/cf5ea11b927e5446b9e5
03:16:19benblackOSX 10.5
03:20:36benblackhttp://github.com/evanphx/rubinius/issuesearch?state=open&q=bdb#issue/160
03:22:47ruebenblack: Try changing that varargs.h to stdarg.h...might fix all of it
03:23:00rueBonus points if we get it resolved before I am done brushing teeth :P
03:25:53benblackdoesn't fix anything but that varargs error
03:25:56benblackthe rest remain
03:26:03benblackand version.h still doesn't exist
03:27:55rueHm
03:28:22rueThose errors are typical of syntax problems caused by missing includes, broken macros
03:29:15benblackbuilds clean with MRI gem so i'm assuming it is a difference in includes for the bindings
03:29:22benblackbut i am still a rubinius newb
03:29:50rueQuite possible, yeah, if it is not finding some type definitions for example
03:30:15rueReally have to go now, but refresh the pastie with the new error after the varargs fix
03:32:07benblackit's the same, modulo that one error.
03:33:19rueRefresh anyway so it does not get in the way :) *wave
07:49:02dbussinkmorning
07:54:44dbussinkevan: brixen: available for a question?
08:32:39brixensup dbussink?
08:33:41dbussinkbrixen: i was wondering, how do you stand on adding something like Method#parameters, which is added to 1.9
08:34:01brixenwe have a one_nine branch ;)
08:34:12dbussinkbrixen: because it was added to 1.9 because stuff that wanted to do that couldn't use parsetree anymore
08:34:31dbussinkbrixen: so on mri 1.8 people can do that with parsetree, on 1.9 with Method#parameters, but on rbx they can't use either
08:34:48brixenI see
08:35:21brixenwell, seems reasonable enough to add Method#parameters then
08:35:25brixenyou should ask evan though
08:35:35brixendid you have another question for me earlier?
08:35:43dbussinkbrixen: it was the same one ;)
08:35:48brixenahh ok
08:35:54dbussinki have the implementation floating around here, was pretty simple
08:35:59brixenI saw you mentioning about #require
08:36:48brixenI'm working on those specs but I haven't gotten to the file extension ones yet
08:37:09brixenwere you able to find a ticket or thread discussing that 1.9 behavior?
08:37:23brixenand is that 1.9.2 head or some previous version?
08:40:28dbussinkbrixen: nope, i opened a thread on ruby-core last night
08:40:35dbussinkbrixen: this is for 1.9.1 and 1.9.2-head
08:40:41dbussinki tested with both those
08:40:53dbussinkbrixen: this issue is what breaks building rbx with 1.9 atm
08:41:25dbussinksince there is a require 'digest/sha1' which loads the 1.8 native library on 1.8, but loads the rbx version in lib/ because that one is an .rb file and the 1.9 extension is a so / bundle file
08:43:29brixendbussink: ok, got the ticket #?
08:43:42brixenor thread rather
08:43:46dbussinkhaven't made a ticket yet (neither rbx or core
08:43:48dbussinklet me check
08:46:19dbussinkbrixen: http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/27522?27451-27528+split-mode-vertica l
08:47:16dbussinkthe reply i got isn't really that useful :S
08:47:44brixenhrm, yeah that's not helpful at all
08:48:02brixenok, I'll make sure we have specs for it
08:48:07brixenthanks benschwarz
08:48:14brixener damn tab hehe
08:48:16benschwarzthanks for?
08:48:18brixenthanks dbussink
08:48:20benschwarzhehe
08:48:22brixenbenschwarz: misfire :P
08:48:23dbussinkbut fixing this in rbx for 1.9 building would create cludgy code
08:48:40brixendbussink: yeah, it's wacky IMO
08:48:45dbussinkbecause there is no way to force loading the .so/bundle file
08:49:01dbussinkexcept for specifying the extension
08:49:45brixenyep
08:50:00brixenwell, sleep for me, catch y'all in a few
08:54:07dbussinkbrixen: night
13:47:42ruedbussink: I would wait for a "second opinion", but can start to push toward pointing out the flaws in the scheme
13:48:00dbussinkrue: how do you mean?
13:48:06dbussinkguess i'm missing the context :)
14:02:49rueOn -core
16:22:48Defilerhehe @properties = Hash[*klass.properties.map{|_,name| name }.zip(props).reject{|k,v| v.nil? }.flatten]
16:22:52DefilerFun
16:29:07dbussinkDefiler: so readable :)
16:29:29rueMorning, De
16:29:42rueSometimes the _ just causes unnecessarily clutter
16:30:40DefilerYeah, that and you could do that way more cleanly, avoiding several of those invocations, by splitting it up into two steps hehe
16:36:43Zoxctemporary variables can be register allocated! speed ftw!
16:51:39rueReminds me of slava's tweet...that was interesting
17:14:51brixenrue: the image size reduction by 1% by storing in a register tweet?
17:22:04rueThat
17:22:36evanmorning gents.
17:24:25rue*wav
17:25:01brixenmorning
17:32:34brixenI think I'm revising the rubyspec commit bit
17:33:05brixenif I have to make edits to a commit, I think the person will need to submit another work before they get a bit
17:33:39brixenthat way I can see if they understand the issues with their commit
17:33:52brixendoes that sound reasonable/unreasonable?
17:44:09rueReasonable; though it is a bit softer than the traditional rejected patch with note to fix it themselves.
17:45:15evanbrixen: seems fine
17:45:26evanwait until they've got the training wheels off
17:46:32dbussinkevan: how do you stand on adding something like Method#parameters?
17:46:45dbussinkevan: also asked brixen, he was ok with it, but suggested to pass it by you
17:47:23evanfine to commit
17:47:34evanit's brand new functionality (thats missing anyway)
17:47:55dbussinkevan: yeah, but it's not in mri 1.8
17:48:07evani can't see how having it would confuse anything
17:48:10dbussinkbut it's also something people can do with parsetree in 1.8, but there's no way to do it in rbx
17:48:15dbussinkand it's pretty simple
17:48:19evanyeah, well, lots of stuff isn't in 1.8 that we've got.
17:49:01brixenrue: yeah, I figure the code directly communicates what needs changing, with supporting notes, rather than just notes
17:49:27rueSure. Traditional is rarely the same as better
17:49:27botanicusHey guys
17:49:28brixenrue: so hopefully less miscommunication for everyone
17:49:48rue*wave
17:50:38brixendbussink: the biggest problem with this is that the specs would be guarded with a 1.9 version guard
17:50:57brixendbussink: but our compat MRI version is not 1.9
17:51:04botanicusevan, dbussink: regarding the 1.9 stuff (for Evan: we was talking about it yesterday with dbussink & Defiler, I'd like to help) ... However it seems I'm not able to help since the C-code changes have to be done first. Most of the failing specs on one_nine branch is about missing Encoding / BasicObject.
17:51:49rueWhat about library-level changes?
17:52:27botanicusrue: as for example? As I understand standard library is cp into Rubinius, right?
17:52:34brixenbotanicus: depends how much you want to help, you could certainly study vm/ontology.cpp and figure out how to add BasicObject
17:52:36evanbotanicus: well, there is still a lot of methods in 1.9 that we don't have
17:52:50evanso while they may not be used in your specs, we'll need them eventually
17:52:54evanyou could start there.
17:53:54botanicusbrixen: I never worked with C++. However I might try ... do you think a Ruby guy is able to do it :) ?
17:54:50botanicusevan: I see. Just to clarify what part of rubinius are we talking about? Kernel (is it called kernel, the built-in classes, right) or stdlib?
17:55:03rueYou need to have some understanding of C++ (or C, at least) before you can efficiently do anything there
17:55:19evanbotanicus: i'm talknig about Array / Hash, etc
17:55:23evanthey're in kernel/, yes
17:55:51botanicusevan: OK, it seems more reasonable than playing with some C++ code
17:56:10botanicusevan: is there any contributing guide? I'm not very familiar with Rubinius so far
17:56:20evanno, there is not.
17:56:46botanicusOK, I'll figure out
17:56:54evanget a failing case in spec/ruby
17:57:01evanmake it pass
17:57:04botanicusHowever it would be pretty helpful to have it
17:57:04evango to 1
17:57:22evanwe haven't needed it for years now
17:57:24evanand we've been ok.
17:57:41brixenbotanicus: there is one for writing specs http://rubyspec.org/wiki/rubyspec
17:57:59brixenbotanicus: for Rubinius ruby code, follow existing style and ask questions when in doubt
17:58:07evanbotanicus: if you'd like to write up the steps you go through, that would work fine.
17:58:11botanicusevan: I believe you core devs are OK without it ;) But really, I think rubinius is a project where everyone can contribute - unlike to MRI.
17:58:33evanwe've got 200+ contributers
17:58:36evanso it's not just core.
17:58:59brixenbotanicus: also, read /doc in the repo if you have not
17:59:11botanicusOK, I'll try ... later, I'm at work now.
17:59:13evanthat being said, if you'd like to write up the steps you take
17:59:20evanthat would be fine
18:00:00botanicusevan: no I hate writing docs and I have enough of my projects where I have to do that ... I'll be happy to contribute some code but docs no
18:00:26evanok....
18:03:29DefilerWe used to have one, but nobody read it
18:06:34rueIt is still there
18:06:55botanicusrue: really? In /doc as well?
18:07:49botanicusAnyway is there someone who's interested in the parser changes for 1.9? I really have no clue how to do that and unfortunately I can't use Rubinius before this will be done :( And I want to use Rubinius ...
18:10:59evanno one has had the time yet, no.
18:14:56evanbotanicus: we're wary of 1.9 is all (responding to your tweet)
18:15:09evanbecause in the time rubinius has existed, 1.9 has changed radically.
18:17:50botanicusevan: yes but it's relatively stable now I would say, so I think it's time to start to support it - also because it will take quite a lot of time to code it.
18:18:23evanwe simply don't have unlimited resources
18:18:50evanwe don't have the luxury of not supporting 1.8
18:19:06evanand 1.8 is by far in more usage than 1.9
18:19:18evan(I realized the circular nature of the last point)
18:21:02botanicusevan: I didn't tolt not to support 1.8
18:21:05botanicus* told
18:22:02evan?
18:22:05evanplease rephrase.
18:22:34botanicusevan: "we don't have the luxury of not supporting 1.8" -- that's fine, I didn't told anything about not supporting 1.8
18:22:56evan"I don't told anything" == "I didn't say anything" ?
18:23:00evanyour grammar is confusing me.
18:23:07botanicusevan: anyway Rails suport 1.9 since 2.3.5 so we can expect more and more people migrate to 1.9 in next year
18:23:29botanicusevan: sorry, EN isn't my native language
18:23:36evannp, just trying to be clear.
18:23:41botanicussure
18:23:42evaneven so, we have to support both
18:23:54botanicusExactly
18:23:59evanand brixen and I ourselves don't have the resources to do both
18:24:13evanso, as you said everyone can contribute, so for now, we rely on others to help.
18:25:15botanicusevan: I'll see if someone (who knows C++) would be interested, I asked at Twitter.
18:25:25evanok
18:26:28DefilerThe parser work is no kind of fun :(
18:26:50botanicusDefiler: I can imagine that
18:27:54botanicusActually has Rubinius its own parser or is using the piece of shit from MRI?
18:28:25evanit uses the MRI parser.
18:28:44evanand i do not suggest you try to write your own.
18:28:54DefilerMany have tried, all have failed
18:28:58Defilerhttp://github.com/evanphx/rubinius/blob/master/lib/ext/melbourne/grammar.y
18:29:05botanicusevan: believe me I don't have this intention ;)
18:29:41botanicusMRI parser ... yeah it will be pretty tough
18:30:41brixenbotanicus: um yeah, you shouldn't call MRI's parser a piece of shit
18:31:11DefilerIt works beautifully, and history has shown that it is non-trivial to replace
18:31:12brixenbotanicus: just an FYI there as that is rude and very uninformed about the difficultly of writing one
18:31:23DefilerNot because of anything it has chosen to do, but simply the raw difficulty of the task
18:33:22DefilerRuby is a great way to find out if your parser generator has all the features it needs :)
18:34:37botanicusbrixen: sorry
18:35:12Defilerevan: Where should I look for the heart of the FFI action these days? I'm wondering if it is possible inline a native call into the JIT'd version of the calling Ruby method
18:35:51evanwe already do that
18:35:52dbussinkbotanicus: also on your last twitter, please don't just to conclusions like that, that only makes you show of bad
18:36:03dbussinkjump to conclusions i mean
18:36:19dbussinkbotanicus: since it's not a matter of not willing too, but of setting priorities
18:36:22DefilerCool.
18:36:40evanDefiler: vm/llvm/inline.cpp:520
18:36:42evanInliner::inline_ffi
18:36:51DefilerAah, thank you
18:37:03boyscoutAdd Method#parameters and UnboundMethod#parameters following 1.9 - ae37c72 - Dirkjan Bussink
18:37:11DefilerOh man this is a beautiful file
18:37:14DefilerI hate being out of date on rbx :(
18:37:37botanicusdbussink: it's not about priorities, it was more about it that every time I come & asked about 1.9, someone shows up and be wondering why we even need to support 1.9 etc. I respect the priorities, but this is something different.
18:38:20evaneverything is about priorities.
18:38:22botanicusAnyway if it's using MRI parser - and you might consider it as a stupid question, however - isn't it enough to just take the one from MRI 1.9 and replace the old one?
18:38:34DefilerBecause that would break our support for 1.8
18:38:35evan1.9 has been a moving target, so that makes it hard to code for
18:39:05evanand we don't have the time to track those changes and/or devest time in getting 1.8 solid to work on 1.9 support
18:39:13DefilerAlso, while the grammar is based on 1.8, it has been modified to make it easier to plug into things that aren't MRI
18:39:25DefilerSo there is at least a little work needed to transform 1.9's grammar into something with the same interface
18:39:44Defiler(though that strikes me as just being tedious, not outright hard)
18:39:59evanbotanicus: thats certainly the direction to take, but it likely won't be just cut and paste the grammar and it works
18:40:27boyscoutCI: rubinius: ae37c72 successful: 3024 files, 11747 examples, 35948 expectations, 0 failures, 0 errors
18:40:39botanicusDefiler: since we have the one_nine branch I thought we'll have rubinius & rubinius-1.9 standalone, no?
18:40:46DefilerYeah
18:40:53evanwe don't honestly know
18:40:59evanthats a future decision
18:41:06DefilerAnd we will presumably need to audit the kernel to make sure we aren't relying on 1.8 semantics
18:41:14evanas it stands now, they're seperate though, yes.
18:41:43botanicusOK
18:43:26botanicusNevertheless for me, as a normal Ruby user, it's better to have them standalone, or at least find a better way than the --1.9 switch as is in JRuby. Mainly when you have some gems depending on 1.9 you can run gem install, but jruby 1.9 -S gem install which is too much writing.
18:44:44brixenthere are always shell aliases
18:45:59botanicusbrixen: and there are always situations when your .profile isn't loaded ;) It's causing a lot of pain ...
18:46:09botanicusBut it was just a suggestion
18:47:17evanhm, i think I broken MemoryPointer.autorelease= at some point
18:47:44DefilerI like separate binaries because it is easier to use gdb on them :)
18:48:01brixenthe syntax changes are the biggest reason for me
18:48:10brixenconsider our install, we precompile lib
18:48:24brixenthat would be more complicated to know which file to compile with which mode
18:48:29brixenetc
18:48:41DefilerYeah, we would have to add a version distinction to the path to stdlib as well
18:48:51Defilerand compile the 1.8 stuff in 1.8 more, 1.9 in 1.9 mode
18:48:55brixenright
18:49:12brixenmight as well be a clean break IMO
18:50:42dbussinkevan: are you still looking at that vmmethod leak?
18:50:51evanpondering a bit
18:50:53evanyes.
18:51:06evani'm a little side-tracked atm.
19:03:54rueDefiler: Yeah, I have been barely able to keep up
19:05:06DefilerEven 1.9.1 is a moving target.. which patchlevel do you pick?
19:05:37DefilerWill there never be another 1.9.1 patchlevel? Unlikely given the history of previous versions
19:07:06ruebrixen: Well...the MRI parser IS awful. One could make an argument that it is the best it can be, but still :)
19:08:00DefilerWhat's wrong with the MRI parser that isn't actually something about bison/yacc?
19:26:02rueBy far the tool is the biggest problem. Use of the tool may be suboptimal, the sexps generated maybe not the best and so on, but it is of less impact
19:26:26rueBut, then, you might as well ask what is wrong with cutting trees down with dynamite except for the tool used ;)
19:27:53rueAnd you may argue that it is the best that could be done at that time etc., but I do not think it is subjective that the parser is just not good as it stands.
19:29:14DefilerHaha, well
19:29:26DefilerIn the case of trees, I would have other proven techniques to steer you toward
19:29:41evanorbital weapons platform!
19:30:00DefilerI think the correct way of thinking about it is 'The MRI parser could be better, but nobody has made it better yet.'
19:30:16DefilerWhich gives us room for the challenge without bringing judgements into it
19:30:41rueNaw, that is just euphemistic
19:30:56rueIt is not a crisis, it is an opportunity!
19:31:11evanI got to use the orbital weapons platform on fallout 3 last night
19:31:11rueWhich is sort of true, but annoying :P
19:31:12evanit's awesome.
19:31:16evanbut you only get to use it once.
19:31:31rueevan: The only necessary orbital weapon is a huge lump of steel
19:31:46rueDrop it down and watch the world go "boom"
19:31:53DefilerI like bundles of thin rods
19:31:54evani wonder how much refined steel breaks up on entry
19:32:20evanit shouldn't get hot enough to melt it
19:32:24evani wouldn't think
19:32:30DefilerThis has some of the number crunching: http://www.jstage.jst.go.jp/article/tjsass/47/157/47_161/_article
19:32:43DefilerIt is all about the surface area you present to the atmosphere
19:33:14evanif there is no stabalization
19:33:21evanit will just tumble into a ball
19:34:06Defilerrods work because you can make the entry speed fast enough to make them stable against tumbling
19:34:18evantrue
19:34:19evanjust put some fins on it
19:34:34evanand get it spinning around the long axis for stability
19:35:16Defilerreentry is a little counter-intuitive
19:35:34Defilerbecause things that work at subsonic speeds can make it worse when the air is as hard as steel
19:36:33DefilerWhoa
19:36:43DefilerI didn't know the particulars of the Galileo probe reentry
19:36:57Defiler47.4km/sec, 230g of acceleration
19:37:05evannice.
19:37:12Defiler16,000 kelvin surface temperature
19:37:16evanhah
19:37:37DefilerTotal blocked heat flux peaked at approximately 15000 W/cm².
19:37:37evanwhat is the melting temperature of the ceramics on the shuttle I wonder
19:37:38Defileraaaaaaaa
19:37:59DefilerWell, 16kK is like 3x as hot as the surface of the sun
19:38:38evanbut the surface is the coolest part! :D
19:39:26DefilerLuckily!
19:39:36marcandreevan: hi! Back from a short trip in NYC.
19:39:38marcandreDid you want to talk about my "recursive" commit? I saw your change removing ".id" and that's good; anything else?
19:39:47evanyeah
19:39:50evanthat throw
19:39:51evanline
19:39:59marcandreYeah?
19:40:09evanwell first off
19:40:16evanusing catch/throw in the kernel is mega gros.
19:40:17evangross.
19:40:31marcandreI can't disagree.
19:40:34evanand the throw on line 349 is entirely unexercised
19:40:38evanand can't work.
19:40:46marcandreIt's the easiest way to achieve the desired result here, though.
19:40:47evanthere is no catch for it.
19:41:02marcandreHold on, getting the source...
19:41:50rueCool, baby, sun surface cool.
19:43:27marcandreSo the catch is in the same method, about 4 lines below.
19:43:43evan"throw objects, objects"
19:43:44evancan't wory
19:43:48evancan't work
19:43:51evanthere is no "catch objects"
19:44:50marcandreMmm, that line is utter crap, you're right. Let me think a second here.
19:46:43marcandreYeah, it should be "return true if". I'll doublecheck that and change it tonight.
19:47:22evanwhy not use an exception
19:47:27evaninstead of catch/throw
19:47:53marcandreWe could. The reason I didn't in MRI is for security: anyone could rescue the exception.
19:48:02evani'd prefer an exception here.
19:48:08marcandreWhile noone can catch the "signal" we use.
19:48:19evanbut thats also a problem
19:48:43evanbecause this code can get called incorrectly and even the loader can't catch it.
19:48:43marcandreHow so?
19:49:04evani'd prefer an exception
19:49:12marcandreWell, we use a flag internally to know if there is a "catch" waiting for our throw or not.
19:49:12evani realize the security problems
19:49:24evanbut it's cleaner and much easier to debug.
19:50:52marcandreI'll use an exception if you want. I'll make a new exception class that won't be a RuntimeException, to make it slightly harder to rescue by mistake.
19:51:06evanthats fine
19:51:20evanwe should have an internal exception hierarchy
19:51:22evanif we don't already
19:51:42evanException < Rubinius::InternalError < ...
19:51:53evani guess this isn't an error
19:52:08marcandreBut it's an exception... :-)
19:52:22evanperhaps Rubinius::InternalException
19:53:06marcandrek. I'll check that sometimes in the next few days.
19:53:21evanthe sooner the better
19:53:25evanthat throw line is a time bomb.
19:53:29evanwaiting to go off.
19:54:11marcandreNot quite sure what you're afraid of, but I'll change it.
19:54:18evani'm afraid it will be run
19:54:55marcandreIs there a ruby-level way to check if a certain symbol will be caught? It would be nicer than a flag and there wouldn't be a risk of throwing an uncaught signal.
19:55:00evanwhen it does, a TypeError will be thrown
19:56:00evanmarcandre: you mean a query to whether or now throw will raise a NameError?
19:56:08evans/now/not/
19:56:10marcandreYup.
19:56:18evanwe have one
19:57:14evanRubinius::ThrownValue.avaliable? appears to do that
19:58:11marcandreI'll write two version then. An exception based one (cute but slightly unsafe and not completely MRI compliant) and an improved catch/throw one and you can be the one you prefer.
19:58:30evank
19:59:29marcandreGlad you checked my code so closely :-)
19:59:45marcandreI'll let you know when I get a second, probably tonight
20:00:53evanthanks
20:01:00evan:)
20:23:21botanicusHow can I run rubyspec? rake spec?
20:23:42evanbin/mspec ci
20:23:48evanor just rake
20:24:26botanicuscheers
20:40:35botanicusI see, so this is what I run yesterday - basically just complaining about missing Encoding & BasicObject, I can't use with that I'm afraid.
20:40:48botanicusIs there a checklist what from 1.9 was already implemented?
20:41:12botanicusI found tap & inject methods up-to-date, for example ...
20:46:07dbussinkbotanicus: well, could be that low hanging fruit was already added
20:46:19dbussink1.8.7 also added a whole slew of 1.9 library features
20:46:28botanicusI found Dir.exist? missing
20:47:07DefilerNo checklist, but if you wanted to start one, that would be a great first step actually
20:47:24DefilerUnfortunately it requires enumerating the differences between 1.8.7 and 1.9.1
20:49:45botanicusAny documentation standard for rubinius?
20:50:00botanicusYard, rdoc?
20:50:23botanicusMost of the stuff seems to lack documentation, at least in kernel
20:52:27botanicusWhen I change something in kernel I have to recompile something?
20:57:06botanicusAlso I don't understand what about specs? I can see something's synced from rubinius/specs from git ... I just want to add a spec for some kernel functionality, what should I do?
21:01:39evanbotanicus: are you on the one_nine branch?
21:01:47botanicusYes
21:01:53evank, just checking.
21:02:17botanicusBTW is this how it should look like? http://github.com/botanicus/rubinius/commit/cac8567f636f5235efae8612f43eb3290c5b30de
21:04:03botanicusI'm asking mainly because I understand that performance matters and there is a lot of Rubinius low-level stuff ...
21:05:25evanbotanicus: yah, thats fine.
21:05:32evanthats the prefered way.
21:06:54botanicusCool, I'm going to find something else
21:07:04botanicusAnd create the checklist
21:07:30botanicusActually shall I update changelog or it's done automatically?
21:08:25evanwe don't have a changelog
21:08:27evanso no.
21:08:34evan:)
21:09:25botanicusI see :)
21:34:03botanicusIf I want to push some changes, who should get the pull request? Just evan?
21:36:38brixenyou can use git fp and post a ticket
21:36:53brixenafaik, only the repo owner gets a pull request, so yes evan would get it
21:40:13botanicusbrixen: can I do it without a ticket? There is a huge amount of methods I'm going to add for 1.9 support, it would be bloody painful to add a ticket for each of them.
21:40:46botanicusbrixen: you can check who should receive the pull request BTW
21:42:17botanicusbrixen: and pls what's git fp? Google isn't very helpful for this query.
21:42:20brixenbotanicus: post your patch, ask evan for a commit bit
21:42:24brixengit format-patch
21:42:31botanicusI see
21:42:53brixenI'm surprised there are a huge amount of 1.9 methods missing
21:43:02brixenmarcandre already added most of the afaik
21:45:38marcandrebrixen: Most of 1.9 was ported in 1.8.7, except the string encoding stuff, and that I haven't touched.
21:45:53marcandreSo yeah, there isn't all that much in 1.9 per say
21:46:05brixenmarcandre: right, so you already added most of the 1.9 methods besides encoding, yes?
21:46:29brixenI need to update the specs on that branch
21:46:44marcandreI think so, but I'm not sure.
21:46:58marcandreThere are also quite a bit of language changes, which I haven't touched.
21:47:50brixenmarcandre: language == syntax?
21:48:41marcandreyeah, syntax, mostyle, and other stuff like 1.9 can throw objects, not just symbols, the different hierarchy of superclass, ...
21:48:47botanicusbrixen: there are still some
21:49:22brixenmarcandre: yep, I'm with ya
21:49:25botanicusAlso 1.9 removed some stuff like Exception#to_str
21:51:07botanicusI'm going to check everything in the 1.9.1 NEWS and make it compatible ... and then in 1.9.2 when it'll be released.
21:52:48marcandreThe biggie is to figure out how to port the encoding stuff, some kind of bridge I guess.
21:53:09rueIt is all over the codebase
21:54:38brixenright, that's why I lobbied for a separate one_nine branch
21:54:48brixenno bridge, just add the code as needed
21:54:57brixenwithout worrying about anything 1.8.x
21:55:35marcandreI meant the data for encodings should probably be used by rubinius directly somehow.
22:03:17Zoxcwhy not head for 1.9.2 straight away and beat MRI? =P
22:03:47brixenbeat MRI to... the undefined definition of 1.9.2?
22:03:54brixenZoxc: sometimes you make me wonder ;)
22:04:21brixenbut yes, we would not waste time with 1.9.1
22:04:30brixenrubyspec does not spec anything less than 1.9.2 head
22:34:13luislavenabrixen: ping?
22:37:01brixenhey luislavena
22:37:29luislavenabrixen: I owe you some stuff :(
22:37:56brixenis that stuff green with pictures of dead US presidents? :)
22:37:58luislavenabrixen: been busy. question: minimum version of GCC required by rbx?
22:38:08brixenoh you mean code...
22:38:15brixen4.0.1
22:38:19luislavenabrixen: money? hmn, don't think so, maybe beers or a dinner ;-)
22:38:23brixenheh
22:39:06luislavenabrixen: cool, will send the MinGW+MSYS packages I use and a few new ones with 4.4.1..
22:39:12luislavenabrixen: 4.4.1 is ok?
22:39:22luislavenaor maybe 4.3.3 ?
22:39:23brixenI'll give it a shot
22:39:27Zoxcwhat are you plotting?
22:39:27brixeneither way
22:39:34brixenZoxc: world domination
22:39:36brixenof course :)
22:39:48Zoxcfor you or ruby?
22:39:54brixenmuhahahah
22:39:59brixenwouldn't you like to know?
22:40:02DefilerThe distinction grows smaller day by day
22:40:12brixenheh
22:40:25luislavenaZoxc: ;-)
22:40:58luislavenabrixen: the whole package ends something like 700MB, will email you once is packaged.
22:41:11brixenluislavena: ok, n/p
22:41:14brixenluislavena: thanks
22:41:26DefilerYou probably shouldn't attach that to the message :)
22:41:30brixenheh
22:41:36brixenwhat, I use gmail...
22:41:59dbussinkluislavena: you going to work on getting rbx to compile on windows? :)
22:42:39luislavenadbussink: no, I found a nice pr0n C++ ASCII game that want to build cross-platform
22:42:48luislavenadbussink: brixen offered to help me with that ;-)
22:42:49brixenhaha
22:42:55brixendamn right
22:42:56dbussinkluislavena: ah, good to start of with then ;)
22:43:12scottrbx killer app
22:43:12brixenthere is nothing quite like ascii pr0n, believe that
22:43:14DefilerI would love to help with that effort actually
22:43:26Defiler(win64 rbx)
22:43:40dbussink8===D
22:44:07brixenoh my
22:44:57dbussinkbrixen: i suspected this would start a = war but fortunately not ;)
22:45:44brixendbussink: you don't know how hard I resisted
22:45:57dbussinkevan: you there?
22:46:27brixendbussink: I was looking for the ascii congruence character to go for the girth win ;)
22:46:32dbussinkbrixen: i want to know how /hard/ you did ;)
22:46:42brixenhah
22:49:09luislavenaDefiler: what platform you can work with?
22:49:24DefilerWhatever is helpful
22:49:37luislavenaleaving aside the mine is bigger than yours topic. since mine is bigger than anybody else.
22:49:38DefilerI'm pretty familiar with ever Windows incarnation but 7, which I haven't used yet
22:49:48Defilerand I have the big fat Windows Internals book by the sysinternals dudes
22:50:02luislavenaDefiler: the sysinternal dudes really rock.
22:50:05DefilerYes.
22:50:25luislavenaDefiler: me working with 7 x64 lately, but no 64bits for many things, a shame
22:50:46DefilerOh, that is too bad. I was hoping they had really put it through the wringer for 7.
22:50:52Defilerbut I guess it is just like it was in Vista?
22:51:40Zoxcmany things = ?
22:54:44luislavenaDefiler: well, sysinternals stuff got updated to work with 7, and they work good. I mean generally speaking, not many software take advantage of x64 bits.
22:55:16DefilerOh, OK. I know in Vista there were numerous 32bit components running even on a 64bit install
22:56:33luislavenaDefiler: yeah, WOW64 sometimes is confusing.
22:58:34dbussinkluislavena: is there already a mingw 64 cross compiler?
22:59:28luislavenadbussink: http://mingw-w64.sourceforge.net/
23:00:08luislavenadbussink: my results with it: http://gist.github.com/273384
23:00:36luislavenadbussink: I didn't like that WPG is a monolithic package of 2GB uncompressed and useless tools :P
23:00:52luislavenadbussink: (well, not useless, but lot of things that I would not use)