Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8
Set by moderator on 27 March 2011.
davidfetter dukeleto, wiki.postgresql.org/wiki/PgCon_2011_PL_Summit <-- a lot sketchy atm. selena's organizing 00:00
00:06 mtk left
tcurtis whiteknight: Do you know if there have been any advances in LALR parsing table creation since "Effficient Computation of LALR(1) Look-Ahead Sets"? 00:09
whiteknight in terms of the underlying theory, no
I'm sure there have been tons of tricks and optimizations found at the implementation level 00:10
sorear I recommend trying to read and understand the source of a couple major LALR systems (bison, happy, antlr) 00:11
if you can't, it means you don't understand the theory well enough 00:12
and you'll know if there are any improvements in standard practice
00:13 mtk joined
dukeleto mtk: welcome! 00:13
theory just wants to be understood. 00:14
dukeleto whiteknight: imcc_compreg_pmc "make test" passed on g++ 4.4.3 on 64bit ubuntu (minus the tests that I broke in extend_vtable :) )
theory: in what way? 00:15
whiteknight yy!
theory dukeleto: responding to what sorear said. :-)
bubaflub tcurtis: there is a pretty good ANTLR book, haven't grok'd all of it but that might be a good place to look 00:18
cotto ~ 00:33
What's the appeal of bcc? All it does is make me sad and break my email filters. 00:35
00:36 petdance joined
sorear It probably seemed like a good idea at the time 00:37
petdance ping dukeleto 00:42
davidfetter cotto, in my case, it's helped me mediate some disputes. 00:44
whiteknight Parrot has preposterously few disputes that need mediation 00:55
compared to my work with other projects and communities, that is 00:56
bubaflub whiteknight: i've used it to mediate problems at work as well 00:57
benabik We're just awesome that way. :-D
dalek sella: 237774e | Whiteknight++ | src/test/ (4 files):
Add a little message at the end of the test run giving the status
 01:00
sella: fcbf696 | Whiteknight++ | src/test/Listener/TAP.winxed:
some docs for TAP listener
01:05 davidfetter left 01:06 kid51 joined 01:19 petdance left 01:42 whiteknight left 01:47 bubaflub left 02:05 hudnix left 02:13 petdance joined 02:19 kid51 left 02:26 dafrito_ is now known as dafrito
soh_cah_toa says goodnight to parrot 03:26
03:26 soh_cah_toa left 03:33 Eduardow left 03:35 Eduardow joined 03:51 jrtayloriv joined 03:52 rblackwe left 03:53 rblackwe joined 04:12 benabik left
dalek rrot: 96a2ce1 | petdance++ | include/parrot/interpreter.h:
The interpreter args get splint annotations, too
 04:16
rrot: 90907c6 | petdance++ | src/hll.c:
Fixing the splint arg annotation
04:21 benabik joined
benabik cottom bacek, dukeleto and anyone else interested: I clarified the "Bugfix" and "Work continutes" lines in my GSoC proposal. gist.github.com/899867 04:48
*cotto ^^
bacek_at_work benabik, still looks good :) 04:49
cotto benabik, reading now 04:52
04:53 JimmyZ joined 04:55 JimmyZ left 05:01 AzureStone left 05:07 AzureStone joined 05:08 simcop2387 left, simcop2387_ joined, simcop2387_ is now known as simcop2387
dalek rrot: 3ddb811 | petdance++ | src/io/buffer.c:
consting local vars
 05:18
rrot: f7917a6 | petdance++ | / (3 files):
updating splint annotations
rrot: 3b2a395 | petdance++ | src/gc/mark_sweep.c:
fixing splint annotations
05:20 theory left 05:23 simcop2387 left, simcop2387_ joined, simcop2387_ is now known as simcop2387
benabik It's starting to get early, I should sleep. G'night, #parrot 05:25
cotto 'night benabik 05:29
05:30 petdance left
dalek rrot: a044b31 | petdance++ | src/gc/string_gc.c:
consting locals
 05:36
rrot: 7785900 | petdance++ | / (2 files):
updating splint annotations
05:39 simcop2387 left 05:53 simcop2387 joined 06:00 simcop2387 left 06:01 simcop2387 joined 06:05 simcop2387 left 06:06 simcop2387 joined 06:11 he__ joined, simcop2387 left 06:13 simcop2387 joined 06:15 ShaneC1 joined 06:16 ShaneC left 06:23 woosley joined
tcurtis should also sleep soon but needs to do a bit more work on and then post proposal to melange. 06:58
06:58 bacek left
tcurtis submitted updated proposal. 07:14
To melange, specifically. I'll email a link to parrot-dev now. 07:15
tcurtis sent the email. 07:17
tcurtis sleeps now.
cotto tcurtis, awesome 07:20
he__ So, I've finally found out some about why some new(?) tests in 3.2.0 fail on NetBSD. 07:27
Smolder report on smolder.parrot.org/app/projects/rep...ails/13975
It turns out that parrot always sets the st_rdev member to 0, while perl does not.
Ref. stat_buf_to_array() in dynpmc/os.pmc. 07:28
cotto seen fbrito 07:34
aloha fbrito was last seen in #parrot 68 days 13 hours ago leaving the channel.
cotto dukeleto, ping 07:35
he__ and stat(2) may not modify the st_rdev member, so leaves whatever garbage was there from before. 07:46
Fix? The tests for stat and lstat should do "$s[6] = 0; # Parrot does this internally; value irrelevant for plain files" 07:47
07:54 mtk left 07:58 contingencyplan left 08:01 mtk joined 08:06 dodathome joined 08:08 bacek joined 08:15 fperrad left 08:26 silug left 08:28 dafrito left
bacek ~~ 08:28
08:36 dafrito joined, dodathome left 08:39 dodathome joined
bacek seen moritz 09:13
aloha moritz was last seen in #perl6 3 hours 29 mins ago saying "\\o/".
bacek seen sorear
aloha sorear was last seen in #perl6 3 hours 22 mins ago saying "o/ moritz".
moritz was last seen when I looked into a mirror
bacek moritz, question about grammars. Here or better move to #perl6? 09:14
moritz bacek: I don't mind, most people that can answer are in both channels :-) 09:15
09:18 ShaneC1 left 09:35 UltraDM joined 09:39 jrtayloriv left
dalek rrot/jit_prototype: ce26842 | bacek++ | / (2 files):
[opsc] Fix parsing of enclosed EXPR. moritz++ and jnthn++ for help
 09:41
09:49 dd070 joined 09:53 dd070 left 10:32 woosley left, UltraDM left
nopaste "he" at 192.168.1.3 pasted "Fix for stat/lstat tests" (20 lines) at nopaste.snit.ch/39539 11:14
he__ Hoping someone might pick up this two-line fix. 11:15
11:18 JimmyZ joined
JimmyZ he__: please submit to trac. trac.parrot.org/ 11:19
he__ ok, then.
11:33 woosley joined 11:36 JimmyZ left 11:55 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
he__ JimmyZ: I must be stupid. I've successfully logged in to trac.parrot.org/, but for the life of me I can't find a butten called "(Create) New ticket". Help?!? My top menu only says "Wiki", "Timeline", "Roadmap", "Browse Source", "View Tickets", and "Search". And "View Tickets" is indeed only "View". 12:01
moritz he__: might be related to the newest ticket spam wave 12:05
12:05 UltraDM joined
he__ Well, I'll then just have to wait for a friendly soul with a "commit bit" to pick up the diff, which is now, btw, committed to NetBSD's pkgsrc to make parrot 3.2.0 packaged there pass all its tests. 12:13
moritz where is the diff?
ah, there's a nopaste in the backlog
he__: testing now, will push if it passes tests here 12:15
he__: should I use your ircname as attribution for the patch? 12:21
12:22 Hackbinary left 12:26 whiteknight joined, lucian joined
moritz ... timeout. 12:31
dalek rrot: 3d5abb6 | moritz++ | t/dynpmc/os.t:
fix stat on NetBSD. Patch courtesy by Havard Eidnes
moritz he__++ 12:32
12:39 benabik left
lucian g'day 12:41
12:42 estrabd left, estrabd joined 12:51 hudnix joined 12:54 bluescreen joined
he__ moritz: sorry, had gaze elsewhere. Thanks for committing, though. 12:55
moritz you're welcome. Thanks for the patch. 12:56
12:59 bluescreen left
tadzik I don't get it. If "Parrot does this internally", why the need to add it? 13:05
13:10 benabik joined 13:14 bluescreen joined 13:28 lucian_ joined 13:31 lucian left
whiteknight good morning, #parrot 13:33
tadzik good morning whiteknight 13:38
13:39 rohit_nsit08 joined
whiteknight hello tadzik: how are you? 13:41
rohit_nsit08 whiteknight: hello, good morning
whiteknight hello rohit_nsit08
tadzik whiteknight: nothing fancy, how about you? 13:42
benabik 'lo whiteknight! 13:43
rohit_nsit08 whiteknight: i wanted to know more about parrot objects? got some good comments from cotto about my proposal today . 13:44
moritz we have design documents that are worth reading 13:45
rohit_nsit08 I have read the wiki book, is it there?
moritz docs.parrot.org/parrot/latest/html/pdds.html
rohit_nsit08 moritz: thanks ! 13:46
benabik rohit_nsit08: I've found the wiki book to be slightly out of date. The concepts are usually right, but the details are sometimes wrong.
13:46 lucian joined
rohit_nsit08 benabik: ya it was mentioned in it, I used it for concepts of PCT 13:47
13:49 lucian_ left
whiteknight I wrote that wikibook, and I haven't updated it in years 13:50
13:51 simcop2387 left, simcop2387 joined
whiteknight rohit_nsit08: I think you can ignore the object model initially, and just use Hashes for all your objects 13:59
the JS "object model" is pretty simplistic semantically 14:02
Andy_ whiteknight: The always-use-PMCNULL is fine with me.
whiteknight Andy_: good! I'm more in favor of consistancy than I am in favor of any particular route to get there 14:03
Andy_ I'd also like to some point float the idea that we make some vmethods take const args. 14:04
14:05 he__ left
Andy_ For instance, if you're comparing two PMCs, can they both be declared const? Can we safely restrict whatever vmethods come down the pipe to the restriction of "If you want to compare two things, you have to do it without modifying them"? 14:05
whiteknight Andy_: I like that idea 14:06
Andy_ How about deciding if a PMC is booleanly true?
etc
whiteknight any get_* vtables are good candidates
benabik Haven't we already had to start deciding that for the GC write barriers? 14:07
Andy_ I don't know squat about how PMCs are working inside, so it might not be feasible.
whiteknight benabik: sort of
Andy_ benabik: I don't know. What's a GC write barrier? :-)
benabik: Have we met?
I mean here on IRC?
You'll find that I know C and that's about it. :-)
whiteknight benabik is one of our prospective GSoC students 14:08
Andy_ Aha.
benabik Andy_: Not sure of details, but I think we had to add markings to some operations to tell the GC "hey, we're changing things in here".
Andy_: And no and what whiteknight said.
whiteknight benabik: we added write barriers to the code generator by default to certain vtables. They can still be added manually if needed elsewhere 14:09
benabik whiteknight: So we've declared "these vtables definitely aren't const", but not "these ones must be const"
whiteknight right
Andy_ Are you talking about the tables, or the methods pointed to by the tables? 14:10
whiteknight Andy_: I can think of at least one data structure (Splay Tree) that would want to modify its internals in response to a read. Parrot doesn't use that internally now, but I would hate to create a situation where it could not be used by an extension
Andy_ RIght, that's what I was a fraid of. 14:11
whiteknight for almost any modification, it's possible to think of an imaginary fringe situation that would be detrimented by it
Andy_ Right
benabik Also, determining some values might require heavy calculation that could be cached.
whiteknight so that's not a great argument to do nothing
benabik That's the most generic "fringe" situation I can think of.
Andy_ Even if we just say "Every arg is ARGMOD()" that's a help.
whiteknight benabik: right, caching is quite important to consider as well. Several of our built-in PMCs do aggressive caching 14:12
Andy_ Because right now, splint knows nothing about anything.
If it's a vmethod, it has no help.
14:12 UltraDM left
whiteknight Andy_: okay, so that's an interesting project. Adding ARGMOD to vtable args should be easy enough to do at the pmc2c level 14:12
Andy_ oh, sure
and the vtable_h.pl, etc. 14:13
whiteknight if only there was a group of available developers who were looking to start making commits to parrot, to prove their skills....
Andy_ but I bet there are some we can reliably say "this is still const"
can_method_t
does_method_t
whiteknight Andy_: yes, that's probably true
Andy_ get_namespace_method_t
whiteknight Andy_: any STRING argument should be const
and ARGIN 14:14
Andy_ the stuff that is about the PMC itself, not the values
whiteknight: Just doing ARGIN(const STRING *) would be a good starting point.
whiteknight yes, I suspect so
Andy_ I don't know if you've noticed, but on master I've changed PARROT_INTERP to ARGMOD(ParrotInterp *) 14:15
whiteknight it's hard to imagine we would get any performance benefit. The big drain there is the indirect method call itself, not anything to do with the args
Andy_ No, i'm not concerned about performance.
whiteknight Andy_: no, I hadn't noticed
benabik Andy_: What're you working on?
whiteknight Andy_: right, but getting more help from splint in proving correctness is almost as good
Andy_ My goal is to have every pointer annotated 14:16
benabik: splint and static analysis.
splint and other static analysis tools
benabik Andy_: Ah. Occasionally grueling, but very useful. 14:17
whiteknight extremely useful
Andy_ And all I can help with, because I don't have the big brains to handle the VM stuff. :-)
benabik: And occassionally on ack 2.0
whiteknight Andy_: is there an ETA on ack2.0? 14:18
Andy_ No
I haven't touched its code in weeks.
whiteknight curses quietly
Andy_ Been working on slides for CodeConf.
benabik Andy_: Bah. Everyone's better at something than others and Parrot's big enough to need a little of everything.
Andy_ benabik: Understood, and that's why I do what I do. 14:19
You're cheering to the captain of that cheer squad.
whiteknight I think I'm the only person at work who uses ack. From the commandline I can find things much faster than the rest of the goobers with their built-in VisualStudio search
Andy_ Their loss. :-) 14:20
It's amusing and heartening to see ack-specific questions on StackOverflow now.
benabik is ashamed to say he just uses `grep -R`, although `git grep` is more common these days.
whiteknight Andy_: I was interested in doing an implementation of Boyer-Moore for Parrot, but I think it would not work well with Parrot's string system. We would lose a lot of the potential optimizations 14:21
Without that, there isn't going to be a compelling alternative to ack running on Parrot any time soon 14:22
Andy_ benabik: and sometimes I blog to Perlbuzz, as in: perlbuzz.com/2011/04/perlbuzz-news-...04-06.html
And sometimes I do actual work for my employer, because I have to get a project out by monday night so the website is ready for TLA. 14:26
www.txla.org/annual-conference
Oooh, book cart drill team! www.txla.org/bookcart 14:27
Ok, back to work. 14:28
14:36 darbelo joined 14:44 lucian left 14:46 bluescreen left, lucian joined 14:50 lucian left 14:51 lucian joined 14:52 contingencyplan joined 14:57 bluescreen joined 15:00 dd070 joined 15:04 dd070 left
whiteknight yay, another proposal submitted 15:07
benabik Boo, more competition. ;-) 15:08
I mean, yay!
15:09 rohit_nsit08 left
whiteknight benabik: if your proposal is sufficiently high quality, that's not a concern 15:09
PerlJam benabik: or if the others are of sufficiently low quality ;> 15:10
whiteknight I think it's time for some espionage!
NotFound Are you thinking about making vtables const again? I think it will be yet another waste of time.
benabik Well not only am I the most awesome person ever, I know everyone else is horrible so I win both ways, right? ;-D
benabik is pretending to have self-esteem and hope he's not over doing it. ;-) 15:12
Andy_ NotFound: "Yet another" waste of time?
NotFound Andy_: It was done another time. And been reverted because we never know when the PMC values needs to change. 15:14
Andy_ NotFound: And that's a valuable decision to be made and to explicitly document. 15:16
and annotate for splint.
NotFound Andy_: What decision? 15:17
Andy_ That we can't const PMCs.
NotFound Andy_: is easy: none.
Andy_ Yes, yes, I know, you think this is all stupid. 15:18
Anything else to add?
NotFound Is not stupid, is just wrong.
Andy_ What is "just wrong"?
NotFound Attempting to const vtable functions. 15:19
Andy_ Not wrong at all.
We can, for instance, const the STRINGs passed in.
We can probably const the args in methods like can_method_t.
15:19 M_o_C joined
NotFound Andy_: we can't. STRINGs can always change. For example, its hash value mey need to be evaluated. 15:20
Andy_ And when we figure which args can be consted and which can't, we can then explicitly annotate them.
sorear NotFound: cases like that are why the standards allow 'casting away constness' 15:21
Andy_ sorear: If we're allowing casting away constness, we are making constness pointless. 15:22
sorear: Where in the docs does it say that? 15:23
sorear I read it in a commentary somewhere, I forget where 15:25
Andy_ I see nothing in and .pod in the tree
sorear By 'standards' I meant C89 and C++89
Not pddXX 15:26
NotFound sorear: the standard allow casting away constness for people that know what they are doing. And there are not a great quantity of such people.
Most just says "Uh, C sucks" when something goes wrong because of wrong usages of such features. 15:28
PerlJam I'm confused ... a second ago you guys seemed to be on opposite sides of an argument and now it seems like you're really agreeing. 15:29
:-)
NotFound In particular, make a function parameter const just by casting away constness inside it is never correct.
benabik PerlJam: Let them argue, it seems to make them happy. ;-) 15:30
NotFound PerlJam: consting is good when weel done. My point is that in parrot vtables it cannot be done well.
15:37 mj41 joined 15:38 lucian_ joined
sorear casting away constness to emulate C++ "mutable" seems fine to me 15:38
NotFound sorear: is not. 15:39
sorear: if mutable was not needed to do that, C++ will not have introduced it. 15:40
Andy_ If a function needs to cast away constness of an arg, then it should not be declared const.
You'd be upset if strlen(p) modified *p, wouldn't you?
NotFound If we want mutable, we should switch to C++.
An I think that battle has been already fought, long time ago. 15:41
15:41 lucian left, lucian_ is now known as lucian 15:42 Eduardow left
TimToady thinks mutable vtables is a good way to pessimize a VM 15:43
arguing about C/C++ semantics is kinda beside the point, if the problem is in parrot design 15:44
this is somewhat symptomatic of the impedance mismatch between the dynamic typing mindset and the gradual typing mindset 15:46
the point of gradual typing is to be able to nail things down that look nailable, not to keep everything as dynamic as possible forever 15:47
sorear TimToady: 'vtable' in this context is somewhat of a misnomer; the subject of the discussion is whether $object.get_hash_code is allowed to cache the hash code even if $object is declared const
Andy and NotFound are taking a philosophical stand against modifying memory through const pointers 15:48
Andy_ It's not even philosophical. 15:49
I'm saying that if we need to modify memory through a pointer, that pointer should not be consted.
NotFound sorear: not philosophical at all. Lying to the compiler generates hard to debug bugs.
Andy_ And that if you have to cast away the constness, then the solution is not to cast away the constness but to change the constness of the arg.
PerlJam "lying to the compiler"? 15:50
Andy_ PerlJam: Imagine you have implemented strlen.
And your implementation of strlen(p) modifies *p
NotFound PerlJam: if you tell the compiler that something is const and it can optimize based on that assumption, and then you modify it, you are lying.
whiteknight I'm perfectly happy making parameters in certain PMC operations const, if those operations are not overidable by subclasses in any way
Andy_ If inside of strlen you say "char * fake_p = (char *)p; *fake_p = 'x'" 15:51
you are lying to the compiler
whiteknight as soon as you open the operation up for general use by coders who are not us, there are going to be problems
sorear If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined.
Andy_ and then, what if you call strlen("foo")
You are now modifying an immutable string.
etc etc etc
NotFound sorear: yeah, and undefined means: "You are doomed"
sorear: Have you hear about the DeathStation? 15:52
sorear STRINGs are never ever defined with const-qualified tye
so that undefined behavior doesn't apply to us
TimToady .o(slippery slope arguments considered harmful)
Andy_ sorear: But we're not talking just about STRINGs.
NotFound sorear: Is a mytical machine that in any usage of C undefined behaviour kills you.
sorear Andy_: oh? 15:53
NotFound That can be done with strict observance of the standards.
Andy_ sorear: Yes, we are not just talking abotu STRING *
TimToady the const abstraction can be thunk of at more than one level
Andy_ For instance, can we say that can_method_t functions have its self arg be declared const?
I'd think we could. 15:54
TimToady a type can have const-y semantics on an abstract leve, but non-const-y infrastructure to support it, like COW or caching or whatever
*level, can't type with this stupid write brace 15:55
*wrist, grr
sorear Andy_: I agree that consting PMCs is dubious at best
Andy_ sorear: Great. 15:56
And if we don't const them, that's fine. And we annotate them as ARGMOD() so that splint knows that they can be modified.
lucian TimToady: i'd love some persistent data structures in parrot (offtopic)
NotFound Problem is: we use PMC internals a lot inside parrot, we don't only call functions that can be written carefully to allow that abstractions.
Andy_ I'm more interested in making the interface explicit than I am specifically consting anything. 15:57
15:58 theory joined
NotFound Andy_: I'm perfectly happy with documenting what vtables are supposed to be logically cont. 15:58
const.
Andy_ I don't care about logically const. I want to document what the compiler can know is const. 15:59
PerlJam NotFound: you just don't want your compiler carping at you when you violate that logic on purpose?
NotFound For example, documenting that get_integer is not supposed to change the viewable behaviour of the PMC.
Andy_ NotFound: If you want to document that, great. That's at a higher level than I'm working. 16:00
NotFound But that and making the SELF of that vtable const are very different things.
Andy_: is just an example.
Andy_ Yes, I know.
I know they are different.
NotFound PerlJam: sometimes you can violate that logic on purpose in a safe way, but is not easy. 16:03
Specially in target as moving as parrot.
16:12 bluescreen left 16:15 bluescreen joined
PerlJam whiteknight: I just read your response to the template engine proposal and it made me chuckle a little bit when you asked which testing library he'd use because earlier, I was going to tell you that you should push yours a little bit on all of the GSoCers so that it gets well used. :-) 16:24
whiteknight PerlJam: I've been mentioning it, but I have not been pushing it on anybody
I want people to use whatever is best and easiest for the job 16:25
and I want to give plenty of examples that the best and easiest is Rosella :)
dukeleto This looks interestting: github.com/cscott/TurtleScript 16:35
benabik dukeleto: It does look interesting. I like that he's borrowing yadda from P6. I wish more languages had it. When I was building my compiler last quarter I kept writing a nyi() function to throw UnsupportedOperationExceptions. 16:41
16:41 mj41 left
benabik Ah, well. Off to school. midterms-- 16:45
16:47 benabik left 16:53 particle1 joined 16:57 particle left 17:01 Eduardow joined
cotto_work ~ 17:04
17:05 dmalcolm joined
lucian allison: ping 17:11
17:12 mj41 joined 17:24 rohit_nsit08 joined 17:38 ShaneC joined 17:39 M_o_C left 17:43 benabik joined, benabik left
rohit_nsit08 whiteknight: i was going through the parrot's object model and prototype object model of javascript, how should i mention them in the proposal? 17:52
whiteknight rohit_nsit08: Whatever you think is relevant. If you think you have to do work, mention it
if not, say you won't
dalek p/ctmo: 3befd15 | jonathan++ | src/stage0/ (7 files):
Update bootstrap with latest changes.
rohit_nsit08 It may or may not be required, depends on the situation that time , i know that i'll be using parrot's PMC to implement JavaScript objects and hierarchy but it will be only a guess right now 17:54
tadzik aloha: clock? 17:57
aloha tadzik: LAX: Wed, 10:57 PDT / CHI: Wed, 12:57 CDT / NYC: Wed, 13:57 EDT / UTC: Wed, 17:57 UTC / LON: Wed, 18:57 BST / BER: Wed, 19:57 CEST / TOK: Thu, 02:57 JST / SYD: Thu, 03:57 EST
lucian can PMCs be cloned easily? if yes, it'd be quite easy to implement a crummy prototypal object system 17:59
NotFound lucian: clone $P1, $P2 18:00
whiteknight define "easy" and "cummy"? 18:01
"crummy"?
lucian whiteknight: it'd be easy because you'd only need Classes for base objects
crummy because it'd likely be slow and not great design 18:02
whiteknight In a naive JavaScript implementation, I don't think we need to use Classes or Objects at all
lucian i don't see how you could get away without JS objects
whiteknight for instance, if every JavaScript object were a Hash, you could implement all operations you would need 18:03
lucian do you mean just implement JS's 'object' with a hash?
whiteknight right
dalek nxed: r937 | NotFound++ | trunk/ (3 files):
Stages 1 and 2 now can't be invoked directly from command line

Non installed driver uses load_bytecode for stages 1 and 2. Auxiliary methods in the compiler object to workaround lack of features in non installed driver. Makefile changes to adapt it to the other changes.
NotFound Note the "naive".
lucian then you'd need to do obj.prototype
whiteknight the only place where you would need somethign tricky is in function objects. Those could be a hash with an attached "invokable" property
lucian whiteknight: there's obj.apply() in JS
whiteknight lucian: We can easily have a fallback mechanism to find method objects for built-in types 18:04
lucian whiteknight: anyway, you'd have to reimplement object attribute resolution 18:05
whiteknight and there's no reason we can't insert a .apply invokable attribute on an invokable object. They're all hashes. All we need to do is set up the right prototypes
invokable.prototype could have a .apply method in it 18:06
lucian whiteknight: it does seem like reimplementing a lot 18:10
whiteknight lucian: Maybe I'm oversimplifying. It doesn't seem to me like we need to do a whole hell of a lot
lucian the biggest issue to me seems dispatch 18:11
whiteknight we set up a few hashes ahead of time as prototypes for the builtin "types", then just treat everything like annotated hashes
lucian you'd have to write that, when Object or 6model would provide it
whiteknight I don't see the problem with dispatch
$P1 = $P0["foo"] \\n $P1()
JS doesn't have inheritance or anything like that 18:12
lucian sure, but you have to walk the prototypal chain
sure it does
plenty of inheritance
whiteknight once you clone the prototype, you create a flat Hash which contains all the necessary methods
lucian if an attribute isn't in obj, look for it in obj.prototype. then obj.prototype.prototype
whiteknight there's no walking any chain for method dispatch
lucian that'd be wrong semantics 18:13
if the prototype changes, your hash wouldn't change
whiteknight right, because when you clone, you create a separate copy
lucian and that's not how JS works
whiteknight you can change the copies without any references between them
lucian whiteknight: but why copy at all? 18:14
whiteknight so you're talking about taking a lazier approach?
lucian you need a reference to the prototype object, that's all
js's attribute dispatch is lazier, semantically
whiteknight that's fine. We can annotate the Hash object.
lucian go ahead and cache, sure
whiteknight all PMCs in Parrot have properties, which can be set and used independently of attributes. 18:15
we can easily have a "prototype" property, in addition to normal entries in the Hash
lucian right. and then you don't need to copy anything when you make a new object 18:16
whiteknight and we can have a simple dispatch function written at the PIR level which can recursively search for prototypes
lucian yeah, that sounds roughly correct
whiteknight good. So we've got a lazy implementation and *still* don't need to use Class or Object types
lucian i'm not sure how NaN, null, undefined and numbers work into that
whiteknight: don't need, no 18:17
it's very similar to my plan for python3 if 6model is crap
whiteknight considering the deficiencies of our current MOP, we probably don't want it either
lucian whiteknight: from what people've been telling me, 6model should fit python's object model reasonably well 18:20
if so, JS's too
it _should_ be faster and cleaner 18:21
whiteknight 6model is probably the better MOP for the JS compiler, yes. I don't think it's worthwhile to do anything fancy with the JS object model during GSoC 18:22
lucian 6model being fancy?
whiteknight I mean, we can get it working well with Hashes, then swap out once we have a better option built into Parrot itself
it's fancy in that it's external to Parrot
lucian right
whiteknight once it's part of Parrot, it's a no-brainer
lucian yeah, i was thinking similarly for python 18:23
but for python, it might be harder to implement it with hashes than with 6model
whiteknight Maybe, yes. There are no hard and fast rules here
jnthn_ Using an underlying hash and using 6model are not mutually exclusive. 18:24
dalek nxed: r938 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler
jnthn_ OK, Parrot folks, I've come to strike terror into your hearts.
I have a problem with IMCC.
whiteknight jnthn_: ?
jnthn_ Of note, if you do
.lex 'foo', $P0
.lex 'bar', $P1
.lex 'baz', $P2
whiteknight jnthn_: I have a huge IMCC refactor branch going to merge in tonight or tomorrow probably 18:25
doesn't change any semantics, but I'm not going to be making unrelated changes to IMCC until that happens
jnthn_ And you didn't previously assign to $P0, $P1 or $P2 then it actually seems to give the same register mapping to all of those lexicals.
whiteknight ...lolwut?
are you kidding?
jnthn_ No :'(
whiteknight damnfartcrap
18:25 soh_cah_toa joined
whiteknight I hate our lexicals 18:25
jnthn_ We never ran into it much before because nobody ever implemented the whole static lexpad thing 18:26
Then I did in a dynpmc
And then I found multiple lexicals sharing a register O_O
Anyway, I'm...a little stuck for any way to actually work around this too :/ 18:28
To make matters more confusing, at least comments in IMCC suggest it should do the right thing 18:30
in reg_alloc.c:
/* all lexicals get a unique register */
allocate_lexicals(interp, unit);
soh_cah_toa does parrot use any llvm libraries? 18:31
jnthn_ whiteknight: Do you happen to know that use_count is on line 659 of reg_alloc.c? 18:32
whiteknight: does .lex 'foo', $P0 count as a usage?
whiteknight I have no idea
soh_cah_toa: not yet. We are planning to use LLVM for our JIT, but we haven't implemented that yet 18:33
bacek is working on a prototype
jnthn_: Can you create a ticket and assign it to me?
jnthn_ whiteknight: Give me a moment to dig a little further first.
There's always a chance I can send a patch too... 18:34
With the emphasis on "chance" :P
soh_cah_toa hmm...okay. regardless, does parrot perform profile-driven optimizations or runtime optimizations?
whiteknight soh_cah_toa: right now, now
no
soh_cah_toa good
b/c i had an idea for stepping backwards in the debugger 18:35
if it performed runtime optimizations, some code may be changed during re-execution
whiteknight we do most of our optimizations at the PAST, POST, and PIR levels 18:36
soh_cah_toa basically you'd keep a step count and if you want to move backwards n steps, you re-execute the program (either two passes or one) until step count - n occurs 18:37
whiteknight We treat bytecode as mostly immutable once it's loaded to help with threading issues
of course, we don't have threading right now, so that's a moot point
soh_cah_toa ah, that too
good, b/c the only experience w/ threads that i have is w/ java
lucian whiteknight: i'd vote for bytecode staying immutable
whiteknight lucian: yeah, that's my vote. If we're going to be optimizing bytecode at all, it should be prior to loading in the interpreter 18:38
we can do all the crazy optimizing we want at the compilation stage. After that, we can't be changing bytecode if various things are pointing into it
lucian whiteknight: not only that, but there are some jit techniques that are hard with mutable bytecode 18:39
soh_cah_toa that's the traditional way. even though that's easier to manage, the optimizations may not be too accurate
b/c optimization is based of the patterns of the developer and not the user 18:40
*off
whiteknight soh_cah_toa: in short, treat bytecode as if it's immutable. If you can step backwards, that's fine
lucian i think it's more than fine, in fact :)
soh_cah_toa that makes things easier, good. 18:41
i'd also like to know if there is an interrupt opcode
or trap, whatever
whiteknight maybe. If there is, it's old and crufty 18:44
github.com/parrot/parrot/tree/master/src/ops
the *.ops files contain the op definitions
soh_cah_toa ok good 18:45
whiteknight there's a debug opcode
core.ops
ah, trap opcode in experimental.ops 18:46
soh_cah_toa b/c i was reading about an interesting way to implement breakpoints. the user specifies where the set the breakpoint, and you overwrite the first byte of the insutruction in memory w/ the value for the interrupt/trap instruction. when that instruction gets executed, you capture the trap
but then you have to worry about re-writing the original instruction back and stuff. just thinking whether or not it's do-able 18:47
whiteknight I was thinking that when you set a breakpoint, you could do a search through the annotations for a matching symbol
search for a file annotation, then search for a matching line annotation 18:48
soh_cah_toa that's an idea 18:49
i need for find out more about packfile annotations
does pbc_dump list annotations?
i know i'd use the PackfileAnnotation pmc but i need to find out about the different types of annotations 18:51
whiteknight jnthn_ is the original author of annotations, I think 18:52
plobsing has done some work on it recently too
soh_cah_toa alright, i'll talk to them 18:53
i think the debugger is going to be pretty kickass
whiteknight it better be! 18:54
:)
soh_cah_toa haha
well, i definitely plan on sticking around afterwards to implement future improvements
can't just leave you guys hanging
whiteknight We're definitely happy to have you 18:55
PerlJam soh_cah_toa++ I hope you get one of the slots.
Andy_ I laffed: i.imgur.com/AKUiT.jpg 18:56
whiteknight interacting with the community is very very important.
soh_cah_toa crosses his fingers
cotto_work Andy_: that's great
PerlJam Andy_: heh!
soh_cah_toa that's hilarious! 18:57
whiteknight It's important that we get to know the students, that we assess the capabilities of the student, etc. This is why having technical conversations with students and accepting patches from students is so important
soh_cah_toa yeah, i think i'm going to dig around the trac tickets this weekend for something to fix. all i got so far are some mistakes i've noticed in the docs since i've been reading all of them 18:58
cotto_work soh_cah_toa: that's a good start 18:59
whiteknight soh_cah_toa: last I looked, we have a tragic lack of function-level documentation in src/debug.c
that seems like it's right up your alley 19:00
soh_cah_toa good idea
whiteknight docs/debug.pod and docs/debugger.pod probably could use some editing, spellchecking, revising, expanding too 19:01
I don't know how much of a writer you are
soh_cah_toa i'm actually very good 19:02
i'm not english major but i can make a pretty good research project
PerlJam soh_cah_toa++ 19:03
soh_cah_toa must be all that cyberpunk i read :)
jnthn_ My word, I'd forgotten how totally nuts imcc is... 19:04
19:05 bubaflub joined
soh_cah_toa oh that reminds me. i've got some low resource machines i can benchmark imcc on 19:05
bubaflub ~~
19:05 davidfetter joined
soh_cah_toa would i just run "make benchmark_tests" and send the results to parrot-dev? 19:08
whiteknight soh_cah_toa: I don't think we have a standard place to send those kinds of results to
compile them to post them here in a gist or something
soh_cah_toa okay 19:09
whiteknight if the numbers are absurd, we can open a ticket to address them. If the numbers look good they will probably just be forgotten
soh_cah_toa alright
i've got some old machines i could use but could i use a virtual machine as well? 19:10
whiteknight I use VMs sometime
soh_cah_toa okay and just tinker w/ the amount of ram
whiteknight although it's hard to get accurate performance benchmarks on a VM that's sharing resources
soh_cah_toa true
is there any specific os that it hasn't been tested on or not as much? 19:11
whiteknight Windows is the big under-represented system 19:13
the BSDs are not tested as well as linux. Solaris also
I gave up on solaris myself after the oracle purchase, and I couldn't get Parrot to install and run tests on the offshoot systems 19:14
illumos might be more mature now if you want to test that
soh_cah_toa good. i've got a windows xp machine i'm building for my mom that be perfect 19:15
i pick up all the pc components i can find at my local recycling center so i can experiment w/ ram anywheres from 64mb to 1gb
19:32 ambs joined 19:41 ambs_ joined, ambs left, ambs_ is now known as ambs 19:44 ambs left 19:46 ambs joined
dalek tracwiki: v19 | benabik++ | ParrotGSoC2011Students 19:47
tracwiki: Adding links to my proposal
tracwiki: trac.parrot.org/parrot/wiki/ParrotG...ction=diff
19:51 pjcj left
soh_cah_toa how do i add a link to my proposal on trac.parrot.org/parrot/wiki/ParrotG...11Students ? i've submitted to google-melange and also gist but it's not there for some reason 19:51
whiteknight soh_cah_toa: you have to add it there if you want it 19:52
are you set up as an editor for trac?
soh_cah_toa not yet. i guess that means i should do that 19:53
whiteknight create an account on trac. We'll have to give you permissions to edit
we've been having a spam problem, so we temporarily locked down editing permissions. 19:54
cotto_work whiteknight: have we gotten any wiki spam? It might be useful to allow authenticated users to edit the wiki.
whiteknight ah, that's true enough 19:55
soh_cah_toa alright, made an account
whiteknight brb phone
soh_cah_toa sure
cotto_work soh_cah_toa: try editing something. it should work now 19:56
19:57 lucian left, rohit_nsit08 left
soh_cah_toa it works now. thanks 19:57
19:58 lucian joined
cotto_work great. If you get the urge to sell pharmaceuticals from the wiki, I recommend you resist. ;] 19:58
soh_cah_toa haha 19:59
rblackwe I need pharmaceuticals to keep happy til parrot is fully flying. 20:06
soh_cah_toa aww...parrot doesn't make you parrot? 20:10
*happy
rblackwe soh_cah_toa: its existance makes me very happy. The fact it is not everywhere makes me sad.
I organized 20:11
Parrot Virtual Machine Workshop 2009
at YAPC::NA|10
I loves me some parrot 20:12
just don't get to play much with it.
20:12 pjcj joined
PerlJam rblackwe: you just need to find some excuse for using it at work :) 20:12
rblackwe true 20:13
That is what we need.
Parrot on a wearable defibrillator.
soh_cah_toa ha
PerlJam rblackwe: Sure, then we start in on the dead parrot jokes for *real* 20:14
20:14 Eduardow left
rblackwe hah 20:14
At texas linux fest 20:15
www.aristanetworks.com/
20:16 dodathome left
rblackwe was there showing off there switch 20:16
They have implimented the cisco commands in python running on linux
Made me think mmmmmm perl 6 grammar for cisoco command set ....
If people were imprsed with "grep" what though I don't think they could handle that. 20:17
dalek tracwiki: v20 | soh_cah_toa++ | ParrotGSoC2011Students 20:19
tracwiki: trac.parrot.org/parrot/wiki/ParrotG...ction=diff
rblackwe BTW: we are planning Pittsburgh Perl Workshop 20:20
I would love me some parrot folks in the house.
whiteknight what are the dates? I doubt I can attend, but I never rule it out 20:23
20:23 Eduardow joined
rblackwe Oct 8-9 at CMU 20:23
bubaflub rblackwe: my employer is a sponsor of PPW, i might be there 20:24
rblackwe and no whiteknight you don't get the sheets off my bed this time
bubaflub: who is that?
bubaflub rblackwe: Grant Street Group
rblackwe ah indeed
great sponsor
bubaflub rblackwe: they take perl very seriously, i'm happy i work there now
PerlJam bubaflub: I've seen them at YAPC and such, but I really have no idea what GSG does with perl. 20:26
whiteknight rblackwe: wouldn't have been a problem if I had sheets of my own to use
rblackwe whiteknight: Luckily I had a spare. I was happy to enable sleep.
bubaflub PerlJam: websites that host cities / counties taxes, and separate platforms to host auctions for all kinds of things 20:27
also, we're hiring :-) 20:29
20:31 whiteknight left
cotto_work dukeleto: ping 21:04
jnthn_ Finally, I managed to golf an example of the IMCC bug I'm blocking on. 21:07
gist.github.com/906525
cotto_work prepares for ouch
jnthn_ foo and bar end up getting allocated the same register, despite being lexicals.
(the output is "oh no", should be a null PMC access) 21:08
Start removing things or even change register numbers around a bit, and it starts working :/ 21:09
cotto_work Can you do it in pasm with explicit register numbers? 21:11
jnthn_ cotto_work: I golfed this from generated code 21:13
cotto_work: as in, generated by PCT
I doubt it'd be a trivial change to make it use explicit register numbers just for this case. 21:14
Well, maybe it's not so bad. But still...better to fix the issue if possible.
Especially since we have it down to 17 lines of PIR with no dependencies. 21:15
cotto_work jnthn_: I'm not saying you should work around by using pasm, just asking if a smaller test case is possible using that. Still, it's a very good test case as is. 21:16
jnthn++
jnthn_ cotto_work: Oh, I see 21:17
cotto_work: I think the bug would disappear then
cotto_work: As in, I think it's the register allocator that's somehow doing this wrong.
21:17 ambs left
jnthn_ It seems to do a bunch of work and then throw most of it away and just use the vanilla allocator... 21:17
I've seen the outcome of the allocation and it's post-allocaiton that it's setting the same register number into the LexInfo for different symbols. 21:19
21:28 bluescreen left
bacek ~~ 21:32
Good morning, humans
21:33 theory left
cotto_work good morning, bacek 21:35
bacek aloha, cotto
cotto_work jnthn_ has an interesting imcc bug with the imcc register allocator and lexicals: gist.github.com/906525 21:36
jnthn_ I may also have a completely hacky patch 21:37
bacek cotto_work, oookey. RegAlloc is broken in imcc
21:39 mj41 left
jnthn_ It appears to do work and throw it away again. :S 21:39
Here's what I can figure so far. It looks like .lex 'foo', $P0 isn't considered an instruction, but just saying "this lexical goes in this register". If that's the only mention of $P0, then there's no "first instruction". It builds a du-chain, then throws away $P0 from the "needs allocation" list because it confuses it with an unused register due to optimization. 21:41
This patch: gist.github.com/906599 21:42
Will make the issue "go away" 21:43
But is potentially sub-optimal and hacky at best, and may result in an infinite loop in the register allocator at the worst.
It probably explains the issue enough for somebody who knows this area a bit better to make a better patch though.
bacek seen plobsing 21:44
aloha plobsing was last seen in #perl6 1 days 20 hours ago joining the channel.
jnthn_ :)
cotto_work bacek: I agree
bacek bad luck... I have no idea about IMCC guts.
cotto_work In the general case I don't think that's bad luck. 21:45
In this case it is though.
jnthn_ The only dangerous part of the patch really is that it might make the quicksort unstable. That is probably easy to deal with. 21:46
But I'm too tired now to do so.
cotto_work jnthn_: thanks 21:48
jnthn_ cotto_work: trac.parrot.org/parrot/ticket/2087 21:52
All the info is in there.
cotto_work great
jnthn++
jnthn_ This is a (hard) blocker. I'd hoped to get a bunch of NQP stuff done tonight before I ran into this. :(
dalek TT #2087 created by jonathan++: Register allocator and lexicals bug
TT #2087: trac.parrot.org/parrot/ticket/2087
cotto_work jnthn_: does your imcc patch at least let you get back to nqp until we find a proper fix? 21:53
jnthn_ cotto_work: Yes, if applied it seems to deal with the issue. 21:54
cotto_work: It'd be good to get a second opinion (though a less tired me would do ;)) on the patch from somebody who vaguely groks what it's doing though. 21:55
Or at best, understands really well what it's doing :)
cotto_work ok. I'll make it a priority to either grok the situation myself or find someone who does. 21:56
jnthn_ OK, thanks.
cotto_work aloha: clock?
aloha cotto_work: LAX: Wed, 14:56 PDT / CHI: Wed, 16:56 CDT / NYC: Wed, 17:56 EDT / UTC: Wed, 21:56 UTC / LON: Wed, 22:56 BST / BER: Wed, 23:56 CEST / TOK: Thu, 06:56 JST / SYD: Thu, 07:56 EST
21:57 cosimo joined
jnthn_ Guess I should sleep. Night 21:59
cotto_work jnthn_: 'night
msg plobsing Can you take a look at tt #2087 (imcc register allocator bug)? 22:00
aloha OK. I'll deliver the message.
22:24 cosimo left 22:31 particle joined 22:34 particle1 left
ttbot Parrot dc1985e5 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/63831 22:53
22:55 kid51 joined 23:10 theory joined 23:18 jrtayloriv joined
darbelo ~~ 23:20
sorear hello darbelo 23:21
darbelo Hi. 23:22
23:37 kid51 left
bacek_at_work ~~ 23:46
23:48 ligne joined
dukeleto ligne: howdy 23:48
~~
ligne hey! 23:49
23:55 kid51 joined 23:56 darbelo left
bacek_at_work ~~ 23:58
cotto_work As a general principle, I'd encourage mentors to leave comments on Melange in addition to voting.

Powered by Cro and the Raku® Programming Language.

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

Thank you!