Camelia, the Perl 6 bug

IRC log for #parrot, 2009-01-15

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 dalek r35567 | kjs++ | trunk/compilers/pirc/src (5 files):
00:00 dalek : [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.
00:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35567
00:09 AndyA joined #parrot
00:18 dalek r35568 | Whiteknight++ | trunk (4 files):
00:18 dalek : [Core] remove dependence on PObj_data_is_PMC_array_FLAG, which was only used in three PMCs. Replaced with custom mark VTABLE routines.
00:18 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35568
00:31 dalek r35569 | japhb++ | trunk/config/gen:
00:31 dalek : [OpenGL] Add preliminary support for GLC
00:31 japhb Infinoid: Would you mind pulling and testing OpenGL on your box?
00:31 dalek : * config/gen/opengl.pm:
00:31 dalek :   + Add typedefs needed by GLC character rendering library
00:31 dalek :   + Mark GLC callbacks as skipped for now
00:31 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35569
00:32 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 Infinoid can do, one sec
00:32 japhb No good deed goes unpunished, clearly ...
00:32 particle joined #parrot
00:32 dalek r35570 | Whiteknight++ | trunk (4 files):
00:32 dalek : [GC] Remove Parrot_gc_trace_pmc_data(), it's unused now that nothing is using the PObj_data_is_PMC_array_FLAG flag.
00:33 Infinoid the wonders of modern technology
00:33 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35570
00:34 Infinoid japhb: went through Configure.pl cleanly
00:34 Infinoid what else should I test?
00:35 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:41 braceta left #parrot
00:41 Infinoid opengl example pir files are running fine
00:41 * japhb installs libglc-dev to test locally ....
00:41 japhb Infinoid: excellent.
00:41 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
00:42 japhb Yeah, you have to run it just like in the SYNOPSIS
00:43 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 ...
00:45 dalek r35571 | Whiteknight++ | trunk (5 files):
00:45 dalek : [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.
00:45 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35571
01:10 japhb That's odd ... *I* can't run any OpenGL examples now.
01:10 * japhb wonders what went wrong ...
01:14 Casan joined #parrot
01:29 kid51 joined #parrot
01:30 Infinoid heh, sorry
01:34 * japhb updating very old checkout of parrot on 64-bit box to see if it's another NCI 32-bit/64-bit snafu
01:35 Fayland joined #parrot
01:35 Infinoid I'm running on 64 bit, if it helps.
01:35 japhb Yeah, and I was testing on 32 bit
01:36 japhb I'm ruling out other variables by using two boxen with nearly the same config, except CPU
01:45 japhb 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:46 japhb So it sounds like two bugs.
01:49 Infinoid urk.
01:49 japhb Checking with --jitcapable=0  on the 32-bit box
01:50 Infinoid japhb++
01:57 Infinoid 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:58 Infinoid oh, it didn't have a PackfileFixupTable to begin with.  nevermind.
02:05 Infinoid 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.
02:07 japhb Yup.  Problem 1 is 32-bit JIT NCI -- it's broken again (still?)
02:07 japhb tewk: ping
02:12 nopaste "japhb" at 76.191.190.8 pasted "Rakudo failure trying to run simplest OpenGL example" (119 lines) at http://nopaste.snit.ch/15312
02:16 japhb pmichaud, jonathan: Can one of you take a look at the above Rakudo crash?
02:17 pmichaud my $window = glutCreateWindow('Test');
02:17 pmichaud what kind of object is $window there?
02:18 japhb pmichaud: checking ...
02:19 pmichaud try say($window.PARROT);
02:19 japhb A simple int
02:19 pmichaud okay, that's good.
02:20 pmichaud Let me update parrot/rakudo on my system and see how far I get.
02:20 japhb ok
02:20 pmichaud (I'm also in the midst of composing a long blog post so I'm only operating at partial capacity)
02:21 pmichaud 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?
02:22 japhb Which reminds me, configure with --jitcapable=0 in order to rule out that mess.
02:22 pmichaud thanks
02:23 pmichaud (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 pmichaud then when a function is called, Rakudo sends the reference instead of the thing being referenced.
02:23 pmichaud (this goes for NCI functions as well)
02:23 pmichaud so many NCI functions don't know what to do with the reference that Rakudo sends.
02:23 pmichaud and get confused because the PMC isn't the exact type they expect.
02:25 japhb gotcha.
02:25 japhb How do you even go about debugging that, from the point of view of the library?
02:25 pmichaud I'm not sure.
02:25 japhb bah, AFK for a bit, bbiab
02:26 pmichaud that's where we need some more examples to work with.
02:26 pmichaud (like the one you provided.)
02:26 pmichaud Also jonathan and I need tuits.  :-)
02:26 pmichaud my tuits for the week just got reassigned by today's events, I think.
02:28 Casan can it be expected that the issues with NCI is also causing issues to DBDI development?
02:29 dalek r35572 | infinoid++ | trunk/t/pmc:
02:29 dalek : [pdd13] Fix some descriptions in packfileconstanttable.t.  Add a sanity check
02:29 dalek : to make sure we're dealing with the right segment of the PMC.
02:29 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35572
02:29 pmichaud Casan: yes, I think that's the case.
02:29 dalek r35573 | infinoid++ | trunk (2 files):
02:29 dalek : [pdd13] Implement and test the readonly portions of PackfileFixupTable.
02:29 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35573
02:30 dalek r35574 | infinoid++ | trunk (2 files):
02:30 dalek : [pdd13] Implement and test the readonly portions of PackfileFixupEntry.
02:30 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35574
02:31 jimmy joined #parrot
02:32 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.
02:35 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.
02:35 Infinoid no problem, I'll keep plugging away at other stuff then.
02:36 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:37 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 :)
02:37 pmichaud Infinoid: so a person want to use Rakudo would need both git and svn.
02:37 pmichaud *wanting
02:38 pmichaud 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)
02:38 pmichaud that's simply what I see as the largest obstacle to a git switch for Rakudo.
02:39 Casan sounds reasonable to evaluate the options.
02:43 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 Infinoid I think git-svn would use far too much bandwidth in this case, it doesn't have an equivalent of "export".
02:43 pmichaud ("export")  -- no, because we subsequently do "svn up"
02:43 pmichaud because otherwise "export" uses too much bandwidth.
02:43 jrockway joined #parrot
02:43 Infinoid ah.  guess I rarely get that far
02:44 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
02:44 Infinoid 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"
02:45 Infinoid last I checked, symbolic revision names like -rHEAD were not supported.
02:45 pmichaud right.
02:45 pmichaud 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.
02:47 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:48 pmichaud it doesn't have to happen in a week.
02:48 pmichaud and both jonathan and I are pretty quick learners :-)
02:48 Infinoid I have no doubt of that :)
02:48 pmichaud I'm more concerned about how it affects the larger community than how it affects me personally.  I can figure git out :-)
02:49 pmichaud especially since it's apparently the "greatest software package ever created in this universe or any other"
02:49 jrockway joined #parrot
02:49 pmichaud :-)
02:49 pmichaud (okay, I'm paraphrasing :-)
02:49 Casan <Casan> is there a "svn up" equivalent in git?
02:50 Casan <mugwump> Casan: git doesn't really do anything that unreliable
02:50 Casan <mugwump> a rough equivalent is 'git pull --rebase'
02:50 Casan <mugwump> or perhaps 'git stash save ; git pull ; git stashapply'
02:50 Casan either way, I am sure the git crowd would be eager to help.
02:51 Casan the above was from the #git channel on #freenode of course.
02:51 leto joined #parrot
02:51 Infinoid in my case, it's usually "git fetch; stg rebase origin"
02:53 jimmy Git was not well supported on windows.
02:53 Infinoid "was"?
02:53 purl somebody said "was" was "what"
02:53 particle1 joined #parrot
02:53 jimmy Maybe I should say 'is'?
02:53 Infinoid if you've tried it recently, and it sucks, then I think "is" is appropriate :)
02:54 Infinoid (I have no idea, I was just curious)
02:54 dalek r35575 | cotto++ | trunk/src (3 files):
02:54 dalek : [cage] revert r35520,5,6.  There's too much hole and not enough dam for this strategy to be effective.
02:54 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35575
02:56 pmichaud http://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)
02:56 jimmy It is supported now.
02:57 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:58 japhb bak, backlogging ...
02:58 Infinoid I've been pushing for it mostly because of the merging issues we are (still) running into
02:58 jimmy msysgit is on windows.
02:58 Coke pmichaud: I have commit bits to http://dev.perl.org/perl6/
02:58 Coke I think.
02:59 pmichaud (1) Can I get commit bits?
02:59 Coke ask robrt.
02:59 pmichaud (2) If no to #1, can I get you to proxy for me?  ;-)
02:59 Coke (2) definitely.
02:59 Coke let me get you the repo url.
02:59 pmichaud that would help a lot.
03:01 pmichaud okay, wife wants some of my time for a while.  I'll post more later.
03:02 Coke https://svn.perl.org/perl.org/docs/live/dev/perl6
03:02 Coke I'm happy to apply any patches until/when you get commit bits.
03:02 Coke I'll open a ticket with robert.
03:03 Casan http://code.google.com/p/msysgit/ is a good bet for git on windows. I'm testing it now.
03:03 Coke (done)
03:03 jimmy Casan: yep
03:04 Infinoid ooh, a crash test dummy!
03:04 GeJ Which TPF will manage the distribution of commit bits to Rakudo?
03:04 GeJ The Parrot one, or the Perl one?
03:04 Infinoid if I had to guess, I'd say probably the Perl foundation, but I'm not positive.
03:05 Infinoid 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.
03:05 Coke man, does use.perl.org's footer bar look ugly in safari. :|
03:05 Casan Infinoid: sure
03:05 Infinoid Coke: it looks ugly in firefox too.  stuff sitting on top of other stuff
03:06 Coke wish I had IE or chrome.
03:06 Coke (there's something I don't normally say...)
03:06 * Infinoid tries those
03:06 Infinoid chrome isn't bad.
03:07 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
03:07 pmichaud (commit bits)  I think I get to manage those.
03:07 Casan chrome is nice, fast, but have some minor rendering problems, and plugin/extension system is sorely missed.
03:07 pmichaud I'm fairly certain I get to set the initial policy.
03:08 pmichaud 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.
03:08 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
03:09 Infinoid 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 #parrot
03:10 GeJ s/entitled/allowed/
03:10 Infinoid Coke: looks horrid in chrome too
03:10 GeJ sorry, wrong choice of word.
03:10 cotto GeJ, commit bits for Rakudo are the same as for Parrot right now.
03:11 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.
03:11 cotto (same as any other HLL that hasn't left the nest)
03:11 Infinoid once TParrotF starts managing these things, will I have to send in another CLA, or are existing committers grandfathered in?
03:12 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:13 jimmy Casan: see also http://sourceforge.net/projects/gitextensions/ on windows
03:13 cotto GeJ++ #not the Best Imagery Evar, but close
03:14 jimmy but I have not try that.
03:14 purl joined #parrot
03:16 jimmy but I have not try that.
03:16 jimmy s/try/tried/
03:18 Casan_ joined #parrot
03:19 Casan_ the Git-1.6.1-preview20081227.exe can't execute on my system now downloading the older beta to test
03:20 japhb jimmy: nice!  Now I can tell my Tortoise-loving friends to stop hating git for lack of shell extensions.
03:22 leto joined #parrot
03:25 jimmy good.
03:27 Casan_ jimmy: you have a setup with git-extensions on windows working
03:28 jimmy the firewall blocked me to download *.exe files.
03:29 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
03:30 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 cotto by "easy", I mean "only modifies pobj.h"
03:31 cotto It's tricky when the macro is used as an lvalue, and rvalue and a function argument.
03:32 cotto Changing the usages of the macros is less appealing because there are >1200 of them.
03:33 Casan jimmy: I could download it, zip it and make it available to you, just let me know which file
03:34 purl joined #parrot
03:34 jimmy Casan: thanks, I hadn't used git yet.
03:40 jimmy cotto: can you nopaste the 1200 codes?
03:41 cotto any invocations of PMC_x_val (PMC_int
03:41 cotto _val, PMC_pmc_val, etc)
03:43 Infinoid cotto: yeah, that's a tough one.  I can't think of a way to do it.
03:44 cotto well, if it were easy someone would have done it already
03:45 Infinoid well, hmm
03:46 Infinoid no, this should be possible
03:48 Infinoid #define PMC_pmc_val(pmc) (((long*)pmc)[some_inline_function_tha​t_returns_its_parameter((long*)&((pmc)​->cache._ptrs._pmc_val)-(long*)pmc)])
03:48 Infinoid err, that should probably be
03:48 cotto I was thinking some bogus inline trinary operator, but let me parse that...
03:48 Infinoid #define PMC_pmc_val(pmc) (((PMC**)pmc)[some_inline_function_tha​t_returns_its_parameter((long*)&((pmc)​->cache._ptrs._pmc_val)-(long*)pmc)])
03:49 Infinoid 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 Infinoid it's a single expression, therefore can be an argument, lvalue or rvalue
03:49 Infinoid probably get some warnings from the casting madness though.
03:50 cotto actually I was hoping to stick another macro in there (to get file and line info)
03:50 cotto (and a pony)
03:50 Infinoid no, you'd need to put __FILE__ and __LINE__ into the PMC_x_val definition directly
03:50 Infinoid putting it in an inline function would just give you the file and line number of the inline function.
03:50 Infinoid though you could certainly pass them to your function as additional arguments
03:52 Infinoid its sickening to look at, but a construct like that should work.
03:52 purl joined #parrot
03:52 cotto yes and yes
03:52 cotto Infinoid++
03:52 Infinoid (oh, and don't expect inline functions to be portable at all, they are not C89)
03:53 tetragon joined #parrot
03:53 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 #parrot
03:54 Infinoid oh, the array offset calculation will need to be divided by sizeof(long) too
03:54 Infinoid (C wouldn't be any fun without pointer arithmetic getting in the way)
03:54 kid51 purl, are you having problems staying awake tonight?
03:54 purl bugger all, i dunno, kid51
03:55 * kid51 must sleep
03:55 purl $kid51->sleep(8 * 3600);
03:57 rurban_ joined #parrot
04:00 dalek r35576 | allison++ | trunk/src/pmc:
04:00 dalek : [cage] Change the parsing of FixedIntegerArray initialization strings from
04:00 dalek : poking directly into the guts of a STRING to use a temporary C string.
04:00 dalek : Partially resolves RT #47011.
04:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35576
04:04 Infinoid cotto: I am amazed, that construct worked more or less as-is, for me
04:05 nopaste "Infinoid" at 75.28.74.141 pasted "A glorious hack." (40 lines) at http://nopaste.snit.ch/15313
04:06 Infinoid and I was wrong about dividing by sizeof(long).
04:09 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:10 Infinoid no warnings?  that's ... astonishing.
04:11 cotto forgot to inline...
04:13 cotto If this works, I'm going to have to throw you a parade or something.
04:13 cotto it built
04:13 Infinoid hah.  so I'm curious, what are you testing for?
04:14 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
04:14 cotto yes
04:16 Coke that looks insanely evil.
04:16 Coke Infinoid++
04:16 Coke cotto++
04:17 Coke sleep--
04:17 Coke karma sleep?
04:17 purl sleep has karma of 106
04:17 Infinoid cotto++
04:17 cotto Infinoid++
04:17 cotto karma for everyone!
04:17 purl everyone! has neutral karma
04:17 cotto except purl
04:17 Infinoid it's an interesting set of constraints.  would make a good subject for a game of golf
04:18 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
04:20 cotto make test passes with one instrumented macro
04:20 cotto amazing
04:21 Infinoid \o/
04:23 cotto or not.  I think I had the macro disabled.
04:23 cotto cotto--
04:24 cotto definitely enabled now, trying again...
04:26 Coke_z tcl: for {set a 1} {$a < 7/2} {incr a} {puts cotto--}
04:26 polyglotbot OUTPUT[cotto--␤cotto--␤]
04:26 Coke_z tcl: for {set a 1} {$a < sqrt(10)} {incr a} {puts cotto++}}
04:26 polyglotbot OUTPUT[extra characters after close-brace␤]
04:26 Coke_z tcl: for {set a 1} {$a < sqrt(10)} {incr a} {puts cotto++}
04:26 polyglotbot OUTPUT[cotto++␤cotto++␤cotto++␤]
04:26 cotto I'm tcl'd
04:27 Infinoid polyglotbot++
04:37 jimmy does c89 support inline function?
04:37 TonyC no
04:40 Infinoid msvc barfs on them
04:45 Infinoid and I'm not really sure how the INLINE macro is supposed to help
04:51 cotto btw, it's also used as an array index.  I think I can work around that.
04:52 cotto and math
04:58 Infinoid it evaluates to a self-contained expression... I don't know that any of those will be a problem
05:05 Casan time to zzzz.. looking into more git win tomorrow
05:05 Infinoid no problem.  thanks for trying it out, Casan
05:05 Infinoid sleep well
05:05 masak joined #parrot
05:08 GeJ hej masak
05:08 masak hola GeJ
05:09 masak I guess it's nearing noon for you.
05:11 GeJ I'm well advanced in the afternoon actually. 4 PM
05:12 masak oh -- of course. it's 6 in the morning here.
05:12 Infinoid and 9pm here
05:12 masak globe++
05:12 Infinoid earth: we have you surrounded, come out with your hands up
05:15 particle joined #parrot
05:18 PerlJam Where are you at?  I'm at 11pm.
05:19 PerlJam I wonder if temporal location will catch on  :)
05:21 leto joined #parrot
05:22 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:24 MariachiElf joined #parrot
05:24 tetragon joined #parrot
05:25 Infinoid Casan: great, opening text files in notepad is all you should need
05:25 Infinoid so that means it Does The Right Thing, that's all I wanted to know
05:25 Infinoid thanks!  Casan++
05:27 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 Casan 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.
05:30 Casan which includes not disgruntling the existing user base with a premature migration
05:32 jimmy git++
05:34 leto joined #parrot
05:42 Tene joined #parrot
05:49 GeJ is jrieks still active?
05:51 GeJ last commit seems to be 2005.6.13
05:52 Infinoid not as far as I know
05:53 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.
05:55 cotto Infinoid, the only problem was that I forgot the change the types that the macros cast to.  With that, everything looks peachy.
05:56 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?
05:57 cotto yes
05:57 cotto about to commit...
05:57 cotto j/k
05:59 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 Infinoid anyway, gcc rules for handling all the weird junk we throw at it all the time
05:59 Infinoid goodnight
06:06 cotto night
06:10 leto joined #parrot
06:30 masak 240 Rakudo tickets!
06:33 MariachiElf left #parrot
06:35 MariachiElf joined #parrot
06:42 leto joined #parrot
06:47 HG` joined #parrot
06:53 cognominal joined #parrot
06:58 namenlos joined #parrot
07:04 alvar joined #parrot
07:25 particle1 joined #parrot
07:29 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
07:56 dalek r35577 | rurban++ | branches:
07:56 dalek : 5 patches partially merged: RT#57548, RT#57006, RT#56998, RT#51944, TT#94
07:56 dalek : the rest not. See http://lists.parrot.org/pipermail/p​arrot-dev/2009-January/000847.html
07:56 dalek : and https://trac.parrot.org/parr​ot/wiki/Pdd30InstallTasklist
07:56 dalek : Ongoing work in branches/pdd30install_stage4
07:56 shorten dalek's url is at http://xrl.us/beck5m
07:56 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35577
07:58 iblechbot joined #parrot
08:02 mberends joined #parrot
08:06 cognominal joined #parrot
08:20 cotto anyone here familiar with Parrot's gc?
08:24 hudnix joined #parrot
08:37 alvar joined #parrot
08:46 jimmy nopaste?
08:46 purl i guess nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others)
08:46 nopaste "jimmy" at 220.231.152.66 pasted "add '=cut'" (62 lines) at http://nopaste.snit.ch/15315
09:01 barney joined #parrot
09:06 cotto jimmy, you can also use tools/dev/nopaste.pl
09:07 jimmy I had created a TT
09:09 leto joined #parrot
09:35 donaldh joined #parrot
09:35 donaldh irc://irc.cisco.com/
09:46 particle joined #parrot
09:47 dalek r35578 | fperrad++ | trunk (3 files):
09:47 dalek : [harness]
09:47 dalek : - restore --html option
09:47 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35578
09:50 dalek r35579 | bernhard++ | trunk/src:
09:50 dalek : [codingstd] t/codingstd/c_indent.t
09:50 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35579
09:52 dalek r35580 | bernhard++ | trunk/src/gc:
09:52 dalek : [codingstd] t/codingstd/c_parens.t
09:52 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35580
10:06 kj joined #parrot
10:24 bacek joined #parrot
10:54 alvar joined #parrot
11:01 braceta joined #parrot
11:15 dalek r35581 | bernhard++ | trunk/t/codingstd:
11:15 dalek : [t] Some beautifications.
11:15 dalek : More info for misplaced macro invocations.
11:15 dalek : Pull expensive join outside the loop.
11:15 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35581
11:25 dalek r35582 | simon++ | branches/strings/pseudocode (2 files):
11:25 dalek : Another function or two done, plus the start of UTF8 support.
11:25 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35582
11:26 clunker3 joined #parrot
11:26 bacek joined #parrot
11:30 cotto it's interesting to turn Parrot's test suite into an IO-bound task
11:34 dalek r35583 | bernhard++ | trunk/src:
11:34 dalek : [codingstd] Add a missing ASSERT_ARGS()
11:34 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35583
11:57 rurban_ joined #parrot
12:00 Casan joined #parrot
12:06 particle1 joined #parrot
12:12 pancake joined #parrot
12:12 pancake i can has a segfault for rakudo
12:13 jonathan congrats!
12:13 pancake :P
12:13 jonathan we can haz a bug report?
12:13 pancake indeed!
12:13 pancake im just trying to reproduce it with the minimum number of chars
12:13 jonathan Were you using the perl6 executable, or the PBC?
12:13 pancake the perl6 executable
12:14 pancake with 0.8.2
12:14 pancake somebody can try with svn maybe its fixed there..
12:15 jonathan pancake: Also interesting - if you cd languages/perl6 and ../../parrot perl6.pbc the_thing_that_segvd.p6
12:16 jonathan Does it segfault there?
12:16 pancake uhm . nope :S
12:16 pancake *** glibc detected *** ./perl6: corrupted double-linked list: 0x085fdb28 ***
12:17 pancake 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.
12:18 jonathan *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 jonathan So the segfault, rather than just getting an error, is related to that.
12:18 pancake http://shorttext.com/inyhgsk
12:18 jonathan But the error shows something is wrong too.
12:19 pancake i know that this is not valid p6 code, i was just trying to get an error from the parser O:)
12:21 jonathan pancake: Yes, it still explodes on HEAD too. Bug report most welcome. :-)
12:21 jonathan rakudobug?
12:21 purl i guess rakudobug is mailto:rakudobug@perl.org
12:21 jonathan To there.
12:21 pancake no special format expected? subject+body and that is?
12:21 jonathan No, nothing special.
12:22 pancake cool. thanks
12:22 jonathan Just include the stuff on the page you just linked me to.
12:24 pancake uhm..the bug cannot be reproduced if i define the array and the hash in the same line
12:24 ruoso joined #parrot
12:24 pancake my @a,%b; <- does not crash, my @a;my %b; <- crashes
12:25 jonathan pancake: I don't see that issue in head.
12:26 pancake let me prepare a oneliner
12:26 pancake my @a; my %b; @a[0].""~%b{0};
12:27 pancake that is
12:29 lathos % ./perl6 -e 'my @a; my %b; @a[0].""~%b{0};'
12:29 lathos too few arguments passed (1) - 2 params expected
12:30 dalek r35584 | bernhard++ | trunk (3 files):
12:30 dalek : [codingstd] svn props and MANIFEST for new files
12:30 jonathan I get that here too
12:30 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35584
12:30 jonathan It's the wrong error.
12:30 pancake dalek: jonathan :  svn?
12:30 jonathan pancake: yes
12:30 pancake jonathan: long example crashes for you?
12:31 lathos I get this at the end: perl6(1245) malloc: *** error for object 0x3167870: double free
12:31 lathos But then I *always* get a segfault after an error.
12:31 dalek r35585 | bernhard++ | trunk (2 files):
12:31 dalek : [perl] Some beautifications and POD updates
12:31 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35585
12:32 lathos If all that effort ensuring coding standards went into implementing new code, we'd have Parrot done by now.
12:35 jonathan pancake: Yes.
12:36 moritz lathos: ... but maybe with such unreadable code that nobody wants to touch it anymore
12:37 lathos Who knows.
12:37 dalek r35586 | jonathan++ | trunk/languages/perl6/src (2 files):
12:37 dalek : [rakudo] Get parametric roles working with mixins via the does operator.
12:37 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35586
12:38 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.
12:39 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.
12:40 jonathan People always come and clear up after me when I do such things. :-)
12:40 namenlos joined #parrot
12:42 tetragon joined #parrot
12:48 dalek r35587 | simon++ | branches/strings/pseudocode (3 files):
12:48 dalek : Split things into separate files.
12:48 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35587
12:54 barney jonathan--
12:57 riffraff joined #parrot
13:00 dalek r35588 | bernhard++ | trunk (3 files):
13:00 dalek : [tools] Add script tools/dev/mk_gitignore.pl.
13:00 dalek : Add support for mk_gitignore.pl to Parrot::Manifest.
13:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35588
13:01 pmichaud lathos: (re parrot-dev post)   do you expect the string handling interface itself to change, or just the internals?
13:02 pmichaud i.e., are you envisioning that the opcodes or their arguments will change?
13:03 lathos I don't know what the dividing line between the internals and the externals is.
13:03 alvar joined #parrot
13:03 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:06 pmichaud okay, so you're referring primarily to the C-level interfaces?
13:06 lathos I think so, yes.
13:06 pmichaud okay.
13:06 pmichaud that makes sense to me.
13:08 pmichaud 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):
13:08 dalek : Ignore all *.o files in the parrot root.
13:08 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35589
13:08 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)
13:10 pmichaud 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 pmichaud again, that's just one viewpoint, not in any way "official".
13:11 pmichaud I totally agree with you that we've stored up a lot of issues in the STRINGS implementation
13:12 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 lathos Otherwise it ends up with the default UTF-7 EBCDIC.
13:12 pmichaud Rakudo acts as if that's the case already, I think.
13:13 pmichaud with one exception
13:13 pmichaud 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.
13:13 lathos OK.
13:14 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 ?
13:14 pmichaud if worse came to worse, we _could_ reimplement that logic in PIR.
13:14 pmichaud riffraff: I'm not aware of one.
13:15 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:16 riffraff or maybe we should just drop \s after an action key ? I can submit a patch if that makes sense
13:17 pmichaud riffraff: I've thought about doing that in the past, but for some reason had decided against it
13:18 pmichaud 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
13:18 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
13:18 riffraff yes, found it
13:19 pmichaud (I'd do a patch but I'm not sure when my schedule will let me get to it.)
13:27 riffraff ok, I'll see what I can do, thanks
13:31 Whiteknight joined #parrot
13:32 dalek r35590 | bernhard++ | trunk/lib/Parrot:
13:32 dalek : [tools] Add leading slash, in order to avoid shell globs with ignored directory part.
13:32 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35590
13:35 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
13:36 Casan there must an implementation of an inter-planetary protocol somewhere on cpan.
13:37 moritz TCP over avian carriers? :-)
13:42 bacek rakudo: say "000" ?? 1 !! 0
13:42 polyglotbot OUTPUT[1␤]
13:42 bacek rakudo: say "0" ?? 1 !! 0
13:42 polyglotbot OUTPUT[0␤]
13:42 lathos Same as Perl 5 then.
13:43 moritz rakudo: say "00" ?? 1 !! 0
13:43 polyglotbot OUTPUT[1␤]
13:56 estrabd joined #parrot
14:00 dalek r35591 | bernhard++ | trunk/languages/pipp/docs:
14:00 dalek : [Pipp] Mention plan to implement constanst as package vars.
14:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35591
14:13 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:14 Coke_Zzzzzz was there any discussion about bringing back the --html option for languages test?
14:14 Coke_Zzzzzz (smoke is dead.)
14:14 AndyA joined #parrot
14:15 pmichaud Coke_Zzzzzz: thus my request to get rid of the perl6-internals mailing list and have a responder message.
14:15 pmichaud Coke_Zzzzzz: also to disable the parrotbug@perl.org mailing list.
14:15 iblechbot joined #parrot
14:15 pmichaud sorry, auto-forwarder.
14:16 pmichaud (parrotbug@perl.org could also use the message I suggested.)
14:27 particle joined #parrot
14:37 dalek r35592 | pmichaud++ | trunk/languages/perl6/docs:
14:37 dalek : [rakudo]: spectest-progress.csv update: 284 files, 6254 passing, 0 failing
14:37 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35592
15:08 AndyA joined #parrot
15:17 Whiteknight question: should src/pmc/object.pmc:invoke() be marked with "VTABLE"?
15:18 gryphon joined #parrot
15:18 Whiteknight I mean, it is a vtable method, so it should have the VTABLE keyword?
15:28 Casan joined #parrot
15:30 nopaste "barney" at 84.154.3.25 pasted "*Main namespace" (18 lines) at http://nopaste.snit.ch/15316
15:31 iblechbot joined #parrot
15:31 barney quick Perl 6 question: How would I access $FOO in the main namespace ?
15:32 jonathan $*FOO
15:32 jonathan Erm
15:32 jonathan No
15:32 PerlJam barney: $OUTER::FOO might work.
15:32 jonathan $::Main::Foo
15:33 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
15:33 polyglotbot ..'parrot;PCT;HLLCompiler;evalpmc' pc 888 (src/PCT/HLLC...
15:33 moritz masak: want to file a bug report? :-)
15:33 jonathan Oh, that one.
15:33 moritz rakudo: our $x = 5; module Foo { say $Main::x };
15:33 polyglotbot OUTPUT[Use of uninitialized value␤␤]
15:34 moritz rakudo: our $x = 5; module Foo { say $Main::y };
15:34 polyglotbot OUTPUT[Use of uninitialized value␤␤]
15:34 jonathan our $x = 5; module Foo { say $*x }
15:34 jonathan rakudo: our $x = 5; module Foo { say $*x }
15:34 polyglotbot OUTPUT[Use of uninitialized value␤␤]
15:34 moritz Main variables aren't global
15:34 jonathan rakudo: say 1; module Foo { say 2 }
15:34 polyglotbot OUTPUT[2␤1␤]
15:35 jonathan Hmm. :-)
15:35 jonathan moritz: Aye, just wanted to check what it did.
15:37 mberends joined #parrot
15:38 PerlJam Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers
15:38 PerlJam ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
15:38 PerlJam Segmentation fault
15:38 purl (Core dumped)
15:38 PerlJam bummer
15:38 PerlJam make: *** [runtime/parrot/include/config.fpmc] Error 139
15:38 Lorn joined #parrot
15:38 jonathan make fail
15:39 jonathan PerlJam: You doing stuff in Parrot guts? Or is that right from svn?
15:40 PerlJam jonathan: that's "make realclean; perl Configure.pl && make" with no local mods at all
15:41 jonathan Oh. Ouch. :-(
15:41 jonathan Platform?
15:42 moritz PerlJam: new compiler?
15:42 Coke_Zzzzzz (warn) poor man's: 'printerr'
15:42 coke pmichaud: you have commit bits to the dev.perl6 repo now, I think.
15:43 coke 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
15:43 coke (typically, test all changes locally in teh combust framework before commiting)
15:45 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 kj joined #parrot
15:47 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?
15:47 PerlJam and the fresh checkout did exactly the same thing.
15:47 barney rakudo: say()
15:47 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
15:47 polyglotbot ..144482 (src/gen_actions.pir:13479)␤called from Sub '...
15:48 Whiteknight PerlJam, what revision are you at?
15:48 PerlJam 35592
15:49 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:50 Whiteknight I don't know if there have been any other changes since then that would cause miniparrot to segfault
15:51 * pmichaud tries a fresh checkout.
15:51 mberends the most recent running rakudobot is r35589, so r35590 may be the problem
15:51 * jonathan did an svn up and clean build today and had no issues on Win32
15:52 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.
15:53 Whiteknight PerlJam, you think you could nopaste a backtrace?
15:53 galf joined #parrot
15:53 mberends true, making r35589 also segfaults here in Linux
15:54 PerlJam Whiteknight: if you tell me how to do it, sure :)
15:55 Whiteknight PerlJam, in the parrot repo, you should be able to type "gdb miniparrot" to start the debugger
15:56 barney r35592 looks fine here, on Kubuntu 8.10
15:56 mberends rakudo: say %*VM<config><revision> # presumably built OK
15:56 polyglotbot OUTPUT[35592␤]
15:57 Whiteknight yeah, 35592 just build fine for me on WinXP32
15:59 * PerlJam puts git bisect to use for real for the first time.
16:01 PerlJam 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.
16:01 pmichaud r35592 builds fine for me.
16:02 pmichaud PerlJam: are you 64-bit ubuntu?
16:02 PerlJam pm: yep
16:02 pmichaud pj: ah.  That's an important detail.  :-)
16:03 pmichaud (I'm 32-bit kubuntu 8.04, fwiw)
16:03 moritz r35592 builds fine on 32 bit debian
16:03 coke pmichaud: start here: http://combust.develooper.com/
16:04 pmichaud coke:  will do, a bit later ($otherjob call now)
16:04 Whiteknight urg, my 64 bit ubuntu computer is at home!
16:05 * Infinoid tries it on 64 bit gentoo
16:05 coke combust?
16:05 purl combust is probably the web framework / content management system for geeks that we use at perl.org. See http://combust.develooper.com
16:05 coke aha. =-)
16:08 Infinoid PerlJam: do you have a backtrace?  (did you already paste one and I missed it?)
16:09 Infinoid trunk@35592 builds fine here on gentoo/amd64
16:11 PerlJam er, no I got sidetracked playing with git bisect.
16:12 Infinoid passes all tests, too
16:13 PerlJam so ... how do I generate a backtrace from gdb?
16:13 PerlJam (again, I never use it)
16:13 moritz gdb ../path/to/parrot
16:13 moritz run path/to/file
16:13 moritz # wait
16:13 moritz bt
16:14 dalek r35593 | infinoid++ | trunk/languages/perl6/src/classes:
16:14 dalek : [codingstd] Fix a trailing_space.t failure in rakudo.
16:14 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35593
16:14 Infinoid or you can generate one after the fact, if you have a core file.
16:15 Tene joined #parrot
16:15 nopaste "PerlJam" at 165.95.12.42 pasted "miniparrot backtrace" (17 lines) at http://nopaste.snit.ch/15317
16:16 Infinoid uh.  that sure looks like a bug
16:16 Infinoid are you still in gdb?
16:17 Theory joined #parrot
16:17 PerlJam yes
16:18 Infinoid great, try these
16:18 Infinoid print scheduler->vtable
16:18 cognominal joined #parrot
16:18 Infinoid if that doesn't return NULL or something like 0xdeadbeef, try:
16:18 Infinoid print scheduler->vtable->share_ro
16:18 PerlJam $1 = (VTABLE *) 0xdeadbeef
16:19 Infinoid that's ticket-worthy :)
16:20 Infinoid its a PMC that was just created, yet has a bogus vtable-pointer array
16:21 Infinoid so your pmc_new() is broken.
16:22 Infinoid the results of your bisect will shed more light
16:22 ask_ joined #parrot
16:25 lathos What's the opposite of "~~" ? "!~~" ?
16:25 pmichaud lathos: yes.
16:26 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.  :)
16:27 jonathan It's the double-hand-waving operator.
16:28 pmichaud it's the "I'm not hand-waving -- Look over there!"  operator.  :)
16:28 clunker3 joined #parrot
16:28 pmichaud jonathan: you have veto power over using git for rakudo, fwiw.
16:29 pmichaud i.e., "I don't want to use git"  ==>  we don't use git.
16:29 jonathan pmichaud: I'm pondering that.
16:30 * 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. ;-)
16:30 jonathan Since people are posting about how gits messianich properties carry onto Win32 as well though, it seems that may not be an issue.
16:31 jonathan 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.
16:31 PerlJam me too fwiw
16:31 jonathan However
16:31 jonathan I would be a lot less bothered if there were a (readonly is just fine) svn mirror.
16:32 jonathan That way only *committers* need to care.
16:32 jonathan (About git.)
16:32 jonathan And we keep the barrier to entry to just one version control system.
16:32 jonathan I don't know how technically feasiable an svn readonly mirror is.
16:32 pmichaud it's within the realm of possibility that spectest could move to git.
16:33 pmichaud (not rakudo's git repo, but a git repo)
16:33 pmichaud we'd still want liberal committer access, but that can be arranged.
16:33 moritz pmichaud: currently it's too much entagled with pugs tests
16:33 PerlJam maybe that's where a svn<->git gateway would be useful.
16:33 coke you could have a git-svn in front of pugs.
16:33 Infinoid http://blog.fallingsnow.net/2007/08/17/mai​ntaining-an-svn-mirror-directly-from-git/
16:33 shorten Infinoid's url is at http://xrl.us/becm3z
16:34 pmichaud it's too entangled with pugs tests?
16:34 pmichaud can't pugs use an approach similar to what rakudo does now for the spectests?
16:34 PerlJam according to the bisect, r35568 is the first bad rev for my miniparrot segfault
16:34 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.
16:35 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
16:35 Infinoid Whiteknight:
16:35 pmichaud moritz: we could move them into t/spec/unclassified, perhaps?
16:35 moritz pmichaud: if we move just t/spec/, we have lost revision history - if not, we stole pugs the tests
16:36 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
16:36 Whiteknight 'ello poppet
16:36 pmichaud moritz: we can keep revision history if moving to git
16:37 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.
16:37 Infinoid Whiteknight: yo.  any idea why r35568 could break pmc_new()?
16:37 Whiteknight Infinoid, what happened in r35568?
16:37 moritz pmichaud: I have to think a bit more about it. Proposal noted.
16:38 * 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
16:38 Infinoid 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.
16:39 Infinoid 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 ...
16:39 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
16:39 Whiteknight although it is a GC change, so maybe something is now getting prematurely recycled for some reason
16:40 Infinoid well, miniparrot does appear to accept the -G flag.
16:40 Whiteknight let me look into it
16:40 Infinoid PerlJam: what happens if you add that to the miniparrot command line?
16:40 Infinoid thanks
16:41 moritz PerlJam: yesterday you convinced me that a bidirectional mirror might not be a good idea :-)
16:42 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.
16:43 PerlJam Infinoid: what does -G do?  (no change, btw.  I still get a segfault)
16:43 Whiteknight -G turns off the GC
16:43 Infinoid it turns off the GC
16:43 Whiteknight and you're still getting a segfault without that? then it can't be a case of premature recycling
16:43 Infinoid yeah, so 0xdeadbeef came from somewhere else
16:45 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?
16:46 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
16:47 Infinoid scheduler->vtable is 0xdeadbeef
16:47 clunker3 joined #parrot
16:47 particle1 joined #parrot
16:47 Infinoid makes me wonder if interp->vtables[] has been corrupted
16:48 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.
16:48 Whiteknight if it's the scheduler pmc, it's a singleton. There's only one place it should be getting init'd
16:49 Infinoid ok
16:50 Infinoid might be worth breakpointing on get_new_pmc_header and taking a look at interp->vtables[]
16:51 Whiteknight the change in r35568 affected fixedpmcarray PMCs, and the interp->vtables[] array is not one of those
16:52 Infinoid interp->vtables[] is where the vtable pointers for new pmcs come from.
16:53 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
16:56 dalek r35594 | jkeenan++ | trunk (2 files):
16:56 dalek : Applying patch submitted by jimmy in TT#175.  POD corrections in two files.
16:56 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35594
16:58 Whiteknight okay, so the segfault happens at src\scheduler.c:82?
16:59 Whiteknight er, :83?
17:00 Infinoid yeah
17:00 Infinoid http://nopaste.snit.ch/15317
17:01 Whiteknight wow, quite the backtrace
17:01 Infinoid I don't think the code had much of an opportunity to do fancy stuff...
17:14 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:
17:14 dalek : [GC] try to fix an issue reported by PerlJam++ where a scheduler PMC's vtable is 0xdeadbeef after r35568, even with -G.
17:14 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35595
17:15 coke if you break at src/scheduler.c:82, does the pmc that is returned seem in order?
17:16 * coke catches up. nevermind.
17:17 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:18 * Whiteknight grumbles angrily about the stupid GC
17:24 dalek r35596 | jonathan++ | trunk/languages/perl6/src/builtins:
17:24 dalek : [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.
17:24 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35596
17:26 dalek r35597 | jonathan++ | trunk/languages/perl6/src/builtins:
17:26 dalek : [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.
17:26 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35597
17:26 pmichaud jonathan++ # I like the way those commit messages read.  :-)
17:26 jonathan A small patch...from a lot of effort. :-|
17:27 jonathan 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:28 pmichaud jonathan: excellent.  I actually think that's the way it should be.  :-)
17:28 pmichaud I suspect we'll see similar things for enums :-)
17:29 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 jonathan (Hacks on them rather than hacks elsewhere to work around them.)
17:29 jonathan How's plans for Cursor looking? I'm suspecting it won't be in for the January release?
17:29 davidfetter joined #parrot
17:33 tomyan left #parrot
17:38 Whiteknight PerlJam, Infinoid, anybody have any updates?
17:40 szabgab I tried    my $input = $*IN.readline; and it segfaulted in Rakudo, how can I read from STDIN?
17:42 coke szabgab: you sent that bug report to parrot-dev, neh? that should go to:
17:42 coke rakudoperl?
17:42 coke rakudobu?
17:42 coke rakudobug?
17:42 purl rakudobug is mailto:rakudobug@perl.org
17:42 coke (where it is now, it's not even in parrot's ticket queue.) Thanks.
17:43 szabgab coke: the segfault is one issue, but how do I read from STDIN?
17:43 szabgab and now I am confused, have you forwarded it already or shall I send it myself?
17:44 coke I have not.
17:44 coke 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.
17:45 dalek r35598 | jonathan++ | trunk/languages/perl6/t:
17:45 dalek : [rakudo] Add parameterized-mixin.t, which is currently heavily fudged (that should change tomorrow) but tests todays additions.
17:45 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35598
17:45 szabgab actuall I just upgraded parrot and now it works
17:45 coke there you go. =-)
17:45 szabgab so it might have been on my end, in the first place
17:46 szabgab but should not readline() alone work?
17:47 coke I don't know perl6, Iunno.
17:47 coke your code seemed reasonable, and segfaults are always bad, of course.
17:47 moritz szabgab: no
17:47 moritz szabgab: =$*IN to read from STDIN
17:51 szabgab moritz: thanks
17:53 alvar joined #parrot
18:11 dalek r35599 | Whiteknight++ | trunk/src/pmc:
18:11 dalek : [PMC] Change Object PMC so that morph vtable interfaces can be overridden (with acceptable results) from PIR
18:11 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35599
18:12 Whiteknight where in the test suite do we test vtable overrides?
18:12 Whiteknight or, do we not test them anywhere?
18:17 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:19 coke ?
18:19 coke ah. rather than having planet parrot aggregate blogs, you want it to aggregate posts?
18:20 coke I don't think we can do that.
18:23 moritz somehow I don't think we're facing a technical problem right now.
18:27 jhorwitz joined #parrot
18:28 braceta left #parrot
18:28 purl joined #parrot
18:35 Whiteknight if anybody has a moment, I could use some input on RT#41825
18:36 kj check your email ;-)
18:36 Whiteknight w00t
18:36 kj but I'm just standing on the sideline in these issues, so not much worth.
18:36 coke Whiteknight: we removed those from PIR deliberately.
18:37 coke 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
18:38 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.
18:38 coke (except morph apparently.)
18:38 coke doesn't the morph opcode already do that lookup before it hits the vtable?
18:39 coke yah.
18:39 coke so from C, this is still doable, and probably will be through 1.0
18:39 coke since the vtable /is/ visible from PIR, however, I recommend doing #2.
18:40 coke (update the vtable to take a string>)
18:40 Whiteknight yeah, the morph opcode takes a string. The morph vtable takes an intval
18:40 Whiteknight okay, I'll see if I can do that
18:40 PerlJam Weren't the stringy names being dropped in favor of keys too?
18:43 coke PerlJam: ayup. included that in my reply.
18:44 coke 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
18:45 coke No, I'm saying we should change the vtable.
18:45 Whiteknight so in C it's still "VTABLE morph(INTVAL type)"
18:45 coke Having the override take a different type is not a good idea, IMO.
18:45 * coke responded to your email, btw.
18:47 Whiteknight urg, there are a lot of morph calls throughout parrot. All of them are going to need updatin'
18:48 kj if you add the new variant, it'll be easier without breaking anything
18:48 kj and then after updating everything, remove the old one
18:50 Whiteknight So like create a new morph_from_string?
18:51 kj eh, I was thinking ops. I guess using the same name, 'morph' is not possible for vtable methods
18:51 kj mmm
18:52 coke yah, I don't think that's possible.
18:52 coke VTABLE_morph ... == ?
18:53 coke just put in a notice and do it post 0.9.0
18:53 kj maybe could be done in a branch?
18:53 kj a short-lived one
18:55 riffraff joined #parrot
19:02 particle joined #parrot
19:02 particle pmichaud: ping
19:06 Whiteknight that's probably what I will do. Do I need like Allison's permission to make a change like that?
19:07 * particle wonders what he missed. irc log?
19:07 particle feh.
19:07 particle2 joined #parrot
19:08 particle Whiteknight: we need a new morph. create a branch and start working on it before approval
19:08 particle use the successfully working branch to plead your case :)
19:09 particle just don't merge it until approval (unlike the stm branch you snuck into trunk)
19:09 Whiteknight roger wilco, over and out
19:09 Whiteknight I asked Allison, she said I could do it!
19:09 particle hrmm, last i spoke to her she said it should undergo a deprecation cycle
19:09 particle well, then, you're out of trouble.
19:10 particle the "mom said i could do it!" defense still works.
19:10 davidfetter there's a hilarious condom commercial with that as a them
19:10 davidfetter +e
19:10 purl 2.71828182845905
19:12 dalek r35600 | simon++ | branches/strings/pseudocode (2 files):
19:12 dalek : This is the first part of NFG normalization support.
19:12 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35600
19:16 Theory joined #parrot
19:26 coke particle: yah, I don't know why she let STM get in. <shrug>
19:28 particle well, hey, it's a smaller release now. that means it's more stable, and has fewer bugs.
19:32 pmichaud particle: pong
19:34 jhorwitz pmichaud: after particle times out, can you take a gander at RT #62410?
19:34 particle :P
19:35 particle 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.  :)
19:36 * particle is multitasking
19:36 pmichaud jhorwitz: I'm guessing that breakage is due to the type registry stuff that jonathan put in.
19:36 pmichaud particle: I'd go for PCT::Commandline::Parser
19:36 particle i know that name is too long, but shall it live in HLL... ok
19:36 jhorwitz ooooh, i can blame jonathan.  i haven't done that in a while....
19:36 pmichaud or something simple like that.  I wouldn't integrate it as part of HLLCompiler
19:37 pmichaud i.e., I think it's worth being a standalone module.
19:37 pmichaud it can be part of PCT, yes.  But I even think it's worth being standalone in runtime/parrot/library/
19:37 coke particle: is this going to replace getopt?
19:37 particle right now there are methods in HLLCompiler for it, like 'process_args'
19:37 particle coke: that's the idea, at least for PCT
19:37 pmichaud HLLCompiler would probably evolve to use that library.
19:37 particle ok, figured. thanks.
19:38 particle i'll use p6meta etc
19:38 pmichaud that's fine, you can use P6object if you wish :-)
19:39 coke particle; I just hate to see timtowtdi in parrot.
19:39 Whiteknight joined #parrot
19:41 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
19:48 particle my top priority is making it work according to S19
19:49 particle i don't know how 'meta' i'll go with the interface yet, to make it do any flavor of cmdline parsing
19:52 lathos OH MAN THIS STUFF HURTS MY HEAD.
19:52 coke better you than us.
19:54 Whiteknight much better
19:55 Whiteknight I'm actually very interested to see how the strings system is going to turn out in the end
19:56 Whiteknight 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.
19:56 Whiteknight yeah, I can imagine. Sounds a lot like the GC work I've been doing
19:56 Whiteknight you fix one thing, you break three others
19:56 lathos My current model has the character-length of a string changing if you look at it funny.
19:57 * moritz looks funny at lathos' strings
19:58 jhorwitz quantum strings
20:02 particle1 joined #parrot
20:07 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
20:07 coke me too. I write my code in cold fusion, what's your excuse?
20:08 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 Whiteknight perl would have been much better
20:09 mberends joined #parrot
20:13 * coke assigns a partcl to ticket to mdiep and crosses his fingers. =-)
20:14 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:15 particle1 it's nice to see tcl under development again
20:15 particle1 i guess that means parrot is a slower-moving target
20:17 Coke slower, yes. =-)
20:32 dalek r35601 | kjs++ | trunk/compilers/pirc/src (2 files):
20:32 dalek : [pirc] don't store duplicate keys.
20:32 dalek : + remove cpp comments.
20:32 dalek : + add STRING * variant to constant struct.
20:32 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35601
21:01 riffraff joined #parrot
21:02 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:03 lathos I can't work out how to do it in P6...
21:04 PerlJam .meth()
21:05 PerlJam (I have no idea if that works in NQP)
21:05 riffraff eh in fact :)
21:05 riffraff it seems that nqp objects do not have a 'self' set
21:05 riffraff so as long as you call $foo.bar it works, but .bar has no way of knowing how to call something else
21:06 riffraff oh well, I'll usea sub :)
21:06 pmichaud even .meth in Perl 6 doesn't mean "self.meth"  :-)
21:06 PerlJam pm: it does if $_ is self  :)
21:06 pmichaud I don't think that NQP sets a self yet.  We haven't needed one.  Arguably it should do that, though.
21:06 pmichaud We could probably add it to NQP w/o too much difficulty.
21:09 contingencyplan joined #parrot
21:09 riffraff by the way: why people keep using $?BLOCK and @?BLOCK in parrot languages' action.pm ?
21:09 riffraff it seems to me that the twigil is useless, $BLOCK would be enough
21:09 particle it matches p6 syntax
21:10 particle 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
21:10 riffraff ah I see
21:25 pmichaud $? is a compile time var.  Since we're writing compilers, it make sense to use compiler time variables.  :-)
21:26 pmichaud s/compiler time/compile time/
21:26 pmichaud Andy++ # http://perlbuzz.com/2009/01/hooray-f​or-the-circling-pundit-vultures.html
21:26 shorten pmichaud's url is at http://xrl.us/becodd
21:26 Andy Thanks
21:26 pmichaud Merlyn++ 's reply to the original article is also sweet.
21:29 particle1 joined #parrot
21:48 rdice joined #parrot
21:48 GeJ Good morning everyone
21:50 Infinoid hi GeJ
22:01 Whiteknight joined #parrot
22:10 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 :)
22:10 Infinoid Whiteknight++ for looking at it tho :)
22:11 Andy That's why I posted it.
22:11 Infinoid and Andy++ for giving us a rallying cry
22:11 Andy Thanks.
22:12 Andy I am glad I sat on Piers' column.
22:12 Andy I didn't have anything to say about it.
22:12 Andy and now it just fit nicely ther.e
22:12 dalek r35602 | Whiteknight++ | trunk/src/pmc:
22:12 dalek : [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
22:12 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35602
22:12 Whiteknight thanks Infinoid
22:14 dalek r35603 | simon++ | branches/strings/pseudocode (4 files):
22:14 dalek : Clarification of the grapheme/char distinction in ParrotNative.
22:14 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35603
22:16 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?
22:16 pmichaud Casan: I'm putting that together now.
22:16 Coke *seamlessly
22:16 pmichaud However, I have publicly commented that Rakudo would likely have early adopter releases in early 2009.
22:17 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:18 Whiteknight rakudo really is coming together remarkably quickly
22:18 Coke ^_o
22:18 Whiteknight it's quite inspirational, from my point of view
22:19 pmichaud Casan: (leaving the nest) -- thanks, now the devil is in the details.  :-)
22:20 Casan yeah, threading careful is key, but must be decisive at some point.
22:27 TimToady joined #parrot
22:28 dalek r35604 | Whiteknight++ | trunk (2 files):
22:28 dalek : [t] add a test for the new morph vtable override (actually, it's going to be for all vtable overrides, eventually)
22:28 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35604
22:30 Infinoid pmichaud: thanks for translating my journal comment to the list, your response makes a lot of sense
22:30 Infinoid having rakudo build parrot seems like a good solution from the perspective of developing rakudo.
22:31 pmichaud Infinoid: thanks for the comment and ideas.
22:31 pmichaud Infinoid: I think it might also point a way for us to be able to use git even if Parrot remains svn.
22:31 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?
22:32 Infinoid 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.
22:32 Infinoid yes, absolutely.
22:32 pmichaud all we would have left to figure out is a good way to handle the spectests (which are still svn)
22:33 pmichaud I don't see an issue with a "make rakudo" or "make partcl" target.
22:33 pmichaud 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.
22:34 pmichaud 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.
22:34 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.
22:35 pmichaud (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
22:35 lathos Shouldn't it be interpreters/rakudo? (Only half serious - the language is Perl 6, so perl6 is a good name for it.)
22:36 Infinoid s/libraries/languages/
22:36 moritz lathos: it's not an interpreter
22:36 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.
22:37 pmichaud I don't know that we've had an official decision about where Parrot will look for its compilers.
22:37 pmichaud latest I heard was   runtime/parrot/languages/
22:37 pmichaud but that was September 2008.
22:38 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
22:39 dalek r35605 | Whiteknight++ | branches:
22:39 dalek : creating a new branch to update the morph vtable method to use STRINGS instead of INTVALS for the type
22:39 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35605
22:39 lathos languages/rakudo is clearly bogus; the language is not called "rakudo".
22:39 pmichaud lathos: that's a reasonable point
22:39 cotto Whiteknight, ping
22:39 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 #parrot
22:40 Whiteknight cotto pong!
22:40 cotto There's a little gc code that uses PMC_struct_val (two instances in mark_sweep.c).
22:41 cotto Is that something you could quickly store elsewhere?
22:41 Whiteknight you want I should bust it's knee caps or sometin? </Al Capone>
22:42 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/
22:42 Whiteknight cotto, I could have it moved, yes. But I need to figure out where to move it to
22:42 Whiteknight I'l have to talk to chromatic/allison about it, since they're doing GC cleanup work now
22:42 cotto no big rush
22:42 cotto ok
22:43 cotto should I file a tt?
22:43 Whiteknight okay
22:43 Whiteknight yeah, do that so I don't forget
22:43 pmichaud Coke:  we've done that for the sources, yes, but I mean where the runtime files should live.
22:44 pmichaud 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:46 PerlJam pm: where ever the parrot-install-language program puts it  :)
22:46 Limbic_Region joined #parrot
22:47 pmichaud PerlJam: "Oh!  Why didn't I think of that?"  :-P
22:47 cotto Whiteknight, TT #178
22:51 On joined #parrot
22:51 dalek r35606 | Whiteknight++ | branches/morph_pmc_type/src:
22:51 dalek : [morph_pmc_type] add a 'morph_string' type as a temporary replacement for 'morph'
22:51 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35606
22:53 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:54 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
22:55 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
22:56 Casan B) cd /usr/ports/lang/parrot && make install clean && cd /usr/ports/lang/rakudo....
22:56 namenlos joined #parrot
22:56 Infinoid indeed.  I think A) is more straightforward for new users.
22:56 Casan and keep it all update using portupgrade -rA
22:57 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 :)
22:57 Infinoid I just think it would be nice if rakudo's Makefile itself knew how to do it
22:57 Casan Infinoid: through the vcs strategy is the one to crack first
22:58 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//
22:58 Infinoid worst case scenario: skip the vcs entirely, the Makefile rule wgets and unpacks a parrot tarball.
22:58 Coke lets use language(s) ; tracks with our use of HLL
22:58 Casan Infinoid: you mean defining in the rakudo makefile that it is to install parrot?
22:59 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?
22:59 Coke the path to perl6.pbc
23:00 Coke 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
23:00 pmichaud Coke: my question is "what is the default search path" that finds perl6.pbc ?
23:00 Infinoid Casan: the next-to-last post on http://groups.google.com/group/perl.perl6.co​mpiler/browse_thread/thread/e8b52511384fb75e#
23:00 pmichaud last I heard it would be parrot/runtime/languages/
23:00 shorten Infinoid's url is at http://xrl.us/becoxv
23:00 Casan Infinoid: thnx for clarifying
23:00 pmichaud but Parrot doesn't implement that yet.
23:08 Infinoid not knowing anything about the issues or code involved, that sounds like an easy hack
23:08 Infinoid has pdd30 landed yet?
23:09 pmichaud I don't think it has.
23:09 pmichaud I could be wrong about that.
23:10 namenlos one question: why are the parrot and perl6 repositories going to be separated?
23:11 namenlos or should i ask this on #perl6?
23:11 PerlJam namenlos: though there is a dependency there, they have separate lives.
23:12 namenlos PerlJam: ok, then i will take it as it its - maybe i am not deep enough into this parrot/perl6 stuff...
23:13 Infinoid I think they just got tired of me committing codingstd tweaks all the time.
23:13 wolverian joined #parrot
23:13 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 #parrot
23:14 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.
23:14 namenlos PerlJam: lathos has an argument ;)
23:15 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
23:15 moritz even though I moved out, I'm still supported financially by my parents
23:15 namenlos but i think i got it, that they want to be some kind of separated...
23:15 Limbic_Region it worked extremely well with pugs
23:15 lathos Also, all analogies suck.
23:15 PerlJam indeed
23:15 Limbic_Region lathos - that's like saying....oh wait, nevermind
23:16 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
23:16 lathos I haven't heard what the actual reason for doing it is.
23:16 Limbic_Region it had been discussed a number of times in the past
23:16 moritz lathos: I think there are many factors, for example communication mismatch
23:17 moritz ... different priorities ...
23:17 lathos There certainly is a communication mismatch. Nobody seems to be able to communicate why they need to do this!
23:17 lathos What communication mismatch? What are the symptoms? What are the practical problems this is trying to solve?
23:17 Limbic_Region oh, salutations all btw
23:18 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 clunker3__ joined #parrot
23:18 moritz that's not the only reason (it had been planned for a while), but it sure is a trigger
23:19 lathos Yeah, I'm still waiting to hear what the reason is, though, and what problem it's trying to solve.
23:19 lathos And if these problems are so great, how do they get fixed by a simple "svn switch" command?
23:21 namenlos anyone could give me a hand making a crux parrot port?
23:21 namenlos http://dpaste.com/109595/ this are the commands i use to build it
23:21 particle joined #parrot
23:22 lathos Looks good.
23:22 purl O_O
23:22 namenlos but still parrot searches for PCT.pbc in the diretory it was built...
23:22 namenlos strace is here: http://dpaste.com/109596/
23:22 lathos Ah. Yeah, I don't think make install actually works yet. :(
23:22 lathos It's on the list.
23:22 namenlos lathos: no, you got to use reallyinstall
23:23 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
23:24 namenlos if i then use the installed perl6 binary or any other pbc i get the following: http://dpaste.com/109598/
23:24 lathos That's right.
23:24 lathos This is because installing doesn't work yet.
23:24 namenlos nah...
23:24 lathos Yuh.
23:25 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 namenlos hm, i could mess with sed :D
23:25 moritz namenlos: btw. parrot recommends icu and libgmp
23:26 moritz namenlos: there's a branch for working on the installer, maybe you can can try it there, instead of trunk?
23:26 moritz pdd30_install or pdd30install_stage4
23:27 namenlos moritz: i am using the 0.8.2 release atm
23:28 namenlos 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. :(
23:29 moritz icu: Unicode functions: gmp: bigint support
23:31 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 namenlos that sucks
23:31 purl The rock is now off.
23:33 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 - https://trac.parrot.org/parrot/ticket/123
23:34 kid51 joined #parrot
23:34 kid51 messages
23:35 namenlos lathos: thx. so let's hope for 0.9
23:37 gravity joined #parrot
23:37 namenlos thanks all for your help. i will go to bed. gn8
23:39 ask_ joined #parrot
23:40 pmichaud actually, I see it that Parrot is moving out of the Rakudo repository.  :)
23:42 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.
23:42 Casan ref?
23:42 purl well, ref is an opaque value
23:42 pmichaud Rakudo has always been expected to stay with perl.org or something similar.
23:42 jonathan Rakudo is a Perl project, thus it'd make sense for it to stay hosted by perl.org.
23:43 Infinoid and supported by TPerlF
23:43 particle2 joined #parrot
23:43 particle3 joined #parrot
23:43 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. :-)
23:44 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 #parrot
23:45 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.
23:45 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.
23:45 Casan s/og/or
23:45 pmichaud jonathan: okay, great.  Mainly I just need to know what you personally are comfortable with.
23:46 cotto pmichaud, right.  I mean which make target can I use to hit the PMC code?
23:46 pmichaud cotto:  "make test"
23:46 purl i guess "make test" is possessed!
23:46 jonathan pmichaud: I need to actually *try* using git before I can sensibly feed in to that one.
23:46 pmichaud jonathan: there's already a testing git setup for rakudo -- obra++ set it up
23:46 pmichaud just a sec
23:46 jonathan pmichaud: I'm not exactly a fan of branching on svn...it's always got in my way.
23:46 jonathan pmichaud: But my concern is more for others than me - as I mentioned earlier.
23:46 jonathan Oh, that's awesome.
23:47 pmichaud http://github.com/obra/rakudoper​l---test-conversion/tree/master
23:47 jonathan Thanks.
23:47 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.
23:47 jonathan Will look tomorrow (too tired and beer right now).
23:47 pmichaud so we (you and I) can use that to test our newfound git skills :)
23:47 jonathan er. beer isn't a verb. :-)
23:48 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. :-)
23:48 pmichaud same here.  :)
23:48 pmichaud and yes, I'm more concerned about newcomers to rakudo than me personally -- but developers have to remain productive also.
23:48 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. ;-)
23:48 pmichaud "nom?"
23:49 jonathan pmichaud: Beer is pivo, there's a bunch of verbs ending "ovat", so I constructed "pivovat" :-)
23:50 * jonathan is enjoying learning a new natural language, as well as Perl 6.
23:51 pmichaud excellent.
23:51 jonathan I'm still not sure which is harder. :-|
23:51 pmichaud I look forward to "Worthington's concise dictionary of the Slovak language" :-)
23:51 jonathan I've found another tricky issue with parametric roles. :-|
23:51 pmichaud I bet there are quite a few tricky issues with parametric roles.
23:52 jonathan role Foo[::T] { method foo(T $x) { ... } }
23:52 jonathan No prizes for guessing why this doesn't work out. :-(
23:52 pmichaud T's not lexical there?
23:52 jonathan Indeed. We're building the signautre in a :load :init.
23:52 pmichaud so why doesn't it work out?
23:53 jonathan Because the signature is built in an :init :load.
23:53 dalek r35607 | Whiteknight++ | branches/morph_pmc_type/src (6 files):
23:53 dalek : [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
23:53 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35607
23:53 pmichaud the signature of foo?
23:53 jonathan Yes, the signature of foo is.
23:53 jonathan We look up the type T at the time we build the signature, right?
23:54 pmichaud but looking up T is (or _was_)  put into a block.
23:54 pmichaud no, it had to be done as a block.
23:54 jonathan Oh.
23:54 jonathan OK, I know that examples like the above aren't working.
23:54 pmichaud because that's the only way that SIGNATURE_BIND could get the correct T.
23:54 pmichaud where clauses also have to be put in blocks, for similar reasons.
23:54 jonathan If we do the lookup per binding (which you're right - we must), then there must be another reason it doesn't work. :-|
23:54 jonathan OK, I'll debug tomorrow
23:55 jonathan But you're right. Type capture could never work.
23:55 pmichaud yes, that was something I ran into in the rvar branch.
23:55 jonathan :-)
23:55 jonathan Fun stuff, hey? :-)
23:55 pmichaud it is, actually.  :-)
23:55 pmichaud Perl 6 gives us lots of daily puzzles.
23:55 jonathan Which is why it's the most interesting project I have.
23:55 TimToady s/sudoku/rakudo/
23:56 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)
23:56 jonathan Unpurposefully.
23:56 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.
23:57 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.
23:58 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.
23:58 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.
23:59 jonathan (where it = a working Rakudo)
23:59 pmichaud agreed.  That will happen one way or another.

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

Parrot | source cross referenced