pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/ Set by Tene on 29 July 2008. |
|||
ruoso | Hello! | 00:00 | |
00:03
Ontolog left
00:09
justatheory left
|
|||
Tene | Hi! | 00:30 | |
00:33
Limbic_Region left
00:43
charsbar_ left,
charsbar joined
00:44
charsbar left
00:49
charsbar joined
00:53
meppuru joined
00:58
meppl left
01:08
Alias_ joined
|
|||
meppuru | good night | 01:29 | |
01:30
meppuru left
|
|||
pugs_svn | r22268 | ruoso++ | [smop] starting to apply "every value is a list of itself" on array | 01:34 | |
01:37
Exodist left
01:47
justatheory joined
02:00
jhorwitz left
02:03
wknight8111 left
02:12
apeiron_ joined
02:20
apeiron left
02:36
cxreg joined
|
|||
cxreg | particle @ spug wants to know who holds the copyright to the test suite. anyone know? | 02:36 | |
obra | cxreg: that's a difficult and loaded question. | 02:43 | |
02:43
apeiron joined
02:50
apeiron_ left
02:51
justatheory left
02:52
sail0r joined
02:53
sail0r left
|
|||
cxreg | obra: that's what we figured :-) | 02:54 | |
03:02
elmex_ joined
03:18
elmex left,
elmex_ is now known as elmex
03:32
Alias_ left
03:40
z80ASM joined
03:44
Ontolog joined
|
|||
z80ASM | Larry, how's it going? | 03:51 | |
03:59
xinming joined,
justatheory joined
04:09
alester joined
04:12
sunnavy joined
04:15
ashizawa joined
04:23
BinGOs left
04:24
sunnavy left
04:25
sunnavy joined
04:26
alester left
04:29
BinGOs joined
04:53
ashizawa left
04:54
justatheory left
05:07
bennymack joined
05:17
ashizawa joined
05:20
qwr joined
05:28
xinming left
05:58
Psyche^ joined
06:00
Patterner left,
Psyche^ is now known as Patterner
06:09
xinming joined
06:24
xuser left
|
|||
Ontolog | everything under the 'TODO Functions' section of src/gen_builtins.pir is really unimplemented? | 06:35 | |
I thought chomp already was implemented | |||
i would like to implement something here, something simple | 06:39 | ||
any suggestions would be nice | |||
06:48
jferrero joined
|
|||
Ontolog | c'mon nobody wants to hand-hold me through the code?! | 06:51 | |
maybe if someone could just give me an explanation of all the things in sub 'infix:=' that would help | |||
i'm not sure which words are PIR native functions and which are defined elsewhere | 06:52 | ||
for example 'assign' and 'getprop' | |||
moritz_ | Ontolog: your chances are better in #parrot (on irc.perl.org) | 06:55 | |
Ontolog | moritz_: ok i found the answers to those parrot questions | ||
moritz_: about the TODO stuff in src/gen_builtins.pir | |||
moritz_: can I just go about trying to implement some of that stuff? is there some basic stuff I need to know? | 06:56 | ||
I see all the methods are in the Perl6Object namespace and have some name like .sub 'infix:=' :method | |||
moritz_ | Ontolog: gen_builtins.pir is generated from classes/*.pir and builtins/*.pir | 06:57 | |
Ontolog: so don't modify that file itself, but rather the files from which it was created | |||
06:57
Alias_ joined
|
|||
Ontolog | haha that's good to know :p | 06:57 | |
moritz_ | all files starting with gen_ are generated | 06:58 | |
(I fell into that trap first as well) | |||
Ontolog | moritz_: could you just assign me some basic task that you know shouldn't be too complex? | ||
moritz_: I would just like to jump in and contribute some code | |||
moritz_ | Ontolog: in src/builtins/any-str.pir there's the 'comb' method | 07:00 | |
Ontolog: it should accept an optional second argument that limits the number of matches | |||
(that's documented in S29) | |||
Ontolog: currently it assumes "as many matches as possible" | |||
Ontolog | cool i'll see what i can do | 07:01 | |
07:02
mberends joined
07:03
xuser joined
07:08
mberends left,
mberends joined
07:11
iblechbot joined
07:19
zamolxes left
|
|||
Ontolog | moritz_: according to the doc it seems that only in the case that capture groups exist in the regex supplied to comb() does there need to be Match objects returns | 07:31 | |
If there are captures in the pattern, a list of Match objects (one per match) is returned instead of strings. | |||
moritz_ | Ontolog: since we can't return match objects anyway (see RT #55962) we don't yet bother about this detail | 07:33 | |
Ontolog: if we *can* return them, the current logic is flawed anyway because truncating s leads to wrong .from and .to values on the match object | |||
Ontolog | hmmm... ok so maybe working on this is not so easy after all... anything simpler without blocking bugs? | 07:34 | |
moritz_ | well, I don't see any blocker for adding a repetition limit | 07:35 | |
it should be as simple as adding a second, optional parameter and a counter, and jumping to 'done' when the counter is exceeded | 07:36 | ||
Ontolog | oh i'm sorry i misunderstood what you wanted | 07:45 | |
so the $n in the docs | |||
basically implement that? | |||
moritz_ | yes | 07:46 | |
Ontolog | is there a rule about not modifying parameters? or can I just n -= 1 in that loop? | ||
moritz_ | on the perl level you are not allowed to modify parameters (unless they are claimed to be 'is rw' in the spec) | 07:47 | |
but if you use .param int count in PIR I think that's a copy anyway | |||
Ontolog | yes the latter is what i meant | 07:49 | |
i'll test it out and see what happens | |||
07:51
zamolxes joined
|
|||
Ontolog | moritz_: ok I got it to work however now I need to make the second argument optional | 07:56 | |
moritz_: any idea on that? | |||
moritz_ | Ontolog: either add a second multi, or use an :optional argument (preferred) | 07:57 | |
Ontolog: see .sub 'index' in the same file for an example | |||
08:00
cotto_w3rk left
|
|||
Ontolog | moritz_: ok got that to work, however i need to know what value optional arguments get set to if they are not supplied | 08:01 | |
moritz_ | Ontolog: if they are not supplied, the corresponding :opt_flag param is false | 08:02 | |
(out of band signalling)++ | |||
Ontolog | sorry i don't understand :p | ||
what opt_flag param? | 08:03 | ||
moritz_ | you can have something like this: | ||
.param in count :optional | |||
.param int has_count :opt_flag | |||
now if that optional parameter was provided, has_count will be true (aka 1) | |||
08:04
mberends left
|
|||
Ontolog | so how is it associated, by its position in the sub? | 08:04 | |
moritz_ | yes | ||
it should go immediately after the :optional param | |||
Ontolog | i see, so we don't rely on some kind of undef or null value | ||
moritz_ | no | 08:05 | |
a (parrot) int can't be undef, afaict | |||
Ontolog | i see, so in fact we must have this extra flag | ||
moritz_ | yes | ||
what you could do is to set count to -1 if it's not provided | 08:06 | ||
and jump to the end if count == 0 | |||
and decrement after each match | |||
08:10
iblechbot left,
lolo92 left
08:11
pmurias joined
|
|||
pmurias | ruoso: hi | 08:11 | |
Ontolog | moritz_: I finished it, so now what do I do? | 08:20 | |
moritz_ | Ontolog: run 'make fulltest' first | 08:21 | |
Ontolog | ok | ||
pmurias | ruoso: i changed my mind a bit about the context stuff, as it's possible to do stuff like ~(+f()) we need at least a big chunk of the lazy context propagation in addition to the forward context propagation | ||
moritz_ | Ontolog: if that's successfull, do a 'svn diff > comb_limit.patch' and send the patch to [email@hidden.address] | ||
Ontolog | moritz_: i also wrote a test | 08:22 | |
moritz_: just a plain perl 6 script | |||
moritz_ | Ontolog: there are already some tests in t/spec/S29-str/comb.t | ||
Ontolog | i see | ||
moritz_ | Ontolog: it would be great if you could integrate your tests there | ||
Ontolog | will do | 08:23 | |
moritz_ | Ontolog: these tests live in the pugs repository | ||
Ontolog | ohhh right | ||
moritz_ | Ontolog: do you have a commit bit for that? | ||
Ontolog | i heard about that | ||
no... at least not that i remember | |||
let me check my email | |||
moritz_ | then give me your email address, and I can get you want | ||
(use a private /msg if you have privacy concerns) | 08:24 | ||
Ontolog | moritz_: I have applied for commit bits it appears in November 2006 :p but i never did anything with it | 08:26 | |
moritz_: username is cdavaz, not sure what I set the password to | |||
moritz_: email is [email@hidden.address] | 08:27 | ||
moritz_ | Ontolog: I'm sending the mail again | 08:28 | |
Ontolog | cool... that test is still running :p | ||
moritz_ | heh, you have a commit bit longer than I do ;) | 08:29 | |
Ontolog | yeah i remember at that time someone encouraged me to contrib to pugs | ||
but i didn't know any haskell really | |||
moritz_ | neither did I ;) | ||
Ontolog | but now i want to make contribs to rakudo | ||
ahh did you learn Haskell for Pugs? | 08:30 | ||
moritz_ | I tried, and failed | ||
Ontolog | haha I did spend some hours learning Haskell at some point but just some basic stuff... completely not intuitive that language :p | ||
seems more geared towards mathematicians | |||
ok the test passed i'll send the patch | 08:31 | ||
moritz_ | you have to re-wire your brain to learn haskell | ||
great | |||
Ontolog | ok there is already a test in there like this: is "a bc d".comb(:limit(2)), <a bc>, 'default matcher with supplied limit'; | 08:38 | |
I see the 'named parameter' syntax there :limit(2) | |||
however in my patch i didn't do anything about named parameters | |||
should I go back and revise the patch? | |||
moritz_ | no, we generally don't handle many named arguments yet :( | 08:40 | |
parrot doesn't support arguments that can be both named an positional | |||
at least not in the way we need it | |||
that should be fixed at some point | |||
before that there's no use in trying to support them | 08:41 | ||
Ontolog | i see... hmm so i'm not sure exactly how to add my tests | ||
there are these formatted comments | |||
that seem to tell the test harness to skip certain tests for either pugs or rakudo | |||
moritz_ | yes | ||
Ontolog | so if we want to skip the test for pugs but execute it on rakudo | ||
what should that comment look like? | |||
moritz_ | well, first add the tests | 08:42 | |
when they pass, no further comments needed | |||
Ontolog | but they will fail on pugs | ||
moritz_ | then add a '#?pugs $count skip "todo: Str.comb"' line before them | ||
Ontolog | ok | 08:43 | |
moritz_ | Ontolog: applied patch, thanks for the great work | 08:47 | |
rakudo_svn | r31204 | moritz++ | [rakudo] implement 2-param form of Str.comb, Ontolog++ | ||
r31204 | moritz++ | Patch courtesy by Chris Davaz <cdavaz at gmail dot com> | |||
moritz_ | Ontolog: (I changed count -= 1 to 'dec count', but that's only a small stylistic fix) | ||
Ontolog | cool | 08:49 | |
if I just want to run an individual test from the pugs test suite is there any easy way to do that? | 08:52 | ||
moritz_ | yes, make t/spec/S29-str/comb.t | 08:53 | |
or 'echo S29-str/comb.t > t/localtest.data' and then 'make localtest' or 'make localtest_loud' | |||
08:54
barney joined
08:57
masak joined
|
|||
pugs_svn | r22269 | cdavaz++ | Added tests to t/spec/S29-str/comb.t for second parameter of comb | 09:04 | |
pmurias | moritz_: does dec count have any benefits compared to count -= 1 | 09:06 | |
? | |||
moritz_ | and Ontolog++ again | ||
pmurias: I'm not entirely sure, which is why I called it a "stylistic" fix | |||
pmurias: it's just a bit more ideomatic | |||
Ontolog | moritz_: any other easy ones? | 09:10 | |
09:11
iblechbot joined
|
|||
moritz_ | Ontolog: there's Str.split(/regex/), but I don't think it's as easy as the previous one | 09:12 | |
Ontolog: but it would be *really* helpful to real world development | |||
Ontolog | the split method is not implemented at all? | 09:13 | |
or just some feature thereof? | |||
moritz_ | just Str.split(Str) is impelemented | ||
Ontolog | i see | ||
which file? | 09:14 | ||
classes/Str.pir it seems | |||
moritz_ | aye | ||
Ontolog | i'll see what i can do | ||
moritz_: so this requires making another sub with the heading.sub 'split' :method :multi('Regex') ? | 09:19 | ||
moritz_ | Ontolog: yes, but I don't think that 'Regex' is the right type | ||
Ontolog: parrot internally stores them as Code or Block objects or so | |||
Ontolog | I see, I'll try to find an example of another method that takes a Perl regex as an argument | 09:20 | |
moritz_ | rakudo: say /a/.WHAT | ||
p6eval | rakudo 31204: OUTPUT[Blockā¤] | 09:21 | |
Ontolog | I see, so it is a "Block" and this is some type that is only known to Parrot, not a Perl type | ||
moritz_ | there's another difficulty - there are some type maps between Perl and Parrot land | 09:22 | |
literal | moritz_: I'd like to help with Rakudo, where could I start? | ||
moritz_ | so you can try with 'Block', but I'm not sure if it will work | ||
maybe groups.google.com/group/november-wi...147adaad2f is of interest | |||
lambdabot | Title: .split(//) - november-wiki | Google Groups, tinyurl.com/5cqbj8 | ||
moritz_ | literal: what's your skill set? | ||
literal | For one, I don't know C. | 09:23 | |
moritz_ | no problem | ||
literal | I know Perl 5 pretty well and I've been reading the synopses now and then for a while | 09:24 | |
moritz_ | literal: common helpful task for beginners are 1) writing tests 2) infrastructure 3) writing builtins (requires a bit of PIR knowledge, but not that hard to learn) | ||
literal | could you point me to some aspect of Rakudo that's easy to get into? | ||
hm, writing tests is no. 1? aren't there thousands of tests already which Rakudo doesn't pass yet? :P | 09:25 | ||
moritz_ | literal: yes, and tens of thousands to be written | ||
literal | I see | 09:26 | |
is there some 'chart' or something that shows which parts of the standard need tests? | |||
09:26
baest joined
|
|||
moritz_ | one easy starter is to go through the bug tracker. Many tickets contain small Perl 6 samples that could be turned into test | 09:26 | |
literal | ok | 09:27 | |
moritz_ | literal: if you look at the synopsis under perlcabal.org/syn/ you'll see these small links to tests spread all over the specs | ||
lambdabot | Title: Official Perl 6 Documentation | ||
moritz_ | literal: when there's a gap somewhere with no links for a long time, there's likely a test deficit | 09:28 | |
literal | I see | ||
and where's the bug tracker? | |||
moritz_ | literal: also t/TASKS in the pugs repo contains a list of things that need to be done | ||
rt.perl.org/rt3/ | |||
lambdabot | Title: Login | ||
literal | hm, is a PAUSE id not sufficient for logging in? | 09:29 | |
moritz_ | only for rt.cpan.org | 09:30 | |
literal | ok | ||
moritz_ | either get a bitcard account, or use the guest interface | ||
09:33
kanru left
09:35
langri joined
09:36
kanru joined
|
|||
masak | moritz_: ping | 09:41 | |
langri | hi | 09:42 | |
masak | hi langri | ||
09:44
langri left
|
|||
moritz_ | masak: pong | 09:44 | |
masak | moritz_: do you have an opinion on rt.perl.org/rt3/Ticket/Display.html?id=58826 ? | ||
lambdabot | Title: #58826: Non-rw attributes are not changeable from within a class in Rakudo | ||
masak | I feel I have a point, but I don't want to be battling windmills either | 09:45 | |
it there's a point to non-rw attrs being writable by _nobody_, I just don't see it | |||
moritz_ | wait a sec (distraction in #perlde...) | 09:47 | |
masak | sure thing. | ||
moritz_ | from an implementation POV it makes sense to forbid $.foo = 3 if $.foo is not rw | 09:48 | |
09:48
smg left
|
|||
moritz_ | because $.stuff is really just $(self.stuff) | 09:49 | |
masak | so how'd you set $.foo ? | ||
moritz_ | $!foo = stuff | ||
masak | :( | ||
can't say I like it | |||
moritz_ | me neither | 09:50 | |
masak | but I also see that my view of things is as arbritary as the one currently implemented, if not more so | ||
and I don't have much in the way of defense of my view, except a strong personal preference... | |||
moritz_ | there's a point in using the private accessors inside the class exclusively | 09:51 | |
remeber, the attributed is called $!foo, the $.foo is only an accessor | |||
masak | yes. | ||
it will also confuse the heck out of beginners | |||
ruoso | pmurias, cool :) | ||
moritz_ | so if you change your mind about which attributes should be public | ||
you have to change code if you don't use the private accessors | |||
it's ugly, but still loads better than $self->{foo} | 09:52 | ||
otoh the first example in perlcabal.org/syn/S12.html#Submethods suggests that $.stuff is rw from inside the class | 09:53 | ||
lambdabot | Title: S12 | ||
masak | moritz_: only under the current regime. were writing to non-rw attrs allowed within the class, there would be no problem in the first place | ||
I sure hope they are. | |||
09:53
hanekomu joined
|
|||
pmurias | ruoso: isn't the lazy context propagation the same thing as coersions? | 09:53 | |
ruoso | it can be seen as the same thing, yes | 09:54 | |
masak | it's like this: we have to litter the attr declarations with "is rw" specifiers, and it feels _pointless_. | ||
09:55
xiaoyafeng left
|
|||
masak | if those were needed when we actually needed to set attrs from the outside, it would be bearable | 09:55 | |
but now they are needed as soon as we plan to give an attr a value, which is, um, all the time | |||
hence all attrs get "is rw" | |||
very non-Perlish | |||
pmurias | masak: why are you opposed to using $!foo? | 09:57 | |
moritz_ | masak: that's mostly because .new() doesn't set attributes, right? | ||
masak | pmurias: because I _declared_ $.foo | ||
moritz_: I guess | |||
moritz_: so they're writable through constructors? | |||
why? | |||
literal | man, I hope Perl 8 won't have trigils | ||
masak | literal: :) | 09:58 | |
moritz_ | masak: because they need to be | ||
smtms | the armaggeddon is planned just after Perl 7 is relesed | ||
masak | trigils would be for AOP, I guess | ||
moritz_ | masak: otherwise $obj.perl simply can't work in any meaningful way | ||
ruoso breakfast & | |||
masak | I see how my problems would be solved if I'd just bite the bullet and use $!foo in my methods. it's just that... it's one more thing to keep in mind, when $.foo could easily have worked | 10:00 | |
pmurias | masak: consider the case when i change has $.foo into has $!foo;method foo {$!foo*2} | ||
masak | hm | 10:01 | |
10:01
baest left,
baest joined
|
|||
masak | pmurias: at least then I wouldn't expect setting $.foo to work, no | 10:02 | |
pmurias | fixing a (nokia pc suite)-- automatisation app& | 10:05 | |
masak | it's a question of DWIM, I think. if I write `$.foo = 5;`, chances are that I really mean that, regardless of whether I wrote `has $.foo` or `has $.foo is rw` before. | 10:06 | |
moritz_ | masak: it's the old question: do we/you want to sacrifice consitency for convenience? | ||
masak: I suggest you take it to p6l | 10:07 | ||
masak | yes. | ||
just thought I'd start here :) | |||
now I know there's a chance I'll be shot down, because I represent convenience, not consistency :) | |||
I didn't know that before | |||
moritz_ | masak: the nice thing about being shot down from p6l is that you recover rather quickly ;) | 10:09 | |
yes, starting here is good but in this case I think we'll benefit from the broader audience | 10:10 | ||
masak | writing mail now | ||
10:12
ashizawa left
10:17
Alias__ joined
10:18
Alias_ left
|
|||
pmurias | masak: i can apply the same thought process to $.foo = 5 from outside the class | 10:19 | |
masak | pmurias: you mean, you could argue for the opinion that it should be writable from the outside as well? please do. | 10:20 | |
I don't see it. | |||
I think it's different. | |||
pmurias | if i want to write to a ro attribute i want to do it so perl 6 should DWIM and do it | 10:21 | |
masak | ah, but then you're crossing a class boundary | 10:24 | |
not your call anymore, the class gets to decide | |||
that's the key -- when I'm writing stuff _within_ the class, I'm (by definition) the author of the class | |||
it's my call when to write to accessors | |||
a call from the outside does not have the same luxury | 10:25 | ||
it's some sort of principle in OO | |||
"encapsulation", perhaps? or "information hiding"? I dunno. | |||
lunch & | |||
moritz_ | rakudo: class A { has $.b }; my A $x .= new(b => 3); say $x.b | 10:29 | |
p6eval | rakudo 31204: OUTPUT[3ā¤] | ||
10:38
Alias__ left
|
|||
pmurias | masak: has $.foo;method bar {$.foo = 4} does violate some sort of "information hiding" too, as you assume that $.foo is defined in your class (it could have mean inherited etc.) is a rw one underneath | 10:38 | |
and the benefit of this is that you will be able to use the wrong twigil and Perl 6 will just silently assume you wanted to use the right one | 10:39 | ||
the "authorship" of a given component in information hiding is not really relevant | 10:41 | ||
10:41
ruoso left
10:43
zamolxes left
|
|||
masak | pmurias: you have a point. | 10:51 | |
11:06
masak left
11:15
Ontolog left
11:19
smg joined
|
|||
pugs_svn | r22270 | pmurias++ | [smop] IO RI converted to the RI DSL | 11:27 | |
11:36
Ontolog joined
11:41
BinGOs left,
BinGOs joined
11:42
BinGOs left
11:47
zamolxes joined
11:53
BinGOs joined
11:57
masak joined
12:01
hanekomu left,
hanekomu joined
12:02
abra joined
12:14
mncharity joined
12:16
hanekomu left,
hanekomu joined
12:23
sri_work joined
|
|||
mncharity | moritz: masak: Thanks for the perl.net.au/wiki/Elf suggestions. It's been updated. | 12:30 | |
lambdabot | mncharity: You have 2 new messages. '/msg lambdabot @messages' to read them. | ||
Title: Elf - PerlNet | |||
moritz_ | mncharity: np, great | ||
mncharity | moritz_: re STD_blue, beyond what the page says, my hope is for the simplicity of using STD/gimme5 directly, with TimToady fixing the bugs which turn up, and one of {TT, or someone else, adding Match tagging, or being able to live without it}. | 12:33 | |
masak | mncharity: glad to help | ||
moritz_ | mncharity: is there a compelling reason not to use the YAML dump from STD? | 12:35 | |
12:36
alester joined
|
|||
mncharity | masak: there are some low-hanging fruit if you wanted something to work on. Like adding arguments and types to the bare names in docs/p6types. rhr++ | 12:36 | |
moritz_: re YAML, dealing with yaml turned out slow and buggy. Slow as in something vaguely like a 50% or 100% hit on total parsing time. Buggy as in such amusements as a the value of a hash field mutating into its field name for particular original field values. I was surprised by how bad it all was. | 12:39 | ||
My current model is that yaml doesn't really get exercised for large data sets. Common case seems to be small config files. | |||
moritz_ | mncharity: ok, interesting | ||
mncharity: another thing... is there a single "make test" somewhere that gives a simple yes/no answer to the question "did I break something"? | 12:40 | ||
mncharity: if not, I feel that's essential in our TDD Perl 6 world | |||
pmurias | mncharity: hi | 12:41 | |
masak | mncharity: I'll consider it. right now, November gives all the joy I can accept and takes all the free time I have. :) | 12:42 | |
pmurias | mncharity: what does the using gimme5 directly mean? | ||
back to eating soup& | 12:43 | ||
mncharity | re make test, hmm, interesting. it currently comes in two parts, make rebuild, and make test. make test runs t/, so takes some time. it's also not quite turnkey, since it doesn't sync your t/ with the revision used to generate the baseline file run-tests.result. | ||
hi pmurias | |||
masak: re November joy, lol. understood. :) | 12:44 | ||
pmurias: re gimme5 directly, -I src/perl6 use STD; | 12:45 | ||
that uses gimme5, yes? | 12:46 | ||
moritz_ | mncharity: the fact thet it takes more than 2 lines to explain in IRC means it's too complicated right now :/ | ||
mncharity | lol. good point. ok, will tool. | 12:47 | |
moritz_ | mncharity: I'd imagine something like rakudo's spectest_regression, which runs those tests that are known to pass | ||
mncharity: that also reduces run time | |||
pmurias | mncharity: it uses gimme5 indirectly as gimme5 is used to compile STD | 12:48 | |
12:49
alester left
|
|||
mncharity | pmurias: ah, ok. | 12:50 | |
12:51
araujo joined
|
|||
pmurias | re branching STD i i don't think it's even vaguely a goodish idea as TimToady does a very good job with STD, and we need to have *one* official grammar | 12:53 | |
moritz_ | aye | ||
mncharity | moritz_: re just run passing tests... hmm... | 12:55 | |
moritz_ | mncharity: if you want to know if additional tests pass, you can still use another test target | ||
12:57
alester joined
|
|||
mncharity | possible reasons for branching STD: to fix things which seem to be bugs (like the current(?) absence of identifier info in sub calls); to replace | with || (there being no existent fast-enough implementation of | , and none written in p6); to add Match node labeling (so AST->IR doesn't have to guess what the Match are); and | 12:59 | |
to decouple TT STD.pm development from elf development (so T can proceed full speed without worrying about elf, and the | 13:00 | ||
to decouple TT STD.pm development from elf development (so TT can proceed full speed without worrying about elf, and elf isn't destablized by those changes). | 13:01 | ||
*Matches are | |||
moritz_ | do you think that STD_red (as an implicit branch) was successful? | 13:02 | |
13:04
meppl joined
|
|||
mncharity | moritz_: re tests... the thing is, at least when passing % is low, a problematic "unexpected thing" may as often(?) manifest as failing tests starting to pass. maybe. anyway, no reason it can't be a test target. | 13:04 | |
originally thought it hard, thus my hesitation, but if not, customer rules. | |||
pmurias | mncharity: TT = ? | ||
mncharity | TimToady | ||
13:05
charsbar_ joined
|
|||
mncharity | moritz_: re "do you think that STD_red (as an implicit branch) was successful?", oh, definitely. Well, the big picture question is whether anything was gained by being able to write elf over the last months, rather than waiting until now. Err, no. Or rather, yes. gimme5 is still rather slow, and STD_red may have helped to push STD development along. As for the role of branching, | 13:07 | |
pmurias | mncharity: you should fix the bugs directly in STD, there is no need for Match node labeling as you now what is it from what you got it from | ||
13:08
nipotan_ joined
|
|||
mncharity | branching permitting fixing tens of bugs old versions of STD (without which elf couldn't work); permitted using || for | (without which elf couldn't exist (working | is recent), or run fast (still no fast | )); permitted tagging Matches with the rule and branch they came from (making the Match AST -> IR node mapping code vastly simpler and more maintainable). | 13:09 | |
13:10
charsbar left,
charsbar joined,
charsbar_ left
|
|||
mncharity | re tagging Matches, for comparison, there's the older attempt to use rakudo as front-end, which took the "guess" approach. really really messy. | 13:10 | |
13:11
charsbar left
|
|||
pmurias | when i was doing pixie i didn't have to guess anything | 13:11 | |
mncharity | re old rakudo front-end, though it appears not easy to find... hmm... | 13:13 | |
13:13
jan_ left
|
|||
mncharity | pmurias: you tweaked STD.pm and applied {*} tagging? | 13:13 | |
13:14
jan_ joined
|
|||
moritz_ | mncharity: rakudo is rather clos to allow builtins written in Perl 6 (modules can already be compiled), and one of the next milestones is to implement LTM in PGE, then bolt STD.pm onto rakudo | 13:14 | |
mncharity: when that's actually done I see no big advantage of elf over rakudo any more | 13:15 | ||
pmurias | i overwrote the {*} handling in STD so i could add hooks at runtime and set the result for Matches as they were created by the grammar | ||
moritz_: elf is perl 5 base which should allow good perl 5 integration | |||
moritz_ | pmurias: point taken | 13:16 | |
moritz_ has to leave no, bbl | |||
mncharity | svn.pugscode.org/pugs/misc/rakudo/e...o_ast.data | ||
lambdabot | tinyurl.com/5lhhe7 | ||
pmurias | mncharity: and i wrote a script which allowed me to write {*} handlers *as* if i was filling the {*} blocks | 13:17 | |
mncharity | re close to allow builtins written in Perl 6, nifty. though... well, my fuzzy recollection is it was also believed to be close a month+ ago. nice to know it really is now. ;) | ||
yay on module compilation | |||
Ontolog | in which files are Regexp objects defined? | ||
mncharity | re LTM, neat. perhaps do a p6 reference implementation before getting down to PIR? | 13:18 | |
moritz_ | dunno, that's pmichaud's design work, I'm mostly observing | 13:19 | |
have to really run now & | |||
pmurias | mncharity: but when TimToady removed all the rule foo {... {*} } {*} blocks pixie broke | ||
Ontolog | in src/classes I can't find either Rule.pir or Regex.pir or anything of the like | 13:20 | |
mncharity | moritz_: re "when that's actually done I see no big advantage of elf over rakudo any more", possibilities include faster (or at least was, and a CL backend may provide another 10x); much more of the compiler written in p6; | ||
13:21
z80ASM left
|
|||
pmurias | mncharity: rakudo could be made to emit CL | 13:22 | |
mncharity | everything directly controllable (ie, nothing blocks on parrot bugs, though obviously, some new desired approach to say a p5 backend my block on p5 bugs, but that's a different, less problematic issue); | ||
s/my/may/ | |||
Ontolog | man dividing the development effort among several competing implementations suck | 13:23 | |
none of the impl's have enough developers | |||
mncharity | pmurias: re "pixie broke", :-( I was about to say, re {*}, that maybe we would have to copy pixie's approach. drat. then... well, yes, STD.pm may need massage. | ||
we'll see. | 13:24 | ||
re "rakudo could be made to emit CL", err, good luck. most of rakudo/parrot is written in C and PIR. | 13:25 | ||
pmurias | mncharity: "pixie broke" it should be possible to fix pixie, it was that i moved on to other things | ||
mncharity | re fix, right. | ||
pmurias | if rakudo has working multi methods it should be possible to write a CL emitter in Perl 6 | 13:26 | |
mncharity | I'm still hoping to avoid the entire issue. Just need to bootstrap the elf code and STD.pm itself. Then it is off the critical path. Elf is fully bootstrapped, and it becomes a "improve the compiler any way you want" issue. Question is whether it cause a maintainability meltdown nightmare. | 13:27 | |
pmurias | for all of the language using PCT | ||
Ontolog | what is CL? | ||
pmurias | common lisp | ||
Ontolog | i see | ||
pmurias | * languages | ||
entire issues = ? | 13:28 | ||
Ontolog | anyone on the Regex thing? I'm trying to find out how to manipulate Regex (or is it Rule?) objects within PIR | ||
taking a look at the Regex class would be nice but I can't seem to find it :( | |||
13:29
charsbar joined
|
|||
masak | Ontolog: as jonathan said, regexes are of typ Sub right now | 13:29 | |
mncharity | re CL emitter, yes, that would let you use the rakudo parser and AST aka IR. But you would still need assorted elf p6 code, and assorted elf p6 code as yet unwritten. | ||
pmurias | assorted elf p6 being the runtime support | 13:30 | |
Ontolog | masak: Sub.pir contains almost nothing | 13:31 | |
masak: which files defines the methods on a regex? | |||
mncharity | while "rakudo" is written in p6 and PIR, the compiler is rakudo+parrot, so being able to compile to non-parrot doesn't get you very far without a lot of parrot and pir replacement effort. which is what elf is. | ||
masak | Ontolog: which methods on a regex do you mean_ | ||
? | |||
Ontolog | masak: well I always see this match = regex.ACCEPTS(something) | 13:32 | |
masak | Ontolog: I suspect that regexes are created (as subs) which then call into PGE | ||
Ontolog: yes, regexes are basically that | |||
Ontolog | 'call into PGE' what does that mean? | ||
masak | Ontolog: PGE is a Perl 6 grammar engine | ||
it parses Perl 6 for Rakudo when compiling | |||
but it also handles regexes for Perl 6 programs in Rakudo | 13:33 | ||
Ontolog | ahhh | ||
masak | oops, sorry PGE == Parrot Grammar Engine | ||
Ontolog | ohh | ||
how about the Match object | |||
same deal? | 13:34 | ||
pmurias | mncharity: very far = bootstrap | ||
masak | probably directly created by PGE, or a wrapper of same | ||
Ontolog | so I have to look into this 'PGE' to see what a Regexp and a Match do? | ||
pmurias | mncharity: ? | ||
Ontolog | where is the pge? | ||
pmurias | compilers/pge | ||
Ontolog | ok | ||
mncharity | moritz_: re "when that's actually done I see no big advantage of elf over rakudo any more", possibilities include faster (or at least was, and a CL backend may provide another 10x); much more of the compiler written in p6 (so can use the many interesting backends out there); everything at hand (no blocking on parrot bugs). Downsides too of course, but those are potential advantages. | 13:35 | |
masak | pmichaud++ # thanks for PGE! it makes Rakudo so much nicer to work with | ||
pmurias | PGE makes rakudo possible | ||
masak | that, too :) | ||
Ontolog | haha I see! there are things about Perl6 outside of the languages/perl6 dir | 13:36 | |
yes Regex and Match are there | |||
I need to implement Str.split(/regex) | |||
masak | Ontolog: no, probably not | ||
Ontolog: go with Str.split(Sub) as jonathan said | |||
Ontolog | yes i mean that | 13:37 | |
i mean i need to implement the version of split that takes a regex | |||
so any hints on how to get the position information from the Match? | |||
masak | Ontolog: if you want inspiration, check out .subst that I implemented a while ago | ||
it's in any-str, I think | |||
Ontolog | yes i am looking at that | ||
masak | Ontolog: you are? cool! | ||
pmurias | mncharity: the main issue with elf for me is that rather then doing one thing good properly, we have a complete set of not good enough components | ||
Ontolog | masak: I see you use the from and to | 13:38 | |
masak | aye | ||
mncharity | pmurias: re very far, regex engine for p5 (as for elf), p6 (may get done for the CL backend; needed for others); and, well, "can now compile modules" and "soon can do builtins" means everything else, not currently written in p6, would have to be so. no? | ||
Ontolog | masak: ok I have a better idea of what to do now i'll give it a shot tomorrow, so don't go implementing it first :p wait for me to try | ||
masak | Ontolog: no promises :) | ||
(actually, I won't have time to implement it, so you're safe) | 13:39 | ||
Ontolog | haha cool | ||
mncharity | pmurias: re "rather then doing one thing good properly, we have a complete set of not good enough components", good observation. the | ||
masak | Ontolog: but don't get too comfortable! I might find some free time! | ||
Ontolog | i'm trying to make some contributions and maybe earn a commit bit | ||
masak | Ontolog: sounds great! | 13:40 | |
Rakudo needs people aspiring for commit rights | 13:41 | ||
Ontolog | yeah i'm lucky i have some time right now, work isn't too busy ;p | ||
mncharity | it seems very unlikely that any p6 code part of any existing implementation is anything but throwaway. to be thoroughly changed as p6 gets closer. perhaps some portion of rakudo's p6 parser and actions is more stable(?). certainly I'd never write a p6 compiler with callbacks rather than multis. so | ||
so the question is, how to get there from here. when we have no usable p6 compiler, and no prelude written in p6. | 13:42 | ||
how to get to xmass. | |||
masak | mncharity: btw, I think it's spelled "X-mas" | ||
but I'm no native, so don't take my word for it | 13:43 | ||
mncharity | tnx | ||
masak | also, "X-mas" might have more US/commercialism connotations than "Christmas" | 13:44 | |
again, don't take my word for it :) | |||
mncharity | how to get to X-mass. kp6 you know. pugs until resurrection is dead, and even then will be mostly hs rather than p6 - migrating the prelude from hs to p6 was a work (struggle) in progress back when pugs wound down. elf is better than redsix. and rakudo you know. | 13:46 | |
masak | it's not dead, it's sleeping! | 13:47 | |
mncharity | elf still seems to me likely the fastest path to a usable p6 compiler. unquestionably to a bootstrapped one. | ||
pmurias | i did a few commits on it recently! ;) | ||
(on pugs) | |||
masak | it's pinin' for the fjords | 13:48 | |
13:48
xiaoyafeng joined
|
|||
mncharity | re sleeping, indeed. and I look forward to morning. but... that just gets us back to where we were in 2005? modulo a much clearer and fleshed out p6 spec. | 13:48 | |
:) | |||
pmurias | mncharity: STD.pm is not throwaway | 13:49 | |
masak | mncharity: Pugs, stalled in late 2006, but point taken | 13:50 | |
s/,// | |||
moritz_ | (kinda re) | 13:52 | |
mncharity | basically, elf seems something vaguely like <1 FT person-year away from pugs-like t/ passing. perhaps just a couple of months. perhaps parallelizable down to 1 calendar month. but... the concept of writing a p6 compiler from scratch, more or less by myself, has very no appeal. even though that seems to be happening slowwwly, on an incremental installment plan. | ||
moritz_ | modulo a much larger test suite, one half of which is implementation independent | ||
mncharity | hell, if a good lisp hacker and one other wizzy person turned up, I suggest a hackathon and see if we could get to pugsian t/ in a long weekend. | 13:53 | |
masak | mind the brain! you don't want to do that... :P | 13:54 | |
13:54
charsbar left
|
|||
masak | that said, it sounds incredibly cool | 13:54 | |
13:56
charsbar joined
|
|||
mncharity | pmurias: re "STD.pm is not throwaway", current STD very little resembles STD of a month or few ago. while "it now works" is great, it's not clear to me that is equivalent to "it is now unlikely to change before X-mass". | 13:56 | |
masak | mncharity: you're still one "s" too many on that "X-mas" word. | 13:57 | |
mncharity | ah well. | ||
masak | :) | ||
13:57
charsbar left
|
|||
pmurias | mncharity: there is a difference between throwaway and "will evolve" | 13:57 | |
mncharity | :) have to head out. | ||
re difference between throwaway and "will evolve", | 13:58 | ||
moritz_ | volatile != throw-away, yes | ||
pmurias | gimme5 is throwaway | ||
avar | also nothing uses STD.pm in a self-hosting way so it might need lots of changes for that use | ||
pmurias | it will certainly need fixing the produced Match | ||
13:59
charsbar joined
|
|||
moritz_ | avar: possible, but not very likely. Rakudo's parser is modeled after earlier version of STD.pm, and didn't hit major usage obstacles | 13:59 | |
pmurias | major usage obstacles != hordes of tiny bugs | 14:00 | |
moritz_ | tiny bugs usually don't require large refactors | 14:01 | |
mncharity | pmurias: I think of "throwaway" as "long-term maintenance is not an issue", "code exists solely to fulfill short-term goals", "ideas play as much role as source", "one can't point to a line and say with confidence 'this line will be in the release version'", "one can point to lots and lots of lines and say with confidence 'this wont be'", ... | 14:02 | |
14:04
charsbar left
|
|||
abra | hi all | 14:05 | |
14:06
charsbar joined
|
|||
mncharity | pmurias: so back to "good thing properly", one certainly could, from scratch, write "if you had full p6, this is how you would write a p6 compiler". and "given that, here's how you would write a p6/CL/whatever backend". and you would be unable to run or test it until rakudo or elf or pugs was finished. | 14:06 | |
moritz_ | hi abra :) | ||
mncharity | at some point rakudo will start being able to run elf. but if one wants p6 to be bootstrapped, or non-parrot backends, that doesn't remove the need for something like elf. though obviously it would alter the details of how you went about it. | 14:08 | |
moritz_ | aye | ||
masak | mncharity++ | ||
Ontolog | Can I tmpstr = new 'Perl6Str' and then later tmpstr = subst self, start_pos, end_pos ? | 14:09 | |
pmurias | pluggin a non-parrot backend into parrot and replacing pir with perl6 when possible could also give a bootstrapped Perl 6 compile | ||
Ontolog | subst should return a Parrot String yes? | ||
pmurias | * plugin in | ||
Ontolog | but should I only be putting a Perl6Str in there? | ||
pmurias | s/parrot/PCT | ||
* compiler | |||
moritz_ | Ontolog: that should work because Perl6Str is a subtype of String | 14:10 | |
Ontolog: re "should I?", in first approximation everything that works is fair game ;) | 14:11 | ||
Ontolog | haha i just worry that we might need a special subst that returns a Perl6Str with some special stuff that a normal String doesn't have | ||
mncharity | pmurias: I'm not sure I understand the last suggestion. | 14:12 | |
masak | rakudo: class A { grammar B { token greeting { HAI }; } }; say ?("OH HAI" ~~ B::greeting) | ||
p6eval | rakudo 31210: OUTPUT[1ā¤] | ||
moritz_ | Ontolog: once HLL type maps are in place that shouldn't be a problem | ||
rakudo: class A { grammar B { token greeting { HAI }; } }; say ?("OH HAI" ~~ &B::greeting) | 14:13 | ||
p6eval | rakudo 31210: OUTPUT[1ā¤] | ||
abra | sorry for my english :) I try to build pugs from source, but it's failed :( Somebody can help me? rafb.net/p/G74g6D28.html | ||
lambdabot | Title: Nopaste - build pugs failed (( | ||
masak | will putting a class/grammar inside a class reduce its visibility in any way? | ||
pmurias | mncharity: what i'm suggesting is that it should be possible to morph rakudo into a Perl 6 only compiler emitting CL | ||
14:14
z80ASM joined
|
|||
moritz_ | abra: how new or old is your copy of pugs, and which version of GHC6 do you use? | 14:14 | |
Ontolog | how should I test if match.'next'() is successful or not? | 14:15 | |
mncharity | have to go. pmurias: much appreciate the thoughts. perhaps the Elf page could use info on "possible long-term roles of elf", and "nature of the elf bootstrap". re morph, | ||
abra | moritz_, The Glorious Glasgow Haskell Compilation System, version 6.8.2 | ||
pmichaud | (named parameters) -- why is it not worth supporting named parameters yet? | ||
moritz_ | Ontolog: either it returns a value which you can test for success, or it mutates match (I don't know) | 14:16 | |
Ontolog | moritz_: it returns () in every case | ||
moritz_ | abra: how did you get pugs? via svn? | ||
abra: if so, which revision do you use? | |||
abra | moritz_, via svn | ||
pmurias | mncharity: i'm willing to help with the CL backend as it would pave the way for a smop one | ||
pmichaud: were did you get the not worth to support named parameters stuff from? | 14:17 | ||
moritz_ | abra: could you please nopaste the output of svn info? | 14:18 | |
mncharity | awesome, help would be great. my next on_sbcl step is to get class and method emitting written. assistance then on writing Array and Hash and etc primitives, part p6 and part CL (like PrimitivesP5.pm), would be most nifty. | 14:19 | |
pmichaud | pmurias: sorry, I was reading scrollback and didn't realize I was reading scrollback | ||
just a sec | |||
08:37 <Ontolog> ok there is already a test in there like this: is "a bc d".comb(:limit(2)), <a bc>, 'default matcher with supplied limit'; | 14:20 | ||
08:38 <Ontolog> I see the 'named parameter' syntax there :limit(2) | |||
08:38 <Ontolog> however in my patch i didn't do anything about named parameters | |||
08:38 <Ontolog> should I go back and revise the patch? | |||
08:40 <moritz_> no, we generally don't handle many named arguments yet :( | |||
moritz_ | pmichaud: that was meant wrt to named versions of positional arguments | 14:21 | |
pmichaud | is what I was referring to. | ||
moritz_ | not named arguments in general | ||
pmichaud | right, named versions of positionals we don't support. But :limit(2) isn't a positional there :-) | ||
ohhhh, I see, it's a positional in the prototype | |||
never mind, thanks for clarifying | |||
abra | moritz_, paste.org.ru/?6621un | 14:22 | |
pmichaud | I must've been up too late last night doing a release or something... :-| | ||
moritz_ | abra: you're using an old repository that's not updated anymore | ||
abra: try svn co svn.pugscode.org/pugs/ | |||
lambdabot | Title: Revision 22270: / | ||
pmurias | mncharity: help with the CL PCT/rakudo one :( | ||
moritz_ | abra: and then build that one instead | ||
abra | moritz_, ok, tnx | 14:23 | |
mncharity | pmurias: if I may rephrase your earlier argument, once rakudo can be build using p6 (regardless of whether or not it is), and is usable for large programs, then one could write p6 bootstrap compiler parts on rakudo instead of elf, and p5/CL emitters too, rather than on elf. And you would probably want to use the rakudo IR in that case. so | ||
oh | |||
re :(, ah well. :/ | |||
rakudo_svn | r31211 | pmichaud++ | [rakudo]: spectest-progress.csv update: 165 files, 3377 passing tests | 14:26 | |
pmurias | as writting elf emitters is mostly fighting with the **** ast | 14:27 | |
mncharity: if i replace the pir emitter stuff with perl 6 why would you prefer going the elf root? | 14:29 | ||
mncharity | I will be most interested in watching how development of a non-parrot rakudo emitter goes. The first one ever I suspect. That rx tests didn't get written because rakudo IO wasn't working(?), makes me wonder how it will work out short-term. | 14:30 | |
moritz_ | mncharity: well, I wrote them later on | 14:31 | |
pmurias | mncharity: there is a partial lol code one | ||
moritz_ | mncharity: and TimToady hacked them together as inline tests later on | ||
mncharity | hmm, we should try to find someone to clean up the rx tests then? | ||
14:31
nothingmuch left
|
|||
mncharity | inline tests? | 14:31 | |
pmurias | mncharity: i'll take a walk, and then check if an emitter in perl6 would be possible& | 14:32 | |
moritz_ | mncharity: the old ones were read from a file | ||
14:32
pmurias left
|
|||
moritz_ | mncharity: the new ones have the regexes in the test file | 14:32 | |
mncharity: t/spec/S05-mass/rx.t iirc | |||
14:32
nothingmuch joined
|
|||
mncharity | pmurias: re why go elf root, you might try writing a little p5 emitter in rakudo as an experiment. if it works out, awesome. if not, the "why prefer elf?" reduces to the old "wait for rakudo to work, or pursue other options" question. | 14:33 | |
lol, you had the same idea. I'm quite curious how it works out. I've no clear idea. | 14:34 | ||
well, I strongly suspect how it will go. but would be most delighted to change opinion. | 14:35 | ||
moritz_: re rx.t, ah, awesome. that will come in handy. | 14:36 | ||
Ontolog | Perl6Str is a String, but why does somePerl6Str = substr self, start_pos, end_pos create an error about no such opcode? $S0 = substr self, start_pos, end_pos works fine | 14:37 | |
moritz_ | mncharity: that's what caused the big leap on the charts on rakudo.de/ :) | 14:38 | |
lambdabot | Title: Rakudo - A Perl 6 Compiler | ||
mncharity | lol :) | ||
yes, I always loved the % bump one gets from getting the rx tests working. :) | |||
masak | what happened at those two red dates? | 14:39 | |
how do we avoid it happening again? :) | |||
avar | wrt elf you might want to re-use some of my work on getting kp6 to cpan to get a wider audience:) | 14:40 | |
masak | kp6 is on CPAN? where? | ||
moritz_ | masak: build failures | 14:41 | |
masak | moritz_: ok | ||
moritz_ | masak: how to avoid it? dunno, perhaps an svn bot that allows commits to trunk only when at least a few tests pass? | ||
masak | so one shouldn't do what I do: submit first and run tests later :) | ||
moritz_ | masak: but I don't think it's worth the trouble; somebody broke it, and it's fixed a few hours later. If UTC midnight is inbetween, the graph shows | 14:42 | |
masak: it's not pretty, but not harmful either | |||
masak | true | 14:43 | |
just feels like the bad PR far exceeds the actual harm :) | |||
it's realistic, yes, but that's not always a desirable thing | |||
moritz_ | masak: for PR reasons I can invent an algorithm to only plot data values that we like ;) | 14:44 | |
masak | go right ahead :) | ||
mncharity | avar: re CPAN, yes, but... pick a random p6 feature, and rakudo is vastly more likely to handle it than elf. elf is "collect a set of features needed for p6 compiler development, and go on from there". so it's not really appropriate at the moment for a general p6 audience. | 14:45 | |
moritz_ | next if $fail > $pass; | ||
masak is all for it | |||
avar | masak: kp6 used to be on cpan but I deleted it from there | 14:46 | |
masak | oh, you can do that? | ||
avar | I did a bunch of changes to it to make it behave like a proper CPAN package, then fglock broke cpanness again so the cpan version was out of date | ||
masak | avar: from what I see in actions.pm in Rakudo, kp6 is very usable | ||
avar | It's usable, it just doesn't work as a CPAN distro last I checked | 14:47 | |
masak has been thinking of releasing November on CPAN | 14:48 | ||
but right now there is little sense in doing that, and only extra work | 14:49 | ||
avar | I'm not going to tell you (elf & nov authors) how to maintain your packages but I find it very useful to be able to do `make disttest' on code even if I don't plan to release it since then I know everything is working properly outside my scm working directory. | 14:50 | |
It was certainly helpful with kp6 where the build system was some elaborate mix of shellscripts | 14:51 | ||
masak | avar: thanks, I'll remember that | ||
mncharity | elf's only excuse for existing is demonstrably being able to write a p6 compiler in p6 (narrow dialect) _now_, rather than waiting until rakudo supports it. If one is confident that will be soon, there's still no excuse. | ||
Or if there turns out to be no interest in writing a p6 compiler now, in which case the ability is largely uninteresting. | 14:52 | ||
avar: re disttest, good idea. | 14:53 | ||
oh, right, I was writing wizzier make test... distracted... maybe this evening. | 14:54 | ||
14:54
Front_slash joined
|
|||
mncharity | really have to go. have fun all & | 14:54 | |
14:54
mncharity left,
alester left
14:57
alester joined
14:58
hercynium joined
15:03
Front_slash left
|
|||
Ontolog | This code: $test.split(/X/); always calls .sub 'split' :method :multi('String') even though I have defined .sub 'split' :method :multi('Sub') | 15:04 | |
What is the bifff?!??! | |||
is /X/ a String? | |||
masak | no. | ||
15:04
Front_slash joined
|
|||
Ontolog | so what do you think is happening? | 15:04 | |
masak | I don't know. | 15:05 | |
suggest you lean heavily on .subst, which works. | |||
15:06
TJCRI joined
|
|||
Ontolog | huh? | 15:07 | |
what is the :lex you have there? | |||
masak | hm, it had something to do with $/ working correctly | 15:08 | |
15:08
justatheory joined
|
|||
masak | don't remember the exact details, but I could find the relevant #parrot discussion if you want | 15:09 | |
Ontolog | that's ok i got it to work by copying your :multi | ||
masak | hehe | 15:10 | |
Ontolog | set it to (_,'Sub') | ||
so _ holds self? | |||
is that it? | |||
I am really confused about :multi | |||
I sent an email to perl6-compiler | |||
did you see that? | |||
masak | Ontolog: I don't know. I just work here. | ||
Ontolog: yes, I saw | |||
good email | |||
many interesting questions | |||
Ontolog | lol | ||
thanks | |||
masak | hope someone answers | ||
Ontolog | yeah me too | ||
masak | Ontolog: oh, pmichaud++ did | 15:12 | |
Ontolog | yes i'm reading =) | ||
masak | re 'so _ holds self?': apparently yes :) | 15:13 | |
moritz_ | that's unexpected (at least to me) | 15:15 | |
masak | not altogether unreasonable, though | ||
ever since the dawn of OO, the invocant has been considered the first argument to methods | 15:16 | ||
moritz_ | there's no reason to make it user visible, though | ||
Ontolog | but self is defined implicitly | ||
so is there a need for this? | |||
anyway there are a few places in the code that need changing | 15:17 | ||
because they don't follow the rules about :multi | |||
15:17
zamolxes left
|
|||
masak | Ontolog: do you have an example? | 15:18 | |
Ontolog | yeah, all moritz stuff ;-) | ||
and the patch i submitted today | 15:19 | ||
masak | :) | ||
moritz_ | if it were broken, it wouldn't have worked | ||
Ontolog | not exactly! maybe something will break later on because of it | 15:20 | |
moritz_ | that fact that the tests pass mean that at least one of us understood something wrong | ||
Ontolog | in any case we should be sure to get it right, no? | ||
certainly | |||
moritz_ | any<parrot moritz Ontolog pmichaud> probably ;) | ||
15:21
alester left
|
|||
Ontolog | well i'm sure it's all over the place | 15:21 | |
but looking at pmichauds email | |||
he seems to be pretty clear about how it should work | |||
and i have come across problems because i did it wrong | |||
anyway, i'll fix and test again | |||
masak | Ontolog: it would be interesting if you could provide a short piece of code that breaks because of what you say is wrong being wrong | 15:22 | |
Ontolog | the example i just gave with my own code | 15:25 | |
This code: $test.split(/X/); always calls .sub 'split' :method :multi('String') even though I have defined .sub 'split' :method :multi('Sub') | 15:26 | ||
pmichaud | because :multi('String') restricts the type of the invocant | ||
15:26
cotto_work joined
|
|||
pmichaud | you probably want :multi(_,'String') and :multi(_,'Sub') | 15:26 | |
Ontolog | yes | 15:27 | |
i understand how it works now, i'll fix it in places where its wrong and do it right in the future | |||
anyway time to go to bed (+8 gmt here) | 15:28 | ||
see you all later | |||
masak | Ontolog: sleep well | 15:30 | |
dream sweet MMD dreams :) | |||
moritz_ | ;) | 15:31 | |
15:46
Front_slash left
15:47
Front_slash joined
15:49
xiaoyafeng left
15:52
Exodist joined
15:58
barney left
16:00
Front_slash left
16:02
nipotan_ left
16:21
masak left
16:33
clintongormley joined
16:36
hanekomu left
16:39
Exodist left
16:40
Exodist joined
16:44
jferrero left
16:50
alester joined
16:57
z80ASM left
17:10
rindolf joined
17:13
hanekomu joined
17:56
pmurias joined
17:59
Lorn left
|
|||
pmurias | pmichaud: is the lolcode emitter viewable somewhere? i'm looking how i could my own emitter in | 18:00 | |
18:00
Lorn joined
18:02
apeiron_ joined
18:06
zamolxes joined
|
|||
pmichaud | the HLLCompiler needs some refactoring before its workable, but I can post the emitter | 18:07 | |
and the point of it was to make a humorous lightning talk, not necessary as an example of how emitters should be written :-) | 18:08 | ||
I do plan to add it to the parrot repo, but I need the HLLCompiler changes first | 18:09 | ||
www.pmichaud.com/perl6/lolpast.pir | |||
pmurias | so a custom emitter would need a custom HLLCompiler? | ||
dinner& | |||
pmichaud | not after the refactor | ||
the HLLCompiler just needs a redesign -- the design that is there now isn't as flexible as the one I originally had in mind | 18:10 | ||
18:11
apeiron left
|
|||
moritz_ | ouch, pugs' Test.pm has an is_deeply function that boils down to sub is_deeply($got, $expected, $desc) { is($got.perl, $expected.perl, $desc) } | 18:13 | |
[particle] | sounds like eqv_deeply | 18:15 | |
"eqv_deeply" (a non-existant test function name) | |||
but perhaps more descriptive. heck, i suppose "eqv" alone would do it | 18:16 | ||
moritz_ | actually infix:<eqv> is quite similar, yes | ||
but if eqv internally uses .perl, it has to enforce ordering of hashes | |||
pmurias | pmichaud: i'll wait some more | ||
moritz_ | which normal .perl doesn't | ||
now I'm wondering what to do | 18:17 | ||
it seems wrong to bring that ugly hack to rakudo's Test.pm | |||
a list_eq might be more accurate, and implementable in rakudo | 18:18 | ||
eqv would really rock, but I don't see that anywhere on the horizon | 18:19 | ||
otoh if .perl supported an optional argument to serialize in a canonical order... | 18:20 | ||
pmurias | moritz_: .perl should propably sort the keys if it is optimised for human readability rather than for speed | 18:24 | |
[particle] | like .perl:serialize<lexicographic> | ||
.perl:serialize<insertion> | |||
pmurias | [particle]: insertion is hard | 18:25 | |
18:26
ruoso joined
|
|||
[particle] | that's not my problem, it's up to the implementors ;) | 18:27 | |
moritz_ | [particle]: then you have to become an implementor ;) | ||
pmurias | [particle]: if they implement Hash'es as linked lists it will be your problem ;) | 18:28 | |
[particle] | parrot's Hash is like perl 5's, in that it stores in insertion order | 18:30 | |
moritz_ | perl 5's hashes don't store in insertion order | ||
they store in quasi-random order | 18:31 | ||
18:34
apeiron joined
|
|||
ruoso | Hello! | 18:36 | |
moritz_ | hi ruoso;) | 18:37 | |
ruoso | :) | ||
18:38
iblechbot left
18:41
apeiron_ left
18:55
omichael joined
|
|||
pmurias | ruoso: hi | 18:56 | |
ruoso | hi pmurias | ||
pmurias | shower& | 19:03 | |
ruoso: any ideas for stuff to put in the ROADMAP? | 19:04 | ||
ruoso | Well.. the current roadmap is valid | 19:06 | |
I'd like to get rid of the leaks | |||
but I'm taking a break from that, and got back to implementing map | |||
pmurias | the leaks are a bit annoying, a whole truck-loads of garbage to follow 1..1\nok\n | 19:07 | |
* truck-load | |||
i read and thought about tracing gc a bit, we would have to write a stop-the-world one as concurrent ones are very complicated | 19:10 | ||
19:11
jferrero joined
|
|||
[particle] | if your gc is pluggable, then that's probably ok | 19:11 | |
especially if it's switchable during runtime | |||
moritz_ | you could always emit code for another vm that already does GC | 19:13 | |
or use a C level garbage collector - no idea how good or bad they are | 19:14 | ||
[particle] | llvm? | ||
moritz_ | [particle]: llvm doesn't do garbage collection | ||
[particle] | orly? i thought they had a lib for that | ||
moritz_ | maybe, I just know it's not a "core" feature | 19:15 | |
speaking of llvm - I mailed the llvm dev list about #line support in clang | |||
they said it's being worked on | 19:16 | ||
[particle] | great | ||
icc also has funky #line handling, but only with continued lines and macros iirc | |||
foo(SOME_MACRO(bar), \ | |||
baz); | 19:17 | ||
moritz_ | llvm.org/bugs/show_bug.cgi?id=2788 | ||
lambdabot | Title: Bug 2788 ā Support #line and # [0-9]+ directives | ||
ruoso | pmurias, [particle], I'm a bit ignorant about how to implement trace gc... is it possible to have trace gc on only part of the objects? | 19:19 | |
or is it all-or-nothing? | |||
19:19
avar joined,
kanru left
19:20
avar left
|
|||
[particle] | i suppose you could trace a portion of the objects, but i haven't seen it done | 19:20 | |
19:22
kanru joined
|
|||
pmurias | ruoso: it should be possible to do it only on part of the object withought any problems | 19:25 | |
* objects | 19:26 | ||
19:26
avar joined
|
|||
ruoso | I suppose we need to add something like SMOP_RELEASE and SMOP_REFERENCE for that to work... | 19:26 | |
and stablish a policy around it | |||
as there is for REFERENCE and RELEASE | |||
pmurias | i was thinking of SMOP_MARK | 19:27 | |
ruoso | that would recursively call MARK on every object it references, right? | 19:28 | |
19:28
avar left
|
|||
pmurias | yes | 19:28 | |
ruoso | and store a bit somewhere, saying it is marked, obviously | 19:29 | |
pmurias | yes | ||
ruoso | so the SMOP_MARK for an object that doesn't use trace gc would simply call mark on the objects it references... | 19:30 | |
and not store anything anywhere... | |||
meaning... | |||
pmurias | mark on refcounting objects would be a noop | ||
ruoso | but that no-op still need to call mark on the objects it references | ||
doesn't it? | 19:31 | ||
19:31
avar joined,
zamolxes left
|
|||
pmurias | the scheme i planned is that *all* objects will have a refcount, and the tracing gc would reference an object when it registers it and release it when it can now longer find it using MARK | 19:32 | |
19:33
iblechbot joined
|
|||
pmurias | ruoso: makes sense? | 19:33 | |
ruoso | why do you need the refcount at all? I mean... if you have the trace, it replaces the refcounting entirely | 19:34 | |
19:34
mberends joined
|
|||
ruoso | an alternative gc would mean an alternative to smop_lowlevel.sm0p+smop_lowlevel.h | 19:35 | |
which means a different way of allocating an object and a different way of managing the object.. | |||
pmurias | if i have an object which uses is governed by the gc and i pass it to refcounting code i can't free it unless the refcount falls to zero | ||
ruoso | pmurias, that would be solved by the "no-op SMOP_MARK still calling mark on the referred objects" | 19:36 | |
even if it doesn't store anywhere the mark bit | |||
pmurias | why use refcounting at all then? | 19:37 | |
ruoso | well, because it's already there... | ||
and I still like the determinism refcount gc provides | 19:38 | ||
trace gc needs a lot of work to be efficient... | |||
refcount generate bugs... but after you eliminate the bugs, it's performance is quite linear | 19:39 | ||
pmurias | shower for real& | ||
19:44
rindolf left
19:45
exodist_ joined
|
|||
TimToady | but any p6 program that relies on that determinism is erroneous | 19:45 | |
19:46
abra left
19:48
Exodist left
|
|||
TimToady | the future of computing is multicore and numa. both of those require us to install a certain amount of non-determinacy into the language or it won't scale | 19:48 | |
pmurias | } | 19:51 | |
void smop_s1p_code_mold_init() { | |||
TimToady | and I strongly suspect that ref counting doesn't mix well with the future. can you imagine trying to keep reference counts on web pages? | ||
19:52
lisppaste3 left
|
|||
TimToady | the future will tend instead toward prioritized probabalistic GC | 19:52 | |
19:53
lisppaste3 joined
|
|||
pmurias | TimToady: $! requires some determinism | 19:54 | |
19:56
clintongormley left,
kanru left
|
|||
moritz_ | what's the connection between GC and $!? | 19:57 | |
pmurias | $! requires semi deterministic destruction (it's specced to trigger a gc run on every scope exit) | 19:58 | |
moritz_ | uhm, where? | 19:59 | |
pmurias | if you forget about $! withought checking it, it throws an exception | ||
S04:937 | |||
moritz_ | thanks | 20:00 | |
pmurias | which is very usefull in itself but one of the tricky bitd | ||
* bits | 20:01 | ||
ruoso: you can only free an object once it's refcount is equal to zero and the tracing gc can't find it, so if all objects are traceable the refcounts can't do anything possibly usefull | 20:03 | ||
moritz_ | there are partial refcouting schemes, but I don't think they're particularly successful | 20:04 | |
pmurias | moritz_: pointers | ||
please | |||
moritz_ | ? | 20:05 | |
pmurias | for partial refcounting | 20:06 | |
TimToady | $! is lexically scoped, hence scope exit is not a problem | ||
moritz_ | pmurias: dunno, it's long time since I read about them | 20:07 | |
pmurias | moritz_: do you mean something like in python where the gc removes circural references? | 20:08 | |
moritz_ | pmurias: yes | ||
ruoso | TimToady, while I conceptually agree with that (expect determinism to be erroneous), pragmatically there is a lot of uses for determinism in day-by-day programming | 20:09 | |
and most machines are still only dual core... | 20:10 | ||
TimToady | to be sure, which is why I've been thinking about what "semi-eager" means | ||
20:11
zamolxes joined
|
|||
pmurias | if the cores get too plentifull there's always haskell ;) | 20:11 | |
ruoso | and in my experience, trace gc can lead to massive memory use... | 20:12 | |
but my experience was with java 1.4 | |||
and that gc is indeed horrible | |||
they probably made it better since then... | 20:13 | ||
buu | I'm in a java class right now =[ | 20:14 | |
ruoso | buu, I know your pain ;) | 20:15 | |
buu | It really is painful. It's full of obscure syntax and magic conventions and excessive verbose crap | 20:16 | |
20:16
hanekomu left
|
|||
pmurias | ruoso: re trace gc needing a lot of work to be efficient i feel that with the amount of time wasted fighting memory leaks we would have wrote a good one ;) | 20:18 | |
20:18
cathyal joined
|
|||
pmurias | ruoso: why do some files in src start with smop_ and others don't? | 20:19 | |
ruoso | maybe... the problem is that I don't have the skills to work on an efficient gc... there's a lack of cs books in my shelf | ||
pmurias, plain inconsistency... ;) | |||
ruoso have sc books instead.. (social sciences...) | 20:20 | ||
ruoso . o O ( oops... that would be ss books... the joke wasn't even valid.. sigh... | |||
pmurias | ruoso: you studied social sciences? | 20:22 | |
ruoso | yes... I'm still missing some credits to have the actual diploma... but I had already even presented my final monography | ||
pmurias | why did you choose social sciences instead of CS? | 20:23 | |
ruoso | I looked at the list of disciplines of cs and said... too much math | 20:24 | |
then I went to a college where there are only 64 hours of math in the entire courese | 20:25 | ||
statistics applied to social sciences... which, here in Brazil, mostly means no statistics at all | |||
we almost don't use quantitative analysis | 20:26 | ||
20:26
eternaleye left
|
|||
ruoso | I've actually never used that in any research as a social scientist... | 20:26 | |
pmurias | should i code a hybrid refcounting/tracing gc or do we switch to a pure gc one? | 20:28 | |
ruoso | I'm afraid that a bad trace gc could make smop painfully slow and memory hungry in the very near future | 20:30 | |
20:31
eternaleye joined
|
|||
ruoso | pmurias, but if you are confident it will work, then just go for it | 20:31 | |
pmurias | ruoso: i don't think it will end up being *both* memory hungry and painfully slow ;) | ||
ruoso | heh.. | ||
anyway... I don't actually have the skills to make that decision.. I feel that refcount gc is easier to deal with (even if generates more bugs and requires more debugging) and gets a sane performance and memory usage... | 20:33 | ||
but that's is just a feeling... | |||
not supported by any concrete information... | |||
so if you really think trace gc will be better, just do it... | 20:34 | ||
pmurias | i'll just code a brutish hybrid one for now | 20:35 | |
ruoso | maybe a graph builder to help debugging would be good enough | ||
I've just realised | 20:38 | ||
if we change the SMOP_RELEASE macro to print where it's being called it will already be a huge help... | 20:39 | ||
ruoso need to reboot for a new kernel version... | 20:44 | ||
ruoso later & | |||
20:44
ruoso left
20:49
alester left
20:50
mberends left
20:54
cathyal left
20:56
ispy_ joined
21:00
jferrero left,
jferrero joined,
pmurias left
21:49
araujo left
21:50
iblechbot left
21:52
TJCRI left
22:07
justatheory left
|
|||
pugs_svn | r22271 | moritz++ | [t/spec] updated a fudge message | 22:11 | |
22:35
Auzon joined
22:41
Limbic_Region joined
22:49
exodist_ left
22:58
elmex left
23:01
jferrero left
23:03
omichael left
|
|||
s1n | @seen pmichaud | 23:05 | |
lambdabot | pmichaud is in #perl6. I last heard pmichaud speak 4h 55m 36s ago. | ||
23:10
kanru joined
23:23
justatheory joined
23:24
grindz joined
23:29
grindz left
23:40
kst```` left,
kst```` joined
23:44
alester joined
23:51
ruoso joined
|