Camelia, the Perl 6 bug

IRC log for #parrot, 2010-04-21

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 japhb I'm thinking you're now linking against the main libs, then dynloading the X11 libs, and all heck is breaking loose.
00:00 japhb ash_, I will trust your vastly greater experience on this one.  ;-)
00:01 ash_ http://developer.apple.com/mac​/library/qa/qa2007/qa1567.html
00:04 japhb "This is a side effect of various linker improvements in Leopard, which we may be able to mitigate in a future release."
00:04 japhb Yeah.  "improvements".
00:04 ash_ lol, yeah, they broke their linker, i think your right, it might be a linker issue
00:04 Coke Coke is also on OSX 10.6.3
00:04 purl okay, Coke.
00:05 Coke japhb: I never test opengl because it never worked for me. I can start testing it if you want.
00:05 japhb Coke, ash_ (and maybe dukeleto) and I will try to get theirs working, and then I'll want all the testers I can get.
00:06 Coke be nice if you could just run some tests in fulltest.
00:06 japhb I'm guessing that with these fixes, we'll break pre-10.5.  I'm not sure if that's a problem or not.
00:06 japhb Coke, I have no idea how to catch an error like this latest one we've been seeing.
00:07 ash_ I still don't get why parrot wont open /System/Library/Frameworks/OpenGL.framework/OpenGL
00:07 japhb Hmmm, I suppose I could write a magic string on STDOUT in the display routine, to confirm that it actually *got* there.
00:07 japhb In fact, I could write the magic string only after it got there N times, and look for that.
00:07 japhb Hmmmm.
00:07 japhb ash_, I dunno.  Maybe plobsing's NCI changes?
00:08 ash_ how does the loadlib op work?
00:09 japhb wait.
00:09 elmex joined #parrot
00:09 japhb Let's try adding that crap from the last line of the apple Q&A article you sent to the config/auto/opengl.pm lib list
00:09 japhb -dylib_file \
00:10 Coke japhb: we don't support 10.4 anymore, I don't think.
00:10 japhb -dylib_file \
00:10 japhb /System/Library/Frameworks/OpenGL.frame​work/Versions/A/Libraries/libGL.dylib:\
00:10 japhb /System/Library/Frameworks/OpenGL.fram​ework/Versions/A/Libraries/libGL.dylib
00:10 japhb And probably also for libGLU.dylib.
00:10 japhb Then maybe the /System/Library/Frameworks/OpenGL.framework/OpenGL line will work again
00:10 japhb Coke, \o/
00:11 japhb That certainly simplifies things
00:11 ash_ what if you did /System/Library/Frameworks/OpenGL.framework​/Versions/A/Libraries/libGL.dylib:/System/L​ibrary/Frameworks/OpenGL.framework/OpenGL ?
00:12 japhb Dunno.  Try it both ways?
00:12 japhb (Or actually, all three ways.)
00:12 japhb Sigh, four.
00:13 Coke 10.4.0 is from 4/29/05.
00:14 japhb Coke: What about 10.4.last?
00:14 ash_ 10.4 isn't even support by apple anymore...
00:14 ash_ only 10.5 is
00:14 japhb OK, fair enough.
00:14 Coke 10.4.11 is from 14NOV07
00:15 ash_ http://gist.github.com/373258 i think it has to do with loadlib, btw
00:15 japhb I strongly object to supporting operating systems that do not receive security updates from their vendors any more.  So thankfully, we aren't.  :-)
00:15 ash_ that might be an issue
00:16 japhb ash_, and what if you do the full .dylib name within the Frameworks path?
00:17 ash_ works fine
00:17 ash_ the system /System/Library/Frameworks/OpenGL​.framework/Libraries/libGL.dylib loaded fine
00:17 ash_ it might be checking for .dylib
00:17 japhb nod
00:18 ash_ in that case it seems that it might not be a problem with opengl at all, just a problem with loadlib
00:19 * japhb looking at src/dynext.c
00:21 ash_ parrot_split_path_ext seems to be expecting a file extension
00:21 ash_ (i think)
00:25 japhb It looks like at the end of get_path, if all else fails, it should just dlopen_string the path as you asked for it, without any magic.
00:26 ash_ but in Parrot_load_lib it returns Undef (which it appears to be doing) if !path || !handle
00:27 ash_ so both of those end up false for whatever reason
00:28 tetragon joined #parrot
00:28 cotto_work chromatic: do you intend on writing a test to use pbc_dump -n to check line numbers of pir files?
00:29 japhb Looks like parrot_split_path_ext will handle no dot in filename
00:29 japhb AFK, food
00:29 ash_ japhb: i have to head home, i can maybe look into it in more detail later though, and if you need me to test stuff just let me know
00:29 ash_ heading home &
00:30 kurahaupo1 joined #parrot
00:43 chromatic cotto_work, I have no immediate plans.
00:45 dalek tracwiki: v165 | allison++ | WikiStart
00:45 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=165&action=diff
00:45 dalek parrot: r45836 | bacek++ | trunk/t/native_pbc (4 files):
00:45 dalek parrot: Rebuild native pbcs.
00:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45836/
00:52 abqar joined #parrot
00:58 kurahaupo1 joined #parrot
00:59 dalek rakudo: ee9c308 | jonathan++ | src/builtins/Failure.pir:
00:59 dalek rakudo: Fix bug in error reporting of unknown subs (and attempts to invoke other fails).
00:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​e9c30830c78a58a6d391f93a41e46f4db025b45
00:59 dalek rakudo: 483a9da | jonathan++ | src/Perl6/Compiler/Role.pm:
00:59 dalek rakudo: The next step in unbreaking anonymous roles; still some issues, but this gets the basics actually working.
00:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​83a9da322ab24c20e868f71ae997ad6d368d8ef
01:00 bubaflub joined #parrot
01:45 kurahaupo1 joined #parrot
01:57 Psyche^ joined #parrot
01:59 tetragon joined #parrot
02:35 janus joined #parrot
02:51 plobsing_ joined #parrot
02:55 sorear seen pmichaud
02:55 purl pmichaud was last seen on #parrot 1 days, 6 hours, 50 minutes and 23 seconds ago, saying: basically calling dlfunc to grab getpid() from the C lib?  Evil.  :-)  [Apr 19 20:04:47 2010]
02:56 ash_ joined #parrot
03:18 petdance joined #parrot
03:20 bubaflub joined #parrot
03:31 Khisanth joined #parrot
03:32 davidfetter joined #parrot
03:35 cotto It appears that the cprederef runcore didn't make the deprecation notice.  Is it something we care to preserve?
03:35 chromatic Axe it.
03:35 cotto w00t
03:36 chromatic If we have to release 2.3.1 with that in DEPRECATED.pod, I will personally do it.
03:39 cotto I don't think it'll matter that much.
03:39 chromatic I won't tell if you don't.
03:40 chromatic Just don't let the MLB satellite start reading this conversat....
03:40 sorear It might matter if it weren't for the fact that, for some reason, it's not the default even on platforms where it works
03:40 sorear Or do we have a "defaults must be cross-platform" policy?
03:40 chromatic We have a "no dead code" policy.
03:44 petdance ping bacek
04:08 jrtayloriv joined #parrot
04:17 kurahaupo1 joined #parrot
04:44 cotto If someone wants to merge a branch, this might be a good time.
04:44 cotto I'm not sure how disruptive the runcore purge is going to be.
04:46 cotto chromatic, do you think it'd annoy the Rakudo team to commit this directly to trunk?
04:53 cotto nm.  The amount of code that I'll get to rip out is large enough to make a branch worthwhile.
04:57 chromatic I definitely prefer a branch.
05:00 rurban_ joined #parrot
05:02 cotto yeah
05:07 dalek parrot: r45837 | cotto++ | branches/runcore_purge:
05:07 dalek parrot: new branch for nuking unused runcores
05:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45837/
05:08 cotto s/unu/underu/
05:18 cotto What's the point of MANIFEST.orig?
05:19 petdance it's a merge artifact
05:19 bacek_at_work petdance, pong
05:20 petdance what's yr plan for mergin' the immutable branch?
05:20 bacek_at_work tonight
05:20 petdance yay
05:20 bacek_at_work in about 4 hours
05:20 bacek_at_work right after visiting chromatic with baseball bat and cookies
05:20 chromatic Samoas, plz.
05:23 dalek parrot: r45838 | cotto++ | branches/runcore_purge (67 files):
05:23 dalek parrot: [runcore] initial purge; all tests pass, still much newly-dead code to remove
05:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45838/
05:23 dalek parrot: r45839 | cotto++ | branches/runcore_purge/config/auto/cgoto:
05:23 dalek parrot: [runcore] nuke unused dir
05:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45839/
05:39 dalek parrot: r45840 | cotto++ | branches/runcore_purge (14 files):
05:39 dalek parrot: [runcore] remove some dead perl code and references to excised runcores
05:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45840/
05:40 bacek_at_work chromatic, btw, can you revert your last commit in Rakudo's immutable branch (about "strange" substr behavior)? It's not needed anymore.
05:56 dalek parrot: r45841 | petdance++ | trunk/src/pmc/schedulermessage.pmc:
05:56 dalek parrot: marking UNUSED(interp)
05:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45841/
06:06 cotto libparrot.so is 1.2M smaller in branch
06:06 sorear wow, almost an entire pagetable full
06:07 cotto (no stripping for either)
06:18 uniejo joined #parrot
06:20 cotto is the event checking code needed without the prederef cores?
06:24 chromatic bacek_at_work, I can.
06:28 dalek parrot: r45842 | cotto++ | branches/runcore_purge (6 files):
06:28 dalek parrot: [runcore] remove some flags and dependent code
06:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45842/
06:34 Cristina joined #parrot
06:36 Cristina_ joined #parrot
06:38 iblechbot joined #parrot
06:43 kurahaupo joined #parrot
07:00 plobsing_ looking a LexInfo.init_pmc, is there a reason why we require an initializer if we just throw it away?
07:08 cotto If it doesn't appear to make sense, there's a good chance it doesn't.
07:09 cotto chromatic, is turn_ev_check safe to remove?  No tests fail without it.
07:20 dalek parrot: r45843 | cotto++ | branches/runcore_purge (12 files):
07:20 dalek parrot: [profiling] get fulltest passing, remove code related to event checking
07:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45843/
07:23 chromatic I think so.
07:25 cotto There's some code that appears to deal with predereferencing that I'm not especially confident about taking out.
07:26 cotto Is predereferecing only used in the old prederef-related runcores?
07:26 chromatic I think so.
07:26 chromatic If you're not confident, leave it and file a ticket about it.
07:27 cotto ok.  I just noticed that some of it's dead code.
07:31 cotto It's nice having a branch to break stuff in.
07:32 * dukeleto seems to be creating a security layer for PL/Parrot in PIR. This could be interesting.
07:38 dalek parrot: r45844 | plobsing++ | trunk/src/pmc/lexinfo.pmc:
07:38 dalek parrot: eliminate LexInfo.thaw that was almost an exact duplicate of Hash.thaw
07:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45844/
07:38 allison dukeleto: The example is good. PIR-level code can always be ported down to C, if needed for speed.
07:51 dukeleto allison: http://gist.github.com/373558
07:52 dukeleto allison: what are you thoughts on that?
07:53 dukeleto allison: i basically fake out FileHandle and File and tell the interpreter that the PLParrot PMC should be consulted instead
07:56 sorear what happens if somebody maliciously writes a stored procedure to calculate the trillionth decimal digit of pi?
07:58 dukeleto allison: that doesn't seem to protect against using the open opcode directly
07:58 dukeleto sorear: they run out of memory
07:59 sorear oooh, a quota?
07:59 purl a quota is 200mb.
08:01 allison dukeleto: well, the open opcode does open a FileHandle
08:02 allison dukeleto: but there's a possibility that it's opening it by PMC ID, rather than looking up the class in the namespace
08:02 dukeleto allison: perhaps the open opcode keeps the original FileHandle around
08:02 allison dukeleto: (and I'm guessing the namespace is where you did your fakery)
08:03 dukeleto allison: yes. can i modify the PMC ID as well?
08:04 allison dukeleto: no, that's hard-coded in a C enum
08:05 allison dukeleto: you're right that selectively disabling opcodes is a better solution
08:06 dukeleto allison: yes, but the opcodes actually need to be modified, and not just disabled, which makes it more fun
08:06 allison dukeleto: modified how?
08:07 dukeleto allison: for instance, read/write access should be allowed outside of the  $PGDATA directory, disallowed inside
08:07 allison dukeleto: and color me surprised, since the power to modify the opcodes actually opens up more security holes...
08:07 dukeleto allison: allowing read/write inside $PGDATA allows for priveledge escalation and data modification
08:08 dukeleto allison: what about modifying them at parrot compile time?
08:08 allison dukeleto: okay, that's not an opcode feature, that's a FileHandle feature
08:08 sorear and allowing modification of any other file on the system doesn't?
08:08 dukeleto allison: or making file i/o a dynop
08:08 allison dukeleto: and it's a security feature that should be built-in to FileHandle
08:09 allison dukeleto: that is, we need some system-wide way of setting "security level", with behaviors like this enabled or disabled depending on the current level
08:09 dukeleto sorear: normal unix file ownership and permission apply and are correct outside of $PGDATA
08:09 dukeleto allison: that could be interesting
08:09 allison dukeleto: the opcodes are a complete red-herring here
08:10 dalek parrot: r45845 | cotto++ | branches/runcore_purge (10 files):
08:10 dalek parrot: [runcore] remove some prederef-related C code
08:10 dalek parrot: There's still some remaining but removing it breaks some tests
08:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45845/
08:10 allison dukeleto: I mean, some systems may want to completely disable I/O, but the more common approach is what you describe with $PGDATA
08:10 dukeleto allison: so maybe parrot needs a global "threat-level" per interpreter ?
08:11 allison (to allow writing to one safe directory)
08:11 allison dukeleto: essentially, yes
08:11 dukeleto allison: if we totally disable all file I/O, parrot libraries and such cannot be loaded, which is kind of useless
08:11 dukeleto allison: the situation i describe is what DBA's tell me they would want
08:12 allison dukeleto: library loading is completely internal to Parrot, it's not "exposed" I/O
08:12 allison dukeleto: so wouldn't be disabled whatever strategy we took for regular I/O
08:13 sorear what about stuff like Rakudo 'use'?
08:13 allison dukeleto: though, one feature I have seen requested is to allow library loading for a certain period (during startup) and then disabled after that, to prevent malicious library extensions
08:14 allison sorear: Rakudo's 'use' just does a parrot load instruction
08:14 dukeleto allison: interesting. then disabling all I/O may be an option as well
08:14 sorear allison: even when it has to compile .pm ?
08:14 allison sorear: NQP-rx, on the other hand, does read a file to decide what to interpret
08:14 lucian joined #parrot
08:15 allison dukeleto: aye, it's an option, one we should provide
08:15 allison dukeleto: just not the option pg needs
08:15 allison sorear: so disabling regular I/O would disrupt that
08:16 dukeleto allison: i can see that there will need to be different "threat-levels" for various levels of distrust
08:16 allison dukeleto: Josh Berkus requested even more fine-grained feature control
08:16 dukeleto allison: so would FileHandle consult the current interpreters security level and then alter its behavior?
08:17 allison dukeleto: which may be possible through opcode categories and specific opcode disabling
08:17 dukeleto allison: yes, he asked chromatic at the parrot talk at OSBridge last year :)
08:18 allison dukeleto: that's the general idea, yes. Not in the spec yet, and needs some thinking through the details
08:18 allison dukeleto: yeah, I've been talking to him on and off for a few years now
08:18 dukeleto allison: yes, i proposed an API for deciding which group an opcode was in, but didn't get much feedback. Perhaps I will just continue and see if anybody stops me
08:19 allison dukeleto: I didn't see it, try reposting
08:20 dukeleto allison: http://trac.parrot.org/parrot/ticket/1500
08:21 allison dukeleto: ah, a ticket
08:22 dukeleto allison: i sent an email to parrot-dev, but only ::crickets::
08:23 allison dukeleto: I'm better about following parrot-dev now that I just have it in my regular inbox, rather than filed away in a folder
08:23 dukeleto allison: there is also the fact that opcode group info never actually makes it into the interpreter
08:24 allison dukeleto: yes, so there's more work involved than simply adding an interface to access the info
08:24 allison dukeleto: the interface looks fine, but add a three-letter 'sec' prefix after Parrot_
08:25 dukeleto allison: yes. the info is in lib/Parrot/OpLib/core.pm but doesn't make it into op_info_t
08:25 dukeleto allison: will add the sec prefix
08:25 allison they should live in src/security.c or src/security/api.c
08:26 allison dukeleto: there's a chance that storing those strings will slow things down, so it may be a feature that is only turned on when running in a certain security level
08:26 allison dukeleto: ('threat-level' gives me too many bad memories of airport security lines)
08:27 dukeleto allison: yes, i was just joking with that term :)
08:27 allison dukeleto: :)
08:28 allison dukeleto: hey, sometimes jokes stick. Like the name "Parrot", for instance... :)
08:28 dukeleto allison: the strings may take up a bit of memory, but since we just gutted the runcores, it will probably not be noticeable. Making it optional is of course best.
08:31 bacek Hello humans.
08:31 purl hey, what about me?
08:31 bacek Hello, silly bot.
08:31 dukeleto bacek: o hai
08:31 bacek dukeleto, o/
08:37 dukeleto allison: i will think some more and try to make some more tickets about this stuff
08:37 * dukeleto passes out
08:52 cotto trac really needs to send out a diff when someone changes the description in a ticket.
08:56 kurahaupo1 joined #parrot
08:58 dalek parrot: r45846 | cotto++ | branches/runcore_purge (2 files):
08:58 dalek parrot: [runcore] remove some more prederef code that doesn't break tests
08:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45846/
08:58 Khisanth joined #parrot
09:14 dalek parrot: r45847 | cotto++ | branches/runcore_purge/inc​lude/parrot/interpreter.h:
09:14 dalek parrot: [runcore] remove a pair of now-unused structs
09:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45847/
09:20 aukjan1 joined #parrot
09:39 jsut_ joined #parrot
09:45 bacek Looks like plobsing broke lexinfo tests in r45844
09:46 dalek parrot: r45848 | fperrad++ | trunk (2 files):
09:47 dalek parrot: add t/harness.pir
09:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45848/
09:47 dalek parrot: r45849 | bacek++ | branches/immutable_strings_part1 (99 files):
09:47 dalek parrot: Sync branch with trunk.
09:47 dalek parrot: Conflicts:
09:47 dalek parrot: MANIFEST.SKIP
09:47 purl well, MANIFEST.SKIP is bogus. or a bit like .cvsignore
09:47 dalek parrot: compilers/imcc/imcparser.c
09:47 dalek parrot: compilers/imcc/imcparser.h
09:47 dalek parrot: src/string/encoding/ucs2.c
09:47 purl src/string/encoding/ucs2.c is, like, mostly unimplemented
09:47 dalek parrot: t/native_pbc/annotations.pbc
09:47 dalek parrot: t/native_pbc/integer_1.pbc
09:47 dalek parrot: t/native_pbc/number_1.pbc
09:47 dalek parrot: t/native_pbc/string_1.pbc
09:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45849/
09:52 bacek msg plobsing I reverted r45844. We do need LexInfo.init with throwing exception to prevent initialising it from PIR.
09:52 purl Message for plobsing stored.
09:52 moritz so, immutable strings weren't merged yet?
09:53 moritz or are you doing that right now, bacek?
09:53 bacek In progress
09:54 bacek (It's main reason why I spotter test failure with LexInfo :)
09:54 moritz :-)
09:56 clinton joined #parrot
09:58 bacek sigh...
09:58 bacek seen gerd
09:58 purl gerd was last seen on #parrot 23 hours, 23 minutes and 14 seconds ago, saying: The update tag seems not to have to modified NEWS file
10:03 dalek parrot: r45850 | bacek++ | trunk/src/pmc/lexinfo.pmc:
10:03 dalek parrot: Revert "eliminate LexInfo.thaw that was almost an exact duplicate of
10:03 dalek parrot: Hash.thaw". It broke LexInfo tests by changing semantic of LexInfo.init.
10:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45850/
10:07 bacek moritz, merged. r45852
10:08 moritz bacek++
10:09 bacek moritz, do you have svn checkout? MANIFEST.SKIP requires regenerating...
10:09 bacek (It was merged incorrectly)
10:11 moritz bacek: nope, I'm also a git-svn user
10:11 * bacek summon mikehh
10:11 ttbot Parrot trunk/ r45852 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/272712.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
10:11 bacek sigh...
10:11 bacek And fperrad
10:11 bacek fperrad, ping
10:12 fperrad pong bacek
10:12 bacek fperrad, I broke win32 build with immutable_strings merge
10:13 bacek fperrad, basically there is a _lot_ of calls to old version of Parrot_str_substr/concat/append under #ifdef.
10:14 bacek #ifdef WIN32/#ifdef CYGWIN
10:15 fperrad bacek, ok, I'll take a look
10:15 bacek fperrad, thanks!
10:17 bacek fperrad, in the nutshell: str_append removed. You can replace it with str_concat. In old str_concat (with "flags" arg) calls just remove "flags".
10:20 ttbot Parrot trunk/ r45853 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/272759.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
10:20 dalek parrot: r45851 | fperrad++ | trunk/runtime/parrot/library/TAP (2 files):
10:20 dalek parrot: [TAP] fix after r45827
10:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45851/
10:20 dalek parrot: r45852 | bacek++ | trunk (88 files):
10:20 dalek parrot: Everybody freeze! Immutable strings enters the building.
10:20 dalek parrot: Merge branch immutable_strings_part1 back to trunk.
10:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45852/
10:20 dalek parrot: r45853 | fperrad++ | trunk/tools/dev/tapir.pir:
10:20 dalek parrot: [TAP] minor refactor
10:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45853/
10:24 mikehh bacek: you requested my presence :-}
10:24 bacek mikehh, MANI.SKIP need some love :)
10:25 mikehh 'k will have a loop
10:30 mikehh bacek: done
10:32 mikehh was re-reading chromatic's book Masterminds of Programming - gaining even more on this read
10:34 lucian joined #parrot
10:36 dalek parrot: r45854 | mikehh++ | trunk/MANIFEST.SKIP:
10:36 dalek parrot: re-generate MANIFEST.SKIP
10:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45854/
10:40 ttbot Parrot trunk/ r45854 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/272841.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
10:45 JimmyZ joined #parrot
10:54 bacek fperrad, check https://trac.parrot.org/parrot/ticket/1571
10:59 dalek TT #1571 created by jimmy++: [PATCH]patch for building on win32.patch after immutable strings merge
10:59 dalek TT #1571: http://trac.parrot.org/parrot/ticket/1571
11:01 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33359), fulltest) at r45854 - Ubuntu 10.04 beta amd64 (g++ with --optimize)
11:25 dalek parrot: r45855 | bacek++ | trunk/src/dynext.c:
11:25 dalek parrot: Apply patch from TT#1571 to restore build on Win32. JimmyZ++
11:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45855/
11:41 dalek parrot: r45856 | gerd++ | trunk/ports/fedora (6 files):
11:41 dalek parrot: update the Fedora port with the files used to build the current package
11:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45856/
11:48 bacek msg JimmyZ You can set LANG to "C" before creating patch. It will help slightly to someone without "unicode locate" :)
11:48 purl Message for jimmyz stored.
11:57 dalek parrot: r45857 | bacek++ | trunk (111 files):
11:57 dalek parrot: Generate a _lot_ of .gitignore files.
11:57 dalek parrot: We can remove them later. But for now they will help developers who use
11:57 dalek parrot: git to develop parrot.
11:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45857/
12:04 dalek lua: c9f4698 | fperrad++ | dynext/pmc/lua (2 files):
12:04 dalek lua: fix PMC after merge immutable strings
12:04 dalek lua: review: http://github.com/fperrad/lua/commit/c9​f4698ce407cc3265690546f7c1a6378a031b49
12:04 dalek TT #1571 closed by bacek++: [PATCH]patch for building on win32.patch after immutable strings merge
12:04 dalek TT #1571: http://trac.parrot.org/parrot/ticket/1571
12:14 bacek fperrad, ooops. Sorry, I had similar commit for Lua in my git repo, but I forgot about it... My bad...
12:21 bacek afk # sleep
12:22 Coke bacek: AIGH.
12:22 Coke you did not just commit 111 .gitignore files...
12:22 Coke grumble.
12:22 purl grumble. is it typically possible to order replacement laptop keys?
12:29 bluescreen joined #parrot
12:30 particle joined #parrot
12:30 dalek parrot: r45858 | gerd++ | trunk/ports/suse (4 files):
12:30 dalek parrot: add the latest spec file I found for suse packing
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45858/
12:30 Coke msg particle I just composed (and deleted) a followup to your message - I was going to point out that patches rule, and that there's a reason your platform doesn't work (none of us use it), but gave up trying to be diplomatic about it, so I discarded the message.
12:30 purl Message for particle stored.
12:34 iblechbot joined #parrot
12:45 bluescreen joined #parrot
12:46 smash joined #parrot
12:46 smash hello everyone
12:46 Coke ~~
12:47 smash question: can i pass a --cc=... option to parrot's 'perl Configure.pl' ?
12:48 allison what's with all the .gitignore files?
12:48 moritz smash: yes, you can
12:48 moritz smash: see perldoc Configure.pl
12:48 mikehh smash: yes
12:49 smash but inter::progs is complaining about my c compiler
12:49 smash i get 'Compilation failed with....'
12:49 mikehh smash when I build with g++ I use - perl Configure.pl --optimize --test --cc=g++ --cxx=g++ --link=g++ --ld=g++ --maintainer --configure_trace
12:51 arnsholt allison: According to the commit message, it's to make life simpler for those who use git to hack on Parrot
12:51 allison nasty clutter
12:52 mikehh does svn ignore the .gitignore :-}
12:53 moritz well, one .gitignore would be enough for that
12:53 smash mikehh, moritz: ahh, i think the correct question here would be: 'can i cross compile it?'
12:53 allison this seems like the kind of policy we should discuss in #parrotsketch before checking it into the repository
12:53 particle allison: agreed, and i really think it can be handled in one .git/ignore file
12:54 allison particle: that seems saner
12:55 moritz actually you can do  git svn show-ignore > .gitignore
12:56 moritz or even git svn show-ignore > .git/info/exclude
12:57 moritz without adding anything to the repo
12:57 mikehh smash: I think you should talk to NotFound - I think he has done something like that
12:57 tetragon joined #parrot
12:58 particle not .git/info/exclude, that's for one repo (not to be cloned)
12:59 particle need to use .gitignore
12:59 smash mikehh: ok, thks
12:59 particle i thought we could hide it behind a .git dir, but it doesn't seem so.  we'll have to have one .gitignore file in the root
13:00 rurban_ joined #parrot
13:03 allison particle: still an improvement. I've added this to my notes for next parrotsketch to make sure we talk through it
13:03 particle allison++
13:03 smash i must be missing something, but a test file is being compiled, and later executed (during the configure process) and of course that step will fail
13:08 Coke (cross compile) we don't really support that.
13:08 Coke I'd ping dukeleto, as I think he got the initial RTEMS port at least building.
13:08 smash Coke: ah, ok.. thank you
13:10 PerlJam good morning
13:10 purl Good Morning Mr Rogers
13:15 dalek lua: f17b2b7 | fperrad++ | lua/ (2 files):
13:15 dalek lua: fix after http://trac.parrot.org/parrot/changeset/45827
13:15 dalek lua: review: http://github.com/fperrad/lua/commit/f1​7b2b7af2cdc203e8a20ccaa0bb9e15919a089f
13:34 whiteknight joined #parrot
13:46 whiteknight good morning,#parrot
13:51 PerlJam good morning wk
13:53 whiteknight hello PerlJam, how are you doing today?
14:00 PerlJam whiteknight: I'm doing good. Today will be a great day I think.
14:01 dalek parrot: r45859 | fperrad++ | trunk/compilers/pge/PGE/Exp.pir:
14:01 dalek parrot: [PGE] add a :nsentry (needed by Lua regex)
14:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45859/
14:01 Andy I like building with g++ so much more than gcc
14:01 whiteknight "great" day? that's pretty good. Better than good, in fact
14:03 whiteknight Andy: why is that?
14:03 PerlJam The first step in making your reality what you want is *believing* it will be so  :)
14:04 whiteknight Then, I *believe* that parrot is 20x faster
14:08 NotFound mikehh: not exactly cross-compiling, scratchpad takes care of most issues.
14:08 Andy whiteknight: More stringent, produces error messages with parameter signatures.
14:10 whiteknight Andy: I've been liking ICC for exactly that reason
14:10 NotFound whiteknight: and error on things that in C are just warnings.
14:10 whiteknight I may switch so ICC is my default, at least on the computers I have with it installed
14:10 PerlJam whiteknight: then next step is making your beliefs real.  You might have a bit of a problem with that for Parrot  :)
14:10 whiteknight PerlJam: steps!?! I don't have time for steps
14:11 PerlJam But ... who's working on lorito?  When will it be a real, functioning part of Parrot?
14:12 mikehh re-generated MANIFEST and it added a whole bunch of .gitignore file - should I commoit or what should I do
14:13 mikehh commit
14:13 Coke Assuming we're keeping them, that's needed. I would rather see us collapse them all into a single .gitignore first.
14:13 Coke (if in fact we're keeping them.)
14:14 Coke backing out the .gitignore is fine with me.
14:14 Coke is chromatic awake yet?
14:19 Coke opbots, trust me in soc-help
14:19 slavorg But I don't trust you there, Coke
14:19 slavorgn But I don't trust you there, Coke
14:19 dalek wmlscript: e18a183 | fperrad++ | dynext/pmc/wmls (4 files):
14:19 dalek wmlscript: fix PMC after merge immutable strings
14:19 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/e18a183abc29b76e3f6c039d4fa1ecd2f3c86034
14:25 Coke bacek: you about?
14:26 Coke Anyone here able to rebuild the native pbcs?
14:30 bubaflub joined #parrot
14:37 Coke bueller?
14:37 purl Um, he's sick. Coke's best friend's sister's boyfriend's brother's girlfriend heard from this guy who knows this kid who's going with the girl who saw Ferris pass out at 31 Flavors last night. I guess it's pretty serious.
14:37 Coke BWAHAHAHAHAAH.
14:37 * Coke hugs purl.
14:37 purl Coke: get off me, you botvert!
14:37 Coke botsnack?
14:37 purl thanks Coke :)
14:39 moritz botvert?
14:40 theory joined #parrot
14:51 ash_ joined #parrot
14:53 Coke like pervert, but with bots.
14:53 moritz I figured. Just wanted to see if purl would elaborate
14:54 Coke oh.
14:54 Coke I was assuming a translation problem. =-)
14:54 Coke apologies.
14:54 purl apologies are in order, then.
14:54 Coke out of order!
15:02 integral joined #parrot
15:03 zostay_m joined #parrot
15:04 Coke chrome++ ; trac.parr ... <TAB> # 361
15:05 Mokurai joined #parrot
15:07 Coke the TT in PBC_COMPAT is closed, if anyone wants easy karma.
15:11 ash_ joined #parrot
15:22 dalek parrot: r45860 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
15:22 dalek parrot: [distutils] revert r45273 (useless since r45285)
15:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45860/
15:27 davidfetter joined #parrot
15:37 dukeleto it looks like parrot will get 5 of the 10 GSoC slots, tentatively
15:38 tewk dukeleto, how many proposals did parrot get?
15:39 * Coke must vote!
15:39 Coke dukeleto: how much longer do I have to vote? =-)
15:45 PerlJam dukeleto: is there any way TPF could get one more slot.  There looks like a clear breaking point in the rankings but at the 11th entry
15:46 Coke PerlJam: do we have dups?
15:46 particle PerlJam: no
15:47 PerlJam Coke: nope
15:49 iblechbot joined #parrot
15:49 particle only org admins see dupes, and i don't see any. however, it isn't entirely clear on how they show up.
15:49 riffraff joined #parrot
15:49 particle it's still possible that we will have dupes today, though
15:50 whiteknight joined #parrot
15:51 PerlJam Coke: go upvote Improvements to the NCI system and LLVM Stack Frame Builder   :-)
15:52 particle we don't play favorites on #parrot.  please keep specific comments about gsoc voting private.
15:53 PerlJam sorry
15:56 Coke I am voting now. I'm reading through everything, not just parrot stuff. :P
15:57 rurban I'm listening also :)
15:58 rurban When we create a c header parser for a ffi we will think of nci also. we will store an intermediate format of a parsed header (similar to ctypes lib on python) which can be translated to any FFI syntax, if perl5 or parrot.
16:03 Coke dukeleto: you know there are proposals with votes of > 4 from individual voters, yes?
16:05 moritz some of them have been compensated by others, some not
16:05 dukeleto Coke: i am looking now.
16:08 dukeleto Coke: seems like people voted multiple times. I should have sent a stern warning.
16:08 Coke Bruce Gray?
16:09 Coke Gray?
16:09 purl i guess Gray is grey is gray
16:09 Coke dukeleto: you know, or instructions. =-)
16:11 dukeleto Coke: yeah. I was changing jobs and other things came up during the voting and I didn't get proper instructions out
16:11 moritz Coke: aka Util, iirc
16:11 PerlJam Doesn't google allow a single person a maximum of +/- 10 anyway?
16:11 PerlJam (I mean, you could *try* to vote +4 +4 +4 +4, but you're only going to get +10)
16:12 moritz PerlJam: it does, but it seems sane not exceed -4...+4 per mentor
16:12 Coke Bruce Gray is Util. maybe.
16:12 moritz purl: Util?
16:12 purl Util is third-party.
16:12 patspam joined #parrot
16:13 PerlJam this is one area where google could have done better. (voting)
16:16 dukeleto i am zero-ing out people that voted more than +4. it doesn't change the rankings, tho
16:17 Coke dukeleto: er, you're changing their 4+2 to 0?
16:17 Coke or to 4?
16:17 dukeleto Coke: changing all votes to >4 to 4
16:18 * moritz kinda expects the SMOP project to be ranked lower by that
16:20 darbelo joined #parrot
16:21 Coke dukeleto: any -5's out there? =-)
16:21 dukeleto moritz: the SMOP project did lose a few points, but kept it's position, because the proposal under it lost some points as well
16:21 moritz dukeleto: ok
16:22 dukeleto some of the proposals in the top 10 need to be improved, such as making the timeline specify each week
16:23 moritz I commented on some of them asking for more specific
16:23 moritz sadly most of the mentors look more at what the student could achieve, and not so much if there's a realisitic plan to do it
16:24 moritz I've made that mistake too, in the some previous years
16:25 whiteknight dukeleto: Could you move me to mentor the hybrid threads one, and allison to mentor the NFG one?
16:25 Mokurai1 joined #parrot
16:31 particle please don't make public comments about proposals that haven't been selected yet.  isn't there a mentors-only gsoc chat room?
16:32 particle am i wrong to think we shouldn't be giving students hints about who might or might not be accepted?
16:32 particle let me know if i'm being paranoid.
16:33 moritz particle++
16:33 aukjan joined #parrot
16:33 darbelo particle: I don't know if there is any *rule* against it. But is seems to be the standard operating procedure to keep quiet until Google anounces the final results.
16:35 * particle wants a "mentors only" jacket
16:36 PerlJam particle: you are being appropriately paranoid.  :)
16:36 PerlJam particle++
16:38 dukeleto particle: i agree with you
16:38 dukeleto whiteknight: i will do that now
16:38 particle thank you for the validation.  i know i'm getting excited about the gsoc proposals becoming projects, and i bet that's what's driving the comments here.  stay excited, just hold your tongue for a little bit longer.
16:40 Coke particle++
16:40 whiteknight particle: I don't know if the proposals will get accepted or not, but when we initially assigned mentors to projects for preliminary slot allocation, that was all done publically
16:41 dukeleto whiteknight: reassignment done
16:41 whiteknight dukeleto++
16:41 Coke is there such a thing as a private channel on irc?
16:41 dukeleto conversation that does not say "X is accepted" is fine. Just don't ruin the surprise for everyone
16:41 whiteknight Coke: sure. Channels can be invite-only
16:42 PerlJam Coke: you can make one invite only
16:42 whiteknight or add a bot that boots anybody not on a whitelist
16:42 NotFound Or set a password
16:42 dukeleto we have the tpf-gsoc mailing list for private discussion. only mentors are on that list
16:44 eternaleye joined #parrot
16:49 darbelo I'm giving fperrad's TAP stuff a look now, and it looks fairly good. With a little tweaking it'll be able to take over as aour main test harness.
16:49 darbelo Maybe not for corevm, we'll probably want perl there for botstrap reasons.
16:51 plobsing ping bacek
16:52 nopaste "plobsing" at 192.168.1.3 pasted "LexInfo access from PIR" (16 lines) at http://nopaste.snit.ch/20323
16:54 plobsing msg bacek You can already instantiate a LexInfo from PIR, check out http://nopaste.snit.ch/20323. Also isn't throwing an exception a little harsh? Why not just a doc saying "Don't do that!"?
16:54 purl Message for bacek stored.
17:01 darbelo Unletaed thought, what's up with the .gitignores?
17:02 mikehh bacek put in a bunch for git users - ssome not happy about it
17:03 mikehh the consensus seems to be there should only be one .gitignore in svn
17:03 Coke mikehh: zero or one, yes.
17:04 darbelo I don't mind them.
17:05 darbelo I just noticed them now and wondered if I has missed something.
17:05 PerlJam what do "extra" .gitignore files hurt?
17:07 dukeleto darbelo: i am confusing to how TAP::Parser in parrot core relates to the external Tapir repo
17:07 dukeleto s/confusing/confused/
17:08 darbelo dukeleto: Don't worry. I am too.
17:08 ash_ is there a wiki page for the intended work with the llvm?
17:08 dukeleto darbelo: it kind of looks like fperrard took Tapir and modified/added features, then committed it to core
17:08 dukeleto ash_: should be something
17:09 dukeleto ash_: http://trac.parrot.org/parrot/wiki/Lorito
17:11 ash_ thanks dukeleto
17:11 Coke PerlJam: MANIFEST creep is the most annoying.
17:12 dukeleto only one .gitignore should be needed
17:12 PerlJam Coke: ah, good point.
17:12 Coke otherwise they do tend to stay out of the way. but it's one more thing for us to worry about keeping up to date.
17:12 dukeleto there are some automated tools that generate many .gitignore, which bacek probably ran
17:12 Coke Why not just let dukeleto put it in the mirror, or use the tools provided by git-svn?
17:13 Coke if we're going to keep them, one top level one is probably the best way, and it's an easy fix.
17:13 mmcleric joined #parrot
17:13 dukeleto Coke: then it wouldn't be a mirror ;P
17:13 dukeleto +1 to a single .gitignore file, regardless of it being in SVN or git
17:13 ash_ github can let you use svn to checkout a git repository now...
17:14 ash_ git won't add empty directories (if there are any) though, a common practice is to add a .gitignore in the empty directory so it has a file, but will ignore everything else in the folder. I don't know if parrot comes with empty folders though (like build or something)
17:18 dukeleto ash_: yes, the only purpose for more than a single .gitignore is to store it in an empty directory, but I don't think parrot ships with any
17:18 particle no empty dirs in parrot source
17:20 dalek rakudo: 56120b7 | (Solomon Foster)++ | src/ (4 files):
17:20 dalek rakudo: Change prefix:<+> to dispatch to .Numeric for all types which descend from Mu.  Define Mu.Numeric to return 0, Cool.Numeric to call the pir function to convert to a Num.
17:20 purl dalek: that doesn't look right
17:20 dalek rakudo: Still need to define Numeric.Numeric.
17:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​6120b7b5511a79643218f050a12d4321bd878b7
17:24 ash_ are lorito and the llvm jit system going to be developed in parallel basically?
17:25 Coke I think there is a wiki page describing the plan for that.
17:26 darbelo ash_: Kind of, 'lorito' is more of a name for the Big Plan to Make Parrot Fast than any particular bit of code.
17:34 kjeldahl joined #parrot
17:35 PerlJam I've always thought of Lorito as a plan to make parrot small and then, as a hopeful consequence, it will be fast.
17:36 cotto_work hi whiteknight
17:37 cotto_work nm.  Was backscrolling and forgot what I was doing.
17:37 whiteknight hello cotto_work
17:37 darbelo "Small enough to be incredibly fast"?
17:37 ash_ joined #parrot
17:38 PerlJam fewer ops and another opportunity for optimization
17:39 PerlJam The "core" would be faster (though it should have more work to do in general) and more regular.
17:39 joeri joined #parrot
17:40 particle a feather is no faster than a bowling ball
17:41 darbelo That doesn't tell us much. You can make bowling balls go damm fast with the proper equipment ;)
17:42 PerlJam a feather is quite a bit slower in the presense of an atmosphere  :)
17:43 Mokurai joined #parrot
17:44 cotto_work2 joined #parrot
17:44 darbelo Also, is that feather attached to large bird?
17:45 particle that's what i'm saying.  smaller != faster
17:47 nopaste "NotFound" at 192.168.1.3 pasted "Proof of concept patch: avoid a method call in every lexinfo creation" (111 lines) at http://nopaste.snit.ch/20324
17:47 NotFound Someone wants to benchmark this?
17:50 Coke someone work on getting us one of these to remote develop on: http://www.reinvented-the-works​tation.com/CX1-iWS-developers/
17:56 darbelo I somehow doubt our need for windows 7 support is *that* bit.
17:56 whiteknight particle: no, smaller is definitely not always faster
17:56 purl okay, whiteknight.
17:57 whiteknight damnit purl
17:57 purl damnit i am a bot!!!
17:58 whiteknight there are lots of opportunities for Lorito to improve performance anyway, regardless of the smaller size
18:07 hudnix joined #parrot
18:11 plobsing NotFound: I'm confused by the analysis on TT#1557. I don't see where unicode strings get converted to C strings when writting PBC.
18:12 NotFound plobsing: failed explanation, is during disassembly
18:13 ash_ joined #parrot
18:13 plobsing OK. Thanks for clarifying.
18:15 NotFound I'm tempted to propose deprecating pbc_dump and pbc_disassemble, his job can be done in pir or hll via packfile pmcs
18:17 dalek rakudo: 3e3a934 | (Solomon Foster)++ | src/core/Numeric.pm:
18:17 dalek rakudo: Add Numeric.Numeric.
18:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​e3a934143923cd2d7e79ca57efb2bfc30acfef8
18:18 plobsing NotFound: if that job can be done in PIR or HLL via packfile PMCs, pbc_d* could be re-implemented using those. No deprecation required.
18:19 darbelo plobsing: Easier to deprecate this and write new ones without any backward-compat issues.
18:20 NotFound plobsing: you mean providing fakecutables for the new versions?
18:20 plobsing NotFound: exactly
18:20 NotFound Not a bad idea, but darbelo's point isn't also bad.
18:21 dalek parrot: r45861 | fperrad++ | trunk/runtime/parrot/library/TAP (3 files):
18:21 dalek parrot: [TAP] add pod
18:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45861/
18:23 dalek rakudo: 1f638cc | moritz++ | docs/ChangeLog:
18:23 dalek rakudo: [docs] another ChangeLog entry
18:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​f638cc342c1b54d7ecfe1936aa1bb5f80ebfb0a
18:23 dalek rakudo: e329a94 | moritz++ | src/core/Date.pm:
18:23 dalek rakudo: [Date] move private subs inside the class
18:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​329a94e905bc43fc5b2dc11a099b6e82140025b
18:28 plobsing NotFound: regarding the LexInfo patch, I had a similar idea but had no idea how to benchmark it. IIUC, there is only 1 LexInfo per sub, so it won't help unless we're creating a lot of subs (which I don't see any of our benchmarks doing)
18:29 NotFound plobsing: i think so
18:30 plobsing complicated programs like rakudo would probably benefit the most. but seeing as rakudo doesn't build against the current trunk...
18:31 NotFound I can't benchmark with winxed because winxed doesn't use lexicals.
18:36 * Coke whinges again about the packfile tests.
18:37 * plobsing wonders why everyone should be able to read i386 packfiles, but i386 doesn't have to be able to read anyone elses
18:38 Coke plobsing: they do.
18:38 Coke but mainly in theory. =-)
18:40 whiteknight packfile portability is known to be a big problem
18:41 plobsing unless you're on i386, the be-all and end-all of architectures as far as parrot is concerned
18:42 NotFound I disagree, my main development machine is x86-64 ;)
18:43 darbelo In theory, everyone can read everyone else's packfiles. In practice, nobody has cared in so long that we'll be better of with a portable format.
18:44 plobsing NotFound: same here. but the JIT was i386-only, the frame builder was i386-only, packfiles are portable from i386 only. I detect a trend.
18:45 darbelo plobsing: JIT worked on PPC too until we ripped it out.
18:45 particle the trend is that we have a very limited pool of talented developers using commodity hardware
18:45 plobsing orly?
18:45 purl YA RLY.
18:46 darbelo plobsing: Yep, framebuilder was i386 only because I had no clue of how to make it work on ppc when I ripped the rest of JIT out.
18:47 darbelo Maybe if I had any ppc hardware, but we had exactly one ppc user at the time, and I don't like macs.
18:48 whiteknight I don't like spiders
18:49 NotFound I don't like mondays
18:49 particle i don't like "don't like"
18:49 whiteknight mondays--
18:49 NotFound u-u-u-u-uuuu...
18:50 rurban packfile portability is no problem at all if would be maintained (and tests enabled)
18:50 dalek winxed: r446 | julian.notfound++ | trunk/examples/packfile.winxed:
18:50 dalek winxed: don't die if no anotations in example packfile
18:50 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=446
18:51 chromatic joined #parrot
18:51 rurban I have lots of double and single float patches still sitting somewhere
18:51 darbelo As I said: In practice, nobody has cared in so long that...
18:52 arnsholt darbelo: Not to mention that even PPC Macs are a dying breed these days
18:52 rurban I rather think of it being torpedoed for a hidden purpose
18:52 shockwave joined #parrot
18:53 darbelo arnsholt: I was being glib, our JIT has never worked on mac os X. Our one user was on netbsd/ppc
18:53 shockwave Hi. Is there a vtable override to give a method an alias? i.e.:
18:53 shockwave .sub 'foo@3f3F#$' :method :alias('foo') ....
18:54 moritz what should that alias be used for?
18:54 darbelo I also don't hate macs, I just don't have one, nor care to get one.
18:54 shockwave moritz, so that it can be called by both it's long, mangled name, as well as it's alias.
18:54 arnsholt Yeah, I figured it was more that kind of "don't like"
18:55 moritz shockwave: I'm not aware of such a feature (but that doesn't mean much)
18:56 shockwave moritz, there's an nsentry() that allows the chainging of the method name. I need it for debugging only, I hope that an alias one does exist.
18:56 NotFound shockwave: override find_method and lie
18:57 Coke jit worked on ppc? !?!?!?! my old macs would disagree with you. =-)
18:58 moritz NotFound: uhm, not sure if that actually simplifies debugging :-)
18:58 moritz sounds as if you have bug there, it's making it much harder
18:58 chromatic JIT worked on PPC.
18:58 shockwave NotFound: I'll keep it in mind.
18:59 NotFound shockwave: just an idea, not sure if workable
19:00 lucian joined #parrot
19:00 shockwave NotFound: I appreciate it anyway :). I'm brainstorming to see how I'm going to solve the current issue, and that idea is as good as any.
19:00 particle yes, jit worked on ppc.  only some math ops were jitted.
19:00 chromatic Not many ops anyway.
19:01 NotFound chromatic: please take a look at http://nopaste.snit.ch/20324
19:03 mmcleric left #parrot
19:04 chromatic Is that to save creating the wrong type of hash and then destroying it?
19:04 NotFound chromatic: no, just avoiding a method call for a now.
19:04 chromatic Avoiding the method call is nice.
19:05 plobsing Avoiding creating the unused hash would be nice too, but probably much harder.
19:05 NotFound Don't know how to benchmark it, though.
19:06 NotFound plobsing: will be easy doing both, at the cost of coupling lexinfo and hash.
19:06 Coke huh. I gave up on JIT for some time. Perhaps I'm misremembering how JIT ended.
19:07 NotFound Maybe that's the better way for a now, and worry about decoupling later.
19:07 plobsing NotFound: can you elaborate on the coupling?
19:08 NotFound plobsing: doing all initialization inside the lexinfo pmc, without using vtables or methods of hash
19:08 chromatic Using init_int might work.
19:09 NotFound chromatic: init_int in hash?
19:10 plobsing wait, hold on; where does LexInfo.init_pmc call Hash.init. I don't see it anywhere. Maybe there isn't an unused hash.
19:11 NotFound plobsing: it doesn't, the method called takes care of initialization
19:11 dalek winxed: r447 | julian.notfound++ | trunk/examples/packfile.winxed:
19:11 dalek winxed: show debug segment size in example packfile
19:11 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=447
19:11 NotFound But that method does the creation and destruction.
19:12 plobsing why not just create the hash yourself and use set_pointer?
19:12 NotFound plobsing: that is the coupling I mentioned.
19:13 plobsing ah. that's not so bad.
19:15 plobsing can anyone explain why LexInfo.init must throw an exception? bacek mentioned that it is to prevent initialization from PIR, but I can still do that.
19:16 NotFound plobsing: maybe just because there is no knwon reasonable usage, and thus no worth testing.
19:17 plobsing NotFound: I have a usage. If we make it work, we can ditch LexInfo.thaw and use Hash.thaw in stead
19:21 NotFound plobsing: not a bad argument. Using init_pmc just to pass NULL looks pointless.
19:22 chromatic plobsing, your example uses init_pmc, not init
19:22 plobsing I did it in r45844, but it got reverted
19:23 plobsing chromatic: my example is how you can still initialize a LexInfo pmc from PIR. It counters the argument that we use init_pmc to prevent PIR from creating such an object.
19:24 pjcj joined #parrot
19:25 chromatic Yeah, there's no good way to prevent its creation from PIR.
19:26 * Coke documents his native_pbc frustration on-list
19:26 Coke if you can create it from C, you can create it from PIR.
19:27 plobsing I'm of the opinion that you shouldn't go out of your way to prevent something just because you can't imagine why it would be useful.
19:30 * Coke points to Andy's message on the list.
19:30 Coke (Andy D)
19:30 Coke (thankfully it's post-release.)
19:30 NotFound plobsing: there is a point: if you forbid soemthing you avoid someone using it while untested. If someone exposes a use case, the test can be written.
19:31 aukjan joined #parrot
19:31 darbelo It sounds immutable string related to me.
19:31 chromatic It is, but bacek and I improved performance there.
19:32 Coke perhaps he's more sensitive to memory usage?
19:33 darbelo 1064262424 bytes
19:33 whiteknight back in my day, we used to allocate at least that many bytes. Uphill both ways
19:35 darbelo "back in my day" ? The computers I grew up with didn't have that much memory. And I'm in my 20's
19:35 whiteknight we didn't allocate them on a computer. I had to carry my bytes in a wheelbarrow
19:35 chromatic My phone has more memory than my first couple of computers.
19:36 ash_ joined #parrot
19:36 pmichaud pbc_to_exe was specifically written to take advantage of Parrot's old string characteristics
19:36 pmichaud immutable string probably changed those characteristics
19:36 pmichaud (because before pbc_to-exe's optimization, it was taking very long to do what it did)
19:38 chromatic real    0m0.714s
19:38 chromatic That's how long it takes to build for me on trunk now.
19:39 iblechbot joined #parrot
19:39 pmichaud also, Andy's message says that it's with the released 2.3.0, which was pre-immutable strings.
19:40 pmichaud oops, I misread. nm.
19:40 pmichaud he says 2.3.0 takes 3 seconds, but r45860 takes forever.
19:40 nopaste "NotFound" at 192.168.1.3 pasted "Proof of concept patch: avoid a method call in every lexinfo creation, using init_int by chromathic++ suggestion" (48 lines) at http://nopaste.snit.ch/20327
19:41 * pmichaud tries r45860 locally
19:43 darbelo pmichaud: No, he said r45860.
19:43 darbelo pmichaud: 2.3.0 works for him in ~ 3s
19:43 pmichaud 19:40 <pmichaud> oops, I misread. nm.
19:44 darbelo Ugh missed that. Sorry.
19:49 gssgss joined #parrot
19:57 chromatic That patch looks much cleaner, NotFound.
19:58 shockwave left #parrot
19:58 NotFound chromatic: yes, that way is easier to write cleanly at the first attempt.
20:00 TimToady phone
20:04 allison is anyone else having trouble getting in to the conf call?
20:04 NotFound Now that I'm on it....
20:05 Coke karma chromathic
20:05 purl chromathic has karma of 1
20:05 Coke chromathic--
20:05 Coke chromatic++
20:06 Spreadsheet_ joined #parrot
20:07 Spreadsheet_ Hello
20:07 purl hey, Spreadsheet_.
20:07 Coke joined #parrot
20:07 Spreadsheet_ Hi purl
20:07 Coke argh. /quit ain't /win quit.
20:08 nopaste "cotto_work" at 192.168.1.3 pasted "some rakudo benchmarking with various runcores (summary at bottom)" (105 lines) at http://nopaste.snit.ch/20328
20:09 moritz cotto_work: so they are all basically the same
20:09 cotto_work yeah
20:10 cotto_work certainly not a dramatic difference
20:10 chromatic Rakudo's overhead masks a lot of the difference at the op level.
20:10 cotto_work How so?  Rakudo's overhead is also mostly ops.
20:11 chromatic It's mostly creating and destroying PMCs.
20:12 cotto_work otoh it shows how much the runcores matter to Rakudo.
20:12 chromatic As in "not".
20:12 cotto_work yup
20:18 lucian joined #parrot
20:20 dalek TT #1572 created by doughera++: pbc_to_exe unusable after immutable_strings merge
20:20 dalek TT #1572: http://trac.parrot.org/parrot/ticket/1572
20:20 dalek parrot: r45862 | NotFound++ | trunk/src/pmc/hash.pmc:
20:20 dalek parrot: avoid creating and destroying a hash in Hash set_value_type method
20:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45862/
20:20 Mokurai joined #parrot
20:20 Util Coke: I see myself being referred to about 4 hours ago (and yes, I am Bruce Gray), but I see no context for the reference. What's up? Did a GSOC proposal reference me?
20:21 Coke the name Bruce Gray came up somewhere.
20:21 Coke might have been GSOC related. nothing bad, just trying to place nick to name.
20:21 ash_ it was on my GSoC application
20:21 ash_ (might be it?)
20:23 Util ash_: I thought that might be it, since GSOC was being discussed at the time.
20:23 * Util lives in the same college town as ash_
20:23 ash_ one of the GSoC dead lines is today
20:24 cotto_work yup.  No further ratings are allowed after about 3.5 hours ago.
20:26 cotto_work official announcements are scheduled for the 26th at 1900 UTC
20:27 particle stay tuned for more.
20:29 dukeleto it seems that TPF is not going to get involved in any dedup hijinx
20:34 NotFound parrot builds fine in Ubuntu 10.04 beta i386
20:35 allison joined #parrot
20:37 dalek parrot: r45863 | petdance++ | trunk/src/pmc/bignum.pmc:
20:37 dalek parrot: removed two unused vars
20:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45863/
20:37 dalek parrot: r45864 | NotFound++ | trunk/src/pmc (2 files):
20:37 dalek parrot: implement Hash init_int vtable to create a hash with given value type, use it in Lexinfo init_pmc
20:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45864/
20:40 cotto_work allison: what are your thoughts on ripping out all the runcores (apart from the function-based ones) that require dedicated preprocessing code, i.e. cgoto, cgp and switch?
20:40 cotto_work and cprederef
20:41 bacek Good morning, @humans.
20:42 davidfetter joined #parrot
20:45 gssgss joined #parrot
20:46 cotto_work hi bacekbot
20:47 bluescreen joined #parrot
20:50 Coke bacek - any clues on the mk_native_pbc post?
20:51 bacek Coke, "our PBC format suck"
20:51 Coke or, "can you just take over that RetContinuation ticket"? =-)
20:52 bacek Coke, no! :)
20:52 Coke but it was your ticket and I did all the hard work! =-)
20:53 bacek Coke, retcon.diff in ticket?
20:53 dalek parrot: r45865 | chromatic++ | trunk/t/op/vivify.t:
20:53 dalek parrot: [t] Removed unnecessary diagnostic output.
20:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45865/
20:53 dalek parrot: r45866 | chromatic++ | trunk/tools/dev/pbc_to_exe.pir:
20:53 dalek parrot: [tools] Fixed non-GCC, non-MSVC code generation in pbc_to_exe to avoid
20:53 dalek parrot: expensive string concatenation (reported by Andy Dougherty, TT #1572).
20:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45866/
20:54 gssgss left #parrot
20:54 Spreadsheet_ Does Parrot have any optimizing features?
20:55 ash_ sure, some, but not much yet
20:55 Coke bacek: yes. that does 99% of the work. I got hung up on the pbc compat issues.
20:56 bacek Coke, testing.
20:56 Spreadsheet_ ash_: I heard somewhere that with two algorithms that do the same thing, the JVM would choose the one that runs faster, so I was wondering if parrot did this
20:57 ash_ well, it does have different runcores, that do similar things, but parrot is in the process of updating its runcores because some of them are kinda special case
20:57 Coke bacek: I was going to do a fulltest and also make sure that t/pmc/... extend? embed? also passed.
20:58 bacek Coke, Configure.pl failed...
20:58 Coke bacek: lies!
20:58 bacek During configuration the following steps failed:
20:58 bacek 25:  auto::pmc
20:58 bacek 55:  gen::core_pmcs
20:58 Coke did you svn remove retcontinuation.pmc ?
20:58 bacek step auto::pmc died during execution: No pmclass declaration found in retcontinuation.pmc at config/auto/pmc.pm line 167.
20:59 Coke svn rm src/pmc/retcontinuation.pmc and t/pmc/retcontinuation.pmc
20:59 bacek Coke, "svn"??? I have no idea what you are talking about :)
20:59 Coke (you probably have empty files there now after applying the patch.
21:00 bacek Coke, it helped. Rebuilding
21:00 rurban_ joined #parrot
21:00 Coke did you resolve the conflict in PBC_COMPAT?
21:01 bacek Yes, of course.
21:01 purl Indubitably.
21:01 ZeroForce joined #parrot
21:01 Coke woot.
21:03 Coke http://trac.parrot.org/parrot/ticket/1427 btw, if you happen to close it.
21:03 cotto_work joined #parrot
21:03 cotto_work joined #parrot
21:04 kurahaupo joined #parrot
21:08 Coke who belongs to compilers/ncigen ?
21:09 tewk I do, you want to chop it, go ahead.
21:09 dalek rakudo: fadb800 | moritz++ |  (2 files):
21:09 dalek rakudo: make reduce() a bit more usable, and test it
21:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​adb800ab8a8a9d5d39e5f9a1ee1f24d769dfa61
21:09 Coke it depends on NQP, which is on the chopping block.
21:09 Coke can we safely remove it? is it installed?
21:10 tewk its not used by anyone that I know of, its not installed
21:11 Coke k. I'll open a ticket for removing it, then. you sure that's ok?
21:11 tewk sure
21:11 Coke tewk++
21:11 bacek Coke, TT#1462 (nqp deprecation)
21:13 bacek meh... I put wrong date into PBC_COMPAT...
21:13 Coke note to releasers - only create a new version for the latest release, don't pre-create unreleased versions in trac.
21:13 Coke bacek: yes?
21:14 bacek Coke, retcont is GONE
21:14 Coke bacek: that's ok, you can update the date without breaking pbc compat. =-)
21:14 Coke bacek++
21:14 moritz Coke: notes to releasers will get lost here... if it's important, put it in release_guide.pod
21:15 dalek rakudo: 205d9d3 | moritz++ | src/Perl6/Grammar.pm:
21:15 dalek rakudo: properly carp on $\ usage
21:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​05d9d3f167b22792681d5a0a67652cd93dab074
21:15 Coke moritz: unless someone borked it, we already had it that way. =-)
21:15 moritz :-)
21:18 cotto_work PBC_COMPAT should reflect the latest supported release
21:20 Coke that will help with later backward compatibility.
21:20 Coke maybe.
21:20 cotto_work maybe
21:21 cotto_work just noting that it should have happened
21:22 bacek cotto_work, yes. Looks gerd forgot to update it...
21:22 Whiteknight joined #parrot
21:23 Coke we can retro-comment it.
21:26 Coke who owns ext/SQLite3?
21:26 dalek parrot: r45867 | bacek++ | trunk (17 files):
21:26 dalek parrot: Remove RetContinuation PMC. Closes TT#1427. Coke++ for all hard work.
21:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45867/
21:26 dalek parrot: r45868 | bacek++ | trunk/PBC_COMPAT:
21:26 dalek parrot: Fix date in PBC_COMPAT.
21:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45868/
21:27 dalek TT #1427 closed by bacek++: RetContinuation PMC
21:27 dalek TT #1427: http://trac.parrot.org/parrot/ticket/1427
21:27 dalek TT #1573 created by coke++: remove compilers/ncigen
21:27 dalek TT #1573: http://trac.parrot.org/parrot/ticket/1573
21:27 Coke looks like simon started it. it's bitrotted, requires languages/rakudo
21:27 dalek TT #1572 closed by chromatic++: pbc_to_exe unusable after immutable_strings merge
21:27 dalek TT #1572: http://trac.parrot.org/parrot/ticket/1572
21:27 Coke I vote we kill it. :P
21:27 cotto_work +1
21:27 purl 1
21:28 darbelo KILL! KILL! KILL!
21:31 cotto_work It's a good week for nuking stuff.
21:39 bacek speaking of which. Can someone with svn checkout nuke immutable_strings_part1 branch?
21:47 bacek Coke, how partcl survived immutable strings merge?
21:48 cotto_work did partcl work with trunk before the merge?
21:49 darbelo bacek: Killled. r45869
21:49 cotto_work Bam!
21:51 Spreadsheet_ http://en.wikipedia.org/wiki/Compari​son_of_application_virtual_machines
21:51 cotto_work Now that strings are immutable, it'll be interesting to see what hashing at initialization does.
21:51 cotto_work The Parrot entry definitely needs updating.
21:52 Spreadsheet_ According to this Parrot does not have "Code security", "pre-compilation", and "shared libraries"
21:52 Spreadsheet_ Are there plans to do that in the future?
21:52 cotto_work Spreadsheet_ that's out of date.
21:53 cotto_work Parrot
21:53 Spreadsheet_ What's wrong, I have an account and can change it
21:53 cotto_work 's jit is long-gone.  I don't know what "shared libraries" means in that context, but we support loading libraries from PIR.
21:54 darbelo "Shared libraries are a facility to reuse segments of native code across multiple running programs"
21:55 ash_ plumage ?
21:55 purl plumage is probably the future Parrot module ecosystem.  It will include tools to search metadata, handle dependencies, install modules, and so forth. The repository is at http://gitorious.org/parrot-plumage/parrot-plumage and the design docs are at https://trac.parrot.org/pa​rrot/wiki/ModuleEcosystem
21:55 japhb <rez.
21:55 japhb Huh what?
21:55 darbelo We don't have it, at least not as described there.
21:56 chromatic libparrot.so
21:56 purl hmmm... libparrot.so is 1.2M smaller in branch
21:56 japhb ash_, was I needed for something?  (Plumage is one of my IRC client highlight words)
21:57 ash_ no, i was just commenting on the link to the wiki article, wouldn't plumage count as shared libraries?
21:58 japhb Not in the sense they're talking about.
21:58 cotto_work I'm not really sure why it's a useful measure of anything.
21:59 darbelo It's not.
21:59 cotto_work shared libraries aren't new technology.
21:59 japhb They're referring to sharing identical memory pages of library code across multiple child processes.
21:59 dalek parrot: r45869 | darbelo++ | branches/immutable_strings_part1:
21:59 dalek parrot: Branch merged to trunk and is no longer needed.
21:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45869/
22:00 japhb As memory-dedup'ing kernels/hypervisors become more common, it probably becomes less critical that VMs directly support memory sharing themselves.
22:00 japhb But, you know, long conversion period.  :-)
22:04 arnsholt Is there a go-to resource for how to work with PAST?
22:05 japhb #perl6?  # Half kidding
22:06 arnsholt japhb: Yeah, I'd just like to try and learn a bit on my own before I go pestering jnthn and all those other nice people over there with my pet project =)
22:06 kurahaupo joined #parrot
22:06 dalek rakudo: 2a93f45 | (Martin Berends)++ |  (2 files):
22:06 dalek rakudo: [core/Temporal.pm] add a fairly large subset of strftime() and some tests for it
22:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​a93f45678dd56b76e109f9998d99a1fd6405fd0
22:06 dalek rakudo: c778995 | (Solomon Foster)++ | src/core/ (2 files):
22:06 dalek rakudo: Remove Mu.Numeric.  Add Any.Numeric, and make it both pickier and more informative.
22:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​778995d56729d79a8bcfc5ef9e128b88ce18992
22:07 bakkdoor joined #parrot
22:08 bakkdoor hi
22:08 bakkdoor :)
22:08 cotto_work hi bakkdoor
22:10 bakkdoor just started getting into parrot today. looks very interesting. I'm looking for a vm suitable for a dynamic language i'm working on and want to compile
22:11 Whiteknight bakkdoor: if it's a dynamic language, it's hard to find a better VM host than Parrot
22:11 bakkdoor i hope so :)
22:11 chromatic bakkdoor, have you seen the Parrot book?  docs/book/pir
22:11 bakkdoor i ordered a book today at amazon
22:11 bakkdoor don't remember the name. wait
22:12 bakkdoor Parrot Developer's Guide: Pir
22:12 bakkdoor that's it
22:12 bakkdoor i guess it's by allison ? :)
22:12 bakkdoor chromatic: is it the same like the one you mentioned or a different one?
22:13 chromatic That's the one.  We've made some changes since then, but it's still a good overview as to how Parrot works.
22:13 bakkdoor alright.
22:13 bakkdoor it wasn't expensive - 9 euros or so - i figured I'd try it out :)
22:13 Coke bacek, darbelo - it worked before the merge. partcl itself might need love. partcl-nqp has no C in it.
22:14 chromatic If you have questions, we'll do our best to help you.
22:15 bakkdoor i just have one problem: i don't know any perl (yet). i'm a ruby guy and i wrote my current implementation for my language (a simple interpreter) in c++. do i need to use perl (in the sense that everything else would be much harder etc.) to implement my language for parrot?
22:16 chromatic No, you shouldn't have to know any Perl at all.
22:17 bakkdoor chromatic: i mean also for some runtime library stuff. my language is heavily inspired by smalltalk and ruby (everything's an object, lots of closures (everything a messagesend, even if and while etc.)).
22:18 arnsholt There's NQP that you can use if you want to though
22:18 chromatic If you run into anything that requires an understanding of Perl, it's likely a bug we need to address.
22:18 arnsholt It's essentially Perl 6-ish syntax and some amenities over PIR
22:18 japhb bakkdoor, as you surmised, learning PIR is very useful.  NQP is much easier, but needs some PIR knowledge for maximum effectiveness
22:18 arnsholt It's pretty simple (and very nice to work with, IMO)
22:19 hercynium joined #parrot
22:19 arnsholt Also, what japhb said. I'm still struggling in that category. My Perl is good enough, but I haven't got a good enough handle on PIR yet
22:19 japhb One of the very nice things about NQP is that it comes with a grammar engine.  :-)
22:19 arnsholt A very nice grammar engine too
22:19 bakkdoor what exactly does nqp stand for?
22:19 arnsholt Not Quite Perl
22:19 arnsholt =)
22:20 bakkdoor ah ok :)
22:20 bakkdoor yeah i've read about it before somewhere
22:20 cotto_work nqp?
22:20 purl rumour has it nqp is http://github.com/perl6/nqp-rx or not quite low-level enough for some purposes
22:20 arnsholt If you're used to working with yacc and flex and such, NQP's grammar engine will be welcome relief
22:20 cotto_work nqp is also Not Quite Perl 6
22:20 purl okay, cotto_work.
22:20 arnsholt Or at least I found it to be =)
22:20 japhb bakkdoor, It's essentially a subset of Perl 6 syntax - (anything that requires a standard library ("setting")) + some magic to do inline PIR cleanly
22:20 bakkdoor arnsholt: yeah I currently use bison & flex
22:21 bakkdoor japhb: oh ok sounds good
22:21 cotto_work There's a hump to get over when learning nqp but it's really nice to work with after that.
22:21 arnsholt I find NQP easier to work with, as it's mostly a top-down parser rather than bottom up as yacc-style parsers
22:22 bakkdoor www.fancy-lang.org <- thats the website for my language. still need to add more documentation etc...
22:22 japhb Also, NQP is implemented in NQP, so you can see how nice it is for implementing languages ... by looking at its own source.
22:22 bakkdoor ok :)
22:24 darbelo joined #parrot
22:24 bakkdoor oh, what I've been wondering about as well. how is parrot's support for concurrency?
22:24 japhb Funny you should ask ...
22:24 bakkdoor japhb: hm?
22:24 japhb We recently discussed whether we wanted to do more concurrency work or garbage collection work as our next big push.  GC won.
22:24 bakkdoor ah ok
22:25 cotto_work There's a promizing gsoc threading proposal though
22:25 cotto_work for parrot
22:25 bakkdoor i'm asking because i want to have erlang-style message-passing concurrency in my language. wondering if that would be (easily) possible with parrot
22:25 chromatic I'd like to support that, but right now it's not easy in Parrot efficiently.
22:25 darbelo To be fair, the gc has caused enough threading breakage that improving it also improves our threads.
22:32 dalek TT #1574 created by coke++: remove ext/SQLite3
22:32 dalek TT #1574: http://trac.parrot.org/parrot/ticket/1574
22:32 dalek TT #1575 created by coke++: remove ext/SQLite3
22:32 dalek TT #1575: http://trac.parrot.org/parrot/ticket/1575
22:32 cotto_work Do we have to remove it twice?
22:33 bakkdoor well i guess it's not too important right now. also, it could be possible to implement that using normal threads. but having light-weight, efficient processes (similar to erlang's) in the vm would be nice to have in the future :)
22:33 kid51 joined #parrot
22:35 dalek rakudo: 0b67c52 | jonathan++ | src/metamodel/RoleToRoleApplier.nqp:
22:35 dalek rakudo: Should check definedness rather than truth when looking if a method exists in the role composer; this is because .Bool method may not be defined so early in the bootstrap in places we'd want it to be, so we exploded if roles were used in a certain way in the setting.
22:35 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​b67c526dc774ab1d14743a3328616d4138dbf6c
22:43 chromatic Hm, fib.pir is 10% faster than it was a couple of days ago.
22:44 japhb Whysat?
22:44 chromatic Checking now.
22:46 chromatic Looks like a simplification in Parrot_pcc_build_sig_object_from_op().
22:48 chromatic Oh wait, wrong benchmark.
22:49 ZeroForce1 joined #parrot
22:49 Myhrlin joined #parrot
22:49 alexn_org joined #parrot
22:58 mikehh did we come to a decision on what is happening with the .gitignore files?
22:58 tetragon joined #parrot
22:59 mikehh MANIFEST needs re-generating (or commiting anywaty)
23:00 mikehh anyway
23:00 cotto_work You can fix it while waiting for whatever the long-term solution is.
23:00 mikehh 'k
23:02 darbelo Have I mentioned lately how much I hate svn merges?
23:02 mikehh was looking at the runcore benchmarks - I can't see how the fast core is slower than the slow core - surely that does more work
23:02 chromatic Time-based benchmarks lie.
23:03 darbelo All benchmarks lie. Time-based benchmarks lie more.
23:03 mikehh darbelo: merge with git then sort it out :-}
23:04 dalek parrot: r45870 | mikehh++ | trunk/src/ops/core.ops:
23:04 dalek parrot: fix codetest failure - trailing spaces
23:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45870/
23:05 darbelo I also suspect parrot's svn repo is slightly corrupted somwhere.
23:05 dalek TT #1575 closed by coke++: remove ext/SQLite3
23:05 dalek TT #1575: http://trac.parrot.org/parrot/ticket/1575
23:06 sorear Parrot on RTEMS will be really awesome for profiling
23:06 cotto_work mikehh: The slow runcore doesn't do much more work than the fast one.  It's likely that the difference is overshadowed by various sources of error.
23:07 sorear because once we have all the running-with-barely-an-OS stuff down, I can run Parrot in ring 0 with interrupts disabled on one of the old computers I have lying around here
23:07 darbelo sorear: simulator lie too ;)
23:07 sorear and get near-cycle-accurate time benchmarks
23:07 sorear darbelo: chromatic does all his benchmarks using simulator
23:07 cotto_work You mean rtems?
23:08 cotto_work That's actually a really good dea.
23:08 sorear I mean physically installing rtems/i386 on a P133
23:08 cotto_work well, *could be* a really good idea
23:09 darbelo sorear: Oh, you mean wallclock time RTEMS? That could work.
23:09 sorear Yes.  And by wallclock I mean RDTSC.
23:11 japhb sorear, The performance profile of an old-world Pentium Classic are so wildly different from a modern processor that you may get *even worse* results.
23:12 sorear japhb: surely it will be better than chromatic's raw instruction counts
23:13 japhb sorear, if he's getting cache miss stats, that will be very different on e.g. a Core 2.
23:13 japhb Let alone a Core i.
23:13 chromatic Or a 64-bit machine.
23:13 japhb chromatic, right.
23:14 japhb (Both of the CPUs I mentioned are 64-bit, FWIW, but yes, the point is general)
23:14 chromatic You don't have to run a Core 2 in 64-bit mode though, but yes.
23:14 japhb chromatic, Right, somehow I always forget that people do that.  :-)
23:16 japhb sorear: Not only do the newer processors have different cache structures, pipelines, etc., as chromatic points out, they even have very different register layouts.
23:16 japhb Mind you, I'm not saying it's a pointless exercise.  Just that it won't give "better" results than a well-controlled benchmark on a modern CPU/OS.
23:21 dalek parrot: r45871 | mikehh++ | trunk/MANIFEST:
23:21 dalek parrot: re-generate MANIFEST
23:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45871/
23:21 Coke I wish irssi would automatically convert "win X" to "/win X" for me.
23:21 Coke anyone have a deep, abiding love for SQLite3 ?
23:22 sorear japhb: yes, but benchmarks on an OS are completely and utterly worthless because they have a margin of error.
23:22 japhb Coke: Well, it's certainly very nice ... and some day I may want to use it for Plumage.  But not immediately.
23:22 Coke well, first you'd have to make it work.
23:22 japhb sorear, that's manifestly untrue.
23:23 japhb Coke, fair enough.  Hadn't tried.  I was speaking of the general tool, not our implementation.
23:23 japhb sorear, (that they are worthless)
23:24 japhb sorear, There are many techniques for compensating for jitter, reducing error margins, finding "most probable" ranges, etc.
23:24 Coke japhb: oh, I meant ext/SQLite3, specifically.
23:24 japhb Coke, gotcha.  I'm not using that.
23:24 japhb (and it sounds like I *couldn't* even, if I wanted to. :-)
23:25 japhb my typing is sucking, sigh
23:28 lucian joined #parrot
23:33 mikehh that was not a good idea codetest/distro_tests FAIL on all the .gitignore files (svn properties missing) otherwise
23:33 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#33375), fulltest) at r45871 - Ubuntu 10.04 beta amd64 (gcc with --optimize)
23:34 * japhb chuckles at the thought of giving a .gitignore svn properties
23:35 darbelo Say, is ports/fedora/2.3.0/parrot.desk.in.tar.gz sipposed to be there?
23:36 ingy joined #parrot
23:37 dalek parrot: r45872 | chromatic++ | trunk/tools/dev/pbc_to_exe.pir:
23:37 dalek parrot: [tools] Fixed MSVC code generation in pbc_to_exe to avoid expensive string
23:37 dalek parrot: concatenation (implied by TT #1572).
23:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45872/
23:37 dalek parrot: r45873 | chromatic++ | trunk/t/op/fetch.t:
23:37 dalek parrot: [t] Removed more debugging output.
23:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45873/
23:37 dalek parrot: r45874 | chromatic++ | trunk/src/call/context.c:
23:37 dalek parrot: [PCC] Changed STRING register initialization to use STRINGNULL from NULL.
23:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45874/
23:37 darbelo I have no knowledge of the packaging process for that, but I feel odd about putting gziped tarballs into the repo.
23:38 dalek TT #1576 created by petdance++: Update functions that take STRING * to take const args where possible
23:38 dalek TT #1576: http://trac.parrot.org/parrot/ticket/1576
23:38 dalek TT #1577 created by coke++: gitignore files
23:38 dalek TT #1577: http://trac.parrot.org/parrot/ticket/1577
23:38 mikehh I think I am going to revert the MANIFEST file commit - I'd rather have a one line manifest_tests failure than hundreds of lines in codetest/distro_tests
23:40 japhb mikehh, why not just fix the tests?
23:40 darbelo I hate svn merges that take so long that I'm already out of sync by the time they are done.
23:41 cotto_work darbelo: you mean most of them?
23:41 japhb That sentence should just end after the fourth word, darbelo
23:42 darbelo It's a particular sort of hate I have for this particular sort of merge.
23:42 darbelo While I hate svn's merging in general. Here I can hate with specificity.
23:44 kurahaupo joined #parrot
23:49 mikehh japhb: I'll have a look at that - but meanwhile I;ll wait for a policy decision on the .gitignore files
23:49 mikehh I'll
23:49 Coke mikehh: please don't revert the manifest fix.
23:49 Coke it can be fixed again once gitignore is cleaned up.
23:49 mikehh I did already - you want me to put it back
23:49 Coke mikehh: I opened a ticket, you have plausible deniability.
23:52 mikehh Coke: it is fairly easy to do, one way or another
23:53 dalek parrot: r45875 | coke++ | trunk (3 files):
23:54 dalek parrot: Remove bitrotted ext/SQLite3 (TT #1574)
23:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45875/
23:54 dalek parrot: r45876 | darbelo++ | branches/include_dynpmc_makefile (486 files):
23:54 dalek parrot: Sync branch with trunk.
23:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45876/
23:54 dalek parrot: r45877 | mikehh++ | trunk/MANIFEST:
23:54 dalek parrot: revert MANIFEST commit - too many codetest/distro_test problems with .gitignore files - no svn properties
23:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45877/
23:55 dalek TT #1574 closed by coke++: remove ext/SQLite3
23:55 dalek TT #1574: http://trac.parrot.org/parrot/ticket/1574
23:56 cotto_work allison, ping
23:56 Coke mikehh: ... you reverted the sql changes, too.
23:57 Coke fixed.
23:58 darbelo Two tickets, two removals. Makes sense to me.
23:59 darbelo :)

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced