Camelia, the Perl 6 bug

IRC log for #parrot, 2010-10-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 cotto atrodo, how would you summarize your experience trying to implement a Lorito prototype?
00:00 davidfetter joined #parrot
00:00 cotto a free-form brain dump is fine
00:03 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:04 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
00:04 dukeleto nwellnhof: that commit is fine and it can stay in trunk, but in the future, think about these things.
00:05 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
00:05 dukeleto nwellnhof: if a test never fails, it isn't useful
00:07 dukeleto 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.
00:07 cotto A code change is a good target for some tests, if for no other reason.
00:07 cotto dukeleto, ok.  I wasn't sure how long the gsoc conference would be.
00:08 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
00:08 cotto srsly
00:09 cotto 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
00:09 dukeleto 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
00:09 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
00:09 cotto I love it when people work on things that I otherwise wouldn't care about at all.
00:10 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.
00:10 cotto atrodo++
00:11 cotto atrodo, What I'm most interested in are the parts you had to fill in on your own.
00:12 dukeleto cotto: many people are interested in parrot. We need utilize that.
00:12 * cotto hopes that didn't come out wrong
00:12 cotto very yes
00:12 dngor_ is now known as dngor
00:13 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 dukeleto Since they forked from FreeBSD 4 years ago, it shouldn't be too different than vanilla FreeBSD.
00:14 dukeleto they mostly seem to have different ideas about SMP than FreeBSD and have a different default filesystem.
00:16 kid51 dukeleto:  Approx 2 years ago we were getting smoke tests from DragonflyBSD.  That was pre-Smolder.
00:17 dukeleto kid51: that is good to hear. So we probably could add them as an experimental platform
00:18 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:19 kid51 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 kid51 It's having a maintainer that is key.
00:19 kid51 As in much else :-)
00:24 nwellnhof left #parrot
00:25 dmalcolm left #parrot
00:38 dalek parrot: r49680 | whiteknight++ | trunk (4 files):
00:38 dalek parrot: 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 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49680/
00:47 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?
01:04 TiMBuS left #parrot
01:05 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 tcurtis joined #parrot
01:06 whiteknight we might want to pick a better term for things like this. I suspect "experimental" is misleading
01:08 TiMBuS joined #parrot
01:08 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
01:08 whiteknight "probational"?
01:09 whiteknight nevermind. "probational" reminds me of a bunch of potheads i knew in highschool
01:09 * cotto had similar thoughts
01:11 kid51 Well whether experimental/provisional/probational, a test file would at least provide an instance of how to use the new method.
01:15 kid51 generational_gc branch not currently building on linux/i386
01:16 kid51 trunk passing make test at r 49631 on linux/i386
01:17 kid51 trunk passing make test at r 49680 on darwin/ppc
01:18 kid51 Hmm, that revision number on the linux test looks suspiciously old
01:18 whiteknight the function is currently untested, It won't remain so
01:19 kid51 Thanks.
01:35 davidfetter o/` test-ety-test yourself before you rest yourself o/`
01:35 davidfetter with apologies to ice cube
01:37 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*
01:37 * davidfetter figures ice cube hasn't hung around with anything but millionaires in a *long* time
01:41 whiteknight left #parrot
01:43 kid51 Well, at least the character he played in 2 movies ...
01:43 davidfetter heh
01:50 dngor_ joined #parrot
01:51 dngor left #parrot
01:55 tcurtis left #parrot
01:58 tcurtis joined #parrot
01:58 tcurtis left #parrot
02:19 kid51 left #parrot
02:21 cotto http://reparrot.blogspot.com/2010/1​0/parrots-teams-five-scenarios.html - new blog post about how teams might work
02:24 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 #parrot
02:54 atrodo cotto> that's apparently a harder question than I initially thought
02:57 cotto atrodo, answers to those kinds of questions can quickly spiral
02:58 cotto Thanks for taking the time to answer.  It'll help.
02:59 atrodo That's kind of what's happening in my thought process
03:00 atrodo 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:07 cotto feel free to think out loud here
03:12 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:13 cotto Yeah.  That's what I'm hoping to expose and define.
03:14 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 atrodo or were there others that desired a more generic blob of memory like the one I went with
03:14 cotto It's... unwritten
03:16 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:19 cotto CPS will be on top of Lorito, though I need to grok exactly what it'll look like.
03:24 cotto On my todo list is a wiki page explaining CPS and how it'll apply to Lorito.
03:40 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 #parrot
04:20 patspam joined #parrot
04:35 patspam left #parrot
04:58 kiwichris joined #parrot
05:07 kiwichris left #parrot
05:08 kiwichris joined #parrot
05:28 kiwichris left #parrot
05:30 cotto plobsing, ping
05:31 cotto plobsing, unping.  I figured it ou.
05:38 cotto plobsing, reping
05:39 nopaste "cotto" at 192.168.1.3 pasted "lingering problem with pbc_dump after dynop_mapping merge for plobsing" (11 lines) at http://nopaste.snit.ch/24883
05:42 dngor_ is now known as dngor
05:45 dukeleto 'ello
05:50 cotto hi dukeleto
05:53 dukeleto cotto: how goes it?
05:54 cotto blogging is hard.  Let's go coding.
05:54 cotto Coding is hard.  Let's go blogging.
06:05 simon_ indecisiveness is hard. let's digress.
06:23 bacek aloha, humans
06:39 uniejo joined #parrot
06:39 uniejo left #parrot
06:45 dukeleto bacek: how is the GC hacking going?
06:46 bacek dukeleto, badly. Collecting some objects too early...
06:47 dukeleto bacek: be more lazy!
06:50 bacek dukeleto, I'm lazy enough. But GC isn't.
06:52 fperrad joined #parrot
07:07 theory left #parrot
07:13 jsut_ left #parrot
07:13 jsut joined #parrot
08:23 raek left #parrot
09:58 uniejo joined #parrot
09:59 contingencyplan left #parrot
10:03 cotto pmc2c--
10:11 dalek parrot: r49681 | fperrad++ | trunk/t/pmc/io_stdin.t:
10:11 dalek parrot: [t] useless interpolation
10:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49681/
10:13 bacek left #parrot
10:37 bacek joined #parrot
10:39 dngor_ joined #parrot
10:39 dngor left #parrot
10:55 kid51 joined #parrot
11:05 dngor joined #parrot
11:07 dngor_ left #parrot
11:33 raek joined #parrot
11:59 dalek parrot: r49682 | fperrad++ | trunk/t/pmc/io_stdin.t:
11:59 dalek parrot: fix Perl5 part on Windows (but tests still fail)
11:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49682/
12:24 kid51 left #parrot
12:51 whiteknight joined #parrot
13:08 whiteknight good morning, #parrot
13:08 whiteknight cotto++ on the excellent blog post
13:09 whiteknight 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.
13:19 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:20 whiteknight 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:21 whiteknight parrot/api.h will be the new header include that all external projects, including the Parrot executable, will use
13:21 whiteknight (I don't think anybody is reading this, I'm just brain-dumping while I have the ideas in my head)
13:22 mikehh whiteknight: hey I am reading it
13:23 whiteknight but I had no way of knowing that!
13:24 mikehh I definately think that the api/interface needs a LOT of simplification/refactoring
13:29 whiteknight I think everybody thinks so
13:29 whiteknight so that's reassuring
13:29 whiteknight 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
13:30 whiteknight then we deprecate the old garbage and have plenty of time to make a gradual switchover
13:41 whiteknight I think I've decided that I'm going to write a Parrot plugin to XChat, as my example/test embedding application
14:01 dmalcolm joined #parrot
14:22 uniejo left #parrot
14:28 brianwisti joined #parrot
14:35 whiteknight left #parrot
14:38 mikehh left #parrot
14:38 whiteknight joined #parrot
14:43 atrodo whiteknight++ # having a new .h is an Excellent idea
14:44 atrodo And, as a suggestion, may I suggest less macros in it.  That would allow using it in non-c languages nicer
14:55 whiteknight yes, I plan to have far fewer macros
14:56 whiteknight The new API will only use the standard P S I N types for most operations, though some might take C-strings
14:57 whiteknight all pointers, including interp, are going to be considered opaque
14:59 theory joined #parrot
15:00 atrodo whiteknight++
15:03 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:04 atrodo Why not both?
15:04 whiteknight I am aiming for consistency
15:04 whiteknight though we could have two APIs, one that returns booleans, one that throws exceptions
15:05 whiteknight 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
15:05 atrodo the return value route would be easier and more C-ish
15:06 whiteknight Maybe instead of returning a boolean, I return a PMC. an exception PMC signifies an error.
15:07 atrodo That would be novel
15:07 plobsing whiteknight: then you run into the semi-predicate problem
15:07 whiteknight plobsing: how so?
15:07 plobsing what if I have a PIR routine that returns (not throws) an exception upon success?
15:08 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:09 whiteknight 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:11 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
15:12 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.
15:13 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.
15:14 atrodo whiteknight> And that's a pretty big question
15:14 whiteknight plobsing: sure, but exception handling would be even worse
15:14 plobsing I'd much rather see 'bool = Parrot_ext_vtable_get_bool(interp, pmc, &error)'
15:14 whiteknight Ah, so a generalized result object
15:15 whiteknight result = Parrot_do_stuff(), bool = Parrot_get_bool_result(result)
15:15 whiteknight set result.error on error, result.value otherwise
15:16 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 #parrot
15:20 nopaste "whiteknight" at 192.168.1.3 pasted "very rough example of exception handling API in C" (12 lines) at http://nopaste.snit.ch/24906
15:20 bluescreen joined #parrot
15:20 whiteknight I think that's terrible, personally
15:21 whiteknight and we have to start thinking about threads, etc.
15:22 plobsing on which side of the C/parrot barrier? both?
15:24 whiteknight Well, I guess it depends how Parrot handles it's threads, internally.
15:24 whiteknight I call a function. That function spawns a worker thread. That worker thread throws an unhandled exception.
15:25 whiteknight Does that unhandled exception propagate to the parent thread, or does it call that C-level handler in a separate thread?
15:25 whiteknight then we have cross-thread accesses to hadError
15:27 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:31 plobsing 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:34 lucian joined #parrot
15:52 NotFound Note that in order to avoid propagating exceptions to the caller almost all api functions should have its own exception handler.
16:04 contingencyplan joined #parrot
16:04 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:05 whiteknight 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 whiteknight assuming the interpreter doesn't end up in an inconsistent state, we should be good
16:07 dukeleto howdy
16:08 whiteknight howdy
16:12 NotFound whiteknight: That is efectively the same as setting up a handler.
16:19 whiteknight right, but there are some differences
16:19 whiteknight 1) an unhandled exception doesn't cause death by fire
16:19 whiteknight 2) we define the handlers, instead of asking the user to define them
16:20 NotFound Yes, but setting up one in any api function may be not cheap.
16:21 whiteknight it's not really setting up a handler.
16:22 whiteknight 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 whiteknight instead of fiery death, we go to a longjmp point if it's defined. Otherwise, crash and burn
16:24 dukeleto Crash Override?
16:25 NotFound You need a setjmp at least. And doing it that way disallows the ability to resume the exception.
16:28 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 whiteknight We've already exhausted all options, the exception was not handled, and we are bailing out
16:29 whiteknight 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.
16:29 whiteknight right, but we need to return something reasonable back to the caller
16:29 whiteknight it would be rude to crash or close the program
16:30 whiteknight 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.
16:38 cotto ~~
16:43 dukeleto whiteknight: so your plan is to make a totally new embed/extend api and deprecate the old one?
16:44 cotto Ooh.  This should be good.
16:44 * cotto backscrolls
16:47 whiteknight dukeleto, yessir. That way we can transition over time
16:49 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:50 NotFound dukeleto: mostly that it doesn't exist.
16:50 dukeleto NotFound: what?
16:51 dukeleto NotFound: Please take a look at http://pl.parrot.org, which embed Parrot in Postgres. Our embed/extend API exists.
16:51 dukeleto s/embed/embeds/
16:51 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.
16:52 plobsing dukeleto: it exists but not in a formal way, and definitely not in a well designed way
16:53 NotFound And I don't think there is any working project that uses only the functions declared in extend.h and embed.h
16:54 cotto dukeleto++ #"crash override"
16:56 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:57 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:58 dukeleto 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:59 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.
17:00 dukeleto NotFound: whiteknight is talking about a total rewrite
17:00 whiteknight yeah, going to take an axe to it all
17:01 dukeleto whiteknight: Totalling rewriting it seems unnecessary. I would like to see incremental improvements
17:01 dukeleto whiteknight: you don't have to maintain an embedded project now, so you have no incentive to improve the current interface
17:02 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
17:02 cotto whiteknight, Is there a nice upgrade path for existing users like PL/Parrot?
17:02 dukeleto whiteknight: that is easy to say but hard to prove correct
17:02 whiteknight it's not going to be written instantaneously
17:02 hudnix left #parrot
17:03 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.
17:03 whiteknight switchover can happen gradually
17:03 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?
17:03 cotto perhaps you just answered my question
17:04 hudnix joined #parrot
17:05 whiteknight I
17:05 NotFound Will be good to know what is the lacked functionality, BTW.
17:05 whiteknight 'm going to put together a branch for some initial work tonight, probably. We can see what's going on then
17:06 whiteknight 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.
17:07 NotFound (and please don't tell me "All the string functions")
17:08 whiteknight We do need to do a much better job of exposing our string functions to the external world
17:09 whiteknight we do still need to figure out how to handle error conditions and exceptions being propagated to embedding code
17:09 whiteknight cotto: that might be an area where some kind of design fiat could be handed down from on high
17:10 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
17:11 cotto plobsing, ping
17:12 whiteknight src/exception.c:die_from_exception needs to change radically, in any case
17:15 whiteknight 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.
17:15 whiteknight and I don't think we can call it at all in RTEMS either
17:18 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:19 whiteknight right, de facto behavior is wrong here
17:28 Tene Yes, the parrot binary really needs to be rewritten as just a normal application embedding libparrot
17:28 Tene IMO
17:29 dukeleto Tene: yes, I agree with you
17:38 cotto whiteknight, ping
18:15 brianwisti left #parrot
18:23 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.
18:25 cotto s/OpLib/OpLib PMC/
18:42 whiteknight what value does it return?
18:43 cotto not sure, but I'd expect -1 for anything except a long form op.  lemme check
18:45 cotto For some reason, it return 531 for "say", which maps to does_i_p_pc
18:46 whiteknight what are you calling to get that result? VTABLE_get_integer_keyed_str?
18:46 cotto nm
18:46 whiteknight ?
18:46 cotto it returns the number for say_i if I ask for "say"
18:46 cotto yes
18:47 whiteknight for the lookup it calls oplib->_op_code(interp,
18:47 cotto nopaste coming
18:47 whiteknight "say", 1
18:47 whiteknight ah, I think I see it
18:48 whiteknight oplib->_op_code takes a bool for the second arg that specifies whether to look up by shortname or long name
18:48 cotto http://nopaste.snit.ch/24917
18:48 whiteknight first we only look up by long name, then by shortname if that fails
18:48 whiteknight check out like 69 in that file
18:48 cotto right.  I'm asking if that's a useful behavior.
18:49 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.
18:49 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?
18:49 cotto it currently returns -1 for keyed access
18:50 whiteknight ah right, this one returns an INTVAL
18:50 whiteknight okay, howabout change that to return -1, and not lookup by shortname
18:51 cotto sure
18:51 cotto I'll dig around and see what I can find wrt why it does the short name lookup
18:52 silug joined #parrot
18:53 whiteknight ok
18:53 jsut_ joined #parrot
18:54 fperrad_ joined #parrot
18:55 cotto It seems like one of those features that could have been bolted on just because it was easy.
18:57 whiteknight it is something that really doesn't make sense now that I am thinking about it
18:57 whiteknight I vote for removal, I suppose
18:58 jsut left #parrot
18:58 fperrad left #parrot
18:58 fperrad_ is now known as fperrad
19:01 whiteknight all anybody has to do is delete lines 68 and 69 from that file
19:02 cotto and make sure there wasn't a good reason for them in the first place
19:03 whiteknight I suspect strongly that there is not
19:04 whiteknight We may want a similar functionality to look ops up by shortname in IMCC, but we're not ready for that yet
19:04 whiteknight the more we can keep IMCC from poking directly into structure guts, the better
19:06 dukeleto Death to IMCC.
19:13 whiteknight no argument here
19:14 dukeleto #ps soon?
19:14 dukeleto or am i an hour early again?
19:15 cotto in 75
19:15 lucian_ joined #parrot
19:17 whiteknight yay! I posted my first #ps report in months
19:17 whiteknight of course, I still won't be at the meeting
19:19 lucian left #parrot
19:22 snarkyboojum left #parrot
19:22 bluescreen left #parrot
19:22 snarkyboojum joined #parrot
19:23 PerlJam left #parrot
19:23 PerlJam joined #parrot
19:28 dalek parrot: r49683 | cotto++ | branches/opmap_aware_pmcs (3 files):
19:28 dalek parrot: [pmc] initial versions, mostly stub code with some untested implementations
19:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49683/
19:28 dalek parrot: r49684 | cotto++ | branches/opmap_aware_pmcs/src/pmc/oplib.pmc:
19:28 dalek parrot: [pmc] add some methods that will be needed by PackfileBytecodeSegment
19:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49684/
19:28 dalek parrot: r49685 | cotto++ | branches/opmap_aware_pmcs/exa​mples/pir/make_hello_pbc.pir:
19:28 dalek parrot: [examples] update make_hello_pbc.pir to use the interface I plan on implementing in this branch
19:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49685/
19:38 chromatic joined #parrot
19:40 bluescreen joined #parrot
19:42 whiteknight dukeleto: I think we are serious about Google Code-In
19:42 whiteknight I think we have to be serious about any program that drives contributors towards us
19:45 bacek left #parrot
19:54 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:56 whiteknight it might be interesting to try branching out on our own for it
19:57 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
19:57 cotto It depends on how our community manager feels though. ;)
19:58 whiteknight this is true
19:59 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).
20:00 dalek parrot: r49686 | cotto++ | branches/opmap_aware_pmcs/src/pmc/oplib.pmc:
20:00 dalek parrot: [pmc] don't try to look for short op names if the long name lookup fails
20:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49686/
20:00 dukeleto cotto: yes, correct.
20:00 whiteknight chromatic: Yeah, I saw some of the sweep-free code he had in there. I was very happy about that
20:00 dukeleto i am talking to TPF about getting a grant for it
20:00 dukeleto I just don't have time for Code-In unless I get paid.
20:00 dukeleto but the application deadline is the end of the week, and TPF moves slowly.
20:00 chromatic I'll make a branch and add a couple of lists to the MS2 struct and see what I can do.
20:00 cotto they do.
20:01 * dukeleto may miss some of #ps due eating lunch with the Git peeps
20:01 kid51 joined #parrot
20:01 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?
20:01 dukeleto cotto: perhaps, but that might be more work than doing it myself
20:02 dukeleto cotto: unless the person has some experience doing these kind of things
20:02 sorear kid51: hi
20:02 whiteknight dukeleto: is it really a lot of work?
20:02 cotto A higher bus number is always a good thing.
20:02 dukeleto whiteknight: You have no idea.
20:03 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
20:03 dukeleto I've never done Code-In, because this is the first year. No one has.
20:03 dukeleto But judging from doing GSoC for the last 2 years, it is a good amount of work.
20:03 cotto Right, so there's be lots of people asking all the relevant questions.
20:03 whiteknight so all the more reason why a new person could grab it and run
20:03 dukeleto whiteknight: I am putting on my lollerskates and I will grab the back bumper and get a free ride
20:03 atrodo whiteknight> That's so strange, so am I
20:04 dukeleto I am only going to be an admin for Code-In. I need lots of mentors.
20:04 dukeleto and people to delegate to
20:04 whiteknight I'm always happy to mentor
20:04 dukeleto I will not mentor for Code-In. I just don't have the time.
20:04 * cotto too
20:04 whiteknight brb, I have to turn off my computer
20:04 whiteknight left #parrot
20:04 dukeleto We need to be coming up with tiny tasks for students: improve parrot.org, translate some docs, etc...
20:04 nwellnhof joined #parrot
20:05 dukeleto I need to write an application that links to a list of tasks for students by Friday
20:05 dukeleto Can somebody volunteer to make a wiki page for those?
20:05 dukeleto I will write the app, but I need help coming up with tasks
20:05 cotto another good #ps question
20:08 allison joined #parrot
20:09 cotto hio allison
20:09 allison hiya cotto
20:12 atrodo everyone needs more minions
20:15 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:23 Andy joined #parrot
20:27 fperrad left #parrot
20:29 tcurtis joined #parrot
20:44 Topic for #parrot is now Parrot 2.9.1 Released | http://parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: http://nopaste.snit.ch:8001 | remove deprecations | volunteer for embedding or Lorito teams |
20:50 plobsing_ joined #parrot
20:53 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?
20:55 plobsing_ not as far as I could determine. I linked against parrot_config.o with no effect.
20:55 plobsing_ I suspect parrot isn't being initialized properly
20:56 cotto plobsing_, that makes sense
20:56 cotto it's a little surprising but understandable.
21:03 bacek joined #parrot
21:16 bluescreen left #parrot
21:22 plobsing_ left #parrot
21:31 bluescreen joined #parrot
21:36 Andy left #parrot
21:54 preflex left #parrot
21:55 hudnix left #parrot
21:57 preflex joined #parrot
21:57 hudnix joined #parrot
21:58 kid51 left #parrot
22:01 dukeleto mikehh: i added an example task to your wiki page
22:04 dukeleto we still dont' get wiki changes in here => :(
22:05 allison left #parrot
22:11 nwellnhof left #parrot
22:20 donaldh joined #parrot
22:21 donaldh Hi, I have a question about NCI
22:21 chromatic go ahead
22:22 donaldh back in Parrot 1.x days (IIRC) I could add NCI thunks by adding a file to config/gen/call_list/
22:22 donaldh That seems to have gone.
22:22 donaldh What's the right approach now?
22:23 donaldh I see src/nci/core_thunks.nci and src/nci/extra_thunks.nci
22:23 chromatic See the src/nci/*.nci
22:23 chromatic Yes.
22:23 donaldh Should I just be editing those?
22:23 chromatic extra_thunks for everything except what core parrot needs, I believe
22:24 donaldh k
22:24 donaldh thanks
22:26 donaldh Should I be going a stage further and compiling my extra thunks as a dynext ?
22:31 chromatic To my knowledge, you'd be the first to do so.  That's interesting though.
22:32 brianwisti joined #parrot
22:34 dukeleto donaldh: there is a gsoc_nci branch that is very close to being merged, which uses libffi
22:34 dukeleto donaldh: you may perhaps want to look at that
22:34 donaldh there is parrot_install/bin/parrot_nci_thunk_gen that will produce a C file for dynext
22:34 donaldh dukeleto: oh
22:37 donaldh dukeleto: that is interesting. very close to merge? I might wait for that.
22:38 dukeleto donaldh: i think there is just 1 failing test left on the branch. Maybe you want to fix it ? ;)
22:38 dukeleto donaldh: it might get merged faster if you fix that failing test :)
22:38 nwellnhof joined #parrot
22:38 bacek_at_work aloha, humans
22:39 brianwisti left #parrot
22:39 donaldh dukeleto: that might happen :-)
22:41 mikehh dukeleto: I am not thinking too clearly at the moment, need some sleep, will get back to GCI later
22:42 dngor left #parrot
22:42 dngor_ joined #parrot
22:45 bluescreen left #parrot
22:50 dalek parrot: r49687 | nwellnhof++ | trunk/t/pmc/io_stdin.t:
22:50 dalek parrot: [t] Make t/pmc/io_stdin.t pass on Windows
22:50 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49687/
23:03 donaldh dukeleto: have checked out gsoc_nci branch. I'll take a look tomorrow. goodnight.
23:05 dngor_ left #parrot
23:12 donaldh left #parrot
23:22 dalek parrot: r49688 | nwellnhof++ | trunk/src/embed.c:
23:22 dalek parrot: [codingstd] Add missing ASSERT_ARGS
23:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49688/
23:31 whiteknight joined #parrot
23:40 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:42 whiteknight which branch is this?
23:43 plobsing gsoc_nci
23:43 whiteknight ah, gotcha
23:43 plobsing the bug is the same kind that caused us to ditch the old frame builder
23:43 plobsing I think I have a new plan though
23:43 whiteknight what's the bug? need another set of eyes?
23:44 plobsing completely wrong PCC signature for a given NCI signature
23:44 plobsing my plan: separate out the parser from the rest. use lex or something like it.
23:45 whiteknight ok
23:45 chromatic How completely wrong?
23:45 plobsing extra S parameter IIRC
23:46 plobsing P parameter where it shouldnt' be either
23:46 plobsing again, going from memory. I took a couple days off of that.
23:47 plobsing 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:48 plobsing s/based//
23:53 chromatic left #parrot
23:53 dalek parrot: r49689 | whiteknight++ | branches/embed_api (2 files):
23:53 dalek parrot: creating a new branch to start working on the new embedding API stuff
23:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49689/
23:53 dalek parrot: r49690 | whiteknight++ | branches/embed_api/src/embed_api.c:
23:53 dalek parrot: adding in a new stub file of embedding API functions I'm playing with
23:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49690/
23:53 dalek parrot: r49691 | whiteknight++ | branches/embed_api/src (2 files):
23:53 dalek parrot: move the load_bytecode_file function into the new API. Rename it to match
23:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49691/
23:56 bacek_at_work whiteknight, deprecation cycle. You have to keep old Parrot_load_bytecode_file (preferably redirecting to Parrot_api version)
23:57 whiteknight bacek_at_work: that function was added two days ago
23:57 bacek_at_work whiteknight, ah, ok.

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

Parrot | source cross referenced