Topic for #parrot is: Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 20 April 2011.
00:01 nopaste left
cotto ~~ 00:04
00:06 nopaste joined
dalek p/ctmo: ca91987 | jonathan++ | src/pmc/sixmodelobject.pmc:
Make invoke Parrot vtable overridable.
 00:10
p/ctmo: 2417dc5 | jonathan++ | src/Regex/Match.pir:
Fix a symbol installation thinko.
p/ctmo: f6fb264 | jonathan++ | src/ (3 files):
Regex::Method and Regex::Regex become 6model classes. This leaves us only use P6object for PAST/POST.
p/ctmo: 3d5e96b | jonathan++ | / (4 files):
Move PAST extensions - the only things that don't use 6model and don't live in the NQP HLL - to a separate PBC. Helps avoid running into issues as a result of them not being capable of behaving wrt separate compilation.
p/ctmo: 1ede5c0 | jonathan++ | / (9 files):
Update bootstrap with PAST additions broken out.
whiteknight soh_cah_toa: my uncle was the "business partner" of the "prince of Nigeria" for several years 00:14
now he lives in my grandparents' basement and his ex-wife doesn't speak to him anymore 00:15
so not only are there still people like that, but I see one on most holidays
soh_cah_toa i suppose it's the older generations that aren't quite technology-educated. younger generations have the benfit of "intro to tech" classes in middle school 00:18
regardless, i thought it was common sense: don't trust strangers 00:21
TiMBuS i have all this money but also, no money to pay the transfer fee, for all this money. 00:23
soh_cah_toa i know, right?
00:24 woosley joined
TiMBuS well its because i sealed it in the briefcase so very tight but i forgot the $1000 stamp i gotta put on it. and if i open it, all the $100 bills will fly everywhere 00:25
its hard being a prince :[
soh_cah_toa you know it's hard out here for a prince, when he tryin' to get his money for the wire transfer...ince 00:27
i'm embarassed that i know those lyrics 00:31
whiteknight from what I hear on NPR, even the nigerian royalty don't seem to have that much cash floating around
soh_cah_toa well, how much cash did the "nigerian prince" have? i mean, "have". 00:33
whiteknight I really should archive some of the spam emails we get. They are hilarious 00:34
00:34 kid51 joined
whiteknight I can't tell whether these people really have such a tenuous grasp of written english, or if they are just playing stupid to get around the spam filters 00:35
soh_cah_toa that last one was pretty ridiculous. i can't get over the "organ of hearing". oh, how they try...
rohit_nsit08 ?? hi , what is going on? strange stories? 00:36
soh_cah_toa rohit_nsit08: spam
rohit_nsit08 on irc?
soh_cah_toa rohit_nsit08: the dev mailing list 00:37
rohit_nsit08: whiteknight was showing a pretty ridiculous example
kid51 whiteknight: Your complaint about line directives: does that mean you should reopen trac.parrot.org/parrot/ticket/1948?
rohit_nsit08 didn't checked it since evening :-)
cotto rohit_nsit08, whiteknight and others kindly filter it out. 00:38
whiteknight kid51: github.com/parrot/parrot/commit/32...87fa93f934
kid51: I couldn't make it stop, so I deleted them in pmc2c
probably not the "real" solution, but it helped me solve my problems today
personally, I don't see any value in having those line directives at all
but maybe somebody else has an opinion on it
cotto: I was working on Parrot-Instrument. I disabled instrumentgc, because it was causing weird GC problems that I couldn't diagnose 00:39
cotto: we're still failing tests, but failing slightly fewer of them in slightly different ways
or, as we say around here, "progress" 00:40
cotto whiteknight, ok. That rounds to good news.
whiteknight++
looks like time to backscroll 00:41
seems like a busy day
soh_cah_toa speaking of testing, i need some help. i submitted a patch that removed the cwd from the library search path. i think it was cotto who said that it needed a test. how do i test this? 00:42
i mean, why test for something that it's not doing?
there are an infinite number of things that code doesn't do. by that same logic, shouldn't i be testing for those?
00:43 bacek left
cotto soh_cah_toa, git can't handle infinite files 00:43
soh_cah_toa well git should have a test for that 00:44
cotto I'm on the fence about whether a test is needed for that patch.
kid51 soh_cah_toa: Does your patch move cwd to the end of the search path -- or does it remove it from the search path altogether?
soh_cah_toa to make sure there AREN'T infinite files
whiteknight it's good practice to make the test anyway
cotto kid51, remove
soh_cah_toa kid51: removes it
i'm just trying to get a better grasp on this unit testing stuff 00:45
kid51 Okay, then presumably placing a library in cwd (for testing purposes), then demonstrating that the library cannot be found, would constitute proof -- would it not?
cotto kid51, that'd be sufficient proof 00:46
soh_cah_toa right
whiteknight I'm not sure why that behavior is not desirable
soh_cah_toa but would that test be just for the patch or is it one that would be run like the others when parrot it built?
kid51 whiteknight: Discussion in TT #1589 leaned toward removing altogether
soh_cah_toa *is 00:47
kid51 soh_cah_toa: it would be run as part of 'make test': perhaps: the t/library tests
soh_cah_toa ok
kid51 That way, if anyone subsequently changed the behavior, a test failure would immediately call attention to that change
00:48 BloodyCoin joined
soh_cah_toa hmm... 00:48
alright
kid51 I don't know the ins and outs of doing this in PIR, but we do things like that in Perl 5 as part of t/configure/*.t
cotto Testing for a behavior also indicates that we think it's explicitly desirable, rather than an unintended side-effect or oversight. 00:49
kid51 Agreed
cotto There are likely many of both remaining in Parrot.
soh_cah_toa cotto: now that makes sense to me 00:50
00:50 rohit_nsit08 left
kid51 So the flow of the test would be: Create something that parrot will think is a library. Create a temporary directory; chdir thereto. Copy library to that tempdir. Run something that shows the library is not found, perhaps capturing error output. Switch back to your top-level dir; remove tempdir. 00:51
soh_cah_toa alright, i'd use the Parrot::Configure module? 00:52
cotto When you find something surprising, the things to look for are an explanatory comment, a test and documentation, in that order.
00:52 S_Arms left
cotto soh_cah_toa, you could do all that in PIR or nqp. 00:52
kid51 soh_cah_toa: Probably not, at least not directly. P::Configure is geared toward running C programs which probe the system for libraries. 00:53
cotto depends on what you're more comfortable with.
soh_cah_toa kid51: oh, you were just using the t/configure directory as an example
kid51 Yes.
soh_cah_toa cotto: aren't they supposed to be perl 5?
kid51 soh_cah_toa: In principle, things which come into existence once the Parrot executable exists ought to be tested via PIR or NQP. 00:54
cotto soh_cah_toa, both are acceptable 00:55
PIR or nqp is preferred
er, all three are acceptable
kid51 Granted, there still are many tests in that area written in Perl 5, but we'd like those to be rewritten in Parrot's languages.
soh_cah_toa loading a library would be easiest in pir and nqp anyway
kid51 Things that exist *prior* to the creation of Parrot executable are tested with Perl 5.
soh_cah_toa i see, that's good to know 00:56
kid51 So you probably want to get familiar with PIR's Test::More for that.
soh_cah_toa yeah, i think i may use that for gsoc
kid51 No "thinking" about it, babe! Whatever you do for GSOC has to be thoroughly tested. 00:57
See whiteknight's blog post about that!
soh_cah_toa well, i know that
"i think" is lazy for "i am". bad habit 00:58
for a while, i was deciding between perl Test::More of pir Test::More 00:59
*or
by "i think", i meant pir is what i decided
instead of "i think i'll test my code"
kid51 Look at it this way: If you learn to write tests in either PIR or NQP, the number of people in the world who demonstrably know how to write code in those languages goes ++ 01:00
01:00 S_Arms joined
kid51 goes back to learning C++ 01:00
cotto Don't do it! It can only end in tears. 01:01
or possibly dollar signs
dalek rrot-instrument: 4fbacba | Whiteknight++ | src/dynpmc/instrument.pmc:
disable instrumentgc for now. it's causing problems that I do not understand
rrot-instrument: b97bdf7 | Whiteknight++ | src/dynpmc/instrument.pmc:
invoke IMCC the correct way
rrot-instrument: 8f56c61 | Whiteknight++ | src/dynpmc/instrument.pmc:
really really call IMCC the right way now. Parrot_pf_execute_bytecode_program takes a PMC, not a raw PackFile*. We now get into an infinite loop in at least some tests
soh_cah_toa well, what made me choose pir's Test::More is b/c languages like pir, nqp, winxed, etc. are all tightly knit together in a nice little community. it'd be pretty stupid to make my project half-parrot half-something-else 01:02
they all work well together 01:03
01:04 BloodyCoin left
soh_cah_toa anyway, back to the test. here's what i'm thinking... 01:06
do something like "$P0 = loadlib './foo' " then make sure the value of $P0 is equal to the right error message 01:07
cotto you should try to load it without specifying where it is 01:09
01:10 jrtayloriv left
cotto The point of the test is to make sure that the cwd isn't searched by default 01:10
soh_cah_toa hmmm...alright. let me try again...
whiteknight okay, the infinite loop in Parrot-Instrument that I am looking at now is caused because two separate PackFile* structs are returning the same :main Sub 01:11
kid51 or: Nothwithstanding the fact that I, the tester, have placed the library in my cwd, Parrot cannot locate it or load it, which is a good thing.
whiteknight so when I try to call the :main sub of the second packfile, it calls the currently executing program
soh_cah_toa make a test library in cwd. try to load it. when it doesn't load. success through failure 01:12
kid51 Yes
soh_cah_toa what does loadlib return on error? null?
kid51 That I don't know. When you find out, you'll know more about it than I. 01:13
soh_cah_toa yeah, i suppose i can just do a 'say $P0' after the fact 01:14
cotto soh_cah_toa, src/ops/core.ops 01:18
soh_cah_toa how would i make a test library in the cwd programmatically in pir?
or should i make it beforehand 01:19
is it okay to have that fake library in the test directory?
whiteknight msg plobsing I could use a hand with parrot-instrument if you have a minute. t/instrumentop.t, among others. Infinite loop because multiple PackFile* are returning the same :main sub for the current program. Trying to load+exec a new packfile causes the loop. Any ideas? 01:21
aloha OK. I'll deliver the message.
kid51 soh_cah_toa: As a first pass, you can have the library in the top-level directory. 01:22
But, ideally, you should figure out how to create a tempdir and conduct the test there.
whiteknight have the test try to loadlib itself
soh_cah_toa yeah i can make a tempdir
kid51 That way, once your code is in master, any failure of the test does not pollute the top-level dir.
whiteknight it's own name should be in the parameter list
soh_cah_toa whiteknight: good idea
whiteknight it is in it's own current directory 01:23
soh_cah_toa recursive logic...does not compute
alright, i think i finally got a handle on this
kid51: what i meant was creating a file to load in that tempdir. i didn't see any touch-like commands in osutils. it doesn't matter. i think i'm gonna take whiteknight's approach 01:24
i'm so excited that i'm understanding the concept now (so far). for a while there, there was something about unit testing that just wasn't computing in my head 01:27
whiteknight yeah, really understanding unit testing is a great moment 01:28
it's not something you learn about in school, but it can be amazingly valuable
soh_cah_toa don't get me started. i'm still mad about that
if it's this important, i really should be taught. i'm embarrased that i have to learn this now 01:29
it*
blah. oh well. 01:30
anyway, i got this great book today "test driven development." it's really great
whiteknight soh_cah_toa: when I graduated, I didn't know anything about: version control, unit testing, coding methodologies, anything related to "best practices", etc 01:31
I could write bubble sort in Java like a mamma-jamma
soh_cah_toa i know! 01:32
whiteknight I was the king of bubble sort in Java
01:32 jrtayloriv joined
soh_cah_toa like that's something to show off to an employer!? 01:32
whiteknight I was hoping I could find a job opening for "Bubble Sort Engineer", maybe at microsoft or somewhere
soh_cah_toa the furthest they we go into development methodologies is the waterfall model. "here is the waterfall. this is what you'll use someday. but not now. moving on..." 01:33
*that 01:34
an apparantly, most developers frown upon the waterfall model
whiteknight because the most you can do with a waterfall is to fall off it, and get wet 01:36
also, "the world does not work that way"
bubaflub pretty much designed to always be behind schedule
soh_cah_toa i understand that some things can only be learned through experience but still... 01:37
and on that note, i need to start writing some code myself. less complaing, more doing. let's start that test... 01:39
whiteknight (more doing)++ 01:40
kid51 whiteknight: "when I graduated, I didn't know anything about: version control, unit testing, coding methodologies, anything related to "best practices", etc" -- Andy has a talk/slideshow/rant about precisely that 01:41
petdance, that is, not doughera
Speaking of which, where has Andy D been lately? (not on parrot-dev)
whiteknight kid51: I don't typically talk about it on my blog, because I would write far too much on the topic 01:42
kid51 I loved your GSOC submissions rant
whiteknight thanks!
kid51 It's always great to hear someone other than petdance or me rant about testing.
whiteknight I showed off Parrot's test suite at work, as an example to my coworkers about "the way it should be" 01:43
you know how many unit tests we have for our system at work? A big fat 0
and not writing unit tests severely cramps my style
bubaflub whiteknight: ouch
kid51 whiteknight: I am all too familiar with $jobs like that 01:44
whiteknight bubaflub: worse than that, we are expected to "test" the application frequently, but randomly and without any particular goals or methodologies in mind
but if I write unit tests, nobody but me will run them, and they quickly stop passing
bubaflub whiteknight: bah
whiteknight: that's rough 01:45
whiteknight: where i'm at the main development has full tests + continuous integration; the legacy products have some tests
whiteknight bubaflub: I'm jealous 01:46
bubaflub whiteknight: but yeah, i've been at places where there are no tests and we were just expected to fix things
01:54 bacek joined
whiteknight Whiteknight's rule of programming #37: If you aren't using unit tests in at least some capacity, you *are wasting your time* 01:55
02:02 bacek left 02:17 bacek joined 02:23 ShaneC joined 02:38 kid51_ joined 02:42 kid51 left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#15383) fulltest) at 3_3_0-32-g8906192 02:44
Ubuntu 11.04 beta amd64 (g++)
02:53 whiteknight left 03:23 bubaflub left 03:32 kid51_ left 03:55 mikehh left 04:03 cogno joined 04:19 cogno left 04:25 woosley left 04:38 ShaneC left
dalek rrot: 2c6ed8c | petdance++ | lib/Parrot/Vtable.pm:
Allow ARGxxx() annotations on vtable methods
 04:57
05:01 hudnix left 05:17 bacek left 05:27 bacek joined 06:00 ShaneC joined 06:10 ShaneC left 06:13 ShaneC joined 06:22 theory left 06:43 JimmyZ joined 07:08 bacek left 07:11 JimmyZ left 07:18 SHODAN joined 07:21 birdwindupbird joined, woosley joined 07:24 bacek joined 07:51 bacek left 07:54 cogno joined 08:02 bacek joined 08:06 cogno left 08:13 bacek left 08:14 cogno joined 08:15 dukeleto left, dukeleto joined, Infinoid left 08:16 Infinoid joined 08:24 cogno left 08:48 alin joined
dalek p/ctmo: a2e9414 | moritz++ | build/Makefile.in:
[build] more blank -> tabs fixes
 08:51
08:58 alin left 09:20 mj41 joined 09:35 lucian joined, alin joined, alin left 09:49 lucian_ joined 09:53 lucian left 10:05 lucian joined 10:06 lucian_ left 10:07 lucian_ joined 10:10 nopaste left 10:11 lucian left 10:14 lucian joined 10:15 lucian_ left 10:16 nopaste joined 10:23 lucian_ joined 10:26 lucian__ joined 10:28 lucian left 10:30 lucian_ left 10:44 lucian__ left 10:49 alin joined 11:05 whiteknight joined 11:07 lucian joined 11:09 lucian_ joined
whiteknight good morning, #parrot 11:12
11:13 lucian left
tadzik good morning whiteknight 11:15
11:15 alin_ joined 11:16 alin_ left 11:17 alin left 11:37 contingencyplan left 11:38 alin joined, alin left, alin joined 11:52 mikehh joined 11:56 Psyche^ joined 11:57 Patterner left, Psyche^ is now known as Patterner 12:24 hudnix joined 12:36 alin left, alin joined 12:51 mj41 left 12:55 GeJ_ joined 12:56 GeJ left 13:01 jrt4 joined 13:04 jrtayloriv left 13:09 jrt4__ joined 13:12 bacek joined, jrt4 left 13:16 jrt4 joined 13:18 lucian joined 13:20 jrt4__ left 13:21 lucian_ left 13:24 jrt4__ joined 13:27 jrt4 left 13:34 whiteknight left
benabik ~~ 14:06
14:07 lucian left 14:16 bacek left, ambs joined 14:46 alin_ joined, alin left, alin_ is now known as alin
dalek rrot: feabd77 | cotto++ | src/ops/core_ops.c:
rebootstrap ops
 15:14
15:16 ambs left 15:17 ambs joined 15:23 mj41 joined 15:24 birdwindupbird left 15:27 ambs_ joined, ambs left, ambs_ is now known as ambs 15:43 alin left 15:49 jrt4__ left 15:50 jrtayloriv joined 16:07 theory joined 16:13 woosley left 16:28 mj41 left 16:40 rohit_nsit08 joined
rohit_nsit08 hello #parrot 16:40
benabik Hello rohit_nsit08 16:41
plobsing o/ 16:43
16:56 petdance joined 17:41 ShaneC left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#15426) fulltest) at 3_3_0-34-gfeabd77 17:59
Ubuntu 11.04 beta i386 (gcc --optimize)
18:07 ShaneC joined 18:15 plobsing left 18:28 alin joined 18:36 petdance left, alin left 18:39 rohitnsit08 joined, alin joined, rohit_nsit08 left 18:46 alin left 18:58 alin joined 19:05 alin_ joined 19:06 alin left, alin_ is now known as alin, particle1 joined 19:08 contingencyplan joined 19:10 particle left, alin left 20:30 mj41 joined 20:48 x3nU left 20:57 rohitnsit08 left 20:59 SHODAN left 21:08 petdance joined 21:20 petdance left 21:21 petdance joined 21:27 petdance left
dalek p/ctmo: 633ca59 | jonathan++ | src/Regex/ (4 files):
Avoid relying on absolutely global state for storing $?CLASS in Regex.pbc, otherwise separate compilation is impossible. Also makes it work just like the generated code.
 21:38
p/ctmo: 864b681 | jonathan++ | src/HLL/Grammar.pm:
HLL::Grammar kinda breaks encapsulation of Regex::Cursor; do it in a way that won't cause so many issues.
p/ctmo: 086ff02 | jonathan++ | src/ (2 files):
Fix a GC marking bug and add a missing write barrier.
21:44 ShaneC left, ambs left 21:47 mj41 left 22:06 bacek joined
dalek p/ctmo: 7f5c477 | jonathan++ | src/ops/nqp.ops:
A few more missing write barriers.
 22:08
22:18 whiteknight joined
dalek p/ctmo: 56d057a | jonathan++ | src/ (2 files):
Another write barrier; fix a leak.
 22:22
p/ctmo: 956db58 | jonathan++ | src/6model/knowhow_bootstrapper.c:
Couple more write-barriers.
whiteknight Good afternoon, #parrot 22:36
benabik 'lo, whiteknight 22:37
jnthn__ Supposing a PMC a holds a reference to PMC b. a and b are both unreachable, so end up in the sweep list. Is there any promise that b will be destroyed before a? 22:50
er, sorry, toher way around
a before b
Or more generally, is the sweep list ordered in any particular way? 22:51
whiteknight no, we make no ordering promises whatsoever
jnthn__ OK.
This...explains the assumption that is causing the segfault I'm currently hitting.
Thanks.
whiteknight we don't provided ordered destruction, and have no concrete plans to do so
jnthn__ *nod*
Yeah, I'm not sure I should have any reasonable expectation of it. 22:52
whiteknight it's something that's been on our wish list but....it's like seriously hard
jnthn__ Yes. Then you get a pointing to b and b pointing to a and then it's impossible to order a circle. :)
benabik ORdered destruction is very rarely provided by GCs
jnthn__ I'd not intented to assume ordered destruction really. 22:53
I just accidentally relied on it.
And it took quite a while to get bitten.
(Long story short, a points to b, and b has information relevant to freeing the memory associated with a.) 22:54
With a little brane application, I can re-work it. I'd been a bit bothered by the current representation factoring in other ways anyway. 22:57
whiteknight Parrot actually relies on ordered destruction in certain places. The scheduler has been notorious for it 23:02
every now and again we get a bug cropping up related to that 23:03
jnthn__ This one is kinda tricky to figure out exactly how to resolve, but I'll come up with something. For now I'll just work around it and leak the odd type object. 23:04
Well, I know *an* answer, but it's not ideal in different ways. 23:05
23:05 bubaflub joined
whiteknight why would the type object leak? is it still being referenced from somewhere? 23:06
if it's still referenced, you don't want to destroy it. If not, it will eventually be collected itself 23:07
jnthn__ whiteknight: See my comment starting Long story short
whiteknight okay, I think I can understand that
jnthn__ whiteknight: To expand a bit, an object references two things. One is its meta-object, which is no problem. The other is its representation.
whiteknight you can't cache all the information relevant to A in A itself?
jnthn__ The representation is concerned with allocation approach and so forth. 23:08
Yes, that's the easy solution.
However, it bulks up every single allocation.
s/allocation/object/
whiteknight ok
jnthn__ There's probably a middle way between the two that doesn't depend on ordering, but keeps the information mostly or entirely out of each allocation. 23:09
whiteknight so when A is destroyed, push any un-freed memory on a to-do stack somewhere and free it later
jnthn__ No, it's not quite that simple. A is the type object. It points to a representation. The representation is the object that knows how A is allocated and freed.
If it goes away first, then we don't actually have the information on how to free A. 23:10
whiteknight when does the representation get freed? only on global destruction?
jnthn__ If nothing is using it, it's elligible for collection.
whiteknight ok
so it should still be alive longer than all objects of that type, except during global destruction? 23:11
jnthn__ It could happen well before global destruction.
Imagine making an anonymous type, then it becoming unreachable.
At that point, we'd like to free everything associated with it. 23:12
whiteknight ok
jnthn__ Anyway, just to be clear - nothing Parrot's doing here is wrong. It's an implementation flaw in the stuff I'm doing. 23:13
dalek p/ctmo: 85011da | jonathan++ | src/6model/reprs/ (6 files):
Write barriering in reprs, plus a re-ordering just in case that triggers an issue.
 23:15
p/ctmo: d777f9e | jonathan++ | src/pmc/sixmodelobject.pmc:
Fix a segfault related to freeing of anonymous types. Note that we need a real fix for this issue, but it's relatively low impact for the time being.
jnthn__ On the upside, it made me scour the code for missing write barriers... :)
I'm not 100% certain all the ones I added are needed, but they all seemed reasonable.
whiteknight bacek assures me that extra write barriers are cheap 23:19
jnthn__: I would really like to start seriously planning, if not doing the actual work, to get 6model integrated into parrot this summer 23:20
that's a high priority for me
bacek ~~ 23:21
Good morning, humans.
whiteknight so whenever you think it a good time to start that work, let me know
hello bacek
bacek whiteknight, aloha
whiteknight, extra write barrier is just one check of pmc->flags. 23:22
quite cheap :)
jnthn__ OK, then I won't worry :) 23:23
whiteknight: OK. I'd like to get the current enormous NQP refactor dealt with first.
whiteknight: I'm also working on 6model docs at the moment. 23:24
The hardest part might well be "how do we get PMCs to be real objects" 23:26
whiteknight jnthn__: that's already the hardest part of everything we do 23:30
jnthn__: we have so much code, including some of the worst code in the entire project, devoted to working around PMCProxies and that mess 23:31
if we can unify and stop being stupid, lots of stuff can be improved 23:32
huge swaths of code in src/oo.c, lots of logic from src/pmc/namespace.pmc, probably a large portion of the two-stage global initialization, etc 23:33
jnthn__ whiteknight: Yes. I think Parrot will have to do a lot of "unlearning". :) 23:35
The methods/namespace association almost certainly wants breaking somehow. 23:36
bacek Did we just missed opportunity to deprecate all this stuff in 3.3? 23:38
whiteknight bacek: we miss many opportunities to deprecate things 23:44
If I had my way, I would have deprecated "everything" after 1.0, and then we would be okay 23:45
23:46 jrtayloriv left
bacek Sounds like a good idea :) 23:47
benabik We should keep a list of "thing's we're looking at removing." Not depreciated, but before each stable release we can look at it an figure out what we're likely to be working on next. 23:48
whiteknight I wanted to have an "opt-in" deprecation policy, where everything is always experimental except things we explictly mark as stable 23:50
then, all the stuff that sucks and that we know sucks and is going to be removed violently won't ever be protected
dalek rrot: d83b2f4 | Whiteknight++ | src/packfile/api.c:
when executing a packfile PMC, look up the :main sub directly instead of expecting it to be set in the current context
 23:57
whiteknight okay, that fixes the bug where Parrot-Instrument gets into an infinite loop. Now it fails to execute completely
I call that "progress"
benabik progress++ 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!