Camelia, the Perl 6 bug

IRC log for #parrot, 2008-10-17

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:06 silug joined #parrot
00:09 AndyA joined #parrot
01:30 dalek r31998 | particle++ | trunk:
01:30 dalek : [rakudo] more simple refactorings
01:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31998
01:40 Ademan joined #parrot
01:41 particle1 joined #parrot
01:56 dalek r31999 | particle++ | trunk:
01:56 dalek : [rakudo] s/perl6/rakudo/
01:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31999
02:00 Andy joined #parrot
02:04 nopaste joined #parrot
02:06 silug joined #parrot
02:11 dalek r32000 | particle++ | trunk:
02:11 dalek : [rakudo] remove unused debug code
02:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32000
02:12 Theory joined #parrot
03:12 konobi joined #parrot
03:21 Theory joined #parrot
03:23 ab5tract joined #parrot
03:37 TonyC joined #parrot
03:48 ab5tract tutorial says i should be able to run 'make test' after generating a new language
03:51 ab5tract PCT tutorial, sorry.
03:52 ab5tract parrot isn't generating byte code either
03:58 konobi left #parrot
04:14 tetragon joined #parrot
04:30 johbar joined #parrot
05:44 Theory joined #parrot
06:16 uniejo joined #parrot
06:19 uniejo joined #parrot
06:35 davidfetter joined #parrot
06:48 dalek r32001 | cotto++ | trunk:
06:48 dalek : [t] break t/pmc/ro.t into a separate rotest.t file, unTODO the related coverage test
06:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32001
06:50 cotto joined #parrot
06:52 cotto is there a nice way to enumerate a PMC's METHODs in PIR?
06:52 cotto (or an ugly one)
06:55 Tene There is.
06:56 cotto get_mro looks like my friend (since I'm just using it to test something)
06:56 Tene get a class object
06:56 Tene $P0 = inspect class, 'methods'
06:56 Tene $P1 = new 'Iterator', $P0
06:57 cotto even better
07:07 cotto except it doesn't work.
07:13 iblechbot joined #parrot
07:21 dalek r32002 | cotto++ | trunk:
07:21 dalek : [t] unTODO test and update svn metadata
07:21 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32002
07:31 Ontolog joined #parrot
07:37 cotto Infinoid, do you know how to use exceptions in PIR?
07:38 cotto er, handlers
07:38 cotto of exceptions
07:39 cotto if not, see my reply to #59940
07:55 Zaba_ t/spec/S16-io/basic-open..................................ok 1/9
07:55 Zaba_ stuck :/
08:09 cosimo joined #parrot
08:09 barney joined #parrot
08:09 Zaba_ What is a .HLL?
08:09 purl somebody said a .HLL was useful w/o any dynamic lib too, if all is PIR
08:16 gmansi joined #parrot
08:18 Zaba joined #parrot
08:38 gaz joined #parrot
08:48 barney HLL stands for High level language, e.g. Perl 6, PHP
08:50 barney .HLL is a directive in PIR that (among other things?) initializen a mapping from standard PMCs to hll specific PMCs
08:55 tomyan joined #parrot
09:35 iblechbot joined #parrot
10:00 bacek joined #parrot
10:23 tetragon joined #parrot
11:45 contingencyplan joined #parrot
11:53 tetragon joined #parrot
11:56 Zaba joined #parrot
12:08 contingencyplan joined #parrot
12:24 contingencyplan joined #parrot
12:29 kj joined #parrot
12:40 Zaba joined #parrot
12:52 iblechbot joined #parrot
13:02 jq joined #parrot
13:03 Ontolog joined #parrot
13:10 grim_fandango joined #parrot
13:14 uniejo joined #parrot
13:25 Infinoid msg cotto thanks, but Mark Grimes != Mark Glines, #59940 is someone else
13:25 purl Message for cotto stored.
13:27 particle :)
13:28 particle Infinoid: been thinking about bytecode at all?
13:28 Infinoid thinking a lot, yes.  doing anything, sadly not.
13:30 particle well, it's important to think before you do
13:31 Infinoid it's also important to do at some point, too.  its on my list of things to work on in the next week or two
13:31 particle excellent
13:31 Infinoid merging is a barrier at the moment.  since I haven't really changed anything outside the new PMCs, it might be easier to just refresh the branch from current trunk
13:32 particle that shouldn't be a problem
13:32 Infinoid I spent some time playing with merges, even brought out git at some point... the results weren't pretty.
13:32 particle really, why?
13:32 purl really, why is it green, and what is its favorite treat?
13:32 particle where were the conflicts?
13:33 gryphon joined #parrot
13:33 Infinoid it was just time consuming.  I didn't realize things would get so difficult with lots of local patches and periodic trunk merges
13:33 Infinoid guess I'm used to some other SCMs, that do all the work for me *shrug*
13:35 PerlJam Which scms "do all the work" of merging?
13:35 PerlJam I mean, conflicts still need to be resolved by a human.  git does all of the work save that.
13:36 Infinoid monotone does this nicely, too
13:37 Infinoid anyway, I've been thinking, I don't really *need* to be doing this stuff in my own branch until I start breaking the rest of the system to use the new PMCs
13:37 Infinoid I'm not really to that point yet.  so the overhead of manually merging is kinda useless
13:38 particle yeah
13:38 particle you can develop the new pmcs in trunk, as long as the tests pass
13:39 Infinoid thanks, I thought that might be the case.
15:11 Andy joined #parrot
15:16 johbar joined #parrot
15:17 Theory joined #parrot
15:36 Wknight8111 joined #parrot
15:38 dalek r32003 | Whiteknight++ | trunk:
15:38 dalek : [PDD] Add information about get_outer opcode to PDD20. Patch courtesy kjs++ from RT#39615
15:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32003
16:05 Wknight8111 only 29 more tickets till we hit 600
16:05 Wknight8111 ...assuming no more bugs are found between now and hen
16:06 Infinoid whiteknight++
16:06 Tene purl: parrotbug?
16:06 purl parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/​trunk/docs/submissions.pod or see also "rakudobug"
16:06 kj it's easy to convert another 20 XXX's to tickets... but let's not :-)
16:06 Tene echo "There are too many open tickets.  We're still over 600." | mail -s '[BUG] Too many bugs' parrotbug@parrotcode.org
16:06 Wknight8111 damnit!
16:08 Wknight8111 some of the tickets are over a year old or more, so closing them is easy because the problems don't exist anymore
16:08 Bzek joined #parrot
16:09 kj otoh, some tickets are too complex, and may have to be converted into several tickets
16:09 TimToady just close 'em all; the important ones will come back again  :)
16:10 kj hehe
16:10 Infinoid oh?  is there a standard rule that defines a number of estimated man-hours per ticket?
16:10 Infinoid other than common sense, I guess
16:11 kj what I meant was that some tickets are very hard to tackle; when browsing to see what Can I Do Today, these are the ones that get skipped
16:11 Infinoid that's a good way to measure it
16:36 sjansen joined #parrot
16:45 borondil joined #parrot
16:45 borondil left #parrot
17:11 silug joined #parrot
17:20 particle2 joined #parrot
17:58 chromatic joined #parrot
18:06 masak joined #parrot
18:22 ruoso joined #parrot
18:27 dalek r32004 | coke++ | trunk:
18:27 dalek : [t] export another handy test function by default.
18:27 dalek : Courtesy mgrimes <mgrimes at cpan dot org> via RT #59938
18:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32004
18:42 Coke we're quite a few more than 30 away from 600.
18:43 Coke btw, 49832, 56052, 58760 59600 and 59660 are probably all the same issue.
18:43 Coke we're 73 away from 600.
18:45 chromatic Coke, he counted just open issues.
18:46 Coke I realize the source of his confusion. =-)
18:47 particle2 i have a question about namespaces and importing
18:47 particle2 i'm trying to get that working for rakudo
18:47 particle haven't seen pmichaud around in a bit, so maybe you'll have some ideas
18:47 Coke chromatic: while I don't particularly like upping our Storable requirement separate from our perl requirement, I don't mind if no one else does. Can probably close out those 5 tickets if someone goes through and cleans that up.
18:48 Coke chromatic: 53156 you say "fixed", but the ticket is still open.
18:48 Coke ... nevermind.
18:49 particle currently, rakudo's use and require just wrap eval
18:50 particle so, when a file is evaled, i need to find out fi any new packages/classes/etc have been created
18:50 particle then look in the namespaces for symbols to import
18:51 particle but i don't see a good way of walking the past tree using nqp
18:51 particle i'm wondering if what i really need is package/class/etc registries
18:51 particle and if a new package is added, a callback can be run or something
18:52 Tene "walking the past tree"?
18:52 particle see src/builtins/eval.pir
18:53 particle no, sorry, see actions.pm
18:53 particle line 303 has 'use_statement' method
18:53 particle when 'use Foo' is encountered, a call to 'use' in eval.pir is made
18:54 particle then the result is compiled to past and invoked
18:55 Coke tcl is going to solve something like this by marking on the namespace  an attribute that tracks what is exported/able.
18:55 Coke you could then just ask the namespace "what do you have?"
18:56 particle but i need to know what new namespaces have been created
18:56 chromatic Coke, I don't like it much either, but I don't want to rule out OpenSolaris as a platform just because they don't know how to update software from upstream.
18:57 particle if i 'use Foo' there's no guarantee that i get a namespace named Foo anywhere in Foo.pm
18:57 particle ...or that that's the only namespace created.
18:57 Coke complain to larry.
18:58 particle this isn't different from perl 5
18:58 Coke if you say "use Foo (stuff)", aren't you expecting stuff to be in the Foo namespace?
18:58 particle Foo.pm could start with 'package Bar;
18:58 Coke it could, sure. or we could make that a compile time error. :)
18:59 Tene particle: if it did, would it be right to import the symbols from the Bar namespace?
18:59 particle yes, as far as i'm aware. coding a p5 test now
19:02 particle ok, it doesn't work like that in p5
19:03 particle it'll only export from package Foo if you do 'use Foo'
19:03 Tene So: use Foo; should look for the exports from the Foo namespace, right?
19:03 chromatic That's because 'use Foo;' turns into BEGIN { require 'Foo'; Foo::->import(); }
19:03 particle yep, so it seems
19:03 particle you'd have to do 'require Foo' and Bar->import
19:04 particle or use Foo and Bar->import
19:04 Coke so if Foo declares what it exports, say by putting an attribute on the namespace slot, you can just interrogate it. =-)
19:04 particle in perl 6, Foo declares what it exports by creating aliases in subnamespaces
19:05 particle Foo::EXPORT::ALL, Foo::EXPORT::DEFAULT, Foo::EXPORT::my_tagset
19:05 particle so i know where to look, as long as i have the module name
19:05 particle ok, that's easy enough
19:06 Tene It would be really great if all the languages used that same convention, for interop...
19:07 particle i'd be happy if that convention were to have shadow namespaces in the language-private ns
19:08 Coke Tene: except that pollutes the namespaces.
19:08 particle _perl6;Foo;EXPORT;ALL
19:08 Tene Coke: s/that/the/
19:09 Coke yes. That would be awesome.
19:09 Coke I am not holding my breath. :|
19:14 silug joined #parrot
19:16 particle ok, the other trick with p6 importing is that it imports to the current block, not current package
19:17 Tene Coke: is it possible to get access to the namespaces directly in TCL?
19:24 Coke I'm not sure what you mean 'directly', but [namespace] gives you a lot of rope.
19:24 Tene 'kay
19:25 Coke I can create, delete, import, export, forget I imported, find a parent, see if one is defined...
19:25 Tene Coke: how would you feel about particle's _hll;etc;EXPORT;ALL suggestion?
19:25 Coke Given that the _hll namespaces are not really private, I'd have concerns.
19:26 Tene "not really private"?
19:26 Coke ... yes. how do you make a namespace private in parrot?
19:26 Tene I'm not sure what you mean.  private namespace?  private to what?
19:26 Coke You can't, SFAIK: there's no way to say "this is visible to the users, but this is only for the compiler."
19:27 Coke in my case, how would I make the _tcl namespace so that Tcl users could not poke around in it?
19:27 Tene I don't understand why you'd want to do that, however, I don't think any HLLs have a way to directly access the other hll namespaces.
19:28 Coke Tene: of course we do. we're all in the same interpreter with no safe.
19:28 Tene set_root_namespace ['_tcl';'foo';'EXPORT';'ALL']
19:28 Tene or whatever
19:28 chromatic You need language syntax for that.
19:28 Tene Right.
19:28 Coke for poking into namespaces? already have it.
19:29 gmansi joined #parrot
19:29 Tene Coke: those would be get_hll_namespace ops, not get_root_namespace
19:29 Coke Tene: I'm not sure those are as separate as you think they are.
19:30 Coke esp. if we're going to allow languages the ability to invoke things, say, in parrot's standard library.
19:30 Tene So your concern is that a user could ask a namespace in tcl for its parent until it got to the parrot root namespace and then looked around in there?
19:30 Tene Or...
19:31 Coke or even in other languages; if I can get to things in the Perl6 namespace from Tcl, what is stopping me from getting to the _perl6 namespace?
19:31 Coke my point is that the _ namespaces aren't a safe place to hide things you don't want the user diddling.
19:32 Tene 1) I odn't see more of a problem with the user diddling _ namespaces than other hll namespaces, 2) I don't see how they'd be doing it in the first place.
19:32 Tene Can you give me an example of a problem?
19:34 Coke no, because HLL interop doesn't really work yet.
19:34 particle #! perl6 ; Q:PIR{ $P0 = get_root_namespace ['tcl' ] ; null $P0 }; #screw you, tcl users!
19:34 Coke but that's a good thought experiment.
19:35 particle ...which can be made safe by outlawing Q:PIR
19:35 Coke ... in perl6.
19:35 particle ayep
19:35 Tene Coke: a hypothetical example
19:35 Coke nothing is stopping arbitrary bytecode from doing whatever it wants in any namespace.
19:35 Coke including the "private" ones.
19:35 particle admittedly, i haven't reviewed allison's security pdd yet
19:37 Coke tene: here's a different way to look at it: not everything is meant to be introspectable.
19:37 Tene Coke: I still don't understand how this is a problem.  The bytecode SHOULD be able to access these namespace.  If the code I write modifies the export list of some other namespace, then my code needs to be able to write to that namespace.
19:37 Coke we should aspire to something a little more secure than perl5's "please don't open this door" model.
19:38 Coke ditto what particle said, though.
19:38 Tene But there are plenty of valid reasons to open that door.
19:38 Tene Also, how are the root namespaces being exposed to tcl/perl6/whatever in this harmful way?
19:39 Tene I'm not sure how I'd get the ['tcl'] namespace from Perl 6.
19:39 Coke in the same way in which we'll able to invoke code defined in other languages from our language?
19:39 chromatic You need HLL syntax for that, I mean -- not PIR, unless you allow inline PIR.
19:40 Tene use Doom :lang<tcl>;
19:40 Tene That won't do it.
19:40 Coke chromatic: yes, but we can't assume poeople running on parrot can't run pir.
19:40 Tene That will import some namespaces into my current hll, at most.
19:40 Coke Tene:  [namespace import ::parrot::perl6::CGI]
19:41 Coke [namespace delete ::parrot::_perl6::CGI::EXPORT::DEFAULT] ?
19:42 Tene What's the leading ::parrot for?
19:42 Coke (and any concerns I have make more sense in something like mod_parrot than me running a script on my desktop, of course.)
19:42 Coke it's me waving my hands to show how I'd get to perl6 in the frist place.
19:42 Tene Okay.
19:42 Coke because if I can't do that, then I don't see how interop will EVER work.
19:42 Tene Why is that more of a problem than [namespace delete ::my::cool::namespace] ?
19:43 Coke because for tcl at least, anything in _tcl is not meant to be user visible. at all. it's compiler internal crap no one should be poking with.
19:43 Coke help methods that aren't meant to be invokable by the user, etc.
19:44 Tene They'll still be called by the same bytecode, though.
19:45 Tene You restrict that at the HLL level, not the bytecode level.
19:45 Coke I can prevent tcl users from mucking with _tcl, yes. unless i let them run raw PIR. or invoke another HLL that I have no control over.
19:46 Coke I can stop -myself- from touching that. I can't stop you.
19:47 Tene so you're suggesting a situation where both you and me are running code on the same interpreter at the same time, and I fuck with your namespaces and then your code breaks?
19:47 Coke that's one thought.
19:48 Tene That's the security pdd.  Namespaces aren't a special case there.j
19:48 Tene These namespaces, at least.
19:48 Coke Ok. I'll read the pdd.
19:48 Tene In your example of 'helper methods' and such, the generated bytecode will be calling those anyway.
19:48 Coke but honestly, I'm more concerned about the HLL pdd, since we haven't really agreed how the stuff that's -supposed- to work is supposed to work.
19:48 Coke which generated bytecode?
19:49 Tene The bytecode generated by your compiler.
19:49 Coke I may not be generating all the bytecode I'm running.
19:49 Coke (in fact, I hope I'm not. at that point, I'll just use tclsh =-)
19:50 Tene Can you give me a hypothetical example of a problem here, or was that your 'delete namespace' example earlier?
19:51 Coke meh. if I haven't made any kind of even remotely convincing argument, nevermind.
19:51 Tene I'm having trouble seeing how your namespace example is significantly different from "$importantvariable = 0; # Oops, I just destroyed some state that I need".
19:52 dalek Krishna Sethuraman | Parrot Development on Windows:
19:52 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?parrot_development_on_windows
19:52 Coke not everything is supposed to be visible to the user.
19:52 Tene That's a bug in the user's code, and bytecode running in the same context will need to be accessing it, wherever it is.
19:52 Coke there's a difference between me changing a variable in perl's interpreter that is visible to the user anyway and me changing the state of a C variable used to run the interpreter.
19:53 Tene In Perl 6, wherever you're storing this list of symbols, the bytecode generated by a 'use' statement needs to access that list, yes?
19:53 Coke I have no place I can put things for you not to touch them, so everything is, by default, world visible/writable.
19:54 Tene $P0 = <get the symbols for some namespace>; namespace.export_to(something, $P0)
19:54 Coke for example, a stupid useless number: [info cmdcount] tells me how many commands the tcl interpreter has run. I have no place to put that variable that isn't visible to someone on the VM.
19:55 Coke but in tclsh, this isn't a user visible variable.
19:56 Tene Am I completely off track in that being the sort of bytecode that will be generated by a 'use' statement?
19:58 NotFound Coke: you can put in the lexical environment of a continuation, for example.
20:00 NotFound I've readed some tie ago an article about that tricks to have private variables in perl, don't remember where.
20:02 Tene Coke: so if we restrict any loaded bytecode from having access, at the bytecode level, to wherever export lists are stored, then no bytecode generated by user code will have be able to read export lists, right?
20:02 Tene I freely admit the possibility that I'm insane here.
20:03 chromatic Uninformed about Perl 5, Perl 6, and Topaz: http://weblog.infoworld.com/fatalexcepti​on/archives/2008/10/virtual_machine.html
20:03 Coke there are various levels of access.
20:04 Coke well, there -could- be.
20:04 Tene Please explain.
20:04 Coke well, ro and rw for one.
20:04 Coke public/private/protected/package might be a different way to slice it.
20:05 Coke (and making a PMC RO is not necessarily sufficient, since you can simply replace it with a more compliant one)
20:06 Coke let's back up. do you agree with the premise that a compiler may have internal state it does not wish to expose?
20:06 Coke s/compiler/HLL/
20:07 Coke and s/state/functionality/
20:08 Coke er, state +/or functionality.
20:11 Tene You're talking about, for example, a helper function in the compiler, for performing a common manipulation on an AST?
20:13 Coke I didn't have that example in mind, but sure.
20:13 Tene That would fit the idea you're referring to, though?
20:13 Coke yes.
20:15 Tene I'd imagine that would be the same as any other non-exported symbol in any other namespace.  If I write some other library and make internal functions there.
20:15 Tene Your compiler should already be in its own namespace.
20:16 Coke what does "exported" mean at the parrot level?
20:17 Tene Nothing.  You can get any symbol in any namespace.
20:17 Coke I posit this is a security issue.
20:17 Tene Please explain.
20:19 Coke No, I give up now. =-)
20:19 Coke (and this time, I mean it. At least for today)
20:19 Tene Running untrusted code, maybe?
20:20 chromatic Running an extension written in C?
20:20 Tene Sandboxing is discussed in pdd23.
20:20 Tene Mentioned, at least.
20:21 Tene "al machine. It’s a safe zone to contain code from an untrusted source. In the extreme case, a sandbox is completely isolated from all outside code, with no access to read or write to the surrounding environment. In the general case, a sandbox will have the ability to read from, but not write to the surrounding environment (global namespaces, for example), with a very
20:21 Tene narrow ad carefully filtered route  to send some data back to the code that called it."
20:22 Tene Hmm.  That was surprising.
20:58 gryphon joined #parrot
21:33 Theory joined #parrot
21:50 rdice joined #parrot
21:53 chromatic joined #parrot
22:02 dalek r32005 | tene++ | hllify:
22:02 dalek : Delete the unused hllify branch.
22:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32005
22:05 jan joined #parrot
22:10 chromatic joined #parrot
22:30 Tene purl: msg pmichaud In HLLCompiler.pir, it looks like we're repeatedly trying to dispatch on a variable being a string, RSA, NameSpace, Class, whatever.  Can we standardize on what $parseactions, $parsegrammar, etc. are holding, and find the appropriate object in the accessor?
22:30 purl Message for pmichaud stored.
22:33 chromatic Tene, Parrot doesn't make that distinction, unfortunately.
22:35 Tene chromatic: In the parsegrammar() setter, I can look at what I've been passed, and then get and save a namespace in the attribute.  Then in the rest of HLLCompiler, I can rely on parsegrammar being a NameSpace.
22:40 chromatic Yes, sanitizing on input seems sane.
22:42 TiMBuS joined #parrot
23:05 silug joined #parrot
23:06 tetragon joined #parrot
23:09 apeiron_ joined #parrot
23:59 PacoLinux joined #parrot

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

Parrot | source cross referenced