Camelia, the Perl 6 bug

IRC log for #parrot, 2009-05-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:25 bobke joined #parrot
00:52 leto_ joined #parrot
01:08 tetragon joined #parrot
01:10 cotto ooh shiny
01:16 rdice joined #parrot
01:17 Whiteknight bacek++
01:24 davidfetter ?
01:25 * davidfetter scrolls up
01:25 davidfetter oh, cool :)
01:27 eternaleye joined #parrot
01:38 cotto bacek++
02:11 leto_ joined #parrot
02:12 cotto msg bacek what are your plans for having the pmc compiler store persistent information (i.e. for attr inheritance)
02:12 purl Message for bacek stored.
02:13 kid51 joined #parrot
02:13 cotto kid51, ping
02:14 kid51 cotto pong
02:14 cotto Could you take a look at the tests in the pmc_pct branch (compilers/pmc) and give me a clue about how to make the work with specifying the parrot binary's absolute path?
02:15 cotto s/absolute/relative/
02:15 kid51 I'll try ... but I've never poked around in that area before.
02:15 kid51 Is there a particular ticket this pertains to?
02:16 cotto nope.
02:16 cotto If you don't feel particularly qualified, don't bother.  I just thought you might know where to go from other test-related work.
02:18 kid51 BTW, is Smolder down again?
02:18 kid51 I started a run in a screen session about 5 hours ago and just checked the result now:
02:18 kid51 Could not upload report to Smolder at http://smolder.plusthree.com
02:18 kid51 HTTP CODE: 500 (read failed: Connection reset by peer)
02:18 kid51 make: *** [smolder_test] Error 104
02:19 kid51 ... which is about the 4th time this week.
02:19 cotto wtf?
02:20 cotto That's not good for such an important part of our testing infrastructure.
02:20 kid51 And the Smolder home page is not coming up.
02:20 kid51 Smolder was down all last weekend.
02:22 kid51 What is focus of pmc_pct branch?
02:22 kid51 Should I add any options to Configure.pl?  (I usually don't on Linux)
02:23 cotto to make a pct-based PMC compiler to replace the perl-based code we have now
02:23 cotto no special configure options
02:24 kid51 And are you concerned with 'make test' in general or some specific subset?
02:25 cotto make test in general
02:25 cotto (although there are only 6 test files)
02:32 bacek joined #parrot
02:38 bacek hi again
02:38 purl oh, you're back!
02:39 bacek cotto: around?
02:44 bacek purl: msg cotto I have no ideas about storing persistent info. But current PMC implementation of attributes volatiles encapsulation...
02:44 purl Message for cotto stored.
02:46 kid51 msg cotto Just ran 'make coretest' in pmc_pct branch.  All tests passed.  So where is the problem?
02:46 purl Message for cotto stored.
02:48 janus joined #parrot
02:49 bacek kid51: "make coretest" in pmc_pct probably doesn't test "compilers/pmc".
02:50 kid51 Yes, I just spotted that.
02:50 kid51 compilers/pmc/ doesn't exist in trunk.
02:51 bacek kid51: of cause :)
02:55 kid51 Here is a guess.
02:55 kid51 In trunk, we have a target 'make nqp_test', which runs tests found in compilers/nqp/t/*.t.
02:56 kid51 i.e., same number of directories down from top-level as compilers/pmc/t/.
02:56 kid51 Opening up the very first file in that t/ dir, 01-literals.t, I see:
02:56 kid51 #!./parrot nqp.pbc
02:56 kid51 Would there be anything equivalent for your goal?
02:57 bacek kid51: yes.
02:58 bacek But there is semi-hardcoded paths in test files.
02:59 kid51 But is that the *only* problem.  When I call 'prove compilers/pmc/t/*.t', *all* tests in that dir fail.
02:59 kid51 with:    Non-zero exit status: 13
02:59 kid51 Parse errors: No plan found in TAP output
03:00 bacek try "cd compilers/pmc; make test"
03:01 kid51 okay, tests are running.
03:03 kid51 Well, I have paid little attention to testing of PIR, so I don't have any quick answers.  Sorry
03:04 kid51 Could any of those t/*.t files be stripped down such that any test passes?
03:04 cotto bacek, back
03:05 bacek kid51: I didn't understand last question... :/
03:06 kid51 If the problem is a semi-hardcoded path in a test file, could you strip out all the tests from a particular file except one that does not include such a path?
03:08 bacek hmm... We can probably pass "path_prefix" to those tests.
03:08 leto_ joined #parrot
03:08 bacek cotto: any suggestions?
03:08 purl any suggestions are welcome.  (including ripping it out entirely :))
03:10 kid51 i.e., Could we place a test file in that directory that did nothing but 'say 'Hello world'' in PIR?  What would we have to do to get that to run?
03:10 bacek wow. Useful bot :)
03:11 bacek kid51: hm. Just run them. Using "prove" or "parrot"
03:11 bacek you can run "prove t/01-parse.t" within compilers/pmc.
03:12 kid51 But what cotto was asking me about (I think) was how to get them to run from top-level directory.
03:15 cotto I'm trying to make the tests work from either svn root or compilers/pmc, or at make them work from compilers/pmc without specifying the path to parrot.
03:16 bacek cotto: there is #!../../parrot in tests...
03:16 cotto although the nqp tests don't work from parrot's root, so that may not be reasonable or necessary
03:16 bacek I've made simple '_get_path_prefix' but it doesn't help.
03:16 bacek easiest solution: pmc_test:\n\t$(MAKE) -C compilers/pmc test
03:17 bacek (In to-level Makefile)
03:20 bacek cotto: we need "failing" tests... Like for adding second class_init, etc
03:22 cotto It'd be smart to make test_parse_one return a value.
03:29 cotto I think I'll leave the tests alone for now wrt the path to parrot.
03:30 cotto bacek, would it be a good time for me to make test_parse_one return a value and refactor the tests to use it?
03:30 bacek cotto: agreed.
03:31 cotto I'll start then.
03:35 cotto Does the current code care about multiple class_inits?
03:35 cotto *init_class
03:35 cotto nm.  I give up
03:35 cotto ;)
03:36 starscream joined #parrot
03:37 bacek cotto: I slightly refactored it :)
03:40 cotto bacek, should I not be working on the tests then?
03:40 cotto nm.  different topic
03:40 bacek :)
03:41 bacek It was about "class_init".
03:41 cotto yup
03:42 dalek parrot: r38434 | bacek++ | branches/pmc_pct/compilers/pmc (4 files):
03:42 dalek parrot: Add (totally incomplete) class_init generating
03:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38434/
03:44 japhb joined #parrot
03:55 bacek No single pmc in parrot marked with "is_ro", "has_ro" or "is_shared"...
03:57 cotto are you going to be at the next #ps?
03:58 starscream joined #parrot
04:00 bacek cotto: no... It's at 4:30. AM.
04:00 davidfetter hrm
04:00 cotto ok.  I'll mention that (and method attributes) then.
04:01 davidfetter should #ps's move around a bit?/
04:01 cotto davidfetter, why?
04:01 bacek davidfetter: then it will be inconvenient for all other people. Australia is far-far-away from other world :)
04:01 davidfetter spreading the inconvenience a bit
04:01 dalek parrot: r38435 | cotto++ | branches/pmc_pct/compilers/pmc/t (3 files):
04:01 dalek parrot: [t] refactor test_parse_one to return a value rather than running ok() directly
04:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38435/
04:02 davidfetter where is everybody?
04:02 purl rumour has it everybody is depraved
04:03 davidfetter http://www.timeanddate.com/worldclock/meeting.html <-- handy tool
04:03 cotto eu and us for the most part, although there are people from all over
04:03 bacek https://www.ohloh.net/p/parrot/map
04:04 cotto including New Caledonia
04:04 cotto (hi GeJ)
04:05 cotto bacek, you're in Australia?  I thought you were in Russia.
04:05 bacek I was in Russia. 3+ year ago
04:06 davidfetter hrm
04:06 davidfetter i don't see new caledonia
04:06 cotto The map doesn't include everyone who contributes.  You may need to register.
04:09 davidfetter joined #parrot
04:10 davidfetter it's probably not good that control-a and control-q are so close together :P
04:11 mikehh_ joined #parrot
04:14 cotto I really should know better than to drink and watch Whose Line clips.
04:15 * bacek wishes to have inheritance and multi-methods in NQP...
04:16 cotto see also: Pony
04:17 bacek :)
04:20 bacek ok. Time to brake stuff. I'm going to "reimplement" src/emitter/pmc in NQP.
04:21 cotto (breaking stuff)++
04:31 bacek cotto: if you'll switch "test_parse_one" from returning string to returning parse tree it will be helpful.
04:32 bacek "check_one_file" in 05-header and 06-body are almost identical...
04:34 cotto bacek, I'll move it into t/common.t
04:35 bacek cotto: agreed.
04:35 cotto are you thinking that test_parse_one should return either a parse tree or an exception?
04:38 Andy joined #parrot
04:45 cotto What does the 'compile' method return?
04:49 rakudohudson joined #parrot
04:52 * Infinoid (probably) breaks dalek again
04:52 dalek joined #parrot
04:54 Infinoid If that worked, dalek should now automatically be tracking all of the github projects mentioned on the Languages page on the wiki
04:54 Infinoid it'll poll that page once every 4 hours to look for new stuff.  Won't detect deletions tho
04:55 eternaleye Infinoid++
04:55 cotto Infinoid++
04:56 leto_ joined #parrot
04:56 Infinoid Now I just need someone to commit something and test it for me. :)
04:57 Infinoid Preferably rakudo; that's a little hackier than the rest because it's supposed to output to 2 channels
04:59 Infinoid http://github.com/Infinoid/dalek-plugin​s/blob/master/modules/local/autofeed.pm
04:59 Infinoid next up, googlecode, then trac, then bitbucket
05:15 bacek cotto: "compile" returns result of last step. For "parse" it will be parse tree. For "past" - PAST
05:17 dalek parrot: r38436 | cotto++ | branches/pmc_pct/compilers/pmc/t (3 files):
05:17 cotto bacek, feel free to rename the new function in this upcoming commit, then.
05:17 dalek parrot: [t] factor out some common code between a couple tests
05:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38436/
05:17 dalek parrot: r38437 | bacek++ | branches/pmc_pct (4 files):
05:17 dalek parrot: Extract C emitter from PMC emitter
05:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38437/
05:18 bacek cotto: Who cares about names? :)
05:19 cotto people who try to figure out what the code is doing
05:21 dalek parrot: r38438 | bacek++ | branches/pmc_pct/compilers/pmc (4 files):
05:21 dalek parrot: Start moving stuff from emitter/pmc.pir into emitter/pmc.pm
05:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38438/
05:21 bacek cotto: English is my forth language :) I'm not very good at naming.
05:22 cotto That's fine.  It's easy to rename variables.
05:27 frodwith joined #parrot
05:38 bacek cotto: can we temporary disable 02-parse-all? It takes too long to process all tests...
05:39 cotto heh.  feel free to do that
05:39 dalek parrot: r38439 | bacek++ | branches/pmc_pct/compilers/pmc/src/emitter (2 files):
05:39 dalek parrot: Reimplement generate_h_file in NQP
05:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38439/
05:59 bacek here we go
06:01 dalek parrot: r38440 | bacek++ | branches/pmc_pct/compilers/pmc/src (4 files):
06:01 dalek parrot: Move emitting C code to pmc.pm
06:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38440/
06:01 dalek parrot: r38441 | bacek++ | branches/pmc_pct/compilers/pmc/src/emitter/pmc.pm:
06:01 dalek parrot: Resurrect TODO comment
06:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38441/
06:04 cotto bacek, where can I jump in?
06:05 bacek cotto: now
06:05 cotto what needs implementing that you don't feel like working on?
06:06 bacek It's probably good idea to start stealing code from lib/Parrot/Pmc2c
06:06 bacek cotto: check my last commit :)
06:06 cotto ah.  vtables
06:06 bacek indeed.
06:07 bacek I've got PMC::VtableInfo::vtables_list and vtable_hash.
06:07 cotto it'll be nicer working in nqp than in raw pir.  bacek++ for that
06:07 bacek It was main idea :)
06:08 bacek We can extract few helper functions for generating signatures. Like mk_full_name, etc.
06:08 bacek Anyway. Movies time. Kids waiting.
06:08 bacek afk # for couple of hours
06:14 dalek parrot: r38442 | cotto++ | branches/pmc_pct/compilers/​pmc/t/02-parse-all-pmcs.t:
06:14 dalek parrot: [t] speed up the test by only testing the 10 smallest PMCs
06:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38442/
06:27 cotto Hmmm.  I wonder what'd happen if we called class_init lazily
06:32 leto_ joined #parrot
06:54 japhb joined #parrot
07:00 dalek parrot: r38443 | chromatic++ | trunk/docs/book/ch01_introduction.pod:
07:00 dalek parrot: [book] Edited chapter 1 for clarity, flow, and style.
07:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38443/
08:12 cotto msg bacek the PMC compiler will need to have some kind of persistence mechanism before class_init can be implemented.  We could put it off by implementing chromatic's suggestion in TT #528, but we'll still eventually need it.
08:12 purl Message for bacek stored.
08:15 cotto msg bacek compilers/json looks like it might work.
08:15 purl Message for bacek stored.
09:04 bacek joined #parrot
09:06 iblechbot joined #parrot
09:32 bacek hi again
09:32 purl oh, you're back!
09:34 bacek cotto: ping
09:46 cotto bacek, pong
09:46 bacek cotto: I'm not yet convinced to any approach for class_init...
09:47 bacek chromatic's idea is very good, but it's slightly out of scope for pmc_pct branch.
09:47 cotto no, but any approach will need persistence (or a bunch of repeated parsing)
09:47 cotto completely agree
09:48 cotto I'm just thinking that if his idea can be implemented, the PMC compiler won't need to persist as much information.
09:48 bacek AFAIU chromatic's suggestion we will not require repeated parsing.
09:48 cotto no
09:48 bacek If we'll factor out Parrot_Foo_get_vtable function we can simplify things a lot
09:49 cotto It's not hard to get a vtable.  It's just interp->vtables[type]
09:50 bacek Like Parrot_Derived_get_vtable() { vtable * res = Parrot_Base_get_vtable(); res[1] = Parrot_Derived_blah; return res; }
09:50 bacek (hard to get) But we have to build interp->vtables first :)
09:51 cotto default is a special case, then everything copies that and adds its own stuff
09:51 bacek Yes. Default is exception.
09:51 cotto istr that it's that way in the pmc2c code
09:51 bacek But everyone else will call Parrot_default_get_vtable, fill it with own methods and return
09:52 bacek no. pmc2c builds whole vtable
09:52 bacek so, it require to export all vtable methods
09:52 cotto or use its first parent's vtable, fill in other parents' stuff, then fill in its own
09:53 bacek With this approach we have to export only 2 methods for each pmc: get_vtable and class_init
09:53 bacek cotto: exactly
09:54 cotto I'm certain that I'm missing something, but this seems like it'll cut out the need for persistent information in the PMC compiler.
09:54 bacek It will cut all requirements for persistence
09:55 cotto It sounds much more elegant.
09:55 bacek agreed :)
09:56 bacek purl: seen chromatic
09:56 purl chromatic was last seen on #parrot 2 days, 9 hours, 27 minutes and 29 seconds ago, saying: I thought he was assistant TO the project manager.  [Apr 30 00:26:16 2009]
09:58 cotto working with generated code can be confusing
10:02 bacek cotto: very
10:02 cotto bacek, I think we'll still need persistent information to deal with the case when a PMC has two immediate parents.
10:03 cotto we can copy the vtable from the first parent directly, but we have to selectively update it with entries from the second.
10:04 cotto (this is something the current code supports, as long as only one parent has ATTRs)
10:04 cognominal joined #parrot
10:06 cotto I guess we could check which function pointers differ between the second parent (P2) and P2's parent, but that rubs me the wrong way.
10:06 bacek one note: there is no CorePMC with multiple parents
10:07 cotto right.  I know partcl has a couple and Lua may also.
10:08 cotto we have to either support it or get a declaration from allison that such behavior is deprecated.
10:08 cotto and I think partcl's taken enough beating
10:10 cotto I guess pointer comparisons would be ok, since it's such a rare use case.  We'll need to be sure to test whatever solution we use, though.
10:12 bacek agreed...
10:12 purl Just kidding!
10:13 cotto < purl-- >
10:13 bacek Looks like current Pmc2c doesn't handle conflicts between parent's vtables
10:13 cotto orly?
10:13 purl YA RLY.
10:13 cotto purl++
10:13 bacek first encounter wins
10:13 cotto That's bad.
10:13 cotto It shouldn't even allow multiple inheritance in that case.
10:14 * cotto goes off to verify
10:16 cotto oh.  conflicts.
10:16 purl conflicts are conflicts
10:16 cotto That's the behavior I'd expect.
10:18 bacek it is... And it's bad...
10:21 bacek ok, current behaviour can be implemented with little help of functional approach.
10:21 bacek get_vtable(VTABLE * parent) ftw
10:21 cotto um... return parent; ?
10:23 bacek Derived_class_init() { VTABLE * t = Derived_get_vtable(Parent2_get_vtable(Pa​rent1_get_vtable(Default_get_vtable())))
10:23 bacek :)
10:24 cotto I'm getting lisp flashbacks.
10:25 cotto oic
10:25 cotto v shiny
10:25 bacek oic?
10:25 purl oic is Oh, \ see or Office of the Independent Counsel or yet another example of kickable k3wlt01k
10:25 bacek ah, ok
10:26 cotto So Foo_get_vtable takes a VTABLE* and adds its own function pointers.
10:26 bacek exactly
10:26 bacek It's probably better to name it "build_vtable"
10:27 cotto I'd call it Foo_update_vtable, but I'm liking the idea.
10:27 rdice joined #parrot
10:27 bacek * :)
10:27 cotto It'd have to be PARROT_EXPORT for dynpmcs, but one symbol per PMC is better than one per VTABLE function.
10:28 cotto s/EXPORT/EXPORT,/
10:28 bacek we'll need 2.
10:29 cotto O(number of PMCs) vs O(number of PMC VTABLE functions)
10:29 bacek :)
10:34 bacek ok. we'll need 3 functions. Exportable get_vtable and class_init (or init_mro). Non exportable build_vtable(VTABLE*parent) which will be called only from get_vtable
10:44 * bacek updated TT#518 with suggestions.
10:45 bacek bacek-- # forgot to mention cotto++ in ticket comment...
10:45 bacek afk #kids time
10:48 cotto have fun
10:56 dalek parrot: r38444 | cotto++ | branches/tt528_vtinit:
10:56 dalek parrot: creating a branch to address TT #528 and simplify PMC VTABLE initialization
10:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38444/
10:56 cotto yay.  my first branch
11:01 rdice joined #parrot
11:03 jan joined #parrot
11:10 cotto rdice, ping
11:38 Ron joined #parrot
11:40 dalek parrot: r38445 | cotto++ | branches/tt528_vtinit/lib/P​arrot/Pmc2c/PMCEmitter.pm:
11:40 dalek parrot: [pmc2c] generate an (unused) update_vtable function for each PMC
11:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38445/
11:42 cotto sleep
11:59 Whiteknight joined #parrot
12:16 kid51 joined #parrot
12:31 bsdz joined #parrot
12:40 HG` joined #parrot
12:48 dalek parrot: r38446 | jkeenan++ | trunk (2 files):
12:48 dalek parrot: Corrected the faulty logic described in
12:48 dalek parrot: https://trac.parrot.org/parrot/ticket/586.
12:48 purl i heard https://trac.parrot.org/parrot/ticket/586 was the reason for kid51's Win32 question.
12:48 dalek parrot: Replaced $_ with named lexicals in many locations.
12:48 dalek parrot: Removed pirc and pirc.exe from MANIFEST.generated.
12:48 dalek parrot: Removed one comment which referred to a ticket which was earlier rejected.
12:48 dalek parrot: Moved the POD to the end of the file so that you don't have to scroll down
12:48 dalek parrot: 5 screens to get to the code.
12:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38446/
13:25 Casan joined #parrot
13:26 jhorwitz joined #parrot
13:46 mikehh Coke: you available
13:48 Coke nope.
13:49 mikehh Is that - I am busy on something else or what?
14:02 fperrad joined #parrot
14:06 dalek parrot: r38447 | fperrad++ | trunk/config/gen/makefiles/pirc.in:
14:06 dalek parrot: [pirc] remove some useless variables in Makefile
14:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38447/
14:30 dalek joined #parrot
14:45 whoppix joined #parrot
14:56 fperrad left #parrot
16:11 mikehh I was a little worried by the sentence starting -> Its architecture is fundamentally different than existing virtual machines
16:12 mikehh The "than" does'nt read right to me
16:13 mikehh doesn;
16:13 mikehh doesn't - ARGH
16:17 kid51 joined #parrot
16:22 pmichaud s/than/from/
16:23 mikehh that's what I thought
16:23 pmichaud also, "existing virtual machines" reads too temporally, since Parrot itself is an existing virtual machine, and there might be other vms that now have an architecture closer to parrot.
16:30 Theory joined #parrot
16:54 tetragon joined #parrot
16:57 Infinoid Coke: Do you mind if I use you as a guinea pig for a dalek feature I'm hacking on?
17:03 mikehh post configure tests fail at r38448
17:04 mikehh Failed 4/37 test programs. 6/996 subtests failed.
17:23 Theory joined #parrot
17:35 mikehh smolder don't seem to be talking to me again
17:59 Ron joined #parrot
18:00 kid51 mikehh:  Could not reproduce your failure.
18:04 mikehh kid51: which one?
18:09 dalek rakudo: cacc976 | pmichaud++ | src/setting/Any-list.pm:
18:09 dalek rakudo: Rewrite Any.join() to avoid the "Cannot reduce() empty list" error.
18:09 dalek rakudo: Might as well use the Parrot 'join' opcode since we have one.
18:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​acc9767a525299e075c5ff2246d4451c64c0d48
18:37 dalek rakudo: 06f0ae8 | pmichaud++ | :
18:37 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
18:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​6f0ae8b379bb6485f75c538e12c01b6de1cc9df
18:37 dalek rakudo: d4a0b3b | pmichaud++ | docs/spectest-progress.csv:
18:37 dalek rakudo: spectest-progress.csv update: 378 files, 10991 passing, 0 failing
18:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​4a0b3b8b5d3b9fb781ccdd154169d58472fbc06
19:27 jonathan Awww...nearly 11,000.
19:32 Theory joined #parrot
19:59 leto_ joined #parrot
20:28 amoc joined #parrot
20:51 Whiteknight joined #parrot
20:52 HG` joined #parrot
21:04 tetragon joined #parrot
21:09 dukeleto joined #parrot
21:12 cotto msg bacek The PMC compiler will still need to persist information about ATTRs.
21:12 purl Message for bacek stored.
21:20 PacoLinux joined #parrot
21:25 cotto bacek, this is interesting.  Apparently the default VTABLE is never initialized.
21:28 cotto nor is it even a usable PMC
21:29 cotto (which makes sense)
21:32 dduncan joined #parrot
21:32 Whiteknight that is pretty interesting actually
21:42 cotto default is a very special case
21:47 rhall joined #parrot
21:51 rhall left #parrot
21:53 s1n joined #parrot
22:17 ingy joined #parrot
22:21 MariachiElf joined #parrot
22:51 bacek good morning
22:51 MariachiElf good afternoon :)
22:52 cotto hi
22:52 cotto seen darbelo
22:52 purl darbelo was last seen on #parrot 2 days, 1 hours, 23 minutes and 24 seconds ago, saying: I'm not PAST, the parser errors out on me ;)  [Apr 30 21:26:59 2009]
22:54 bacek cotto: (default) We can still provide Default.build_vtable. Just don't register it in interp->vtables
22:56 bacek cotto: (ATTR) Attributes are not perfect in parrot. Imagine pmclass B1 { ATTR INTVAL foo }; pmclass B2 { ATTR STRING * foo }; pmclass D extends B1 extends  B2 { ATTR NUMVAL foo };
22:57 cotto Currently, the pmc2c code catches that ATTR situation and refuses to build.
22:58 cotto It's not the way we want to do things long-term, but allison said it's ok for now.
22:59 bacek Probably it's time to reinvent C++ wheel with virtual inheritance...
23:01 MariachiElf Which reminds me of the xTalk project I'm working on
23:01 bacek xTalk?
23:01 MariachiElf One of the things that's always annoyed me about the xTalk's I've used is that "add-on" functions don't look like native functions
23:02 MariachiElf bacek: Have you ever heard of HyperCard, SuperCard, MetaCard, or Revolution?  Maybe seen some AppleScript?
23:03 bacek I heard about it. Nothing apart general concepts
23:03 MariachiElf It's a very "English like" scripting language which I really enjoyed for developing GUI apps
23:04 bacek oh. Sounds bad...
23:04 MariachiElf Instead of something like x.label = "SomeLabel";
23:04 MariachiElf You'd use: set the label of field x to "SomeLabel"
23:05 bacek cotto: we can use Hash.freeze/thaw for persistence.
23:05 bacek MariachiElf: It's weird. Too noisy.
23:05 MariachiElf After years of C++ and Perl I thought I'd feel really constrained using it, however I was pleasantly surprised to find myself more productive
23:06 MariachiElf bacek: However, the target audience isn't "real developers" (though I'd argue real developers could learn a lot from using it) but more the "average person"
23:07 cotto bacek, good idea.  It'll be lower-overhead than json, although more opaque too.
23:07 MariachiElf It's extremely popular amongst the teachers and graphic artists crowd -- think of it as a better version of what Visual Basic wanted to be
23:07 bacek MariachiElf: every language has own niche. Even PHP :)
23:08 bacek cotto: we can even freeze whole PMC::Class.
23:09 MariachiElf bacek: Check out: http://en.wikipedia.org/wiki/XTalk for a super brief 'what does it look like'
23:10 MariachiElf But back to the problem I'm hoping to solve is the extensible part of the language
23:11 MariachiElf For instance, let's say there's a builtin command "move" that will move an object on screen from one position to another
23:11 MariachiElf It'd probably be used: move button "x" to 100,300 in 5 seconds
23:12 MariachiElf You can imagine that will use up "5 seconds" to reposition button "x" to the new location
23:13 bacek no. I think it will kill kittens and eat my lunch! :)
23:13 MariachiElf Now if you write your own "move" command that works differently (for instance, instead of a simple straight line movement at a constant speed it uses acceleration at each end of the movement)
23:14 MariachiElf You can't use the cool syntax
23:15 MariachiElf You need to do something like: move(x, (100,300), 5, useAccel= "yes")
23:16 bacek Use Perl6 for implementing xTalk. Then everything will be extremely cool :)
23:16 MariachiElf bacek: That's actually what I was thinking
23:16 MariachiElf I was trying to decide if xTalk on top of Perl6 would be better than xTalk on top of Parrot
23:17 MariachiElf The part I'm not sure how to cope with at the moment is the introduction of my new "move" command and the new syntax
23:19 MariachiElf How do I add a command that replaces the existing behavior, but still have a way to access the native command if that's what I want
23:19 bacek MariachiElf: (In bright future) Perl6 allows dynamic syntax constructions. Unfortunately only STD.pm supports it ATM.
23:19 MariachiElf I'd love to just leave this kind of thing up to the experts, but unfortunately I don't think the experts would take much interest in the xTalk family
23:20 bacek And you don't need to replace existing behaviour. MMD ftw
23:20 MariachiElf MMD ftw?
23:20 bacek MultiMethodDispatch
23:22 bacek class Accel{}; multi sub move(Object $o, Point $p, Time $i) {...}; multi sub move(Object $o, Point $p, Time $i, Accel $a) { ... }
23:22 * MariachiElf starts reading "What the heck is MMD"
23:22 bacek Then parser will just emit "move(...)" and MMD will dispatch it to proper function
23:22 MariachiElf Oh signature based
23:22 bacek yes
23:23 MariachiElf But that's only if the signatures can be identified
23:23 MariachiElf The example I gave happens to have different signatures
23:23 bacek You are really doesn't want signature clashing.
23:24 MariachiElf But depending on whether or not the optional parameter useAccel is provided you can't tell the difference between the signatures
23:24 Theory joined #parrot
23:24 MariachiElf Well it's useful in this language to rewrite existing "verbs"
23:24 bacek Without "useAccell" it will use "old" version
23:25 MariachiElf There's use cases for replacing the "native" functionality
23:26 MariachiElf I just don't want to lose all access to it...
23:26 MariachiElf For instance perhaps an optional qualifier would force the command to come from a particular namespace?
23:27 MariachiElf native.move button x to 100, 300
23:27 bacek How you can distinguish calling "built-in" from recursive calling to self? (BTW, there is no "built-ins" in Perl6. All functions are first-class citizens)
23:27 bacek rakudo: say "hi"
23:27 bacek no evalbot?
23:28 MariachiElf bacek: Well in the xTalks I've used you have a "start using" clause which sucks in a namespace and your call goes to which was loaded last
23:29 bacek anyway. package Core { sub foo() is export {} }; package Plugin { sub foo is export { Core::foo() } }
23:29 MariachiElf Yeah that's what I was thinking
23:30 MariachiElf Perl6 is pretty much exactly what I want... I just want to use a different parser
23:30 bacek join #perl6 at freenode and say "rakudo: say 'hi'" :)
23:30 bacek Parser isn't "built-in" in Perl6.
23:32 MariachiElf joined #parrot
23:33 * MariachiElf is feeling rather Pidgin incompetent atm
23:34 MariachiElf So what output am I looking at here
23:34 bacek use xchat-gnome
23:34 * MariachiElf is on Vista
23:34 bacek ouch....
23:34 purl ouch is http://www2.epscylonb.com/image001.gif
23:34 MariachiElf lol
23:35 MariachiElf I can't watch
23:35 bacek bad girl
23:35 MariachiElf Yes, that's worse than using Vista
23:35 bacek purl: bad girl
23:35 purl bacek: huh?
23:36 bacek Last time I used Vista 2 years ago. AFAIR it was much better than XP.
23:37 MariachiElf I'd rather be using KDE4, but anyway my kid's school tuition, health insurance, and my mortgage are based on my Windows experience - so Vista stays for now
23:38 MariachiElf I am hoping very much to get some kind of free and extensible xTalk implementation going though
23:39 MariachiElf The xTalks are about more than just the scripting language, there's a whole GUI metaphor that goes with it
23:40 MariachiElf It's a very high level abstraction great for doing cool GUI apps
23:40 Limbic_Region joined #parrot
23:41 MariachiElf Then you tie it into shared libraries to do any real computational work and expose those shared libraries as new commands in the language
23:56 dukeleto joined #parrot

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

Parrot | source cross referenced