Camelia, the Perl 6 bug

IRC log for #parrot, 2011-11-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:10 dalek rakudo/nom: 9544769 | Coke++ | t/spectest.data:
00:10 dalek rakudo/nom: Splice was implemented, run (fudged) tests
00:10 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9544769b61
00:21 u2011 joined #parrot
00:28 u2011 left #parrot
00:41 nn joined #parrot
00:42 nn left #parrot
01:17 whiteknight joined #parrot
01:28 benabik joined #parrot
01:34 soh_cah_toa joined #parrot
02:38 cotto ~~
03:00 jsut joined #parrot
05:04 nbrown joined #parrot
05:59 lateau joined #parrot
06:10 schmooster joined #parrot
06:55 dalek rakudo/nom: a2e2b96 | moritz++ | / (4 files):
06:55 dalek rakudo/nom: Get rid of nqp::want usage in the setting
06:55 dalek rakudo/nom:
06:55 dalek rakudo/nom: Also switches pir:: ops to nqp:: ops and adds return type annotations
06:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a2e2b96ead
07:19 rfw joined #parrot
07:25 lateau joined #parrot
07:56 woosley joined #parrot
08:39 mj41 joined #parrot
09:24 lucian joined #parrot
09:38 woosley left #parrot
09:46 lateau1 joined #parrot
10:14 dalek nqp: 4bc5cae | moritz++ | src/PAST/NQP.pir:
10:14 dalek nqp: bitwise str nqp:: ops
10:14 dalek nqp: review: https://github.com/perl6/nqp/commit/4bc5cae4eb
10:17 dalek rakudo/native-str-ops: 010ed9a | moritz++ | / (2 files):
10:17 dalek rakudo/native-str-ops: add native str ops, add return type annotations, and use nqp:: opcodes for string bitwise ops
10:17 dalek rakudo/native-str-ops: review: https://github.com/rakudo/rakudo/commit/010ed9a229
10:39 dalek TT #1720 reopened by kurahaupo++: fdiv_i_i_i and fdiv_i_i ops don't work correctly.
10:39 dalek TT #1720: http://trac.parrot.org/parrot/ticket/1720
11:36 lateau joined #parrot
11:38 Psyche^ joined #parrot
11:50 benabik joined #parrot
12:02 whiteknight joined #parrot
12:09 whiteknight good morning #parrot
12:10 whiteknight Interesting article from intel about the performance of memcpy in GCC: http://software.intel.com/en-u​s/articles/memcpy-performance/
12:13 benabik o/ whiteknight
12:17 whiteknight good morning, benabik
12:17 tadzik good morning #parrot
12:20 whiteknight hello tadzik
12:35 JimmyZ joined #parrot
12:51 benabik_ joined #parrot
12:51 benabik joined #parrot
12:51 benabik_ joined #parrot
12:54 mls hi whiteknight!
12:54 mls I've a question about exceptions for you
12:55 man_in_shack joined #parrot
12:55 * man_in_shack waves
12:57 man_in_shack once again i find myself wanting to develop my own programing language
12:57 man_in_shack and the only tools i'm aware of to assist me are flex/bison and parrot
12:57 moritz hello
12:57 moritz what kind of language do you want to develop?
12:58 man_in_shack long-term goal is to have fancy stuff like classes
12:59 man_in_shack but more importantly, i want it interpreted or at least compiled to bytecode, and embedable into other applications
13:00 moritz do you want it typed at runtime or at compile time?
13:00 moritz (ie "dynamic" or "static" language)
13:00 man_in_shack at the moment, compile time
13:02 moritz parrot isn't really optimized for that case, but you can still use it for that
13:02 * benabik wants more static typing support.
13:03 benabik And since I seem to be designing/writing the next set of compiler tools, I guess I'll get it.  :-D
13:03 man_in_shack oh, i misinterpreted, sorry
13:03 man_in_shack dynamic
13:03 * man_in_shack is tired
13:05 whiteknight mls: sorry for the delay. What do you need?
13:06 man_in_shack BRAAAAAAIINS
13:09 man_in_shack i guess i could write a preliminary AND SLOW interpreter in a language i know
13:09 man_in_shack like python
13:09 benabik You could write a preliminary interpreter in a language you don't know.  I find that to be fun.  :-D
13:09 * benabik likes learning languages.
13:10 man_in_shack i tried parrot somewhere around 1.x and gave up on it after not very long
13:10 atrodo like bf or intercal
13:10 man_in_shack everything should be written in bf
13:10 benabik atrodo: I tend to suggest Haskell, but those "work" too.
13:10 benabik (fsvo of work)
13:10 pbaker joined #parrot
13:10 atrodo i'm waiting for the parrot rewrite in bf
13:11 * benabik seems to recall seeing programs written in bf and whitespace in the same file.
13:11 man_in_shack my problem back then was i could handle the asm-like PIR(?) stuff but couldn't get my head around mapping that to an interpreted language construct
13:12 benabik PCT helps build language constructs and handles the dirty work of making it into PIR.
13:12 benabik (Don't know if that was around back then.)
13:12 whiteknight PCT has been around for a long time
13:13 man_in_shack i attended a lecture on parrot at the 2006 linux conf au
13:13 man_in_shack got quite excited about it
13:13 man_in_shack then had trouble doing anything useful with it :D
13:14 atrodo man_in_shack> Have you gone through the squaak tutorial?
13:14 man_in_shack i did at some point
13:14 man_in_shack and it confused me
13:15 benabik man_in_shack: We're starting a new push on documentation.  If you could give us notes about what you found confusing, it would be appreciated.  :-)  And we can try to help remove the confusion.
13:15 man_in_shack ok
13:15 man_in_shack guess i need to try again then :D
13:16 man_in_shack where's the latest squaak tut?
13:16 benabik I was assuming you were willing to start again since you showed up here.  :-)
13:16 atrodo https://github.com/ekiru/squaak-tutorial I believe
13:17 benabik atrodo: The description of the repo says it's out of date.  :-/
13:18 benabik http://docs.parrot.org/parrot/​latest/html/pct_tutorial.html is the more "official" one.  Not sure how they differ.
13:19 man_in_shack deb unstable has parrot 3.6
13:20 benabik …  Optimizer?
13:21 man_in_shack hm?
13:21 benabik Is slow still the default runtime?
13:22 benabik Sorry, I just discovered that IMCC claims to have an optimizer.
13:22 benabik *runcore
13:22 benabik We probably need to take a good look at docs/running.pod.  I think it's full of lies.
13:25 man_in_shack http://dpaste.com/646709/ << whee
13:25 benabik Although I think it's a reasonable candidate for turning into parrot.1
13:25 mls (the default runcore seems to be "fast")
13:25 mls (see parseflags() in parrot2/main.c)
13:27 whiteknight mls: yeah, the fast core is the default
13:28 whiteknight it's a basic function-based runcore.
13:28 mls parrot's ops are surprisingly fast, as long as you don't allocate a PMC
13:30 man_in_shack so how do i fix this error then?
13:30 benabik man_in_shack: Is that from debian's parrot package?
13:31 man_in_shack yup
13:31 benabik man_in_shack: There should be a osutils.pbc in /usr/lib/parrot/3.6.0/library
13:31 mls whiteknight: about that exception question: I implemented a "pop_upto_eh <exception>" op that pops all handlers until the one is found that handled the exception. This is very useful if you don't plan to do a return after the exception was caught, as you don't know how many handlers have been pushed.
13:32 benabik If the file is not there, then the debian package is missing files.  If the directory isn't, then I don't know where debian is putting our files.  If it is, then something off with the library paths.
13:32 moritz is there maybe a parrot-dev package too?
13:32 man_in_shack benabik: the file's not there
13:33 mls I am wondering if that behavior should be the default, i.e. if parrot should always pop the "excess" handlers. But that means that we have to store a copy of the handler array in the exception, so that we can restore the handler in the rethrow/resume case
13:33 benabik moritz++
13:33 benabik man_in_shack: You may need to install parrot-devel
13:33 man_in_shack i have already
13:34 mls Thus exception throwing would be a bit more expensive. Rakudo doesn't benefit from the change, as Rakodo's exception handling is completely different from parrot. So I don't know if making exception handling saner is good or bad.
13:34 man_in_shack dpkg -S isn't reporting any osutils.pbc file, so no package has it installed
13:35 man_in_shack and i had no luck finding it on packages.debian.org either
13:35 benabik The debian package missing files.  Don't know how to fix that.
13:35 mls (compile your own parrot ;) )
13:36 benabik Well that's the work around for sure.
13:36 man_in_shack yah
13:37 benabik man_in_shack++ # bug report
13:37 * benabik opens an issue.
13:38 man_in_shack who's bugging what now?
13:40 ambs joined #parrot
13:48 man_in_shack just updating my sid32 chroot to see if it's the same problem there
13:49 benabik man_in_shack: It's an issue with the debian packages.  Parrot's not that hard to build from source: http://parrot.org/download
13:49 whiteknight mls: good question. Making the behavior more sane is a good idea, but exceptions already have terrible performance and making them worse will not go over well
13:50 whiteknight mls: Implement your op, and we'll see if it makes sense for us. I suspect it will be a good idea, but I want to see it in action
13:51 dalek rakudo/nom: c838c1c | moritz++ | src/core/Int.pm:
13:51 dalek rakudo/nom: fix copy/pasto in native int op name, mls++
13:51 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c838c1c1a9
13:52 mls the op doesn't have a cost. the problem is that if we make it default, we need to restore the handlers
13:52 mls when we do a rethrow/resume
13:52 whiteknight okay
13:53 mls currently the op can't be used if one wants to resume the exception later on
13:54 mls cause resume breaks if the handlers are changed
13:54 mls (that's true for all continuations)
13:54 benabik mls: You probably want to pop the handlers as the last thing before leaving, not as the first thing when entering.
13:54 * benabik ponders if continuations should hold onto their handlers...
13:55 mls (continuations that jum back in the call chain are ok, continuations that jump forward are very dangerous)
13:56 lateau1 joined #parrot
13:56 mls actually I think for most exceptions handlers it would make sense to pop the handlers right away, so that exceptions thrown in the exception handler don't get caught by the same handler leading to a loop
13:56 mls (Rakudo solves this in a different way, so all this doesn't apply)
13:56 benabik Continuations are conceptually supposed to hold on to the entire state of the program at a given moment.  If their behavior depends on what others do, that would be somewhat surprising.
13:58 man_in_shack ♫ round and round the infinite loop, the program chased exceptions. where it stops, nobody knows! pop goes the handle ♫
13:58 mls ;)
13:59 benabik That's an excellent point.  Generally rethrows should go up the chain, not start at the bottom again.  Perhaps we need a pointer to where we are in the chain…  Throwing would start at that point again, and finalize (or a new op) could toss everything below.
13:59 benabik (i.e. delay the expensive alterations of the stack until it's required)
13:59 mls rethrows dont' start at the bottom. I'm talking about new exceptions
14:00 benabik I don't view those as terribly different things.  :-D
14:00 benabik (I'll admit Parrot might.)
14:00 benabik But wrapping an exception and re-throwing is a common idiom in several language.
14:00 benabik (Er, throwing the new one farther up.)
14:01 mls yes, most languges implement that "pop the handlers" semantics I proposed.
14:02 mls so rethrow == throw
14:02 benabik This comes back to me being surprised that continuations don't manage exception handlers.  I would expect an EH to run in its own context, including handlers, not the context of the exception.
14:03 mls they don't run in the context of the exception, they run in the context of the EH
14:03 man_in_shack now i'm not sure what exactly is being talked about
14:03 benabik But that context doesn't include the state of the EHs.
14:04 man_in_shack but is there a case where you would want a handler to be reused after an exception is thrown?
14:04 benabik That's the exception's context leaking into the handler, IMHO.
14:05 mls well, currently nqp implements 'next' et al with control exceptions, that won't work if we create a new context when an exception is caught
14:06 mls (That's also why I proposed to pop all the handlers up to the one that caught the exception, so that the programmer can have it both ways)
14:06 mls (just add a pop_eh if you want the current handler to be popped as well)
14:07 benabik You'd have to give the handler an array of everything that was popped so it can be restored later.
14:07 mls not the handler, but the exception
14:08 mls the resume or rethrow method would restore the handlers
14:08 mls that that's a new ResizablePMCArray PMC, so it's not cheap
14:08 mls but that's...
14:08 lateau joined #parrot
14:08 benabik Well, since the handler has the exception, so that's a way to give it over.
14:09 benabik How are the handlers stored currently?
14:09 mls A ResizeablePMCArray in the CallContext
14:09 benabik Bleh.
14:09 benabik Mutable state strikes again.
14:09 mls (it's a bit overkill if there's just one handler)
14:10 benabik It would be cheap if it was maintained as a linked list.
14:11 benabik But we're already maintaining an index into it for rethrow, aren't we?
14:11 mls So the super-correct implementation would be that *every* continuation stores a list of all handlers, even the return continuations. But that's very expensive.
14:11 benabik mls: It's cheaper if they share common parts.  Linked lists are awesome like that.
14:12 moritz ... and then you want to change one of the elements
14:12 mls Yes, we generate an ArrayIterator when we search for an exception handler that can handle the exception
14:12 mls that's also expensive...
14:12 benabik moritz: I thought the only interface into it was push and pop.
14:12 benabik Oh, we provide raw access to the RPA, don't we?
14:12 mls We just store that iterator in the Exception when we found the correct handler
14:14 mls As it's just an PMC we can use all methods including random access
14:15 mls so we could improve exception handling a bit by not using an ArrayIterator
14:16 mls but I don't think that would gain much, I doubt we have to check many handlers before finding the right one
14:16 benabik Copying around an RPA feels very heavy for something so common.
14:17 mls (still, we could write the index into the exception instead of the iterater and thus get rid of one pmc)
14:17 mls yeah, that's why I don't like it very much. Putting it in all continuations would be correct, but is completely out of the question. Much too expensive
14:18 benabik Well, you'd have to make them cheaper.  RPA optimizes for random changes, but the common operations are push and pop.
14:19 mls well, I'm talking about a VTABLE_clone of the RPA if an exception is caught
14:19 benabik And most contexts share a common prefix of handlers, so we're copying that around a lot.
14:20 mls what? why should they share a common prefix?
14:20 benabik When you call a function, doesn't it keep around the handlers from you?
14:20 benabik Or do we store handlers for each context separately?
14:20 mls separately
14:21 benabik Ahhhhh....
14:21 mls so not many contexts have handlers attached
14:21 benabik I expected a single stack for the current continuation.
14:21 mls and the RPAs are pretty small
14:21 benabik Yeah.
14:23 mls Hmm, we really can get rid of that iterator and make exception handling a bit faster
14:23 mls I should patch parrot to do this independent of any other change
14:23 mls we could also easily change parrot to use an RPA only of more than one handler has been pushed
14:24 benabik Using an iterator for an RPA seems a little excessive.  Ints are your friend.
14:24 mls yes
14:24 benabik And avoiding the GCable in the small case is probably a good idea.
14:24 benabik mls++
14:24 mls we could check the base_type it it's a RPA or a handler
14:24 whiteknight so long as we only use built-in types, base_type can work
14:24 mls and store the handler in place of the RPA if the context uses only one handler
14:25 benabik Do we push arbitrary objects as handlers?
14:25 mls yes, I think so
14:25 benabik That does make it a bit more difficult to distinguish then.
14:25 mls we can detect the RPA, an RPA cannot be a handler ;)
14:26 mls and RPA is pretty much hardcoded
14:26 benabik True.
14:26 benabik And if the user pushes an RPA and expects it to handle exceptions, something's a little strange.
14:26 mls right ;)
14:27 mls (we could even handler that: always create the RPA if the handler is an RPA)
14:27 mls handle
14:27 cosimo joined #parrot
14:28 benabik What does it do if you push an RPA now?  Explode if you throw?
14:28 mls checking the code...
14:29 mls it calls the can_handle method
14:29 mls as there's no such method it'll throw another exception
14:29 mls thus it'll loop I guess
14:29 benabik :-(
14:30 mls well, so don't push things that don't implement can_handle ;)
14:30 jsut_ joined #parrot
14:30 benabik Being that easy to get Parrot to just loop is bad.
14:31 benabik It's a reasonable argument for saying exceptions when handling exceptions should not start at the same place.
14:31 mls IMHO it's a "doctor it hurts when I do this" case
14:32 moritz you can't guard against too many things at the low level
14:32 moritz otherwise you'll slow down stuff
14:32 mls (that's about pushing hon-handlers)
14:32 moritz so if you think that case should be caught, please only in debug builds
14:32 mls the discussion seems to be back at "catching exceptions in handlers"
14:32 benabik Well if you're in the "find exception handlers" section of code and you have a problem, throwing an exception starting at the same place is pretty much brain dead since you'll just hit the same problem again.
14:33 mls oh, that's true. looking at the code again...
14:33 mls there's a guard against that already implemented
14:34 benabik \o/
14:34 mls so I think it won't loop
14:34 mls of course the guard is not thread-safe ;)
14:35 mls it uses some static vars
14:35 benabik oog
14:35 benabik But, anyway, the question was motivated by saying that instead of putting RPA inside RPA, we could treat an RPA as a list of handlers to push.  And clone it at "no current handlers" point.
14:36 mls uh, now you lost me
14:36 benabik You were saying that if they push an RPA, we could put the RPA in an RPA to handle the edge case.
14:36 benabik But if pushing an RPA is pointless, then we can treat it as a list of handlers instead of a handler itself.
14:37 benabik Random idea, really.
14:37 mls yes, we could do that
14:37 mls (I don't know of a use caase, though)
14:38 mls case
14:38 benabik Fair enough.
14:38 mls okay, so i'll implement those optimizations.
14:39 mls (that doesn't solve the original problem, though.)
14:40 mls (i.e. that we currently don't touch any handler when an exception is caught, and thus new exceptions occuring in the handler code may create loops)
14:41 mls (and a different but related problem was that continuations jumping forard in the call chain are really dangerous)
14:42 mls I got bitten by that once, I resumed the exception after the pop_eh of the handler was done -> boom
14:43 mls cause after the resume we will return into the context at some point and then do another pop_eh -> "No exception to pop"
14:45 mls (Thus havind a list of exception handlers in the context is kinda bad. I like the idea of doing exception handlers with code annotations.)
14:45 mls having
14:45 benabik Well, if we can keep the index of the current handler around, we can somewhat "pretend" it was popped.  Throws use that index as its starting point.
14:46 benabik Avoids the expensive copying and alteration.  Might cause other issues.
14:48 benabik Looking it up in a code annotation seems like it might be a bit slow.  And is impossible for dynamic handlers.
14:48 mls yes
14:48 mls I don't know where to store that index
14:49 mls and what if the handler does a push_eh
14:50 benabik In the context?  Then the exception keeps a copy and restores it when resumed.  Cheaper than copying around an RPA.
14:50 benabik I guess that's when you'd actually have to modify the handler list.
14:50 benabik Hm.  The exception would have to notice when the list changes.  :-/
14:53 benabik Hm.  rethrow takes an arbitrary exception.
14:54 mls yes. You if an exception occurs in the exception handler you can rethrow any of them
14:54 cosimo joined #parrot
14:55 benabik Well, it's been fun brainstorming, but I really really need to finish a paper.
14:55 mls ok, good luck with the paper!
14:56 benabik I think the issue is that we're mixing CPS with non-CPS.  If exception handlers were themselves continuations, it would be easier.  But continuations are too expensive for that, I guess.
14:57 mls exception handlers are continuations
14:57 mls the problem is that they have to be stored in the context
14:57 whiteknight continuations are too expensive right now, and we need to fix that
14:58 mls why are they expensive?
14:58 benabik I'm not sure why the EH stack isn't a linked list of all handlers in the continuation.  That's where I'd expect them.  Handlers are part of the current state of execution, and a continuation is supposed to be that state.
14:58 benabik (I'm back to my leaking context complaint.  Yes, I'm circular.)
14:59 moritz circular logic is the best kind of logic. Because it's circular.
14:59 benabik moritz++
14:59 benabik I could expound more, but writing.  (Arguing on the internet is more fun than writing papers.)
15:00 mls Hmm, using a linked list means that you can't re-use an exception handler
15:00 mls (If the link is in the handler)
15:01 benabik Things can be in a linked list more than once.
15:01 benabik (Put the handler in twice, not the cons cell.)
15:02 mls That means push_eh always allocates a cons cell
15:03 mls and the continuation stores the tail cell, and restores the cell when it is invoked
15:03 benabik Cons cells should be cheap.  Two pointers.  Current GC design may make this not cheap, I'll admit.
15:04 whiteknight the fixed-size allocator should be relatively cheap to get cells of a fixed size
15:04 whiteknight I'm not as familiar with it as I used to be
15:04 * benabik knows nothing about the details of the GC.
15:05 benabik I'm always afraid that dealing with the GC involves creating entire PMCs.
15:05 benabik (Which shouldn't be a fear.  They should be cheap since we use them everywhere, but that gets back to 6model integration.  :-D)
15:05 mls you don't have to. You can just attach it to another PMC, in that case the continuation PMC
15:06 mls hmm
15:07 whiteknight yeah, if you attach the linked list to a PMC, you can destroy the linked list on PMC destroy
15:08 mls I don't know where to put it in our case
15:08 nnunley joined #parrot
15:08 benabik I think I'm talking about a large change to how we do EHs.  :-/
15:08 benabik I am musing randomly while avoiding a paper.  :-)
15:09 mls hurry, quit irc or you'll miss the deadline
15:09 benabik … quit IRC?
15:09 benabik ;-)
15:10 mls Is that an "I'd rather miss the paper's deadline"? ;-)
15:10 benabik I'm not sure I can make the deadline.  Eh.
15:10 mls just blame parrot ;)
15:10 benabik It's the cool thing to do.
15:11 nnunley joined #parrot
15:13 JimmyZ joined #parrot
15:24 whiteknight all the cool kids are doing it
15:24 whiteknight some of the uncool kids too
16:41 dalek parrot/mls/kill-events-in-ehqueue: 3456ac0 | mls++ | / (9 files):
16:41 dalek parrot/mls/kill-events-in-ehqueue: Get rid of the iterator PMC when iterating through the exceptions handlers.
16:41 dalek parrot/mls/kill-events-in-ehqueue:
16:41 dalek parrot/mls/kill-events-in-ehqueue: Instead of the iterator we store the number of handlers left in the Exception.
16:41 dalek parrot/mls/kill-events-in-ehqueue: Also, a new experimental op was added, "pop_upto_eh". It pops all handlers
16:41 dalek parrot/mls/kill-events-in-ehqueue: until it reaches the current handler of ther specified exception.
16:41 dalek parrot/mls/kill-events-in-ehqueue: review: https://github.com/parrot/parrot/commit/3456ac087f
16:43 mls now we just have to get rid of that Parrot_pcc_invoke_method_fr​om_c_args(..."can_handle")
16:45 lateau joined #parrot
16:48 mls hmm, we could mis-use the is_equal VTABLE in exceptionhandler.pmc ;)
16:49 benabik Is pcc_invoke_method much slower than using a VTABLE?
16:49 mls I think it allocates a callcontext
16:50 mls I may be wrong, though
16:50 mls I know it's slower, but I don't know how much. whiteknight++ did some benchmarks
16:52 mls yep, it allocates a CallContext
16:52 benabik And VTABLEs dont?
16:52 mls no
16:53 benabik Interesting.
16:53 mls a VTABLE call is pretty much a C function call
16:53 benabik Which can be overridden to do invoke_method.  I see.
16:54 mls then it's slow again ;)
17:00 mls we could also use VTABLE_does_pmc ;)
17:00 mls to check if the exception handler "does" the exception
17:01 benabik Changing how we interrogate handlers has a chance of breaking HLLs.  Should look into that.
17:01 pbaker joined #parrot
17:01 benabik Although most of those sound a little hacky.  :-)
17:12 dukeleto msg NotFound is the best way to embed POD in .winxed files to wrap it in a multi-line comments? such as /*\n$POD\n*/
17:12 aloha OK. I'll deliver the message.
17:23 benabik joined #parrot
17:25 cotto ~~
17:31 NotFound dukeleto: is what we do in C files, so I guess is fine for winxed.
17:32 dukeleto NotFound: yep, already merged the pull request :)
17:32 dukeleto NotFound++ thanks for the help with setup.winxed for cardinal
17:35 NotFound dukeleto: thanks for cardinal contributing for winxed world domination ;)
17:38 contingencyplan joined #parrot
18:00 lateau joined #parrot
18:04 nbrown joined #parrot
18:07 not_gerd joined #parrot
18:07 not_gerd hello #parrot
18:10 mls hi not_gerd!
18:10 mls another idea: shouldn't handle_types and handle_types_except take a key as argument?
18:11 mls preferable a const key
18:12 not_gerd mls: hi
18:12 not_gerd dukeleto: care to explain why you closed https://github.com/parrot/parrot/pull/191 ?
18:15 NotFound mls: how will you pass a const key to a method in pir?
18:16 mls isn't that a PMC?
18:18 NotFound mls: Is that an answer?
18:18 mls yes. ;) it seems to work for VTABLEs
18:18 moritz "just like any other PMC"?
18:20 mls I just thought it might be consistent with other usages of keys
18:20 NotFound "PIR". I mean syntax.
18:21 mls Dunno, I don't know what imcc currently does. Can it only create string type keys?
18:22 mls (imcc, my old nemesis, we meet again ;) )
18:22 NotFound Pir does some black magic in some opcodes. The syntax for sub and method calls is not an opcode.
18:23 NotFound And I seriously doubt any one is liking to create more pir sugar.
18:24 mls hey, it's just pir ;)
18:24 NotFound mls: yes, just pir, but the pir compiler is imcc ;)
18:24 mls oh, I've got imcc patching experience by now ;)
18:24 fperrad joined #parrot
18:25 mls hmm, leys see what imcc generates when I use [1;2;3] in a method call
18:26 mls ts ts, it doesn't like it
18:27 mls back to the imcc.y file
18:28 NotFound mls: if you really like the idea you should start by proposing the changes to imcc, yes.
18:32 mls oh wait, it doesn't need to be a method call
18:33 mls the new op can take an PMC argument
18:33 mls much better, as in that case we also don't need the CallContext PMC
18:35 mls we could even set the min and max severity ;)
18:36 NotFound mls: with just a key? How so?
18:36 mls we need two new constants ;)
18:36 mls [.MINSEVERITY;5;.CONTROL_NEXT]
18:36 mls ok, I admit that's a gross hack ;)
18:37 mls I don't think the severity is often used
18:38 mls anyway, enough strange ideas for today -> heading home
18:38 NotFound pmc_init taking a key can be useful. For example, int positive values giving handle_types and negatives giving handle_types_except, for example.
18:38 mls oh yes, good idea
18:39 benabik joined #parrot
18:39 NotFound A hack, yes, but for code generated from HLLs not so bad.
18:39 mls I thought of a .TYPESEXCEPT pseudo-entry
18:39 mls it doesn't make sense to have both types and types_except anyway
18:40 mls but yes, using negative values is another option
18:41 NotFound handle_types_except is not used if handle_types is set to non null, but nothing disallow doing it.
18:46 mls ok, as said, heading home. talk to you tomorrow
19:03 fperrad joined #parrot
19:13 dalek winxed: 1e0cb9f | NotFound++ | t/advanced/10closure.t:
19:13 dalek winxed: a test for closure in nested anon functions
19:13 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/1e0cb9fc51
19:16 dalek winxed: ff75af5 | NotFound++ | winxedst1.winxed:
19:16 dalek winxed: avoid generating 'outer' if no outer lexicals used
19:16 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/ff75af5145
19:52 dalek rakudo/nom: 4b4f5ef | moritz++ | src/core/ (2 files):
19:52 dalek rakudo/nom: throw X::OutOfRange exception from Date and DateTime constructors
19:52 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4b4f5efb4a
20:16 ambs joined #parrot
20:18 ambs_ joined #parrot
20:19 mj41 joined #parrot
20:31 soh_cah_toa joined #parrot
20:34 ambs joined #parrot
21:06 benabik joined #parrot
21:07 dalek rakudo/nom: 16b498b | moritz++ | docs/ChangeLog:
21:07 dalek rakudo/nom: update ChangeLog
21:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/16b498b1ee
21:10 u2011 joined #parrot
21:34 u2011 left #parrot
21:36 not_gerd bye, #parrot
22:16 schmooster joined #parrot
23:09 rfw joined #parrot

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

Parrot | source cross referenced