Parrot 1.1.0 Released | parrot.org/ | 325 RTs left | Weekly Priority: Remove Deprecated Items
Set by moderator on 28 April 2009.
00:09 AndyA joined 00:25 bobke joined 00:52 leto_ joined 01:08 tetragon joined
cotto ooh shiny 01:10
01:16 rdice joined
Whiteknight bacek++ 01:17
davidfetter ? 01:24
davidfetter scrolls up 01:25
oh, cool :)
01:27 eternaleye joined
cotto bacek++ 01:38
02:11 leto_ joined
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
cotto kid51, ping 02:13
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?
s/absolute/relative/ 02:15
kid51 I'll try ... but I've never poked around in that area before.
Is there a particular ticket this pertains to?
cotto nope. 02:16
If you don't feel particularly qualified, don't bother. I just thought you might know where to go from other test-related work.
kid51 BTW, is Smolder down again? 02:18
I started a run in a screen session about 5 hours ago and just checked the result now:
Could not upload report to Smolder at smolder.plusthree.com
HTTP CODE: 500 (read failed: Connection reset by peer)
make: *** [smolder_test] Error 104
... which is about the 4th time this week. 02:19
cotto wtf?
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.
Smolder was down all last weekend.
What is focus of pmc_pct branch? 02:22
Should I add any options to Configure.pl? (I usually don't on Linux)
cotto to make a pct-based PMC compiler to replace the perl-based code we have now 02:23
no special configure options
kid51 And are you concerned with 'make test' in general or some specific subset? 02:24
cotto make test in general 02:25
(although there are only 6 test files)
02:32 bacek joined
bacek hi again 02:38
purl oh, you're back!
bacek cotto: around? 02:39
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.
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
bacek kid51: "make coretest" in pmc_pct probably doesn't test "compilers/pmc". 02:49
kid51 Yes, I just spotted that. 02:50
compilers/pmc/ doesn't exist in trunk.
bacek kid51: of cause :) 02:51
kid51 Here is a guess. 02:55
In trunk, we have a target 'make nqp_test', which runs tests found in compilers/nqp/t/*.t.
i.e., same number of directories down from top-level as compilers/pmc/t/. 02:56
Opening up the very first file in that t/ dir, 01-literals.t, I see:
#!./parrot nqp.pbc
Would there be anything equivalent for your goal?
bacek kid51: yes. 02:57
But there is semi-hardcoded paths in test files. 02:58
kid51 But is that the *only* problem. When I call 'prove compilers/pmc/t/*.t', *all* tests in that dir fail. 02:59
with: Non-zero exit status: 13
Parse errors: No plan found in TAP output
bacek try "cd compilers/pmc; make test" 03:00
kid51 okay, tests are running. 03:01
Well, I have paid little attention to testing of PIR, so I don't have any quick answers. Sorry 03:03
Could any of those t/*.t files be stripped down such that any test passes? 03:04
cotto bacek, back
bacek kid51: I didn't understand last question... :/ 03:05
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:06
bacek hmm... We can probably pass "path_prefix" to those tests. 03:08
03:08 leto_ joined
bacek cotto: any suggestions? 03:08
purl any suggestions are welcome. (including ripping it out entirely :))
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 :)
kid51: hm. Just run them. Using "prove" or "parrot" 03:11
you can run "prove t/01-parse.t" within compilers/pmc.
kid51 But what cotto was asking me about (I think) was how to get them to run from top-level directory. 03:12
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:15
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
bacek I've made simple '_get_path_prefix' but it doesn't help.
easiest solution: pmc_test:\\n\\t$(MAKE) -C compilers/pmc test
(In to-level Makefile) 03:17
cotto: we need "failing" tests... Like for adding second class_init, etc 03:20
cotto It'd be smart to make test_parse_one return a value. 03:22
I think I'll leave the tests alone for now wrt the path to parrot. 03:29
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.
cotto I'll start then. 03:31
Does the current code care about multiple class_inits? 03:35
*init_class
nm. I give up
;)
03:36 starscream joined
bacek cotto: I slightly refactored it :) 03:37
cotto bacek, should I not be working on the tests then? 03:40
nm. different topic
bacek :)
It was about "class_init". 03:41
cotto yup
dalek rrot: r38434 | bacek++ | branches/pmc_pct/compilers/pmc (4 files):
Add (totally incomplete) class_init generating
 03:42
03:44 japhb joined
bacek No single pmc in parrot marked with "is_ro", "has_ro" or "is_shared"... 03:55
cotto are you going to be at the next #ps? 03:57
03:58 starscream joined
bacek cotto: no... It's at 4:30. AM. 04:00
davidfetter hrm
cotto ok. I'll mention that (and method attributes) then.
davidfetter should #ps's move around a bit?/ 04:01
cotto davidfetter, why?
bacek davidfetter: then it will be inconvenient for all other people. Australia is far-far-away from other world :)
davidfetter spreading the inconvenience a bit
dalek rrot: r38435 | cotto++ | branches/pmc_pct/compilers/pmc/t (3 files):
[t] refactor test_parse_one to return a value rather than running ok() directly
davidfetter where is everybody? 04:02
purl rumour has it everybody is depraved
davidfetter 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
bacek www.ohloh.net/p/parrot/map
cotto including New Caledonia 04:04
(hi GeJ)
bacek, you're in Australia? I thought you were in Russia. 04:05
bacek I was in Russia. 3+ year ago
davidfetter hrm 04:06
i don't see new caledonia
cotto The map doesn't include everyone who contributes. You may need to register.
04:09 davidfetter joined
davidfetter it's probably not good that control-a and control-q are so close together :P 04:10
04:11 mikehh_ joined
cotto I really should know better than to drink and watch Whose Line clips. 04:14
bacek wishes to have inheritance and multi-methods in NQP... 04:15
cotto see also: Pony 04:16
bacek :) 04:17
ok. Time to brake stuff. I'm going to "reimplement" src/emitter/pmc in NQP. 04:20
cotto (breaking stuff)++ 04:21
bacek cotto: if you'll switch "test_parse_one" from returning string to returning parse tree it will be helpful. 04:31
"check_one_file" in 05-header and 06-body are almost identical... 04:32
cotto bacek, I'll move it into t/common.t 04:34
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
cotto What does the 'compile' method return? 04:45
04:49 rakudohudson joined
Infinoid (probably) breaks dalek again 04:52
04:52 dalek joined
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
it'll poll that page once every 4 hours to look for new stuff. Won't detect deletions tho
eternaleye Infinoid++ 04:55
cotto Infinoid++
04:56 leto_ joined
Infinoid Now I just need someone to commit something and test it for me. :) 04:56
Preferably rakudo; that's a little hackier than the rest because it's supposed to output to 2 channels 04:57
github.com/Infinoid/dalek-plugins/b...utofeed.pm 04:59
next up, googlecode, then trac, then bitbucket
bacek cotto: "compile" returns result of last step. For "parse" it will be parse tree. For "past" - PAST 05:15
dalek rrot: r38436 | cotto++ | branches/pmc_pct/compilers/pmc/t (3 files):
[t] factor out some common code between a couple tests
 05:17
cotto bacek, feel free to rename the new function in this upcoming commit, then.
rrot: r38437 | bacek++ | branches/pmc_pct (4 files):
Extract C emitter from PMC emitter
bacek cotto: Who cares about names? :) 05:18
cotto people who try to figure out what the code is doing 05:19
dalek rrot: r38438 | bacek++ | branches/pmc_pct/compilers/pmc (4 files):
Start moving stuff from emitter/pmc.pir into emitter/pmc.pm
 05:21
bacek cotto: English is my forth language :) I'm not very good at naming.
cotto That's fine. It's easy to rename variables. 05:22
05:27 frodwith joined
bacek cotto: can we temporary disable 02-parse-all? It takes too long to process all tests... 05:38
cotto heh. feel free to do that 05:39
dalek rrot: r38439 | bacek++ | branches/pmc_pct/compilers/pmc/src/emitter (2 files):
Reimplement generate_h_file in NQP
bacek here we go 05:59
dalek rrot: r38440 | bacek++ | branches/pmc_pct/compilers/pmc/src (4 files):
Move emitting C code to pmc.pm
 06:01
rrot: r38441 | bacek++ | branches/pmc_pct/compilers/pmc/src/emitter/pmc.pm:
Resurrect TODO comment
cotto bacek, where can I jump in? 06:04
bacek cotto: now 06:05
cotto what needs implementing that you don't feel like working on?
bacek It's probably good idea to start stealing code from lib/Parrot/Pmc2c 06:06
cotto: check my last commit :)
cotto ah. vtables
bacek indeed.
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
bacek It was main idea :)
We can extract few helper functions for generating signatures. Like mk_full_name, etc. 06:08
Anyway. Movies time. Kids waiting.
afk # for couple of hours
dalek rrot: r38442 | cotto++ | branches/pmc_pct/compilers/pmc/t/02-parse-all-pmcs.t:
[t] speed up the test by only testing the 10 smallest PMCs
 06:14
cotto Hmmm. I wonder what'd happen if we called class_init lazily 06:27
06:32 leto_ joined 06:54 japhb joined
dalek rrot: r38443 | chromatic++ | trunk/docs/book/ch01_introduction.pod:
[book] Edited chapter 1 for clarity, flow, and style.
 07:00
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.
cotto msg bacek compilers/json looks like it might work. 08:15
purl Message for bacek stored.
09:04 bacek joined 09:06 iblechbot joined
bacek hi again 09:32
purl oh, you're back!
bacek cotto: ping 09:34
cotto bacek, pong 09:46
bacek cotto: I'm not yet convinced to any approach for class_init...
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)
completely agree
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.
cotto no
bacek If we'll factor out Parrot_Foo_get_vtable function we can simplify things a lot
cotto It's not hard to get a vtable. It's just interp->vtables[type] 09:49
bacek Like Parrot_Derived_get_vtable() { vtable * res = Parrot_Base_get_vtable(); res[1] = Parrot_Derived_blah; return res; } 09:50
(hard to get) But we have to build interp->vtables first :)
cotto default is a special case, then everything copies that and adds its own stuff 09:51
bacek Yes. Default is exception.
cotto istr that it's that way in the pmc2c code
bacek But everyone else will call Parrot_default_get_vtable, fill it with own methods and return
no. pmc2c builds whole vtable 09:52
so, it require to export all vtable methods
cotto or use its first parent's vtable, fill in other parents' stuff, then fill in its own
bacek With this approach we have to export only 2 methods for each pmc: get_vtable and class_init 09:53
cotto: exactly
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
cotto It sounds much more elegant. 09:55
bacek agreed :)
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]
cotto working with generated code can be confusing 09:58
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.
we can copy the vtable from the first parent directly, but we have to selectively update it with entries from the second. 10:03
(this is something the current code supports, as long as only one parent has ATTRs) 10:04
10:04 cognominal joined
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
cotto right. I know partcl has a couple and Lua may also. 10:07
we have to either support it or get a declaration from allison that such behavior is deprecated. 10:08
and I think partcl's taken enough beating
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:10
bacek agreed... 10:12
purl Just kidding!
cotto < purl-- > 10:13
bacek Looks like current Pmc2c doesn't handle conflicts between parent's vtables
cotto orly?
purl YA RLY.
cotto purl++
bacek first encounter wins
cotto That's bad.
It shouldn't even allow multiple inheritance in that case.
cotto goes off to verify 10:14
oh. conflicts. 10:16
purl conflicts are conflicts
cotto That's the behavior I'd expect.
bacek it is... And it's bad... 10:18
ok, current behaviour can be implemented with little help of functional approach. 10:21
get_vtable(VTABLE * parent) ftw
cotto um... return parent; ?
bacek Derived_class_init() { VTABLE * t = Derived_get_vtable(Parent2_get_vtable(Parent1_get_vtable(Default_get_vtable()))) 10:23
:)
cotto I'm getting lisp flashbacks. 10:24
oic 10:25
v shiny
bacek oic?
purl oic is Oh, \\ see or Office of the Independent Counsel or yet another example of kickable k3wlt01k
bacek ah, ok
cotto So Foo_get_vtable takes a VTABLE* and adds its own function pointers. 10:26
bacek exactly
It's probably better to name it "build_vtable"
cotto I'd call it Foo_update_vtable, but I'm liking the idea. 10:27
10:27 rdice joined
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.
s/EXPORT/EXPORT,/ 10:28
bacek we'll need 2.
cotto O(number of PMCs) vs O(number of PMC VTABLE functions) 10:29
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:34
bacek updated TT#518 with suggestions. 10:44
bacek-- # forgot to mention cotto++ in ticket comment... 10:45
afk #kids time
cotto have fun 10:48
dalek rrot: r38444 | cotto++ | branches/tt528_vtinit:
creating a branch to address TT #528 and simplify PMC VTABLE initialization
 10:56
cotto yay. my first branch
11:01 rdice joined 11:03 jan joined
cotto rdice, ping 11:10
11:38 Ron joined
dalek rrot: r38445 | cotto++ | branches/tt528_vtinit/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] generate an (unused) update_vtable function for each PMC
 11:40
cotto sleep 11:42
11:59 Whiteknight joined 12:16 kid51 joined 12:31 bsdz joined 12:40 HG` joined
dalek rrot: r38446 | jkeenan++ | trunk (2 files):
Corrected the faulty logic described in

Replaced $_ with named lexicals in many locations. Removed pirc and pirc.exe from MANIFEST.generated. Removed one comment which referred to a ticket which was earlier rejected. Moved the POD to the end of the file so that you don't have to scroll down 5 screens to get to the code.		 12:48
purl i heard trac.parrot.org/parrot/ticket/586 was the reason for kid51's Win32 question.
13:25 Casan joined 13:26 jhorwitz joined
mikehh Coke: you available 13:46
Coke nope. 13:48
mikehh Is that - I am busy on something else or what? 13:49
14:02 fperrad joined
dalek rrot: r38447 | fperrad++ | trunk/config/gen/makefiles/pirc.in:
[pirc] remove some useless variables in Makefile
 14:06
14:30 dalek joined 14:45 whoppix joined 14:56 fperrad left
mikehh I was a little worried by the sentence starting -> Its architecture is fundamentally different than existing virtual machines 16:11
The "than" does'nt read right to me 16:12
doesn; 16:13
doesn't - ARGH
16:17 kid51 joined
pmichaud s/than/from/ 16:22
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 16:54 tetragon joined
Infinoid Coke: Do you mind if I use you as a guinea pig for a dalek feature I'm hacking on? 16:57
mikehh post configure tests fail at r38448 17:03
Failed 4/37 test programs. 6/996 subtests failed. 17:04
17:23 Theory joined
mikehh smolder don't seem to be talking to me again 17:35
17:59 Ron joined
kid51 mikehh: Could not reproduce your failure. 18:00
mikehh kid51: which one? 18:04
dalek kudo: cacc976 | pmichaud++ | src/setting/Any-list.pm:
Rewrite Any.join() to avoid the "Cannot reduce() empty list" error.
 18:09
kudo: 06f0ae8 | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
 18:37
kudo: d4a0b3b | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 378 files, 10991 passing, 0 failing
jonathan Awww...nearly 11,000. 19:27
19:32 Theory joined 19:59 leto_ joined 20:28 amoc joined 20:51 Whiteknight joined 20:52 HG` joined 21:04 tetragon joined 21:09 dukeleto joined
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
cotto bacek, this is interesting. Apparently the default VTABLE is never initialized. 21:25
nor is it even a usable PMC 21:28
(which makes sense) 21:29
21:32 dduncan joined
Whiteknight that is pretty interesting actually 21:32
cotto default is a very special case 21:42
21:47 rhall joined 21:51 rhall left 21:53 s1n joined 22:17 ingy joined 22:21 MariachiElf joined
bacek good morning 22:51
MariachiElf good afternoon :)
cotto hi 22:52
seen darbelo
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]
bacek cotto: (default) We can still provide Default.build_vtable. Just don't register it in interp->vtables 22:54
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:56
cotto Currently, the pmc2c code catches that ATTR situation and refuses to build. 22:57
It's not the way we want to do things long-term, but allison said it's ok for now. 22:58
bacek Probably it's time to reinvent C++ wheel with virtual inheritance... 22:59
MariachiElf Which reminds me of the xTalk project I'm working on 23:01
bacek xTalk?
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
bacek: Have you ever heard of HyperCard, SuperCard, MetaCard, or Revolution? Maybe seen some AppleScript? 23:02
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
bacek oh. Sounds bad... 23:04
MariachiElf Instead of something like x.label = "SomeLabel";
You'd use: set the label of field x to "SomeLabel"
bacek cotto: we can use Hash.freeze/thaw for persistence. 23:05
MariachiElf: It's weird. Too noisy.
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
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:06
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
bacek MariachiElf: every language has own niche. Even PHP :)
cotto: we can even freeze whole PMC::Class. 23:08
MariachiElf bacek: Check out: en.wikipedia.org/wiki/XTalk for a super brief 'what does it look like' 23:09
But back to the problem I'm hoping to solve is the extensible part of the language 23:10
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
It'd probably be used: move button "x" to 100,300 in 5 seconds
You can imagine that will use up "5 seconds" to reposition button "x" to the new location 23:12
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)
You can't use the cool syntax 23:14
You need to do something like: move(x, (100,300), 5, useAccel= "yes") 23:15
bacek Use Perl6 for implementing xTalk. Then everything will be extremely cool :) 23:16
MariachiElf bacek: That's actually what I was thinking
I was trying to decide if xTalk on top of Perl6 would be better than xTalk on top of Parrot
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:17
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.
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
bacek And you don't need to replace existing behaviour. MMD ftw 23:20
MariachiElf MMD ftw?
bacek MultiMethodDispatch
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"
bacek Then parser will just emit "move(...)" and MMD will dispatch it to proper function
MariachiElf Oh signature based
bacek yes
MariachiElf But that's only if the signatures can be identified 23:23
The example I gave happens to have different signatures
bacek You are really doesn't want signature clashing.
MariachiElf But depending on whether or not the optional parameter useAccel is provided you can't tell the difference between the signatures 23:24
23:24 Theory joined
MariachiElf Well it's useful in this language to rewrite existing "verbs" 23:24
bacek Without "useAccell" it will use "old" version
MariachiElf There's use cases for replacing the "native" functionality 23:25
I just don't want to lose all access to it... 23:26
For instance perhaps an optional qualifier would force the command to come from a particular namespace?
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)
rakudo: say "hi"
no evalbot?
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:28
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
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'" :)
Parser isn't "built-in" in Perl6.
23:32 MariachiElf joined
MariachiElf is feeling rather Pidgin incompetent atm 23:33
So what output am I looking at here 23:34
bacek use xchat-gnome
MariachiElf is on Vista
bacek ouch....
purl ouch is www2.epscylonb.com/image001.gif
MariachiElf lol
I can't watch 23:35
bacek bad girl
MariachiElf Yes, that's worse than using Vista
bacek purl: bad girl
purl bacek: huh?
bacek Last time I used Vista 2 years ago. AFAIR it was much better than XP. 23:36
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:37
I am hoping very much to get some kind of free and extensible xTalk implementation going though 23:38
The xTalks are about more than just the scripting language, there's a whole GUI metaphor that goes with it 23:39
It's a very high level abstraction great for doing cool GUI apps 23:40
23:40 Limbic_Region joined
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:41
23:56 dukeleto 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!