Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 14 January 2009.
dalek r35567 | kjs++ | trunk/compilers/pirc/src (5 files): 00:00
: [pirc] fix a bug that in case of a 2-operand version of if/if_null and the unless variants, no bit was set that the 2nd operand was actually a label. This would prevent that operand be fixed up into a bytecode offset, and be emitted as bytecode. This patch fixes all that.
review: www.parrotvm.org/svn/parrot/revision?rev=35567
00:09 AndyA joined
dalek r35568 | Whiteknight++ | trunk (4 files): 00:18
: [Core] remove dependence on PObj_data_is_PMC_array_FLAG, which was only used in three PMCs. Replaced with custom mark VTABLE routines.
review: www.parrotvm.org/svn/parrot/revision?rev=35568
r35569 | japhb++ | trunk/config/gen: 00:31
: [OpenGL] Add preliminary support for GLC
japhb Infinoid: Would you mind pulling and testing OpenGL on your box?
dalek : * config/gen/opengl.pm:
: + Add typedefs needed by GLC character rendering library
: + Mark GLC callbacks as skipped for now
review: www.parrotvm.org/svn/parrot/revision?rev=35569
Infinoid heh. post a bug report to LKML, get spam about winning 800 thousand euros in the "linux lotto" the very next day. 00:32
can do, one sec
japhb No good deed goes unpunished, clearly ...
00:32 particle joined
dalek r35570 | Whiteknight++ | trunk (4 files): 00:32
: [GC] Remove Parrot_gc_trace_pmc_data(), it's unused now that nothing is using the PObj_data_is_PMC_array_FLAG flag.
Infinoid the wonders of modern technology 00:33
dalek review: www.parrotvm.org/svn/parrot/revision?rev=35570
Infinoid japhb: went through Configure.pl cleanly 00:34
what else should I test?
japhb Can you compile parrot and run any of the OpenGL demos? I obviously don't have a GLC test there yet, but I'd like to make sure the OpenGL bindings compiled cleanly. 00:35
00:41 braceta left
Infinoid opengl example pir files are running fine 00:41
japhb installs libglc-dev to test locally ....
Infinoid: excellent.
Infinoid I can't run the .p6 files because it can't find OpenGL in @INC... I'm probably running it from the wrong dir
japhb Yeah, you have to run it just like in the SYNOPSIS 00:42
Infinoid documentation? read? NEVER 00:43
japhb I put in a request to get that fixed in Rakudo, but I don't think it ever got done ...
dalek r35571 | Whiteknight++ | trunk (5 files): 00:45
: [Core] remove the last few mentions of PObj_data_is_PMC_array_FLAG, and fix an error that I apparently uncovered when I ran make headerizer last time. My bad.
review: www.parrotvm.org/svn/parrot/revision?rev=35571
japhb That's odd ... *I* can't run any OpenGL examples now. 01:10
japhb wonders what went wrong ...
01:14 Casan joined 01:29 kid51 joined
Infinoid heh, sorry 01:30
japhb updating very old checkout of parrot on 64-bit box to see if it's another NCI 32-bit/64-bit snafu 01:34
01:35 Fayland joined
Infinoid I'm running on 64 bit, if it helps. 01:35
japhb Yeah, and I was testing on 32 bit
I'm ruling out other variables by using two boxen with nearly the same config, except CPU 01:36
Well, on the 64 bit box, PIR examples run perfectly (where they just show black in 32 bit), but Perl 6 examples run the same in both places -- or rather, don't, since they crash with big ol' backtrace on both boxen. 01:45
So it sounds like two bugs. 01:46
Infinoid urk. 01:49
japhb Checking with --jitcapable=0 on the 32-bit box
Infinoid japhb++ 01:50
odd. PackfileFixupTable is supposed to return its elements as "PackfileFixupEntry" objects, but instead it seems to be returning ParrotInterpreters. I don't think that's supposed to happen. 01:57
oh, it didn't have a PackfileFixupTable to begin with. nevermind. 01:58
msg jonathan pdd13 specifies some enums for things like fixup type and constant type. Are these available in pir land somehow (via sets of _keyed_str methods or some kind of constants)? or are the HLLs just going to use magic numbers for them? 02:05
purl Message for jonathan stored.
japhb Yup. Problem 1 is 32-bit JIT NCI -- it's broken again (still?) 02:07
tewk: ping
nopaste "japhb" at 76.191.190.8 pasted "Rakudo failure trying to run simplest OpenGL example" (119 lines) at nopaste.snit.ch/15312 02:12
japhb pmichaud, jonathan: Can one of you take a look at the above Rakudo crash? 02:16
pmichaud my $window = glutCreateWindow('Test'); 02:17
what kind of object is $window there?
japhb pmichaud: checking ... 02:18
pmichaud try say($window.PARROT); 02:19
japhb A simple int
pmichaud okay, that's good.
Let me update parrot/rakudo on my system and see how far I get. 02:20
japhb ok
pmichaud (I'm also in the midst of composing a long blog post so I'm only operating at partial capacity)
in general we know that Rakudo has some issues with NCI. Or, more precisely, some NCI libraries have issues with the values that Rakudo sends it. 02:21
japhb pmichaud: Are there details on that somewhere?
Which reminds me, configure with --jitcapable=0 in order to rule out that mess. 02:22
pmichaud thanks
(details) we're still working out exactly what they are. But in general, Rakudo tends to create references to things that aren't Rakudo types or otherwise indicate that they are "scalar" values. 02:23
then when a function is called, Rakudo sends the reference instead of the thing being referenced.
(this goes for NCI functions as well)
so many NCI functions don't know what to do with the reference that Rakudo sends.
and get confused because the PMC isn't the exact type they expect.
japhb gotcha. 02:25
How do you even go about debugging that, from the point of view of the library?
pmichaud I'm not sure.
japhb bah, AFK for a bit, bbiab
pmichaud that's where we need some more examples to work with. 02:26
(like the one you provided.)
Also jonathan and I need tuits. :-)
my tuits for the week just got reassigned by today's events, I think.
Casan can it be expected that the issues with NCI is also causing issues to DBDI development? 02:28
dalek r35572 | infinoid++ | trunk/t/pmc: 02:29
: [pdd13] Fix some descriptions in packfileconstanttable.t. Add a sanity check
: to make sure we're dealing with the right segment of the PMC.
review: www.parrotvm.org/svn/parrot/revision?rev=35572
pmichaud Casan: yes, I think that's the case.
dalek r35573 | infinoid++ | trunk (2 files):
: [pdd13] Implement and test the readonly portions of PackfileFixupTable.
review: www.parrotvm.org/svn/parrot/revision?rev=35573
r35574 | infinoid++ | trunk (2 files): 02:30
: [pdd13] Implement and test the readonly portions of PackfileFixupEntry.
review: www.parrotvm.org/svn/parrot/revision?rev=35574
02:31 jimmy joined
Infinoid msg jonathan Is the PMC API defined by pdd13 updated with the current state of the various Annotations objects? (Do we expect those to match reality or are they still subject to change?) 02:32
purl Message for jonathan stored.
Infinoid pmichaud: I take it you're referring to repo management stuff. I've got some spare tuits, anything I can help with? 02:35
pmichaud Infinoid: I'm about to post a message, I'm more interested in planning than in execution for today.
Infinoid no problem, I'll keep plugging away at other stuff then.
pmichaud if you're interested in arguing in favor of a git-based repo, then answering the questions of "how we continue to make use of Parrot and spectest suite" would seem critical. 02:36
Infinoid the Makefile executes svn to get a new checkout of spectest, it wouldn't make any difference what VCS the parent project was using. As for git, meh. This channel's had too much VCS battling already today. 02:37
Casan :)
pmichaud Infinoid: so a person want to use Rakudo would need both git and svn.
*wanting
and yes, there's been a lot of vcs battling, I'm not trying to stoke the fire. 02:38
Infinoid it's a good point. if the spectests are in svn, then you need svn (or git-svn, which would probably want to grab full revision history and would be wasteful in this instance)
pmichaud that's simply what I see as the largest obstacle to a git switch for Rakudo.
Casan sounds reasonable to evaluate the options. 02:39
Infinoid actually, the spectest_checkout target might want to be using "svn export", because it's essentially fetching a throwaway copy to run the tests 02:43
I think git-svn would use far too much bandwidth in this case, it doesn't have an equivalent of "export".
pmichaud ("export") -- no, because we subsequently do "svn up"
because otherwise "export" uses too much bandwidth.
02:43 jrockway joined
Infinoid ah. guess I rarely get that far 02:43
pmichaud there's not really a way to say "export only what's new". That's what "svn up" is for. 02:44
Infinoid indeed
my qualm is that I don't know if git-svn has a way to say "fetch the latest revision only, not every revision all the way back to -r1"
last I checked, symbolic revision names like -rHEAD were not supported. 02:45
pmichaud right.
I don't know, I've yet to use git. I'll probably play with it over the next couple of days to see what it's like, but maybe among the people in the community we can come up with a creative answer.
Infinoid I think switching a project over to a complicated VCS which the main two project developers have never used before, in the timeframe of a week, probably isn't justified. 02:47
pmichaud it doesn't have to happen in a week. 02:48
and both jonathan and I are pretty quick learners :-)
Infinoid I have no doubt of that :)
pmichaud I'm more concerned about how it affects the larger community than how it affects me personally. I can figure git out :-)
especially since it's apparently the "greatest software package ever created in this universe or any other" 02:49
02:49 jrockway joined
pmichaud :-) 02:49
(okay, I'm paraphrasing :-)
Casan <Casan> is there a "svn up" equivalent in git?
<mugwump> Casan: git doesn't really do anything that unreliable 02:50
<mugwump> a rough equivalent is 'git pull --rebase'
<mugwump> or perhaps 'git stash save ; git pull ; git stashapply'
either way, I am sure the git crowd would be eager to help.
the above was from the #git channel on #freenode of course. 02:51
02:51 leto joined
Infinoid in my case, it's usually "git fetch; stg rebase origin" 02:51
jimmy Git was not well supported on windows. 02:53
Infinoid "was"?
purl somebody said "was" was "what"
02:53 particle1 joined
jimmy Maybe I should say 'is'? 02:53
Infinoid if you've tried it recently, and it sucks, then I think "is" is appropriate :)
(I have no idea, I was just curious) 02:54
dalek r35575 | cotto++ | trunk/src (3 files):
: [cage] revert r35520,5,6. There's too much hole and not enough dam for this strategy to be effective.
review: www.parrotvm.org/svn/parrot/revision?rev=35575
pmichaud use.perl.org/~pmichaud/journal/38291 02:56
Infinoid the reason noone can give you a straight answer about the equivalent of "svn up" is because data transfer is explicitly separate from local checkout management, and thus it depends on how your stuff is set up (and what third party tools you may be using)
jimmy It is supported now.
Infinoid git was designed with the needs of a project with thousands of contributors and hundreds of patches submitted per day, in mind. so as you might expect, it handles merges and subsystem delegation very well, but it also explains why it's more daunting than the smaller players. 02:57
japhb bak, backlogging ... 02:58
Infinoid I've been pushing for it mostly because of the merging issues we are (still) running into
jimmy msysgit is on windows.
Coke pmichaud: I have commit bits to dev.perl.org/perl6/
I think.
pmichaud (1) Can I get commit bits? 02:59
Coke ask robrt.
pmichaud (2) If no to #1, can I get you to proxy for me? ;-)
Coke (2) definitely.
let me get you the repo url.
pmichaud that would help a lot.
okay, wife wants some of my time for a while. I'll post more later. 03:01
Coke svn.perl.org/perl.org/docs/live/dev/perl6 03:02
I'm happy to apply any patches until/when you get commit bits.
I'll open a ticket with robert.
Casan code.google.com/p/msysgit/ is a good bet for git on windows. I'm testing it now. 03:03
Coke (done)
jimmy Casan: yep
Infinoid ooh, a crash test dummy! 03:04
GeJ Which TPF will manage the distribution of commit bits to Rakudo?
The Parrot one, or the Perl one?
Infinoid if I had to guess, I'd say probably the Perl foundation, but I'm not positive.
Casan: would you be willing to do "git clone git://squawk.glines.org/parrot-trunk" and see if the resulting checkout has UNIX linefeeds or windows ones? 03:05
Coke if it's one or the other, perl.
man, does use.perl.org's footer bar look ugly in safari. :|
Casan Infinoid: sure
Infinoid Coke: it looks ugly in firefox too. stuff sitting on top of other stuff
Coke wish I had IE or chrome. 03:06
(there's something I don't normally say...)
Infinoid tries those
chrome isn't bad.
Casan Infinoid: btw whats the size of the trunk? (I'm sitting on a "borrowed public wireless connection".) 03:07
Infinoid oh. that command will result in a 92MB checkout, because it has full revision history. maybe not a good idea
pmichaud (commit bits) I think I get to manage those.
Casan chrome is nice, fast, but have some minor rendering problems, and plugin/extension system is sorely missed.
pmichaud I'm fairly certain I get to set the initial policy.
that said, I don't plan a radical departure from what we've been doing. 03:08
Casan but it its great and detailed with information about memory usage, wish eg. Padre will have something like this integrated one day.
Infinoid Casan: I have the idea that they do have some plugin systems in place, but the APIs are a lot different from other browsers, so third parties haven't caught up yet
the traditional browser plugin API is a security nightmare 03:09
GeJ pmichaud: So, provided that my CLA doesn't get lost at see and reaches WA, I may be entitled to get a bit for rakudo?
03:10 contingencyplan joined
GeJ s/entitled/allowed/ 03:10
Infinoid Coke: looks horrid in chrome too
GeJ sorry, wrong choice of word.
cotto GeJ, commit bits for Rakudo are the same as for Parrot right now.
Infinoid footer looks completely different (and not as horrid) in IE. 03:11
cotto If you can commit to one, you can commit to the other.
(same as any other HLL that hasn't left the nest)
Infinoid once TParrotF starts managing these things, will I have to send in another CLA, or are existing committers grandfathered in?
GeJ cotto: indeed, but what if I get mine after the camel left the parrot's nest (which is a disturbing image if you think about it) 03:12
jimmy Casan: see also sourceforge.net/projects/gitextensions/ on windows 03:13
cotto GeJ++ #not the Best Imagery Evar, but close
jimmy but I have not try that. 03:14
03:14 purl joined
jimmy but I have not try that. 03:16
s/try/tried/
03:18 Casan_ joined
Casan_ the Git-1.6.1-preview20081227.exe can't execute on my system now downloading the older beta to test 03:19
japhb jimmy: nice! Now I can tell my Tortoise-loving friends to stop hating git for lack of shell extensions. 03:20
03:22 leto joined
jimmy good. 03:25
Casan_ jimmy: you have a setup with git-extensions on windows working 03:27
jimmy the firewall blocked me to download *.exe files. 03:28
japhb pmichaud: re: the use.perl post -- are we at all limited in terms of hosting hardware, admin time, or admin expertise? Is there anything other than "making a decision and making arrangements" that stands in the way of implementing a change to the repo/wiki/issue tracker? 03:29
Infinoid posts his comments to the use.perl post, directly
cotto Can anyone see an easy (even if nasty and hackish) way to instrument the PMC_x_val macros in include/parrot/pobj.h to execute a chunk of code every time they're used? 03:30
by "easy", I mean "only modifies pobj.h"
It's tricky when the macro is used as an lvalue, and rvalue and a function argument. 03:31
Changing the usages of the macros is less appealing because there are >1200 of them. 03:32
Casan jimmy: I could download it, zip it and make it available to you, just let me know which file 03:33
03:34 purl joined
jimmy Casan: thanks, I hadn't used git yet. 03:34
cotto: can you nopaste the 1200 codes? 03:40
cotto any invocations of PMC_x_val (PMC_int 03:41
_val, PMC_pmc_val, etc)
Infinoid cotto: yeah, that's a tough one. I can't think of a way to do it. 03:43
cotto well, if it were easy someone would have done it already 03:44
Infinoid well, hmm 03:45
no, this should be possible 03:46
#define PMC_pmc_val(pmc) (((long*)pmc)[some_inline_function_that_returns_its_parameter((long*)&((pmc)->cache._ptrs._pmc_val)-(long*)pmc)]) 03:48
err, that should probably be
cotto I was thinking some bogus inline trinary operator, but let me parse that...
Infinoid #define PMC_pmc_val(pmc) (((PMC**)pmc)[some_inline_function_that_returns_its_parameter((long*)&((pmc)->cache._ptrs._pmc_val)-(long*)pmc)])
cast pmc to an array of pmc pointers, then calculate the offset of the array, pass that through your inline function, and deref to get the right member. 03:49
it's a single expression, therefore can be an argument, lvalue or rvalue
probably get some warnings from the casting madness though.
cotto actually I was hoping to stick another macro in there (to get file and line info) 03:50
(and a pony)
Infinoid no, you'd need to put __FILE__ and __LINE__ into the PMC_x_val definition directly
putting it in an inline function would just give you the file and line number of the inline function.
though you could certainly pass them to your function as additional arguments
its sickening to look at, but a construct like that should work. 03:52
03:52 purl joined
cotto yes and yes 03:52
Infinoid++
Infinoid (oh, and don't expect inline functions to be portable at all, they are not C89)
03:53 tetragon joined
cotto I don't care about portability. This isn't anything that'll see the svn repo. 03:53
Infinoid perfect.
03:53 purl joined
Infinoid oh, the array offset calculation will need to be divided by sizeof(long) too 03:54
(C wouldn't be any fun without pointer arithmetic getting in the way)
kid51 purl, are you having problems staying awake tonight?
purl bugger all, i dunno, kid51
kid51 must sleep 03:55
purl $kid51->sleep(8 * 3600);
03:57 rurban_ joined
dalek r35576 | allison++ | trunk/src/pmc: 04:00
: [cage] Change the parsing of FixedIntegerArray initialization strings from
: poking directly into the guts of a STRING to use a temporary C string.
: Partially resolves RT #47011.
review: www.parrotvm.org/svn/parrot/revision?rev=35576
Infinoid cotto: I am amazed, that construct worked more or less as-is, for me 04:04
nopaste "Infinoid" at 75.28.74.141 pasted "A glorious hack." (40 lines) at nopaste.snit.ch/15313 04:05
Infinoid and I was wrong about dividing by sizeof(long). 04:06
cotto I'm testing Parrot with PMC_pmc_val instrumented. It's compiling so far (and silently, once I added a prototype for the function). 04:09
Infinoid no warnings? that's ... astonishing. 04:10
cotto forgot to inline... 04:11
If this works, I'm going to have to throw you a parade or something. 04:13
it built
Infinoid hah. so I'm curious, what are you testing for?
cotto I need to know what kind of PMC is used for each invocation of the PMC_x_val macros. 04:14
Infinoid that's gonna generate a lot of output
cotto yes
Coke that looks insanely evil. 04:16
Infinoid++
cotto++
sleep-- 04:17
karma sleep?
purl sleep has karma of 106
Infinoid cotto++
cotto Infinoid++
karma for everyone!
purl everyone! has neutral karma
cotto except purl
Infinoid it's an interesting set of constraints. would make a good subject for a game of golf
Casan Infinoid: I downloaded Git-1.6.1-preview20081227.exe again, and it installed fine and is now running a clone on the trunk requested 04:18
Infinoid then again... maybe not. you could replace all the "(long*)&((pmc)->cache._ptrs._pmc_val)-(long*)pmc" junk with "3" or whatever it is
cotto make test passes with one instrumented macro 04:20
amazing
Infinoid \\o/ 04:21
cotto or not. I think I had the macro disabled. 04:23
cotto--
definitely enabled now, trying again... 04:24
Coke_z tcl: for {set a 1} {$a < 7/2} {incr a} {puts cotto--} 04:26
polyglotbot OUTPUT[cotto--ā¤cotto--ā¤]
Coke_z tcl: for {set a 1} {$a < sqrt(10)} {incr a} {puts cotto++}}
polyglotbot OUTPUT[extra characters after close-braceā¤]
Coke_z tcl: for {set a 1} {$a < sqrt(10)} {incr a} {puts cotto++}
polyglotbot OUTPUT[cotto++ā¤cotto++ā¤cotto++ā¤]
cotto I'm tcl'd
Infinoid polyglotbot++ 04:27
jimmy does c89 support inline function? 04:37
TonyC no
Infinoid msvc barfs on them 04:40
and I'm not really sure how the INLINE macro is supposed to help 04:45
cotto btw, it's also used as an array index. I think I can work around that. 04:51
and math 04:52
Infinoid it evaluates to a self-contained expression... I don't know that any of those will be a problem 04:58
Casan time to zzzz.. looking into more git win tomorrow 05:05
Infinoid no problem. thanks for trying it out, Casan
sleep well
05:05 masak joined
GeJ hej masak 05:08
masak hola GeJ
I guess it's nearing noon for you. 05:09
GeJ I'm well advanced in the afternoon actually. 4 PM 05:11
masak oh -- of course. it's 6 in the morning here. 05:12
Infinoid and 9pm here
masak globe++
Infinoid earth: we have you surrounded, come out with your hands up
05:15 particle joined
PerlJam Where are you at? I'm at 11pm. 05:18
I wonder if temporal location will catch on :) 05:19
05:21 leto joined
Casan Infinoid: didn't back down quite, the trunk is browsable now on the windows machine, have a shell like environment so its decent. there are also some gui tools, but I haven't tested them much yet. as for the line carriage return test... can you explain more precisely what to look for? I've opened a few files in notepad and none of them show sign of platform difference when it comes to new lines. 05:22
05:24 MariachiElf joined, tetragon joined
Infinoid Casan: great, opening text files in notepad is all you should need 05:25
so that means it Does The Right Thing, that's all I wanted to know
thanks! Casan++
Casan a test with commits though would prove it is doing the right thing the other way. and the windows git seems ok actually with the updates from later dec08. but still before doing anything some serious testing and matching with peoples needs etc should be performed. but at least now we have some basic information and a knowledge base can begin to be created. 05:27
as for git, svn, etc, I am not an advocat for either, I just want to know what we are doing and we do it the best we can.
which includes not disgruntling the existing user base with a premature migration 05:30
jimmy git++ 05:32
05:34 leto joined 05:42 Tene joined
GeJ is jrieks still active? 05:49
last commit seems to be 2005.6.13 05:51
Infinoid not as far as I know 05:52
cotto you can assume no if he hasn't committed in the past 12 months 05:53
GeJ enjoys his local trac setup... easy when doing archeology like this.
cotto Infinoid, the only problem was that I forgot the change the types that the macros cast to. With that, everything looks peachy. 05:55
GeJ I'm having evil thoughts about making Data::Dumper return strings instead of printing directly... 05:56
Infinoid cotto: awesome. are you using gcc on linux/x86?
cotto yes 05:57
about to commit...
j/k
Infinoid ok. I actually think this stuff should be fairly portable, except for the inline function of course. only platform I'm not sure of is LLP64 (e.g. win64). to handle that case, "long" should probably be switched for "INTVAL" or whatever the "guaranteed to be the same size as a pointer" type is 05:59
anyway, gcc rules for handling all the weird junk we throw at it all the time
goodnight
cotto night 06:06
06:10 leto joined
masak 240 Rakudo tickets! 06:30
06:33 MariachiElf left 06:35 MariachiElf joined 06:42 leto joined 06:47 HG` joined 06:53 cognominal joined 06:58 namenlos joined 07:04 alvar joined 07:25 particle1 joined
cotto seen whiteknight 07:29
purl whiteknight was last seen on #parrot 8 hours, 3 minutes and 22 seconds ago, saying: thanks barney, I posted a note there
dalek r35577 | rurban++ | branches: 07:56
: 5 patches partially merged: RT#57548, RT#57006, RT#56998, RT#51944, TT#94
: the rest not. See lists.parrot.org/pipermail/parrot-d...00847.html
: and trac.parrot.org/parrot/wiki/Pdd30I...llTasklist
: Ongoing work in branches/pdd30install_stage4
shorten dalek's url is at xrl.us/beck5m
dalek review: www.parrotvm.org/svn/parrot/revision?rev=35577
07:58 iblechbot joined 08:02 mberends joined 08:06 cognominal joined
cotto anyone here familiar with Parrot's gc? 08:20
08:24 hudnix joined 08:37 alvar joined
jimmy nopaste? 08:46
purl i guess nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "jimmy" at 220.231.152.66 pasted "add '=cut'" (62 lines) at nopaste.snit.ch/15315
09:01 barney joined
cotto jimmy, you can also use tools/dev/nopaste.pl 09:06
jimmy I had created a TT 09:07
09:09 leto joined 09:35 donaldh joined
donaldh irc://irc.cisco.com/ 09:35
09:46 particle joined
dalek r35578 | fperrad++ | trunk (3 files): 09:47
: [harness]
: - restore --html option
review: www.parrotvm.org/svn/parrot/revision?rev=35578
r35579 | bernhard++ | trunk/src: 09:50
: [codingstd] t/codingstd/c_indent.t
review: www.parrotvm.org/svn/parrot/revision?rev=35579
r35580 | bernhard++ | trunk/src/gc: 09:52
: [codingstd] t/codingstd/c_parens.t
review: www.parrotvm.org/svn/parrot/revision?rev=35580
10:06 kj joined 10:24 bacek joined 10:54 alvar joined 11:01 braceta joined
dalek r35581 | bernhard++ | trunk/t/codingstd: 11:15
: [t] Some beautifications.
: More info for misplaced macro invocations.
: Pull expensive join outside the loop.
review: www.parrotvm.org/svn/parrot/revision?rev=35581
r35582 | simon++ | branches/strings/pseudocode (2 files): 11:25
: Another function or two done, plus the start of UTF8 support.
review: www.parrotvm.org/svn/parrot/revision?rev=35582
11:26 clunker3 joined, bacek joined
cotto it's interesting to turn Parrot's test suite into an IO-bound task 11:30
dalek r35583 | bernhard++ | trunk/src: 11:34
: [codingstd] Add a missing ASSERT_ARGS()
review: www.parrotvm.org/svn/parrot/revision?rev=35583
11:57 rurban_ joined 12:00 Casan joined 12:06 particle1 joined 12:12 pancake joined
pancake i can has a segfault for rakudo 12:12
jonathan congrats! 12:13
pancake :P
jonathan we can haz a bug report?
pancake indeed!
im just trying to reproduce it with the minimum number of chars
jonathan Were you using the perl6 executable, or the PBC?
pancake the perl6 executable
with 0.8.2 12:14
somebody can try with svn maybe its fixed there..
jonathan pancake: Also interesting - if you cd languages/perl6 and ../../parrot perl6.pbc the_thing_that_segvd.p6 12:15
Does it segfault there? 12:16
pancake uhm . nope :S
*** glibc detected *** ./perl6: corrupted double-linked list: 0x085fdb28 ***
invoke() not implemented in class 'ResizablePMCArray' 12:17
jonathan pancake: The bug that triggers this is worth reporting, because Rakudo should never die that way.
*But* there is a known issue involving shutdown memory freeing in the executable that doesn't cause things to blow up in the PBC version. 12:18
So the segfault, rather than just getting an error, is related to that.
pancake shorttext.com/inyhgsk
jonathan But the error shows something is wrong too.
pancake i know that this is not valid p6 code, i was just trying to get an error from the parser O:) 12:19
jonathan pancake: Yes, it still explodes on HEAD too. Bug report most welcome. :-) 12:21
rakudobug?
purl i guess rakudobug is mailto:rakudobug@perl.org
jonathan To there.
pancake no special format expected? subject+body and that is?
jonathan No, nothing special.
pancake cool. thanks 12:22
jonathan Just include the stuff on the page you just linked me to.
pancake uhm..the bug cannot be reproduced if i define the array and the hash in the same line 12:24
12:24 ruoso joined
pancake my @a,%b; <- does not crash, my @a;my %b; <- crashes 12:24
jonathan pancake: I don't see that issue in head. 12:25
pancake let me prepare a oneliner 12:26
my @a; my %b; @a[0].""~%b{0};
that is 12:27
lathos % ./perl6 -e 'my @a; my %b; @a[0].""~%b{0};' 12:29
too few arguments passed (1) - 2 params expected
dalek r35584 | bernhard++ | trunk (3 files): 12:30
: [codingstd] svn props and MANIFEST for new files
jonathan I get that here too
dalek review: www.parrotvm.org/svn/parrot/revision?rev=35584
jonathan It's the wrong error.
pancake dalek: jonathan : svn?
jonathan pancake: yes
pancake jonathan: long example crashes for you?
lathos I get this at the end: perl6(1245) malloc: *** error for object 0x3167870: double free 12:31
But then I *always* get a segfault after an error.
dalek r35585 | bernhard++ | trunk (2 files):
: [perl] Some beautifications and POD updates
review: www.parrotvm.org/svn/parrot/revision?rev=35585
lathos If all that effort ensuring coding standards went into implementing new code, we'd have Parrot done by now. 12:32
jonathan pancake: Yes. 12:35
moritz lathos: ... but maybe with such unreadable code that nobody wants to touch it anymore 12:36
lathos Who knows. 12:37
dalek r35586 | jonathan++ | trunk/languages/perl6/src (2 files):
: [rakudo] Get parametric roles working with mixins via the does operator.
review: www.parrotvm.org/svn/parrot/revision?rev=35586
jonathan lathos: The people putting the effort into coding standards maybe aren't the same people who know how to do the guts. :-) 12:38
lathos Yep, I guess it gives that kind of people something useful to be doing.
jonathan I know that the sum of my effort on coding standards has been committing stuf that fails the coding standards tests and trolling about them on #parrot, for example. ;-) 12:39
lathos The magic code pixies approach does work awfully well, I admit.
jonathan People always come and clear up after me when I do such things. :-) 12:40
12:40 namenlos joined 12:42 tetragon joined
dalek r35587 | simon++ | branches/strings/pseudocode (3 files): 12:48
: Split things into separate files.
review: www.parrotvm.org/svn/parrot/revision?rev=35587
barney jonathan-- 12:54
12:57 riffraff joined
dalek r35588 | bernhard++ | trunk (3 files): 13:00
: [tools] Add script tools/dev/mk_gitignore.pl.
: Add support for mk_gitignore.pl to Parrot::Manifest.
review: www.parrotvm.org/svn/parrot/revision?rev=35588
pmichaud lathos: (re parrot-dev post) do you expect the string handling interface itself to change, or just the internals? 13:01
i.e., are you envisioning that the opcodes or their arguments will change? 13:02
lathos I don't know what the dividing line between the internals and the externals is. 13:03
13:03 alvar joined
lathos However I'm fairly sure that not just internal manipulation but also users of STRINGS will need to change a lot of their code. Witness the trouble with PIRC and C strings right now. 13:03
pmichaud okay, so you're referring primarily to the C-level interfaces? 13:06
lathos I think so, yes.
pmichaud okay.
that makes sense to me.
I can respond on-list, but here's my (one person's) assessment of how it relates to 1.0 13:08
dalek r35589 | bernhard++ | (2 files):
: Ignore all *.o files in the parrot root.
review: www.parrotvm.org/svn/parrot/revision?rev=35589
pmichaud I don't suspect that many languages are (yet) manipulating strings at the C level. Libraries may indeed be doing that, but language translators as a whole are not. (more)
Parrot would probably be willing to live with the current (broken) strings implementation for 1.0, and our target for a new one would be 1.5 (July 2009). We would expect language implementors to adapt to whatever the new API is at that point. 13:10
again, that's just one viewpoint, not in any way "official".
I totally agree with you that we've stored up a lot of issues in the STRINGS implementation 13:11
lathos But this has big implications for language implementors right now. Rakudo's strings are going to need upheaval because every string in Parrot is going to need to declare its encoding and charset. 13:12
Otherwise it ends up with the default UTF-7 EBCDIC.
pmichaud Rakudo acts as if that's the case already, I think.
with one exception 13:13
the code that is in Perl6Str doesn't do that. But I'm comfortable that we could quickly adapt that code to a new API.
lathos OK.
pmichaud the only reason that perl6str.pmc pokes around in the guts of STRINGs is because that's how some of the other Parrot implementations do it (and the API isn't clear). But I don't expect that fixing that will be a huge burden once Parrot's API is in place. 13:14
riffraff is there a "warn" opcode ?
pmichaud if worse came to worse, we _could_ reimplement that logic in PIR.
riffraff: I'm not aware of one.
riffraff point is, I've been bitten twice already by a spurious ' ' after an action key and I thought it would be nice to raise a warning if that happens 13:15
or maybe we should just drop \\s after an action key ? I can submit a patch if that makes sense 13:16
pmichaud riffraff: I've thought about doing that in the past, but for some reason had decided against it 13:17
if you're being bitten by it, though, then yes, we can probably do that. 13:18
riffraff well maybe here are cases where yo want that, that's why I thought of a warning
pmichaud feel free to submit a trac ticket for it, or if you want to work on a patch that'd be great also. I think the relevant code is in compilers/pge/PGE/Perl6Regex.pir
riffraff yes, found it
pmichaud (I'd do a patch but I'm not sure when my schedule will let me get to it.) 13:19
riffraff ok, I'll see what I can do, thanks 13:27
13:31 Whiteknight joined
dalek r35590 | bernhard++ | trunk/lib/Parrot: 13:32
: [tools] Add leading slash, in order to avoid shell globs with ignored directory part.
review: www.parrotvm.org/svn/parrot/revision?rev=35590
Casan humm, life on mars they say.. would mars.pm.org be a little too optimistic? :) 13:35
moritz Casan: TCP isn't well suited for communicating with Mars
Casan there must an implementation of an inter-planetary protocol somewhere on cpan. 13:36
moritz TCP over avian carriers? :-) 13:37
bacek rakudo: say "000" ?? 1 !! 0 13:42
polyglotbot OUTPUT[1ā¤]
bacek rakudo: say "0" ?? 1 !! 0
polyglotbot OUTPUT[0ā¤]
lathos Same as Perl 5 then.
moritz rakudo: say "00" ?? 1 !! 0 13:43
polyglotbot OUTPUT[1ā¤]
13:56 estrabd joined
dalek r35591 | bernhard++ | trunk/languages/pipp/docs: 14:00
: [Pipp] Mention plan to implement constanst as package vars.
review: www.parrotvm.org/svn/parrot/revision?rev=35591
Coke_Zzzzzz IWBNI someone wrote up a page about how to report bugs on perl6 vs. parrot to help avoiding sending bugs that need to be diagnosed in perl6 first to parrot's mailing list instead of neither ticketing system. 14:13
was there any discussion about bringing back the --html option for languages test? 14:14
(smoke is dead.)
14:14 AndyA joined
pmichaud Coke_Zzzzzz: thus my request to get rid of the perl6-internals mailing list and have a responder message. 14:15
Coke_Zzzzzz: also to disable the parrotbug@perl.org mailing list.
14:15 iblechbot joined
pmichaud sorry, auto-forwarder. 14:15
(parrotbug@perl.org could also use the message I suggested.) 14:16
14:27 particle joined
dalek r35592 | pmichaud++ | trunk/languages/perl6/docs: 14:37
: [rakudo]: spectest-progress.csv update: 284 files, 6254 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=35592
15:08 AndyA joined
Whiteknight question: should src/pmc/object.pmc:invoke() be marked with "VTABLE"? 15:17
15:18 gryphon joined
Whiteknight I mean, it is a vtable method, so it should have the VTABLE keyword? 15:18
15:28 Casan joined
nopaste "barney" at 84.154.3.25 pasted "*Main namespace" (18 lines) at nopaste.snit.ch/15316 15:30
15:31 iblechbot joined
barney quick Perl 6 question: How would I access $FOO in the main namespace ? 15:31
jonathan $*FOO 15:32
Erm
No
PerlJam barney: $OUTER::FOO might work.
jonathan $::Main::Foo
moritz rakudo: our $x = 5; module Foo { say $x }; 15:33
polyglotbot OUTPUT[Null PMC access in isa()ā¤current instr.: 'parrot;List;!flatten' pc 5130 (src/classes/List.pir:287)ā¤called from Sub 'print' pc 18744 (src/builtins/io.pir:18)ā¤called from Sub 'say' pc 18781 (src/builtins/io.pir:35)ā¤called from Sub 'parrot;Foo;_block22' pc 126 (EVAL_19:58)ā¤called from Sub
..'parrot;PCT;HLLCompiler;evalpmc' pc 888 (src/PCT/HLLC...
moritz masak: want to file a bug report? :-)
jonathan Oh, that one.
moritz rakudo: our $x = 5; module Foo { say $Main::x };
polyglotbot OUTPUT[Use of uninitialized valueā¤ā¤]
moritz rakudo: our $x = 5; module Foo { say $Main::y }; 15:34
polyglotbot OUTPUT[Use of uninitialized valueā¤ā¤]
jonathan our $x = 5; module Foo { say $*x }
rakudo: our $x = 5; module Foo { say $*x }
polyglotbot OUTPUT[Use of uninitialized valueā¤ā¤]
moritz Main variables aren't global
jonathan rakudo: say 1; module Foo { say 2 }
polyglotbot OUTPUT[2ā¤1ā¤]
jonathan Hmm. :-) 15:35
moritz: Aye, just wanted to check what it did.
15:37 mberends joined
PerlJam Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers 15:38
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
Segmentation fault
purl (Core dumped)
PerlJam bummer
make: *** [runtime/parrot/include/config.fpmc] Error 139
15:38 Lorn joined
jonathan make fail 15:38
PerlJam: You doing stuff in Parrot guts? Or is that right from svn? 15:39
PerlJam jonathan: that's "make realclean; perl Configure.pl && make" with no local mods at all 15:40
jonathan Oh. Ouch. :-( 15:41
Platform?
moritz PerlJam: new compiler? 15:42
Coke_Zzzzzz (warn) poor man's: 'printerr'
coke pmichaud: you have commit bits to the dev.perl6 repo now, I think.
robrt asks that I make sure you have a combust setup. 15:43
PerlJam does a completely fresh checkout to avoid and weirdness cause by the continual updating in his existing wc and tries again
coke (typically, test all changes locally in teh combust framework before commiting)
PerlJam wow, a fresh checkout sure takes a long time. I'm glad I don't have to do it all the time. 15:45
15:45 kj joined
PerlJam moritz: nope, just an ordinary ubuntu 8.10 installation. 15:47
pmichaud Coke: I don't have a combust setup. What do I do to get one?
PerlJam and the fresh checkout did exactly the same thing.
barney rakudo: say()
polyglotbot OUTPUT[say requires an argument at line 1, near ""ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤called from Sub 'parrot;Perl6;Grammar;Actions;_block4478' pc 144545 (src/gen_actions.pir:13505)ā¤called from Sub 'parrot;Perl6;Grammar;Actions;_block4459' pc
..144482 (src/gen_actions.pir:13479)ā¤called from Sub '...
Whiteknight PerlJam, what revision are you at? 15:48
PerlJam 35592
Whiteknight I was doing some monkeying with the GC mark routines on Ubuntu 8.10-64 last night, but I didn't see any problems with that 15:49
I don't know if there have been any other changes since then that would cause miniparrot to segfault 15:50
pmichaud tries a fresh checkout. 15:51
mberends the most recent running rakudobot is r35589, so r35590 may be the problem
jonathan did an svn up and clean build today and had no issues on Win32
Whiteknight r35590 looks like it was only a change to lib/* stuff, which shouldn't cause this kind of segfault 15:52
PerlJam mberends: nah, the commits after 35589 don't look like they affect miniparrot at all.
Whiteknight PerlJam, you think you could nopaste a backtrace? 15:53
15:53 galf joined
mberends true, making r35589 also segfaults here in Linux 15:53
PerlJam Whiteknight: if you tell me how to do it, sure :) 15:54
Whiteknight PerlJam, in the parrot repo, you should be able to type "gdb miniparrot" to start the debugger 15:55
barney r35592 looks fine here, on Kubuntu 8.10 15:56
mberends rakudo: say %*VM<config><revision> # presumably built OK
polyglotbot OUTPUT[35592ā¤]
Whiteknight yeah, 35592 just build fine for me on WinXP32 15:57
PerlJam puts git bisect to use for real for the first time. 15:59
Whiteknight: okay, what do you want me to show you from the debugger exactly? (/me never uses gdb) 16:01
mberends PerlJam: for bisect, r35568 was good yesterday afternoon.
pmichaud r35592 builds fine for me.
PerlJam: are you 64-bit ubuntu? 16:02
PerlJam pm: yep
pmichaud pj: ah. That's an important detail. :-)
(I'm 32-bit kubuntu 8.04, fwiw) 16:03
moritz r35592 builds fine on 32 bit debian
coke pmichaud: start here: combust.develooper.com/
pmichaud coke: will do, a bit later ($otherjob call now) 16:04
Whiteknight urg, my 64 bit ubuntu computer is at home!
Infinoid tries it on 64 bit gentoo 16:05
coke combust?
purl combust is probably the web framework / content management system for geeks that we use at perl.org. See combust.develooper.com
coke aha. =-)
Infinoid PerlJam: do you have a backtrace? (did you already paste one and I missed it?) 16:08
trunk@35592 builds fine here on gentoo/amd64 16:09
PerlJam er, no I got sidetracked playing with git bisect. 16:11
Infinoid passes all tests, too 16:12
PerlJam so ... how do I generate a backtrace from gdb? 16:13
(again, I never use it)
moritz gdb ../path/to/parrot
run path/to/file
# wait
bt
dalek r35593 | infinoid++ | trunk/languages/perl6/src/classes: 16:14
: [codingstd] Fix a trailing_space.t failure in rakudo.
review: www.parrotvm.org/svn/parrot/revision?rev=35593
Infinoid or you can generate one after the fact, if you have a core file.
16:15 Tene joined
nopaste "PerlJam" at 165.95.12.42 pasted "miniparrot backtrace" (17 lines) at nopaste.snit.ch/15317 16:15
Infinoid uh. that sure looks like a bug 16:16
are you still in gdb?
16:17 Theory joined
PerlJam yes 16:17
Infinoid great, try these 16:18
print scheduler->vtable
16:18 cognominal joined
Infinoid if that doesn't return NULL or something like 0xdeadbeef, try: 16:18
print scheduler->vtable->share_ro
PerlJam $1 = (VTABLE *) 0xdeadbeef
Infinoid that's ticket-worthy :) 16:19
its a PMC that was just created, yet has a bogus vtable-pointer array 16:20
so your pmc_new() is broken. 16:21
the results of your bisect will shed more light 16:22
16:22 ask_ joined
lathos What's the opposite of "~~" ? "!~~" ? 16:25
pmichaud lathos: yes.
lathos Thanks. I tried it and it seemed to work but I wasn't sure what it was doing. :) 16:26
pmichaud it's supposed to work. I'm not sure exactly what it's doing either. :)
jonathan It's the double-hand-waving operator. 16:27
pmichaud it's the "I'm not hand-waving -- Look over there!" operator. :) 16:28
16:28 clunker3 joined
pmichaud jonathan: you have veto power over using git for rakudo, fwiw. 16:28
i.e., "I don't want to use git" ==> we don't use git. 16:29
jonathan pmichaud: I'm pondering that.
PerlJam starts taking collections from githeads to bribe jonathan just in case ;) 16:30
jonathan If I'm going to veto it for technical reasons, I need to actually have tried it to know if they exist. ;-)
Since people are posting about how gits messianich properties carry onto Win32 as well though, it seems that may not be an issue.
The only one that does bother me a little more is the "you use svn to get the spectests and Parrot, and git to get Rakudo" 16:31
pmichaud that bothers me a lot.
PerlJam me too fwiw
jonathan However
I would be a lot less bothered if there were a (readonly is just fine) svn mirror.
That way only *committers* need to care. 16:32
(About git.)
And we keep the barrier to entry to just one version control system.
I don't know how technically feasiable an svn readonly mirror is.
pmichaud it's within the realm of possibility that spectest could move to git.
(not rakudo's git repo, but a git repo) 16:33
we'd still want liberal committer access, but that can be arranged.
moritz pmichaud: currently it's too much entagled with pugs tests
PerlJam maybe that's where a svn<->git gateway would be useful.
coke you could have a git-svn in front of pugs.
Infinoid blog.fallingsnow.net/2007/08/17/mai...-from-git/
shorten Infinoid's url is at xrl.us/becm3z
pmichaud it's too entangled with pugs tests? 16:34
can't pugs use an approach similar to what rakudo does now for the spectests?
PerlJam according to the bisect, r35568 is the first bad rev for my miniparrot segfault
pmichaud anyway, I'm not going to impose a change on pugs (or the spectests), I'm just saying it's a possibility. But lots of people have veto say over that.
moritz pmichaud: there are a lot of tests outside of t/spec/ that might or might not be moved to t/spec... 16:35
jonathan ah crap, hateful enums bite again
Infinoid Whiteknight:
pmichaud moritz: we could move them into t/spec/unclassified, perhaps?
moritz pmichaud: if we move just t/spec/, we have lost revision history - if not, we stole pugs the tests
coke PerlJam: those change marking; possible something is now not correctly marked, and therefore is collected. 16:36
moritz pmichaud: we could think about it
Whiteknight 'ello poppet
pmichaud moritz: we can keep revision history if moving to git
moritz pmichaud: yes, but not if we move a part, and then later move individual files from svn to git 16:37
pmichaud moritz: it's simply a proposal/thought on this end, I'm not really wanting to push against any resistance. If you think it makes thing unnecessarily complicated outside of rakudo, that's sufficient for me.
Infinoid Whiteknight: yo. any idea why r35568 could break pmc_new()?
Whiteknight Infinoid, what happened in r35568?
moritz pmichaud: I have to think a bit more about it. Proposal noted.
Whiteknight is building right now 16:38
Infinoid Whiteknight: [08:34] <@PerlJam> according to the bisect, r35568 is the first bad rev for my miniparrot segfault
the code in question calls pmc_new() to create a Scheduler PMC, and then tries to call a vtable function, yet the vtable array pointer is 0xdeadbeef.
I don't know what's going on here well enough, was hoping you might :) 16:39
PerlJam moritz: if there were a hook in the svn repo to push changes to the git repo and a hook in the git repo to push changes to the svn repo ...
Whiteknight well, that's not a good sign. I am on the same exact system as PerlJam (Ubunu 8.10-64) and didn't see any problems with it
although it is a GC change, so maybe something is now getting prematurely recycled for some reason
Infinoid well, miniparrot does appear to accept the -G flag. 16:40
Whiteknight let me look into it
Infinoid PerlJam: what happens if you add that to the miniparrot command line?
thanks
moritz PerlJam: yesterday you convinced me that a bidirectional mirror might not be a good idea :-) 16:41
Infinoid The "tailor" tool can set up readonly mirrors in either direction. Is that sufficient? 16:42
PerlJam moritz: Yeah, I waffle on it. It pits desire and usefulness against disruption for me.
Infinoid: what does -G do? (no change, btw. I still get a segfault) 16:43
Whiteknight -G turns off the GC
Infinoid it turns off the GC
Whiteknight and you're still getting a segfault without that? then it can't be a case of premature recycling
Infinoid yeah, so 0xdeadbeef came from somewhere else
Whiteknight there are only afew places in the core where that number is used 16:45
Infinoid could it be a properly recycled pmc that was reallocated but didn't get initialized properly?
Whiteknight it's just a regular run-of-the-mill Scheduler PMC, not some fancy overriden type? 16:46
Infinoid newp, crash occurred at src/scheduler.c:83
scheduler->vtable is 0xdeadbeef 16:47
16:47 clunker3 joined, particle1 joined
Infinoid makes me wonder if interp->vtables[] has been corrupted 16:47
coke if you see the deadbeaf, set a condition breakpoint in pmc_new for that memory address, rerun, and see what init'd it. 16:48
Infinoid pmc_new was src/scheduler.c:82, the line above the crash.
Whiteknight if it's the scheduler pmc, it's a singleton. There's only one place it should be getting init'd
Infinoid ok 16:49
might be worth breakpointing on get_new_pmc_header and taking a look at interp->vtables[] 16:50
Whiteknight the change in r35568 affected fixedpmcarray PMCs, and the interp->vtables[] array is not one of those 16:51
Infinoid interp->vtables[] is where the vtable pointers for new pmcs come from. 16:52
Whiteknight right, but that doesn't explain how the changes in r35568 would have broken that 16:53
Infinoid yeah, I don't know either
dalek r35594 | jkeenan++ | trunk (2 files): 16:56
: Applying patch submitted by jimmy in TT#175. POD corrections in two files.
review: www.parrotvm.org/svn/parrot/revision?rev=35594
Whiteknight okay, so the segfault happens at src\\scheduler.c:82? 16:58
er, :83? 16:59
Infinoid yeah 17:00
nopaste.snit.ch/15317
Whiteknight wow, quite the backtrace 17:01
Infinoid I don't think the code had much of an opportunity to do fancy stuff...
Whiteknight okay, I've got a small commit coming through nowish. When it hits could you update and try again PerlJam? 17:14
dalek r35595 | Whiteknight++ | trunk/src/gc:
: [GC] try to fix an issue reported by PerlJam++ where a scheduler PMC's vtable is 0xdeadbeef after r35568, even with -G.
review: www.parrotvm.org/svn/parrot/revision?rev=35595
coke if you break at src/scheduler.c:82, does the pmc that is returned seem in order? 17:15
coke catches up. nevermind. 17:16
Whiteknight I don't have a debugger or anything here. But it doesn't matter since the problem doesn't manifest on this box 17:17
Whiteknight grumbles angrily about the stupid GC 17:18
dalek r35596 | jonathan++ | trunk/languages/perl6/src/builtins: 17:24
: [rakudo] Rip out a chunk of duplicated code from a routine, calling the new (and correct) version instead. Also, make !keyword_has now just forward to !meta_attribute, in preparation for removing it proper.
review: www.parrotvm.org/svn/parrot/revision?rev=35596
r35597 | jonathan++ | trunk/languages/perl6/src/builtins: 17:26
: [rakudo] Various (some rather subtle) changes to infix:<does> and infix:<but>, to bring them up to date, fix various bugs and ensure they work in the parametric case too.
review: www.parrotvm.org/svn/parrot/revision?rev=35597
pmichaud jonathan++ # I like the way those commit messages read. :-)
jonathan A small patch...from a lot of effort. :-|
pmichaud: Roles generally - even in the none-parametric case - have improved somewhat thanks to the work to get them up to scratch in the parametric case. 17:27
pmichaud jonathan: excellent. I actually think that's the way it should be. :-) 17:28
I suspect we'll see similar things for enums :-)
jonathan I layered a bunch of hacks onto enums yesterday, relying on the fact one of us will be giving them a re-write soonish. 17:29
(Hacks on them rather than hacks elsewhere to work around them.)
How's plans for Cursor looking? I'm suspecting it won't be in for the January release?
17:29 davidfetter joined 17:33 tomyan left
Whiteknight PerlJam, Infinoid, anybody have any updates? 17:38
szabgab I tried my $input = $*IN.readline; and it segfaulted in Rakudo, how can I read from STDIN? 17:40
coke szabgab: you sent that bug report to parrot-dev, neh? that should go to: 17:42
rakudoperl?
rakudobu?
rakudobug?
purl rakudobug is mailto:rakudobug@perl.org
coke (where it is now, it's not even in parrot's ticket queue.) Thanks.
szabgab coke: the segfault is one issue, but how do I read from STDIN? 17:43
and now I am confused, have you forwarded it already or shall I send it myself?
coke I have not. 17:44
If you could, that would be helpful. then the rakudo folks can figure out if it's their issue or parrots and forward it on accordingly.
dalek r35598 | jonathan++ | trunk/languages/perl6/t: 17:45
: [rakudo] Add parameterized-mixin.t, which is currently heavily fudged (that should change tomorrow) but tests todays additions.
review: www.parrotvm.org/svn/parrot/revision?rev=35598
szabgab actuall I just upgraded parrot and now it works
coke there you go. =-)
szabgab so it might have been on my end, in the first place
but should not readline() alone work? 17:46
coke I don't know perl6, Iunno. 17:47
your code seemed reasonable, and segfaults are always bad, of course.
moritz szabgab: no
szabgab: =$*IN to read from STDIN
szabgab moritz: thanks 17:51
17:53 alvar joined
dalek r35599 | Whiteknight++ | trunk/src/pmc: 18:11
: [PMC] Change Object PMC so that morph vtable interfaces can be overridden (with acceptable results) from PIR
review: www.parrotvm.org/svn/parrot/revision?rev=35599
Whiteknight where in the test suite do we test vtable overrides? 18:12
or, do we not test them anywhere?
cognominal pmichaud , reading your stuff on Parrot planet... I think aggregation should filter in on words. I could not care less of chromatic persecution delirium thru the perl 5 proxy. 18:17
coke ? 18:19
ah. rather than having planet parrot aggregate blogs, you want it to aggregate posts?
I don't think we can do that. 18:20
moritz somehow I don't think we're facing a technical problem right now. 18:23
18:27 jhorwitz joined 18:28 braceta left, purl joined
Whiteknight if anybody has a moment, I could use some input on RT#41825 18:35
kj check your email ;-) 18:36
Whiteknight w00t
kj but I'm just standing on the sideline in these issues, so not much worth.
coke Whiteknight: we removed those from PIR deliberately.
very painfully and at some cost to my sanity. 18:37
Whiteknight that's what I figured, but that makes the morph vtable overrides a little more tricky to deal with then it would be otherwise
kj I think at some point, it was mentioned somewhere, the ids will be removed altogether (post 1.0) 18:38
coke we've just removed all user facing variants.
(except morph apparently.)
doesn't the morph opcode already do that lookup before it hits the vtable?
yah. 18:39
so from C, this is still doable, and probably will be through 1.0
since the vtable /is/ visible from PIR, however, I recommend doing #2.
(update the vtable to take a string>) 18:40
Whiteknight yeah, the morph opcode takes a string. The morph vtable takes an intval
okay, I'll see if I can do that
PerlJam Weren't the stringy names being dropped in favor of keys too?
coke PerlJam: ayup. included that in my reply. 18:43
Whiteknight: if you're changing the vtable, that has to get a DEPRECATED notice. 18:44
Whiteknight well, I'm not changing the vtable, I'm only changing the way the vtable is overriden from PIR
coke No, I'm saying we should change the vtable. 18:45
Whiteknight so in C it's still "VTABLE morph(INTVAL type)"
coke Having the override take a different type is not a good idea, IMO.
coke responded to your email, btw.
Whiteknight urg, there are a lot of morph calls throughout parrot. All of them are going to need updatin' 18:47
kj if you add the new variant, it'll be easier without breaking anything 18:48
and then after updating everything, remove the old one
Whiteknight So like create a new morph_from_string? 18:50
kj eh, I was thinking ops. I guess using the same name, 'morph' is not possible for vtable methods 18:51
mmm
coke yah, I don't think that's possible. 18:52
VTABLE_morph ... == ?
just put in a notice and do it post 0.9.0 18:53
kj maybe could be done in a branch?
a short-lived one
18:55 riffraff joined 19:02 particle joined
particle pmichaud: ping 19:02
Whiteknight that's probably what I will do. Do I need like Allison's permission to make a change like that? 19:06
particle wonders what he missed. irc log? 19:07
feh.
19:07 particle2 joined
particle Whiteknight: we need a new morph. create a branch and start working on it before approval 19:08
use the successfully working branch to plead your case :)
just don't merge it until approval (unlike the stm branch you snuck into trunk) 19:09
Whiteknight roger wilco, over and out
I asked Allison, she said I could do it!
particle hrmm, last i spoke to her she said it should undergo a deprecation cycle
well, then, you're out of trouble.
the "mom said i could do it!" defense still works. 19:10
davidfetter there's a hilarious condom commercial with that as a them
+e
purl 2.71828182845905
dalek r35600 | simon++ | branches/strings/pseudocode (2 files): 19:12
: This is the first part of NFG normalization support.
review: www.parrotvm.org/svn/parrot/revision?rev=35600
19:16 Theory joined
coke particle: yah, I don't know why she let STM get in. <shrug> 19:26
particle well, hey, it's a smaller release now. that means it's more stable, and has fewer bugs. 19:28
pmichaud particle: pong 19:32
jhorwitz pmichaud: after particle times out, can you take a gander at RT #62410? 19:34
particle :P
pmichaud: i need some direction wrt pct and a command-line parsing module. PCT::HLLCompiler::Commandline::Parser? 19:35
jhorwitz particle: i underestimated your latency. :)
particle is multitasking 19:36
pmichaud jhorwitz: I'm guessing that breakage is due to the type registry stuff that jonathan put in.
particle: I'd go for PCT::Commandline::Parser
particle i know that name is too long, but shall it live in HLL... ok
jhorwitz ooooh, i can blame jonathan. i haven't done that in a while....
pmichaud or something simple like that. I wouldn't integrate it as part of HLLCompiler
i.e., I think it's worth being a standalone module. 19:37
it can be part of PCT, yes. But I even think it's worth being standalone in runtime/parrot/library/
coke particle: is this going to replace getopt?
particle right now there are methods in HLLCompiler for it, like 'process_args'
coke: that's the idea, at least for PCT
pmichaud HLLCompiler would probably evolve to use that library.
particle ok, figured. thanks.
i'll use p6meta etc 19:38
pmichaud that's fine, you can use P6object if you wish :-)
coke particle; I just hate to see timtowtdi in parrot. 19:39
19:39 Whiteknight joined
particle coke: i expect it'll replace getopt::obj, but i need to make sure it's compatible in order for that to happen 19:41
coke k
particle my top priority is making it work according to S19 19:48
i don't know how 'meta' i'll go with the interface yet, to make it do any flavor of cmdline parsing 19:49
lathos OH MAN THIS STUFF HURTS MY HEAD. 19:52
coke better you than us.
Whiteknight much better 19:54
I'm actually very interested to see how the strings system is going to turn out in the end 19:55
there are a lot of places where we are using C strings in the source code, like in src/inter_call.c and src/inter_run.c where we really should be using STRING instead 19:56
lathos It's very hard to make it do the right thing in the majority of places without doing the spectacularly wrong thing in unexpected corners.
Whiteknight yeah, I can imagine. Sounds a lot like the GC work I've been doing
you fix one thing, you break three others
lathos My current model has the character-length of a string changing if you look at it funny.
moritz looks funny at lathos' strings 19:57
jhorwitz quantum strings 19:58
20:02 particle1 joined
lathos OK, I think a Grapheme type will deal with some of my problems. 20:07
Whiteknight I wish we had a good test harness here at work, something automated and written in perl
coke me too. I write my code in cold fusion, what's your excuse?
Whiteknight instead, our test "harness" is about two meters wide, runs about a 25V, contains an air compressor, and I had to make out of wires, solder, and electrical tape 20:08
perl would have been much better
20:09 mberends joined
coke assigns a partcl to ticket to mdiep and crosses his fingers. =-) 20:13
Coke partcl is now loading tcl's standard "init.tcl" as part of the shell; lets me move some stuff I'd written in PIR as a stopgap to use the official tcl version. 20:14
particle1 it's nice to see tcl under development again 20:15
i guess that means parrot is a slower-moving target
Coke slower, yes. =-) 20:17
dalek r35601 | kjs++ | trunk/compilers/pirc/src (2 files): 20:32
: [pirc] don't store duplicate keys.
: + remove cpp comments.
: + add STRING * variant to constant struct.
review: www.parrotvm.org/svn/parrot/revision?rev=35601
21:01 riffraff joined
riffraff how is it possible to call a method from another method of the same object in nqp? it seems I have to pass self somehow but I'm not sure how 21:02
lathos I can't work out how to do it in P6... 21:03
PerlJam .meth() 21:04
(I have no idea if that works in NQP) 21:05
riffraff eh in fact :)
it seems that nqp objects do not have a 'self' set
so as long as you call $foo.bar it works, but .bar has no way of knowing how to call something else
oh well, I'll usea sub :) 21:06
pmichaud even .meth in Perl 6 doesn't mean "self.meth" :-)
PerlJam pm: it does if $_ is self :)
pmichaud I don't think that NQP sets a self yet. We haven't needed one. Arguably it should do that, though.
We could probably add it to NQP w/o too much difficulty.
21:09 contingencyplan joined
riffraff by the way: why people keep using $?BLOCK and @?BLOCK in parrot languages' action.pm ? 21:09
it seems to me that the twigil is useless, $BLOCK would be enough
particle it matches p6 syntax
so it's easy to remember that it's a compiler-special var 21:10
riffraff yes, but I thought the $? twigili was a kind of compile time var
ah I see
pmichaud $? is a compile time var. Since we're writing compilers, it make sense to use compiler time variables. :-) 21:25
s/compiler time/compile time/ 21:26
Andy++ # perlbuzz.com/2009/01/hooray-for-the...tures.html
shorten pmichaud's url is at xrl.us/becodd
Andy Thanks
pmichaud Merlyn++ 's reply to the original article is also sweet.
21:29 particle1 joined 21:48 rdice joined
GeJ Good morning everyone 21:48
Infinoid hi GeJ 21:50
22:01 Whiteknight joined
Infinoid Whiteknight: (backlogging) sorry, I can't provide updates on the miniparrot crash, because I can't reproduce it here anyway 22:10
Casan Andy: hehe despite Binstock's article being extremely unprofessional journalism, I still like the resulting attention and "we are going to prove him wrong" effect that it motivates :)
Infinoid Whiteknight++ for looking at it tho :)
Andy That's why I posted it. 22:11
Infinoid and Andy++ for giving us a rallying cry
Andy Thanks.
I am glad I sat on Piers' column. 22:12
I didn't have anything to say about it.
and now it just fit nicely ther.e
dalek r35602 | Whiteknight++ | trunk/src/pmc:
: [PMC] modify the behavior of the morph vtable override. From PIR, morph now uses a string parameter instead of an int. This user-facing behavior is different from the internal behavior, which needs to be redone/updated
review: www.parrotvm.org/svn/parrot/revision?rev=35602
Whiteknight thanks Infinoid
dalek r35603 | simon++ | branches/strings/pseudocode (4 files): 22:14
: Clarification of the grapheme/char distinction in ParrotNative.
review: www.parrotvm.org/svn/parrot/revision?rev=35603
Coke whee. partcl now uses the standard library's "auto_load", which allows you to bring in procs written in tcl fairly seemlessly. one more step (which I think I can get mdiep to commit), and then we'll have as much of the stdlib as we can otherwise run available to us. 22:16
Casan Andy: something seems confusing to me though... Randals comment "A usable public beta release should appear at OSCON this summer" and the vision for parrot 1.0 having production release march09 in whatever form.. is there a 1.0 vision for rakudo published anywhere... pmichaud?
pmichaud Casan: I'm putting that together now.
Coke *seamlessly
pmichaud However, I have publicly commented that Rakudo would likely have early adopter releases in early 2009.
Casan pmichaud++ for the leaving the nest entry btw, you addressed many of my concerns and its easy to be aligned with your strategy, it comes natural. 22:17
Whiteknight rakudo really is coming together remarkably quickly 22:18
Coke ^_o
Whiteknight it's quite inspirational, from my point of view
pmichaud Casan: (leaving the nest) -- thanks, now the devil is in the details. :-) 22:19
Casan yeah, threading careful is key, but must be decisive at some point. 22:20
22:27 TimToady joined
dalek r35604 | Whiteknight++ | trunk (2 files): 22:28
: [t] add a test for the new morph vtable override (actually, it's going to be for all vtable overrides, eventually)
review: www.parrotvm.org/svn/parrot/revision?rev=35604
Infinoid pmichaud: thanks for translating my journal comment to the list, your response makes a lot of sense 22:30
having rakudo build parrot seems like a good solution from the perspective of developing rakudo.
pmichaud Infinoid: thanks for the comment and ideas. 22:31
Infinoid: I think it might also point a way for us to be able to use git even if Parrot remains svn.
Infinoid I am a little concerned about the opposite perspective, though. would anyone really object to convenience targets e.g. "make partcl" and "make rakudo" just so you can tell whether a given parrot change breaks external languages?
even if they aren't the main mechanisms for obtaining those languages, I can see a use for that. 22:32
pmichaud well, I think that some developers who work on both Parrot and Rakudo would still have to deal with two repositories. But the general population could potentially just get everything from Rakudo's repo if Rakudo is their primary interest.
Infinoid yes, absolutely.
pmichaud all we would have left to figure out is a good way to handle the spectests (which are still svn)
I don't see an issue with a "make rakudo" or "make partcl" target. 22:33
OTOH, if we have a model whereby we expect people to download copies of Rakudo instead of Parrot, I doubt that Rakudo will continue to consider "languages/perl6" as its primary root.
so how Parrot would deal with that is an open question. 22:34
Infinoid that's fine. I'm not really sure how the two repositories should interact, but I would hope to make things as smooth as possible.
pmichaud i.e., I can envision that parrot/ will be a subdirectory of the Rakudo repository, instead of languages/perl6 being a subdirectory of the Parrot repo.
(and even if we do keep languages/perl6, it's likely to become languages/rakudo instead of languages/perl6. But we'll wait to see if that happens.) 22:35
Infinoid Presumably, the various libraries would all be doing pretty much the same thing, in this regard
lathos Shouldn't it be interpreters/rakudo? (Only half serious - the language is Perl 6, so perl6 is a good name for it.)
Infinoid s/libraries/languages/ 22:36
moritz lathos: it's not an interpreter
pmichaud lathos: if you're suggesting s/perl6/rakudo/ I agree. If you're suggesting s/languages/interpreters/ -- that's really up to Parrot. But I really think Rakudo isn't going to consider itself a subcomponent of Parrot much longer.
I don't know that we've had an official decision about where Parrot will look for its compilers. 22:37
latest I heard was runtime/parrot/languages/
but that was September 2008.
lathos What I mean is that "/languages/" is not a great name for implementations, particularly once you get multiple implementations of the same language. 22:38
Infinoid hmm, true
dalek r35605 | Whiteknight++ | branches: 22:39
: creating a new branch to update the morph vtable method to use STRINGS instead of INTVALS for the type
review: www.parrotvm.org/svn/parrot/revision?rev=35605
lathos languages/rakudo is clearly bogus; the language is not called "rakudo".
pmichaud lathos: that's a reasonable point
cotto Whiteknight, ping
pmichaud from my perspective I'm not sure we should make a distinction between "languages", "compilers", and "library" in the first place, but allison disagreed with me on that point.
22:40 Theory joined
Whiteknight cotto pong! 22:40
cotto There's a little gc code that uses PMC_struct_val (two instances in mark_sweep.c).
Is that something you could quickly store elsewhere? 22:41
Whiteknight you want I should bust it's knee caps or sometin? </Al Capone>
Coke IME, compilers == "stuff we ship with parrot", and languages == "stuff that's going to be addons" 22:42
cotto s/quickly/quickly figure out how to/
Whiteknight cotto, I could have it moved, yes. But I need to figure out where to move it to
I'l have to talk to chromatic/allison about it, since they're doing GC cleanup work now
cotto no big rush
ok
should I file a tt? 22:43
Whiteknight okay
yeah, do that so I don't forget
pmichaud Coke: we've done that for the sources, yes, but I mean where the runtime files should live.
i.e., once I've compiled NQP, where should the nqp.pbc file live so that the symlink from "nqp" to "parrot" can find it ? 22:44
PerlJam pm: where ever the parrot-install-language program puts it :) 22:46
22:46 Limbic_Region joined
pmichaud PerlJam: "Oh! Why didn't I think of that?" :-P 22:47
cotto Whiteknight, TT #178
22:51 On joined
dalek r35606 | Whiteknight++ | branches/morph_pmc_type/src: 22:51
: [morph_pmc_type] add a 'morph_string' type as a temporary replacement for 'morph'
review: www.parrotvm.org/svn/parrot/revision?rev=35606
Casan as for parrot under rakudo, or rakudo under parrot, now in a highly utopian but also call it as you see it relation, they are two projects running side by side, and at this time rakudo have parrot as dependency, but who said this is exclusive in the future? 22:53
Infinoid from the user's point of view, they want the language, and expect an implementation of that language to sort out its dependencies for itself. 22:54
Casan say from a freebsd users point of view, I'll do one of A or B
pmichaud it does raise an interesting point for some of the things in the examples/ directory. 22:55
Casan A) cd /usr/ports/lang/rakudo|perl6 && make install clean #which will include parrot as dependency
B) cd /usr/ports/lang/parrot && make install clean && cd /usr/ports/lang/rakudo.... 22:56
22:56 namenlos joined
Infinoid indeed. I think A) is more straightforward for new users. 22:56
Casan and keep it all update using portupgrade -rA
Infinoid then again, ports/pkgsrc will probably get this stuff right either way. (and so will apt, portage, yum, and all of those) 22:57
Casan Infinoid: sure, but but will be possible thanks to the ports system and rakudo parrot needs to do nothing different :)
Infinoid I just think it would be nice if rakudo's Makefile itself knew how to do it
Casan Infinoid: through the vcs strategy is the one to crack first
Coke pmichaud: I don't think users will specify it by name. It should probably be in the default search path. 22:58
Casan s/through//
Infinoid worst case scenario: skip the vcs entirely, the Makefile rule wgets and unpacks a parrot tarball.
Coke lets use language(s) ; tracks with our use of HLL
Casan Infinoid: you mean defining in the rakudo makefile that it is to install parrot?
PerlJam Casan: frontiersmen use the VCS, but early adopters use tarballs and rpms and debs and ... 22:59
pmichaud Coke: you don't think users will specify what by name?
Coke the path to perl6.pbc
or rather, the installed bits of perl6 in the parrot runtime. 23:00
Infinoid Casan: this is following a discussion about how Rakudo is the one who should define which version of Parrot it runs under
pmichaud Coke: my question is "what is the default search path" that finds perl6.pbc ?
Infinoid Casan: the next-to-last post on groups.google.com/group/perl.perl6....1384fb75e#
pmichaud last I heard it would be parrot/runtime/languages/
shorten Infinoid's url is at xrl.us/becoxv
Casan Infinoid: thnx for clarifying
pmichaud but Parrot doesn't implement that yet.
Infinoid not knowing anything about the issues or code involved, that sounds like an easy hack 23:08
has pdd30 landed yet?
pmichaud I don't think it has. 23:09
I could be wrong about that.
namenlos one question: why are the parrot and perl6 repositories going to be separated? 23:10
or should i ask this on #perl6? 23:11
PerlJam namenlos: though there is a dependency there, they have separate lives.
namenlos PerlJam: ok, then i will take it as it its - maybe i am not deep enough into this parrot/perl6 stuff... 23:12
Infinoid I think they just got tired of me committing codingstd tweaks all the time. 23:13
23:13 wolverian joined
lathos I don't understand either. 23:13
namenlos atm i am trying to make a working parrot/perl6 port for crux...
23:13 wolverian joined
PerlJam namenlos: Think of it like this ... when you first came into the world you lived with your parents, then you grow up and move out. The same thing might be happening with rakudo :) 23:14
lathos I grew up and moved out because I was able to operate independently. The same thing is not happening with rakudo.
namenlos PerlJam: lathos has an argument ;)
Casan but what will a separation of rakudo and parrot in relation to the language of perl6 and the implementation of perl6 known as rakudo, if this is clarified anywhere it would be a nice read 23:15
Limbic_Region I think moving languages out of parrot proper might encourage the respective maintainers to more freely give out commit bits
moritz even though I moved out, I'm still supported financially by my parents
namenlos but i think i got it, that they want to be some kind of separated...
Limbic_Region it worked extremely well with pugs
lathos Also, all analogies suck.
PerlJam indeed
Limbic_Region lathos - that's like saying....oh wait, nevermind
lathos Limbic_Region: Is that the reason for doing it, access to commit bits? 23:16
Limbic_Region dunno, I got the news about the same time as everyone else
lathos I haven't heard what the actual reason for doing it is.
Limbic_Region it had been discussed a number of times in the past
moritz lathos: I think there are many factors, for example communication mismatch
... different priorities ... 23:17
lathos There certainly is a communication mismatch. Nobody seems to be able to communicate why they need to do this!
What communication mismatch? What are the symptoms? What are the practical problems this is trying to solve?
Limbic_Region oh, salutations all btw
moritz because the rakudo developers aren't happy that their repo was nearly being migrated away under the feet with less than a day notice? 23:18
23:18 clunker3__ joined
moritz that's not the only reason (it had been planned for a while), but it sure is a trigger 23:18
lathos Yeah, I'm still waiting to hear what the reason is, though, and what problem it's trying to solve. 23:19
And if these problems are so great, how do they get fixed by a simple "svn switch" command?
namenlos anyone could give me a hand making a crux parrot port? 23:21
dpaste.com/109595/ this are the commands i use to build it
23:21 particle joined
lathos Looks good. 23:22
purl O_O
namenlos but still parrot searches for PCT.pbc in the diretory it was built...
strace is here: dpaste.com/109596/
lathos Ah. Yeah, I don't think make install actually works yet. :(
It's on the list.
namenlos lathos: no, you got to use reallyinstall
lathos Right, which is the target you use to mean "I know that installing doesn't work yet, but I want to do it anyway." 23:23
namenlos yes
if i then use the installed perl6 binary or any other pbc i get the following: dpaste.com/109598/ 23:24
lathos That's right.
This is because installing doesn't work yet.
namenlos nah...
lathos Yuh.
namenlos and there is no way that i can convince parrot to search in /usr and not /tmp/<where it was buit>/usr 23:25
hm, i could mess with sed :D
moritz namenlos: btw. parrot recommends icu and libgmp
namenlos: there's a branch for working on the installer, maybe you can can try it there, instead of trunk? 23:26
pdd30_install or pdd30install_stage4
namenlos moritz: i am using the 0.8.2 release atm 23:27
moritz: i will have a look at icu and libgmp (but atm i don't even know, what they're doing) 23:28
lathos Not enough. :(
moritz icu: Unicode functions: gmp: bigint support 23:29
namenlos here it is: It is also not optimized to build and test installables, which should not access libraries in the build directory, but in the destination directory. 23:31
that sucks
purl The rock is now off.
namenlos so i will add a readme to the port, which says, that it simply doesn't work atm 23:33
lathos There's a ticket for it - trac.parrot.org/parrot/ticket/123
23:34 kid51 joined
kid51 messages 23:34
namenlos lathos: thx. so let's hope for 0.9 23:35
23:37 gravity joined
namenlos thanks all for your help. i will go to bed. gn8 23:37
23:39 ask_ joined
pmichaud actually, I see it that Parrot is moving out of the Rakudo repository. :) 23:40
Casan did they expect rakudo to automatically follow suit into the new parrot repository, or whats their stance? 23:42
pmichaud this has actually been discussed a bit before.
Casan ref?
purl well, ref is an opaque value
pmichaud Rakudo has always been expected to stay with perl.org or something similar.
jonathan Rakudo is a Perl project, thus it'd make sense for it to stay hosted by perl.org.
Infinoid and supported by TPerlF 23:43
23:43 particle2 joined, particle3 joined
pmichaud Indeed, the copyrights for Parrot were transferred to the Parrot Foundation, but the transfers explicitly exclude Rakudo Perl. 23:43
jonathan jhorwitz: Will look at the bug you pm'd me tomorrow - bug me if I forget. :-)
cotto What's the quickest way to get good test coverage on all of Rakudo's PMCs? 23:44
lathos OK, this is starting to make more sense, and explains the Parrot SVN switch too.
23:44 ruoso joined
pmichaud I think most of Rakudo's PMCs are already being tested. Perhaps Perl6Str isn't, but I'm hoping it can go away at some point. 23:45
jonathan pmichaud: Will chip in to the "rakudo leaving the parrot nest" thread tomorrow - meant to today but ended up spending my time chasing down various role-related issues.
Casan the TPF relation is obvious. but how about management decissions such as local infrastructure, is that a TPF central decission, og a delegated, distributed rakudo management decission.
s/og/or
pmichaud jonathan: okay, great. Mainly I just need to know what you personally are comfortable with.
cotto pmichaud, right. I mean which make target can I use to hit the PMC code? 23:46
pmichaud cotto: "make test"
purl i guess "make test" is possessed!
jonathan pmichaud: I need to actually *try* using git before I can sensibly feed in to that one.
pmichaud jonathan: there's already a testing git setup for rakudo -- obra++ set it up
just a sec
jonathan pmichaud: I'm not exactly a fan of branching on svn...it's always got in my way.
pmichaud: But my concern is more for others than me - as I mentioned earlier.
Oh, that's awesome.
pmichaud github.com/obra/rakudoperl---test-c...ree/master 23:47
jonathan Thanks.
pmichaud it's just for playing and stuff, but obra++ was seeing how difficult it would be to move things from the perl.org svn repository to github. Turns out it wasn't difficult.
jonathan Will look tomorrow (too tired and beer right now).
pmichaud so we (you and I) can use that to test our newfound git skills :)
jonathan er. beer isn't a verb. :-)
moritz you can make it one ;-) 23:48
jonathan I haven't got any git skills yet, but I'll try and pick some up tomorrow. :-)
pmichaud same here. :)
and yes, I'm more concerned about newcomers to rakudo than me personally -- but developers have to remain productive also.
jonathan moritz: I already *did* invent a new Slovak verb for the act of drinking beer and use it liberally here. Everyone knows it's not really a word, but totally understands. ;-)
pmichaud "nom?"
jonathan pmichaud: Beer is pivo, there's a bunch of verbs ending "ovat", so I constructed "pivovat" :-) 23:49
jonathan is enjoying learning a new natural language, as well as Perl 6. 23:50
pmichaud excellent. 23:51
jonathan I'm still not sure which is harder. :-|
pmichaud I look forward to "Worthington's concise dictionary of the Slovak language" :-)
jonathan I've found another tricky issue with parametric roles. :-|
pmichaud I bet there are quite a few tricky issues with parametric roles.
jonathan role Foo[::T] { method foo(T $x) { ... } } 23:52
No prizes for guessing why this doesn't work out. :-(
pmichaud T's not lexical there?
jonathan Indeed. We're building the signautre in a :load :init.
pmichaud so why doesn't it work out?
jonathan Because the signature is built in an :init :load. 23:53
dalek r35607 | Whiteknight++ | branches/morph_pmc_type/src (6 files):
: [morph_pmc_type] add morph_string vtable methods to PMCs that had morphs. These should act identically, but they take strings instead of intvals. Now I can start switching the old VTABLE_morph to VTABLE_morph_string
review: www.parrotvm.org/svn/parrot/revision?rev=35607
pmichaud the signature of foo?
jonathan Yes, the signature of foo is.
We look up the type T at the time we build the signature, right?
pmichaud but looking up T is (or _was_) put into a block. 23:54
no, it had to be done as a block.
jonathan Oh.
OK, I know that examples like the above aren't working.
pmichaud because that's the only way that SIGNATURE_BIND could get the correct T.
where clauses also have to be put in blocks, for similar reasons.
jonathan If we do the lookup per binding (which you're right - we must), then there must be another reason it doesn't work. :-|
OK, I'll debug tomorrow
But you're right. Type capture could never work. 23:55
pmichaud yes, that was something I ran into in the rvar branch.
jonathan :-)
Fun stuff, hey? :-)
pmichaud it is, actually. :-)
Perl 6 gives us lots of daily puzzles.
jonathan Which is why it's the most interesting project I have.
TimToady s/sudoku/rakudo/
jonathan TimToady: My first commit to Rakudo had the tag [raduko] :-| 23:56
pmichaud anyway, whatever comments you have on the infrastructure thread are very welcome -- but I think I kinda understand your position already (and have it weighted accordingly)
jonathan Unpurposefully.
pmichaud so if you prefer to focus on hacking, that's okay too. Just browse the thread and speak up if you see anything you particularly disagree or agree with.
jonathan pmichaud: Unless I find git will hugely get in my way, and if I'm happy we're going to cater to new users (e.g. by having a read-only SVN mirror), I won't object to git. 23:57
pmichaud that's what I had figured, I think my position is the same.
jonathan That basically is my position on that issue. 23:58
pmichaud And too many people whose opinions I respect say that "git is wonderful" for me to dismiss it.
jonathan Site wise, I want _one_ place that I can tell people to go to for Rakudo info when I'm presenting it/telling people about it. Not just including latest news, but instructions on how to obtain it.
(where it = a working Rakudo) 23:59
pmichaud agreed. That will happen one way or another.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!