Parrot 2.9.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GC tuning | remove deprecations |
Set by moderator on 21 October 2010.
cotto atrodo, how would you summarize your experience trying to implement a Lorito prototype? 00:00
00:00 davidfetter joined
cotto a free-form brain dump is fine 00:00
dukeleto nwellnhof: You have very high code quality, I am not even trying to imply that you don't. But I think we need to move away from committing directly to trunk unless it is a trivial doc fix or adding tests 00:03
cotto dukeleto, speaking of which, what' the git migration schedule look like? 00:04
dukeleto nwellnhof: and just because it works on your machine, doesn't mean it works on all the platforms/OS's we support
nwellnhof: that commit is fine and it can stay in trunk, but in the future, think about these things.
nwellnhof dukeleto: Yes, but I can always break other platforms, even if I add tests. 00:05
dukeleto nwellnhof: a failing test has lower impact than breaking the build on a platform
nwellnhof: if a test never fails, it isn't useful
cotto: I am in the middle of a week of conferencing, and have lots of stuff going on. And I need to finish create_language/mk_language_shell porting to git 00:07
cotto We don't expect that our tests will cover every possible code path, but we still want as much test coverage as possible.
A code change is a good target for some tests, if for no other reason.
dukeleto, ok. I wasn't sure how long the gsoc conference would be.
dukeleto cotto: i am at the git developer conf now, and came to GSoC early to write a book, so I am actually cramming 2.5 confs into 8 days 00:08
dukeleto is running on the fumes of sleep
cotto srsly
best to do the migration well-rested 00:09
dukeleto Also, i haven't had time to talk about it, but some people have contacted me that they are working on R on Parrot
cotto: yeah. but i will try to hack on finishing porting create_lang to git, that shouldn't be too hard, now that I know what scope it needs to work for
atrodo cotto> to summarize, it's been pretty fun as well as fairly easy. The direction given, while vague, was a good set of guidelines to the product I have now
cotto I love it when people work on things that I otherwise wouldn't care about at all.
atrodo as for a longer brain dump, I started working on that this morning 00:10
cotto It's a good sign that the Parrot is diverse enough to be relevant to people in different spheres of hackerdom.
atrodo++
atrodo, What I'm most interested in are the parts you had to fill in on your own. 00:11
dukeleto cotto: many people are interested in parrot. We need utilize that. 00:12
cotto hopes that didn't come out wrong
very yes
00:12 dngor_ is now known as dngor
dukeleto I meet so many different kinds of people at GSoC. I sat next to a DragonFlyBSD dev on a shuttle, and he was interested in seeing if parrot works on it. Stuff like that. 00:13
Since they forked from FreeBSD 4 years ago, it shouldn't be too different than vanilla FreeBSD.
they mostly seem to have different ideas about SMP than FreeBSD and have a different default filesystem. 00:14
kid51 dukeleto: Approx 2 years ago we were getting smoke tests from DragonflyBSD. That was pre-Smolder. 00:16
dukeleto kid51: that is good to hear. So we probably could add them as an experimental platform 00:17
kid51 It appears we have no "dragonfly" tag in our Smolder site. Which means we haven't received any smokes on that OS since we began smolder.parrot.org a few months back. 00:18
If we had someone who was really interested and would respond to test failure reports, then we could include it even without the 'experimental'. 00:19
It's having a maintainer that is key.
As in much else :-)
00:24 nwellnhof left 00:25 dmalcolm left
dalek rrot: r49680 | whiteknight++ | trunk (4 files):
add a new Parrot_load_bytecode_file API in src/embed.c. This new method allows the user to load a .pbc file into the interpreter without having to deal with a struct PackFile like the old way required. Returns a boolean to signify success or failure. This method is experimental and currently untested. It may need to be tweaked in a variety of ways.
 00:38
kid51 whiteknight: Re r 49680: If it is true that "This method is experimental and currently untested", shouldn't you be developing it in a branch? 00:47
01:04 TiMBuS left
whiteknight no. That addition is basically orthogonal to any other functionality. It's only "experimental" in the sense that "it isn't covered by deprecation policy" 01:05
01:05 tcurtis joined
whiteknight we might want to pick a better term for things like this. I suspect "experimental" is misleading 01:06
01:08 TiMBuS joined
cotto "provisional"? 01:08
whiteknight Because this feature is going to be included in the Parrot API, the only question is whether the current form of it is correct
"probational"?
nevermind. "probational" reminds me of a bunch of potheads i knew in highschool 01:09
cotto had similar thoughts
kid51 Well whether experimental/provisional/probational, a test file would at least provide an instance of how to use the new method. 01:11
generational_gc branch not currently building on linux/i386 01:15
trunk passing make test at r 49631 on linux/i386 01:16
trunk passing make test at r 49680 on darwin/ppc 01:17
Hmm, that revision number on the linux test looks suspiciously old 01:18
whiteknight the function is currently untested, It won't remain so
kid51 Thanks. 01:19
davidfetter o/` test-ety-test yourself before you rest yourself o/` 01:35
with apologies to ice cube
kid51 When I was in Portland, I got my haircut at a barbershop that ice cube would have felt right at home at 01:37
davidfetter you must be *loaded*
davidfetter figures ice cube hasn't hung around with anything but millionaires in a *long* time
01:41 whiteknight left
kid51 Well, at least the character he played in 2 movies ... 01:43
davidfetter heh
01:50 dngor_ joined 01:51 dngor left 01:55 tcurtis left 01:58 tcurtis joined, tcurtis left 02:19 kid51 left
cotto reparrot.blogspot.com/2010/10/parro...arios.html - new blog post about how teams might work 02:21
GeJ msg whiteknight t/codingstd/c_arg_assert.t is complaining about an unused assert macro declared for Parrot_load_bytecode_file. Should I add it myself or do you prefer to do it? 02:24
aloha OK. I'll deliver the message.
02:52 davidfetter left
atrodo cotto> that's apparently a harder question than I initially thought 02:54
cotto atrodo, answers to those kinds of questions can quickly spiral 02:57
Thanks for taking the time to answer. It'll help. 02:58
atrodo That's kind of what's happening in my thought process 02:59
It's taking some thought to figure out what wasn't defined, what is an implementation detail, and what did I just go another direction with 03:00
cotto feel free to think out loud here 03:07
atrodo Well, not a lot has really been defined with Lorito. It's more concrete than it was 6 months ago, but there's still a bit of hand waving over a some of the details 03:12
cotto Yeah. That's what I'm hoping to expose and define. 03:13
atrodo For instance. PMCs. Is there a unwritten understanding that PMCs are going to continue to be opaque struct-like blobs that are referenced by index or name? 03:14
or were there others that desired a more generic blob of memory like the one I went with
cotto It's... unwritten
atrodo Or, take the CPS talks that there have been. Is all of the lorito ops in one flat address space, or are there still a high level concept of a code block? 03:16
cotto CPS will be on top of Lorito, though I need to grok exactly what it'll look like. 03:19
On my todo list is a wiki page explaining CPS and how it'll apply to Lorito. 03:24
GeJ aloha, clock? 03:40
aloha GeJ: GeJ: LAX: Mon, 20:40 PDT / CHI: Mon, 22:40 CDT / NYC: Mon, 23:40 EDT / UTC: Tue, 03:40 UTC / LON: Tue, 04:40 BST / BER: Tue, 05:40 CEST / TOK: Tue, 12:40 JST / SYD: Tue, 14:40 EST
04:16 silug left 04:20 patspam joined 04:35 patspam left 04:58 kiwichris joined 05:07 kiwichris left 05:08 kiwichris joined 05:28 kiwichris left
cotto plobsing, ping 05:30
plobsing, unping. I figured it ou. 05:31
plobsing, reping 05:38
nopaste "cotto" at 192.168.1.3 pasted "lingering problem with pbc_dump after dynop_mapping merge for plobsing" (11 lines) at nopaste.snit.ch/24883 05:39
05:42 dngor_ is now known as dngor
dukeleto 'ello 05:45
cotto hi dukeleto 05:50
dukeleto cotto: how goes it? 05:53
cotto blogging is hard. Let's go coding. 05:54
Coding is hard. Let's go blogging.
simon_ indecisiveness is hard. let's digress. 06:05
bacek aloha, humans 06:23
06:39 uniejo joined, uniejo left
dukeleto bacek: how is the GC hacking going? 06:45
bacek dukeleto, badly. Collecting some objects too early... 06:46
dukeleto bacek: be more lazy! 06:47
bacek dukeleto, I'm lazy enough. But GC isn't. 06:50
06:52 fperrad joined 07:07 theory left 07:13 jsut_ left, jsut joined 08:23 raek left 09:58 uniejo joined 09:59 contingencyplan left
cotto pmc2c-- 10:03
dalek rrot: r49681 | fperrad++ | trunk/t/pmc/io_stdin.t:
[t] useless interpolation
 10:11
10:13 bacek left 10:37 bacek joined 10:39 dngor_ joined, dngor left 10:55 kid51 joined 11:05 dngor joined 11:07 dngor_ left 11:33 raek joined
dalek rrot: r49682 | fperrad++ | trunk/t/pmc/io_stdin.t:
fix Perl5 part on Windows (but tests still fail)
 11:59
12:24 kid51 left 12:51 whiteknight joined
whiteknight good morning, #parrot 13:08
cotto++ on the excellent blog post
msg GeJ I won't have time to get around to that issue until tonight. If you can fix it, please do. Otherwise I will get to it 13:09
aloha OK. I'll deliver the message.
whiteknight I think what I am going to do is create a new file "src/embed_api.c" and maybe a new header file "include/parrot/api.h" 13:19
I'm going to create a new API that's completely orthogonal to the existing API. Then we can put in deprecation notices for all the functions in src/embed.c (some will be moved/renamed/cleaned up, others will be deleted) and deprecate the use of include/parrot/embed.h for external projects 13:20
parrot/api.h will be the new header include that all external projects, including the Parrot executable, will use 13:21
(I don't think anybody is reading this, I'm just brain-dumping while I have the ideas in my head)
mikehh whiteknight: hey I am reading it 13:22
whiteknight but I had no way of knowing that! 13:23
mikehh I definately think that the api/interface needs a LOT of simplification/refactoring 13:24
whiteknight I think everybody thinks so 13:29
so that's reassuring
my thought is if I create a new API as basically a new overlay, it won't interfere with the existing "API" and won't cause any hardships when we merge
then we deprecate the old garbage and have plenty of time to make a gradual switchover 13:30
I think I've decided that I'm going to write a Parrot plugin to XChat, as my example/test embedding application 13:41
14:01 dmalcolm joined 14:22 uniejo left 14:28 brianwisti joined 14:35 whiteknight left 14:38 mikehh left, whiteknight joined
atrodo whiteknight++ # having a new .h is an Excellent idea 14:43
And, as a suggestion, may I suggest less macros in it. That would allow using it in non-c languages nicer 14:44
whiteknight yes, I plan to have far fewer macros 14:55
The new API will only use the standard P S I N types for most operations, though some might take C-strings 14:56
all pointers, including interp, are going to be considered opaque 14:57
14:59 theory joined
atrodo whiteknight++ 15:00
whiteknight I'm trying to figure out how to signal errors. I don't know whether we expect the embedding application to register exception handlers with Parrot, or whether we return a flag and an error message, similar to Win32 with GetLastError 15:03
atrodo Why not both? 15:04
whiteknight I am aiming for consistency
though we could have two APIs, one that returns booleans, one that throws exceptions
I don't know how huge a pain in the ass it is to register and maintain C exception handlers 15:05
atrodo That's probably the big kicker
the return value route would be easier and more C-ish
whiteknight Maybe instead of returning a boolean, I return a PMC. an exception PMC signifies an error. 15:06
atrodo That would be novel 15:07
plobsing whiteknight: then you run into the semi-predicate problem
whiteknight plobsing: how so?
plobsing what if I have a PIR routine that returns (not throws) an exception upon success?
whiteknight well, the API function will return the exception as a pointer in the arglist. The return value of the C-level function is separate 15:08
If I say that the return value of C-level APIs always returns a status object, then any other results would be passed through pointers in the arglist 15:09
plobsing OK, I understand better now. So the place return values go is passed as a by-ref argument. 15:11
whiteknight right. That seems a little messy, but again I am worried about consistency
plobsing So all parrot API functions that can throw exceptions (and I'm betting that's nearly all of them) return PMCs? 15:12
atrodo i'd take consistency over the mess that's there now.
whiteknight the question is really whether we want to propagate Parrot exceptions into embedding code (and ask the embedder to wrap API calls in weird C-level exception handlers) or whether we just hand off values and assume exceptions are internal to libparrot only 15:13
plobsing that doesn't seem quite right. 'error = Parrot_ext_vtable_get_bool(interp, pmc, &bool)' is clunky and un-C-ish.
atrodo whiteknight> And that's a pretty big question 15:14
whiteknight plobsing: sure, but exception handling would be even worse
plobsing I'd much rather see 'bool = Parrot_ext_vtable_get_bool(interp, pmc, &error)'
whiteknight Ah, so a generalized result object
result = Parrot_do_stuff(), bool = Parrot_get_bool_result(result) 15:15
set result.error on error, result.value otherwise
plobsing passing an error space by-ref also gives parrot information from when an embedder chooses to ignore errors (by passing NULL) 15:16
whiteknight I worry about the performance hit of creating a new result PMC for every single API call though
15:17 mikehh joined
nopaste "whiteknight" at 192.168.1.3 pasted "very rough example of exception handling API in C" (12 lines) at nopaste.snit.ch/24906 15:20
15:20 bluescreen joined
whiteknight I think that's terrible, personally 15:20
and we have to start thinking about threads, etc. 15:21
plobsing on which side of the C/parrot barrier? both? 15:22
whiteknight Well, I guess it depends how Parrot handles it's threads, internally. 15:24
I call a function. That function spawns a worker thread. That worker thread throws an unhandled exception.
Does that unhandled exception propagate to the parent thread, or does it call that C-level handler in a separate thread? 15:25
then we have cross-thread accesses to hadError
plobsing what happens when the root thread returns to C? do the other threads get killed? does the call hang until all threads are finished? do we continue executing parallel to the application in separate OS threads? 15:27
but, for the record, I am against C-level exception handlers. Parrot languages already know how to deal with these problems (or should at least), so you can just whip up a wrapper if you really need to do tricky things. 15:31
15:34 lucian joined
NotFound Note that in order to avoid propagating exceptions to the caller almost all api functions should have its own exception handler. 15:52
16:04 contingencyplan joined
whiteknight NotFound: at the moment, yes. What I think we need to do instead is to have a flag that we are inside an API call-in. When we have an unhandled exception, instead of dieing, we store that exception someplace and return that to the caller 16:04
so in the API function we do a setjmp or something. When we have an unhandled exception we jump back to that point with the exception object in payload 16:05
assuming the interpreter doesn't end up in an inconsistent state, we should be good
dukeleto howdy 16:07
whiteknight howdy 16:08
NotFound whiteknight: That is efectively the same as setting up a handler. 16:12
whiteknight right, but there are some differences 16:19
1) an unhandled exception doesn't cause death by fire
2) we define the handlers, instead of asking the user to define them
NotFound Yes, but setting up one in any api function may be not cheap. 16:20
whiteknight it's not really setting up a handler. 16:21
we don't need to create a handler, because this is an issue of last resort. We just change the behavior for when an exception is unhandled 16:22
instead of fiery death, we go to a longjmp point if it's defined. Otherwise, crash and burn
dukeleto Crash Override? 16:24
NotFound You need a setjmp at least. And doing it that way disallows the ability to resume the exception. 16:25
whiteknight NotFound: if we're talking about an unhandled exception where Parrot would have called exit() instead, this is still an improvement. We're past the point of resuming 16:28
We've already exhausted all options, the exception was not handled, and we are bailing out
so we need to find a way to do this without destroying the embedding application too 16:29
NotFound whiteknight: but if we do inside the api function, is out of the caller control.
whiteknight right, but we need to return something reasonable back to the caller
it would be rude to crash or close the program
so we send back an error message: We died. Sorry. Here's the info. Don't do it again 16:30
NotFound I don't have objections for that, but supposedly there are people in parrot that like resumable exceptions.
cotto ~~ 16:38
dukeleto whiteknight: so your plan is to make a totally new embed/extend api and deprecate the old one? 16:43
cotto Ooh. This should be good. 16:44
cotto backscrolls
whiteknight dukeleto, yessir. That way we can transition over time 16:47
dukeleto whiteknight: what is your #1 problem with our current embed/extend interface that makes you want to kill it instead of improve it? 16:49
NotFound dukeleto: mostly that it doesn't exist. 16:50
dukeleto NotFound: what?
NotFound: Please take a look at pl.parrot.org, which embed Parrot in Postgres. Our embed/extend API exists. 16:51
s/embed/embeds/
NotFound dukeleto: the api functions are supposed to be decorated with PARROT_API. Look at the source tree and tell me how many you see.
plobsing dukeleto: it exists but not in a formal way, and definitely not in a well designed way 16:52
NotFound And I don't think there is any working project that uses only the functions declared in extend.h and embed.h 16:53
cotto dukeleto++ #"crash override" 16:54
plobsing if you want to resume exceptions from C, you can write a simple wrapper that sets up a root exception handler that traps a continuation and rethrows to C. 16:56
dukeleto NotFound: i use "almost" only functions in the embed/extend headers, and the ones i do use that aren't there, should be there 16:57
I am not quibbling with the fact that our embed/extend API is paperclips and duct tape, but I am not sure a total rewrite is needed, vs. fixing the sharp edges 16:58
NotFound dukeleto: I don't think that creating new headers means a total rewrite. Is an opportunity for reorganization and self-documentation, and makes easy future deprecations. 16:59
dukeleto NotFound: whiteknight is talking about a total rewrite 17:00
whiteknight yeah, going to take an axe to it all
dukeleto whiteknight: Totalling rewriting it seems unnecessary. I would like to see incremental improvements 17:01
whiteknight: you don't have to maintain an embedded project now, so you have no incentive to improve the current interface
whiteknight my incentive is the good of the parrot project 17:02
dukeleto whiteknight: but for those of us that already are using it, incremental improvements are better
cotto whiteknight, Is there a nice upgrade path for existing users like PL/Parrot?
dukeleto whiteknight: that is easy to say but hard to prove correct
whiteknight it's not going to be written instantaneously
17:02 hudnix left
whiteknight I'm going to put together parts of it, and they will be made available in parallel with the existing functions 17:03
NotFound I think we can mix bot approaches, at least as a start. Put some of the lacked functionality in the new headers, well designed, documented and decorated.
whiteknight switchover can happen gradually
cotto Once it's in place will the only way to convert be to change a bunch of code all at once or will the APIs overlap enough to avoid that?
perhaps you just answered my question
17:04 hudnix joined
whiteknight I 17:05
NotFound Will be good to know what is the lacked functionality, BTW.
whiteknight 'm going to put together a branch for some initial work tonight, probably. We can see what's going on then
anybody here familiar with the config hash stuff? 17:06
NotFound The functionality that real projects are aleady using and is not in extend.h or embed.h, I mean.
(and please don't tell me "All the string functions") 17:07
whiteknight We do need to do a much better job of exposing our string functions to the external world 17:08
we do still need to figure out how to handle error conditions and exceptions being propagated to embedding code 17:09
cotto: that might be an area where some kind of design fiat could be handed down from on high
NotFound whiteknight: yes. Just exposing the current functions is opening a can of worms. 17:10
whiteknight if we had a setjmp at every entry point, an unhandled exception could cause parrot to jump back to that point with error information
cotto plobsing, ping 17:11
whiteknight src/exception.c:die_from_exception needs to change radically, in any case 17:12
src/exit.c:Parrot_exit needs to change too. We can't be calling exit() in the context of an embedding application 17:15
NotFound We can change the current way of creating the main interpreter and child interprteres with the same function, and make the main interpreter creation function takes a parameter to set up the last-resource-catch.
whiteknight and I don't think we can call it at all in RTEMS either
NotFound BTW some of our docs says that exiting return control to whatever launched the main runloop, calling exit is just a de facto behavior. 17:18
whiteknight right, de facto behavior is wrong here 17:19
Tene Yes, the parrot binary really needs to be rewritten as just a normal application embedding libparrot 17:28
IMO
dukeleto Tene: yes, I agree with you 17:29
cotto whiteknight, ping 17:38
18:15 brianwisti left
whiteknight pong 18:23
cotto whiteknight, why does OpLib return a value for the short name of an op? I'm not sure why that value would be useful.
s/OpLib/OpLib PMC/ 18:25
whiteknight what value does it return? 18:42
cotto not sure, but I'd expect -1 for anything except a long form op. lemme check 18:43
For some reason, it return 531 for "say", which maps to does_i_p_pc 18:45
whiteknight what are you calling to get that result? VTABLE_get_integer_keyed_str? 18:46
cotto nm
whiteknight ?
cotto it returns the number for say_i if I ask for "say"
yes
whiteknight for the lookup it calls oplib->_op_code(interp, 18:47
cotto nopaste coming
whiteknight "say", 1
ah, I think I see it
oplib->_op_code takes a bool for the second arg that specifies whether to look up by shortname or long name 18:48
cotto nopaste.snit.ch/24917
whiteknight first we only look up by long name, then by shortname if that fails
check out like 69 in that file
cotto right. I'm asking if that's a useful behavior.
whiteknight i have no idea. 18:49
cotto If OpLib is being used to build bytecode segments, it should only accept full op names and return an error on anything else.
whiteknight what would you suggest as replacement? return PMCNULL? Return an array of all ops with the same shortname, as we do in METHOD op_family?
cotto it currently returns -1 for keyed access
whiteknight ah right, this one returns an INTVAL 18:50
okay, howabout change that to return -1, and not lookup by shortname
cotto sure 18:51
I'll dig around and see what I can find wrt why it does the short name lookup
18:52 silug joined
whiteknight ok 18:53
18:53 jsut_ joined 18:54 fperrad_ joined
cotto It seems like one of those features that could have been bolted on just because it was easy. 18:55
whiteknight it is something that really doesn't make sense now that I am thinking about it 18:57
I vote for removal, I suppose
18:58 jsut left, fperrad left, fperrad_ is now known as fperrad
whiteknight all anybody has to do is delete lines 68 and 69 from that file 19:01
cotto and make sure there wasn't a good reason for them in the first place 19:02
whiteknight I suspect strongly that there is not 19:03
We may want a similar functionality to look ops up by shortname in IMCC, but we're not ready for that yet 19:04
the more we can keep IMCC from poking directly into structure guts, the better
dukeleto Death to IMCC. 19:06
whiteknight no argument here 19:13
dukeleto #ps soon? 19:14
or am i an hour early again?
cotto in 75 19:15
19:15 lucian_ joined
whiteknight yay! I posted my first #ps report in months 19:17
of course, I still won't be at the meeting
19:19 lucian left 19:22 snarkyboojum left, bluescreen left, snarkyboojum joined 19:23 PerlJam left, PerlJam joined
dalek rrot: r49683 | cotto++ | branches/opmap_aware_pmcs (3 files):
[pmc] initial versions, mostly stub code with some untested implementations
 19:28
rrot: r49684 | cotto++ | branches/opmap_aware_pmcs/src/pmc/oplib.pmc:
[pmc] add some methods that will be needed by PackfileBytecodeSegment
rrot: r49685 | cotto++ | branches/opmap_aware_pmcs/examples/pir/make_hello_pbc.pir:
[examples] update make_hello_pbc.pir to use the interface I plan on implementing in this branch
19:38 chromatic joined 19:40 bluescreen joined
whiteknight dukeleto: I think we are serious about Google Code-In 19:42
I think we have to be serious about any program that drives contributors towards us
19:45 bacek left
cotto I think his question is whether we want to be under TPF or do it ourselves. It's implicit that we want to do it. 19:54
whiteknight it might be interesting to try branching out on our own for it 19:56
cotto +1. We need to do it eventually and this would probably be lower-maintenance than gsoc. 19:57
whiteknight Eventually I would like to do GSoC separately. This would be a decent test for that
cotto It depends on how our community manager feels though. ;)
whiteknight this is true 19:58
chromatic GC MS2 is fairly close to sweepfree and semi-generational already... with a few tweaks it could be much closer (and probably 30% faster). 19:59
dalek rrot: r49686 | cotto++ | branches/opmap_aware_pmcs/src/pmc/oplib.pmc:
[pmc] don't try to look for short op names if the long name lookup fails
 20:00
dukeleto cotto: yes, correct.
whiteknight chromatic: Yeah, I saw some of the sweep-free code he had in there. I was very happy about that
dukeleto i am talking to TPF about getting a grant for it
I just don't have time for Code-In unless I get paid.
but the application deadline is the end of the week, and TPF moves slowly.
chromatic I'll make a branch and add a couple of lists to the MS2 struct and see what I can do.
cotto they do.
dukeleto may miss some of #ps due eating lunch with the Git peeps 20:01
20:01 kid51 joined
whiteknight dukeleto: maybe this is a task that could be farmed out to another person? Especially true if PaFo goes separate from TPF 20:01
cotto We could ask for a volunteer during #ps. dukeleto, would you have the tuits to help someone figure out the role?
dukeleto cotto: perhaps, but that might be more work than doing it myself
cotto: unless the person has some experience doing these kind of things 20:02
sorear kid51: hi
whiteknight dukeleto: is it really a lot of work?
cotto A higher bus number is always a good thing.
dukeleto whiteknight: You have no idea.
cotto Wouldn't most of the necessary information be documented somewhere? 20:03
whiteknight yeah, because I have a bus, I've been drinking, and I'm heading to dukeleto's neighborhood right now
dukeleto I've never done Code-In, because this is the first year. No one has.
But judging from doing GSoC for the last 2 years, it is a good amount of work.
cotto Right, so there's be lots of people asking all the relevant questions.
whiteknight so all the more reason why a new person could grab it and run
dukeleto whiteknight: I am putting on my lollerskates and I will grab the back bumper and get a free ride
atrodo whiteknight> That's so strange, so am I
dukeleto I am only going to be an admin for Code-In. I need lots of mentors. 20:04
and people to delegate to
whiteknight I'm always happy to mentor
dukeleto I will not mentor for Code-In. I just don't have the time.
cotto too
whiteknight brb, I have to turn off my computer
20:04 whiteknight left
dukeleto We need to be coming up with tiny tasks for students: improve parrot.org, translate some docs, etc... 20:04
20:04 nwellnhof joined
dukeleto I need to write an application that links to a list of tasks for students by Friday 20:05
Can somebody volunteer to make a wiki page for those?
I will write the app, but I need help coming up with tasks
cotto another good #ps question
20:08 allison joined
cotto hio allison 20:09
allison hiya cotto
atrodo everyone needs more minions 20:12
kid51 sorear: I suspect we'll be forming an Embedding group or task force or whatever during psketch today. whiteknight or dukeleto will be able to use your help there. 20:15
20:23 Andy joined 20:27 fperrad left 20:29 tcurtis joined
moderator Parrot 2.9.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | remove deprecations | volunteer for embedding or Lorito teams | 20:44
20:50 plobsing_ joined
plobsing_ cotto: (re: pbc_dump problems) pbc_dump and pbc_disassemble don't have parrot's runtime environment properly set up. I can get your example to work properly if I 'mkdir dynext; cp runtime/parrot/dynext/math_ops.so dynext' 20:53
chromatic Is that a Makefile problem?
plobsing_ not as far as I could determine. I linked against parrot_config.o with no effect. 20:55
I suspect parrot isn't being initialized properly
cotto plobsing_, that makes sense 20:56
it's a little surprising but understandable.
21:03 bacek joined 21:16 bluescreen left 21:22 plobsing_ left 21:31 bluescreen joined 21:36 Andy left 21:54 preflex left 21:55 hudnix left 21:57 preflex joined, hudnix joined 21:58 kid51 left
dukeleto mikehh: i added an example task to your wiki page 22:01
we still dont' get wiki changes in here => :( 22:04
22:05 allison left 22:11 nwellnhof left 22:20 donaldh joined
donaldh Hi, I have a question about NCI 22:21
chromatic go ahead
donaldh back in Parrot 1.x days (IIRC) I could add NCI thunks by adding a file to config/gen/call_list/ 22:22
That seems to have gone.
What's the right approach now?
I see src/nci/core_thunks.nci and src/nci/extra_thunks.nci 22:23
chromatic See the src/nci/*.nci
Yes.
donaldh Should I just be editing those?
chromatic extra_thunks for everything except what core parrot needs, I believe
donaldh k 22:24
thanks
Should I be going a stage further and compiling my extra thunks as a dynext ? 22:26
chromatic To my knowledge, you'd be the first to do so. That's interesting though. 22:31
22:32 brianwisti joined
dukeleto donaldh: there is a gsoc_nci branch that is very close to being merged, which uses libffi 22:34
donaldh: you may perhaps want to look at that
donaldh there is parrot_install/bin/parrot_nci_thunk_gen that will produce a C file for dynext
dukeleto: oh
dukeleto: that is interesting. very close to merge? I might wait for that. 22:37
dukeleto donaldh: i think there is just 1 failing test left on the branch. Maybe you want to fix it ? ;) 22:38
donaldh: it might get merged faster if you fix that failing test :)
22:38 nwellnhof joined
bacek_at_work aloha, humans 22:38
22:39 brianwisti left
donaldh dukeleto: that might happen :-) 22:39
mikehh dukeleto: I am not thinking too clearly at the moment, need some sleep, will get back to GCI later 22:41
22:42 dngor left, dngor_ joined 22:45 bluescreen left
dalek rrot: r49687 | nwellnhof++ | trunk/t/pmc/io_stdin.t:
[t] Make t/pmc/io_stdin.t pass on Windows
 22:50
donaldh dukeleto: have checked out gsoc_nci branch. I'll take a look tomorrow. goodnight. 23:03
23:05 dngor_ left 23:12 donaldh left
dalek rrot: r49688 | nwellnhof++ | trunk/src/embed.c:
[codingstd] Add missing ASSERT_ARGS
 23:22
23:31 whiteknight joined
plobsing dukeleto: close to merge is a bit misleading. the bug in question has been a huge hacking time sink for me. no progress. 23:40
whiteknight which branch is this? 23:42
plobsing gsoc_nci 23:43
whiteknight ah, gotcha
plobsing the bug is the same kind that caused us to ditch the old frame builder
I think I have a new plan though
whiteknight what's the bug? need another set of eyes?
plobsing completely wrong PCC signature for a given NCI signature 23:44
my plan: separate out the parser from the rest. use lex or something like it.
whiteknight ok 23:45
chromatic How completely wrong?
plobsing extra S parameter IIRC
P parameter where it shouldnt' be either 23:46
again, going from memory. I took a couple days off of that.
I'm also not a fan of the switching out of files based using config. it was expedient, but its ugly. I want to get rid of that too. 23:47
s/based// 23:48
23:53 chromatic left
dalek rrot: r49689 | whiteknight++ | branches/embed_api (2 files):
creating a new branch to start working on the new embedding API stuff
 23:53
rrot: r49690 | whiteknight++ | branches/embed_api/src/embed_api.c:
adding in a new stub file of embedding API functions I'm playing with
rrot: r49691 | whiteknight++ | branches/embed_api/src (2 files):
move the load_bytecode_file function into the new API. Rename it to match
bacek_at_work whiteknight, deprecation cycle. You have to keep old Parrot_load_bytecode_file (preferably redirecting to Parrot_api version) 23:56
whiteknight bacek_at_work: that function was added two days ago 23:57
bacek_at_work whiteknight, ah, ok.

Powered by Cro and the Raku® Programming Language.

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

Thank you!