Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches | Review and vote GSoC applications
Set by moderator on 20 April 2010.
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
ash_, I will trust your vastly greater experience on this one. ;-)
ash_ developer.apple.com/mac/library/qa/...a1567.html 00:01
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
Yeah. "improvements".
ash_ lol, yeah, they broke their linker, i think your right, it might be a linker issue
Coke Coke is also on OSX 10.6.3
purl okay, Coke.
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.
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.
Coke, I have no idea how to catch an error like this latest one we've been seeing.
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.
In fact, I could write the magic string only after it got there N times, and look for that.
Hmmmm.
ash_, I dunno. Maybe plobsing's NCI changes?
ash_ how does the loadlib op work? 00:08
japhb wait. 00:09
00:09 elmex joined
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
-dylib_file \\
Coke japhb: we don't support 10.4 anymore, I don't think. 00:10
japhb -dylib_file \\
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:\\
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
And probably also for libGLU.dylib.
Then maybe the /System/Library/Frameworks/OpenGL.framework/OpenGL line will work again
Coke, \\o/
That certainly simplifies things 00:11
ash_ what if you did /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/OpenGL ?
japhb Dunno. Try it both ways? 00:12
(Or actually, all three ways.)
Sigh, four.
Coke 10.4.0 is from 4/29/05. 00:13
japhb Coke: What about 10.4.last? 00:14
ash_ 10.4 isn't even support by apple anymore...
only 10.5 is
japhb OK, fair enough.
Coke 10.4.11 is from 14NOV07
ash_ 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. :-)
ash_ that might be an issue
japhb ash_, and what if you do the full .dylib name within the Frameworks path? 00:16
ash_ works fine 00:17
the system /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib loaded fine
it might be checking for .dylib
japhb nod
ash_ in that case it seems that it might not be a problem with opengl at all, just a problem with loadlib 00:18
japhb looking at src/dynext.c 00:19
ash_ parrot_split_path_ext seems to be expecting a file extension 00:21
(i think)
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:25
ash_ but in Parrot_load_lib it returns Undef (which it appears to be doing) if !path || !handle 00:26
so both of those end up false for whatever reason 00:27
00:28 tetragon joined
cotto_work chromatic: do you intend on writing a test to use pbc_dump -n to check line numbers of pir files? 00:28
japhb Looks like parrot_split_path_ext will handle no dot in filename 00:29
AFK, food
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
heading home &
00:30 kurahaupo1 joined
chromatic cotto_work, I have no immediate plans. 00:43
dalek tracwiki: v165 | allison++ | WikiStart 00:45
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
rrot: r45836 | bacek++ | trunk/t/native_pbc (4 files):
Rebuild native pbcs.
00:52 abqar joined 00:58 kurahaupo1 joined
dalek kudo: ee9c308 | jonathan++ | src/builtins/Failure.pir:
Fix bug in error reporting of unknown subs (and attempts to invoke other fails).
 00:59
kudo: 483a9da | jonathan++ | src/Perl6/Compiler/Role.pm:
The next step in unbreaking anonymous roles; still some issues, but this gets the basics actually working.
01:00 bubaflub joined 01:45 kurahaupo1 joined 01:57 Psyche^ joined 01:59 tetragon joined 02:35 janus joined 02:51 plobsing_ joined
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 03:18 petdance joined 03:20 bubaflub joined 03:31 Khisanth joined 03:32 davidfetter joined
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.
cotto w00t
chromatic If we have to release 2.3.1 with that in DEPRECATED.pod, I will personally do it. 03:36
cotto I don't think it'll matter that much. 03:39
chromatic I won't tell if you don't.
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
Or do we have a "defaults must be cross-platform" policy?
chromatic We have a "no dead code" policy.
petdance ping bacek 03:44
04:08 jrtayloriv joined 04:17 kurahaupo1 joined
cotto If someone wants to merge a branch, this might be a good time. 04:44
I'm not sure how disruptive the runcore purge is going to be.
chromatic, do you think it'd annoy the Rakudo team to commit this directly to trunk? 04:46
nm. The amount of code that I'll get to rip out is large enough to make a branch worthwhile. 04:53
chromatic I definitely prefer a branch. 04:57
05:00 rurban_ joined
cotto yeah 05:02
dalek rrot: r45837 | cotto++ | branches/runcore_purge:
new branch for nuking unused runcores
 05:07
cotto s/unu/underu/ 05:08
What's the point of MANIFEST.orig? 05:18
petdance it's a merge artifact 05:19
bacek_at_work petdance, pong
petdance what's yr plan for mergin' the immutable branch? 05:20
bacek_at_work tonight
petdance yay
bacek_at_work in about 4 hours
right after visiting chromatic with baseball bat and cookies
chromatic Samoas, plz.
dalek rrot: r45838 | cotto++ | branches/runcore_purge (67 files):
[runcore] initial purge; all tests pass, still much newly-dead code to remove
 05:23
rrot: r45839 | cotto++ | branches/runcore_purge/config/auto/cgoto:
[runcore] nuke unused dir
rrot: r45840 | cotto++ | branches/runcore_purge (14 files):
[runcore] remove some dead perl code and references to excised runcores
 05:39
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:40
dalek rrot: r45841 | petdance++ | trunk/src/pmc/schedulermessage.pmc:
marking UNUSED(interp)
 05:56
cotto libparrot.so is 1.2M smaller in branch 06:06
sorear wow, almost an entire pagetable full
cotto (no stripping for either) 06:07
06:18 uniejo joined
cotto is the event checking code needed without the prederef cores? 06:20
chromatic bacek_at_work, I can. 06:24
dalek rrot: r45842 | cotto++ | branches/runcore_purge (6 files):
[runcore] remove some flags and dependent code
 06:28
06:34 Cristina joined 06:36 Cristina_ joined 06:38 iblechbot joined 06:43 kurahaupo joined
plobsing_ looking a LexInfo.init_pmc, is there a reason why we require an initializer if we just throw it away? 07:00
cotto If it doesn't appear to make sense, there's a good chance it doesn't. 07:08
chromatic, is turn_ev_check safe to remove? No tests fail without it. 07:09
dalek rrot: r45843 | cotto++ | branches/runcore_purge (12 files):
[profiling] get fulltest passing, remove code related to event checking
 07:20
chromatic I think so. 07:23
cotto There's some code that appears to deal with predereferencing that I'm not especially confident about taking out. 07:25
Is predereferecing only used in the old prederef-related runcores? 07:26
chromatic I think so.
If you're not confident, leave it and file a ticket about it.
cotto ok. I just noticed that some of it's dead code. 07:27
It's nice having a branch to break stuff in. 07:31
dukeleto seems to be creating a security layer for PL/Parrot in PIR. This could be interesting. 07:32
dalek rrot: r45844 | plobsing++ | trunk/src/pmc/lexinfo.pmc:
eliminate LexInfo.thaw that was almost an exact duplicate of Hash.thaw
 07:38
allison dukeleto: The example is good. PIR-level code can always be ported down to C, if needed for speed.
dukeleto allison: gist.github.com/373558 07:51
allison: what are you thoughts on that? 07:52
allison: i basically fake out FileHandle and File and tell the interpreter that the PLParrot PMC should be consulted instead 07:53
sorear what happens if somebody maliciously writes a stored procedure to calculate the trillionth decimal digit of pi? 07:56
dukeleto allison: that doesn't seem to protect against using the open opcode directly 07:58
sorear: they run out of memory
sorear oooh, a quota? 07:59
purl a quota is 200mb.
allison dukeleto: well, the open opcode does open a FileHandle 08:01
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
allison dukeleto: (and I'm guessing the namespace is where you did your fakery)
dukeleto allison: yes. can i modify the PMC ID as well? 08:03
allison dukeleto: no, that's hard-coded in a C enum 08:04
dukeleto: you're right that selectively disabling opcodes is a better solution 08:05
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?
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...
dukeleto allison: allowing read/write inside $PGDATA allows for priveledge escalation and data modification
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
sorear and allowing modification of any other file on the system doesn't?
dukeleto allison: or making file i/o a dynop
allison dukeleto: and it's a security feature that should be built-in to FileHandle
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
allison: that could be interesting
allison dukeleto: the opcodes are a complete red-herring here
dalek rrot: r45845 | cotto++ | branches/runcore_purge (10 files):
[runcore] remove some prederef-related C code
 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
dukeleto allison: so maybe parrot needs a global "threat-level" per interpreter ?
allison (to allow writing to one safe directory) 08:11
dukeleto: essentially, yes
dukeleto allison: if we totally disable all file I/O, parrot libraries and such cannot be loaded, which is kind of useless
allison: the situation i describe is what DBA's tell me they would want
allison dukeleto: library loading is completely internal to Parrot, it's not "exposed" I/O 08:12
dukeleto: so wouldn't be disabled whatever strategy we took for regular I/O
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
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
sorear allison: even when it has to compile .pm ?
allison sorear: NQP-rx, on the other hand, does read a file to decide what to interpret
08:14 lucian joined
allison dukeleto: aye, it's an option, one we should provide 08:15
dukeleto: just not the option pg needs
sorear: so disabling regular I/O would disrupt that
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
dukeleto allison: so would FileHandle consult the current interpreters security level and then alter its behavior?
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 :)
allison dukeleto: that's the general idea, yes. Not in the spec yet, and needs some thinking through the details 08:18
dukeleto: yeah, I've been talking to him on and off for a few years now
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
allison dukeleto: I didn't see it, try reposting 08:19
dukeleto allison: trac.parrot.org/parrot/ticket/1500 08:20
allison dukeleto: ah, a ticket 08:21
dukeleto allison: i sent an email to parrot-dev, but only ::crickets:: 08:22
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
allison dukeleto: yes, so there's more work involved than simply adding an interface to access the info 08:24
dukeleto: the interface looks fine, but add a three-letter 'sec' prefix after Parrot_
dukeleto allison: yes. the info is in lib/Parrot/OpLib/core.pm but doesn't make it into op_info_t 08:25
allison: will add the sec prefix
allison they should live in src/security.c or src/security/api.c
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
dukeleto: ('threat-level' gives me too many bad memories of airport security lines)
dukeleto allison: yes, i was just joking with that term :) 08:27
allison dukeleto: :)
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.
bacek Hello humans. 08:31
purl hey, what about me?
bacek Hello, silly bot.
dukeleto bacek: o hai
bacek dukeleto, o/
dukeleto allison: i will think some more and try to make some more tickets about this stuff 08:37
dukeleto passes out
cotto trac really needs to send out a diff when someone changes the description in a ticket. 08:52
08:56 kurahaupo1 joined
dalek rrot: r45846 | cotto++ | branches/runcore_purge (2 files):
[runcore] remove some more prederef code that doesn't break tests
 08:58
08:58 Khisanth joined
dalek rrot: r45847 | cotto++ | branches/runcore_purge/include/parrot/interpreter.h:
[runcore] remove a pair of now-unused structs
 09:14
09:20 aukjan1 joined 09:39 jsut_ joined
bacek Looks like plobsing broke lexinfo tests in r45844 09:45
dalek rrot: r45848 | fperrad++ | trunk (2 files):
add t/harness.pir
 09:46
rrot: r45849 | bacek++ | branches/immutable_strings_part1 (99 files):
Sync branch with trunk.

  \tMANIFEST.SKIP
  \tcompilers/imcc/imcparser.c
  \tcompilers/imcc/imcparser.h
  \tsrc/string/encoding/ucs2.c
  \tt/native_pbc/annotations.pbc
  \tt/native_pbc/integer_1.pbc
  \tt/native_pbc/number_1.pbc
  \tt/native_pbc/string_1.pbc
purl well, MANIFEST.SKIP is bogus. or a bit like .cvsignore
purl src/string/encoding/ucs2.c is, like, mostly unimplemented
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.
moritz so, immutable strings weren't merged yet?
or are you doing that right now, bacek? 09:53
bacek In progress
(It's main reason why I spotter test failure with LexInfo :) 09:54
moritz :-)
09:56 clinton joined
bacek sigh... 09:58
seen gerd
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
dalek rrot: r45850 | bacek++ | trunk/src/pmc/lexinfo.pmc:
Revert "eliminate LexInfo.thaw that was almost an exact duplicate of
 10:03
bacek moritz, merged. r45852 10:07
moritz bacek++ 10:08
bacek moritz, do you have svn checkout? MANIFEST.SKIP requires regenerating... 10:09
(It was merged incorrectly)
moritz bacek: nope, I'm also a git-svn user 10:11
bacek summon mikehh
ttbot Parrot trunk/ r45852 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/272712.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
bacek sigh...
And fperrad
fperrad, ping
fperrad pong bacek 10:12
bacek fperrad, I broke win32 build with immutable_strings merge
fperrad, basically there is a _lot_ of calls to old version of Parrot_str_substr/concat/append under #ifdef. 10:13
#ifdef WIN32/#ifdef CYGWIN 10:14
fperrad bacek, ok, I'll take a look 10:15
bacek fperrad, thanks!
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:17
ttbot Parrot trunk/ r45853 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/272759.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 10:20
dalek rrot: r45851 | fperrad++ | trunk/runtime/parrot/library/TAP (2 files):
[TAP] fix after r45827
rrot: r45852 | bacek++ | trunk (88 files):
Everybody freeze! Immutable strings enters the building.
rrot: r45853 | fperrad++ | trunk/tools/dev/tapir.pir:
[TAP] minor refactor
mikehh bacek: you requested my presence :-} 10:24
bacek mikehh, MANI.SKIP need some love :)
mikehh 'k will have a loop 10:25
bacek: done 10:30
was re-reading chromatic's book Masterminds of Programming - gaining even more on this read 10:32
10:34 lucian joined
dalek rrot: r45854 | mikehh++ | trunk/MANIFEST.SKIP:
re-generate MANIFEST.SKIP
 10:36
ttbot Parrot trunk/ r45854 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/272841.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 10:40
10:45 JimmyZ joined
bacek fperrad, check trac.parrot.org/parrot/ticket/1571 10:54
dalek TT #1571 created by jimmy++: [PATCH]patch for building on win32.patch after immutable strings merge 10:59
TT #1571: trac.parrot.org/parrot/ticket/1571
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:01
dalek rrot: r45855 | bacek++ | trunk/src/dynext.c:
Apply patch from TT#1571 to restore build on Win32. JimmyZ++
 11:25
rrot: r45856 | gerd++ | trunk/ports/fedora (6 files):
update the Fedora port with the files used to build the current package
 11:41
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.
dalek rrot: r45857 | bacek++ | trunk (111 files):
Generate a _lot_ of .gitignore files.

git to develop parrot.		 11:57
a: c9f4698 | fperrad++ | dynext/pmc/lua (2 files):
fix PMC after merge immutable strings
 12:04
TT #1571 closed by bacek++: [PATCH]patch for building on win32.patch after immutable strings merge
TT #1571: trac.parrot.org/parrot/ticket/1571
bacek fperrad, ooops. Sorry, I had similar commit for Lua in my git repo, but I forgot about it... My bad... 12:14
afk # sleep 12:21
Coke bacek: AIGH. 12:22
you did not just commit 111 .gitignore files...
grumble.
purl grumble. is it typically possible to order replacement laptop keys?
12:29 bluescreen joined 12:30 particle joined
dalek rrot: r45858 | gerd++ | trunk/ports/suse (4 files):
add the latest spec file I found for suse packing
 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.
purl Message for particle stored.
12:34 iblechbot joined 12:45 bluescreen joined 12:46 smash joined
smash hello everyone 12:46
Coke ~~
smash question: can i pass a --cc=... option to parrot's 'perl Configure.pl' ? 12:47
allison what's with all the .gitignore files? 12:48
moritz smash: yes, you can
smash: see perldoc Configure.pl
mikehh smash: yes
smash but inter::progs is complaining about my c compiler 12:49
i get 'Compilation failed with....'
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
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
mikehh does svn ignore the .gitignore :-} 12:52
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?'
allison this seems like the kind of policy we should discuss in #parrotsketch before checking it into the repository
particle allison: agreed, and i really think it can be handled in one .git/ignore file
allison particle: that seems saner 12:54
moritz actually you can do git svn show-ignore > .gitignore 12:55
or even git svn show-ignore > .git/info/exclude 12:56
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
particle not .git/info/exclude, that's for one repo (not to be cloned) 12:58
need to use .gitignore 12:59
smash mikehh: ok, thks
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
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++
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
Coke (cross compile) we don't really support that. 13:08
I'd ping dukeleto, as I think he got the initial RTEMS port at least building.
smash Coke: ah, ok.. thank you
PerlJam good morning 13:10
purl Good Morning Mr Rogers
dalek a: f17b2b7 | fperrad++ | lua/ (2 files):
fix after trac.parrot.org/parrot/changeset/45827
 13:15
13:34 whiteknight joined
whiteknight good morning,#parrot 13:46
PerlJam good morning wk 13:51
whiteknight hello PerlJam, how are you doing today? 13:53
PerlJam whiteknight: I'm doing good. Today will be a great day I think. 14:00
dalek rrot: r45859 | fperrad++ | trunk/compilers/pge/PGE/Exp.pir:
[PGE] add a :nsentry (needed by Lua regex)
 14:01
Andy I like building with g++ so much more than gcc
whiteknight "great" day? that's pretty good. Better than good, in fact
Andy: why is that? 14:03
PerlJam The first step in making your reality what you want is *believing* it will be so :)
whiteknight Then, I *believe* that parrot is 20x faster 14:04
NotFound mikehh: not exactly cross-compiling, scratchpad takes care of most issues. 14:08
Andy whiteknight: More stringent, produces error messages with parameter signatures.
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.
whiteknight I may switch so ICC is my default, at least on the computers I have with it installed
PerlJam whiteknight: then next step is making your beliefs real. You might have a bit of a problem with that for Parrot :)
whiteknight PerlJam: steps!?! I don't have time for steps
PerlJam But ... who's working on lorito? When will it be a real, functioning part of Parrot? 14:11
mikehh re-generated MANIFEST and it added a whole bunch of .gitignore file - should I commoit or what should I do 14:12
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.
(if in fact we're keeping them.)
backing out the .gitignore is fine with me. 14:14
is chromatic awake yet?
opbots, trust me in soc-help 14:19
slavorg But I don't trust you there, Coke
slavorgn But I don't trust you there, Coke
dalek lscript: e18a183 | fperrad++ | dynext/pmc/wmls (4 files):
fix PMC after merge immutable strings
Coke bacek: you about? 14:25
Anyone here able to rebuild the native pbcs? 14:26
14:30 bubaflub joined
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.
Coke BWAHAHAHAHAAH.
Coke hugs purl.
purl Coke: get off me, you botvert!
Coke botsnack?
purl thanks Coke :)
moritz botvert? 14:39
14:40 theory joined 14:51 ash_ joined
Coke like pervert, but with bots. 14:53
moritz I figured. Just wanted to see if purl would elaborate
Coke oh. 14:54
I was assuming a translation problem. =-)
apologies.
purl apologies are in order, then.
Coke out of order!
15:02 integral joined 15:03 zostay_m joined
Coke chrome++ ; trac.parr ... <TAB> # 361 15:04
15:05 Mokurai joined
Coke the TT in PBC_COMPAT is closed, if anyone wants easy karma. 15:07
15:11 ash_ joined
dalek rrot: r45860 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] revert r45273 (useless since r45285)
 15:22
15:27 davidfetter joined
dukeleto it looks like parrot will get 5 of the 10 GSoC slots, tentatively 15:37
tewk dukeleto, how many proposals did parrot get? 15:38
Coke must vote! 15:39
dukeleto: how much longer do I have to vote? =-)
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:45
Coke PerlJam: do we have dups? 15:46
particle PerlJam: no
PerlJam Coke: nope 15:47
15:49 iblechbot joined
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
15:49 riffraff joined
particle it's still possible that we will have dupes today, though 15:49
15:50 whiteknight joined
PerlJam Coke: go upvote Improvements to the NCI system and LLVM Stack Frame Builder :-) 15:51
particle we don't play favorites on #parrot. please keep specific comments about gsoc voting private. 15:52
PerlJam sorry 15:53
Coke I am voting now. I'm reading through everything, not just parrot stuff. :P 15:56
rurban I'm listening also :) 15:57
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. 15:58
Coke dukeleto: you know there are proposals with votes of > 4 from individual voters, yes? 16:03
moritz some of them have been compensated by others, some not 16:05
dukeleto Coke: i am looking now.
Coke: seems like people voted multiple times. I should have sent a stern warning. 16:08
Coke Bruce Gray?
Gray? 16:09
purl i guess Gray is grey is gray
Coke dukeleto: you know, or instructions. =-)
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
PerlJam Doesn't google allow a single person a maximum of +/- 10 anyway?
(I mean, you could *try* to vote +4 +4 +4 +4, but you're only going to get +10)
moritz PerlJam: it does, but it seems sane not exceed -4...+4 per mentor 16:12
Coke Bruce Gray is Util. maybe.
moritz purl: Util?
purl Util is third-party.
16:12 patspam joined
PerlJam this is one area where google could have done better. (voting) 16:13
dukeleto i am zero-ing out people that voted more than +4. it doesn't change the rankings, tho 16:16
Coke dukeleto: er, you're changing their 4+2 to 0? 16:17
or to 4?
dukeleto Coke: changing all votes to >4 to 4
moritz kinda expects the SMOP project to be ranked lower by that 16:18
16:20 darbelo joined
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
moritz dukeleto: ok
dukeleto some of the proposals in the top 10 need to be improved, such as making the timeline specify each week 16:22
moritz I commented on some of them asking for more specific 16:23
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
I've made that mistake too, in the some previous years 16:24
whiteknight dukeleto: Could you move me to mentor the hybrid threads one, and allison to mentor the NFG one? 16:25
16:25 Mokurai1 joined
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:31
am i wrong to think we shouldn't be giving students hints about who might or might not be accepted? 16:32
let me know if i'm being paranoid.
moritz particle++ 16:33
16:33 aukjan joined
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:33
particle wants a "mentors only" jacket 16:35
PerlJam particle: you are being appropriately paranoid. :) 16:36
particle++
dukeleto particle: i agree with you 16:38
whiteknight: i will do that now
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.
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
dukeleto whiteknight: reassignment done 16:41
whiteknight dukeleto++
Coke is there such a thing as a private channel on irc?
dukeleto conversation that does not say "X is accepted" is fine. Just don't ruin the surprise for everyone
whiteknight Coke: sure. Channels can be invite-only
PerlJam Coke: you can make one invite only 16:42
whiteknight or add a bot that boots anybody not on a whitelist
NotFound Or set a password
dukeleto we have the tpf-gsoc mailing list for private discussion. only mentors are on that list
16:44 eternaleye joined
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
Maybe not for corevm, we'll probably want perl there for botstrap reasons.
plobsing ping bacek 16:51
nopaste "plobsing" at 192.168.1.3 pasted "LexInfo access from PIR" (16 lines) at nopaste.snit.ch/20323 16:52
plobsing msg bacek You can already instantiate a LexInfo from PIR, check out 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.
darbelo Unletaed thought, what's up with the .gitignores? 17:01
mikehh bacek put in a bunch for git users - ssome not happy about it 17:02
the consensus seems to be there should only be one .gitignore in svn 17:03
Coke mikehh: zero or one, yes.
darbelo I don't mind them. 17:04
I just noticed them now and wondered if I has missed something. 17:05
PerlJam what do "extra" .gitignore files hurt?
dukeleto darbelo: i am confusing to how TAP::Parser in parrot core relates to the external Tapir repo 17:07
s/confusing/confused/
darbelo dukeleto: Don't worry. I am too. 17:08
ash_ is there a wiki page for the intended work with the llvm?
dukeleto darbelo: it kind of looks like fperrard took Tapir and modified/added features, then committed it to core
ash_: should be something
ash_: trac.parrot.org/parrot/wiki/Lorito 17:09
ash_ thanks dukeleto 17:11
Coke PerlJam: MANIFEST creep is the most annoying.
dukeleto only one .gitignore should be needed 17:12
PerlJam Coke: ah, good point.
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.
dukeleto there are some automated tools that generate many .gitignore, which bacek probably ran
Coke Why not just let dukeleto put it in the mirror, or use the tools provided by git-svn?
if we're going to keep them, one top level one is probably the best way, and it's an easy fix. 17:13
17:13 mmcleric joined
dukeleto Coke: then it wouldn't be a mirror ;P 17:13
+1 to a single .gitignore file, regardless of it being in SVN or git
ash_ github can let you use svn to checkout a git repository now...
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:14
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
dalek kudo: 56120b7 | (Solomon Foster)++ | src/ (4 files):
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
ash_ are lorito and the llvm jit system going to be developed in parallel basically? 17:24
Coke I think there is a wiki page describing the plan for that. 17:25
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:26
17:34 kjeldahl joined
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:35
cotto_work hi whiteknight 17:36
nm. Was backscrolling and forgot what I was doing. 17:37
whiteknight hello cotto_work
darbelo "Small enough to be incredibly fast"?
17:37 ash_ joined
PerlJam fewer ops and another opportunity for optimization 17:38
The "core" would be faster (though it should have more work to do in general) and more regular. 17:39
17:39 joeri joined
particle a feather is no faster than a bowling ball 17:40
darbelo That doesn't tell us much. You can make bowling balls go damm fast with the proper equipment ;) 17:41
PerlJam a feather is quite a bit slower in the presense of an atmosphere :) 17:42
17:43 Mokurai joined 17:44 cotto_work2 joined
darbelo Also, is that feather attached to large bird? 17:44
particle that's what i'm saying. smaller != faster 17:45
nopaste "NotFound" at 192.168.1.3 pasted "Proof of concept patch: avoid a method call in every lexinfo creation" (111 lines) at nopaste.snit.ch/20324 17:47
NotFound Someone wants to benchmark this?
Coke someone work on getting us one of these to remote develop on: www.reinvented-the-workstation.com/...evelopers/ 17:50
darbelo I somehow doubt our need for windows 7 support is *that* bit. 17:56
whiteknight particle: no, smaller is definitely not always faster
purl okay, whiteknight.
whiteknight damnit purl 17:57
purl damnit i am a bot!!!
whiteknight there are lots of opportunities for Lorito to improve performance anyway, regardless of the smaller size 17:58
18:07 hudnix joined
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:11
NotFound plobsing: failed explanation, is during disassembly 18:12
18:13 ash_ joined
plobsing OK. Thanks for clarifying. 18:13
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:15
dalek kudo: 3e3a934 | (Solomon Foster)++ | src/core/Numeric.pm:
Add Numeric.Numeric.
 18:17
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:18
darbelo plobsing: Easier to deprecate this and write new ones without any backward-compat issues. 18:19
NotFound plobsing: you mean providing fakecutables for the new versions? 18:20
plobsing NotFound: exactly
NotFound Not a bad idea, but darbelo's point isn't also bad.
dalek rrot: r45861 | fperrad++ | trunk/runtime/parrot/library/TAP (3 files):
[TAP] add pod
 18:21
kudo: 1f638cc | moritz++ | docs/ChangeLog:
[docs] another ChangeLog entry
 18:23
kudo: e329a94 | moritz++ | src/core/Date.pm:
[Date] move private subs inside the class
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:28
NotFound plobsing: i think so 18:29
plobsing complicated programs like rakudo would probably benefit the most. but seeing as rakudo doesn't build against the current trunk... 18:30
NotFound I can't benchmark with winxed because winxed doesn't use lexicals. 18:31
Coke whinges again about the packfile tests. 18:36
plobsing wonders why everyone should be able to read i386 packfiles, but i386 doesn't have to be able to read anyone elses 18:37
Coke plobsing: they do. 18:38
but mainly in theory. =-)
whiteknight packfile portability is known to be a big problem 18:40
plobsing unless you're on i386, the be-all and end-all of architectures as far as parrot is concerned 18:41
NotFound I disagree, my main development machine is x86-64 ;) 18:42
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:43
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:44
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
plobsing orly?
purl YA RLY.
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:46
Maybe if I had any ppc hardware, but we had exactly one ppc user at the time, and I don't like macs. 18:47
whiteknight I don't like spiders 18:48
NotFound I don't like mondays 18:49
particle i don't like "don't like"
whiteknight mondays--
NotFound u-u-u-u-uuuu...
rurban packfile portability is no problem at all if would be maintained (and tests enabled) 18:50
dalek nxed: r446 | julian.notfound++ | trunk/examples/packfile.winxed:
don't die if no anotations in example packfile
18:51 chromatic joined
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...
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
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.:
.sub 'foo@3f3F#$' :method :alias('foo') ....
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.
shockwave moritz, so that it can be called by both it's long, mangled name, as well as it's alias.
arnsholt Yeah, I figured it was more that kind of "don't like"
moritz shockwave: I'm not aware of such a feature (but that doesn't mean much) 18:55
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
Coke jit worked on ppc? !?!?!?! my old macs would disagree with you. =-) 18:57
moritz NotFound: uhm, not sure if that actually simplifies debugging :-) 18:58
sounds as if you have bug there, it's making it much harder
chromatic JIT worked on PPC.
shockwave NotFound: I'll keep it in mind.
NotFound shockwave: just an idea, not sure if workable 18:59
19:00 lucian joined
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.
chromatic Not many ops anyway.
NotFound chromatic: please take a look at nopaste.snit.ch/20324 19:01
19:03 mmcleric left
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.
chromatic Avoiding the method call is nice.
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.
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.
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?
NotFound plobsing: doing all initialization inside the lexinfo pmc, without using vtables or methods of hash 19:08
chromatic Using init_int might work.
NotFound chromatic: init_int in hash? 19:09
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:10
NotFound plobsing: it doesn't, the method called takes care of initialization 19:11
dalek nxed: r447 | julian.notfound++ | trunk/examples/packfile.winxed:
show debug segment size in example packfile
NotFound But that method does the creation and destruction.
plobsing why not just create the hash yourself and use set_pointer? 19:12
NotFound plobsing: that is the coupling I mentioned.
plobsing ah. that's not so bad. 19:13
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:15
NotFound plobsing: maybe just because there is no knwon reasonable usage, and thus no worth testing. 19:16
plobsing NotFound: I have a usage. If we make it work, we can ditch LexInfo.thaw and use Hash.thaw in stead 19:17
NotFound plobsing: not a bad argument. Using init_pmc just to pass NULL looks pointless. 19:21
chromatic plobsing, your example uses init_pmc, not init 19:22
plobsing I did it in r45844, but it got reverted
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:23
19:24 pjcj joined
chromatic Yeah, there's no good way to prevent its creation from PIR. 19:25
Coke documents his native_pbc frustration on-list 19:26
if you can create it from C, you can create it from PIR.
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:27
Coke points to Andy's message on the list. 19:30
(Andy D)
(thankfully it's post-release.)
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
darbelo It sounds immutable string related to me. 19:31
chromatic It is, but bacek and I improved performance there.
Coke perhaps he's more sensitive to memory usage? 19:32
darbelo 1064262424 bytes 19:33
whiteknight back in my day, we used to allocate at least that many bytes. Uphill both ways
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
chromatic My phone has more memory than my first couple of computers.
19:36 ash_ joined
pmichaud pbc_to_exe was specifically written to take advantage of Parrot's old string characteristics 19:36
immutable string probably changed those characteristics
(because before pbc_to-exe's optimization, it was taking very long to do what it did)
chromatic real 0m0.714s 19:38
That's how long it takes to build for me on trunk now.
19:39 iblechbot joined
pmichaud also, Andy's message says that it's with the released 2.3.0, which was pre-immutable strings. 19:39
oops, I misread. nm. 19:40
he says 2.3.0 takes 3 seconds, but r45860 takes forever.
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 nopaste.snit.ch/20327
pmichaud tries r45860 locally 19:41
darbelo pmichaud: No, he said r45860. 19:43
pmichaud: 2.3.0 works for him in ~ 3s
pmichaud 19:40 <pmichaud> oops, I misread. nm.
darbelo Ugh missed that. Sorry. 19:44
19:49 gssgss joined
chromatic That patch looks much cleaner, NotFound. 19:57
19:58 shockwave left
NotFound chromatic: yes, that way is easier to write cleanly at the first attempt. 19:58
TimToady phone 20:00
allison is anyone else having trouble getting in to the conf call? 20:04
NotFound Now that I'm on it....
Coke karma chromathic 20:05
purl chromathic has karma of 1
Coke chromathic--
chromatic++
20:06 Spreadsheet_ joined
Spreadsheet_ Hello 20:07
purl hey, Spreadsheet_.
20:07 Coke joined
Spreadsheet_ Hi purl 20:07
Coke argh. /quit ain't /win quit.
nopaste "cotto_work" at 192.168.1.3 pasted "some rakudo benchmarking with various runcores (summary at bottom)" (105 lines) at nopaste.snit.ch/20328 20:08
moritz cotto_work: so they are all basically the same 20:09
cotto_work yeah
certainly not a dramatic difference 20:10
chromatic Rakudo's overhead masks a lot of the difference at the op level.
cotto_work How so? Rakudo's overhead is also mostly ops.
chromatic It's mostly creating and destroying PMCs. 20:11
cotto_work otoh it shows how much the runcores matter to Rakudo. 20:12
chromatic As in "not".
cotto_work yup
20:18 lucian joined
dalek TT #1572 created by doughera++: pbc_to_exe unusable after immutable_strings merge 20:20
TT #1572: trac.parrot.org/parrot/ticket/1572
rrot: r45862 | NotFound++ | trunk/src/pmc/hash.pmc:
avoid creating and destroying a hash in Hash set_value_type method
20:20 Mokurai joined
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:20
Coke the name Bruce Gray came up somewhere. 20:21
might have been GSOC related. nothing bad, just trying to place nick to name.
ash_ it was on my GSoC application
(might be it?)
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_
ash_ one of the GSoC dead lines is today
cotto_work yup. No further ratings are allowed after about 3.5 hours ago. 20:24
official announcements are scheduled for the 26th at 1900 UTC 20:26
particle stay tuned for more. 20:27
dukeleto it seems that TPF is not going to get involved in any dedup hijinx 20:29
NotFound parrot builds fine in Ubuntu 10.04 beta i386 20:34
20:35 allison joined
dalek rrot: r45863 | petdance++ | trunk/src/pmc/bignum.pmc:
removed two unused vars
 20:37
rrot: r45864 | NotFound++ | trunk/src/pmc (2 files):
implement Hash init_int vtable to create a hash with given value type, use it in Lexinfo init_pmc
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
and cprederef
bacek Good morning, @humans. 20:41
20:42 davidfetter joined 20:45 gssgss joined
cotto_work hi bacekbot 20:46
20:47 bluescreen joined
Coke bacek - any clues on the mk_native_pbc post? 20:50
bacek Coke, "our PBC format suck" 20:51
Coke or, "can you just take over that RetContinuation ticket"? =-)
bacek Coke, no! :) 20:52
Coke but it was your ticket and I did all the hard work! =-)
bacek Coke, retcon.diff in ticket? 20:53
dalek rrot: r45865 | chromatic++ | trunk/t/op/vivify.t:
[t] Removed unnecessary diagnostic output.
rrot: r45866 | chromatic++ | trunk/tools/dev/pbc_to_exe.pir:
[tools] Fixed non-GCC, non-MSVC code generation in pbc_to_exe to avoid
20:54 gssgss left
Spreadsheet_ Does Parrot have any optimizing features? 20:54
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.
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
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.
bacek Coke, Configure.pl failed... 20:58
Coke bacek: lies!
bacek During configuration the following steps failed:
25: auto::pmc
55: gen::core_pmcs
Coke did you svn remove retcontinuation.pmc ?
bacek step auto::pmc died during execution: No pmclass declaration found in retcontinuation.pmc at config/auto/pmc.pm line 167.
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 :)
Coke (you probably have empty files there now after applying the patch.
bacek Coke, it helped. Rebuilding 21:00
21:00 rurban_ joined
Coke did you resolve the conflict in PBC_COMPAT? 21:00
bacek Yes, of course. 21:01
purl Indubitably.
21:01 ZeroForce joined
Coke woot. 21:01
trac.parrot.org/parrot/ticket/1427 btw, if you happen to close it. 21:03
21:03 cotto_work joined 21:04 kurahaupo joined
Coke who belongs to compilers/ncigen ? 21:08
tewk I do, you want to chop it, go ahead. 21:09
dalek kudo: fadb800 | moritz++ | (2 files):
make reduce() a bit more usable, and test it
Coke it depends on NQP, which is on the chopping block.
can we safely remove it? is it installed?
tewk its not used by anyone that I know of, its not installed 21:10
Coke k. I'll open a ticket for removing it, then. you sure that's ok? 21:11
tewk sure
Coke tewk++
bacek Coke, TT#1462 (nqp deprecation)
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.
bacek: yes?
bacek Coke, retcont is GONE 21:14
Coke bacek: that's ok, you can update the date without breaking pbc compat. =-)
bacek++
moritz Coke: notes to releasers will get lost here... if it's important, put it in release_guide.pod
dalek kudo: 205d9d3 | moritz++ | src/Perl6/Grammar.pm:
properly carp on $\\ usage
 21:15
Coke moritz: unless someone borked it, we already had it that way. =-)
moritz :-)
cotto_work PBC_COMPAT should reflect the latest supported release 21:18
Coke that will help with later backward compatibility. 21:20
maybe.
cotto_work maybe
just noting that it should have happened 21:21
bacek cotto_work, yes. Looks gerd forgot to update it... 21:22
21:22 Whiteknight joined
Coke we can retro-comment it. 21:23
who owns ext/SQLite3? 21:26
dalek rrot: r45867 | bacek++ | trunk (17 files):
Remove RetContinuation PMC. Closes TT#1427. Coke++ for all hard work.
rrot: r45868 | bacek++ | trunk/PBC_COMPAT:
Fix date in PBC_COMPAT.
TT #1427 closed by bacek++: RetContinuation PMC 21:27
TT #1427: trac.parrot.org/parrot/ticket/1427
TT #1573 created by coke++: remove compilers/ncigen
TT #1573: trac.parrot.org/parrot/ticket/1573
Coke looks like simon started it. it's bitrotted, requires languages/rakudo
dalek TT #1572 closed by chromatic++: pbc_to_exe unusable after immutable_strings merge
TT #1572: trac.parrot.org/parrot/ticket/1572
Coke I vote we kill it. :P
cotto_work +1
purl 1
darbelo KILL! KILL! KILL! 21:28
cotto_work It's a good week for nuking stuff. 21:31
bacek speaking of which. Can someone with svn checkout nuke immutable_strings_part1 branch? 21:39
Coke, how partcl survived immutable strings merge? 21:47
cotto_work did partcl work with trunk before the merge? 21:48
darbelo bacek: Killled. r45869 21:49
cotto_work Bam!
Spreadsheet_ en.wikipedia.org/wiki/Comparison_of...l_machines 21:51
cotto_work Now that strings are immutable, it'll be interesting to see what hashing at initialization does.
The Parrot entry definitely needs updating.
Spreadsheet_ According to this Parrot does not have "Code security", "pre-compilation", and "shared libraries" 21:52
Are there plans to do that in the future?
cotto_work Spreadsheet_ that's out of date.
Parrot 21:53
Spreadsheet_ What's wrong, I have an account and can change it
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.
darbelo "Shared libraries are a facility to reuse segments of native code across multiple running programs" 21:54
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 gitorious.org/parrot-plumage/parrot-plumage and the design docs are at trac.parrot.org/parrot/wiki/ModuleEcosystem
japhb <rez.
Huh what?
darbelo We don't have it, at least not as described there.
chromatic libparrot.so 21:56
purl hmmm... libparrot.so is 1.2M smaller in branch
japhb ash_, was I needed for something? (Plumage is one of my IRC client highlight words)
ash_ no, i was just commenting on the link to the wiki article, wouldn't plumage count as shared libraries? 21:57
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.
darbelo It's not. 21:59
cotto_work shared libraries aren't new technology.
japhb They're referring to sharing identical memory pages of library code across multiple child processes.
dalek rrot: r45869 | darbelo++ | branches/immutable_strings_part1:
Branch merged to trunk and is no longer needed.
japhb As memory-dedup'ing kernels/hypervisors become more common, it probably becomes less critical that VMs directly support memory sharing themselves. 22:00
But, you know, long conversion period. :-)
arnsholt Is there a go-to resource for how to work with PAST? 22:04
japhb #perl6? # Half kidding 22:05
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
22:06 kurahaupo joined
dalek kudo: 2a93f45 | (Martin Berends)++ | (2 files):
[core/Temporal.pm] add a fairly large subset of strftime() and some tests for it
 22:06
kudo: c778995 | (Solomon Foster)++ | src/core/ (2 files):
Remove Mu.Numeric. Add Any.Numeric, and make it both pickier and more informative.
22:07 bakkdoor joined
bakkdoor hi 22:08
:)
cotto_work hi bakkdoor
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:10
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 :)
chromatic bakkdoor, have you seen the Parrot book? docs/book/pir
bakkdoor i ordered a book today at amazon
don't remember the name. wait
Parrot Developer's Guide: Pir 22:12
that's it
i guess it's by allison ? :)
chromatic: is it the same like the one you mentioned or a different one?
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.
it wasn't expensive - 9 euros or so - i figured I'd try it out :)
Coke bacek, darbelo - it worked before the merge. partcl itself might need love. partcl-nqp has no C in it.
chromatic If you have questions, we'll do our best to help you. 22:14
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:15
chromatic No, you shouldn't have to know any Perl at all. 22:16
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:17
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.
arnsholt It's essentially Perl 6-ish syntax and some amenities over PIR
japhb bakkdoor, as you surmised, learning PIR is very useful. NQP is much easier, but needs some PIR knowledge for maximum effectiveness
arnsholt It's pretty simple (and very nice to work with, IMO)
22:19 hercynium joined
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. :-)
arnsholt A very nice grammar engine too
bakkdoor what exactly does nqp stand for?
arnsholt Not Quite Perl
=)
bakkdoor ah ok :) 22:20
yeah i've read about it before somewhere
cotto_work nqp?
purl rumour has it nqp is github.com/perl6/nqp-rx or not quite low-level enough for some purposes
arnsholt If you're used to working with yacc and flex and such, NQP's grammar engine will be welcome relief
cotto_work nqp is also Not Quite Perl 6
purl okay, cotto_work.
arnsholt Or at least I found it to be =)
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
bakkdoor arnsholt: yeah I currently use bison & flex
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.
arnsholt I find NQP easier to work with, as it's mostly a top-down parser rather than bottom up as yacc-style parsers
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.
bakkdoor ok :)
22:24 darbelo joined
bakkdoor oh, what I've been wondering about as well. how is parrot's support for concurrency? 22:24
japhb Funny you should ask ...
bakkdoor japhb: hm?
japhb We recently discussed whether we wanted to do more concurrency work or garbage collection work as our next big push. GC won.
bakkdoor ah ok
cotto_work There's a promizing gsoc threading proposal though 22:25
for parrot
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
chromatic I'd like to support that, but right now it's not easy in Parrot efficiently.
darbelo To be fair, the gc has caused enough threading breakage that improving it also improves our threads.
dalek TT #1574 created by coke++: remove ext/SQLite3 22:32
TT #1574: trac.parrot.org/parrot/ticket/1574
TT #1575 created by coke++: remove ext/SQLite3
TT #1575: trac.parrot.org/parrot/ticket/1575
cotto_work Do we have to remove it twice?
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
22:33 kid51 joined
dalek kudo: 0b67c52 | jonathan++ | src/metamodel/RoleToRoleApplier.nqp:
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
chromatic Hm, fib.pir is 10% faster than it was a couple of days ago. 22:43
japhb Whysat? 22:44
chromatic Checking now.
Looks like a simplification in Parrot_pcc_build_sig_object_from_op(). 22:46
Oh wait, wrong benchmark. 22:48
22:49 ZeroForce1 joined, Myhrlin joined, alexn_org joined
mikehh did we come to a decision on what is happening with the .gitignore files? 22:58
22:58 tetragon joined
mikehh MANIFEST needs re-generating (or commiting anywaty) 22:59
anyway 23:00
cotto_work You can fix it while waiting for whatever the long-term solution is.
mikehh 'k
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
chromatic Time-based benchmarks lie.
darbelo All benchmarks lie. Time-based benchmarks lie more. 23:03
mikehh darbelo: merge with git then sort it out :-}
dalek rrot: r45870 | mikehh++ | trunk/src/ops/core.ops:
fix codetest failure - trailing spaces
 23:04
darbelo I also suspect parrot's svn repo is slightly corrupted somwhere. 23:05
dalek TT #1575 closed by coke++: remove ext/SQLite3
TT #1575: trac.parrot.org/parrot/ticket/1575
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.
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 ;)
sorear and get near-cycle-accurate time benchmarks
darbelo: chromatic does all his benchmarks using simulator
cotto_work You mean rtems?
That's actually a really good dea. 23:08
sorear I mean physically installing rtems/i386 on a P133
cotto_work well, *could be* a really good idea
darbelo sorear: Oh, you mean wallclock time RTEMS? That could work. 23:09
sorear Yes. And by wallclock I mean RDTSC.
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:11
sorear japhb: surely it will be better than chromatic's raw instruction counts 23:12
japhb sorear, if he's getting cache miss stats, that will be very different on e.g. a Core 2. 23:13
Let alone a Core i.
chromatic Or a 64-bit machine.
japhb chromatic, right.
(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.
japhb chromatic, Right, somehow I always forget that people do that. :-)
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
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.
dalek rrot: r45871 | mikehh++ | trunk/MANIFEST:
re-generate MANIFEST
 23:21
Coke I wish irssi would automatically convert "win X" to "/win X" for me.
anyone have a deep, abiding love for SQLite3 ?
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.
Coke well, first you'd have to make it work.
japhb sorear, that's manifestly untrue.
Coke, fair enough. Hadn't tried. I was speaking of the general tool, not our implementation. 23:23
sorear, (that they are worthless)
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.
japhb Coke, gotcha. I'm not using that.
(and it sounds like I *couldn't* even, if I wanted to. :-)
my typing is sucking, sigh 23:25
23:28 lucian joined
mikehh that was not a good idea codetest/distro_tests FAIL on all the .gitignore files (svn properties missing) otherwise 23:33
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#33375), fulltest) at r45871 - Ubuntu 10.04 beta amd64 (gcc with --optimize)
japhb chuckles at the thought of giving a .gitignore svn properties 23:34
darbelo Say, is ports/fedora/2.3.0/parrot.desk.in.tar.gz sipposed to be there? 23:35
23:36 ingy joined
dalek rrot: r45872 | chromatic++ | trunk/tools/dev/pbc_to_exe.pir:
[tools] Fixed MSVC code generation in pbc_to_exe to avoid expensive string
 23:37
rrot: r45873 | chromatic++ | trunk/t/op/fetch.t:
[t] Removed more debugging output.
rrot: r45874 | chromatic++ | trunk/src/call/context.c:
[PCC] Changed STRING register initialization to use STRINGNULL from NULL.
darbelo I have no knowledge of the packaging process for that, but I feel odd about putting gziped tarballs into the repo.
dalek TT #1576 created by petdance++: Update functions that take STRING * to take const args where possible 23:38
TT #1576: trac.parrot.org/parrot/ticket/1576
TT #1577 created by coke++: gitignore files
TT #1577: trac.parrot.org/parrot/ticket/1577
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
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.
cotto_work darbelo: you mean most of them? 23:41
japhb That sentence should just end after the fourth word, darbelo
darbelo It's a particular sort of hate I have for this particular sort of merge. 23:42
While I hate svn's merging in general. Here I can hate with specificity.
23:44 kurahaupo joined
mikehh japhb: I'll have a look at that - but meanwhile I;ll wait for a policy decision on the .gitignore files 23:49
I'll
Coke mikehh: please don't revert the manifest fix.
it can be fixed again once gitignore is cleaned up.
mikehh I did already - you want me to put it back
Coke mikehh: I opened a ticket, you have plausible deniability.
mikehh Coke: it is fairly easy to do, one way or another 23:52
dalek rrot: r45875 | coke++ | trunk (3 files):
Remove bitrotted ext/SQLite3 (TT #1574)
 23:53
rrot: r45876 | darbelo++ | branches/include_dynpmc_makefile (486 files):
Sync branch with trunk.
rrot: r45877 | mikehh++ | trunk/MANIFEST:
revert MANIFEST commit - too many codetest/distro_test problems with .gitignore files - no svn properties
TT #1574 closed by coke++: remove ext/SQLite3 23:55
TT #1574: trac.parrot.org/parrot/ticket/1574
cotto_work allison, ping 23:56
Coke mikehh: ... you reverted the sql changes, too.
fixed. 23:57
darbelo Two tickets, two removals. Makes sense to me. 23:58
:) 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!