Show enters and exits. Hide enters and exits.
| 00:00:17 | rubuildius_amd64 | Adam Gardiner: 60a6b2003; 1788 files, 6220 examples, 22038 expectations, 0 failures, 0 errors; http://rafb.net/p/SeCufq19.html |
| 00:00:17 | rubuildius_amd64 | Brian Ford: e5480fa09; 1788 files, 6220 examples, 22038 expectations, 0 failures, 0 errors; http://rafb.net/p/mmv15l33.html |
| 00:02:07 | pluskid leaves the room. | |
| 00:02:30 | pluskid enters the room. | |
| 00:07:20 | rubuildius_ppc | Adam Gardiner: 60a6b2003; 1788 files, 6223 examples, 22067 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171297 |
| 00:07:21 | rubuildius_ppc | Brian Ford: e5480fa09; 1788 files, 6223 examples, 22067 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171293 |
| 00:07:22 | rubuildius_ppc | Adam Gardiner: ef616fe2c; 1787 files, 6217 examples, 22057 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171290 |
| 00:07:33 | qwert666 leaves the room. | |
| 00:10:39 | Arjen_ leaves the room. | |
| 00:12:43 | cored enters the room. | |
| 00:13:00 | pluski1 enters the room. | |
| 00:13:19 | crafterm enters the room. | |
| 00:13:45 | pluskid leaves the room. | |
| 00:13:58 | srbaker leaves the room. | |
| 00:14:37 | The_Linux_Lich enters the room. | |
| 00:16:29 | djwhitt enters the room. | |
| 00:19:12 | djwhitt | btw, discussion of fonts earlier prompted me to try a few. conslusion: sgi screen font is really nice if you're on linux |
| 00:21:58 | evan | never seen that one, i don't think. |
| 00:24:03 | FoobarWidget leaves the room. | |
| 00:24:45 | eventualbuddha leaves the room. | |
| 00:26:30 | d2dchat enters the room. | |
| 00:27:42 | macournoyer enters the room. | |
| 00:29:39 | pluskid enters the room. | |
| 00:29:56 | pluskid leaves the room. | |
| 00:30:58 | pluskid enters the room. | |
| 00:36:19 | brainopia leaves the room. | |
| 00:36:57 | dewd leaves the room. | |
| 00:39:40 | rue | djwhitt: That is not bad |
| 00:42:57 | rue | Terrible at <11 but 11, 12 are very nice and crisp |
| 00:45:10 | rue | I will give it a try for a bit |
| 00:46:25 | wdperson enters the room. | |
| 00:48:59 | womble leaves the room. | |
| 00:50:16 | imajes_ leaves the room. | |
| 00:54:22 | mae enters the room. | |
| 00:54:46 | The_Linux_Lich leaves the room. | |
| 00:57:30 | srbaker enters the room. | |
| 00:58:01 | wdperson leaves the room. | |
| 01:10:41 | mae leaves the room. | |
| 01:12:03 | aotearoa enters the room. | |
| 01:18:20 | imajes_ enters the room. | |
| 01:19:24 | benburkert leaves the room. | |
| 01:20:29 | mark___ enters the room. | |
| 01:21:01 | benburkert enters the room. | |
| 01:22:35 | ezmobius leaves the room. | |
| 01:24:06 | benburkert leaves the room. | |
| 01:26:04 | imajes_ leaves the room. | |
| 01:30:16 | AndrewO enters the room. | |
| 01:30:46 | d2dchat leaves the room. | |
| 01:31:49 | srbaker leaves the room. | |
| 01:34:57 | binary42_ leaves the room. | |
| 01:37:35 | antares leaves the room. | |
| 01:40:42 | nicksieger leaves the room. | |
| 01:41:50 | cored leaves the room. | |
| 01:42:39 | srbaker enters the room. | |
| 02:09:18 | dkubb enters the room. | |
| 02:09:29 | mae enters the room. | |
| 02:12:24 | kw_ leaves the room. | |
| 02:16:16 | binary42 enters the room. | |
| 02:22:06 | mae_ enters the room. | |
| 02:22:25 | mae_ leaves the room. | |
| 02:22:58 | mae_ enters the room. | |
| 02:24:16 | VVSiz_ enters the room. | |
| 02:25:54 | KirinDave leaves the room. | |
| 02:27:19 | dkubb leaves the room. | |
| 02:28:52 | _martinS_ leaves the room. | |
| 02:29:48 | aasmith enters the room. | |
| 02:30:03 | dewd enters the room. | |
| 02:32:05 | d2dchat enters the room. | |
| 02:33:43 | dkubb enters the room. | |
| 02:34:17 | lopex leaves the room. | |
| 02:41:10 | kw_ enters the room. | |
| 02:41:25 | dkubb leaves the room. | |
| 02:42:23 | chop3 enters the room. | |
| 02:42:26 | VVSiz leaves the room. | |
| 02:45:11 | mae leaves the room. | |
| 02:45:34 | radarek leaves the room. | |
| 03:02:13 | agile enters the room. | |
| 03:05:07 | mae enters the room. | |
| 03:10:53 | webmat | Has anybody tried the rake install task since Ryan's commit to the Rakefile and stuff? (commit 5dee7377f21dad0aecef82e8f6aa3be9dbd19d28) |
| 03:11:42 | webmat | I can't seem to install from edge tonight |
| 03:12:13 | d2dchat leaves the room. | |
| 03:13:01 | agardiner | may not help, but i never do an install... just run shotgun/rubinius |
| 03:13:06 | benburkert enters the room. | |
| 03:13:36 | rue | webmat: Do you mean it worked after that commit but not currently? |
| 03:14:17 | webmat | the reverse. the 24th's tarball was ok but it does not work anymore |
| 03:15:54 | KirinDave enters the room. | |
| 03:17:23 | macournoyer leaves the room. | |
| 03:19:15 | webmat | And by the way I haven't investigated this in detail, but now the build task seems to depend on the directory being a git repo. Which means it fails when run from a daily tarball. |
| 03:20:15 | webmat | If I remember correctly, I had installed from the 24th's tarball without such a problem |
| 03:20:54 | mae_ leaves the room. | |
| 03:21:05 | cyndis_ leaves the room. | |
| 03:23:38 | cyndis_ enters the room. | |
| 03:28:04 | rue | webmat: Ah, that is quite possible |
| 03:28:24 | rue | Paging Dr. zenspider |
| 03:31:53 | AndrewO_ enters the room. | |
| 03:33:34 | webmat | following agardiner's comment, I'm considering using a small script named 'rbx' to just point to my edge directory's shotgun/rubinius, but then the uninstall task fails as well :-) |
| 03:34:07 | webmat | the problem seems to be that some stuff in ENV is never set. therefore the task complains about having a nil instead of a string |
| 03:34:08 | rue | Heh, it would. We should try to resolve it anyway to avoid issues with lib locations and so on |
| 03:36:53 | KirinDave leaves the room. | |
| 03:37:23 | KirinDave enters the room. | |
| 03:39:54 | evan | webmat: please open a ticket |
| 03:39:59 | evan | so zenspider can fix it |
| 03:40:03 | webmat | yup |
| 03:40:04 | evan | include as much info as possible |
| 03:41:08 | rby enters the room. | |
| 03:42:15 | fbuilesv enters the room. | |
| 03:43:25 | benburkert_ enters the room. | |
| 03:43:25 | benburkert leaves the room. | |
| 03:48:00 | alexvollmer enters the room. | |
| 03:51:07 | KirinDave leaves the room. | |
| 03:52:13 | wycats enters the room. | |
| 03:54:49 | alexvollmer leaves the room. | |
| 04:01:17 | binary42 leaves the room. | |
| 04:03:20 | ttmrichter enters the room. | |
| 04:16:09 | webmat | created ticket 439, don't hesitate to ask for more info. |
| 04:16:20 | webmat | eyes ... burning ... |
| 04:16:24 | webmat | needs sleep |
| 04:17:55 | webmat leaves the room. | |
| 04:37:22 | AndrewO_ leaves the room. | |
| 04:48:44 | mark___ leaves the room. | |
| 04:49:32 | mark___ enters the room. | |
| 04:55:44 | yipstar leaves the room. | |
| 05:02:40 | mark___ leaves the room. | |
| 05:17:22 | ezmobius enters the room. | |
| 05:23:44 | fbuilesv leaves the room. | |
| 05:35:43 | mediogre enters the room. | |
| 05:44:58 | jicksta leaves the room. | |
| 05:47:07 | boyscout | 2 commits by Brian Ford |
| 05:47:08 | boyscout | * Rework and cleanup of various String methods.; 3145a74 |
| 05:47:09 | boyscout | * Shuffle some String methods. Add specs for and rework String#substring.; 9ba3e51 |
| 05:55:04 | rubuildius_amd64 | Brian Ford: 3145a74a8; 1789 files, 6230 examples, 22062 expectations, 0 failures, 0 errors; http://rafb.net/p/qD7rx197.html |
| 05:55:35 | tizianobis enters the room. | |
| 06:01:58 | rubuildius_ppc | Brian Ford: 3145a74a8; 1789 files, 6233 examples, 22091 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171408 |
| 06:03:53 | agile leaves the room. | |
| 06:04:16 | tizianobis_ enters the room. | |
| 06:20:19 | tizianobis leaves the room. | |
| 06:29:24 | tizianobis_ leaves the room. | |
| 06:37:27 | crafterm leaves the room. | |
| 06:39:17 | hassox enters the room. | |
| 06:40:26 | sdeming enters the room. | |
| 06:41:18 | dewd leaves the room. | |
| 06:48:55 | agardiner leaves the room. | |
| 06:53:55 | jartz enters the room. | |
| 07:10:01 | AndrewO leaves the room. | |
| 07:35:37 | rby leaves the room. | |
| 07:39:38 | yaroslav enters the room. | |
| 07:42:56 | ezmobius leaves the room. | |
| 07:50:42 | den1jay enters the room. | |
| 07:51:28 | TheVoice leaves the room. | |
| 07:56:50 | jartz leaves the room. | |
| 07:58:04 | benburkert_ leaves the room. | |
| 08:09:43 | den1jay | hi |
| 08:09:48 | den1jay | anyone awake? |
| 08:11:04 | GMFlash leaves the room. | |
| 08:11:13 | GMFlash enters the room. | |
| 08:13:14 | rue | Yep, aloha |
| 08:14:03 | yaroslav leaves the room. | |
| 08:14:27 | den1jay | :) |
| 08:16:01 | kw_ leaves the room. | |
| 08:17:16 | den1jay leaves the room. | |
| 08:18:15 | jinjing enters the room. | |
| 08:22:51 | den1jay enters the room. | |
| 08:25:34 | srbaker leaves the room. | |
| 08:25:35 | srbaker_ enters the room. | |
| 08:25:53 | den1jay | anyone currently active developing rubinius? |
| 08:27:35 | thehcdreamer enters the room. | |
| 08:32:32 | rue | Most of us, yep |
| 08:32:51 | rue | Unless you mean right this minute? In that case most probably will use some lame excuse like being asleep |
| 08:33:11 | rue | I am, incidentally, just writing some FFI specs |
| 08:34:49 | den1jay | Hi rue |
| 08:34:54 | den1jay | thx for the quick message |
| 08:35:39 | den1jay | can you plz provide me some tips or direct me to some urls where i can find info on how can I start developing rubinius in shortest time possible? |
| 08:39:11 | den1jay | rue: u there? |
| 08:40:13 | rue | I would recommend starting with the wiki-ish pages found on http://rubinius.lighthouseapp.com |
| 08:41:05 | rue | The developer readme has some useful information, it is in the source or you can read it in the repository browser: http://git.rubini.us/?p=code;a=blob_plain;f=README-DEVELOPERS;hb=HEAD |
| 08:42:13 | rue | Largely, though, the specific course will depend on what in particular you want to do? You can write specs or write/fix core and library code or try to get a specific library or application to run or you can work on the VM. |
| 08:42:34 | rue | Among other things. Is there anything that you are interested in doing, specifically? |
| 08:44:18 | den1jay | i am just thinking of porting builder library to rubinius |
| 08:45:37 | zenspider leaves the room. | |
| 08:47:49 | rue | Cool |
| 08:49:07 | rue | The typical process is 1. Try to run the library or its tests; 2. if Rubinius is broken, write a spec for the correct behaviour; 3. fix Rubinius; 4. repeat until library runs flawlessly |
| 08:50:03 | rue | Of course some problems could be things that you cannot fix: in that case it is of course perfectly fine to just omit step 3., someone else will work on fixing it |
| 08:50:08 | context | den1jay. the wiki has a page for starting developing rubinius |
| 08:50:15 | rue | Writing specs for the broken behaviour is important though. |
| 08:50:23 | context | den1jay. with links to books/blog entries to help you on your way of understanding how rubinius works |
| 08:50:50 | den1jay | ok |
| 08:51:01 | den1jay | thx rue and context |
| 08:51:12 | den1jay | I am reading wiki and help doc now |
| 08:56:20 | hassox leaves the room. | |
| 08:59:25 | qwert666 enters the room. | |
| 09:00:33 | mutle enters the room. | |
| 09:05:17 | jartz enters the room. | |
| 09:10:19 | Arjen_ enters the room. | |
| 09:13:23 | octopod enters the room. | |
| 09:20:53 | rue | context: It does? I did not realize that |
| 09:21:55 | dkubb enters the room. | |
| 09:29:31 | dkubb leaves the room. | |
| 09:33:55 | jartz leaves the room. | |
| 09:34:03 | jartz enters the room. | |
| 09:41:25 | antares enters the room. | |
| 09:42:17 | hassox enters the room. | |
| 09:47:13 | antares leaves the room. | |
| 09:48:49 | den1jay leaves the room. | |
| 09:51:34 | Skip enters the room. | |
| 09:58:56 | BlackEdder enters the room. | |
| 10:08:12 | jinjing leaves the room. | |
| 10:08:27 | jinjing enters the room. | |
| 10:11:59 | den1jay enters the room. | |
| 10:39:18 | aotearoa leaves the room. | |
| 10:44:32 | flori enters the room. | |
| 10:51:28 | loop_ leaves the room. | |
| 10:55:46 | pluskid leaves the room. | |
| 10:58:57 | tizianobis_ enters the room. | |
| 11:00:37 | Fullmoon leaves the room. | |
| 11:01:02 | webmat enters the room. | |
| 11:11:44 | tizianobis__ enters the room. | |
| 11:14:11 | tizianobis__ leaves the room. | |
| 11:23:19 | tizianobis leaves the room. | |
| 11:27:50 | Cu9YpD leaves the room. | |
| 11:39:20 | wdperson enters the room. | |
| 11:43:42 | ctennis enters the room. | |
| 11:52:07 | srbaker_ leaves the room. | |
| 11:52:08 | srbaker enters the room. | |
| 11:57:37 | radarek enters the room. | |
| 12:13:31 | chop3 leaves the room. | |
| 12:13:43 | fbuilesv enters the room. | |
| 12:18:32 | imajes_ enters the room. | |
| 12:19:32 | imajes_ leaves the room. | |
| 12:48:57 | mediogre leaves the room. | |
| 12:48:59 | cyndis_ leaves the room. | |
| 13:03:35 | BlackEdder leaves the room. | |
| 13:11:38 | AndrewO enters the room. | |
| 13:18:33 | dkubb enters the room. | |
| 13:28:17 | den1jay leaves the room. | |
| 13:31:48 | d2dchat enters the room. | |
| 13:32:17 | probablycorey enters the room. | |
| 13:34:00 | rue | djwhitt: Good find! I really like this font |
| 13:34:22 | rue | Except for some reason MacVim's line spacing is incorrect |
| 13:35:32 | fbuilesv leaves the room. | |
| 13:35:44 | wmoxam enters the room. | |
| 13:35:57 | rue | Just single quotes too, which is weird |
| 13:39:55 | fbuilesv enters the room. | |
| 13:46:07 | nemerle_afk enters the room. | |
| 13:54:31 | brainopia enters the room. | |
| 13:57:40 | agile enters the room. | |
| 13:59:22 | mae leaves the room. | |
| 14:03:31 | nemerle leaves the room. | |
| 14:05:21 | moofbong enters the room. | |
| 14:06:22 | den1jay enters the room. | |
| 14:07:57 | rue | Hm. I am getting conflicting info on .dylib vs. .bundle |
| 14:11:42 | scoopr | I somehow remember the difference being that dylibs are referenced from mach-o headers and .bundles are more like plugins that are runtime loadable, I could be wrong though |
| 14:13:13 | octopod_ enters the room. | |
| 14:14:09 | rype enters the room. | |
| 14:14:14 | octopod leaves the room. | |
| 14:14:53 | gnufied enters the room. | |
| 14:15:23 | rue | Yeah, it seems that .dylib are "statically linked shared libraries" |
| 14:15:34 | gnufied | hi folks |
| 14:15:40 | rue | And .bundle are "dynamically linked shared libraries" |
| 14:15:43 | rue | Hola |
| 14:17:32 | skaar enters the room. | |
| 14:20:52 | djwhitt | rue: cool, glad you like it |
| 14:21:37 | jney leaves the room. | |
| 14:24:01 | nemerle enters the room. | |
| 14:25:09 | pate_ enters the room. | |
| 14:26:46 | pate | if you're headed to MWRC today ... pack a coat/jacket |
| 14:26:55 | pate | it's started snowing again. :) |
| 14:30:04 | rue | Heh |
| 14:35:07 | nemerle_afk leaves the room. | |
| 14:38:21 | rue | I wonder if this is why drbrain disabled externals |
| 14:42:53 | BlackEdder enters the room. | |
| 14:43:05 | BlackEdder leaves the room. | |
| 14:45:07 | nicksieger enters the room. | |
| 14:46:28 | BlackEdder enters the room. | |
| 14:47:12 | evan | pate_: will do |
| 14:48:19 | rue | You are up early :P |
| 14:49:19 | evan | flying to SLC today |
| 14:49:30 | evan | have to take fog to the kitty hotel first |
| 14:49:43 | anony | Moin |
| 14:49:45 | rue | evan: Quick--ltdl can load either .dylib or .bundle files. We have it hardcoded to .bundle. This may be a problem because it is likely that most of the /usr/lib stuff are in fact .dylibs. This puts Mac at a disadvantage with the .so platforms |
| 14:50:26 | rue | evan: I tried a kitty hotel once. It was ugly |
| 14:50:36 | rue | Hello, anony |
| 14:51:10 | evan | you can't dynamically load .dylibs |
| 14:51:13 | evan | so no |
| 14:51:16 | evan | ltdl can't load them |
| 14:52:03 | rue | I just did |
| 14:52:04 | anony | evan, can't you? |
| 14:52:11 | anony | why can't you, rather? |
| 14:52:22 | evan | the docs clearly say that dylib's not not meant to be used with dlopen() |
| 14:53:08 | rue | I think it goes through dyld |
| 14:53:49 | anony | evan, what docs are you looking at? |
| 14:54:12 | evan | check google for dylib versus bundle |
| 14:54:33 | olabini leaves the room. | |
| 14:54:35 | anony | I looked at the developer docs and it says nothing in there, in fact it uses the dylib path for loading. |
| 14:55:11 | evan | hm |
| 14:55:21 | evan | perhaps i'm thinking legacy |
| 14:55:28 | evan | remember, i started with OS X in 10.0 days |
| 14:55:28 | anony | dlopen |
| 14:55:29 | anony | Loads and links a dynamic library or bundle |
| 14:55:34 | evan | there was a big difference back then |
| 14:55:37 | evan | perhaps there isn't anymore |
| 14:55:39 | anony | :) |
| 14:55:50 | anony | Trust the source, not the nettertubes! |
| 14:55:52 | evan | i vividly recall dlopen() refusing on .dylib's at one point |
| 14:58:09 | anony | That's probably true, I've only been doing OS X programming since 10.2ish |
| 14:58:17 | evan | hm. perhaps it was that you can't link against a .bundle |
| 14:58:27 | rue | I was reading our libltdl, looks like it is OK. |
| 14:58:51 | rue | It just creates a bit of an issue because we need to support both extensions for FFI, I guess |
| 14:59:20 | evan | ah ah! |
| 14:59:21 | evan | i see |
| 14:59:22 | evan | ok |
| 14:59:30 | evan | it has to do with how dyld handles it's symbols |
| 14:59:34 | evan | a .bundle can be unloaded |
| 14:59:36 | evan | a .dylib can not. |
| 14:59:43 | rue | Yeah |
| 15:00:08 | evan | the symbols tables are set up differently, because of the different purposes |
| 15:00:32 | evan | a .bundle is simpler, looks like it just have a simple symbol table with minimual info |
| 15:00:40 | rue | I think I will enable both for now, need to split FFI loading from subtend_find_symbol() though. |
| 15:03:38 | evan | ok |
| 15:03:41 | evan | go for it |
| 15:03:44 | evan | i'm off to the kitty hotel |
| 15:04:05 | rue | Have fun! Give Fog a scratch for me :D |
| 15:04:13 | evan | will do! |
| 15:06:18 | agile leaves the room. | |
| 15:11:28 | imajes_ enters the room. | |
| 15:15:03 | srbaker leaves the room. | |
| 15:15:10 | srbaker enters the room. | |
| 15:20:22 | cyndis enters the room. | |
| 15:26:20 | BlackEdder enters the room. | |
| 15:26:22 | imajes leaves the room. | |
| 15:28:43 | wycats leaves the room. | |
| 15:39:51 | den1jay leaves the room. | |
| 15:53:56 | imajes enters the room. | |
| 15:54:52 | srbaker leaves the room. | |
| 15:55:33 | srbaker enters the room. | |
| 15:55:37 | yipstar enters the room. | |
| 15:55:53 | srbaker leaves the room. | |
| 15:56:25 | srbaker enters the room. | |
| 15:57:15 | srbaker leaves the room. | |
| 15:58:32 | srbaker enters the room. | |
| 16:02:45 | srbaker leaves the room. | |
| 16:08:14 | imajes_ leaves the room. | |
| 16:08:43 | fbuilesv leaves the room. | |
| 16:22:59 | agile enters the room. | |
| 16:24:26 | Arjen_ leaves the room. | |
| 16:25:10 | tobyo enters the room. | |
| 16:31:59 | wycats enters the room. | |
| 16:51:07 | w1rele55 enters the room. | |
| 16:52:06 | wycats leaves the room. | |
| 16:56:53 | JimMc leaves the room. | |
| 16:57:57 | dewd enters the room. | |
| 17:03:16 | mutle leaves the room. | |
| 17:12:44 | dgtized enters the room. | |
| 17:15:02 | gnufied leaves the room. | |
| 17:15:48 | srbaker enters the room. | |
| 17:19:45 | dgtized | so are all of these string changes being benchmarked to ensure they actually speed things up? |
| 17:20:20 | dgtized | they look like they are good, changes, but I'm not noticing any speedup |
| 17:20:43 | dgtized | in fact it seems like the bin/mspec ci is taking steadily longer |
| 17:20:56 | rue | I dunno, that brixen is a sneaky fellow |
| 17:21:52 | djwhitt | dgtized: you're not noticing any speed up when doing what? |
| 17:22:03 | dgtized | I mean if they are just intended as a cleanup that results in temporarily slower performance prior to some really nice optimization then I'm all for it |
| 17:22:08 | dgtized | bin/mspec ci |
| 17:22:10 | djwhitt | ah, ok |
| 17:22:20 | djwhitt | I think if you run the string benchmarks you'll find that they're a lot faster |
| 17:22:24 | dgtized | it's taking about a minute to run now |
| 17:22:35 | dgtized | right but bin/mspec ci is kind of a nice real world usage |
| 17:23:20 | dgtized | so if the spot optimizations are causing a speedup in specific methods that's good, but that doesn't necessarily mean that it corresponds to overall performance |
| 17:23:43 | djwhitt | true |
| 17:24:34 | KirinDave enters the room. | |
| 17:26:29 | TheVoice enters the room. | |
| 17:28:15 | imajes leaves the room. | |
| 17:29:45 | Defiler | Benchmarks in the ticket show a 10x speed improvement |
| 17:29:56 | Defiler | I doubt our bottleneck in ci has much to do with strings |
| 17:30:21 | djwhitt | I think ci is actually fairly io bound |
| 17:30:32 | djwhitt | writing all those dots ;) |
| 17:30:36 | Defiler | hah |
| 17:30:44 | antares_ enters the room. | |
| 17:37:27 | cremes | djwhitt: those dots incur about a 20% overhead on both my ppc mac and intel mac |
| 17:37:54 | cremes | you guys should compare execution times between default "bin/mspec ci" and "bin/mspec ci -fm" |
| 17:38:06 | cremes | -fm suppresses the dots and gains back lots o' speed |
| 17:38:37 | imajes enters the room. | |
| 17:38:53 | probablycorey leaves the room. | |
| 17:38:57 | benburkert enters the room. | |
| 17:39:25 | probablycorey enters the room. | |
| 17:44:22 | djwhitt | yeah, I do that on my rubuildius |
| 17:44:25 | djwhitt | speeds things up a lot |
| 17:47:19 | ezmobius enters the room. | |
| 17:49:04 | dbussink | wondering about how much time is spend in File.stat, anyone ever looked at that? |
| 17:50:16 | srbaker leaves the room. | |
| 17:50:28 | srbaker enters the room. | |
| 17:53:41 | scoopr | damn |
| 17:54:32 | Defiler | dbussink: Yes. Most of the time =( |
| 17:54:57 | evan | fog is happily at her kitty condo, and now i'm waiting at the airport |
| 17:55:51 | benburkert_ enters the room. | |
| 17:56:08 | dgtized | is File.stat just slow because it's FFI instead of primitive or something? |
| 17:56:08 | scoopr | so, theres no one-command-way of building a statically linked shotgun currently, and -pg profiling doesn't play nice profiling dynamic libs (eg. librubinius-*.so), and LD_PROFILE doesn't seem to work. |
| 17:56:38 | evan | dgtized: no, it's using a primitive now anyway |
| 17:56:49 | evan | i'm pretty sure it is at least |
| 17:56:56 | dgtized | evan: doesn't look like it |
| 17:57:02 | dgtized | it's using a pointer to FFI::Struct |
| 17:57:02 | evan | though, i could have gotten lost in the changes to it |
| 17:57:38 | ezmobius leaves the room. | |
| 17:58:16 | evan | that should be fastish |
| 18:00:15 | evan | benchmarks need to be written to verify it |
| 18:00:18 | dgtized | we are a good 3 times slower then MRI on that |
| 18:00:39 | dgtized | running bm_stat anyway |
| 18:00:49 | gnufied enters the room. | |
| 18:01:06 | evan | where is bm_stat? |
| 18:01:15 | dgtized | benchmarks/rubinius/bm_stat |
| 18:01:41 | evan | why the hell is it compiling a file... |
| 18:01:53 | dgtized | evan: good question |
| 18:02:26 | GMFlash leaves the room. | |
| 18:02:34 | evan | maybe at one point, this benchmark compared our stat to a raw C stat |
| 18:02:38 | evan | using that aux program |
| 18:02:47 | evan | use -p when running bm_stat |
| 18:02:58 | dgtized | looks like it from the C program |
| 18:03:12 | evan | oh, it still does |
| 18:03:14 | evan | at the bottom |
| 18:03:31 | evan | thats nice actually |
| 18:04:21 | brixen | djwhitt: http://pastie.org/private/3yx05lijjdh4txyfluba |
| 18:04:31 | brixen | djwhitt: and see #359 |
| 18:04:50 | brixen | I've compared -fd with -fm before and have seen little or no speed difference |
| 18:04:54 | brixen | I'll try it right now |
| 18:04:57 | djwhitt | brixen: did you mean that for dgtized? |
| 18:05:08 | brixen | djwhitt: heh, yeah, sorry |
| 18:05:16 | brixen | tab completion |
| 18:05:21 | brixen | dgtized: see above |
| 18:05:49 | dbussink | the file stat benchmark shows huge diffeerence |
| 18:05:53 | GMFlash enters the room. | |
| 18:06:14 | dbussink | maybe it's beneficial to convert it to a primitive for now, because it's so heavily used (every rbc / rb file that is hit) |
| 18:06:38 | dgtized | brixen: yea I see -- I saw your benchmarks on your ticket afterwards, that does look good -- I just was curious why bin/mspec ci seems to be getting slower at a rate non-proportional to the number of tests in it |
| 18:06:53 | brixen | I've been around and around the File.stat loop, let me look at it again |
| 18:06:58 | dgtized | brixen: and given that you had a lot of string updates I was curious |
| 18:07:04 | djwhitt | dgtized: are you running on Gentoo 64? |
| 18:07:17 | dgtized | djwhitt: no ubuntu hardy |
| 18:07:19 | evan | brixen: please don't rewrite it 8 times while i'm offline over the next week again |
| 18:07:23 | evan | ok plz thxn. |
| 18:07:30 | djwhitt | dgtized: 64 or 32 bit? |
| 18:07:34 | brixen | dgtized: why wouldn't mspec get slower proportional to the number tests it runs? |
| 18:07:49 | brixen | evan: I won't, I'm just trying to avoid people making unfounded assumptions about that area |
| 18:08:00 | dgtized | brixen: it should get slower proprotional, it seemed like it was getting slower at a rate that wasn't proprotional to the increase in spec count |
| 18:08:17 | dgtized | 32bit ubuntu hardy |
| 18:08:18 | brixen | dgtized: well, seems or you have something to show that? |
| 18:08:28 | brixen | dgtized: and, each spec is not constant time |
| 18:08:42 | brixen | the ipaddr and socket specs have taken a long time |
| 18:08:44 | djwhitt | dgtized: never mind then, seen weird stuff on 64 bit |
| 18:09:22 | dgtized | brixen: true, but I've been paying attention to spec checkin's too and it didn't seem like anything would be rediculously slow -- I just no that yesterday bin/mspec was going at around 40-50 seconds and now it's going at 55-65 |
| 18:09:46 | gnufied leaves the room. | |
| 18:10:07 | brixen | bin/mspec ci => 41 sec; bin/mspec ci -fm => 39 sec |
| 18:10:14 | evan | did anything get found out about the be_empty problem? |
| 18:10:22 | brixen | I'd like to see someone else run that and show some numbers |
| 18:10:25 | brixen | evan: nope |
| 18:10:49 | brixen | evan: it only manifests that I can see on 64bit, and I have (conclusively to my mind) ruled out the be_empty matcher |
| 18:10:51 | evan | printing to the terminal will always be slower than not, esp. while we have totally unbuffered writing |
| 18:10:58 | evan | thats one syscall per . |
| 18:11:00 | brixen | I can reproduce it with that code commented out |
| 18:11:02 | benburkert leaves the room. | |
| 18:11:02 | djwhitt | evan: we figure out that Generator is screwed up |
| 18:11:20 | dgtized | brixen: that's your machine, and I'm sure it will be different from mine, what should be similar is that mine became slower over the past couple of days at a rate that didn't match the number of added specs |
| 18:11:21 | djwhitt | evan: takes huge amounts of memory |
| 18:11:28 | evan | ok, to me, it smells like something is up continuations |
| 18:11:47 | evan | since Generator uses them |
| 18:11:53 | brixen | dgtized: I hear you, but I'm not seeing it. I can try on ubuntu 32bit and gentoo 64 if you give me two commit hashes |
| 18:12:05 | evan | i think this a good time to let the rest of you know that i'm in the middle of a massive VM cleanup |
| 18:12:07 | djwhitt | evan: I wrote this ticket about the 64 bit issues http://rubinius.lighthouseapp.com/projects/5089/tickets/434-slow-ci-runs-on-gentoo-54#ticket-434-3 |
| 18:12:32 | evan | snapping off pieces and getting 100% test coverage on them as I go along |
| 18:12:39 | pate | hey evan, are you EY guys heading to SLC together? do you know when you'll get here? |
| 18:12:43 | evan | and it's being transitioned to C++ |
| 18:12:49 | scoopr | o_O |
| 18:12:52 | djwhitt | evan: C++ really?!? |
| 18:12:58 | evan | pate_: i'm not with other EY people, no. |
| 18:13:08 | evan | pate_: I'm arriving at 4pm |
| 18:13:44 | evan | djwhitt: yep, i think my reasoning is sound. It's that using an OO language allows us to match the VM to the semantics of the ruby much easier |
| 18:14:00 | evan | for instance, the VM now has a Hash class, which has methods just like the ruby one |
| 18:14:07 | dgtized | brixen: let me a do a little testing, I am basing this on memory, and not written numbers so it's possible I misremembered |
| 18:14:08 | djwhitt | yeah, I don't have a big problem with C++. just surprised |
| 18:14:36 | evan | the idea is to use small parts of STL |
| 18:14:44 | evan | and simple C++ |
| 18:14:55 | evan | to help make the VM more modular |
| 18:15:09 | evan | it's already helped me make the GC a ton cleaner |
| 18:17:00 | evan | i know some people see C++ as terrible, and for quite a while so did I |
| 18:17:00 | evan | but it's a tool like any other |
| 18:17:05 | evan | with it's ups and downs. |
| 18:17:17 | evan | ozy`: thats the spirit! |
| 18:17:18 | brixen | I think it's important for folks to have a realistic understanding of our current performance profile. I've profiled entire mspec ci runs at a high resolution (10,000 sps) and our profile is extremely flat |
| 18:17:25 | evan | next stop, FFI in fortran! |
| 18:17:42 | brixen | IOW, nothing contributes much more than a few percent to the whole time |
| 18:18:01 | djwhitt | I don't think C++ is terrible. it's just abused |
| 18:18:04 | djwhitt | a lot |
| 18:18:16 | evan | ozy`: so, i'll put you down to work on that then? :) |
| 18:18:40 | evan | djwhitt: yes, it is. my hope is to avoid as much abuse that others do as possible |
| 18:18:49 | evan | i've been reading a lot of C++ style guides and such |
| 18:18:50 | scoopr | I'm also fine by c++, but being a developer in game industry kinda forces me being at least passable c++ coder :/ |
| 18:18:58 | evan | and not much C++ code itself |
| 18:19:10 | evan | and using the simplest things I can |
| 18:19:38 | scoopr | for all kinds of cornercases etc. I like reading http://www.parashift.com/c++-faq-lite/ |
| 18:19:40 | evan | for instance, i don't forsee using any templates |
| 18:19:47 | evan | scoopr: thats what I read through |
| 18:19:54 | scoopr | aight |
| 18:20:11 | brixen | btw, if someone wants to investigate perf with File.stat, look into why File.stat is called like 12 times for each file required. that's what I was observing |
| 18:20:18 | scoopr | yeah, templates wouldn't probably make much sense in a vm, except maybe some collection stuff |
| 18:20:40 | evan | scoopr: i've used templates in so far as vector requires you to use the vector template |
| 18:20:57 | scoopr | and that's probably just enough |
| 18:20:57 | evan | my thinking is that STL provides a body of functionality in the same way the ruby kernel does |
| 18:21:14 | evan | lean on it a bit to make things easier |
| 18:21:22 | evan | don't reinvent every wheel |
| 18:21:23 | scoopr | std::vector backed Array? =) |
| 18:21:27 | evan | ha no. |
| 18:21:37 | evan | std::vector is only used internal to the VM |
| 18:21:59 | evan | no std classes at all are used to implement actual ruby objects |
| 18:22:04 | evan | it's just to make implementing the VM easier |
| 18:22:40 | evan | there are few more changes coming down the pike |
| 18:22:45 | evan | that will show up in the new VM |
| 18:23:26 | evan | the call convention changes have eliminated all instructions that pushed an unknown number of items on the stack |
| 18:23:30 | scoopr | somewhat related, I have a tiny request ;) |
| 18:23:39 | evan | so the compiler can now properly calculate max stack size |
| 18:23:44 | djwhitt | evan: I assume you've seen this: http://www.sgi.com/tech/stl/ |
| 18:24:05 | evan | and so i'm going to try moving towards more ST style MethodContexts |
| 18:24:10 | evan | where each MC has it's own stack |
| 18:24:24 | evan | sized to what the compiler calculated the method required |
| 18:24:29 | scoopr | in ruby Float is usually implemented as double. would it be too much trouble to make that configurable, say typedef double rb_real; or so? |
| 18:24:29 | thehcdreamer leaves the room. | |
| 18:24:36 | evan | that will make Task much more lightweight |
| 18:25:19 | evan | and should (hopefully) eliminate the Continuation/Task problems that continue to plague us |
| 18:25:35 | evan | i'm realizing that the one-stack-per-Task idea is really too complicated |
| 18:27:26 | evan | scoopr: sure, thats doable |
| 18:27:31 | evan | scoopr: may I ask why? |
| 18:28:44 | scoopr | porting to platforms that don't have native double, or specialcases where precision doesn't matter (*cough* games) |
| 18:28:55 | evan | :) |
| 18:28:56 | evan | sure. |
| 18:29:06 | evan | what other types might it be? |
| 18:29:07 | evan | float? |
| 18:29:13 | scoopr | float, yeah |
| 18:29:27 | evan | sure, i'll typedef it out. |
| 18:29:37 | Defiler | evan: That change should make it easier to write tests for the state of the stack, sounds like |
| 18:29:46 | evan | Defiler: very much so |
| 18:29:49 | Defiler | (one stack per MC) |
| 18:30:10 | Defiler | I have been worried about that for a while.. we don't have a lot of insight into what the stack is meant to look like after a break or return, say |
| 18:30:16 | evan | so, one problem with the current arch is that if you copy an MC |
| 18:30:30 | evan | that MC still has indexs into the one stack shared with the original |
| 18:30:47 | evan | and if the original returns back up the stack... the copy loses it's data |
| 18:30:49 | evan | and all hell breaks loose |
| 18:30:57 | evan | which is just a stupid. |
| 18:31:13 | NoKarma enters the room. | |
| 18:31:23 | NoKarma | Heya all |
| 18:31:26 | evan | by having each MC it's own stack, then when you copy an MC, it can just copy it's own stack |
| 18:31:36 | NoKarma | brixen: you around? |
| 18:31:36 | evan | and life can happily continue |
| 18:32:14 | brixen | NoKarma: yo |
| 18:32:16 | evan | the plan is to allocate the stacks in the lazy, stack-oriented way that MC's are allocated now |
| 18:32:33 | evan | that should largely help with GC preesure |
| 18:32:37 | NoKarma | brixen: You responsible for the Rubinius GSOC stuff? |
| 18:32:50 | brixen | NoKarma: responsible in what way? |
| 18:33:04 | NoKarma | well, mentoring or something like that :) |
| 18:33:06 | Defiler | evaevCan ou explain why you opted to put the LRE in @lre instead of in, say, a slot on the SendSite? |
| 18:33:10 | evan | one problem now is also that to many parts of the VM have knowledge of the stack |
| 18:33:13 | Defiler | whoa.. keyboard excitement |
| 18:33:25 | brixen | NoKarma: I'm going to sign up as a mentor because it sounds like they need more |
| 18:33:35 | brixen | NoKarma: and I'll help coordinate stuff with participants |
| 18:33:37 | evan | it would be a huge waste of memory in a SendSite |
| 18:33:44 | evan | plus, how would it be found if it were put in a SendSite? |
| 18:34:00 | NoKarma | brixen: I'm intending to participate in this years GSOC |
| 18:34:07 | brixen | NoKarma: ok |
| 18:34:12 | Defiler | Well, ignoring that last part, how would it take up more memory in a SendSite? |
| 18:34:23 | Defiler | It is already the most-frequently-allocated class in the system |
| 18:34:24 | evan | every SendSite would require another slot for an LRE |
| 18:34:28 | evan | which would normally not be used |
| 18:34:50 | evan | but the bigger question is not that |
| 18:34:55 | NoKarma | brixen: And I was just glimpsing through the ruby-related ideas |
| 18:34:56 | evan | it's how would the other machinery find the LRE |
| 18:35:01 | evan | if it's located in a SendSite |
| 18:35:17 | Defiler | Well, we could pass the current sendsite as a pointer on 'state' |
| 18:35:22 | evan | how would it know where to find the SendSite of the send that had the block? |
| 18:35:27 | evan | Defiler: that doesn't work |
| 18:35:30 | evan | because you have to come back to it |
| 18:35:43 | Defiler | Come back to what? |
| 18:35:50 | evan | a block, which could be infinite depth from the send site of the first block |
| 18:35:54 | evan | has to be able to find the LRE |
| 18:36:23 | Defiler | Well, in the trivial case, 'the_lre' could be a field of 'state' |
| 18:36:39 | Defiler | Since the VM already handles the return, it would just keep that field up to date like it does the rest of the 'world' |
| 18:36:45 | srbaker leaves the room. | |
| 18:36:57 | evan | where would it update it from? |
| 18:37:03 | srbaker enters the room. | |
| 18:37:11 | evan | the_lre would constantly have to be swapped in and out |
| 18:37:14 | evan | every method call |
| 18:37:29 | evan | and where would it be swapped in and out from? |
| 18:37:36 | Defiler | A lot of work is already done to achieve that |
| 18:37:49 | evan | not where to swap it in and out from |
| 18:38:04 | evan | don't forget, the LRE code required no VM support |
| 18:38:05 | evan | that was big |
| 18:38:17 | evan | because it keeps the VM small |
| 18:38:26 | Defiler | Yeah. It just keeps appearing as a hugely expensive thing in the profiler |
| 18:38:31 | evan | what does? |
| 18:38:36 | evan | creating one? |
| 18:38:44 | Defiler | allocating and collecting LongReturnException objects |
| 18:39:08 | evan | hm |
| 18:39:27 | Defiler | There are more of them than Strings and Arrays put together, in a CI run, last time I checked |
| 18:39:40 | evan | well, the compiler can help that |
| 18:39:45 | Defiler | The approach is elegant, though |
| 18:39:48 | Defiler | It just seems pricey |
| 18:39:49 | evan | if the compiler looks into the blocks |
| 18:39:54 | evan | it can figure out of an LRE is required |
| 18:40:00 | evan | if there is a return or break, it's needed |
| 18:40:02 | evan | otherwise, it's not |
| 18:40:13 | Defiler | Aah. I will take a look at that |
| 18:40:15 | evan | so the LRE code could be omitted based on the code |
| 18:40:21 | Defiler | I suspect that will help a lot |
| 18:40:59 | brixen | yeah, that seems quite promising |
| 18:41:05 | evan | it might be as easy as using set/get inside the compiler |
| 18:41:09 | brixen | it is indeed the most allocated obj in a CI run |
| 18:41:23 | evan | to allow the block code, as it's processed, to set a property to indicate that it has a break or return |
| 18:41:33 | evan | and have the call then just perform a get() to see if the property was set |
| 18:41:37 | evan | if it was, then use the LRE code |
| 18:41:40 | evan | otherwise, dont |
| 18:42:54 | gnufied enters the room. | |
| 18:45:55 | NoKarma | What are the "hot spots" of rubinus development right now? I'm having exams next week so I had absolutely no time in doing some rubinius related work (or even getting up to date about what you guys have been doing letely) |
| 18:46:50 | brixen | NoKarma: well, working on getting more of stdlib working/spec'd |
| 18:46:53 | cremes | NoKarma: IO specs, REXML specs, YAML specs... fleshing out the core libs |
| 18:46:56 | brixen | other apps, gems, etc |
| 18:47:15 | brixen | NoKarma: rubygems works in rbx now :) |
| 18:47:55 | antares | and brixen did some great String methods performance optimizations |
| 18:48:24 | NoKarma | Woooo! :D |
| 18:48:26 | NoKarma | Sounds cool |
| 18:48:43 | antares | like it is ten times (or so) faster now |
| 18:51:14 | antares | brixen: I want to get myself familiar with FFI. What in the source code is a good way to start? |
| 18:51:31 | brixen | antares_: depends on your question. what are you looking to do? |
| 18:52:10 | antares | brixen: just want to understand how the interface work and document it somewhere |
| 18:52:32 | brixen | ok, have a look at shotgun/lib/subtend in the files with ffi in the name |
| 18:52:43 | brixen | also see MemoryPointer and FFI::Struct classes |
| 18:52:58 | brixen | the stuff in kernel/platform generally |
| 18:53:01 | antares | brixen: thank you |
| 18:53:08 | brixen | sure |
| 18:56:48 | benburkert_ leaves the room. | |
| 18:57:37 | rue | Hey, what's with all the talkin'? |
| 18:57:55 | brixen | totally |
| 18:58:00 | evan | sorry. |
| 18:58:04 | brixen | heh |
| 18:58:12 | evan | well, i should go check my flight status |
| 19:05:13 | TheVoice | where you headed to? |
| 19:06:21 | gnufied | TheVoice, oblivion! |
| 19:08:33 | rue | Or SLC |
| 19:10:11 | NoKarma | brixen: I'm going to send in applications for 2 or 3 of the rubinius-related ideas. You guys can then select the one who is in the greatest need of someone working on it :) |
| 19:10:50 | rue | Hm, do you think they would accept a proposal to provide back rubs to everyone? |
| 19:10:54 | rue | goes to stretch |
| 19:15:21 | benburkert enters the room. | |
| 19:18:28 | brixen | NoKarma: sounds good |
| 19:19:48 | agile leaves the room. | |
| 19:21:34 | NoKarma | rue: Haha |
| 19:23:16 | qwert666 enters the room. | |
| 19:23:39 | VVSiz | hi guys, a question about REXML specs |
| 19:23:55 | VVSiz | seems like the fail on MRI 1.8.6 pl 111 (3 failures) |
| 19:25:03 | obvio enters the room. | |
| 19:26:49 | Defiler | VVSiz: That's not so good. Heh. |
| 19:27:27 | VVSiz | in fact, it's a bit strange. with older MRI (default on Ubuntu 7.10), I see one failure. With pl 111 - three. With the very latest from svn 1.8 branch - zero. |
| 19:28:05 | djwhitt | I think there were actually REXML bugs discovered in the course of writing those specs if I remember correctly |
| 19:28:18 | djwhitt | fbuilesv was working on them |
| 19:29:32 | VVSiz | OK, good. just checking. Ideally it would have been great to pass 100% on official "compatibility" target 1.8.6 pl111 |
| 19:30:50 | antares | VVSiz: there was a discussion on ruby-core about REXML bugs and behaviour AFAIK |
| 19:31:20 | headius enters the room. | |
| 19:31:23 | antares | VVSiz: submit a ticket and assigned it to me. I was me who applied that spec patch |
| 19:31:34 | brixen | VVSiz: well, we need to up "official" to p114 I think |
| 19:31:59 | headius | evening |
| 19:32:05 | brixen | morning |
| 19:32:06 | VVSiz | evening :) |
| 19:32:23 | brixen | ok, technically afternoon :) |
| 19:32:35 | brixen | headius: whereabouts are you today? |
| 19:32:42 | headius | today we are in Prague |
| 19:32:50 | headius | lovely evening, a bit cold, but clear |
| 19:32:51 | VVSiz | brixen: right, pl114 is officially out! OK, I'll upgrade to 114 too. |
| 19:33:02 | brixen | VVSiz: yeah, I need to as well |
| 19:33:19 | brixen | headius: sounds nice |
| 19:34:34 | RyanTM enters the room. | |
| 19:35:54 | VVSiz | antares_: I'll ugrade to pl114 and we'll see whether there are any REXML failures then. thanks! |
| 19:36:11 | antares | VVSiz: yeah I am already compiling p114 |
| 19:36:19 | VVSiz | same here :) |
| 19:36:31 | djwhitt | I'm a Gentoo user we've been on p114 for ages ;) |
| 19:36:36 | VVSiz | and it seems that there are REXML related changes in it |
| 19:36:58 | Defiler | Horrible how many differences there are between 111 and 114 |
| 19:38:22 | headius | brixen: so far so good |
| 19:38:42 | headius | super lagged though, we arrived in amsterdam at 6:30 and have had to just stay awake since |
| 19:39:12 | VVSiz | antares_: hey, no Rexml related failures in pl 114. good. |
| 19:40:57 | djwhitt | VVSiz: ah, looks like all the bugs were wrapped with ruby_bug in the specs |
| 19:41:27 | VVSiz | hmmm, spoke too soon. I actually see 2 failures (previously was filtering them out with JRuby-specific excludes).... |
| 19:42:34 | qwert666__ leaves the room. | |
| 19:43:07 | headius_ enters the room. | |
| 19:45:51 | antares | VVSiz: is there a changelog for p114 in source tarball? |
| 19:46:34 | antares | VVSiz: I am still waiting for make doc, but go ahead and create a ticket if you see failures |
| 19:50:34 | rubuildius_amd64 leaves the room. | |
| 19:51:42 | RyanTM leaves the room. | |
| 19:53:14 | headius leaves the room. | |
| 19:56:23 | benburkert leaves the room. | |
| 19:56:51 | VVSiz | brixen: adding comments to exclusions of the form: ruby-core:55555 fails |
| 19:57:05 | VVSiz | bin/mspec tag -t j --add 'fails(ruby-core:15981)' .... |
| 19:57:18 | VVSiz | actually adds just ':' instead of fails(ruby-core:15981) |
| 19:57:27 | brixen | yeah, don't use : |
| 19:57:33 | VVSiz | :) |
| 19:57:37 | brixen | it's excluding |
| 19:57:46 | brixen | I believe there's a comment to that |
| 19:57:57 | brixen | excluded |
| 19:58:31 | VVSiz | ah, ':' is such a useful thing to have. like in that ruby-core:xxx, or in URLs in comments |
| 19:58:42 | VVSiz | but I get it. I'll use ruby-core-xxxx for now |
| 19:59:13 | antares | VVSiz: what's your resolution on this? Could you comment on http://tinyurl.com/2v23px ? |
| 19:59:20 | brixen | hmm, well if you really need it, I'll change the parser for the tags |
| 19:59:50 | skaar leaves the room. | |
| 20:01:04 | VVSiz | antares_: done. thanks! |
| 20:01:38 | brixen | VVSiz: you need to come up with another character than : to separate tag or tag(comment) from the spec string |
| 20:01:47 | brixen | VVSiz: is it really that big a problem? |
| 20:02:10 | VVSiz | brixen: Understood. Yeah, it's not really that big. |
| 20:02:41 | VVSiz | I thought if that's something trivial to correct, but indeed, there needs to be a char to separate tags from the spec |
| 20:03:16 | brixen | perhaps I could use :: |
| 20:04:15 | djwhitt | another cool thing about dwm |
| 20:04:23 | djwhitt | it's smokin' fast |
| 20:04:42 | djwhitt | they're both similar in speed once they're running, but dwm is so fast to startup |
| 20:04:57 | VVSiz | brixen: if you're thinking of changing the format for excludes, please dont! :) I'll have to update all mine :) |
| 20:05:00 | djwhitt | oops |
| 20:05:03 | djwhitt | wrong window |
| 20:05:07 | VVSiz | :) |
| 20:05:47 | brixen | djwhitt: thanks for the info though :) |
| 20:05:52 | djwhitt | hehe |
| 20:05:53 | djwhitt | yep |
| 20:05:56 | djwhitt | comparing dwm and xmonad |
| 20:06:03 | brixen | VVSiz: well, it's a simple find/replace right? |
| 20:06:10 | brixen | VVSiz: : -> :: |
| 20:06:59 | VVSiz | yeah, indeed |
| 20:08:42 | brixen | VVSiz: well, you say yea/nay then. I've just spec'd it and it seems to work |
| 20:09:00 | brixen | so, you can do: 'tag(this:5555)::Another#method' |
| 20:09:40 | VVSiz | cool, I'm all for it! :) |
| 20:09:51 | brixen | heh, ok, I'll push in a sec |
| 20:10:45 | VVSiz | you're going to update rbx excludes too? if so, please post the one-liner for that :) |
| 20:11:01 | brixen | yeah, I'll update them |
| 20:11:10 | brixen | you're asking me to pull out some sed-fu, huh? |
| 20:11:12 | brixen | hmm |
| 20:11:43 | brixen | first I have to fix the 12 mspec failures this causes in other parts of it :) |
| 20:12:41 | VVSiz | :) |
| 20:13:31 | antares | VVSiz: ok I got it down to 1 failure |
| 20:13:44 | antares | VVSiz: now need to figure out what changed in REXML in p114 |
| 20:14:45 | therealadam enters the room. | |
| 20:15:50 | VVSiz | antares_: if the latest 1.8 branch from svn passes all the tests, maybe we could just mark/exclude those that fail for 114 for now, sooner or later new patch level arrive and it will pass them :) |
| 20:15:51 | brixen | VVSiz: will you be around for a bit? I'm grabbing some lunch (and something for this major headache) |
| 20:16:03 | VVSiz | yeah, I'm here |
| 20:16:09 | brixen | k, bbiab.. |
| 20:16:13 | VVSiz | thanks!! |
| 20:17:09 | antares | VVSiz: hm, failure I have says the whole class is gone or got renamed, no less |
| 20:17:20 | antares | VVSiz: I am looking for a changelog now |
| 20:18:37 | VVSiz | man, I *really* with MRI folks would start using rubyspecs and run them before every change :) |
| 20:19:13 | antares | or get hannibalized by Rubinius :) |
| 20:19:40 | antares | I should have said "or Ruby gets hannibalized" I guess :) |
| 20:22:27 | VVSiz | :) |
| 20:22:30 | w1rele55 leaves the room. | |
| 20:23:39 | headius leaves the room. | |
| 20:23:41 | antares | VVSiz: it was a missing require problem |
| 20:23:47 | antares | should have fixed now |
| 20:23:49 | antares | let me try |
| 20:28:35 | benburkert enters the room. | |
| 20:29:22 | brainopia_ enters the room. | |
| 20:29:52 | brainopia_ leaves the room. | |
| 20:30:28 | brainopia_ enters the room. | |
| 20:31:08 | antares | VVSiz: I should swap existing rexml in lib with a new copy from p114, right? |
| 20:32:46 | VVSiz | antares_: dunno about rubinius impl. I mostly concerned with the specs and the fact that pass on our official MRI. |
| 20:32:58 | VVSiz | so that we could use them against JRuby. :) |
| 20:33:44 | antares | VVSiz: no, I mean we should have new REXML in Rubinius repository |
| 20:33:59 | antares | VVSiz: nevermind, I'll read LH pages once more |
| 20:37:14 | lopex enters the room. | |
| 20:39:29 | olabini enters the room. | |
| 20:40:20 | srbaker leaves the room. | |
| 20:46:01 | brainopia leaves the room. | |
| 20:46:15 | antares | VVSiz: REXML in p114 has a bug: method with 1 argument in constructor signature is called with 2 agruments in rexml/document.rb |
| 20:46:26 | antares | VVSiz: should we tag this as Ruby bug? |
| 20:47:50 | zenspider | antares_: pls report that to ruby-core |
| 20:48:28 | antares | zenspider: sure, will do. Let me try to check out stable branch of 1.8 first and check things there |
| 20:50:51 | srbaker enters the room. | |
| 20:51:54 | ctennis enters the room. | |
| 20:57:38 | antares | In Ruby 1.8 branch (rev 15833) REXML is completely reorganized compared to p114 |
| 20:59:05 | kw enters the room. | |
| 20:59:32 | antares | zenspider: do you think providing failing spec we have as example would be good idea for ruby core? Or should I write a simplest possible example to prove that as a script? |
| 21:00:37 | zenspider | antares_: prolly nicer to provide a minimal repro script and lower the bar for them |
| 21:00:43 | rby_ enters the room. | |
| 21:01:34 | antares | zenspider: roger |
| 21:01:56 | zenspider | tnx |
| 21:04:38 | ndemonner leaves the room. | |
| 21:11:40 | antares | zenspider: ok sent to ruby-core. Should we wrap this example in ruby_bug for now? |
| 21:12:49 | obiejuan enters the room. | |
| 21:15:18 | macournoyer enters the room. | |
| 21:25:27 | boyscout | 1 commit by Brian Ford |
| 21:25:28 | boyscout | * Allow ':' in MSpec tag comments: tag(bug:555):Some#method.; 1da73a0 |
| 21:26:05 | zenspider | antares_: sure, why not? |
| 21:26:19 | brixen | VVSiz: it was much easier :) |
| 21:26:40 | brixen | VVSiz: so, I'm off the hook for the one-liner (which I couldn't easily produce anyway) |
| 21:31:24 | dewd leaves the room. | |
| 21:41:02 | rubuildius_ppc | Brian Ford: 1da73a015; 1789 files, 6233 examples, 22091 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171701 |
| 21:42:02 | rubuildius_amd64 enters the room. | |
| 21:46:20 | antares | brixen: wrapping example into ruby_bug does not save from Wrong number of arguments error, any workarounds? |
| 21:46:51 | antares | brixen: http://tinyurl.com/3c4c8o for more details on what I face with REXML specs |
| 21:47:32 | tizianobis enters the room. | |
| 21:48:34 | brixen | antares_: what's the exmple I'm looking at? |
| 21:49:29 | antares | brixen: REXML::Document#write returns document with transitive support (ruby/1.8/library/rexml/document/write_spec.rb line 33 |
| 21:49:38 | brixen | k, sec |
| 21:50:06 | rubuildius_amd64 | Brian Ford: 1da73a015; 1789 files, 6230 examples, 22062 expectations, 0 failures, 0 errors; http://rafb.net/p/ahRwtH98.html |
| 21:50:19 | brixen | antares_: is that in your local repo? if so, can you pastie me |
| 21:50:30 | brixen | I don't see anything but 'end' on line 33 |
| 21:51:21 | pastie | brixen: http://pastie.org/171706 by antares_. |
| 21:51:59 | AndrewO leaves the room. | |
| 21:52:04 | brixen | antares_: ok, so ruby_bug must be yielding then |
| 21:52:10 | antares | brixen: spec file and backtrace provided, sorry for plain text |
| 21:52:21 | antares | brixen: so tag it I guess? |
| 21:53:46 | brixen | antares_: what system are you running under? |
| 21:53:50 | brixen | rbx or mri? |
| 21:54:06 | brixen | rbx, right? |
| 21:54:11 | antares | brixen: it is rake spec:ci run |
| 21:54:17 | brixen | yeah, ok |
| 21:54:22 | brixen | ruby_bug only guards for MRI |
| 21:54:30 | brixen | so, for rbx, either fix or tag I guess |
| 21:54:50 | antares | brixen: there's not way to fix it now, see the link above |
| 21:55:09 | antares | brixen: ok I'll tag it — need to figure out how to do it though :) |
| 21:55:30 | brixen | bin/mspec tag spec/file/name_spec.rb |
| 21:55:44 | jptix enters the room. | |
| 21:56:22 | antares | brixen: does it tag the whole file? |
| 21:56:29 | brixen | antares_: whatever fails |
| 21:56:50 | brixen | so, I'm still a bit lost. this fails rbx because the spec is for REXML behavior that doesn't exist yet in MRI? |
| 21:57:19 | antares | brixen: REXML is messed up in p114 |
| 21:57:39 | antares | brixen: there are calls to method with "old" arity in the code |
| 21:57:57 | antares | brixen: and in ruby_1_8 branch as of today REXML is *completely* reorganized |
| 21:58:07 | brixen | ahh, I gotcha |
| 21:58:12 | brixen | we're using old REXML |
| 21:58:18 | antares | brixen: so there's no way to fix it before Ruby core team explains what the heck is going on with it |
| 21:58:20 | wmoxam leaves the room. | |
| 21:58:22 | brixen | ok |
| 21:58:34 | antares | brixen: we are using p114 (I do in my repo) |
| 21:58:52 | antares | it is screwed up in 114, before that everything is ok |
| 21:59:01 | brixen | so, you could: bin/mspec tag --add 'fails(see ruby-bug:XXXX)' spec/path/to_file_spec.rb |
| 21:59:39 | antares | brixen: I left a comment in spec, will update it when someone pops up on ruby-core |
| 21:59:48 | antares | ok rake spec:ci now passes |
| 21:59:52 | brixen | k, sounds good. thanks |
| 22:00:50 | moofbong leaves the room. | |
| 22:01:20 | jptix leaves the room. | |
| 22:01:41 | jptix enters the room. | |
| 22:04:43 | hassox enters the room. | |
| 22:05:30 | kw leaves the room. | |
| 22:07:52 | antares | brixen: now a stupid question. How do one use pastie bot (the way you did recently to get pastie from me)? |
| 22:09:11 | boyscout | 1 commit by Michael S. Klishin |
| 22:09:11 | boyscout | * Update stdlib and specs for REXML from 1.8.6 patchlevel 114 (see details!); 6886ec5 |
| 22:09:32 | brixen | antares_: not sure of your question. if you type pastie, it should pm you |
| 22:10:22 | brixen | pastie: for antares_ |
| 22:10:41 | antares | brixen: that's what I was asking about, thanks |
| 22:10:47 | pastie | antares_: http://pastie.org/171721 by brixen. |
| 22:13:07 | KirinDav enters the room. | |
| 22:15:05 | rubuildius_amd64 | Michael S. Klishin: 6886ec585; 1789 files, 6229 examples, 22061 expectations, 0 failures, 0 errors; http://rafb.net/p/HH9N2f74.html |
| 22:15:31 | tizianobis leaves the room. | |
| 22:16:05 | agardiner enters the room. | |
| 22:17:23 | pate_ leaves the room. | |
| 22:17:32 | bitbang enters the room. | |
| 22:19:21 | VVSiz | brixen: very nice. thanks! :) |
| 22:26:15 | KirinDave leaves the room. | |
| 22:28:52 | rubuildius_ppc | Michael S. Klishin: 6886ec585; 1789 files, 6232 examples, 22090 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/171733 |
| 22:34:23 | rue | Haha, awesome |
| 22:35:09 | rue | The download for p114 said "8 minutes remaining" I was thinking "when the hell did Ruby get that big?" and turns out it is coming in at 14kbps :D |
| 22:35:48 | agardiner | sounds like a server may be... busy :-) |
| 22:36:22 | jptix leaves the room. | |
| 22:38:15 | wycats enters the room. | |
| 22:41:26 | NoKarma | wycats: Heya! |
| 22:41:57 | wycats | NoKarma: ltns |
| 22:42:40 | wycats | zenspider: you were looking for me? |
| 22:43:04 | zenspider | wycats: hey you. |
| 22:43:12 | zenspider | you reported something odd about rubygems + hoe? |
| 22:43:48 | wycats | yes |
| 22:44:10 | wycats | if hoe is a dependency of any gem, it tries to connect to rubyforge when you activate the gem |
| 22:44:30 | zenspider | what is "it" ? |
| 22:44:41 | wycats | the wizard behind the curtain |
| 22:44:45 | wycats | here's an example |
| 22:44:48 | wycats | I'm on an airplane |
| 22:44:52 | wycats | I go into my merb directory |
| 22:44:54 | wycats | I type merb |
| 22:44:56 | zenspider | I'm the wizard behind the curtain |
| 22:45:01 | wycats | I get an error about not connecting to rubyforge |
| 22:45:04 | wycats | and I cannot start merb |
| 22:45:09 | wycats | I then go into the gemspec for RubyInline |
| 22:45:12 | wycats | and remove the hoe dependency |
| 22:45:15 | wycats | viola... it works |
| 22:45:47 | twbray enters the room. | |
| 22:46:04 | jinjing leaves the room. | |
| 22:46:09 | zenspider | can you show me that error? pref with actual traceback? |
| 22:46:34 | wycats | ummm... |
| 22:46:45 | wycats | I have to figure out how to replicate it when I have internet ;) |
| 22:46:55 | Arjen_ enters the room. | |
| 22:47:00 | drbrain | haha, viola |
| 22:47:07 | NoKarma | it's voila :) |
| 22:47:16 | wycats | I meant the character in shakespeare |
| 22:47:22 | wycats | sweet Viola |
| 22:48:10 | wycats | zenspider: ideas on how to replicate it with connectivity? |
| 22:48:16 | drbrain | at least it wasn't "wala" |
| 22:48:22 | drbrain | I want to stab those people |
| 22:48:25 | zenspider | so true |
| 22:48:34 | zenspider | I hate wala... they need to be shot |
| 22:48:50 | zenspider | wycats: something like little snitch maybe |
| 22:48:55 | zenspider | or. /etc/hosts |
| 22:49:00 | wycats | good idea |
| 22:49:13 | wycats | and I need to add the hoe dep back in ;) |
| 22:49:55 | zenspider | I am not hitting this |
| 22:50:10 | wycats | ok |
| 22:50:11 | zenspider | so I need a merb project that winds up doing something with PT |
| 22:50:16 | wycats | yeah |
| 22:50:19 | wycats | just install action-args |
| 22:50:21 | zenspider | I added 127.0.0.1 for rubyforge in etc/hosts |
| 22:50:24 | wycats | action-args requires rubytoruby |
| 22:51:09 | zenspider | ?? sudo gem install action-args ? |
| 22:51:58 | hoopy | so do y'all have rails running on mod_ruby yet or what!? </sarcasm> |
| 22:52:08 | hoopy | er mod_rubinius |
| 22:52:12 | drbrain | hoopy: EWRONGCHANNEL |
| 22:52:16 | zenspider | I don't see ANYTHING directly networky in hoe |
| 22:52:20 | wycats | zenspider: sudo gem install merb-more |
| 22:52:29 | zenspider | EDONTBECLEVER |
| 22:52:31 | wycats | hoe doesn't try to connect to rubyforge? |
| 22:52:34 | wycats | via the RubyForge gem? |
| 22:52:43 | wycats | ? |
| 22:52:51 | zenspider | the tasks do |
| 22:52:58 | zenspider | like rake release |
| 22:53:04 | wycats | this was happening simply by activating the gem |
| 22:53:12 | wycats | I wasn't even requiring hoe |
| 22:53:14 | womble enters the room. | |
| 22:53:19 | wycats | I was requiring Ruby2Ruby |
| 22:53:43 | brainopia_ leaves the room. | |
| 22:53:45 | drbrain | as far as RubyGems is concerned, nothing hits the network there |
| 22:53:47 | wycats | lemme see if I can catch the request via little snitch |
| 22:53:53 | wycats | ? |
| 22:54:09 | wycats | it definitely happened |
| 22:54:13 | wycats | let me see if I can reproduce |
| 22:54:23 | zenspider | gak... merb-more is icky! |
| 22:54:33 | wycats | how so? |
| 22:54:48 | wycats | I can try and make it less icky |
| 22:54:59 | zenspider | four hundred gems just installed! |
| 22:55:30 | wycats | gem install merb-more is a convenience |
| 22:55:37 | wycats | the gem in question is merb-action-args |
| 22:55:45 | wycats | we want people to be able to do gem install merb |
| 22:56:08 | wycats | the alternative is Rails... where everything is in one gem |
| 22:56:16 | wycats | take your pick |
| 22:56:22 | zenspider | so, now that this is installed, merb blah; cd blah; merb should repro |
| 22:56:26 | zenspider | ? |
| 22:56:41 | wycats | you have to require merb-more in init.rb |
| 22:56:48 | wycats | or at least merb-action-args |
| 22:56:57 | wycats | I would also make a controller with a method that has action-args |
| 22:57:01 | wycats | def foo(bar); end |
| 22:57:12 | wycats | Little Snitch: "This software requires that you restart your computer. Click restart to complete this installation." |
| 22:57:13 | wycats | whaaaaaa |
| 22:57:44 | zenspider | I assume you mean config/merb_init.rb ? |
| 22:57:50 | zenspider | I added require 'merb-more' |