|
#parrot Parrot 2.2.0 "Like Clockwork" Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: fix line number annotations | Finish GSoC applications Set by moderator on 6 April 2010. |
|||
| sorear | darbelo: Parrot is technically opposed to compacting GC, not morally. Our GC is imprecise because it walks the platform stack without compiler-provided type information. If and when we rewrite Parrot in a language with sufficiently powerful RTTI (most likely Lorito), there's no reason not to move to compaction. | 00:06 | |
| chromatic: I actually finally found the docs in question, so my opinion has moved from "WTF are these people doing?" to "Um, why is the specification of VTABLE_*_keyed in src/ops/set.ops?" | 00:08 | ||
| chromatic | Good, we can fix that. | ||
| ingy | O HAI chromatic | 00:09 | |
| Coke | sorear: see PDD17. | 00:10 | |
| chromatic | ingy | 00:11 | |
| sorear | darbelo: "one-way type inference and peephole optimization for NQP" is sounding more and more good as a project... | 00:12 | |
| dalek | rrot: r45470 | plobsing++ | trunk/src/nci (2 files): regenerate nci thunks |
00:13 | |
| sorear | Coke: Indeed it would be nice if the important parts (shallow copy vs. deep copy) were in the PDDs. | 00:14 | |
| Parrot | 00:16 | ||
| Parrot's own PMCs are inconsistent on this | |||
| it wasn't until I found set.ops that I read that you aren't supposed to assume one or the other, clone liberally | |||
|
00:17
snarkyboojum joined
|
|||
| sorear | (don't mind me, I'm just lost) | 00:22 | |
| plobsing | sorear: how interested are you in your posix frame builder idea? If all you had to do was register a callback (implementable in PIR/whatever), how much work would it be? | 00:24 | |
| sorear | plobsing: 1 week | 00:25 | |
| plobsing: my interest level is inversely proportional to the success level of the libffi/libffcall/C/Invoke/ctype GSoCers | |||
|
00:26
eternaleye joined
|
|||
| japhb | posix frame builder? | 00:26 | |
| plobsing | japhb: use cc (as required by POSIX) at runtime to generate shared libs that are loaded to emulate an in-memory frame builder | 00:29 | |
| dalek | rrot: r45471 | jkeenan++ | trunk/t/library/tap_parser.t: [codingstd] Add coda for .pir files to make test pass. |
||
| plobsing | sorear: do we have GSoC proposals for all of those? | 00:31 | |
|
00:34
mikehh_ joined
|
|||
| kid51 | plobsing: When commit 45473 comes up, can you confirm that I reformatted the documentation correctly? | 00:34 | |
| nopaste | "kid51" at 70.85.31.226 pasted "codingstd failure in include/parrot/nci.h" (8 lines) at nopaste.snit.ch/20220 | 00:36 | |
| Austin | Whiteknight: How's your windows api skillz? | ||
| Whiteknight | Austin: mad skillz | 00:37 | |
| Austin | tt# 1546 | ||
| Whiteknight | oh great, dll hell | 00:38 | |
| x86 or x64? | 00:40 | ||
| Coke | Austin: can I twist your arm to do some more partcl? | 00:43 | |
| Austin | Whiteknight: I'm a simple 32-bit guy, but I don't think this is dll-hell-ish, so much as it is "this is a fundamental problem that applies to all platforms"-ish. | 00:44 | |
| Coke: Sure, what's up? | |||
| sorear | plobsing: I haven't been keeping track. | ||
| Coke | Austin: crap,I think I just figured it out. | 00:45 | |
| nevermind. =-) | |||
| dalek | rrot: r45472 | plobsing++ | trunk (3 files): assert_args(build_call_func) |
00:46 | |
| rrot: r45473 | jkeenan++ | trunk/src/nci/api.c: [codingstd] Reformat documentation so it passes c_function_docs.t. |
|||
| Austin | Bummer, i was hoping for a little horse trading... | ||
|
00:49
snarkyboojum joined
|
|||
| Whiteknight | Austin: on your system is parrot compiled with the flag /Md? | 00:50 | |
| Austin | What do you get if you cross an pachyderm with a rhinocerous? | 00:51 | |
|
00:51
abqar joined
|
|||
| Whiteknight | Austin: could you just nopaste the output of your build? | 00:51 | |
| dalek | TT #1546 created by Austin_Hastings++: Env.pmc fails to link dll in Windows VC build, and probably doesn't work | ||
| TT #1546: trac.parrot.org/parrot/ticket/1546 | |||
| nopaste | "Austin" at 68.37.47.32 pasted "Whiteknight++: Build failure" (65 lines) at nopaste.snit.ch/20221 | 00:52 | |
| Whiteknight | Austin: do you have the commandline args to the compiler? linker args don't help here | 00:59 | |
| nopaste | "Austin" at 68.37.47.32 pasted "touch env.pmc ; make" (84 lines) at nopaste.snit.ch/20222 | 01:00 | |
| dalek | rrot: r45474 | plobsing++ | trunk/src/nci/api.c: make documentation readable with perldoc |
01:02 | |
| rtcl-nqp: 6fba342 | Coke++ | (2 files): Run this test by default. |
01:09 | ||
| plobsing | is there somewhere I can get a list of all current Parrot GSoC proposals? | 01:11 | |
| cotto | plobsing, are you a mentor? | 01:12 | |
| Whiteknight | plobsing: ask dukeleto to become a mentor | 01:14 | |
| then you can see the list online | |||
| cotto | We have a good crop this year, even if nobody else adds a proposal between now and the deadline. | 01:15 | |
| More is always awesomer, but you knew that. ;) | |||
| plobsing | seen dukeleto | 01:16 | |
| purl | dukeleto was last seen on #parrot 5 hours, 14 minutes and 0 seconds ago, saying: Andy: the book "Apprenticeship Patterns" from O'reilly would probably interest you. | ||
| cotto | I think the process involves logging in to socghop.appspot.com/ and requesting to become a TFP mentor. | 01:17 | |
| cotto goes off to a different thing | |||
| kid51 | plobsing: Thanks. make codetest PASS | 01:19 | |
| Coke wonders if he is the only one that reads that url as "SOCK HOP" | 01:23 | ||
| plobsing just realizes there's a g in there. it makes sense now! | 01:24 | ||
| dalek | rrot: r45475 | plobsing++ | trunk (3 files): first cut at hooks for runtime-loadable frame builder |
01:36 | |
|
01:48
mikehh__ joined
01:54
tcurtis joined
02:20
theory joined
|
|||
| tcurtis | Coke: you develop a HLL compiler or two, right? What do you think about a PAST optimization framework for GSoC? | 03:24 | |
| yjh | Is this the right place to ask about a parrot build problem ( on windows ) ? gcc seems to be having problems with the drive letter. I naively tried stripping the drive letters in the makefile, but it didn't work... | 03:29 | |
| plobsing | yjh: this is the right place. I'm not terribly windows-savvy, but I'll try. can you nopaste the build output? | 03:32 | |
| yjh | sure, but the output I dumped to file was from mingw32-make -d... just want the last lines ? | 03:33 | |
| plobsing | whatever you think is relevant | ||
|
03:36
Andy joined,
mikehh joined
|
|||
| yjh | plobsing: paste.lisp.org/display/97540 | 03:37 | |
| Running gcc individually without the leading drive letter doesn't complain. | 03:38 | ||
| plobsing | I notice that the paths are wonky. rakudo ones appear to use '/' whereas parrot stuff seems to use '\\'. I know a lot of tools cope with unix paths on windows, but do they handle mixed ones? | 03:40 | |
| yjh | Yes, I tried fiddling with that and it didn't seem to affect the outcome for the pbc_to_exe part. | 03:41 | |
| chromatic | tcurtis, I'd like to see that. | 03:42 | |
| tcurtis | chromatic, I knew of your interest, but I was wondering which of the GSoC mentors might be similarly interested. | 03:45 | |
| chromatic | I thought I was a mentor. | ||
| I should be; if I'm not, I will be. | 03:46 | ||
| plobsing | yjh: what about case sensitivity? I see C:\\devel and C:\\Devel. Does that matter? I only see 'Devel' in the failure, which seems suspicious. | 03:48 | |
| tcurtis | I was looking at this page www.perlfoundation.org/perl5/index....oc_mentors , but now I notice it only says "possible mentors". | 03:49 | |
| chromatic | I'm happy to mentor that project. | 03:51 | |
| yjh | plobsing : The directory itself is actually title-cased ( "Devel" ). I just tried running gcc with the lower-case name -I"/devel... and it worked. | 03:53 | |
| but I guess this doesn't guarantee there isn't any confusion b/w that portion and the make steps that precede it... | 03:54 | ||
| I can try renaming the directory and re-configuring / making. | 03:56 | ||
| tcurtis | Alrighty, then. I fear I may be over-specifying my timeline, but I suppose it's better that than under-specifying it, especially since I'm explicitly leaving some empty time to handle any problems that have thrown off the schedule. chromatic, are you male? I don't want to misuse pronouns. | ||
|
03:56
janus joined
|
|||
| Austin | tcurtis: he is. | 03:57 | |
| Or the ugliest damn woman I've ever met. | |||
| plobsing | yjh: that appears to be the easy fix. I find it odd that titlecase directories cause the build to fail, but I lack the windows-fu to figure out where the bug is | 03:58 | |
| chromatic | I wouldn't say ugliest, but certainly male. | ||
| Austin | tcurtis: trac.parrot.org/parrot/wiki/Yapc10B...ouppicture | 03:59 | |
| yjh | plobsing : alright, realcleaned and re-making. something else I noticed ( not in pastebin ) is that previous gcc make steps used -I./include instead of the absolute path. | 04:07 | |
| plobsing | yjh: that's it! That happens to be the *first* invocation of pbc_to_exe (as a pbc in this case). That might be the root cause of this failure. | 04:12 | |
| yjh | plobsing : which invocation is the first invocation of pbc_to_exe ? | 04:14 | |
| plobsing | the cc invocation that is failing (and is different from the others) is being invoked as a sub-process of .\\parrot pbc_to_exe.pbc pbc_to_exe.pbc | 04:15 | |
| yjh | hmm... it failed. the -I option is still title-cased, too. | 04:19 | |
| dalek | rrot: r45476 | petdance++ | trunk (3 files): removed unused arg from Parrot_oo_clone_object. Un-reused a loop variable. |
||
| yjh | err, nm, it's not lower-case | 04:20 | |
| plobsing | yjh: the path gets set at configure time. make clean in the parrot directory won't fix it. you need to 'make realclean\\nperl Configure.pl' | 04:21 | |
| yjh | plobsing : yes, I did realclean and re-configure. The Makefile has lower-case dir names. I did move the old Makefile to Makefile.orig, though. The man page says it checks for GNUMakefile, Makefile, and makefile, so not sure what's going on. Going to get rid of the Makefile.orig and re-realclean, etc. | 04:26 | |
| dalek | rrot: r45477 | petdance++ | trunk/include/parrot/misc.h: removed function definition for a function that no longer exists |
05:08 | |
| cotto | plobsing, make reconfig is the same as running realclean then running Configure.pl with the arguments you originally passed to it. | 05:20 | |
| it's a handy shortcut if you have any configure options you care about | |||
| dukeleto | 'ello | 05:21 | |
| the github is up to date again, for now | |||
| parrot mirror on github, that is | |||
| i need to improve the mirror script | |||
|
05:21
hudnix joined
|
|||
| cotto | dukeleto, do the rtems guys know how slow parrot it currently? | 05:22 | |
| It seems that they're excited about getting HLLs on RTEMS (which is great) but they don't mention speed considerations. | 05:24 | ||
| chromatic | plobsing, r45475 gives some warnings about argument type mismatches. | 05:27 | |
| plobsing | I was having trouble making up my mind on the order the arguments should be in. so apparently I didn't :-) | 05:29 | |
| dukeleto | cotto: they are excited about parrot because it allows the possibility of easily adding many dynamic languages to their runtime | 05:30 | |
| cotto: i don't know how concerned they are with "slow-ness". real-time stuff has a different concept of slowness | 05:31 | ||
| cotto | right | ||
| I can definitely see the charm of HLLs for places where RTEMS would be used. They'd be much easier to write and less error-prone. | 05:32 | ||
| or easier to debug than C at least | 05:33 | ||
| ooc, what school is tcurtis going to after high school? | 05:38 | ||
|
05:38
kurahaupo joined
|
|||
| dalek | rrot: r45478 | plobsing++ | trunk/src/nci/api.c: fix order of arguments passed to frame builder callback |
05:40 | |
| sorear | what, google docs has no "view in plain text"? :/ | 05:54 | |
| dalek | rrot: r45479 | chromatic++ | trunk/src/gc/gc_ms.c: [GC] Fixed a compiler warning in gc_ms_allocate_buffer_storage() by removing a |
05:57 | |
| purl | temporary variable is a huge difference, though. | ||
| rrot: r45480 | chromatic++ | trunk/src/debug.c: [debug] Fixed a compilation warning in PDB_cond(). |
|||
| rrot: r45481 | chromatic++ | trunk/src/io/buffer.c: [IO] Removed unnecessary code from Parrot_io_read_buffer(), in the hope that C |
|||
| rrot: r45482 | chromatic++ | trunk/src/pmc/default.pmc: [PMC] Removed compiler warning. |
|||
| rrot: r45483 | chromatic++ | trunk/src/pmc/imageio.pmc: [PMC] Fixed a compiler warning in ImageIO PMC's set_string_native VTABLE. |
|||
| cotto | go play in a tar pit | 05:58 | |
|
06:08
uniejo joined
|
|||
| dukeleto | cotto: i don't know, but tcurtis has a nice proposal and he seems to be on the ball | 06:12 | |
| dalek | rrot: r45484 | chromatic++ | trunk/src/pmc/packfile.pmc: [PMC] Fixed a compiler warning in Packfile PMC's set_string_native VTABLE. |
06:13 | |
| sorear | not all parts of a real-time system have to be real time | 06:14 | |
| dukeleto | sorear: and parrot won't be, until it gets a real time GC or you turn off the current GC via -G | 06:15 | |
| cotto | dukeleto, sure. I'll evaluate his proposal on its own merits (and it has plenty). I'm just curious. | 06:16 | |
| sorear | dukeleto: the current GC is real time, it guarantees to complete in time O(heap size) | 06:17 | |
| if your application requires a one-second deadline, the Parrot GC is fine | 06:18 | ||
| chromatic | Not heap size, but allocated memory size. | ||
| sorear | not even for the sweep? | ||
| chromatic | It's a precise collector, so no. | ||
| sorear | oh right allocated memory | 06:19 | |
| I read "live data size" there | |||
| chromatic | It's not even that though, because we don't have to trace buffer pools. | 06:20 | |
| dukeleto | sorear: our current GC is not real-time | 06:21 | |
| also, there is a spectrum of real-time-ness. you have to specify "at what time interval" | 06:22 | ||
| our current GC may be "real-time" on the order of seconds or tens of seconds, but it definitely is not at smaller time scales | 06:23 | ||
| for short-lived processes, turning off the GC is a perfectly good solution | |||
| for servers, not so much | |||
|
06:37
hudnix joined
|
|||
| chromatic | He. | 06:46 | |
| 1.945% performance improvement in avoiding *one* memset() call. | |||
| dukeleto | t/profiling/profiling.t is still failing on trunk on darwin | 06:49 | |
| msg bubaflub you were the last one to touch the profiling tests. do you know why they are failing on darwin ? | 06:51 | ||
| purl | Message for bubaflub stored. | ||
| dalek | kudo: 4c94d70 | masak++ | src/core/Temporal.pm: [Temporal] removed nanoseconds; chasing spec |
06:55 | |
| dukeleto | what do i do if i want variadic macros in C89? | 06:56 | |
| chromatic | Cry. | ||
| dukeleto cries | 07:00 | ||
| sorear | dukeleto: Wrap the arguments in an extra pair of parantheses and hold your nose | 07:34 | |
| #define DECL(rt, fun, params) rt fun params; | 07:35 | ||
| DECL(int, printf, (const char *, ...)); | |||
| Perl5 uses a form of this to deal with only declaring functions if an ANSI compiler is used | 07:36 | ||
| thankfully Parrot doesn't support K&R | |||
| dukeleto | sorear++ | 07:40 | |
|
07:48
riffraff joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33081), fulltest) at r45484 - Ubuntu 10.04 beta amd64 (g++ with --optimize) | 07:49 | |
| dukeleto | how do I tell what kind of PMC a given PMC is, in C? | 08:00 | |
| chromatic | pmc->vtable->whoami | ||
| It's a STRING | 08:01 | ||
| sorear | pmc->vtable is the most direct way if you just want to check equality | ||
| if you want something human readable, =chromatic | |||
| dukeleto | basically, i want to know if a PMC is a Float, String or Integer PMC | 08:04 | |
| s/Float/Numeric/ | |||
| also, this is via the extend/embed interface | 08:05 | ||
| Parrot_PMC_does looks like it could be useful | 08:06 | ||
| mikehh | only two warnings - declared with attribute warn_unused_result - in compilers/imcc/symreg.c | ||
| dukeleto | Parrot_PMC_inspect sounds interesting as well | 08:08 | |
| Parrot_PMC_isa! that sounds like a win | |||
| sorear | Parrot_PMC_inspect has no semantics | 08:09 | |
| nopaste | "mikehh" at 81.149.189.7 pasted "remaining warnings from g++ build at r45484" (49 lines) at nopaste.snit.ch/20223 | 08:10 | |
| sorear | it's probably only useful for quick hacks, or debugging | ||
| ie Devel::Peek | |||
| dukeleto | sorear: duly noted. I think i will try Parrot_PMC_isa | ||
| are things like Parrot_PMC_i_absolute supposed to be in extend_vtable.h ? | 08:11 | ||
| sorear | I don't think anyone knows how the vtable stuff is supposed to work | 08:13 | |
| Parrot_str_*** is defined in parrot/string_funcs.h | 08:20 | ||
| parrot/string_funcs.h only parses itself if PARROT_IN_CORE is defined | |||
| yet I can use Parrot_str_new in extensions | |||
| what am I missing | |||
| ? | 08:21 | ||
| dukeleto | magic sausage ninjas riding unicorns | 08:23 | |
| sorear | and if the entire string API is supposed to be private, what am I to do with all these STRINGs? | 08:24 | |
| Is there any nice simple way to ask a STRING to turn itself into either ISO-8859-1 or UTF-8, then get a char* base pointer and a byte count? | 08:33 | ||
|
08:36
Khisanth joined
|
|||
| dalek | tracwiki: v10 | mikehh++ | BuildWarnings | 08:40 | |
| tracwiki: remaining warnings from g++ build at r45484</a> | |||
| tracwiki: trac.parrot.org/parrot/wiki/BuildWa...ction=diff | |||
| tracwiki: v162 | mikehh++ | WikiStart | |||
| tracwiki: add BuildWarnings</a> to Development Tasklists | |||
| tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff | |||
|
09:00
janus joined
|
|||
| darbelo | sorear: You have to do it in two steps, Parrot_str_change_encoding() and then Parrot_str_to_cstring() | 09:22 | |
| Oh, and a call to Parrot_str_byte_length() for the length. | 09:26 | ||
| sorear | Parrot_str_to_cstring makes a copy though | 09:28 | |
| I'd like to avoid that if possible, since the function I'm going to pass it to is specced to copy itself | |||
| dalek | parrot: ad7dd1c | dukeleto++ | plparrot.c: Put call to get_typlenbyvalalign in plparrot_push_pgdatatype_pmc |
||
| parrot: 54f7395 | dukeleto++ | (2 files): Start making sausage, i.e. turning PMCs into Datum's. Returning ints back to Postres now works. |
|||
| parrot: d162ea4 | dukeleto++ | t/sql/test.sql: Add tests for TEXT arguments and remove useless casting in test_varchar_* |
|||
| parrot: dca15e4 | dukeleto++ | (2 files): Code cleanup and fix signatures of test_char_* and test_varchar_* tests |
|||
| dukeleto | what is the best way to convert a Parrot_String into a cstring ? | 09:29 | |
| Parrot_str_to_cstring, it seems | |||
| sorear | how portable is .PHONY? | 09:32 | |
| moritz | GNU make only, iirc | ||
| darbelo | dukeleto: Yeah, that's the one. | ||
| sorear: the alternative is to break encapsulation and read from the STRING's internal buffer. | 09:33 | ||
| But that's an evil practice I've tried to rid parrot's core of, and if you do it in a extension I'll shuffle the struct's member daily just to break your code ;) | 09:35 | ||
| sorear | alternatively, you could add a function to allow me to copy the buffer myself | 09:36 | |
| hmm, segfault on global destruction is back | |||
| I was wondering where it went | |||
| dalek | izkost: a39f261 | sorear++ | (2 files): Implement get_pmc_keyed for P5Scalar of a less wrong way to make it happen. |
09:37 | |
| darbelo | Order of destruction bug? | ||
| izkost: 9dfcf49 | sorear++ | build/Makefile.in: Combine nt with test named nt. |
|||
| sorear | darbelo: yes | ||
| order of destruction is critical and cannot be enforced | |||
| darbelo | Meh, they come and go, except when they stay. | 09:38 | |
| sorear | what I'm going to do is to store the interpreter status struct outside of the Parrot heap, and refcount it | 09:39 | |
| so it's guaranteed to last long enough | |||
| stupid idea? | |||
| darbelo | What exactly is the problem? | 09:40 | |
| sorear | segfault during global destruction | ||
| because neither Parrot nor Perl can be trusted to destroy referers before referents | |||
| darbelo | No, I mean what is getting prematurely collected? | 09:41 | |
| purl | okay, darbelo. | ||
| sorear | I think the P5Interpreter PMC, but it's hard to tell just from the -O2 stack trace | ||
| darbelo | Is that pmc intended to live throught the duration of the program? | 09:42 | |
| sorear | generally, yes | 09:43 | |
| darbelo | Hm. Is there just one or many? | ||
| sorear | one | ||
| the preceding two statements will change in the future, at the same time | |||
| darbelo | You could make it a singleton. | 09:44 | |
| sorear | I'm not a fan of the "permanent process-global singleton" pattern | ||
| would that help? | |||
| parrot global destroys /everything/ | |||
| darbelo | You can 'leak' those without worrying about destruction... | ||
| sorear | you can't access the address registry from within a destroy vtable because the addr registry is usually one of the first PMCs to get destroyed | ||
| FIFO destruction order | 09:45 | ||
| ughhhh | |||
| I may have to do that | |||
| deliberately adding memory leaks is a very repugnant concept | |||
| darbelo | Yeah, singleton dynpmcs will segfault if they have active destruciton set. | 09:46 | |
| sorear | why? | ||
| what about non-singleton dynpmcs that are referred to from a singleton non-dynpmc? | 09:47 | ||
| I may need to rethink the entire design; active destruction is critical, and I can't guarantee the dynpmcs will already have been collected at global destroy time | |||
| darbelo | The library where the code for the 'destroy' vtable lives get's unloaded before the destruction of the immortal^Wconstant PMC pool. | ||
| Leaking works, since they are only created once and they live until interpreter destruction anyway. | 09:48 | ||
| sorear | unless somebody creates parrot interpreters in a loop | ||
| darbelo | It's not a solution, I know. But it'll keep you from segfaulting... | 09:49 | |
| sorear | I don't think so | 09:50 | |
| if what you say is true, and dynpmc libraries are unloaded before global destroy | |||
| then I have to leak ALL values | |||
| darbelo | dynpmc libraries are unloaded as *part of* global destroy, IIRC. | 09:51 | |
| Regular dynpmcs ussually avoid this bug. | 09:52 | ||
| sorear | so basically I can't use active destroy in dynpmcs if there is any chance the pmc will survive to global destroy | ||
| darbelo | It's stuff in the constant pools that lives beyond what it should. | ||
| sorear | isn't there only one global destroy? | 09:53 | |
| darbelo | Global destroy, destroys *everything* the key factor is that the order in which things are destroyed ignores dependencies. | 09:54 | |
| sorear | yes | 09:55 | |
| darbelo | The problem I'm describing here (which might not exactly be the one you see.) is due to the fact that the constan pool is destroyed in one go at the very end of the process, not caring if somethign in there hould have died sooner. | ||
| sorear | it's a FIFO destroy, afaict | ||
| the P5Interpreter is created first and it's usually the first to go | |||
| the dynpmc library is loaded before any of the dynpmcs are created | 09:56 | ||
|
09:57
szabgabx joined
|
|||
| darbelo | The dynpmc library is unloaded after the dynpmcs die. Unless one of the dynpmcs is immortal. | 09:57 | |
| The library is unloaded anyway, and then bad stuff happens when the immortal dynpmc has to die. | 09:58 | ||
| sorear | the dynpmc is unloaded when the Library PMC dies | 10:03 | |
| how does Parrot guarantee that Library PMCs die last? | |||
| darbelo | I doesn't, that's our problem. | ||
| sorear | Parrot is not fixable? | 10:04 | |
| darbelo | Nobody has yet put in the effort. The fix is very likely to involve changes to constant and sigleton PMC semantics. | 10:05 | |
| Other than bacek, chromatic and maybe whiteknight, we don't have a lot of people familiar with gc internals. | 10:06 | ||
| sorear | Rakudo has dynpmcs which can survive to global destruction and have active destruction | ||
| Why doesn't Rakudo crash on exit? | |||
| darbelo | Luck? | 10:07 | |
| purl | Luck is red and spotty? | ||
| sorear | :( | ||
| moritz | sorear: because it calls exit() before the end, bypassing global destruction | ||
| sorear | moritz: . . . is this deliberate | 10:08 | |
| moritz | rakudo doesn't implement DESTROY methods | ||
| yet | |||
| darbelo | That's... a workable alternative, I guess. | ||
| moritz | so it doesn't really suffer from it, yet | ||
| sorear | moritz: p6lowlevelsig and mutablevar have active destroy | 10:09 | |
| moritz | darbelo: not really, if you need to flush buffers | ||
| sorear | darbelo: not so much for a library | ||
| moritz | sorear: I meant at the Perl 6 level | ||
|
10:30
clinton joined
|
|||
| bacek | Aloha | 11:11 | |
| Who called my name? | |||
| darbelo | Crap, we broke a commandment. We used the bacek's name in vain. | 11:12 | |
| bacek throw few lightning bolts to random targets | 11:13 | ||
| darbelo | bacek++ # untargetted retaliation. | 11:14 | |
| Infinoid | bacek's wrath is highly parallelizable | 11:30 | |
|
11:36
whiteknight joined
11:37
ruoso joined
11:47
Andy joined
11:55
szabgabx joined
|
|||
| dalek | rrot: r45485 | bacek++ | branches/immutable_strings_part1 (13 files): Mass remove 'dest' parameter in various string manipulation functions |
11:57 | |
|
12:05
mikehh joined
|
|||
| darbelo wonders about the Google Summer of Warnock. | 12:26 | ||
| "Your proposal is very good. There's nothing we would like you to change in it." vs "You proposal is completely uninteresting to us. There's nothing we care about in it." | 12:29 | ||
|
12:33
bluescreen joined
12:34
clinton joined
|
|||
| moritz | darbelo: your "Parrot on RTEMS" proposal looks good, and has got a positive (private) comment already | 12:35 | |
|
12:35
smash joined
|
|||
| smash | hello everyone | 12:35 | |
| moritz | darbelo: the other one got pretty positive comments too. One of them wants more details in the schedule (and I wonder why it's not a comment visible to you) | 12:36 | |
| darbelo | moritz: I see no comments on either proposal. | 12:37 | |
| moritz | Week 2: Normalization algorithm and conversion functions via Unicode fully-decomposed form. -- shouldn't that be "fully composed"? | ||
| darbelo: the private comments are only visible to mentors | |||
| darbelo | moritz: Yes, that should be fully-composed (NFC) | 12:38 | |
| moritz | anyway, I don't agree that there should be more details in the schedule | ||
| it looks fine to me | |||
| darbelo: so both proposals are rather on the "very good" side, not on the "completely uninteresting" side :-) | 12:39 | ||
|
12:40
SamuraiJack_ joined
|
|||
| darbelo | Oh, I got enoug comments from people on IRC to figure there was some interest on NFG. I'm mostly bitching at melange's student UI. | 12:41 | |
| It tell you absolutely *nothing* about what's happening on the other side. | 12:42 | ||
| moritz | darbelo: :-) | ||
| darbelo: as a selfish, non-RTEMS Perl 6 hacker I'd love to see you doing the NFG project | 12:43 | ||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33086), fulltest) at r45485 - Ubuntu 9.10 i386 (g++ with --optimize) | 12:44 | |
| darbelo | Heh, I would be surprised if I landed a TPF slot to work on the RTEMS port. | ||
|
12:45
atrodo joined
|
|||
| darbelo | Originally I had submitted just one proposal to each org. I only submitted the second one to TPF after a suggestion from the RTEMS guys. | 12:45 | |
| moritz | so you have at least three proposals in the running, two of wich are identical? | 12:46 | |
| darbelo | Pretty much, I did some light editing to remove stuff that is obvious to people in the Parrot community and try to get it a little closer to the TPF app template. But I presented the same plan to both orgs. | 12:48 | |
| moritz | seems like a good idea to me | ||
| darbelo | I was kind of surprised that it's allowed. But given that the RTEMS guys suggested it and dukeleto had no problems with it, I'm guessing it's all good. | 12:49 | |
| moritz | I guess if it were forbidden, it would be quite an effort to track down | 12:50 | |
| and it gives people the possiblity to mentor it either organization for such "bridge" projects | 12:51 | ||
| darbelo | Yeah, I can see the benefit to that. | 12:53 | |
| moritz | well, we have other fun too | 12:54 | |
| somebody who mentored last year applies as a student this year | |||
| darbelo | That's an odd situation. | 12:55 | |
| moritz | but again it's "why not?" | ||
| darbelo | Yeah, the presominat attitude from the Google people seems to be 'whatever works for your org' | 12:57 | |
| szbalint | that's certainly flexible. | 12:58 | |
| darbelo | Well except for the guy that stated in the mailing list that he had lied in his application last year, and intended to do the same this year. | 12:59 | |
| Coke | msg tcurtis - Anything that makes the HLLs faster is a good thing from my standpoint. My biggest concern is that it probably won't help anything with 'eval()'. | ||
| purl | Message for tcurtis stored. | ||
| darbelo | Coke: But doesn't eval build a PAST/POST tree just like normal compilation? | 13:00 | |
| szbalint | darbelo: lied about what? | 13:02 | |
| darbelo | I don't recall exactly, someone had a question about a grey-ish area in the elegibility criteria. | 13:05 | |
|
13:05
Andy joined
|
|||
| darbelo | And one guy replied that he could just lie on the application, as that had worked for him last year. | 13:06 | |
| *And* that he was doing it again this year. | |||
| szbalint | ah ok. I tried to look in my GSOC folder, but full text search on lie just brings up "Leslie Hawthorn" :) | ||
| thunderbird should do regexps :) | 13:07 | ||
| darbelo | My recolection of the even is fuzzy. I don't pay that much attention to the students mailing list. | ||
| Ah. Found the thread. | 13:09 | ||
| subject was "Can I do GSoC and another internship at the same time? | |||
| Starting March 24. | |||
| Coke | Andy: trac.parrot.org/parrot/wiki/BuildWarnings (warnings found by various people over time.) | 13:12 | |
| darbelo | szbalint: perl does regexps, if you have your mail in mbox format that's all you need. | ||
| moritz | unless the email is base64 encoded... | 13:13 | |
| Coke | darbelo: yes, it builds it, runs it, and then throws it away. | 13:15 | |
| the PAST optimizations seem better for things that are compiled and saved (and then run multiple times.) | |||
| particle | that depends | 13:17 | |
| tailcall optimizations can be very useful for short programs if they're recursive | |||
| Coke | Yup, I'm not saying there isn't benefit in some cases, just in general. I'd be interested to see benchmarks. | 13:18 | |
| (based on "real world" rakudo or partcl code.) | 13:19 | ||
| moritz | tailcall optimizations are partly remove from rakudo, because some of them make IMCC segfault, or so | ||
| particle | sure, blame it on imcc.... | 13:20 | |
| what's up with pirc? | |||
| bubaflub | msg dukeleto: i did touch t/profiling/profiling.t, but that was only codingstd stuff (line length, no extra spaces, svn-props, etc) | ||
| purl | Message for dukeleto stored. | ||
| darbelo | particle: It's not done? | 13:21 | |
| Coke | particle: andy and... notfound? tried to get pirc to build recently and gave up after a valiant effort. | ||
| particle | ah, rats. | ||
| Coke | I really don't see it taking over for IMCC any time soon. | 13:22 | |
| Coke wonders if he ever added that config option to parrot yet. | |||
| LHF - merge pirc_config back to trunk. | 13:23 | ||
| darbelo | I remember now: It doesn't build with c++ and it breaks every time we run the headerizer. | ||
| particle | ah, well, doesn't build with c++ shouldn't be too hard to fix | ||
| moritz | why did I just read "bacek to trunk"? :-) | 13:24 | |
| Coke wanders off to a meeting. | |||
|
13:26
mikehh joined
13:30
snarkyboojum joined
13:39
ruoso joined
14:04
Andy joined
14:07
ash_ joined
|
|||
| darbelo | Ugh. We need to pull less configure stuff from perl. | 14:07 | |
| bubaflub | darbelo: what should go? (just curious) | 14:17 | |
| mikehh | darbelo: me also | ||
| we get a lot of the compiler stuff from perl | 14:18 | ||
| darbelo | Everithing with _provisional on it's name should go away. | 14:19 | |
| Also a lot of what we get from perl is highly static data that could just as easily be stored on the hints files. | 14:20 | ||
| mikehh | one of the things I think we need to look at is an examination of why things were done in a given way | 14:22 | |
| and if they are relevant to current parrot development | |||
|
14:22
Mokurai joined
|
|||
| darbelo | o, share_ext, a, exe, ar, ranlib, make are all candidates for not getting pulled from perl. | 14:22 | |
| Once we get rid of recursive make calls we'll be able to abliterate all make-related variables too. | 14:23 | ||
|
14:25
SamuraiJack__ joined
14:27
patspam joined
|
|||
| Andy | Is this crazy 2-space-indent switch statement The Right Way It's Done? | 14:43 | |
| darbelo | Andy: where? | 14:44 | |
| Andy | look at line 1530 of src/hash.c | ||
| darbelo | Bleargh. | 14:45 | |
| Andy | yeah | ||
| I fixed it in a couple of places, but it seemed so widespread I thought "Huh. maybe it's a standard I'm missing" | 14:46 | ||
|
14:46
ash_ joined
|
|||
| bubaflub | Andy: the only place i've seen the two-indent thing is in PIR with a label | 14:46 | |
| i.e. your code is 4 spaces in, a label is 2 spaces outdented | |||
| Andy | Labels (including case labels) must be outdented two columns relative to the | ||
| code they label. | |||
| . | |||
| From pdd07 | |||
| bubaflub | but beyond that, i haven't seen it in c stuff, though i don't look too often | 14:47 | |
| Andy | blah | ||
| whiteknight | you shouldn't see it in C, goto considered harmful, etc | 14:56 | |
| I've seen mixed usage in case statements | |||
| darbelo | PDD07: " (including case labels)" | 14:57 | |
| whiteknight | damn you, darbelo | ||
| smarty pants | |||
| darbelo | Technically. All of the ugly code is right, and the rest should be uglyfied. | ||
| bubaflub | you are technically correct -- the best kind. | 14:58 | |
| Andy | I'm going to have to hack the vim strings. | ||
| because I use the vim C indenter all the time. | |||
| darbelo | Or maybe we should repaint the bikeshed^W^W^Wrevise the conding standards. | 14:59 | |
| bubaflub | in other news, 4 hours to the GSoC deadline (i believe) | 15:00 | |
| darbelo | bubaflub: www.timeanddate.com/cou[#]&min=...0&p0=0 | 15:01 | |
| Er, www.timeanddate.com/counters/custom...0&p0=0 | |||
| 14290 seconds ! | |||
| bubaflub | the horror! the horror! | ||
| ash_ | its always amazed me how tacking 1 more zero on to the end of seconds makes it grow at a crazy rate | 15:02 | |
| dalek | rrot: r45486 | petdance++ | trunk (5 files): Removed an unused argument. Fixed consting. |
15:03 | |
|
15:05
theory joined
|
|||
| PerlJam is surprised in a good way when reading tyler curtis' gsoc submission | 15:12 | ||
| whiteknight | PerlJam: yes, it is impressive | ||
| all of our submissions this year are top-notch | |||
| moritz | the parrot ones are pretty good, yes | 15:13 | |
| I'm afraide the perl 6 related are mostly not | |||
| with the notable exception of masak's | |||
| PerlJam | yep | ||
| whiteknight | masak's is very impressive indeed | ||
| bubaflub | cool! | ||
| how do they (Google or TPF) determine how many slots an organization will have? | 15:14 | ||
|
15:14
lucian joined
|
|||
| moritz | bubaflub: all organizations have to make an estimate of how many of the applications are good enough to sponsor... | 15:14 | |
| bubaflub | moritz: ok. | 15:15 | |
| moritz | bubaflub: then google assigns them a number of slots proportionaal to that number, to the ratio of succeeded applications last year, moon phase... | ||
| and in the end ther's a big random number generator | |||
| bubaflub | cryptographically secure number generator? | ||
| darbelo | I think the official term for that was 'Leslie Math' | ||
| particle | actually google draws a circle on the floor, throws the submissions in the air, and any that land outside the circle are thrown out. | ||
| they don't want unlucky students. | 15:16 | ||
| bubaflub | makes sense. | ||
| darbelo | I wonder how I got in last year, then. | ||
| bubaflub | same. | ||
| PerlJam | they don't draw a circle, they use an existing one (one of the "o"s from their name) | ||
| moritz | bubaflub: there's a contingent of ~500 applications that will be sponsored (or at least that's how it was last year) | ||
| darbelo: half of the proposals are rubbish from the start, usually | 15:17 | ||
| bubaflub | so there were about 500 accepted proposals last year? | ||
| whiteknight | 5000 | ||
| moritz | whiteknight: sure? | ||
| purl | But are you sure you're sure? | ||
| whiteknight | moritz: to the best of my recollection | 15:18 | |
| darbelo | moritz: It was a comment on particle's 'only lucky students' method. | ||
| Last year was not my luckiest year ;) | |||
| PerlJam | that would mean google put up about 23 million ... I thought it was more like 3 million | ||
| whiteknight | oh shit, no. My brain is broke | ||
| PerlJam | (dollars) | ||
| whiteknight | 900 in 2007 | ||
| bubaflub | i thought it was closer to a thousand last year | ||
| whiteknight | say about 1000 this year | 15:20 | |
| socghop.appspot.com/document/show/g...r_students | |||
| bubaflub | socghop.appspot.com/document/show/p...llocations - the method behind the madness | 15:22 | |
|
15:29
payload joined
|
|||
| Coke | SOCKHOP! | 15:32 | |
|
15:38
khairul joined
16:06
dngor joined
16:12
SamuraiJack___ joined
|
|||
| darbelo | less than 9450 seconds to 'SOCKHOP' deadline. Everyone panic! | 16:22 | |
| moritz panics | |||
|
16:32
cotto_work joined
|
|||
| dalek | TT #1547 created by petdance++: Mass-update vim modelines | 16:33 | |
| TT #1547: trac.parrot.org/parrot/ticket/1547 | |||
|
16:44
ash_ joined
|
|||
| cotto_work | howdy | 16:45 | |
| purl | salut, cotto_work. | ||
| darbelo | 'sup cotto_work | 16:48 | |
| darbelo is getting bored of the panic. | 16:49 | ||
| dalek | tracwiki: v55 | cotto++ | ParrotQuotes | ||
| tracwiki: darbelo lays down the law | |||
| tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff | |||
| ash_ | anyone have any last minute comments on my GSoC app? docs.google.com/View?id=dfvcbmxs_51fd6qw7zj is a copy of it | 16:50 | |
| moritz | ash_: it's a bit worrying that testing only appears in the last week :-) | 16:52 | |
| ash_: maybe add something that each step will be accompanied by unit tests along the way | |||
| cotto_work | +1 to what moritz said | ||
| ash_ | should i push it to the front of the project? | ||
| moritz | ash_: I'd add it to 'project details' | ||
|
17:02
SamuraiJack1 joined
17:30
ash_ joined
17:51
senf_statt_oel joined
17:59
chromatic joined
18:08
Mokurai joined
|
|||
| cotto_work | Melange needs a gsoc proposal to make it faster than cold molasses. | 18:14 | |
| darbelo | cotto_work: I almost submitted my ideas for 'Make the internet faster.' but I needed to find my own mentor, which I couldn't do on the current, slow, internet. | 18:22 | |
| cotto_work | Yeah. That sounds like a tricky bootstrapping issue. | ||
| darbelo | For next year I'll make sure to mention that speeding up the internet will make melange faster ;) | 18:23 | |
|
18:38
ash_ joined
19:13
riffraff joined
19:27
Mokurai joined
|
|||
| chromatic | www.modernperlbooks.com/mt/2010/04/...rings.html | 19:32 | |
| ... in case I haven't convinced everyone yet. | |||
| PerlJam | heh .. "there's no garbage collection mechanism cheaper than not creating garbage at all." chromatic++ | 19:35 | |
| whiteknight | chromatic: | 19:43 | |
| Ive been loving these posts | |||
| chromatic | Want to see something crazy? | 19:48 | |
| Coke | chromatic: does it involve a commit? | ||
| particle | coke++ | 19:49 | |
| PerlJam | chromatic: did you actually get a 10-15% speed increase? :) | ||
| nopaste | "chromatic" at 173.50.130.127 pasted "Remove a memset(), go 1.945% faster" (96 lines) at nopaste.snit.ch/20227 | ||
| Coke | particle: I was just trying to figure out /how/ crazy we're talking about here. | ||
| particle | "Again, if things go weird, this is the commit to check." | 19:51 | |
| that list keeps growing. | |||
| Andy | chromatic: have you tried PARROT_HOTting gc_ms_allocate_string_header ? | 19:55 | |
| chromatic | I haven't; let me try that. | ||
| Andy | Might be interesting. DUnno. | 19:56 | |
| chromatic | No effect. | 19:58 | |
| Trying another benchmark. | |||
| A tiny degradation. | 20:00 | ||
| cotto_work | Would callgrind care about the delay from page faults? | ||
| chromatic | Cachegrind does measure instruction cache misses. | ||
| We might see more benefit if we compile all of the .c files in a directory into a .o file in a single pass. | 20:01 | ||
| I'm sure the function pointer indirection doesn't help. Sometimes I think some of these pieces of Parrot would benefit more from C++ than anything else. | 20:02 | ||
| Andy | I suspect that PARROT_HOT is only going to be interesting when groups of functions are tagged together. | 20:05 | |
| chromatic | Yeah, but GCC would also have to optimize across modules for that to help. | 20:06 | |
| Andy | I'm thinking that it's the interactions of hot/cold functions | ||
| chromatic | If I'm right about these estimates, we could double Parrot's speed: trac.parrot.org/parrot/wiki/Perform...provements | 20:25 | |
| dalek | tracwiki: v1 | chromatic++ | PerformanceImprovements | 20:27 | |
| tracwiki: sixteen performance improvement suggestions | |||
| tracwiki: trac.parrot.org/parrot/wiki/Perform...ction=diff | |||
| cotto_work | chromatic: is the garbage-first gc related to the sweep-free gc? | 20:29 | |
| chromatic | No. | 20:30 | |
| We can, in theory, create the sweep-free GC at any time with the current system. | |||
| The G1 GC probably requires larger changes throughout the system. | 20:31 | ||
|
20:31
joeri joined
20:32
Austin joined,
payload joined
|
|||
| Coke | chromatic: config_lib.pbc is loaded all the time, not just on demand? | 20:33 | |
| chromatic | I believe so. | 20:34 | |
| Coke | (and do you mean config_lib.pasm ? config.fpmc?) | ||
| chromatic | config.fpmc, I think. | ||
| One of the root globals triggers its loading. | |||
| Coke | I think it's only loaded if you load 'config.pir' | 20:36 | |
| darbelo | $P0 = getinterp | 20:38 | |
| $P1 = $P0[.IGLOBALS_CONFIG_HASH] | |||
| chromatic | That's the one. | ||
| particle | ain't it baked-in? i thought miniparrot was the only parrot without config baked-in | ||
| Coke | darbelo: danke. | 20:39 | |
| particle | PARROT and PARROT_INSTALL always have config info | ||
| Coke | chromatic: you should know I just eliminated several dozen entries from that with the warnings cleanup. | 20:40 | |
|
20:40
TiMBuS joined
|
|||
| Coke | s/just/in the past ... month?/ | 20:40 | |
| chromatic | src/parrot_config.c | ||
| darbelo | And fo the record, config.fpmc is loaded and *thawed*, wether that is the faster way to do it hasn't been benchmarked. | ||
| Coke | easy win, kill everything with _provisional. | ||
| not every bit of information determined at Configure time belongs in config. | 20:42 | ||
| chromatic | There are some 250 key/value pairs in that hash. That's 500 strings. | ||
| Coke | (like, the specific entries for warnings, I'd wager. does someone running parrot need to know what the warnings flags used to compile src/gc/api.c were? | ||
| darbelo | Does someone running parrot need to know how 'cp' was invoked? | 20:43 | |
| Coke | no, but someone building an extension could. | ||
| (though arguably they should be using parrot itself for that.) | 20:44 | ||
| chromatic | I'm sure we could remove 50 entries with little fuss. | ||
| Possibly 100. | |||
| darbelo | Coke: The cp, that built parrot might or might not be the same cp that is available where the extension is getting built. | 20:45 | |
| plobsing | If we're looking to slim down config, last I checked it was a Hash of string *PMCs*. Thaw should run much faster if it were a Hash of parrot strings. | 20:47 | |
| chromatic | That's an easy change. | 20:48 | |
| darbelo | plobsing: Really? set P0["as"], "as" | ||
| plobsing | when I was doing freeze thaw, it was one of the only really big structures that gets passed through there in build/test. It was a Hash of PMCs | 20:49 | |
| unless hashes got smart since then | 20:50 | ||
| Coke | added trac.parrot.org/parrot/wiki/RemoveU...FromConfig | 20:51 | |
| darbelo: true, but putting in parrot_config hurts little. | 20:52 | ||
| (putting in config.fpmc is silly.) | |||
| darbelo | Split up the hash? | 20:54 | |
| Small one get's put into the interpreter, big one into the executable? | 20:55 | ||
| chromatic | Hm, making the hash use string values gives a freeze error. | 20:57 | |
| Coke | (if we had a small, defined set of keys, we could convert the keys to all be ints.) | 21:00 | |
| dalek | tracwiki: v2 | coke++ | PerformanceImprovements | ||
| tracwiki: trac.parrot.org/parrot/wiki/Perform...ction=diff | |||
| tracwiki: v1 | coke++ | RemoveUnnecessaryDataFromConfig | |||
| tracwiki: trac.parrot.org/parrot/wiki/RemoveU...ction=diff | |||
|
21:06
mikehh joined
|
|||
| plobsing | chromatic: I can probably fix the freeze error, but my pasm-fu is weak. can you nopaste the patch that gives the error? | 21:10 | |
| chromatic | I don't have a good patch for it at the moment, as I turned the PASM into PIR because I don't want to write the PASM to make a method call. | 21:13 | |
| That suggests that we take advantage of pmc_init_int to set the expected key/value type of a Hash during construction. | |||
| ... but I don't have time for that at the moment. | |||
| Though I can nopaste the PIR file. One moment. | 21:17 | ||
| nopaste | "chromatic" at 173.50.130.127 pasted "plobsing: PIR file freeze/thaw culprit" (293 lines) at nopaste.snit.ch/20229 | ||
| plobsing | I tried figuring out how to call a method in PASM, but PCC is one of the places PIR->PASM conversion is lossy | 21:19 | |
| chromatic | The best answer is "don't". | ||
| Coke | Is there a a compelling reason to keep config_lib in pasm? | 21:28 | |
| chromatic | Not to my knowledge. | 21:30 | |
|
21:43
Mokurai1 joined
21:49
tcurtis joined
22:00
rbuels joined
22:05
davidfetter joined,
Mokurai joined
22:06
dolmen joined
|
|||
| dalek | rrot: r45487 | plobsing++ | trunk/src/hash.c: add support for freezing hashes with pmc keys and/or string entries |
22:12 | |
|
22:15
Mokurai1 joined
|
|||
| dalek | ose: r194 | Austin_Hastings++ | branches/austin/src/Slam/ (18 files): Created SlamAst... types (bad names to avoid the last-name problem). Moved |
22:27 | |
|
22:59
Whiteknight joined
|
|||
| Whiteknight | good evening, #parro | 22:59 | |
| that's the phonetic spelling of the French pronunciation of "#parrot" | 23:00 | ||
| darbelo | ORLY? | 23:02 | |
| purl | YA RLY. | ||
| darbelo | If purl says so, it must be true- | ||
| plobsing | NO WAI! | ||
|
23:03
senf_statt_oel left
|
|||
| arnsholt | Whiteknight: But the real word is perroquet =) | 23:10 | |
| dalek | kudo: 43f8659 | (Solomon Foster)++ | src/core/ (4 files): Move to-radians and from-radians from Any to Numeric, make them public. |
23:11 | |
| Whiteknight | The Rakudo IO proposal has potential | 23:14 | |
| has the submission deadline passed? | 23:15 | ||
| darbelo | Yep. | ||
| No more submissions and no more edits. Melange only allows students to comment from now on. | |||
| bacek | Good morning (fsvo "good") | 23:16 | |
| darbelo | fsvo "morning" ;) | ||
| Whiteknight | hello bacek | ||
| bacek | Whiteknight, hello Mr. Whitworth! :) | ||
| darbelo | Hi bacek | ||
| bacek | hi darbelo | 23:17 | |
| darbelo | How are the constant strings going? | ||
| Whiteknight | bacek: :) | 23:18 | |
| bacek | darbelo, in progress. I almost removed all stuff related to COW. No time to remove references to it :) | ||
| darbelo | bacek++ | ||
|
23:29
silug joined
|
|||
| dalek | rrot: r45488 | plobsing++ | trunk/src/pmc/hash.pmc: handle creating storage on thaw of odd typed hashes |
23:34 | |
| plobsing | should 'null $S0' set $S0 to NULL or STRINGNULL? | 23:37 | |
|
23:37
tcurtis joined
|
|||
| plobsing | or how do I get at 'STRINGNULL' in PIR? | 23:37 | |
| cotto | It looks like null $0 does NULL, but it also probably predates STRINGNULL. | 23:56 | |
| cotto goes off to see if it's an easy fix | 23:57 | ||