www.parrotcode.org/ | Last release: 0.7.1 "Manu Aloha"
Set by moderator on 17 September 2008.
00:06 silug joined 00:09 AndyA joined
dalek r31998 | particle++ | trunk: 01:30
: [rakudo] more simple refactorings
diff: www.parrotvm.org/svn/parrot/revision?rev=31998
01:40 Ademan joined 01:41 particle1 joined
dalek r31999 | particle++ | trunk: 01:56
: [rakudo] s/perl6/rakudo/
diff: www.parrotvm.org/svn/parrot/revision?rev=31999
02:00 Andy joined 02:04 nopaste joined 02:06 silug joined
dalek r32000 | particle++ | trunk: 02:11
: [rakudo] remove unused debug code
diff: www.parrotvm.org/svn/parrot/revision?rev=32000
02:12 Theory joined 03:12 konobi joined 03:21 Theory joined 03:23 ab5tract joined 03:37 TonyC joined
ab5tract tutorial says i should be able to run 'make test' after generating a new language 03:48
PCT tutorial, sorry. 03:51
parrot isn't generating byte code either 03:52
03:58 konobi left 04:14 tetragon joined 04:30 johbar joined 05:44 Theory joined 06:16 uniejo joined 06:19 uniejo joined 06:35 davidfetter joined
dalek r32001 | cotto++ | trunk: 06:48
: [t] break t/pmc/ro.t into a separate rotest.t file, unTODO the related coverage test
diff: www.parrotvm.org/svn/parrot/revision?rev=32001
06:50 cotto joined
cotto is there a nice way to enumerate a PMC's METHODs in PIR? 06:52
(or an ugly one)
Tene There is. 06:55
cotto get_mro looks like my friend (since I'm just using it to test something) 06:56
Tene get a class object
$P0 = inspect class, 'methods'
$P1 = new 'Iterator', $P0
cotto even better 06:57
except it doesn't work. 07:07
07:13 iblechbot joined
dalek r32002 | cotto++ | trunk: 07:21
: [t] unTODO test and update svn metadata
diff: www.parrotvm.org/svn/parrot/revision?rev=32002
07:31 Ontolog joined
cotto Infinoid, do you know how to use exceptions in PIR? 07:37
er, handlers 07:38
of exceptions
if not, see my reply to #59940 07:39
Zaba_ t/spec/S16-io/basic-open..................................ok 1/9 07:55
stuck :/
08:09 cosimo joined, barney joined
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 08:18 Zaba joined 08:38 gaz joined
barney HLL stands for High level language, e.g. Perl 6, PHP 08:48
.HLL is a directive in PIR that (among other things?) initializen a mapping from standard PMCs to hll specific PMCs 08:50
08:55 tomyan joined 09:35 iblechbot joined 10:00 bacek joined 10:23 tetragon joined 11:45 contingencyplan joined 11:53 tetragon joined 11:56 Zaba joined 12:08 contingencyplan joined 12:24 contingencyplan joined 12:29 kj joined 12:40 Zaba joined 12:52 iblechbot joined 13:02 jq joined 13:03 Ontolog joined 13:10 grim_fandango joined 13:14 uniejo joined
Infinoid msg cotto thanks, but Mark Grimes != Mark Glines, #59940 is someone else 13:25
purl Message for cotto stored.
particle :) 13:27
Infinoid: been thinking about bytecode at all? 13:28
Infinoid thinking a lot, yes. doing anything, sadly not.
particle well, it's important to think before you do 13:30
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
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
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.
particle really, why?
purl really, why is it green, and what is its favorite treat?
particle where were the conflicts?
13:33 gryphon joined
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
guess I'm used to some other SCMs, that do all the work for me *shrug*
PerlJam Which scms "do all the work" of merging? 13:35
I mean, conflicts still need to be resolved by a human. git does all of the work save that.
Infinoid monotone does this nicely, too 13:36
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
I'm not really to that point yet. so the overhead of manually merging is kinda useless
particle yeah 13:38
you can develop the new pmcs in trunk, as long as the tests pass
Infinoid thanks, I thought that might be the case. 13:39
15:11 Andy joined 15:16 johbar joined 15:17 Theory joined 15:36 Wknight8111 joined
dalek r32003 | Whiteknight++ | trunk: 15:38
: [PDD] Add information about get_outer opcode to PDD20. Patch courtesy kjs++ from RT#39615
diff: www.parrotvm.org/svn/parrot/revision?rev=32003
Wknight8111 only 29 more tickets till we hit 600 16:05
...assuming no more bugs are found between now and hen
Infinoid whiteknight++ 16:06
Tene purl: parrotbug?
purl parrotbug is mailto:parrotbug@parrotcode.org or svn.perl.org/parrot/trunk/docs/submissions.pod or see also "rakudobug"
kj it's easy to convert another 20 XXX's to tickets... but let's not :-)
Tene echo "There are too many open tickets. We're still over 600." | mail -s '[BUG] Too many bugs' parrotbug@parrotcode.org
Wknight8111 damnit!
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
16:08 Bzek joined
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 :)
kj hehe 16:10
Infinoid oh? is there a standard rule that defines a number of estimated man-hours per ticket?
other than common sense, I guess
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 16:45 borondil joined, borondil left 17:11 silug joined 17:20 particle2 joined 17:58 chromatic joined 18:06 masak joined 18:22 ruoso joined
dalek r32004 | coke++ | trunk: 18:27
: [t] export another handy test function by default.
: Courtesy mgrimes <mgrimes at cpan dot org> via RT #59938
diff: www.parrotvm.org/svn/parrot/revision?rev=32004
Coke we're quite a few more than 30 away from 600. 18:42
btw, 49832, 56052, 58760 59600 and 59660 are probably all the same issue. 18:43
we're 73 away from 600.
chromatic Coke, he counted just open issues. 18:45
Coke I realize the source of his confusion. =-) 18:46
particle2 i have a question about namespaces and importing 18:47
i'm trying to get that working for rakudo
particle haven't seen pmichaud around in a bit, so maybe you'll have some ideas
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.
chromatic: 53156 you say "fixed", but the ticket is still open. 18:48
... nevermind.
particle currently, rakudo's use and require just wrap eval 18:49
so, when a file is evaled, i need to find out fi any new packages/classes/etc have been created 18:50
then look in the namespaces for symbols to import
but i don't see a good way of walking the past tree using nqp 18:51
i'm wondering if what i really need is package/class/etc registries
and if a new package is added, a callback can be run or something
Tene "walking the past tree"? 18:52
particle see src/builtins/eval.pir
no, sorry, see actions.pm 18:53
line 303 has 'use_statement' method
when 'use Foo' is encountered, a call to 'use' in eval.pir is made
then the result is compiled to past and invoked 18:54
Coke tcl is going to solve something like this by marking on the namespace an attribute that tracks what is exported/able. 18:55
you could then just ask the namespace "what do you have?"
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.
particle if i 'use Foo' there's no guarantee that i get a namespace named Foo anywhere in Foo.pm 18:57
...or that that's the only namespace created.
Coke complain to larry.
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?
particle Foo.pm could start with 'package Bar;
Coke it could, sure. or we could make that a compile time error. :)
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
ok, it doesn't work like that in p5 19:02
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?
chromatic That's because 'use Foo;' turns into BEGIN { require 'Foo'; Foo::->import(); }
particle yep, so it seems
you'd have to do 'require Foo' and Bar->import
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. =-)
particle in perl 6, Foo declares what it exports by creating aliases in subnamespaces
Foo::EXPORT::ALL, Foo::EXPORT::DEFAULT, Foo::EXPORT::my_tagset 19:05
so i know where to look, as long as i have the module name
ok, that's easy enough
Tene It would be really great if all the languages used that same convention, for interop... 19:06
particle i'd be happy if that convention were to have shadow namespaces in the language-private ns 19:07
Coke Tene: except that pollutes the namespaces. 19:08
particle _perl6;Foo;EXPORT;ALL
Tene Coke: s/that/the/
Coke yes. That would be awesome. 19:09
I am not holding my breath. :|
19:14 silug joined
particle ok, the other trick with p6 importing is that it imports to the current block, not current package 19:16
Tene Coke: is it possible to get access to the namespaces directly in TCL? 19:17
Coke I'm not sure what you mean 'directly', but [namespace] gives you a lot of rope. 19:24
Tene 'kay
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?
Coke Given that the _hll namespaces are not really private, I'd have concerns.
Tene "not really private"? 19:26
Coke ... yes. how do you make a namespace private in parrot?
Tene I'm not sure what you mean. private namespace? private to what?
Coke You can't, SFAIK: there's no way to say "this is visible to the users, but this is only for the compiler."
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.
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']
or whatever
chromatic You need language syntax for that.
Tene Right.
Coke for poking into namespaces? already have it.
19:29 gmansi joined
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.
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?
Or...
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
my point is that the _ namespaces aren't a safe place to hide things you don't want the user diddling.
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
Can you give me an example of a problem?
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!
Coke but that's a good thought experiment.
particle ...which can be made safe by outlawing Q:PIR 19:35
Coke ... in perl6.
particle ayep
Tene Coke: a hypothetical example
Coke nothing is stopping arbitrary bytecode from doing whatever it wants in any namespace.
including the "private" ones.
particle admittedly, i haven't reviewed allison's security pdd yet
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.
Coke we should aspire to something a little more secure than perl5's "please don't open this door" model.
ditto what particle said, though. 19:38
Tene But there are plenty of valid reasons to open that door.
Also, how are the root namespaces being exposed to tcl/perl6/whatever in this harmful way?
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?
chromatic You need HLL syntax for that, I mean -- not PIR, unless you allow inline PIR.
Tene use Doom :lang<tcl>; 19:40
That won't do it.
Coke chromatic: yes, but we can't assume poeople running on parrot can't run pir.
Tene That will import some namespaces into my current hll, at most.
Coke Tene: [namespace import ::parrot::perl6::CGI]
[namespace delete ::parrot::_perl6::CGI::EXPORT::DEFAULT] ? 19:41
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.)
it's me waving my hands to show how I'd get to perl6 in the frist place.
Tene Okay.
Coke because if I can't do that, then I don't see how interop will EVER work.
Tene Why is that more of a problem than [namespace delete ::my::cool::namespace] ?
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
help methods that aren't meant to be invokable by the user, etc.
Tene They'll still be called by the same bytecode, though. 19:44
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.
I can stop -myself- from touching that. I can't stop you. 19:46
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.
Tene That's the security pdd. Namespaces aren't a special case there.j 19:48
These namespaces, at least.
Coke Ok. I'll read the pdd.
Tene In your example of 'helper methods' and such, the generated bytecode will be calling those anyway.
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.
which generated bytecode?
Tene The bytecode generated by your compiler. 19:49
Coke I may not be generating all the bytecode I'm running.
(in fact, I hope I'm not. at that point, I'll just use tclsh =-)
Tene Can you give me a hypothetical example of a problem here, or was that your 'delete namespace' example earlier? 19:50
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".
dalek Krishna Sethuraman | Parrot Development on Windows: 19:52
link: www.perlfoundation.org/parrot/index...on_windows
Coke not everything is supposed to be visible to the user.
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.
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.
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.
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.
but in tclsh, this isn't a user visible variable. 19:55
Tene Am I completely off track in that being the sort of bytecode that will be generated by a 'use' statement? 19:56
NotFound Coke: you can put in the lexical environment of a continuation, for example. 19:58
I've readed some tie ago an article about that tricks to have private variables in perl, don't remember where. 20:00
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
I freely admit the possibility that I'm insane here.
chromatic Uninformed about Perl 5, Perl 6, and Topaz: weblog.infoworld.com/fatalexception...chine.html 20:03
Coke there are various levels of access.
well, there -could- be. 20:04
Tene Please explain.
Coke well, ro and rw for one.
public/private/protected/package might be a different way to slice it.
(and making a PMC RO is not necessarily sufficient, since you can simply replace it with a more compliant one) 20:05
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
s/compiler/HLL/
and s/state/functionality/ 20:07
er, state +/or functionality. 20:08
Tene You're talking about, for example, a helper function in the compiler, for performing a common manipulation on an AST? 20:11
Coke I didn't have that example in mind, but sure. 20:13
Tene That would fit the idea you're referring to, though?
Coke yes.
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
Your compiler should already be in its own namespace.
Coke what does "exported" mean at the parrot level? 20:16
Tene Nothing. You can get any symbol in any namespace. 20:17
Coke I posit this is a security issue.
Tene Please explain.
Coke No, I give up now. =-) 20:19
(and this time, I mean it. At least for today)
Tene Running untrusted code, maybe?
chromatic Running an extension written in C? 20:20
Tene Sandboxing is discussed in pdd23.
Mentioned, at least.
"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
narrow ad carefully filtered route to send some data back to the code that called it."
Hmm. That was surprising. 20:22
20:58 gryphon joined 21:33 Theory joined 21:50 rdice joined 21:53 chromatic joined
dalek r32005 | tene++ | hllify: 22:02
: Delete the unused hllify branch.
diff: www.parrotvm.org/svn/parrot/revision?rev=32005
22:05 jan joined 22:10 chromatic joined
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.
chromatic Tene, Parrot doesn't make that distinction, unfortunately. 22:33
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:35
chromatic Yes, sanitizing on input seems sane. 22:40
22:42 TiMBuS joined 23:05 silug joined 23:06 tetragon joined 23:09 apeiron_ joined 23:59 PacoLinux 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!