Parrot 0.9.1 Released | parrot.org/ | 451 RTs left!
Set by moderator on 24 February 2009.
Tene NotFound: could the makefile just use ../../parrot_config instead? 00:00
Tene not big on makefile-fu
NotFound Tene: yes, but I want to let open the possibility to build it in other places
Tene kk 00:01
00:09 AndyA joined
dalek rrot: r37010 | jkeenan++ | branches/deprecate_tqueue:
Creating deprecate_tqueue in svn.parrot.org/parrot//branches
 00:27
cotto Do I need to make any Makefile modifications if one PMC depends on another's header? 00:31
chromatic Yes. 00:39
cotto Care to elaborate? 00:40
chromatic It's easy. Add that header to the rule for the PMC's .o file after the colon. That's where dependencies go. 00:42
I'm looking for an example.
$(SRC_DIR)/call/pcc$(O) isn't a PMC, but it's an .o file with a PMC header dependency. 00:43
src/pmc/null$(O) is a better example. It depends on the Default PMC's header.
cotto chromatic++ #helping me not break -j 00:44
What needs to be edited to update that part of the Makefile? 00:49
chromatic config/gen/makefiles/root.in
purl config/gen/makefiles/root.in is what generates parrot/Makefile
chromatic ... I think. There may be something in one of the Config libs though.
cotto It looks like the code is smart enough to look at the .pmc files and dtrt. 00:51
confirmed 00:52
chromatic That's good.
01:12 dukeleto joined 01:15 ilia joined
dalek rrot: r37011 | NotFound++ | trunk/examples/embed/lorito.c:
[examples] add -e option to lorito
 01:16
ilia so i'm running make spectest on the latest code and i'm getting: 01:19
Scope not found for PAST::Var '@INC'
is this bad? 01:20
pmichaud it's unexpected. (I'm assuming you mean in Rakudo.)
ilia oh yes Rakudo
pmichaud Someone else reported a similar problem earlier.
ilia it was working a few commits ago
pmichaud you might need to update your version of Parrot with --gen-parrot 01:21
(assuming that's the way you obtained parrot in the first place)
ilia i got parrot from svn
pmichaud sometimes the head version of parrot will break Rakudo.
or perhaps your version of parrot isn't recent enough 01:22
ilia i compiled parrot HEAD
NotFound pmichaud: there is warning building rakudo on head that looks like a pontential problem
And makes it fail buildng with c++ 01:23
ilia :(
pmichaud NotFound: okay. Rakudo doesn't guarantee that it works against Parrot head.
We only aim to work with whatever version of parrot is in build/PARROT_REVISION
NotFound I've been unable to find the problem because of pmc2c messing with line numbers. 01:24
ilia ok i will try parrot 0.9.1 01:26
pmichaud ilia: better is to simply download rakudo, and then run perl Configure.pl --gen-parrot
that always gets the "correct" version of Parrot for whatever copy of Rakudo you have.
ilia pmichaud: i can do that for head rakudo?
pmichaud ilia: yes. 01:27
01:27 TiMBuS joined
ilia interesting 01:27
is buildbot still running the tests?
i'm setting up a Hudson job for Rakudo... is that useful to anyone 01:31
dalek kudo: 2cf2dfe | pmichaud++ | README:
Update README with latest news on building Rakudo.
 01:38
shorten dalek's url is at xrl.us/behkez
ilia dalek: approved :) 01:43
wait, is dalek a bot too?
pmichaud yes, dalek is a bot 01:44
ilia haah
pmichaud dalek reports on updates to parrot, rakudo, websites, etc.
afk for a while. 01:45
dalek kudo: e6b7133 | pmichaud++ | (3 files):
Update some references to Parrot, Perl, and/or Rakudo.
 01:46
shorten dalek's url is at xrl.us/behkfw
ilia i am still getting Scope not found for PAST::Var '@INC' 01:48
using the `perl Configure.pl --gen-parrot` method
pmichaud ilia: what platform, compiler, etc.? 01:49
ilia os x, perl 5.8.9
pmichaud what revision number does "parrot/parrot_config revision" say? 01:50
ilia 37000
pmichaud you might also need to do "make realclean" and run the perl Configure.pl line a second time (it won't rebuild parrot, so it should go quickly)
if that doesn't help, then perhaps report the details to rakudobug@perl.org 01:53
ilia damn still persistent 01:55
pmichaud I'm guessing it must be an osx issue, then. 01:57
do you get the error with 'make test'?
ilia ye[ 01:58
yes
pmichaud very odd.
ilia i didn't get these errors just a few hours ago
it started happenning after a git pull
dalek rrot: r37012 | jkeenan++ | branches/deprecate_tqueue (9 files):
Implement deprecation of tqueue PMC as per trac.parrot.org/parrot/ticket/192.
 01:59
pmichaud does it happen for all tests or just specific ones?
ilia pmichaud: all
pmichaud that's very bizarre.
I can't find anywhere that @INC is really being used in a PAST::Var 02:00
well, I need to run -- file it as a rakudobug and hopefully someone else can take a closer look at it. 02:01
02:03 Theory joined
chromatic Maybe there was a conflict, like when you get a .orig and .rej file in a patch fuzz problem. 02:03
ilia git conflict? 02:04
u suggesting i git clone again?
chromatic Or just look for any local modifications. 02:05
ilia i checked git status, nothing special
chromatic That was my only other guess. 02:08
I can't reproduce that, as of a recentish Parrot and current Rakudo. 02:14
ilia i am trying to reproduce again 02:16
from the beginning
02:18 Andy joined
ilia ye here it is again 02:19
rg must be an osx thing. i can't reproduce it either with current parrot, current rakudo. 02:20
ilia i sent a bug 02:21
how do i roll back to a revision in git 02:23
git reset? 02:26
chromatic I don't know. 02:29
ilia looks like `git reset --hard f1f722edd9ee6cccfbf7cb0fbbe08188b7b8a382`
nopaste "rg" at 93.104.124.78 pasted "compare error message to queried message instead of fixed in os.t" (18 lines) at nopaste.snit.ch/15722 03:07
pmichaud generally I just do a new clone when I want to make sure I have a clean copy.
rg chromatic: could you please look at nopaste.snit.ch/15722 and possibly commit it. it fixes a test failure on solaris.
pmichaud for those looking for a rakudo release tonight -- it's likely not going to happen until tomorrow. My cold is getting steadily worse :-( 03:08
ilia pmichaud: get some sleep :)
pmichaud rest is becoming more important than release :)
ilia pmichaud: try oregano oil
03:25 jimmy joined
chromatic rg, that test fails that way on Solaris? 03:26
rg it fails because the message on solaris is 'Not owner' (which i find a bit strange, but that's solaris for you). 03:29
the errno is the same (EPERM)
cotto A good hair stylist can help you with that.
rg i guess it would also fail if you run the test with a different locale on any platform that has localized error messages, which would be fixed by the patch aswell. 03:31
chromatic Okay, good to know. I *thought* I had the same error text as that from link() in the OS PMC, but that uses strerror now.
rg that *is* the link test 03:32
chromatic I mean, I read the PMC when I wrote that test.
How do we know that the errno for that is *always* 1 across platforms? 03:33
rg oh you mean the message was fixed in the pmc?
chromatic Yes.
03:33 Theory joined
rg we don't know that. if you know how to get to EPERM, that would be preferable. 03:34
chromatic We probably need to generate them as constants somehow. 03:35
03:35 janus joined
chromatic That sounds like a configure probe. 03:39
rg does perl have a list or errno constants? otherwise you'd have to parse errno.h 03:40
sounds almost like it might be easier with c
chromatic It's almost trivial in C. Just write out a .pasm file. 03:41
dalek rrot: r37013 | jkeenan++ | trunk/PBC_COMPAT:
Wordspaces used where hard tabs were needed to delimit columns; change to hard tabs.
rrot: r37014 | jkeenan++ | branches/deprecate_tqueue/PBC_COMPAT:
As in trunk, change multiple wordspaces to hard tabs to delimit columns.
 03:46
chromatic rg, I worked around it in a different way. 03:58
I'll file a ticket that we need the POSIX errno constants generated somehow. 03:59
dalek rrot: r37015 | chromatic++ | trunk (2 files):
[PMC] Improved the "Can't hardlink a directory unless you're root" test of the

  (reported by Rolf Grossmann).
This test may fail if you run it as root. Try not to do that.		 04:01
rg ah, you coded back a string to match. 04:03
chromatic I figured the error message for that could be clearer. 04:05
rg there is actually an Errno.pm in perl. 04:06
could we use that to generate a list of constants or should we already try not to introduce new dependencies on perl. 04:07
?
chromatic It's probably better not to generate new dependencies on Perl. 04:10
We want to remove them eventually.
cotto It's going to be a project to get Perl out of the build process. 04:15
rg ok, i now have a 76 line perl script to generate a 328 c file that will generate a 101 line pasm file with the errno values. any takers for anything? 04:22
the fixed os test works. thanks chromatic++ 04:23
ok, time to get some sleep. i'll check the logs ;) 04:30
04:48 jimmy left 05:22 elmex_ joined 05:32 dukeleto joined 05:37 masak joined 05:44 Theory joined 05:52 eternaleye joined 06:04 Tene_ joined
cotto seen kj 06:49
purl kj was last seen on #parrot 8 days, 5 hours, 59 minutes and 3 seconds ago, saying: good night all [Feb 18 00:50:14 2009]
06:52 Fayland_logger joined
cotto crosses fingers that his upcoming huge commit doesn't break anything 06:56
06:56 szabgab joined 07:00 dukeleto joined
dalek rrot: r37016 | cotto++ | trunk (32 files):
[PMC] replace PMC_struct_val and derivatives with ATTR accessors for the Sub PMC
 07:01
rrot: r37017 | cotto++ | trunk/include/parrot/sub.h:
[.h] minor tidying
 07:09
07:20 uniejo joined 07:52 dukeleto joined
dukeleto ilia: get reset HEAD^ 07:53
GeJ cotto: well, build and test after a realclean didn't show any sign of b0rkness. 07:55
07:58 namenlos joined 08:08 jimmy joined
jimmy cotto++, all passed on mswin32 08:15
08:21 mikehh joined
cotto That's good to know. Thanks jimmy. 08:25
I'll sleep well.
Although I generally sleep well when I break the build, too. 08:28
jimmy good night. 08:33
mikehh Build ok at r37017 08:40
smoke smolder.plusthree.com/app/public_pr...ails/18353 reports 100%
shorten mikehh's url is at xrl.us/behmc2 08:41
mikehh however t/pmc/exceptionhandler.t (Wstat: 11 Tests: 6 Failed: 0)
Parse errors: Bad plan. You planned 8 tests but ran 6 08:42
I have been getting this for a few days
jimmy yes, it's 6 08:43
mikehh: please create a ticket for it. 08:47
mikehh ok - got to take the kids to school - will do so whrn I get bavk 08:49
back
t/pmc/exceptionhandler.t passed with 8 tests at r36930 but only 6 at r36946 09:21
jimmy mikehh: welcome back, could you create the trac ticket? 09:31
mikehh doing that now 09:33
jimmy mikehh++ 09:35
dalek kudo: 2758f79 | (Moritz Lenz)++ | tools/ (2 files):
[tools] use fake executable in autounfudge and test_summary
 10:05
shorten dalek's url is at xrl.us/behme6
dalek kudo: e4bd268 | (Moritz Lenz)++ | t/spectest.data:
we now pass sub-calls.t, add to spectest.data
 10:21
shorten dalek's url is at xrl.us/behmfk
10:43 jimmy left 10:55 mikehh joined 11:44 AndyA joined 11:45 bsdz joined
bsdz an issue buliding parrot from svn with MSVC. after running Configure.pl, nmake gives "fatal error U1086: inference rule cannot have dependents". any one come across something similar? 11:47
11:53 jimmy joined
jimmy bsdz: could you create a ticket for it? 11:53
bsdz i'll try
11:59 gaz joined 12:10 magnachef joined 12:15 PacoLinux joined 12:25 masak joined 12:28 PacoLinux joined 12:32 rg1 joined 12:34 PacoLinux joined 12:37 cas joined 12:42 particle joined 12:49 PacoLinux joined 12:55 AndyA joined 13:02 PacoLinux joined 13:08 PacoLinux joined 13:15 PacoLinux joined 13:18 bsdz left 13:23 PacoLinux joined 13:29 PacoLinux joined 13:41 particle joined 13:46 gryphon joined 13:49 PacoLinux joined 13:57 PacoLinux joined 14:01 jimmy joined 14:10 namenlos joined 14:13 mikehh joined 14:15 bsdz joined 14:17 PacoLinux joined 14:31 PacoLinux joined 14:44 PacoLinux joined 14:53 PacoLinux joined 14:59 jimmy_ joined 15:12 Andy joined
dalek kudo: d0739a3 | (Patrick R. Michaud)++ | docs/spectest-progress.csv:
spectest-progress.csv update: 314 files, 7041 passing, 0 failing
 15:32
shorten dalek's url is at xrl.us/behm3b
dalek kudo: e9a06c1 | (Andy Lester)++ | README:
Added explanation of how to get Rakudo without git. Minor punctuation fixes.
 15:45
shorten dalek's url is at xrl.us/behm4i
dalek kudo: 68b39d2 | pmichaud++ | (2 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
 16:16
kudo: d46df75 | pmichaud++ | build/Makefile.in:
Add some more dependencies into the Makefile.
shorten dalek's url is at xrl.us/behm6v
kudo: f0a9a5d | pmichaud++ | docs/compiler_overview.pod:
Some minor documentation updates.
shorten dalek's url is at xrl.us/behm6x
dalek's url is at xrl.us/behm6z
dalek kudo: d2cd0fb | (Andy Lester)++ | CREDITS:
updated my info. Normalized fields in some others
shorten dalek's url is at xrl.us/behm63
dalek kudo: 8b9b21e | (Andy Lester)++ | build/Makefile.in:
config/ directory should not be checked with critic
shorten dalek's url is at xrl.us/behm65
dalek kudo: c173544 | (Andy Lester)++ | build/gen_junction_pir.pl:
Check return code of close
shorten dalek's url is at xrl.us/behm69
dalek kudo: af9452e | (Andy Lester)++ | t/harness:
use lexical filehandles, not global; Check for .git dirs as skippable; modernizations
kudo: 1951708 | (Moritz Lenz)++ | t/harness:
[t/harness] remove variable $recurse
shorten dalek's url is at xrl.us/behm7b
shorten dalek's url is at xrl.us/behm7d
dalek kudo: 5e410bb | pmichaud++ | (4 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/behm7f
pmichaud moritz: you _are_ running tests prior to accepting the commits, yes? 16:17
moritz pmichaud: yes; which is why I added 1951708d1d6d0e635285457ba96020f6dd5ac6a8
I didn't run full spectests because no actualy compiler changes were made 16:18
but I verified that reconfigure + make + make spectest work
pmichaud okay. We particularly need to check that reconfigure with --gen-parrot works, since it's the official build sequence.
moritz I put them into a branch first (merge_petdance) and tested the bunch of them together
actually the integration branch feature is quite neat 16:21
pmichaud yes, I'll probably play with that shortly.
when do commits disappear from the fork queue? 16:22
when they're applied to a branch, or when they merge back to master?
moritz the former
pmichaud so, if you apply a commit to an integration branch, but then abandon the branch, the commit is "lost" from the queue?
moritz yes 16:23
pmichaud hmmm, that might not be so good.
moritz not 100% sure though
pmichaud we might end up deciding not to use the fork queue. 16:24
is there a way to get a list of files being managed by git? 16:31
i.e., to know which files are part of the repo?
ah, git ls-files 16:32
16:36 Tene joined 16:45 Theory joined 16:56 khisanth_ joined, chromatic joined 17:03 namenlos joined 17:16 allison joined
allison wading her way through 700 OSCON proposals 17:16
davidfetter pick mine! ;) 17:19
Andy allison: Are you following the Rakudo naming? 17:23
I'm so excited.
pmichaud allison probably isn't on #perl6 :-)
Andy Each code name for each Rakudo name will be a city with a Perl Mongers.
17:23 contingencyplan joined
Andy and PM groups get to duke it out who gets naming rights. 17:24
davidfetter lobbies for Oakland.pm
Andy davidfetter: You have a while. :-)
allison Andy: sounds great!
davidfetter are we talking about the squared circle for this duking business?
Andy davidfetter: One can only hope.
Austin and Bratislava are already pegged.
But C is up for grabs.
Chicago and Copenhagen can duke it out.
davidfetter "two mongers enter. one monger leaves!"
PerlJam sounds like a good thing to "auction" at an appropriate perl conference too. 17:25
Andy OOOH
pmichaud darnit, merged to the wrong branch.
apparently moritz' changing of the integration branch changes it for everyone. 17:26
moritz that's... unexpected 17:27
17:30 ilia joined
pmichaud okay, how do I get andy's commit into master now? 17:31
Andy either from the fork queue, or 17:32
pmichaud it's not in the fork queue anymore.
because it got mistakenly applied to a branch.
(i.e., not master)
Andy oh
you can cherry-pick
git cherry-pick c98a526f893eeb7336dac91df66a8cf06e97e8f4
pmichaud so, I can't do it through github.
Andy don't think so 17:33
dunno.
and then do git commit -cc98a526f893eeb7336dac91df66a8cf06e97e8f4
to use the same commit message
pmichaud pain.
maybe I'll just re-add.
or maybe you can re-request the pull. 17:34
Andy but I think that may mean dupe changes on different commits
which means if you do that, it'll be a conflict when I get it.
pmichaud I haven't committed it to master yet.
so you shouldn't be seeing it yet.
Andy ok
pmichaud and git is supposed to be able to manage such things, iirc
how do I drop a branch in github? 17:35
PerlJam git branch -d branchname # (assuming you mean delete) 17:36
pmichaud that deletes it from github?
moritz and then git-push origin branchname:
pmichaud with the colon?
moritz yes 17:37
Andy pmichaud: Maybe I misunderstand what you meant by "re-add" then.
pmichaud Andy: I was just thinking about abandoning your push and doing a new one from the source.
moritz no, it's :branchname
sorry
pmichaud just a sec, let me see if I can clean this up.
moritz github.com/guides/remove-a-remote-branch
Andy pmichaud: But if you do that, then when you push that back, I have a conflict with mine.
which is fine, I guess.
I just have to do something to undo my commit. 17:39
and it IS on master right now.
it's in my FQ at least.
ilia hey guys, the Scope not found for PAST::Var problem only occurs on the 5.8.9 perl from macports. I see no such problem with apple's stock perl
which is 5.8.8
pmichaud ilia: oh, I see -- it's a Test::Harness issue then. 17:40
Andy: when I look at github.com/rakudo/rakudo/tree/master and follow the links into docs/ I don't see the file there. So I think it's not in master yet. 17:41
Andy strange.
purl But true.
ilia now how do i update my bug? rt.perl.org/rt3/Public/Bug/Display.html?id=63506
pmichaud ilia: reply to the email you got back from rt 17:42
ilia ok
Tene pmichaud: so, you said that the AST that should be generated for try {} should be the same as { ...; CATCH {$! = $^ex}} right? 17:46
pmichaud Tene: I think that's what S04 says, I can't be certain of it. 17:47
Tene That's the approach you want me to try?
pmichaud sure. 17:48
Tene Okay.
ilia so here's the result of my efforts from yesterday... rakudo spectest suite on Hudson twitpic.com/1pgu1 17:53
Tene What's Hudson? 17:54
purl Hudson is, like, better
Tene Oh. Helpful.
purl: go lart yourself.
purl Tene: sorry...
ilia i have Hudson set to poll git every hour and build and spectest on any changes 17:55
pmichaud for anyone who wants to try my first cut at a tarball for rakudo: www.pmichaud.com/perl6/rakudo-200902-test.tar.gz
Coke apparently missed a chance for Albany.pm; gypped. 17:56
pmichaud I haven't cut the release yet. 17:57
I can go with Albany.
17:57 rdice joined
ilia rdice: hi Richard 17:57
rdice ilia, hello.
ilia rdice: coming to tpm? 17:58
Coke pmichaud: kidding. Albany.pm is all but dead.
rdice ilia: indeed I am. 17:59
Coke tpm?
purl tpm is The Perl Machine, a hardware platform designed for compiling and running Perl programs. or Transaction Process Monitoring software or The Phantom Menace. or The Poor Movie or Toronto Perl Mongers or Trusted Platform Modulle, a DRM for MacOS or Tivoli Provisioning Manager (or how to screw a data centre automatically)
ilia coke: Toronto Perl Mongers
Coke wonders if it's worth thinking about going to oscon.
ilia: I guessed, given what I know of rdice.
rdice Coke: I'm sure it's worth thinking about. Thinking is cheap. :-) 18:00
Coke danke.
rdice: sadly, nothing else is.
I'm not even sure I can afford to go to pittsburgh this year.
rdice Hm. My sense of self-respect?
davidfetter oscon is harder for me to get to in san jose than portland
which is a sad commentary on the state of public transit here in the sf bay area :P
davidfetter lives in oakland
Infinoid despite my helping to fund BART with those bridge tolls 18:01
rdice I think it's an interesting change. I wonder why they did that. Portland seems to have worked out pretty well the past few years. Maybe The Great Recession has brought down prices on conference space in San Jose and they figure they'll get more attendance this way.
davidfetter: I thought public transit in the bay area was pretty good for american metro areas. 18:02
pmichaud I think the decision for San Jose pre-dates the recession.
I could be wrong about that.
davidfetter rdice, that caveat leaves a pretty huge hole :P
rdice pmichaud: there was a "before the recession"? I can't remember that far back.
pmichaud sure, I remember it. Clinton was president.
rdice davidfetter: One I intentionally inserted. :-)
Infinoid The bay is *big*. I think San Jose is an hour farther away from me than Oakland is 18:03
pmichaud afk, lunch
ilia so who is twitter.com/0280cbb8710f7b7 ? anyone here
rdice infinoid: I know it well. :-) It's about the same physical scale and population as Toronto. They're remarkably similar in a lot of ways. 18:04
Infinoid So given that I'd already be driving from the east edge of the state, it turns a 3.5 hour trip into a 4.5 hour one 18:05
This is why I don't go to San Jose very often... 18:06
18:07 particle joined, alvar joined
Tene Hey, is anyone here near San Francisco? 18:10
18:17 Psyche^ joined
Coke f 18:41
b
wow. that was bizarre. 18:43
(managed to, I think, /background/ my screen session.)
ilia slaps Coke around a bit with a large trout... or smth like that 18:47
18:50 Theory joined 19:06 barney joined 19:29 mberends joined
dalek rrot: r37018 | NotFound++ | trunk/examples/embed/lorito.c:
[examples] add --warnings option to lorito
 19:52
kudo: f4d2486 | pmichaud++ | README:
More README improvements.
 19:56
kudo: 78023fa | pmichaud++ | build/Makefile.in:
Makefile targets for creating MANIFEST and a release tarball.
shorten dalek's url is at xrl.us/behn2b
kudo: b412361 | pmichaud++ | .gitignore:
Ignore any MANIFEST file.
shorten dalek's url is at xrl.us/behn2d
shorten dalek's url is at xrl.us/behn2f
ilia what is the process for pushing a branch of rakudo? 20:13
or should i fork
pmichaud we're still working out the process. 20:26
producing diffs and submitting to rakudobug@perl.org is still valid, though.
ilia i'm having trouble with producing a diff even 20:33
git diff master shows a change i made but not a new file I added
20:40 gryphon joined
ilia see it now 20:45
i had to git rebase origin master
anyone else getting read errors for github.com 20:52
20:59 mberends joined
moritz ilia: git-format-patch works well if you did a commit first 21:00
jsut|work wouldn't one easy way be to pull the repo, create a local branch, code away, then use git diff master? 21:04
if it's been a long time you can git checkout master; git pull, get rebase master mybranch; to update your branch to current 21:05
ilia nice thanks
cotto Is there any reason the [GS]ETATTR accessor macros are in curly braces rather than a do{}while(0); ? 21:12
chromatic Doubt it. 21:15
pmichaud chromatic: would appreciate your advice on Rakudo numbering scheme I'm thinking of (more) 21:16
cotto I'll commit the change then if it doesn't cause any test failures.
pmichaud we were going to use letter-based names: A B C D ...
Andy suggested that we use .pm cities as release names
I like that, and modified it to be alphabetical city names 21:17
but I'm now thinking perhaps we'll just number sequentially, starting with #14
so "Rakudo #14 ('Chicago')"
next month would be #15
etc.
I didn't want to use #1, #2, #3 etc because they're too easily confused with 1.0, 2.0, 3.0
but starting with 14 shouldn't invite that confusion 21:18
21:18 purl joined
pmichaud it also emphasizes that we've had around 13 releases prior to this one. 21:18
thoughts?
purl Moonlight shines through the dark night / clouds move overhead, casting shadows / dancing in the firelight
moritz pmichaud: I'm fine with that
pmichaud that way .pm groups that want to support/associate themselves with Rakudo don't have to wait months or years to do so 21:19
chromatic pmichaud, that seems fine to me.
pmichaud of course, we can also identify a release by date ("February 2009") -- in fact, I'm thinking that the tarball will be named rakudo-2009-02.tar.gz 21:20
chromatic I like that. There's no magical thinking involved. 21:21
ilia rakudo-2009-02 Chicagos 21:22
rakudo-2009-02 Chicago Monsters
szbalint finally a use for Budapest.pm 21:23
;]
Coke chromatic: speaking of magical thinking, are you and allison on the same page regarding our releases yet? 21:25
jonathan szbalint: Sorry, B is taken. :-P
chromatic No.
szbalint jonathan: aww :) 21:26
chromatic I don't like calling two releases a year "stable".
jonathan szbalint: As a condolence, it's by a city just up the river from it. ;-)
szbalint jonathan: by Bratislava or Boston?
jonathan Bratislava, of course! :-)
szbalint ah, so the former then
chromatic That's like your wife asking "Do you think I'm pretty?" and you saying "Your friend is cute."
Coke chromatic: Ok. If allison doesn't want to discuss that on list (c.f. "poisonous"), IWBNI the two of you could take it out and at least present a concensus of two.
chromatic We tried. There's no consensus.
She believes that Ubuntu, for example, will only ever package 1.0 and 1.4 (or 2.0 and 2.6). 21:27
NotFound I'd like to name releases with the unix time in hex X-)
chromatic I say "If our software is better this month than it was last month (and we have over two years of history demonstrating that we can achieve that), let's release a new version." 21:28
She says "Normal people won't upgrade to 1.1, 1.2, 1.3, 1.5, etc."
I say "They have the option."
She says "We'll spend extra time fixing bugs before 1.0, 1.4, 2.0, and 2.6."
Coke they won't upgrade if we say they aren't stable.
chromatic I say "How does that make 1.1, 1.2, 1.3, 1.5, etc less stable?"
Coke ... so it seems like it's kind of self fulfilling.
NotFound I think "normal people" mean "package managers"
chromatic What makes them "not stable" though? 21:29
Do we not run tests for them?
Coke chromatic: I don't know what the rationale is.
I'm just trying to have a plan.
chromatic Do we drop quality for the release right after the one where we spent a lot of time improving quality?
Coke s/have a/know the/
chromatic That's what I don't get.
dalek rrot: r37019 | cotto++ | trunk/lib/Parrot/Pmc2c/Attribute.pm:
[PMC2C] wrap GETATTR/SETATTR macros in a do{}while(0); instead of curly braces
chromatic Why are we calling some releases stable and some releases not stable if we try very, very hard to keep trunk always stable?
cotto, someday I'd like to see GETATTR macros usable as rvalues. 21:30
Coke perhaps this would be a good topic for the board to address.
NotFound Y think that a 'stable' label only makes sense if someone will provide updates with just bug fixes to it.
cotto If someday were soon, that'd make the conversion to ATTRs a little easier. 21:31
chromatic I agree. I don't want to do that. I think it's a great way to waste volunteer resources.
cotto, it also helps static analysis tools not see so many "used uninitialized" problems.
NotFound Well, distro package managers can do, if they see a need.
Coke chromatic: seems like this falls under the 2nd bullet point at www.parrot.org/foundation
we could even put something up to a vote. 21:32
chromatic NotFound, that was my point. Ubuntu's update and release and stability policy has absolutely no bearing on me as an upstream developer. That's pretty much kind of exactly the reason why downstream exists.
Coke I do think it is is confusing that 1.1 might have /radical/ changes from 1.0
NotFound Let's radical! 21:33
Coke whereas the 'magical thinking' crowd would expect that to be a minor update.
chromatic If downstream reports a bug, I'll fix it.
I'll tell them which commit fixes it.
I'll tell them which new release will contain the fix.
Coke but just because 1.1 might be a big change from 1.0, that doesn't a priori mean it's unstable. 21:34
NotFound It even can (and even must) be a lot more stable
chromatic Given that we (by intent and deliberate choice) only merge feature branches to trunk when they're stable, I'm not sure why trunk would ever be unstable.
Andy I would really like them to be #14, #15 21:36
because then we're not tied to alphabetical
and we can have more PM involvement.
Coke I thought our PM quit!
NotFound Poor Monk?
cotto I thought "stable" referred to the API, not the code, i.e. there would only be major API changes or deprecations at 1.0, 1.4, etc.
Infinoid Partly Mortal 21:37
pmichaud Andy: I'm pretty sure we're going with #14, #15
chromatic "stable" is just too loaded a word.
Coke cotto: agreeing on terminology would be nice; what does "development" mean, then?
cotto That's what we do. 21:38
pmichaud Andy: because I agree I don't want to be tied to alphabetical.
NotFound We can call them "enhanced pro" releases ;)
Andy pmichaud: YAY!
Coke cotto: what is a "development release" ?
purl a "development release" is clearest
Andy I want to get people fighting over naming!
Infinoid Yay for PM groups duking it out!
pmichaud well, I think we've already got Feb and Apr spoken for.
Andy Chicago! Boston! Boca Raton!
ilia sounds like you guys are going to spend another year over release naming
Andy ilia: Not at all.
Coke ilia: parrot or rakudo?
pmichaud parrot, yes. 21:39
rakudo has its house pretty much in order :-)
szbalint naming-- # let's just use sha256 sums for release names, versions ;-)
ilia we need perl6 yesterday!
pmichaud we're all excited about our naming convention :-)
NotFound NAMECON?
Coke parrot doesn't care what the name of a release is. We're arguing about something more fundamental. 21:41
chromatic Basically we're arguing over two philosophies.
cotto We need to do what the College of Cardinals does when electing the Pope: lock all interested parties in a room until a decision is reached.
Infinoid with a bowl full of candy
chromatic One is "Users should be able to upgrade at their own pace."
NotFound cotto: What we will burn for the 'fumata'?
chromatic The other is "Developers should be able to make changes at their own pace." 21:42
cotto Infinoid, or cookies.
Coke chromatic: given the volunteer nature of our work, the latter seems more sane.
Infinoid cotto: I'm openminded to the prospect of cookies. Definitely pro-cookie here.
Hmm. Users probably don't care about parrot, per se. It all comes down to what the HLs depend on
chromatic Allison cares a lot about downstream packages, and stability there. 21:43
I don't.
Hang 'em.
NotFound Infinoid: that's a good point. Will be a shame if several languages need different parrot releases
Infinoid NotFound: it'll be fine as long as we get our installer right
Coke NotFound: shouldn't be ... what Infinoid said.
pmichaud (different parrot releases) I don't expect that to be an issue.
NotFound Infinoid: not so fine for distro packagers
pmichaud it should generally be "release xyz or later" 21:44
Coke (distro packages) - I think the HLL packages are more interesting from that standpoint.
pmichaud and that's part of the point of the longer publication cycle -- we work at 6-month intervals there instead of monthly ones.
in the short term, though, 6-months often isn't frequent enough.
Infinoid The idea of 6-monthly rakudo releases is a bit shocking to me. You guys are advancing at a *furious* pace 21:45
chromatic The HLL point didn't come up in our discussion yesterday, actually. 21:46
That's a good point.
NotFound "xyz or later" will be good, provided that we take some care to allow it.
pmichaud yes, the purpose of the 6-month cycle is also so that hll developers can publish HLLs to a known Parrot release point 21:47
at least, that's how I understood it.
It's simply that Rakudo, and possibly other languages, likely won't be able to live with Parrot 1.0 for some of their audiences
chromatic I don't see it as quite that way.
Coke pmichaud: but all releases are known release points.
so why can't they target 1.2 if they want?
chromatic The six month cycle is easier for us to prioritize features.
Coke chromatic: but our prioritization there has no direct correlation to reality. 21:48
pmichaud Coke: a particular HLL could target 1.2 if they wish, yes.
Coke: but if there are multiple HLLs sharing a common Parrot, that may not work.
Coke: Because 1.2 might not have some features that 1.0 provided.
chromatic A month is too short, and a year is too long.
The real question no one has addressed is "What do we tell people who want bug fixes?"
Coke pmichaud: we can't really assume how HLLs interacting on parrot is going to look.
NotFound We can't talk about language interoperability if it becomes normal that each language requires his own release. Well, we can, but nobody will believe
pmichaud Coke/NotFound: I agree, which is why I'm not worrying about it until the July release anyway. 21:49
interoperability isn't really a goal until then.
chromatic Coke, it has some degree of correlation with reality. We haven't figured out our load average so that we can refine our predictions.
pmichaud by July things may have settled down within Parrot that it's not really an issue.
chromatic We'll be better at scheduling for 1.4, and better yet for 2.0. 21:50
Coke chromatic: i remain skeptical.
chromatic Plus we should remember that we don't really have any users right now.
Coke we've had 8 years so far, and still suck at it.
Infinoid chromatic: If the HLLs always depend on the once-every-6-months-and-somehow-magically-more-stable releases, and those are our deprecation points, and the HLL depends on something that's about to be deprecated, then that means HLL users can *never* upgrade parrot to fix a bug without breaking the HLL at the same time.
Coke (no users) you /WOUND/ me.
chromatic How about "no users who aren't also Parrot developers"?
pmichaud "to fix a bug" -- those are "bugfix releases"
chromatic I don't want "bugfix releases". 21:51
Coke but we're not doing bugfix releases in the traditional sense.
pmichaud chromatic: I can agree to that sentiment.
but I think allison has been aiming in the direction of "bugfix releases"
i.e., we'd issue bugfix releases for the Jul/Jan releases 21:52
chromatic She thinks we'll probably have to have them for "critical bugs" and "security fixes".
In other words, if we find a big bug in December, we have to make a 1.4.1 release.
pmichaud Infinoid: I think the expectation (wrongly or rightly) has been that HLL users would only upgrade parrot at the six month intervals
chromatic Possibly also a 1.0.1 release, if Ubuntu hasn't updated to 1.4.
(To which I said "No. That's nuts.")
pmichaud as opposed to HLL developers, which would probably be working with more recent versions of Parrot 21:53
(in expectation of preparing for the next Parrot six-month release)
NotFound We will have a naming problem with bugs found in November X-)
pmichaud Personally, I'm not advocating any particular model yet, because I think we'll end up making up a bunch of it as we go.
chromatic I think so too. 21:54
Coke I'd be happy if we had a general plan. Right now we have two plans. :|
pmichaud to me that argues for a simplistic naming/numbering convention that isn't overloaded with lots of other meanings.
Coke (other meanings) even our simplistic numbering scheme now implies things are untrue. 21:55
"that are"
pmichaud our numering scheme now isn't my idea of "simplistic"
depending on which scheme you're referring to.
chromatic I suggested we refrain from labeling any release as "stable" or "development" or more stable and see what happens.
She said "People already call 1.0 and 1.4 stable."
21:55 isop joined
chromatic So STOP DOING THAT and I'll give you candy. 21:55
Or chips. Or crisps. Whatever you told Matthew.
pmichaud cookies won. :-) 21:56
NotFound Mentos with coke
pmichaud *diet coke*
NotFound Ofcoz
chromatic What does our current numbering scheme imply?
pmichaud wonders if Coke has ever had a Mentos, and what the impact was :-)
NotFound Unstable 21:57
purl wobbles
Coke chromatic: 1.1 vs. 1.0 with a 2.0 on the horizon implies that 1.1 is an incremental update to 1.0
and that 2.0 will be the first release that includes a bunch of new features.
I know you and I know it doesn't mean that. 21:58
pmichaud Coke: and this is exactly why I've been arguing against the 1.x 2.x scheme. :-)
NotFound We can use @ instead of dots, looks more modern ;)
ilia 2@0 ? 21:59
pmichaud proposes ˆ
NotFound Yeah
chromatic If I had a better numbering scheme, I'd suggest it.
ilia NotFound: crazy
NotFound ilia: I am
ilia: look at pirric, for example %-) 22:00
Coke if this were a coding project, I'd say lets figure out what problem we're trying to solve, and then a solution will become obvious.
or at least attainable.
cotto We could go surrealist. Instead of 1.0 we could release elephant.flower
ilia so is there a product manager
chromatic The problem is "How do we indicate that a release in February is newer than a release in January?"
Coke ilia: not in any sense that you would recognize from a for-$ project.
chromatic: that's YOUR problem.
that's not allison's problem.
so I think we need to agree on the problem we're trying to solve if we're going to agree ona solution. 22:01
"apparently not alli..."
ilia Coke: maybe it's time to treat parrot like a commercial product
NotFound First we need to agree that there is a problem
ilia parrot and rakudo
Coke ilia: Ok. give me 3 million dollars.
pmichaud "Parrot XP" :-)
"Parrot 2007"
"Parrot ME"
"Parrot Vista"
...that sort of commercial product? ;-)
NotFound "Parrot Enhanced Pro for Enterprise Environment"
Coke or we could use oracle or sun's number schemes. 22:02
chromatic What other kind of information *can* you extract from a version number though?
"Should I test it if I upgrade?"
"Is it different from the previous version?"
"What exactly has changed?"
ilia pmichaud: how about OS X style productizing
chromatic "How important are the changes, to me?"
NotFound I think that the information you must extract for a version number is just what web page to look for inromation 22:03
information
purl i guess information is similar, but not the same
chromatic Yeah, it's just an identifier for a particular release that sorts nicely.
Coke (that sorts nicely) - do we agree that we're (except in emergencies) going to have a linear set of releases? 22:04
NotFound chromatic: 1 & 2 answers: always yes
chromatic Yes.
Coke chromatic: then we don't need the major/minor numbering at all (except for emergencies) 22:05
chromatic Except that Allison says that no one will take us seriously if we jump from Parrot 1 to Parrot 2 too soon.
I don't agree, mind you, but she believes that strongly.
Coke chromatic: if we cared about people taking us seriously...
no one that I know takes us seriously now. 22:06
chromatic Yeah, I've said what I've had to say about only caring about grown-up opinions.
NotFound Foolest proposal of the day: Complex version numbers: Parrot 1.4 + 3.5i
Tene We could just drop numbers completely! "Parrot Awesome!" "Parrot ITSREALLYGOODIPROMISE"
"Parrot DontUseThisOne" 22:07
mberends what is wrong with something like 2009.02 like Gentoo and Ubuntu?
chromatic Predictable version numbers *do* have meaning, though. They tell you what's newer and what's older.
mberends, nothing's wrong with that, as far as I can see -- but people who want biannual Super Stable releases don't like that.
Tene mberends: Then the version information doesn't also carry metadata about the release itself.
pmichaud Tene: I'm not sure the currently adopted system carries metadata either. 22:08
Tene Doesn't distinguish, in the version number itself, between "REALLY STABLE" and "Kinda sorta stable-ish"
Coke the only metadata that we're willing to give (it seems) is whether or not it is a "milestone" release.
and right now, we have to do that by marking them somewhere else.
but the ONLY thing we're using that to track are items in DEPRECATION.pod 22:09
pmichaud and "milestone release" is defined by a date, not by a set of features.
chromatic But what's the value in exposing milestone releases to end users?
Coke so let's just track that in DEPRECATION.pod
"eligible for removal after the 2009.07 release".
chromatic In other words, the milestone releases are merely deprecation points? 22:10
pmichaud is certain he's heard that somewhere before. :-)
(the "eligible for removal..." part)
Coke chromatic: based on my reading of you, yes.
chromatic: based on my reading of allison, no.
but I like that plan. 22:11
chromatic I like that plan too.
It removes a lot of magic from the plan.
Coke magic--
chromatic pmichaud? 22:12
purl i think pmichaud is www.pmichaud.com/ or "Patrick R. Michaud" <mailto:pmichaud@pobox.com> or in charge of toaster experiments
Tene But... but maybe I want a feeling of pride every time I see someone using my proposed numbering scheme!
Coke gotta run, but will try to review.
Tene stops trolling #parrot to go troll his students instead.
pmichaud since I was arguing for "identify releases by date" at PDS, I think I'm the choir here. :-)
chromatic Just wanted to get you on record again. 22:13
mikehh If the product passes the test suite - surely that is stable?
chromatic mikehh, that's right.
NotFound Note that, as in TAP, we can have a plan but lots of skip 22:14
chromatic NotFound, I'm trying to remove as many skips as possible... would appreciate assistance from anyone.
mikehh but to be stable it must pass the full test suite 22:15
NotFound chromatic: I unTO an old TODO yesterday
chromatic Great!
22:15 Whiteknight joined
chromatic prove -r --directives t/ 2> directives.log is a big help 22:16
NotFound That TODO was just that someone just don't knowed how to build a key 22:22
mikehh that starts out with the banchmark tests 22:24
dalek kudo: cdcb92c | pmichaud++ | docs/NEWS:
Initial version of NEWS for Rakudo.
 22:34
shorten dalek's url is at xrl.us/behonh
22:47 Theory joined
dalek kudo: f45384a | pmichaud++ | docs/release_guide.pod:
First version of release_guide.pod, based on a proposed version
 22:52
shorten dalek's url is at xrl.us/behorb
Andy pmichaud: My first overhual is on my branch 22:55
s/branch/fork/
pmichaud checking. 22:56
23:02 rurban joined
pmichaud Andy: did you do a pull request? 23:02
Andy no 23:03
pmichaud ah.
rurban hi folks. I believe pbc is now platform compatible, but confirmation for 64bit appreciated: trac.parrot.org/parrot/attachment/...pbc.tar.gz
shorten rurban's url is at xrl.us/behosi
Andy it's 343c28e05a36d42b2a6de4248b4fb74c6a78a35f
rurban seen rg
purl rg was last seen on #parrot 18 hours, 33 minutes and 15 seconds ago, saying: ok, time to get some sleep. i'll check the logs ;)
pmichaud hmmm... that's a bit longer than I was planning... certainly longer than what we've done in Parrot's NEWS
rg i'm here 23:04
pmichaud we'll go with your version for now, though.
rurban msg rg please test xrl.us/behosi
purl Message for rg stored.
rurban rg: I think I've found the 64bit compat problems
rg so much that we won't even need -xmemalign ? 23:05
rurban rg: But I have no 64bit machine to test.
rg: no sorry. -xmemalign will go to the new hints file, not yet done. I fixed the more general pbc compat problem 23:06
Andy ok, now I did.
rg i can test it on amd64 pretty quit
Andy pmichaud: It's longe,r but it's more readable.
Ther'es more to see, rather than a block of text.
pmichaud yes, I agree.
Infinoid rurban: testing now 23:07
pmichaud We can shorten later if we decide it's too long. For now it's good as longer, readable text.
Andy One of the problems with the regular releases is that they're not interesting in themselves.
rg but i guess you mean big endian
Andy So when we put out Parrot, who cares? It's just another release.
rurban struct ptr_alignment on sparc is not possible to solve for now.
Andy WHY is it interesting?
Same thing with Vienna14.
chromatic One of the features of regular releases is that they're just not interesting in themselves.
rurban rg: no be<>le is no problem at all. 64<->32 bit was the big problem
pmichaud well, part of the reason for the shorter version of NEWS is that it's easier to cut-and-paste into a release announcement.
Andy chromatic: I understand that, so we need to pick out the good stuff to tell people. 23:08
pmichaud We don't want the release managers to have to go through a lot of editing work to cut a release.
Andy pmichaud: The way around that is for someone else to write the release announcement
such as we had happen here.
pmichaud "good stuff to tell people" belongs in the release announcement, not in NEWS
chromatic "Here is a cool feature AND YOU CAN USE IT TODAY RIGHT NOW IN A NEW STABLE RELEASE!"
Andy well, I guess I don't know what's this, what's that.
I don't know what you see as release announcement vs. NEWS
pmichaud release announcement is what gets sent to use.perl, rakudo.org, mailing lists, etc. 23:09
Andy chromatic: I'm not dissing reuglar releases at all.
And you don't see NEWS as an aggregation of those announcements?
pmichaud an aggregation of the highlights, sure.
more like an rss feed than a document.
Infinoid rurban: the patch doesn't apply to latest HEAD, and the pbc tests don't seem to do anything with the unpacked pbc files 23:10
Andy I guess I don't see that NEWS is too heavy by aggregating the release announcmenets.
that's what I thought I was doing.
chromatic: the downside of Just Another Parrot Release is that nobody cares unless we tell them why to care
rurban Infinoid: yes, I was away from the net for a few days. Tommorrow I'll update and make a clean patch to apply to latest.
Andy I'm not going to run an announcement on Perlbuzz about Parrot #97 just because it comes out. 23:11
Infinoid rurban: Cool. Looking forward to giving you a pass result on gentoo/amd64 :)
rurban Infinoid: But the new pbc tests (sparc 64bit) are handled as _6 in integer.t and number.t
chromatic Would you run an announcement about an awesome new feature? 23:12
Andy Yup
And so if someone hands me a release announcement that says "This has this new feature", then I'll run that. 23:13
rurban Infinoid: I'll also finish the missing floatval converters in the meantime. This should be done quick. Maybe even 4-byte single float, since its so easy to add
Andy So when I declined to run a 0.9.1 announcement, and I explained that it wasn't interesting, the reply came "I didn't realize it needed to be interesting."
Which is one of the big problems that people too close to the project can have.
It's interesting to US, but what about to THEM? 23:14
Infinoid Again, for most people, parrot is probably just an HLL dependency
rurban Infinoid: I had to write a written permission request to enable the VMWARE Virtualization support BIOS setting in my laptop for 64bit testing. No answer yet.
Andy All of this goes back to my ongoing frustration that FOSS people don't think about marketing their projects.
rurban I'm leaving bye, thanks! 23:15
Infinoid rurban: Well, I'm always happy to test :)
bye rurban
23:17 bsdz_ joined
Andy ok, goin' home. New rakudo.org up tonight. 23:18
bsdz_ i'm trying to dlfunc an exported. when i try "func = dlfunc lib, "dgesvd_", "itt33p3pp3p3p33"" i get "Parrot VM: PANIC: itt33p3pp3p3p33 is an unknown signature type.". anyone know if that looks wrong? 23:19
23:20 isop joined
NotFound bsdz_: Are you randomly testing ot that is a real signature of some function? 23:29
bsdz_ it's a real signature from clapack
i noticed a load of hardcoded sigs in nci.c 23:30
PerlJam bsdz_: add it to src/call_list.txt then
(and recompile)
NotFound I hope to never have to work in a project with such functions 23:31
bsdz_ ah okay thanks.
does this mean we can't use any sig without recomp parrot core? 23:32
NotFound bsdz_: if you don't have a nci-jitable platform, yes
GeJ Good morning everyone
bsdz_ i recall a colleague once solving a similar problem (dyn sigs) using C++ templates. note sure how though
is windows a non nci-jitable plat? 23:33
(morning gej)
PerlJam bsdz_: I don't think we even have an NCI-compiler yet, so no platform is jitable in that regard.
bsdz_ ha ha 23:34
okay thanks PerlJam
NotFound PerlJam: we have
PerlJam NotFound: excellent!
purl plays air guitar
NotFound Linux i386 at least
PerlJam heh, I was about to ask if it was x86 only :) 23:35
23:35 bacek_ joined
bsdz_ what generates call_list.txt? should i edit the progenitor? 23:36
japhb NotFound: NCI JIT is broken, even on Linux i386. It claims to work, and then does the wrong thing 23:38
23:38 TiMBuS joined
bsdz_ no probs i'll take a look in makefile 23:38
japhb bsdz_: config/gen/call_list
(.pm, and the dir)
bsdz_ thanks japhb
japhb bsdz_: no problem -- the first version of that was mine, to work around the fact that my OpenGL bindings were needing a BUNCH of NCI sigs that are only discovered at Configure time 23:39
NotFound japhb: last time I checked it was enabled 23:40
23:40 rdice joined
japhb dunno how much it has been hacked since then -- $day_job has taken me largely out of Parrot work except for answering questions and such 23:40
NotFound: yup. It's a horrible, horrible lie. I rant about it semi-regularly, and no one seems to care. 23:41
bsdz_ i'll see if i need to add a load of sigs
japhb (No, I haven't created new Trac tickets for it. I haven't had time to get over my frustration with the infrastructure migration.) 23:42
dalek rrot: r37020 | rurban++ | trunk/src/packfile/pf_items.c:
pbc-compat only TT #254: add missing fetch_iv inits
NotFound japhb: all my test programs works fine
japhb NotFound: run any OpenGL example with and without JIT. 23:43
23:43 skv joined
japhb Unless major improvements have happened in the last month, they will work perfectly with --jitcapable=0 ... and give blank windows with NCI JIT on 23:43
NotFound Don't remeber if that problem was solved, will check when/if I have time 23:47
japhb NotFound: Seriously, thank you. I've been feeling really ignored for months on this. I went through special effort to write variants of my examples to help narrow down the problem, and just couldn't get anyone who understood the internals to care. 23:48
NotFound japhb: maybe will be easier to test and diagnose now that we have some clean embedding examples. 23:49
japhb nod. 23:50
japhb rebases to look for said embedding examples ...
NotFound japhb: t/src/emebd.t and examples/embed
japhb NotFound: roger that 23:51
NotFound Well, they are clean to me, because I wrote them ;)
23:52 rdice_ joined
japhb NotFound: heh 23:53
23:57 skv joined 23:58 ewilhelm joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!