Parrot 3.9.0 "Archaeopteryx" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 19 October 2011.
dalek kudo/nom: 9544769 | Coke++ | t/spectest.data:
Splice was implemented, run (fudged) tests
 00:10
00:21 u2011 joined 00:28 u2011 left 00:41 nn joined 00:42 nn left 01:17 whiteknight joined 01:28 benabik joined 01:34 soh_cah_toa joined
cotto ~~ 02:38
03:00 jsut joined 05:04 nbrown joined 05:59 lateau joined 06:10 schmooster joined
dalek kudo/nom: a2e2b96 | moritz++ | / (4 files):
Get rid of nqp::want usage in the setting

Also switches pir:: ops to nqp:: ops and adds return type annotations		 06:55
07:19 rfw joined 07:25 lateau joined 07:56 woosley joined 08:39 mj41 joined 09:24 lucian joined 09:38 woosley left 09:46 lateau1 joined
dalek p: 4bc5cae | moritz++ | src/PAST/NQP.pir:
bitwise str nqp:: ops
 10:14
kudo/native-str-ops: 010ed9a | moritz++ | / (2 files):
add native str ops, add return type annotations, and use nqp:: opcodes for string bitwise ops
 10:17
TT #1720 reopened by kurahaupo++: fdiv_i_i_i and fdiv_i_i ops don't work correctly. 10:39
TT #1720: trac.parrot.org/parrot/ticket/1720
11:36 lateau joined 11:38 Psyche^ joined 11:50 benabik joined 12:02 whiteknight joined
whiteknight good morning #parrot 12:09
Interesting article from intel about the performance of memcpy in GCC: software.intel.com/en-us/articles/m...rformance/ 12:10
benabik o/ whiteknight 12:13
whiteknight good morning, benabik 12:17
tadzik good morning #parrot
whiteknight hello tadzik 12:20
12:35 JimmyZ joined 12:51 benabik_ joined, benabik joined, benabik_ joined
mls hi whiteknight! 12:54
I've a question about exceptions for you
12:55 man_in_shack joined
man_in_shack waves 12:55
once again i find myself wanting to develop my own programing language 12:57
and the only tools i'm aware of to assist me are flex/bison and parrot
moritz hello
what kind of language do you want to develop?
man_in_shack long-term goal is to have fancy stuff like classes 12:58
but more importantly, i want it interpreted or at least compiled to bytecode, and embedable into other applications 12:59
moritz do you want it typed at runtime or at compile time? 13:00
(ie "dynamic" or "static" language)
man_in_shack at the moment, compile time
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.
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
dynamic
man_in_shack is tired
whiteknight mls: sorry for the delay. What do you need? 13:05
man_in_shack BRAAAAAAIINS 13:06
i guess i could write a preliminary AND SLOW interpreter in a language i know 13:09
like python
benabik You could write a preliminary interpreter in a language you don't know. I find that to be fun. :-D
benabik likes learning languages.
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
man_in_shack everything should be written in bf
benabik atrodo: I tend to suggest Haskell, but those "work" too.
(fsvo of work)
13:10 pbaker joined
atrodo i'm waiting for the parrot rewrite in bf 13:10
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
benabik PCT helps build language constructs and handles the dirty work of making it into PIR. 13:12
(Don't know if that was around back then.)
whiteknight PCT has been around for a long time
man_in_shack i attended a lecture on parrot at the 2006 linux conf au 13:13
got quite excited about it
then had trouble doing anything useful with it :D
atrodo man_in_shack> Have you gone through the squaak tutorial? 13:14
man_in_shack i did at some point
and it confused me
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
guess i need to try again then :D
where's the latest squaak tut? 13:16
benabik I was assuming you were willing to start again since you showed up here. :-)
atrodo github.com/ekiru/squaak-tutorial I believe
benabik atrodo: The description of the repo says it's out of date. :-/ 13:17
docs.parrot.org/parrot/latest/html/...orial.html is the more "official" one. Not sure how they differ. 13:18
man_in_shack deb unstable has parrot 3.6 13:19
benabik ā€¦ Optimizer? 13:20
man_in_shack hm? 13:21
benabik Is slow still the default runtime?
Sorry, I just discovered that IMCC claims to have an optimizer. 13:22
*runcore
We probably need to take a good look at docs/running.pod. I think it's full of lies.
man_in_shack dpaste.com/646709/ << whee 13:25
benabik Although I think it's a reasonable candidate for turning into parrot.1
mls (the default runcore seems to be "fast")
(see parseflags() in parrot2/main.c)
whiteknight mls: yeah, the fast core is the default 13:27
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
man_in_shack so how do i fix this error then? 13:30
benabik man_in_shack: Is that from debian's parrot package?
man_in_shack yup 13:31
benabik man_in_shack: There should be a osutils.pbc in /usr/lib/parrot/3.6.0/library
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.
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?
man_in_shack benabik: the file's not there
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++
man_in_shack: You may need to install parrot-devel
man_in_shack i have already
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
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.
mls (compile your own parrot ;) )
benabik Well that's the work around for sure. 13:36
man_in_shack yah
benabik man_in_shack++ # bug report 13:37
benabik opens an issue.
man_in_shack who's bugging what now? 13:38
13:40 ambs joined
man_in_shack just updating my sid32 chroot to see if it's the same problem there 13:48
benabik man_in_shack: It's an issue with the debian packages. Parrot's not that hard to build from source: 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
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:50
dalek kudo/nom: c838c1c | moritz++ | src/core/Int.pm:
fix copy/pasto in native int op name, mls++
 13:51
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
when we do a rethrow/resume
whiteknight okay
mls currently the op can't be used if one wants to resume the exception later on 13:53
cause resume breaks if the handlers are changed 13:54
(that's true for all continuations)
benabik mls: You probably want to pop the handlers as the last thing before leaving, not as the first thing when entering.
benabik ponders if continuations should hold onto their handlers...
mls (continuations that jum back in the call chain are ok, continuations that jump forward are very dangerous) 13:55
13:56 lateau1 joined
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
(Rakudo solves this in a different way, so all this doesn't apply)
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.
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 ;)
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
(i.e. delay the expensive alterations of the stack until it's required)
mls rethrows dont' start at the bottom. I'm talking about new exceptions
benabik I don't view those as terribly different things. :-D 14:00
(I'll admit Parrot might.)
But wrapping an exception and re-throwing is a common idiom in several language.
(Er, throwing the new one farther up.)
mls yes, most languges implement that "pop the handlers" semantics I proposed. 14:01
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.
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
benabik But that context doesn't include the state of the EHs.
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.
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:05
(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
(just add a pop_eh if you want the current handler to be popped as well)
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
the resume or rethrow method would restore the handlers 14:08
that that's a new ResizablePMCArray PMC, so it's not cheap
but that's...
14:08 lateau joined
benabik Well, since the handler has the exception, so that's a way to give it over. 14:08
How are the handlers stored currently? 14:09
mls A ResizeablePMCArray in the CallContext
benabik Bleh.
Mutable state strikes again.
mls (it's a bit overkill if there's just one handler)
benabik It would be cheap if it was maintained as a linked list. 14:10
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.
benabik mls: It's cheaper if they share common parts. Linked lists are awesome like that.
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
that's also expensive...
benabik moritz: I thought the only interface into it was push and pop.
Oh, we provide raw access to the RPA, don't we?
mls We just store that iterator in the Exception when we found the correct handler
As it's just an PMC we can use all methods including random access 14:14
so we could improve exception handling a bit by not using an ArrayIterator 14:15
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.
mls (still, we could write the index into the exception instead of the iterater and thus get rid of one pmc) 14:17
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
benabik Well, you'd have to make them cheaper. RPA optimizes for random changes, but the common operations are push and pop. 14:18
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.
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?
Or do we store handlers for each context separately?
mls separately
benabik Ahhhhh.... 14:21
mls so not many contexts have handlers attached
benabik I expected a single stack for the current continuation.
mls and the RPAs are pretty small
benabik Yeah.
mls Hmm, we really can get rid of that iterator and make exception handling a bit faster 14:23
I should patch parrot to do this independent of any other change
we could also easily change parrot to use an RPA only of more than one handler has been pushed
benabik Using an iterator for an RPA seems a little excessive. Ints are your friend. 14:24
mls yes
benabik And avoiding the GCable in the small case is probably a good idea.
mls++
mls we could check the base_type it it's a RPA or a handler
whiteknight so long as we only use built-in types, base_type can work
mls and store the handler in place of the RPA if the context uses only one handler
benabik Do we push arbitrary objects as handlers? 14:25
mls yes, I think so
benabik That does make it a bit more difficult to distinguish then.
mls we can detect the RPA, an RPA cannot be a handler ;)
and RPA is pretty much hardcoded 14:26
benabik True.
And if the user pushes an RPA and expects it to handle exceptions, something's a little strange.
mls right ;)
(we could even handler that: always create the RPA if the handler is an RPA) 14:27
handle
14:27 cosimo joined
benabik What does it do if you push an RPA now? Explode if you throw? 14:28
mls checking the code...
it calls the can_handle method 14:29
as there's no such method it'll throw another exception
thus it'll loop I guess
benabik :-(
mls well, so don't push things that don't implement can_handle ;) 14:30
14:30 jsut_ joined
benabik Being that easy to get Parrot to just loop is bad. 14:30
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
moritz you can't guard against too many things at the low level 14:32
otherwise you'll slow down stuff
mls (that's about pushing hon-handlers)
moritz so if you think that case should be caught, please only in debug builds
mls the discussion seems to be back at "catching exceptions in handlers"
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.
mls oh, that's true. looking at the code again... 14:33
there's a guard against that already implemented
benabik \\o/ 14:34
mls so I think it won't loop
of course the guard is not thread-safe ;)
it uses some static vars 14:35
benabik oog
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.
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.
But if pushing an RPA is pointless, then we can treat it as a list of handlers instead of a handler itself.
Random idea, really. 14:37
mls yes, we could do that
(I don't know of a use caase, though)
case 14:38
benabik Fair enough.
mls okay, so i'll implement those optimizations.
(that doesn't solve the original problem, though.) 14:39
(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:40
(and a different but related problem was that continuations jumping forard in the call chain are really dangerous) 14:41
I got bitten by that once, I resumed the exception after the pop_eh of the handler was done -> boom 14:42
cause after the resume we will return into the context at some point and then do another pop_eh -> "No exception to pop" 14:43
(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
having
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.
Avoids the expensive copying and alteration. Might cause other issues. 14:46
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
I don't know where to store that index
and what if the handler does a push_eh 14:49
benabik In the context? Then the exception keeps a copy and restores it when resumed. Cheaper than copying around an RPA. 14:50
I guess that's when you'd actually have to modify the handler list.
Hm. The exception would have to notice when the list changes. :-/
Hm. rethrow takes an arbitrary exception. 14:53
mls yes. You if an exception occurs in the exception handler you can rethrow any of them 14:54
14:54 cosimo joined
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!
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:56
mls exception handlers are continuations 14:57
the problem is that they have to be stored in the context
whiteknight continuations are too expensive right now, and we need to fix that
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.
(I'm back to my leaking context complaint. Yes, I'm circular.)
moritz circular logic is the best kind of logic. Because it's circular. 14:59
benabik moritz++
I could expound more, but writing. (Arguing on the internet is more fun than writing papers.)
mls Hmm, using a linked list means that you can't re-use an exception handler 15:00
(If the link is in the handler)
benabik Things can be in a linked list more than once. 15:01
(Put the handler in twice, not the cons cell.)
mls That means push_eh always allocates a cons cell 15:02
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.
whiteknight the fixed-size allocator should be relatively cheap to get cells of a fixed size 15:04
I'm not as familiar with it as I used to be
benabik knows nothing about the details of the GC.
I'm always afraid that dealing with the GC involves creating entire PMCs. 15:05
(Which shouldn't be a fear. They should be cheap since we use them everywhere, but that gets back to 6model integration. :-D)
mls you don't have to. You can just attach it to another PMC, in that case the continuation PMC
hmm 15:06
whiteknight yeah, if you attach the linked list to a PMC, you can destroy the linked list on PMC destroy 15:07
mls I don't know where to put it in our case 15:08
15:08 nnunley joined
benabik I think I'm talking about a large change to how we do EHs. :-/ 15:08
I am musing randomly while avoiding a paper. :-)
mls hurry, quit irc or you'll miss the deadline 15:09
benabik ā€¦ quit IRC?
;-)
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.
mls just blame parrot ;)
benabik It's the cool thing to do.
15:11 nnunley joined 15:13 JimmyZ joined
whiteknight all the cool kids are doing it 15:24
some of the uncool kids too
dalek rrot/mls/kill-events-in-ehqueue: 3456ac0 | mls++ | / (9 files):
Get rid of the iterator PMC when iterating through the exceptions handlers.

Instead of the iterator we store the number of handlers left in the Exception. Also, a new experimental op was added, "pop_upto_eh". It pops all handlers until it reaches the current handler of ther specified exception.		 16:41
mls now we just have to get rid of that Parrot_pcc_invoke_method_from_c_args(..."can_handle") 16:43
16:45 lateau joined
mls hmm, we could mis-use the is_equal VTABLE in exceptionhandler.pmc ;) 16:48
benabik Is pcc_invoke_method much slower than using a VTABLE? 16:49
mls I think it allocates a callcontext
I may be wrong, though 16:50
I know it's slower, but I don't know how much. whiteknight++ did some benchmarks
yep, it allocates a CallContext 16:52
benabik And VTABLEs dont?
mls no
benabik Interesting. 16:53
mls a VTABLE call is pretty much a C function call
benabik Which can be overridden to do invoke_method. I see.
mls then it's slow again ;) 16:54
we could also use VTABLE_does_pmc ;) 17:00
to check if the exception handler "does" the exception
benabik Changing how we interrogate handlers has a chance of breaking HLLs. Should look into that. 17:01
17:01 pbaker joined
benabik Although most of those sound a little hacky. :-) 17:01
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
cotto ~~ 17:25
NotFound dukeleto: is what we do in C files, so I guess is fine for winxed. 17:31
dukeleto NotFound: yep, already merged the pull request :) 17:32
NotFound++ thanks for the help with setup.winxed for cardinal
NotFound dukeleto: thanks for cardinal contributing for winxed world domination ;) 17:35
17:38 contingencyplan joined 18:00 lateau joined 18:04 nbrown joined 18:07 not_gerd joined
not_gerd hello #parrot 18:07
mls hi not_gerd! 18:10
another idea: shouldn't handle_types and handle_types_except take a key as argument?
preferable a const key 18:11
not_gerd mls: hi 18:12
dukeleto: care to explain why you closed github.com/parrot/parrot/pull/191 ?
NotFound mls: how will you pass a const key to a method in pir? 18:15
mls isn't that a PMC? 18:16
NotFound mls: Is that an answer? 18:18
mls yes. ;) it seems to work for VTABLEs
moritz "just like any other PMC"?
mls I just thought it might be consistent with other usages of keys 18:20
NotFound "PIR". I mean syntax.
mls Dunno, I don't know what imcc currently does. Can it only create string type keys? 18:21
(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.
And I seriously doubt any one is liking to create more pir sugar. 18:23
mls hey, it's just pir ;) 18:24
NotFound mls: yes, just pir, but the pir compiler is imcc ;)
mls oh, I've got imcc patching experience by now ;)
18:24 fperrad joined
mls hmm, leys see what imcc generates when I use [1;2;3] in a method call 18:25
ts ts, it doesn't like it 18:26
back to the imcc.y file 18:27
NotFound mls: if you really like the idea you should start by proposing the changes to imcc, yes. 18:28
mls oh wait, it doesn't need to be a method call 18:32
the new op can take an PMC argument 18:33
much better, as in that case we also don't need the CallContext PMC
we could even set the min and max severity ;) 18:35
NotFound mls: with just a key? How so? 18:36
mls we need two new constants ;)
[.MINSEVERITY;5;.CONTROL_NEXT]
ok, I admit that's a gross hack ;)
I don't think the severity is often used 18:37
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.
mls oh yes, good idea
18:39 benabik joined
NotFound A hack, yes, but for code generated from HLLs not so bad. 18:39
mls I thought of a .TYPESEXCEPT pseudo-entry
it doesn't make sense to have both types and types_except anyway
but yes, using negative values is another option 18:40
NotFound handle_types_except is not used if handle_types is set to non null, but nothing disallow doing it. 18:41
mls ok, as said, heading home. talk to you tomorrow 18:46
19:03 fperrad joined
dalek nxed: 1e0cb9f | NotFound++ | t/advanced/10closure.t:
a test for closure in nested anon functions
 19:13
nxed: ff75af5 | NotFound++ | winxedst1.winxed:
avoid generating 'outer' if no outer lexicals used
 19:16
kudo/nom: 4b4f5ef | moritz++ | src/core/ (2 files):
throw X::OutOfRange exception from Date and DateTime constructors
 19:52
20:16 ambs joined 20:18 ambs_ joined 20:19 mj41 joined 20:31 soh_cah_toa joined 20:34 ambs joined 21:06 benabik joined
dalek kudo/nom: 16b498b | moritz++ | docs/ChangeLog:
update ChangeLog
 21:07
21:10 u2011 joined 21:34 u2011 left
not_gerd bye, #parrot 21:36
22:16 schmooster joined 23:09 rfw joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!