»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend! Set by sorear on 4 February 2011. |
|||
dalek | d: be1f10e | larry++ | STD.pm6: parse <[...]> as unbalanced text, not balanced |
00:01 | |
japhb_ | Why is Rakudo so much faster starting a REPL session than executing an empty file or empty -e ? | 00:12 | |
On my system, time (echo | ./perl6) => 0.152s while time (echo | ./perl6 -e '') => 0.930s and time (echo | ./perl6 ./test-empty) => 0.939s | 00:13 | ||
00:21
replore_ joined
00:28
shinobicl_ joined
|
|||
flussence | try running those more than once each | 00:36 | |
00:36
pat____________ joined
|
|||
pat____________ | perl6: my $foo = {*+*} but "+" | 00:42 | |
p6eval | niecza v10-66-g71325b0: OUTPUT«Potential difficulties: $foo is declared but not used at /tmp/yRms4raP4u line 1:------> my ⏏$foo = {*+*} but "+"Unhandled Exception: RoleApply with superclasses NYI at /home/p6eval/niecza/lib/CORE.setting line 0 (CORE infix:<but>… | 00:43 | |
..pugs b927740: OUTPUT«*** Cannot cast from VStr "+" to VCode (VCode) at Prelude.pm line 541, column 5-16» | |||
..rakudo 158bd0: ( no output ) | |||
sorear | hello pat | ||
sbp | std: my $foo = {*+*} but "+" | ||
p6eval | std 580b69a: OUTPUT«ok 00:01 122m» | ||
pat____________ | perl6: my $foo = {*+*} but "+"; say "{~$foo"} || {$foo(3,4)}" | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«===SORRY!===Two terms in a row at /tmp/DOO2l1pQwx line 1:------> my $foo = {*+*} but "+"; say "{~$foo⏏"} || {$foo(3,4)}"Parse failed» | 00:44 | |
..pugs b927740: OUTPUT«***  Unexpected "\"}" expecting "::", term postfix, operator or "}" at /tmp/U2MpORBoAT line 1, column 37» | |||
..rakudo 158bd0: OUTPUT«===SORRY!===Unable to parse blockoid, couldn't find final '}' at line 1» | |||
sbp | /tmp/U2MpORBoAT sounds like a request for Bono to be admitted to Parliament or banished | ||
japhb_ | flussence, I did. Those times were the minimum of 3 for each (and the first in each case was only a few percent worse). | 00:45 | |
flussence | hm, my bad | 00:46 | |
japhb_ | flussence, no worries, it's an obvious braino check. ;-) | ||
pat____________ | sorry had a date | 00:47 | |
benabik: (from 4 hours ago) yes, but the symbol should be any not used | 00:49 | ||
dalek | ecza/serialize: 9c51257 | sorear++ | lib/ (2 files): Fix indirect-name package autovivification |
||
sorear | down to four failing files | 00:54 | |
00:57
pernatiy left,
pernatiy joined,
daniel-s joined
01:17
fod joined
01:18
shinobicl_ left,
shinobicl_ joined
01:25
bady joined
01:27
bady left
01:32
alc joined
01:41
pat____________ left,
orafu left
01:42
pat_______ joined
01:43
orafu joined
01:46
fod left
01:47
cognomore left,
cognomore joined
01:48
donri left
01:49
djanatyn is now known as djanatyn|afl,
djanatyn|afl is now known as djanatyn|afk
01:56
alc left,
benabik joined
01:58
fod joined
01:59
alc joined
02:00
whiteknight left
02:03
orafu left
02:07
orafu joined
02:10
japhb_ left
|
|||
dalek | ecza/serialize: 9f04acf | sorear++ | src/ (4 files): mergeback |
02:33 | |
ecza/serialize: 52fdc3b | sorear++ | / (2 files): Reimplement compilation of subsets |
|||
sorear | perl6: my $foo = Nil; say $foo.perl | 02:35 | |
p6eval | niecza v10-66-g71325b0: OUTPUT«Any» | ||
..rakudo 158bd0: OUTPUT«Nil» | |||
..pugs b927740: OUTPUT«*** No such subroutine: "&Nil" at /tmp/6hsK5Wm3G0 line 1, column 6-14» | |||
sorear | Does my $x mean my Any $x? | 02:37 | |
niecza/master seems to think so | |||
niecza/serialize thinks my $x means my Mu $x = Any | 02:38 | ||
which I thought was correct? | |||
02:43
alester joined
02:51
pat_______ left
02:54
shinobicl_ left
|
|||
sorear | niecza: "foo" ~~ /<sym>/ | 03:05 | |
p6eval | niecza v10-66-g71325b0: OUTPUT«Use of uninitialized value in string context at /home/p6eval/niecza/boot/lib/CORE.setting line 613 (CORE warn @ 2)  at /home/p6eval/niecza/boot/lib/CORE.setting line 21 (CORE Mu.Str @ 12)  at line 0 (ExitRunloop @ 0)  at /home/p6eval/niecza/src/Rx… | ||
sorear | boom | ||
03:06
colomon joined
|
|||
sorear | o/ colomon | 03:06 | |
colomon | \o | ||
sorear | down to 3 failing test files | 03:07 | |
colomon | in serialization? | 03:09 | |
\ | |||
sorear | yes | ||
colomon | \o/ | ||
03:12
thou left
|
|||
sorear | colomon: did you see it's fast now too? :D | 03:14 | |
colomon | no, what? | ||
sorear | the factor-of-3 compile speed regression has been fixed | 03:15 | |
TimToady | sorear++ | ||
colomon | in your branch, right? | ||
sorear | yes | ||
colomon | sorear++ | ||
(because compile time is quite fast on the master branch) | |||
dalek | ecza/serialize: 67f9b80 | sorear++ | src/ (3 files): Fix /(x|y)/ case; tracking :dba immediately while parsing |
03:16 | |
sorear | 2 more | ||
TimToady: what's the current ruling on my $x versus my Any $x versus my Mu $x = Any ? | |||
TimToady | as we last left it, the default value for a container was allowed to be different from its most general type | 03:17 | |
this particularly makes sense for 0-def arrays | |||
but nobody implements defaults yet | |||
but defaults are required for KeyHash semantics in any case | 03:18 | ||
colomon | afk # bed after a long day of chasing a 3-year-old among fantastic steam engines | ||
TimToady | that it, autodelete semantics when the value goes to the default | ||
sorear | TimToady: niecza/serialize thinks my $x; $x = Nil; results in $x === | 03:20 | |
Mu | |||
TimToady | in terms of where we're headed, normal containers will achieve default values much like S02:2274 talks about parameters | 03:28 | |
they just have to be hung on the declaration somehow | |||
dalek | ecza/serialize: 853ca5d | sorear++ | lib/Kernel.cs: Fix class A::B {}; class A {} |
03:30 | |
sorear | TimToady: I'm trying to avoid adding an extra word fo containers | 03:31 | |
for now I'll just switch it back to my Any $x semantics | 03:32 | ||
I didn't intend to change it in any case | |||
TimToady | defaulting containers can mix in | 03:33 | |
sorear | well there's the question of "my $x" versus "my Mu $x" | 03:35 | |
..weird, it looks like niecza/master actually implemetns an inconsistant mixture of both definitions .:) | 03:36 | ||
sorear begins to wonder what the use case for this is | 03:42 | ||
03:42
soh_cah_toa left
03:50
[particle] left
03:51
alvis left,
[particle] joined
03:59
fod left
|
|||
sorear | TimToady: what is the anticipated use case for $x = Nil ? | 04:02 | |
04:14
thou joined,
envi_ joined
04:27
abercrombie left
|
|||
dalek | ecza/serialize: 9ceaa8e | sorear++ | / (7 files): Regularize Any/Mu variable handling It turned out that 'type' was not a necessary part of the public API. Removing it simplified other things. Also fixes coretest; changes Nil to reset variables to Any default. |
04:32 | |
sorear | all spectest regressions should now be fixed. running another run to confirm this... | ||
dalek | ecza/serialize: 2a9f24b | sorear++ | / (2 files): Merge branch 'master' of github.com:sorear/niecza into serialize |
04:34 | |
moritz | good morning | 04:46 | |
sorear | good morning moritz | 05:04 | |
looks like I did cause a fail with my fixes for the other fails | 05:05 | ||
05:05
sftp left
|
|||
sorear | uhm | 05:07 | |
S05-grammar/methods.t and RT73680 look bogus | |||
05:12
orafu left
05:13
orafu joined
05:27
packetknife joined
|
|||
moritz | sorear: what looks bogus about it? | 05:29 | |
a grammar is just a class that also inherits from Grammar | 05:32 | ||
does niecza's Grammar override Mu's .new? | 05:33 | ||
sorear | yeah, I figured that there's no real reason *not* to allow it, even if it won't be very useful | 05:39 | |
dalek | ecza/serialize: f5dc966 | sorear++ | / (2 files): Rename Cursor.new to avoid conflicting with code that pretends grammars are classes |
||
sorear | hopefully now there are no spectest failures | ||
can anyone think of a reason not to merge the branch now? | 05:40 | ||
05:45
lestrrat left
05:46
lestrrat joined
05:47
replore__ joined
05:48
replore_ left,
alester left
05:51
packetknife left
05:56
mtk left
05:59
wtw joined
|
|||
moritz | moon phase? | 06:12 | |
06:22
thou left
06:23
mkramer joined,
mkramer left
06:24
wamba joined
06:26
mj41 joined,
mj41_nb joined
|
|||
tadzik | good morning | 06:28 | |
sorear | morning tadzik | 06:29 | |
sorear sleep | 06:30 | ||
masak | good night sorear, good morning tadzik | 06:32 | |
random question: which concept do you consider more difficult to grok: OO, or testing? | 06:33 | ||
tadzik | en.wiktionary.org/wiki/grok#Verb | 06:34 | |
which variant should I use? | |||
To have an intuitive understanding of, or to fully and completely understand? | |||
masak | meant the latter, but the former sounds fine too. | 06:35 | |
of course, it really means "to drink" :P | 06:36 | ||
06:36
envi_ left
|
|||
tadzik | I don't think I completely understand either :) | 06:36 | |
when we're at intuitively understanding, I think I'm more towards testing | |||
masak | I'm discussing testing with @quietfanatic on Twitter. a fascinating exchange. | 06:37 | |
I'm realizing (again) that my view on testing has changed a lot in the past year, much thanks to CQRS. | 06:38 | ||
for example, @quietfanatic said "my app is a game, so my external API is keystrokes and pixels". a year or so ago, I might have thought "oh, right". now I'm thinking "that just isn't so -- the GUI isn't the API". | 06:40 | ||
anyway, the reason for my original question is that I heard a prospective client say yesterday "I spent five years getting used to the idea of OO -- I hope tests don't take as long to learn. :)" and I realize Pugs (and my first experience with immersive testing) happened six years ago. | 06:44 | ||
moritz: [backlogging #phasers more carefully] the Set operators do have ASCII equivalents. TimToady has said that these are the only ones that get imported by default, and for the Unicode ones you have to 'use Set;' | 06:46 | ||
06:48
mj41_nbx joined
|
|||
Woodi | masak: probably both concepts have few layers... first one for testing is very simple: testing... ok, wil ldo tests :) but first layer of OO is broader i think... and next layers include more teory and more practics so answers can be different. IMO: 'testsing' is simpler, but on your question i will be answer 'testing' becouse there is more unknown behind that... | 06:48 | |
06:51
SHODAN joined
|
|||
masak | I guess both concepts are pretty simple if one counts all the un-learning that needs to be done as negative complexity ;) | 06:52 | |
06:53
koban joined
|
|||
moritz | masak: I found testing much easier to learn, but then I already had much more programming experience | 06:55 | |
masak: I know for sure that testing is easier to explain to my wife | |||
"we put some data in, and see if the program behaves the right way. We can automate that." | 06:56 | ||
masak | OO could be made quite easy to explain too, I think. | 07:00 | |
"a program consists in part of what we want to do, and how we do things. if we separate these, it's easier to change (and protect) the how without affecting the what." | 07:01 | ||
ok, that's quite abstract, I guess. :) | 07:02 | ||
diakopter: what I find the most alarming about search.cpan.org/~lichtkind/Perl6-Do...AQ/FUD.pod isn't that answers have bitrotted or gotten harder to answer, but that *several of the questions are unanswered*, and that module was last updated in 2008. any casual observer can see that, and draw his own conclusions. | 07:04 | ||
in fact, must draw his own conclusions. | |||
"here, let's make a document where we assuage the concerns of people with doubts -- *alarming question* -- lack of answer" | 07:05 | ||
moritz | masak: you've described modularization, not OO | 07:08 | |
at least the way I've learned it, OO needs polymorphism, which doesn't appear in that explanation | 07:16 | ||
masak | also true. | 07:23 | |
I'll try to do better. :) | |||
"we let data and code travel together, in logical bundles called 'objects'. we know early on about an object's capabilities, but which code is actually run depends on the state and type of the object." | 07:25 | ||
that doesn't cover encapsulation, but encapsulation is not an absolute necessity for OO -- as Perl 5 shows. | 07:30 | ||
moritz still finds the explanatioin for testing much simpler | 07:34 | ||
masak | aye. | 07:35 | |
moritz | and the mere fact that the first OO explanation didn't cover some essential OO component is also telling :-) | 07:36 | |
masak | well, it didn't *explicitly* cover it. one could argue that polymorphism is a kind of "changing the how". | 07:37 | |
nom: class A { method foo { say "OH HAI" } }; A.new.foo | 07:44 | ||
p6eval | nom 158bd0: OUTPUT«OH HAI» | ||
masak | nom: class A { method foo($self:D :) { say "OH HAI" } }; A.new.foo | ||
p6eval | nom 158bd0: OUTPUT«===SORRY!===invoke() not implemented in class 'Capture'» | ||
masak | hm. | ||
nom: class A { method foo($self:D:) { say "OH HAI" } }; A.new.foo | |||
p6eval | nom 158bd0: OUTPUT«===SORRY!===invoke() not implemented in class 'Capture'» | ||
masak | D: | 07:45 | |
I'm assuming this isn't expected behaviour. | |||
is it a bug, or a NYI thing? | |||
nqp: class A { method foo($self:D:) { say("OH HAI") }; A.new.foo | 07:47 | ||
p6eval | nqp: OUTPUT«Routine declaration requires a signature at line 1, near "($self:D:)"current instr.: 'nqp;HLL;Grammar;panic' pc 23698 (src/stage2/gen/NQPHLL.pir:6757) (src/stage2/gen/NQPHLL.pm:329)» | ||
masak | ok, that didn't make things clearer :) | ||
moritz | nom: class A { method foo($?CLASS:D:) { say 'oh hai' } }; A.new.foo; A.foo | 07:50 | |
p6eval | nom 158bd0: OUTPUT«===SORRY!===In signature parameter, '$?CLASS', it is illegal to use '?' twigil at line 1, near ":D:) { say"» | ||
08:01
wamba left
|
|||
masak | is there any substance to my intuition that the late binding of OO polymorphism is somehow "later" or looser than that of procedural programming? | 08:02 | |
moritz | well, which procedural programming languages do runtime dispatch? | 08:04 | |
masak | I guess because if you'd want to emulate run-time polymorphism in procedural code, you'd have to write it out explicitly with (the moral equivalent of) a switch statement. and that's a static thing, in code. | ||
moritz: hm, interesting question. I guess the pattern matching in Haskell is a sort of runtime dispatch, for example. | |||
Erlang has similar facilities. | |||
basically anything with powerful enough multimethods has it. | 08:05 | ||
moritz | does either allow dispatch based on the actual type of something, and not just the declared type? | ||
masak | I don't know about types. I keep thinking of fib as the prototypical example, but it just dispatches on values. | 08:06 | |
come to think of it, all multi variants of something in Haskell needs to have the same type signature... | |||
(I think.) | |||
08:07
envi_ joined
|
|||
moritz | the second aspect is that method dispatch looks in different scopes then procedural dispatch | 08:07 | |
so somebody can load another class at runtime, and give me an object of that class, and when I call a method on it, it will dispatch to that newly loaded class | 08:09 | ||
masak | oh yes, scoping. | ||
08:11
ab5tract joined
|
|||
masak | that's what the dot twigil does to attributes and methods -- it switches the scope from being along the 'OUTER' axis to being along the 'nextsame' axis. ish. | 08:11 | |
moritz | I don't see how that could work in a procedural lang, except by emulating method dispatch tables | ||
masak | right. | ||
08:19
dual joined
08:25
mj41_nb left,
mj41_nbx left
08:28
ab5tract left
08:34
alvis joined
08:36
mberends left
08:42
molaf joined
08:52
am0c left
08:56
dakkar joined
|
|||
masak | interesting: perlmonks.org/?node_id=933680 | 09:03 | |
I'm writing a(nother) talk about languages, parsers, and parsing right now. the kind of input this thread gives is very valuable. | 09:04 | ||
especially seeing the incomprehension of the OP as he tries to understand the replies. | |||
ooh, someone recommended a jnthn++ talk, and (naturally) it helped a lot! | 09:06 | ||
tadzik | :) | ||
yeah, noticed that too | |||
masak | many other great recommendations in there too. following up on them now. | 09:08 | |
09:10
ggoebel left
|
|||
masak | oh wow, BrowserUk and ikegami can really push each other's testosterone buttons. | 09:22 | |
moritz | yes, that happens with quite some regularity | ||
which is rather sad, since both usually have very good replies otherwise | 09:23 | ||
masak | yeah. | ||
moritz | it kinda spoils their record :( | ||
masak | whatever made either, much less both, of them think that the status of "glob" as a word was worth a mud-slinging comment war? :/ | ||
it globbles the imagination. | 09:24 | ||
moritz | very globbing indeed | ||
moritz thinks about scraping perlmonks for replies of a depth >= 2, and doing a statistic of how often either or both of them are involved | 09:25 | ||
erm, depth >= 20 | |||
though on the more productive side, I've been pondering a blog post about the different forms of polymorphism | 09:26 | ||
inheritance vs. roles/interfaces vs. duck typing vs. structural typing | |||
masak | ooh | 09:28 | |
mux | vs. parametric polymorphism maybe? | 09:38 | |
moritz | what is parametric polymorphism? :-) | ||
mux | what procedural people call generics ;-) | ||
jnthn | What parametric roles do. | 09:39 | |
mux | jnthn: not really no | ||
moritz | mux: the part that I wanted to describe (not too deeply) doesn't really need generics | ||
I wondered about haskell's typeclasses though | |||
mux | but... that's my favourite form of polymorphism :-P | ||
haskell's type-classes are ad-hoc polymorphism | 09:40 | ||
which is implemented using subtyping in OO languages, at least most of the time | |||
moritz | but decided that they are, in some sense, isomorophic to java's interfaces (people will kill me for that statement, I know) | ||
mux | which is not to say those are equivalent | ||
moritz | mux: ok, I'll make sure to give you a draft of that post to read before publishing it :-) | 09:41 | |
mux | moritz: cool! | ||
masak | mux: what you say sounds intriguing. maybe you should write a blog post, too! :) | ||
mux | masak: what's intriguing about what I say? | 09:42 | |
masak | you seem to have a good grasp of how the different types of polymorphism are represented in various programming paradigms. | 09:43 | |
mux | I just read TAPL ;-) | ||
masak | and also how they (the types of polymorphism) differ from each other. | ||
tadzik | TAPL? | ||
masak | oh, I should totally do that! I started reading it in 2005. | ||
mux | types and programming languages by B. Pierce | ||
masak | tadzik: au++ read it, found exercise at the end saying "implement something", and then went and wrote Pugs. | 09:44 | |
tadzik | :) | ||
mux | it has all you ever wanted to know about lambda calculus (untyped, simply typed, System F...), type system formalisation, subtyping (nominal and structural and possibly bounded), and so on | ||
quite possibly the greatest CS book I ever read | 09:45 | ||
tadzik | wishlist'd | ||
mux | the follow-up (advanced types and programming languages) is very cool too, though it hurt my brain multiple times and there are still stuff in there that I don't get | 09:46 | |
tadzik | search.cpan.org/dist/HOP-Lexer/lib/...rticle.pod is an awesome readt | 09:47 | |
moritz | tadzik: when I read that in the book, I kept thinking "there must be a simpler and more efficient way to do that" all the time | 09:48 | |
tadzik grumbles something about pdf being free and Kindle edition costing more than a paperback | 09:49 | ||
moritz | like, having a single closure that knows about all the lexing regexes, and applies them all in parallel upon request, returning one token | 09:50 | |
tadzik | moritz: I'd like to learn, one day, about writing parsers step-by-step, tokenizing, lexing, building ast. It's quite easy with grammars, sure, but the result is that I can't write a parser in something else than Perl :) | ||
09:51
mkramer joined
|
|||
moritz | tadzik: tokenizing == lexing afaict :-) | 09:51 | |
09:51
mkramer left
|
|||
tadzik | well, that's quite my understanding after reading that article :) | 09:51 | |
moritz | tadzik: I've written a recursive descending parser for a turing-complete toy language with not-too-awful syntax | 09:52 | |
tadzik | was it fun? | ||
moritz | tadzik: it taught me two things: 1) it's not too hard to do and 2) it's so much repetition that I almost went off to write a wrapper that generates a parser from a data spec | 09:53 | |
tadzik | :Y | ||
(: | |||
moritz | but yes, it was fun | ||
tadzik: a part of that code lives on in github.com/moritz/math-expression-.../Parser.pm | 09:54 | ||
09:55
daxim joined
|
|||
tadzik | moritz: typo in #170 :) | 09:55 | |
moritz | tadzik: thanks | 09:57 | |
mux wonders if he should voice his opinion on regexps in here :-P | 09:58 | ||
moritz | mux: please do, it'll be entertaining :-) | 09:59 | |
mux | heh | ||
09:59
replore__ left
|
|||
moritz | tadzik: typo fixed | 10:00 | |
mux | I think they're a great tool for sysadmins, in the command line; but I also think they're not fit for development and I find that they are "only" a very obfuscated domain-specific language taht wuold be better expressed using parsing combinators | ||
moritz | mux: do you find Perl 6 grammars comparable obfuscated and inferior to parsing combinators? | ||
mux | moritz: I don't know perl6 grammars :-( | 10:01 | |
I really should get up to speed with perl6 | 10:02 | ||
moritz | mux: see for example github.com/moritz/json/blob/master...Grammar.pm for an example | ||
that's a complete grammar for JSON | |||
mux | I'm surprised you cannot just write BNF grammars directly in Perl6 :D | 10:03 | |
moritz | in short, grammars are classes. They can contain "special" methods that are basically regexes, and which can call other (regex-)methods by name | ||
mux: it's very much BNF, just with different syntax :-) | |||
mux | moritz: anyways, I find tht more readable that ad-hoc code that would deal with tokenization/etc itself | 10:04 | |
than* | |||
work calls, bbl & | |||
10:17
pnu left
10:19
pnu joined
10:26
ggoebel joined
10:27
leprevost joined
|
|||
masak | aye. Perl 6 grammars are essentially BNF, but for Perl 6. | 10:39 | |
the "for Perl 6" part is quite important. they really fit in well. | |||
tadzik: there's a *lot* of theory behind parsing, all the way up to finite automata theory and beyond. I don't understand much of it yet, but I find that the general principles are quite sane and easy to grasp. writing a decent parser probably isn't that difficult. | 10:42 | ||
doing it well with LTM and stuff seems a little tricky, but also achievable. | 10:43 | ||
snarkyboojum | Perl 6 grammars are essentially parsing expression grammars in Perl 6 :) | ||
10:47
pnu left,
pnu joined
|
|||
masak | one question I haven't really tried to answer yet is "Why does everyone else think it's a good idea to separate out lexing and building an AST, but Perl 6 mixes them together?" | 10:47 | |
10:50
sivoais left
10:51
sivoais joined
|
|||
geekosaur | what everyone else? most haskell parsers combine them | 10:54 | |
I think it's generally done because you get an explosion of states if you do it the usual low level way, so it makes sense to lex first into tokens (using a simpler state machine) and then parse those (which again simplifies the state machine) | 10:55 | ||
...it helps that computers are faster now so it doesn't cost so much to use a higher level approach | 10:56 | ||
cognominal_ | masak, when you conceptually separate lexing and parsing you end up with language like javascript. You can't use keywords as for other usages like variable names. | ||
geekosaur | (yacc-like parsers go back to the pdp11) | ||
masak | cognominal_: good point. | 10:57 | |
oh, I guess lex and yacc pretty much set the standard for a few decades. | |||
geekosaur | yes | ||
cognominal_ | perl solves partially that specific conflict with the use of sigils but the discussion yesterday shows you need some context to recognize a key of a fat arrow and not a keyword. | 10:58 | |
masak | nice to hear that Haskell parsers combine them, too. | ||
geekosaur | go count how many parsers on cpan are basically translations of yacc :) | ||
masak | cognominal_: yes. | ||
cognominal_ | masak, I think this is a case of choice made by tools (yacc, lex) shaping people thought. | 10:59 | |
masak | geekosaur: without having studied lex/yacc too much, I think the way Perl 6/Haskell does it is significantly saner, and I don't currently feel very tempted to study the old way :) | ||
cognominal_: I think so too. just as make had/has a hegemony, so did/does lex/yacc. | 11:00 | ||
geekosaur | as I said, the main davantage of the lex/yacc way was saving memory | ||
much easier to force stuff to fit into a 64K (!) address space | |||
cognominal_ | The infamous Whorf hypothesis could be applied besides languages. | ||
geekosaur | modern parsers use considerably more state storage than that, conveniently we have more than that :) | 11:01 | |
cognominal_ | geekosaur. This is probably true that many tool we are using todays were shaped by constraint irrelevant today. | ||
geekosaur | (also, yacc was itself something of a revolution *at the time*) | ||
in large part because it went to a lot of effort to optimize the state table (again, in the interests of saving memory) | 11:02 | ||
masak | tools surviving the usefulness of their optimizations. interesting. | 11:03 | |
geekosaur | perl has a certain history of busting that particular wall down :) | ||
masak | :) | 11:04 | |
11:05
nek joined
|
|||
cognominal_ | Speaking of automata, I wish someone had explained to me that a NFA was just a DFA on the powerset. When I read that, it made obvious things I had trouble to grasp. | 11:05 | |
mux | cognominal_: you might enjoy the type signature of the 'determinize' function there: code.mumux.org/automata/src/120d63e...ton/NFA.hs | 11:06 | |
haskell is pretty like that ;-) | |||
-- Convert the NFA into a DFA using the powerset-construction algorithm. | |||
determinize :: (Ord a, Ord s) => NFA s a -> DFA (Set s) a | |||
11:07
alc left
|
|||
masak | cognominal_: that is indeed a nice explanation. it also explains why NFAs are sometimes expensive to build. | 11:07 | |
11:07
benabik left
|
|||
mux | the Ord constraints are implementation details | 11:07 | |
cognominal_ | I need to work haskell. I can read it but I have trouble writing it when composing monads. | ||
mux++ # thx for the link | 11:08 | ||
mux | you can do tons of stuff in haskell without monads though | ||
cognominal_: yw; tht code is a bit messy though, I have to warn you | |||
masak | determinize :: (Ord a, Ord s) => NFA s a -> DFA (Set s) a | ||
♥ | |||
mux | heh :D | 11:09 | |
you gotta love when a type signature precisely matches the mathematical formalisation of something | |||
masak | mux: do you really need to nest 'where' clauses like that? can't just just carry on on the same indentation level with just one 'where'? | 11:10 | |
mux | masak: I could, but when the were clause really only pertains to a sub-clause, I like it better to have a sub-sub-clause; this way when you move code around, it has more chances of working | ||
masak | I thought that might be the reason. | 11:11 | |
fair enough. | |||
mux | but I agree this is not very pretty | ||
11:13
pernatiy left
|
|||
tadzik | .u u umlaut | 11:13 | |
phenny | tadzik: Sorry, no results for 'u umlaut'. | ||
tadzik | pff | ||
11:14
koban left
|
|||
tadzik | oh, I need ö anyway :) | 11:14 | |
could've taken Camelia's head | |||
masak | noooooooo | ||
gfldex | nom: my @a = 1,2,3; my @b = <a b c>; say @a Z @b Z "\n" xx * | 11:17 | |
p6eval | nom 158bd0: OUTPUT«1 a  2 b  3 c » | ||
11:17
arx joined
|
|||
gfldex | any way to get rid of the extra space before the NL? | 11:18 | |
11:19
nek left
|
|||
masak | there's extra spaces everywhere because you're .gist-ing a List. | 11:19 | |
nom: my @a = 1,2,3; my @b = <a b c>; say (@a Z @b Z "\n" xx *).join | |||
p6eval | nom 158bd0: OUTPUT«1a2b3c» | ||
gfldex | now there are to few spaces :) | 11:20 | |
masak | nom: say "1 a\n2 b\n3 c\n\n" # there you go | 11:21 | |
p6eval | nom 158bd0: OUTPUT«1 a2 b3 c» | ||
gfldex | tyvm :D | ||
masak | problems. I solve them. | 11:22 | |
nom: my @a = 1,2,3; my @b = <a b c>; for @a Z @b -> $a, $b { say "$a $b" } # this also works | |||
p6eval | nom 158bd0: OUTPUT«1 a2 b3 c» | ||
gfldex | that does work | 11:23 | |
is there a forEach method in List? | |||
masak | nom: my @a = 1,2,3; my @b = <a b c>; .say for map { "$^a $^b" }, (@a Z @b) # this works, too | ||
p6eval | nom 158bd0: OUTPUT«1 a2 b3 c» | ||
masak | gfldex: there's "for", and "map". we've theorized about an "each" pseudo-junction. | 11:24 | |
gfldex | my @a = 1,2,3; my @b = <a b c>; (@a Z @b).each(&say) # looks neat to me | 11:25 | |
masak | actually, it would be say each map { "$^a $^b" }, (@a Z @b), I think. | 11:26 | |
actually, I think it's perfectly possible to *build* the Each type with what nom has already, without necessarily sticking it inside the Rakudo repo. | |||
someone should do that. ;) | |||
gfldex | my @a = 1,2,3; my @b = <a b c>; @a Z @b each .say # may work as an operator too | 11:28 | |
masak | even assuming it did, it'd probably be tigher than Z, so you'd still need the parens. | 11:34 | |
but I'd prefer it to be a listop just like any, all, one, and none. | |||
gfldex | Confused at line 8, near "@a Z @b ea" | 11:35 | |
nom is so easy to confuse these days :) | |||
masak | I take it back about 'each' being implementable outside of Rakudo. I don't see it anymore. | ||
gfldex | can i define the precedence of custom operators? | 11:36 | |
or better is tha speced? | |||
tadzik | b: use MONKEY_TYPING; augment class List { method each(&call) { self.map: { &call(|$_) } } }; (1, 2, 3, 4).each(&say) | 11:37 | |
p6eval | b 1b7dd1: OUTPUT«Method 'each' not found for invocant of class 'Parcel' in main program body at line 22:/tmp/Nnp0sw9Ku5» | ||
tadzik | pff | ||
b: use MONKEY_TYPING; augment class List { method each(&call) { self.map: { &call(|$_) } } }; (1, 2, 3, 4).list.each(&say) | |||
p6eval | b 1b7dd1: ( no output ) | ||
11:38
Psyche^ joined
|
|||
masak | gfldex: yes, and yes. | 11:38 | |
gfldex: I believe it only works in Niecza so far. | |||
gfldex | i cant wait for Xmas! | 11:39 | |
masak | tadzik: right, but the thing with 'each' (as far as I understand it) is that it isn't a method on List taking a closure, but rather (just like junctions) a sub on a list returning an kind of object that when passed as a parameter dispatches to possibly many repetitions of the same call but with different values. | 11:40 | |
tadzik: the main difference with each is that it guarantees sequencing. | |||
tadzik | mhm | 11:41 | |
11:41
Patterner left,
Psyche^ is now known as Patterner
|
|||
moritz | and that it returns something from which you can extract the eigenstates | 11:42 | |
gfldex | nom: my @a = 1,2,3; my @b = <a b c>; (@a Z @b)>>.say; | 11:44 | |
p6eval | nom 158bd0: OUTPUT«ca312b» | ||
gfldex | wut? | 11:45 | |
shouldn't >>. be in order? | |||
jnthn | no | ||
moritz | gfldex: it just returns itse results in order | ||
11:45
MayDaniel joined
|
|||
gfldex | we need each then :) | 11:45 | |
jnthn | The compiler is allowed to parallelize it. | ||
In which case order of side-effects really can't be relied on | 11:46 | ||
masak | pmichaud++ # for randomizing the results of >> | 11:48 | |
jnthn | yeah but >> has the wrong semantics now because the spec went and changed after pmichaud implemented it. | 11:49 | |
masak | not for method calls, I think. | ||
moritz | (but it's not the random part that's wrong) | ||
masak: yes, for method calls too | |||
jnthn | I thought it was the method call part that was wrongest? | ||
masak | oh, where's the dividing line, then? | ||
jnthn needs to read those changes more closely | 11:50 | ||
masak re-reads that spec patch | |||
jnthn | Well, I'll preserve the randomizing order provided I don't have to go out of my way to do it. | ||
That is, if nobody else takes this on. In which case it's up to them. :) | |||
11:51
pernatiy joined
|
|||
jnthn | (If anybody wants to work on it, that would be much appreciated, btw.) | 11:51 | |
11:51
benabik joined
|
|||
moritz | I might, but I have no idea how to do a dispatch that excludes Cool/Any/Mu | 11:51 | |
jnthn | we...huh...what | 11:52 | |
moritz | exactly. | ||
lemme dig out the relevant lines... | |||
jnthn pushes it down his task list some way, as that sounds like something he REALLY can't be bothered with. | 11:53 | ||
masak comes back up out of the spec | |||
I must say I'm not really sold on fallback semantics. | |||
jnthn | Two more words I don't like hearing. :/ | ||
masak | also, I've come to accept Cool and why we have it, but I don't like it becoming special-cased in other features. doesn't feel like a design that scales. | 11:54 | |
moritz | (For this meaning of "responds to", | ||
we ignore any multi candidates defined in Cool, or the negation | |||
above would not work, since Array responds to negation via Cool. | |||
jnthn | Like, in .^methods et al | ||
moritz | from S03 | 11:55 | |
jnthn | We ignore...multi candidates defined in...pfft, so it's not just about method dispatch being affected, it wants the multi-dispatcher to get involved too? | ||
masak | :( | ||
jnthn | OK, I need to look at it much more closely. | ||
moritz | nom: class A { method defined() }; say A.^can('defined')[0] === Any.^can('defined')[0] | 11:56 | |
p6eval | nom 158bd0: OUTPUT«===SORRY!===Missing block at line 1, near "}; say A.^"» | ||
masak takes a skeptical stance to the "duck mapping" idea | |||
moritz | nom: class A { method defined() {} }; say A.^can('defined')[0] === Any.^can('defined')[0] | ||
p6eval | nom 158bd0: OUTPUT«Bool::False» | ||
moritz | nom: class A { method defined() {} }; say Cool.^can('defined')[0] === Any.^can('defined')[0] | ||
p6eval | nom 158bd0: OUTPUT«Bool::True» | ||
moritz has a nasty idea | 11:57 | ||
masak | moritz: ah, a test for "is this method from Cool/Any/Mu?" | ||
moritz | masak: correct | ||
masak cackles evilly | |||
jnthn | Yes but...that won't tell you anything about the multi candidates | ||
masak | true. | 11:58 | |
moritz | nom: class A { method defined() { 42 } }; say A.^can('defined')[0].(A.new) | ||
p6eval | nom 158bd0: OUTPUT«42» | ||
moritz | well, the spec doesn't say it's a normal dispatch, but a weird dispatch | ||
moritz finds excuses | |||
jnthn | weird = slow, of course :) | ||
11:58
eiro joined
|
|||
eiro | hello | 11:58 | |
jnthn | well, slower | ||
masak | heiro! | 11:59 | |
moritz: one slightly disturbing thing is that extensions to Mu/Any/Cool in later Perl 6 spec versions might break previously working uses of >> | 12:07 | ||
moritz | masak: example? | ||
masak: since they are excluded from dispatch, that shouldn't happen | 12:08 | ||
masak: but I agree it's a general problem with this approach, it relies on the absence of methods in certain classes | |||
masak | right. | 12:10 | |
12:15
bluescreen10 joined
12:19
MayDaniel left
12:23
sftp joined
12:26
djanatyn|afk is now known as djanatyn
|
|||
jnthn | I see Parrot folks are planning to merge the green threads branch. Did the sizable slowdown to mandelbrot get resolved? | 12:28 | |
tadzik | they claim so | ||
jnthn | ok | ||
moritz | the last report was that the slowdown decreased to 0.8% | ||
I'll test that :-) | |||
jnthn | OK, that's more acceptable. | ||
Please do | |||
benabik | Hasn't merged yet. Testing welcome. :-D | ||
jnthn | 0.8% should be a fraction of a second's difference. | 12:29 | |
moritz | nom: say 35 * 8e-3 | 12:30 | |
p6eval | nom 158bd0: OUTPUT«0.28» | ||
tadzik | worth it, I suppose | 12:31 | |
12:31
icwiener joined
|
|||
[Coke] | aye. much like the nom rewrite is worth it even though we have regressions. ;) | 12:32 | |
12:33
replore_ joined
|
|||
jnthn | Well, with the small difference that the nom re-write made some things significantly faster, rather than a little slower ;) | 12:33 | |
[Coke] | I was referring more to the "made some things possible that would have been reallly hard otherwise" portion. | ||
12:34
tokuhiro_ joined
|
|||
[Coke] | existing parrot threads have been nigh-useless since... | 12:34 | |
tadzik | they're like the Matrix sequels | ||
you just assume they don't exist | 12:35 | ||
[Coke] | bah. they were perfectly fine action movies. :P | ||
I remember whiteknight trying to get me to rip them out in a release, was probably 2.6 | 12:36 | ||
masak | thought-provoking quotes: en.wikipedia.org/wiki/Object-orient...#Criticism | ||
[Coke] | (but it was a gsoc thing, and the request to merge came in just before the release was due, so I said no. | 12:37 | |
moritz | masak: the one from Paul Graham immediately made the word "Java" pop into my mind :-) | 12:38 | |
tadzik | hehe, how so? :> | ||
masak | moritz: I'm pretty sure that wasn't a design goal of Java... but it might be argued that that was the result, yes. | ||
tadzik | my head reacted quite similarly | ||
masak | moritz: in essence, there are lots of companies out there who want both Java and some sort of programmer herding/replaceability at the same time. | 12:39 | |
colomon | I think OOP is a great tool. But people who try to make it THE paradigm of their programming language are insane. | ||
masak | moritz: though in Sweden, that role seems to be increasingly filled by C#/.NET -- admittedly a slightly nicer solution. | ||
jnthn | I think it's a bit better than "slightly" | 12:40 | |
You can do higher order programming reasonably nicely in C# these days | 12:41 | ||
Admittedly, that probably means the average C# developer gets a headache over a bunch of the stuff I write... :) | |||
moritz wonders if jnthn belongs to the High Order of Programming | 12:42 | ||
jnthn | No, just the ones who studied a functional language at uni, rather than just Java :) | ||
masak | hey! :) | ||
jnthn | hehe :P | ||
masak | though I must admit that I snuck into the functional language lectures at uni, even though I technically shouldn't be there... | 12:43 | |
jnthn | masak: You're not average or typical. :) | ||
masak | I'll interpret that as a compliment. | 12:44 | |
;) | |||
jnthn | :) | 12:46 | |
masak | those were ML lectures, IIRC. a bit too basic, but still nicer than the Java lectures we got in the Engineering track. | 12:49 | |
jnthn | yeah, ML was what I got | 12:53 | |
masak | ooh, ML is written by Milner or Hindley-Milner fame. | 12:54 | |
jnthn | The usual lecturer for the course was the author of "ML for the working programmer", but he was on leave the year I did the course. His stand-in poked a little fun at the book title, but actually did the course pretty well. :) | ||
masak | "the working programmer is currently on leave" *ba dum dish* | ||
mls_ | Hah! Success! nqp passes with most blocks as :blocktype("inline") ! | 12:57 | |
(I know why I don't build compilers as my main job, debugging is really time consuming) | 12:58 | ||
moritz | \o/ | ||
mls_ | Now I've got to do some time measurements and a bit of code cleanup | ||
jnthn | mls_: Is this related to stacked lexpads? | ||
mls_ | It *is* stacked lexpads | 12:59 | |
jnthn | :) | ||
mls_ | lots of push_pad and pop_pad in the generated code | ||
It works really well with the driectaccess patch I did end of last day | |||
week | 13:00 | ||
Thus it doesn't generate find_lex/store_lex for the lexicals it can access directly | |||
benabik | mls_: Thank you for doing a lot of the PCT work I had on my list. Both of those were high on the "should be done" list. | ||
masak | mls_: ooc, which lexicals can it access directly? | 13:01 | |
mls_ | wait until I know if it really makes things faster ;) | ||
all of the ones from the current sub | |||
13:01
daxim left
|
|||
moritz | just be careful about lexicals that can be modified from an eval() | 13:01 | |
13:02
daxim joined
|
|||
moritz | nom: my $x = 3; say $x; eval '$x = 6'; say $x | 13:02 | |
p6eval | nom 158bd0: OUTPUT«36» | ||
mls_ | (except $_, $/, ... because you treat them special in the lexpad) | ||
moritz | that needs to re-fetch the $x | ||
mls_ | that's a different sub | ||
masak | well, a different block, at least. | ||
mls_ | but it uses the same register | ||
masak | what does 'eval "return"' do? | ||
moritz | yes, but the re-fetching needs to happen in the mainline, because a sub we called modified the lexicals | ||
mls_ | the eval changes the correct register | 13:03 | |
moritz | nom: eval 'return' | ||
p6eval | nom 158bd0: ( no output ) | ||
moritz | mls_: that's cool | ||
benabik | moritz: Nope. Parrot uses the register you declared in .lex as the storage location for the lexical. So if you say $P25 is $x, then $P25 is always always the value of $x | ||
moritz | nom: eval 'return'; say 3 | ||
p6eval | nom 158bd0: OUTPUT«3» | ||
mls_ | that's how fetch_lex/store_lex work, they mess with the registers of another context | ||
masak | perl6: sub foo { eval 'return'; say "OH HAI" }; foo | ||
benabik | moritz: (In that routine, of course.) | ||
p6eval | pugs b927740, rakudo 158bd0, niecza v10-66-g71325b0: ( no output ) | ||
masak | \o/ | ||
so, not a different sub. | |||
jnthn | eval implies a block not a sub. | ||
buubot_backup | jnthn: ERROR: Illegal declaration of anonymous subroutine at (eval 20) line 1. | ||
mls_ | parrot sub | 13:04 | |
masak slaps buubot_backup | |||
benabik | buubot_backup: shush | ||
buubot_backup | benabik: Couldn't match input. | ||
jnthn | buubot_backup: THOU SHALT NOT SPEAK UNLESS SPOKEN TO, BOT | ||
buubot_backup | jnthn: Couldn't match input. | ||
masak | buubot_backup: Could you match inpu? | ||
buubot_backup | masak: Couldn't match input. | ||
masak | buubot_backup: what couldn't you match? | ||
buubot_backup | masak: Couldn't match input. | ||
mls_ | anyway, I'll do some benchmarks now... | ||
masak | buubot_backup: you could do everything, except... | ||
buubot_backup | masak: Couldn't match input. | ||
mls_ | (I hope things get faster, otherwise it a week's work was useles...) | 13:05 | |
jnthn | mls_: It *should* help plenty (more) | ||
benabik | mls_: Avoiding calling subs and find/store_lex should just be doing less work. | ||
masak | jnthn: admittedly, it uses a fixed prefix 'eval ', which is still better than purl... | ||
jnthn | One of the things that the optimizer does is inline basic blocks. | ||
That doesn't declare lexicals | 13:06 | ||
It makes a notable difference | |||
mls_ | yes, I saw that | ||
jnthn | Since it saves multiple GC-ables | ||
benabik | That inlining can still avoid creating the lexpad. | ||
jnthn | (the CallContext and a Continuation) | ||
mls_ | I still have to allocate one PMC though, the lexpad | ||
jnthn | benabik: Yes, true. It's worth doing even with the mls++ patch. | ||
They're complementary :) | |||
mls_ | blocktype inline doesn't create the lexpad if it's not needed | 13:07 | |
benabik | mls_: !!! | ||
mls_ | (not needed == no lexicals declared) | ||
jnthn | Oh :) | ||
Wow :) | |||
mls_ | (that was an easy optimization) | 13:08 | |
jnthn | Smart. :) | ||
mls_ | I still have a bit of a problem with contextuals, they use find/store_dynamic_lex | ||
Now, find/store_dynamic_lex ignores the current lexpad, I don't know what the correct semantics should be in this case | 13:09 | ||
Hmm, that souned confusing, let's try again | |||
currently find_dynamic_lex starts with with lexpad of the caller context | 13:10 | ||
I don't know if I should change that to "skip the current lexpad" | |||
as a sub now has a chain of lexpads | |||
(For now I've just added two new ops: find/store_dynamic_lex_current to make contextuals work) | 13:11 | ||
(cause with $/ et al we don't need to skip the current pad) | 13:12 | ||
anyway, benchmarks first ;) | |||
jnthn | For contextual I think it's tied to scope depth | 13:13 | |
And you've just changed the unit of scope. | |||
So yes, it'd be skip the current lexpad, not skip all lexpads (scopes) in the current context. | |||
13:17
mtk joined
|
|||
mls_ | afk for a while... | 13:17 | |
13:20
am0c joined
|
|||
benabik | Is there a particular reason the failing tests in NQP haven't been marked TODO? | 13:24 | |
moritz | benabik: there should only be regex tests failing, and there the answer is probably that we thought the regex engine was still in too much flux | ||
(unless you are missing ICU; we haven't gone the lengths to skip ICU-dependent tests in NQP yet) | 13:25 | ||
benabik | moritz: Have ICU, only getting failures in qregex. I'm just tired of going "oh yes, it's those tests again." ;-) | ||
moritz | benabik: feel free to TODO them if they annoy you | 13:26 | |
PerlJam | so once green threads are available in parrot ... who is planning to use them in rakudo/nqp ? | ||
masak | benabik: if it's possible to TODO them in such a way to show that they're *regressions*, that's good too. | ||
masak is not too hot about the practice of regressing and then just slapping TODO on things | 13:27 | ||
benabik | masak: `:todo<regression>` ? | ||
masak | somethinglikethat | ||
benabik | masak: For me "todo" means "these tests are expected to fail right now". I also note that I'm getting a pile of passing TODOs as well. :-D | 13:28 | |
masak | masak: I'm fine with that definition of TODO... it's just that I don't think that's sufficient reaction to a regression. | 13:29 | |
unless it's a completely private project with no downstream users, I guess. | |||
13:30
im2ee joined
|
|||
im2ee | Hi! o/ | 13:31 | |
masak | hi im2ee | 13:32 | |
13:33
wtw left
13:41
mtk left
13:42
JimmyZ joined
13:46
SHODAN left,
drbean left
13:47
drbean joined,
mtk joined
13:53
GlitchMr joined
13:56
thou joined
14:02
daniel___ joined
|
|||
benabik | Huh. qregex test failing hid from me the fact that the p6regex test hangs. Excellent. :-( | 14:03 | |
moritz | oh, that might be my fault | 14:04 | |
14:04
MayDaniel joined
|
|||
benabik | Uh, it hangs after emitting the done testing line? | 14:04 | |
Hm. | |||
benabik hopes this isn't due to green_threads. | 14:05 | ||
moritz | nope | ||
I think I've seen that on top of master too | |||
14:05
envi_ left
|
|||
benabik | I'm somewhat confused why it hangs at the end of the script. | 14:06 | |
14:07
SHODAN joined
|
|||
moritz | benabik: it might have started to hang around commit 05affcfdbebee1f74faf63969ee6d1b393b248f3 | 14:07 | |
not sure if that's any help to you | 14:08 | ||
benabik | moritz: I'll look into it after my test this afternoon. | ||
dalek | p: 1f3891e | moritz++ | t/p6regex/01-regex.t: work around hang of p6regex tests at end of file |
14:12 | |
moritz | benabik: this is somewhat ugly... | ||
benabik | moritz: That's one way to "solve" it... | 14:13 | |
moritz | benabik: I remember that rakudo had a similar hack, because the final teardown caused segfaults back in the days | 14:14 | |
jnthn | Could be worth attaching the debugger to see where it's hanging. | 14:15 | |
Or run it under the debugger and break when it hangs | |||
benabik | jnthn: That was on my todo list, yes. | 14:16 | |
jnthn: But I should be studying for a test right now, and debugging takes much longer than mucking with TODOs. :-D | |||
jnthn | :) | ||
mls_ | might be a runloop problem, i.e. some finalize ops missing | 14:17 | |
14:22
cognomor` joined,
cognomore left
14:24
cognomor` left,
cognomor` joined
|
|||
moritz | nom: say so 'a' ~~ /<?alpha>/ | 14:29 | |
p6eval | nom 158bd0: OUTPUT«Bool::True» | ||
dalek | p: fa9f991 | moritz++ | src/QRegex/Cursor.nqp: try to implement <before> It seems a bit wrong since it never captures, but it does look-ahead |
14:36 | |
jnthn | afk...vaguely work related beer drinking opportunity arose & | ||
moritz | have fun jnthn | ||
jnthn | L( | ||
*:) | |||
probably back in a few hours | |||
moritz | phenny: ask pmichaud to please review github.com/perl6/nqp/commit/fa9f99...20f76fe6d9 when he has a spare minute. My first regex built-in, so I'm not sure at all if that's the right approach | 14:37 | |
phenny | moritz: I'll pass that on when pmichaud is around. | ||
masak | moritz: nice! | 14:38 | |
moritz | I figured it can't be too hard, since look-ahead is a *very* simple operation | 14:39 | |
dalek | nqp: 9ce492d | benabik++ | t/p6regex/01-regex.t.old: | ||
nqp: Remove t/p6regex/01-regex.t.old | |||
nqp: | |||
nqp: It's not being used and if someone wants to refer to it, it's still | |||
nqp: available in the git history. | |||
14:39
dalek left
|
|||
moritz | you just do a normal regex match, and "forget" to bump the position | 14:39 | |
14:39
dalek joined,
ChanServ sets mode: +v dalek
|
|||
masak | apparently :) | 14:39 | |
and since 'tis all immutable Cursor objects, it's a bit like doing an experimental branch in git, I guess... | 14:40 | ||
benabik | Did dalek get lost mid-commit? | ||
moritz | benabik: kicked for flodding, I'd guess | ||
masak | aye. | ||
benabik | Oh. | ||
moritz | benabik: never mind, not your fault | 14:41 | |
masak | in such a case, dalek always emits five lines and then gets kicked. | ||
benabik | Well the NQP test suite now completes for me, which is useful for noticing bad tests are actually bad. If anyone disagrees with the set of TODOed tests, that's a useful data point. :-D | ||
14:41
SHODAN left
|
|||
moritz | masak: I'm not sure how immutable cursors actually are | 14:41 | |
masak: the qregex code is full of things like $cur.'!cursor_pass'($pos, $name) | 14:42 | ||
where the return value is ignored | |||
14:42
am0c left
|
|||
moritz | if the cursor was immutable, why would one do a method call and throw away the result? | 14:43 | |
masak | I think it's "immutable for all you know". :P | ||
which is a kind I like. | |||
moritz | "just don't look carefully" | ||
IME it creates a new cursor for each branch in an alternation, for each backtracking etc. | 14:44 | ||
so for all the things that look like they might need one | |||
hm, wait, that's just a guess | |||
masak | but it sounds sane. | 14:46 | |
14:46
cognominal joined
|
|||
masak | technically, for an alternation you'd only need to create one new branch. | 14:46 | |
but it might be nicer from a model perspective to create both in nqp, I dunno. | 14:47 | ||
moritz | my mental model is "each point where a decision is made that could be revised later on, we create a list of cursors, one for each possible choice" | ||
s/each/at each/ | 14:48 | ||
taking a branch in an alternation is such a choice | |||
masak | nod. | ||
moritz | not sure how closely qregex follows that model | ||
14:49
cognominal_ left,
cognomor` left
|
|||
masak | the PGE model was "push to @ustack and do a local_branch for each possible future backtrack-oid choice": github.com/masak/gge/blob/master/l...xp.pm#L586 | 14:50 | |
moritz | masak: how was @ustack scoped? | 14:51 | |
masak | globally. | 14:52 | |
[Coke] | question: the setting is currently compiled as a single unit why? so they all have the same OUTER? | ||
masak | moritz: well, global for the match process. | ||
[Coke]: because it's a single unit. | |||
moritz | [Coke]: we've been discussing a staged setting, but it'd need a good, clear cutting point | 14:53 | |
[Coke] | masak: I understand it's a single unit, but why does that matter to parrot is the part I'm trying to tease out. | 14:55 | |
but, meetings. | 14:57 | ||
14:57
daniel___ left
14:59
donri joined
|
|||
masak | [Coke]: the mainline code conceptually has the setting as its OUTER. so it needs to be a single unit. | 15:00 | |
JimmyZ introduces Perl 6 to his new colleague, and his colleague likes it very much | |||
moritz | masak: I'm not convinced. The REPL has code to copy two nested scopes into a single scope. That might be reusable for having nested settings appear to be a single one | 15:01 | |
masak | I thought what the REPL did was descend into new inner scopes all the time... | 15:05 | |
moritz | it'd leak memory like hell if it did | ||
masak | I'd always wondered about that ;) | 15:06 | |
moritz | like, at least one lexpad per line | ||
masak | right. | 15:07 | |
15:07
envi_ joined
|
|||
masak | grammars and thread safety -- where do I put the variables that pertain to my ongoing grammar match, if I don't want them to collide with other matches going on concurrently? | 15:08 | |
moritz | in the cursor :-) | ||
not only for thread safety | 15:09 | ||
consider /foo { 'a' ~~ /./ }/ | |||
you have to take care that the inner match doesn't mess up the outer one | |||
so you'd better not use globals :-) | |||
masak | aye. | 15:14 | |
oh, can I store things in my immutable Cursor? great! | |||
moritz | in your immutable-ish Cursor, yes | 15:15 | |
masak | moritz: your example doesn't apply, since it's not a grammar that's re-entrant there. | ||
moritz | masak: then modify it accordingly *handwave* | ||
masak | but point taken. | ||
moritz | the cursor also has to cache the Match object, otherwise the Match'es .ast goes lost | 15:17 | |
sorear | hello #perl6 | ||
masak | sorear! \o/ | 15:18 | |
moritz | hello sorear. How (im)mutable are your cursors? | ||
colomon | o/ | 15:19 | |
niecza: say Array.new(4, 5, 6).STR | 15:20 | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«Unhandled Exception: Excess arguments to CORE List.new, used 1 of 4 positionals at /home/p6eval/niecza/lib/CORE.setting line 0 (CORE List.new @ 0)  at /tmp/tx6oYsO2JQ line 1 (MAIN mainline @ 1)  at /home/p6eval/niecza/lib/CORE.setting line 2193 (COR… | ||
colomon | STUPID CAPS LOCK | ||
niecza: say Array.new(4, 5, 6).Str | |||
p6eval | niecza v10-66-g71325b0: OUTPUT«Unhandled Exception: Excess arguments to CORE List.new, used 1 of 4 positionals at /home/p6eval/niecza/lib/CORE.setting line 0 (CORE List.new @ 0)  at /tmp/QPiyR8e_2h line 1 (MAIN mainline @ 1)  at /home/p6eval/niecza/lib/CORE.setting line 2193 (COR… | ||
colomon | niecza: say [4, 5, 6].Str | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«4 5 6» | 15:21 | |
colomon | niecza: say (4, 5, 6).list | ||
moritz | niecza: say Array.new((4, 5, 6)).Str | ||
sorear | moritz: when a Cursor is presented to Perl6-space, it's immutable | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«Unhandled Exception: Excess arguments to CORE List.new, used 1 of 2 positionals at /home/p6eval/niecza/lib/CORE.setting line 0 (CORE List.new @ 0)  at /tmp/9NLV4GIrlk line 1 (MAIN mainline @ 1)  at /home/p6eval/niecza/lib/CORE.setting line 2193 (COR… | ||
niecza v10-66-g71325b0: OUTPUT«4 5 6» | |||
moritz | niecza: sub f($x) { say $x }; f((1, 2, 3)) | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«1 2 3» | ||
sorear | moritz: however it holds a back-reference to the RxFrame, which is mutable and holds the ast field, as well as backtrack control info | 15:22 | |
so $¢.commit will DWIM (or would if commit were implemented) | |||
colomon | gang, t/spec/S32-array/create.t -- should Array.new(4, 5, 6) work? list(4, 5, 6) ? Those are both syntaxes I don't ever recall seeing before. | ||
moritz | std: list 1 | 15:23 | |
sorear | "it's in roast, so yes" | ||
p6eval | std be1f10e: OUTPUT«ok 00:01 119m» | ||
moritz | colomon: I'm pretty sure the 'list' listop is in the specs | ||
colomon | std: dsfsdfs(1, 2, 3) | ||
p6eval | std be1f10e: OUTPUT«===SORRY!===Undeclared routine: 'dsfsdfs' used at line 1Check failedFAILED 00:01 121m» | ||
sorear pops back out | 15:24 | ||
colomon | niecza: say (4, 5, 6).list.Str | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«4 5 6» | ||
[Coke] | (setting is the single outer unit) - pbc_merge fails to address this? | 15:26 | |
moritz | I'm pretty sure it does | ||
masak | colomon: I think I've seen Array.new(4, 5, 6) a few times. | 15:27 | |
though how it works bootstrap-ly I have no idea. | |||
moritz | it's positionals all the way down :-) | 15:28 | |
masak | :) | 15:29 | |
benabik | pbc_merge just puts the subs and constants together in one file. Since P6 has more complex ideas about namespaces and scoping than parrot, you'd have to add more code to tie everything together at that level. | 15:30 | |
JimmyZ | perl6: sub f(:$x, :&x) { say $x }; f(:x(min(6,2,3)), :x(1, 2, 3)) | ||
15:30
mj41 left
|
|||
p6eval | niecza v10-66-g71325b0: OUTPUT«===SORRY!===Undeclared routine: 'min' used at line 1Potential difficulties: &x is declared but not used at /tmp/JqYiXINZ05 line 1:------> sub f(:$x, :⏏&x) { say $x }; f(:x(min(6,2,3)), :x(1, Unhandled Excepti… | 15:30 | |
..pugs b927740: OUTPUT«123» | |||
..rakudo 158bd0: OUTPUT«1 2 3» | |||
moritz is kinda surprised that it doesn't blow up | |||
JimmyZ | perl6: sub f(:$x, :$x) { say $x }; f(:x(min(6,2,3))) | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«===SORRY!===Undeclared routine: 'min' used at line 1Potential difficulties: Useless redeclaration of variable $x (see line 1) at /tmp/8B3kFxpiJZ line 1:------> sub f(:$x, :$x⏏) { say $x }; f(:x(min(6,2,3)))Un… | ||
..pugs b927740: OUTPUT«2» | 15:31 | ||
..rakudo 158bd0: OUTPUT«===SORRY!===Redeclaration of symbol $x at line 1, near ") { say $x"» | |||
15:31
MayDaniel left,
simcop2387 left
|
|||
JimmyZ thinks it's a bug | 15:31 | ||
masak | it is. | ||
such a signature with two named parameters save for the sigil is illegal. | 15:32 | ||
I remember moritz and me spec'ing the rules for that. | |||
moritz | std: -> :$x, :&x { } | ||
p6eval | std be1f10e: OUTPUT«ok 00:01 122m» | ||
masak | STD is lagging :) | ||
JimmyZ | std: -> :$x, :$x { } | ||
p6eval | std be1f10e: OUTPUT«Potential difficulties: Useless redeclaration of variable $x (see line 1) at /tmp/FKzWHzu2P5 line 1:------> -> :$x, :⏏$x { }ok 00:01 121m» | ||
masak | that's too lenient, if you ask me. | ||
it's fine for lexicals in general, but not for a siggie. | 15:33 | ||
JimmyZ | perl6: sub f(:$x, :%x) { say $x }; | ||
p6eval | pugs b927740, rakudo 158bd0: ( no output ) | ||
..niecza v10-66-g71325b0: OUTPUT«Potential difficulties: %x is declared but not used at /tmp/UvwYaQgjMv line 1:------> sub f(:$x, :⏏%x) { say $x }; &f is declared but not used at /tmp/UvwYaQgjMv line 1:------> sub f⏏(:$x, :%x) { say $x };»… | |||
masak | binding is serious business :) | ||
moritz | and signatures are complex beasts | 15:34 | |
JimmyZ | niecza has this bug too | ||
15:34
simcop2387 joined
15:42
preflex left
15:43
preflex joined
15:50
cognominal_ joined
|
|||
moritz | masak: I think you were referring to 60657ebc7f9d9410a7fcc3769fd268fcad732127, which is only about positional parameters :/ | 15:50 | |
JimmyZ | nom: class A { multi fun() { say 'zero' ; }; multi sub fun(2) { say 'two'; }; method hi() { fun(); fun(2); } }; my A $a .=new; $a.hi(); | 15:51 | |
p6eval | nom 158bd0: OUTPUT«zerotwo» | ||
masak | moritz: no, I'm referring to S06:705 | 15:52 | |
moritz: the commit you refer to is a precursor to what ended up there. | 15:53 | ||
15:53
MayDaniel joined
|
|||
moritz | ok :-) | 15:53 | |
15:54
cognominal left
|
|||
masak decommutes | 15:59 | ||
PerlJam | masak: whenever you decommute, does that mean you are no longer commutative? | 16:02 | |
daxim | perl6: (masak ⊕ masak).say | 16:05 | |
p6eval | rakudo 158bd0: OUTPUT«===SORRY!===Confused at line 1, near "(masak \u2295 m"» | ||
..pugs b927740: OUTPUT«decodeUTF8': bad data: '\8853'***  Unexpected "\8853" expecting bare or pointy block construct, ":", identifier, operator or ")" at /tmp/SN20dnC73O line 1, column 8» | |||
..niecza v10-66-g71325b0: OUTPUT«===SORRY!===Confused at /tmp/rZppPdK7eE line 1:------> (masak ⏏⊕ masak).sayUndeclared routine: 'masak' used at line 1Parse failed» | |||
tadzik | nom: <masak ⊕ masak>.say | 16:06 | |
p6eval | nom 158bd0: OUTPUT«masak ⊕ masak» | ||
benabik | daxim: masak knows perl6, but perl6 doesn't know masak. | ||
.oO( mask may commute, but knowledge doesn't? ) |
16:07 | ||
*masak, stupid autocorrect | |||
16:08
am0c joined
16:09
tokuhiro_ left
|
|||
JimmyZ | nom: sub f(:&x) { say &x }; f(:x(min)) | 16:11 | |
p6eval | nom 158bd0: OUTPUT«Nominal type check failed for parameter '&x'; expected Callable but got Num instead in sub f at /tmp/WYVvIUDWfr:1 in block <anon> at /tmp/WYVvIUDWfr:1 in <anon> at /tmp/WYVvIUDWfr:1» | ||
donri | alla känner apan men apan känner ingen | ||
moritz | phenny: se "apan"? | 16:12 | |
phenny | moritz: "monkey" (se to en, translate.google.com) | ||
moritz | ah right, "ape" | ||
JimmyZ | why expected Callable but got Num ? | ||
moritz | JimmyZ: because you called min, not returned a reference to it | 16:13 | |
moritz anticommutes | |||
JimmyZ | moritz: thanks | ||
benabik | nom: sub f(:&x) { say &x }; f(:x(&min)) | ||
p6eval | nom 158bd0: OUTPUT«Sub.new()» | ||
JimmyZ | nom: sub f(:&x) { say &x(5, 3,6) }; f x => &min | 16:16 | |
p6eval | nom 158bd0: OUTPUT«3» | ||
JimmyZ | nom: sub f(:&x, |$c) { say &x(|$c) }; f x => &min, 5,2,3 | 16:17 | |
p6eval | nom 158bd0: OUTPUT«2» | ||
16:18
wolfman2000 left
16:29
JimmyZ left
16:50
pernatiy left
|
|||
TimToady | masak: I'm thinking of changing the macro placeholder syntax to something more like $term:ast($x) to indicate the desired category | 16:53 | |
possibly it wants a new sigil | |||
moritz | .u § | 16:54 | |
phenny | U+00A7 SECTION SIGN (§) | ||
TimToady | §term:ast($x) | ||
you beat me to it :) | |||
moritz | that one's still free :-) | ||
TimToady | I'm also rethinking whether we really need a no-non-Latin-1-by-default rule | 16:55 | |
or whether that's just a sop to the Unicode-haters | 16:56 | ||
and a relatively meaningless one | |||
16:56
risou is now known as risou_awy
|
|||
TimToady | I'm not sure that built-in types like sets should be deprived of their natural operators by default | 16:57 | |
and after helping with the Unicode chapter in camel4, I see that Perl is getting starting to get a reputation for being the best langauge for Unicode | 16:58 | ||
and I'd hate to work against that with an artificial rule | |||
with a new sigil, we could remove the 'ast' and just have §term:($x), which is pretty concise | 16:59 | ||
and then you can have §infix:($y) or §parameter:($p) | 17:00 | ||
we'd have to smarten the parsers to allow such a substitution at any proto in the grammar | 17:01 | ||
(not that parameter is currently parsed with a proto...) | |||
sjohnson | hi | 17:02 | |
tadzik | ( ° ー°) <( hi sjohnson! ) | 17:03 | |
17:03
Je joined
|
|||
TimToady | § looks too much like $ maybe, so ¶term:($x) might be better | 17:03 | |
sjohnson | haha | ||
tadzik: yo, how's life | |||
tadzik | pretty cool. I got a day off today, feels good | ||
well, more like "I decided not to go to my classes", but still :) | 17:04 | ||
sjohnson is envious | |||
TimToady | or ¤term:($x) | ||
tadzik | maybe €term | ||
or <the-pound-sign> | |||
TimToady | I kinda like ¤, since it's generic currency | ||
and it looks like a "hole" :) | 17:05 | ||
17:05
dakkar left
|
|||
TimToady | actually, it looks like a round peg in a square hole :) | 17:05 | |
PerlJam | What's the criterion of choice for these characters? | 17:06 | |
(they have no mnemonic value or anything to me) | |||
TimToady | well, I just mentioned a couple of possibilities | 17:07 | |
something that is generically fungible is like a macro parameter | |||
and the placeholders have already been called holes | 17:08 | ||
and placeholders are like square pegs in round holes, or vice versa | |||
I wasn't just saying those things randomly... :) | 17:09 | ||
it's also rather visually distinct from anything else | |||
and being up in the Latin-1 range, unlikely to be used accidentally, like $¢ | |||
PerlJam | there's no unicode char that's a square circumscribed by a circle? | 17:10 | |
TimToady | well, there's ⌼ | 17:11 | |
but that's the other way around | |||
㉤ | 17:12 | ||
17:12
ksi joined
|
|||
benabik | .u ㉤ | 17:12 | |
phenny | U+3264 CIRCLED HANGUL MIEUM (㉤) | ||
TimToady | but things in the Latin-1 range are usually a bit handier on the compose key, or the vim digraphs | 17:13 | |
ashleydev | .u ⽊ | 17:18 | |
phenny | U+2F4A KANGXI RADICAL TREE (⽊) | ||
masak | TimToady: aww, but I'd just started to see the merits of the ugly {{{ $ast }}} syntax! :/ | ||
(namely, if you ever want to nest quasi blocks, it's indispensible) | 17:19 | ||
17:22
Je left
|
|||
TimToady | not at all | 17:23 | |
masak | oh right, it falls out of lexical lookup, I guess. | ||
no, wait. | |||
you still have to specify to *which* quasi the placeholder belongs. | 17:24 | ||
17:24
SHODAN joined
|
|||
TimToady | ¤term:( quasi { stuff } ) seems straightforward | 17:24 | |
masak | because it's not at all a given that what's inside the {{{ }}} is a single variable. | ||
er. | |||
TimToady | that's why its () | 17:25 | |
*it's | |||
so you can have an expression in there | |||
masak | I feel we're talking past each other a bit. | ||
quasi { {{{$a}}} ... quasi [ {{{$b}}} [[[$c]]] ] } | 17:26 | ||
please show this with the new syntax. | |||
PerlJam | TimToady: is the category mandatory or just for "hinting" ? | 17:27 | |
TimToady | it would be mandatory | 17:28 | |
masak | yes. | ||
grrr, and we're supposed to get *fewer* non-ASCII symbols in core Perl 6, not more... | 17:29 | ||
TimToady | sez hoo? | ||
PerlJam | under the current universe categories are implicit by where the macro shows up in the parse? | ||
masak | well, the FUD FAQ from 2008 sez it, for one... :) | ||
TimToady | I'm not worried about FUD anymore | 17:30 | |
masak | my point wasn't really about FUD, but about ASCII. | ||
TimToady | irclog.perlgeek.de/perl6/2011-10-27#i_4623544 | ||
masak | oh, didn't see that when I skimmed the backlog. | 17:31 | |
TimToady | it was part of what was addressed to you :) | ||
masak | I see :) | ||
17:32
fsergot left
|
|||
PerlJam | TimToady: do you think writing macros will be rampant in Perl 6 or mostly just the use of macros? | 17:32 | |
masak | I can only give anecdotal counterarguments. most people think it's a PITA to enter non-ASCII (or, more exactly, non-keyboard) characters in their editor. | ||
I'd hate for that to hinder macro adoption. | |||
TimToady | macros should be a pita, in some sense :) | ||
masak | I definitely don't buy that argument. | ||
TimToady | we don't want people overusing htem | 17:33 | |
masak | "hey, we put this PITA character here to deter you. good luck finding how to type it!" | ||
TimToady | yup | ||
PerlJam | TimToady: the thing is, I expect people will want to use macros quite a bit. | ||
masak | I'd suggest Lisp's prefix:<,> except I see that it doesn't really fit in Perl 6. | ||
PerlJam | (use them for Good I mean :) | ||
TimToady | and then maybe they'll be dragged kicking and screaming into the 21st century | 17:34 | |
PerlJam | or just complain about having to type the funny characters | ||
TimToady | let 'em complain | ||
they can always write their own ¤sigil macro | 17:35 | ||
PerlJam | feels like an embedded second system | 17:36 | |
TimToady | they can write a 'use ASCII-ONLY-DAMNIT;' module if they want | ||
masak | TimToady: my vote is on something easy-to-type and entirely innocuous, such as keeping {{{ }}}, or an all-caps identifier, like AST($x) | ||
TimToady | won't fly, unless you only ever want terms | ||
PerlJam | masak: I'd be fine with a unicode sigil as long as it's not too big of a pain to type or (more importantly) discover how to type | 17:37 | |
masak | I'm having enough trouble figuring out how to implement only terms :/ | ||
TimToady | nobody will hold you to implementing ¤infix:() just yet :) | ||
since in general it'll take more parsing hooks than we've done yet | |||
masak | PerlJam: good for you. I think no matter which one we find, it'll keep some people back. | ||
TimToady | anyone who can't figure out how to copy/paste the first ¤ has NO BUSINESS writing macros, it could be argued | 17:38 | |
PerlJam | masak: perhaps. Seems like this is one of those delicate balancing acts. (and it makes me glad that TimToady is the language designer :) | 17:39 | |
masak | quick general poll: people who know/don't know by hand how to type ¢ in their day-to-day editor? | ||
TimToady | and {{{ }}} is really very cluttery, when you get down to it | ||
masak | s/by hand/by heart/ | ||
TimToady | quick poll, how many people are worried about Cursor objects directly? | 17:40 | |
PerlJam | heh | ||
masak | TimToady: I'd always thought that {{{ }}} is cluttery, but that's not purely a disadvantage. it stands out, especially with proper color coding. | ||
17:40
bluescreen10 left
|
|||
TimToady | ¤ is really easy for a highlighter to recognize | 17:40 | |
and the following word will tell it what state to be in after the () | |||
masak | any highlighter that isn't a Perl 6 parser will be toast highlighting Perl 6 anyway... | ||
TimToady | {{{ }}} can't | ||
masak should be making supper... | 17:41 | ||
TimToady | I hope we've helped you develop an appetite :) | ||
not lost it :) | |||
PerlJam | TimToady: how do you type ¤ ? | 17:42 | |
TimToady | compose x o | ||
arnsholt | PerlJam: I hit the ¤ key on my keyboard =) | ||
TimToady | I have a program like the unicode looker upper that greps the compose database instead | ||
masak | TimToady: look, you make the rules. :) my initial reaction to the ¤ suggestion is that it's ugly and will have low adoption. {{{ }}} may be ugly, but it's really easy to type. | ||
tadzik | I'm with masak, if that matters :) | 17:43 | |
TimToady | IT WON'T WORK!!! | ||
except for terms... | |||
masak | besides, I'm not sure you ever responded to my nested-quasis use case. | ||
PerlJam | "low adoption" sounds like a feature :) | ||
masak | PerlJam: I disagree. | ||
TimToady | I don't know why you're putting an AST as the endpoint of a ... | ||
masak | the '...' aren't literal, for once. | 17:44 | |
put a ';' in places where needed, if that helps. | |||
PerlJam | masak: perhaps that should have been a 1/2 :) I go back and forth on it. But I do think that "macro writers" will proliferate once the technology is in place. | ||
masak | the point is that the inner quasi can placeholder the outer quasi. | ||
PerlJam: that remains to be seen. but I do dislike "let's make this a little uncomfortable because it's a dangerous feature"-type arguments. | 17:45 | ||
TimToady | ¤OUTER::term:() then :) | ||
masak | yeech :/ | 17:46 | |
TimToady | the non-negotiable here is that we have to get the grammar rule that we're clobbering in there somewhere | ||
masak | well, assuming it's on the top level of the inner quasi... | ||
TimToady | at some point it's better to write separate quasis or macros and just compose them | ||
nested {{{ [[[ ]]] }}} is atrocious engineering | 17:47 | ||
masak | TimToady: I always thought it was quite fitting that we only did terms in quasis, since we can only pass in terms as macro arguments anyway. | ||
TimToady | you can parse anything an 'is parsed' can return, much more than terms | ||
terms is just the default | 17:48 | ||
masak | I hear what you're saying. this is doing some violence to my mental model of macros. | ||
I need nutrition. | |||
masak cooks | |||
TimToady | o/ | ||
PerlJam | masak: maybe it's a good thing TPF is taking so long on your grant proposal :) | 17:49 | |
TimToady | .oO(no battle plan survives first contact with the implementor) |
17:50 | |
.oO(or with the language designer) |
|||
17:54
Chillance joined
17:55
bluescreen10 joined
|
|||
TimToady | std: macro foo($a,$b,$c) { quasi { {{{$a}}} ... quasi [ {{{$b}}} [[[$c]]] ] } } | 17:56 | |
p6eval | std be1f10e: OUTPUT«===SORRY!===Strange text after block (missing comma, semicolon, comment marker?) at /tmp/u0YJqAbZeg line 1:------> { quasi { {{{$a}}} ... quasi [ {{{$b}}}⏏ [[[$c]]] ] } } expecting any of: bracketed infix infix or meta-in… | ||
TimToady | what I thought, doesn't even parse | ||
fundamentally, the parser must know what reduction a macro is replacing, and a quasi-unquote is just a funny looking macro | 17:58 | ||
well, the parser must know that for hygienic macros, not text macros, to be precise | 17:59 | ||
text macros can get away with it because the reparse to put parser into the correct final state | 18:00 | ||
s/the/they/ | |||
18:00
Je joined
|
|||
moritz | TimToady: in your mental model, what kind of syntaxes can be replaced with {{{$placeholder}}}, or whatever syntax we'll chose for them? | 18:01 | |
18:01
im2ee left,
benabik left
|
|||
moritz | things that the OPP parses for you? | 18:01 | |
TimToady | any named rule in the grammar | ||
moritz | wow. | 18:02 | |
18:02
benabik joined
|
|||
TimToady | that's why I said it'd require a bit more work on the parser | 18:02 | |
masak | std: macro foo($a,$b,$c) { quasi { {{{$a}}}; quasi [ {{{$b}}}; [[[$c]]] ] } } | ||
moritz | so even stuff like the identifier in a sigiled variable | ||
p6eval | std be1f10e: OUTPUT«ok 00:03 140m» | ||
18:02
im2ee joined
|
|||
TimToady | it's fine to implement just terms for now, but I want the syntax that expressive | 18:02 | |
masak | <masak> put a ';' in places where needed, if that helps. | ||
TimToady | otherwise we have no argument to bring against the homoiconophiles | ||
masak | I'm also worried about the homoiconophiles. | 18:03 | |
but mostly because they'll always win on minimal syntax, and maybe on minimal semantics, too. | |||
TimToady | otherwise they'll just say "Well, you can't really do anything interesting with just the nouns" | 18:04 | |
but also because some of our thunky infixes are already macro-y, and we need to handle that eventually | |||
well, they'll always win the argument that they've pushed the waterbed down maximally in one spot | 18:05 | ||
masak | I'm not planning to do 'is parsed' during my grant. but of course we should plan for it. | ||
18:05
sivoais left
|
|||
TimToady | btw, the semicolon is not sufficient; it's parsing {{{$b}}} is three nested blocks | 18:07 | |
*as | |||
no other quotes can reach inside other quotes | |||
[Coke] | masak: I have no idea how to type ¢ in my editor of choice. | 18:09 | |
masak | TimToady: what!? then what is all this futuristic fancy nibbler-based parser architecture *for*? | ||
TimToady: I thought it was *just* these kinds of things it took care of without blinking. | |||
TimToady is tempted to channel MJD | |||
masak | seriously, I'm surprised about this. | 18:10 | |
TimToady | std: qq[ { "]]]]]]]] | ||
p6eval | std be1f10e: OUTPUT«===SORRY!===Unable to parse double quotes at /tmp/yaPNH6pmRF line 1:------> qq[ { ⏏"]]]]]]]]Couldn't find final '"'; gave up at /tmp/yaPNH6pmRF line 1 (EOF):------> qq[ { "]]]]]]]]⏏<EOL>Parse failedFAILED … | ||
TimToady | std: qq[ { "]]]]]]]]" } ] | ||
p6eval | std be1f10e: OUTPUT«ok 00:01 119m» | ||
masak | right, sure. but those are string quotes. | 18:11 | |
TimToady | and these are quasi quotes | ||
they're still quotes | |||
masak | I guess I assumed that *because* there was this {} <-> {{{}}} sympathy, it would reach through blocks. guess not. | ||
[Coke] | masak: though I was able to google it in under a minute, and it'll work on my editor on the 3 platforms I tend to use. | ||
TimToady | no place else in Perl 6 tracks multiple start/stop delimiters at the same spot | 18:12 | |
and if {} <-> {{{}}} makes you expect that, then maybe that's another reason for breaking it | 18:14 | ||
and the scoping should be determined by the variable's you reference inside, anyway, methinks | 18:15 | ||
s/'// | 18:16 | ||
the parser knows where $a, $b, and $c come from | |||
18:17
sivoais joined
|
|||
masak | right, but that only works for the simple case, where there's just a variable inside. | 18:19 | |
also, variables are not really tied to quasis, they're tied to scopes in general. outside macro, inside macro, inside quasi... | 18:20 | ||
TimToady | I think you're still mixing up the quasi-unquasi levels, they're very either-or, whether your in quasi or not, and a nested macro will make that clear | 18:21 | |
18:22
Je left
18:24
daniel-s left
|
|||
TimToady | *you're | 18:24 | |
18:24
envi_ left
|
|||
cognominal_ | so far, macros are very quasi-modo. | 18:34 | |
[Coke] | cognominal_: ugh. I had a hunch someone would make that pun. | ||
sjohnson | .u music | 18:35 | |
phenny | U+0749 SYRIAC MUSIC (◌݉) | ||
colomon | boy, that rings a bell | ||
TimToady | odd that I don't find this conversation bazaar... | 18:36 | |
cognominal_ | [Coke] :) | ||
nqp: say('a') | 18:46 | ||
p6eval | nqp: OUTPUT«a» | ||
18:47
leprevost left
18:48
daxim left
18:49
Gruber_ joined
18:51
Je joined,
Grrrr left,
Gruber_ is now known as Grrrr
|
|||
colomon just suddenly realized PerlJam might be a reference to the band. Sigh.... | 18:58 | ||
[Coke] | You beat me to it. | 19:01 | |
(no pun intended. I never made that cxn either | |||
19:01
araujo left
|
|||
TimToady | That's okay, I laugh three times at every joke: once when it's told, once when it's explained, and once when I get it. :) | 19:01 | |
19:02
araujo joined
|
|||
colomon | :) | 19:03 | |
19:05
kaare_ joined
19:18
bluescreen10 left
19:19
packetknife joined
19:23
Je left
|
|||
masak | TimToady: ok, I've internalized my new understanding of how quasis work. it's still an open question to me whether the semantics I thought was there can be emulated somehow. | 19:28 | |
TimToady: also the fact that {{{}}}s don't nest makes me slightly less attached to them. doesn't make me like ¤ better, though. I hope there's a cuter solution out there somewhere. | 19:29 | ||
19:29
packetknife left
|
|||
PerlJam | .oO( what I laugh at 3 times is funny? ) |
19:30 | |
colomon: no, PerlJam isn't a reference to the band. It was more of a "happy accident" that I chose my nick right around the same time as they were becoming popular. | 19:31 | ||
colomon: Though my brother actually chose the nick and he probably listened to them at the time while I was oblivious. | |||
masak | you let your brother choose IRC nick for you...? | 19:32 | |
PerlJam | aye. I had a few options, he went with this one, I liked it, it stuck. | 19:33 | |
masak | perl6: say <perl ruby python>.roll ~ <jam hack jazz>.roll | ||
p6eval | pugs b927740: OUTPUT«*** No such method in class Array: "&roll" at /tmp/tz2AeUKQTX line 1, column 5 - line 2, column 1» | ||
..rakudo 158bd0, niecza v10-66-g71325b0: OUTPUT«rubyhack» | |||
PerlJam | later I went with perlpilot and there was a time I tried "OpenSourceror" :) | ||
masak | oops, .roll wasn't fair to Pugs. | ||
PerlJam | but ... I'm just too used to PerlJam to change :) | 19:34 | |
masak | PerlJam: sir, I would've been honored to address you as OpenSourceror :P | ||
colomon | wait, rakudo and niecza both came up with the same random choices? | ||
PerlJam | colomon: not very random, eh? | ||
masak | colomon: yeah, but the chances for that weren't astronomical. | ||
colomon: 1 in 9. | |||
colomon | perl6: say <perl ruby python>.roll ~ <jam hack jazz>.roll | 19:35 | |
p6eval | niecza v10-66-g71325b0: OUTPUT«rubyjam» | ||
..rakudo 158bd0: OUTPUT«rubyhack» | |||
..pugs b927740: OUTPUT«*** No such method in class Array: "&roll" at /tmp/8iPxc57Mfr line 1, column 5 - line 2, column 1» | |||
19:35
packetknife joined
|
|||
masak | perl6: say <perl ruby python>.pick ~ <jam hack jazz>.pick | 19:35 | |
colomon is relieved. | |||
p6eval | pugs b927740: OUTPUT«pythonjam» | ||
..niecza v10-66-g71325b0: OUTPUT«rubyjazz» | |||
..rakudo 158bd0: OUTPUT«perlhack» | |||
masak | \o/ | ||
PerlJam | heh | ||
masak | nice distribution :) | ||
masak wishes perlhack were here | |||
19:37
bluescreen10 joined
19:38
SHODAN left
|
|||
masak | hm, I wonder if I can create an Epimenides paradox... | 19:43 | |
perl6: say "What ", <rakudo niecza pugs>.pick, " says isn't true." | 19:44 | ||
p6eval | pugs b927740: OUTPUT«What niecza says isn't true.» | ||
..rakudo 158bd0, niecza v10-66-g71325b0: OUTPUT«What rakudo says isn't true.» | |||
masak | Rakudo went Epimenides. | ||
I don't know about the status of the other two, but it's possible that paradoxicity is contagious. | 19:45 | ||
19:45
soh_cah_toa joined
19:46
packetknife left
|
|||
masak | is there a more general name for the "forwards compatibility" afforded by OO/interfaces/polymorphism and closures, but not by "regular" procedural programming? | 19:48 | |
maybe the answer I'm looking for is "IoC", but I'm not sure... | 19:49 | ||
PerlJam | I'm not sure what you mean by "forwards compatibility", but it doesn't soundlike IoC | 19:50 | |
masak | when you write code that's able to call on code that hasn't been written yet. | 19:51 | |
I can see how such a property might be really nice for big code bases, because it allows you to compensate for changing requirements to some extent. | 19:52 | ||
without having to re-model, I mean. | |||
colomon | That's really pretty standard for C code too, you know. | 19:54 | |
PerlJam | okay ... still wouldn't call that IoC | ||
japhb | masak, that property is in fact one of the most common reasons I write things in OO form when that would be more complex than the procedural form. | ||
"Don't like the way I did it? Derive a subclass and enjoy." | |||
It's not infinitely powerful that way, of course, but it helps with the easy cases. | 19:55 | ||
PerlJam | masak: maybe "defensive design" :) | ||
20:01
supernovus joined,
GlitchMr left
|
|||
masak | japhb: sounds like convenience bordering on misuse... :) | 20:03 | |
PerlJam: there was a paper that I read that talked about joining-points in the model where things were liable to change. paper said "put your interfaces there". sounded like a good rule of thumb. | 20:04 | ||
japhb | masak, don't forget that virtually every advance in computer language design over the last 50 years was to make something easier or less bug-prone or both. Having learned programming philosophy from Michael Abrash's works at a critical point in my life, I aim to see such constructs for what they can do for me, not what the axe-grinder who invented them thought they should be used for. ;-) | 20:06 | |
masak | japhb: oh, sans doute. | 20:07 | |
20:08
packetknife joined
|
|||
masak | japhb: I like to think that way too. the more one sees the various constructs as vehicles that will take you places, the better, I think. | 20:08 | |
japhb chuckles | |||
quite. | |||
masak | japhb: but there are also "patterns of misuse" that are worth paying attention to. | ||
japhb returns the 'sans doute' comment, with extra emphasis. | 20:09 | ||
PerlJam | .oO( patterns of abuse? ) |
||
masak | PerlJam: I was so close to writing that! | ||
sounded wrong, though. | |||
colomon | Michael Abrash!!! | ||
japhb | sadly, bad connotations to that phrasing in this part of the world | ||
masak | yeah, I figgered. | 20:10 | |
colomon | I adored the Zen of Assembly Language. | ||
japhb | colomon, One of my favorites, easily. | 20:11 | |
colomon | japhb: I haven't read it in ages, and I never really directly applied its contents, but I hope that at least some of the philosophy rubbed off. | ||
japhb | I used to wonder what kind of amazing would come from having Michael Abrash and Jon Bentley on the same project. | 20:12 | |
colomon, heh. I think that's the important part anyway. | |||
Heck, I think one of the biggest value of that book is taking some simple concepts and driving them home so completely that by the end you practically feel them in your bones. | 20:13 | ||
colomon | You have to actually time it, not just guess where it's slow. :) | 20:15 | |
japhb | That's a really big one. :-) | ||
20:17
Je joined
20:19
Je left
|
|||
colomon | The other thing that really stands out in my memory is the program (from Zen of Graphics, maybe?) which optimized the Game of Life by generating custom machine code for each possible board size (as needed). | 20:22 | |
PerlJam | japhb: you might find that Jon Bentley and Michael Abrash can't stand each other and fight constantly :) | 20:23 | |
japhb | One of the things I loved about that Game of Life contest was that when he discovered some people had broken some of the rules to go faster, he was all ready to put his foot down and disqualify them, until he discovered that EVERY entrant would have been disqualified. :-) | 20:24 | |
PerlJam, LOL | |||
Well, the mix of Abrash and Carmack was pretty powerful. | |||
But then they were both ASM experts .... | |||
colomon, regarding generating code for each board size ... I'm reminded of a Chuck Moore rant about programmers trying to write general code that is "highly configurable" and "runs everywhere". He argued that you can write an entire OS in a few K if it only has to run on one system -- but that's not as rare as most people think. | 20:27 | ||
I never go quite that far, but it does serve as a nice reminder when I'm about to make my configuration files Turing complete or decide that I have to run on 16- and 64-bit CPUs or somesuch. | 20:29 | ||
PerlJam | that "entire OS" sounds mostly like a scheduler :) | ||
japhb | PerlJam, he wrote his disk drivers in a couple hundred bytes! | ||
The core of Forth is like 4K, and it's a lot more complex than you'd think. | 20:30 | ||
colomon | heh, Thinking Forth was another very influential book for me. :) | ||
masak keeps close notes | |||
PerlJam | japhb: I can't imagine that it'd ve more complex than I'd think ;) | ||
s/ve/be/ | |||
japhb | PerlJam, you're a Forthwright I take it? | 20:31 | |
masak | japhb: what complexity is one likely to miss when thinking of the Forth core? | ||
PerlJam | indeed. | 20:32 | |
japhb | does> | ||
Also, the Forth core is conceptually compressed in a way that I found mind-bending the first time around. It's like someone had zipped the source to an OS and an editor and somehow kept the output as readable 7-bit ASCII text | 20:34 | ||
japhb shrugs | |||
But like most moments of enlightenment, it will be obvious to some, and world-changing to others .... | 20:35 | ||
cognominal_ | For one year, I had a job programmaing that beast oldcomputers.net/Panasonic_HHC.html using SnapForth using an Apple II | ||
japhb | That thing looks awesome! | 20:36 | |
colomon | I think I've said it before here, but lately I've started to think that the world of programming languages is like a circle Lisp and Forth, which seem like they ought to be complete opposites, are disturbingly close -- and honestly, I usually like Chuck Moore's choices better than whoever designed Lisp. :) | ||
japhb | NOD | 20:37 | |
colomon lost a sentence-ending period in there, but hopefully it is still relatively clear. | |||
cognominal_: yow. | 20:38 | ||
cognominal_ | In the same small company, the had also a portable panasonic PC probably around 20kg. They made a point that each pixel was visible instead of desiginng some convolution so that a white screen would be uniservally white | 20:39 | |
japhb | An odd optimization choice. Why? | 20:40 | |
cognominal_ | White is not the appropriate word because phosphor displays were not white. | ||
masak | colomon: I think it was Paul Graham who said that Lisp and C stand out as the two "pure" languages around which all the others flock. | ||
colomon | masak: but Forth is actually much more "pure" than C, and not in C's orbit at all. | 20:41 | |
cognominal_ | japhb: I don't know. But that striked me as odd. I think they thought this was some form of high precision. | ||
masak | colomon: no, Forth is probably in Lisp's orbit, like you say. | ||
colomon | masak: but it's not. | 20:42 | |
it's hard to explain. | |||
japhb | It really is a world of its own. | ||
masak | heh. snobs :P | ||
cognominal_ | Doing forth helped me immensely when I programmed with NeWS at Sun which was a window system based on PostScript. | ||
colomon | Forth was the first structured language I ever programmed in, I loved it on my Commodore 64. | 20:43 | |
cognominal_ | Doing windowing programming using exch, pop and roll was weird. | ||
japhb | Now there's an image. | ||
masak | has any one checked out False? | ||
it feels a bit like APL, Forth, and Perl all mixed together. | 20:44 | ||
cognominal_ | So NeWS was years ahead as an imaging system, even if the implementation was very bad, but sucked as a language. | ||
en.wikipedia.org/wiki/NeWS | |||
20:45
packetknife left
|
|||
colomon | masak: False looks like the ugly predecessor of Factor | 20:46 | |
masak | Factor looks like a modern Forth to me. | 20:50 | |
niecza: my @a = 1; push @a, $_ if any(@a) * any(2, 3, 5) == $_ for 2..1000; say @a.perl | 20:52 | ||
p6eval | niecza v10-66-g71325b0: OUTPUT«[1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, 27, 30, 32, 36, 40, 45, 48, 50, 54, 60, 64, 72, 75, 80, 81, 90, 96, 100, 108, 120, 125, 128, 135, 144, 150, 160, 162, 180, 192, 200, 216, 225, 240, 243, 250, 256, 270, 288, 300, 320, 324, 360, 375, 3… | ||
masak | O(N ** 2) way to generate the Hamilton sequence ;) | 20:53 | |
er, Hamming sequence. | 20:54 | ||
colomon | masak: Forth old timers won't like that, but it seems like a pretty fair summary. :) | ||
dynamically typed, higher order Forth. :) | 20:55 | ||
20:57
prammer joined
21:01
explorer__ joined
|
|||
masak | let the pair (X, Y) denote the assertion "language X drinks very deeply from the well of programming concept Y" | 21:01 | |
(Forth, stacks) | |||
(Lisp, ASTs) | |||
(APL, operators) | 21:02 | ||
sbp | APL drank so deeply from the well of programming concept operators that it passed out | ||
TimToady | (Perl,_) | ||
masak | TimToady: what, trailing commas? :P | 21:03 | |
21:03
jferrero left
|
|||
masak | underscores? | 21:03 | |
TimToady | I'm thinking in Prolog | ||
masak | yes, I realize. | ||
so, "Perl, whatever" | |||
which is quite fitting, considering. | 21:04 | ||
"In Perl, you can go overboard with any programming concept you like!" | |||
"We let *you* pick the foot to shoot yourself in!" | |||
21:04
am0c left
|
|||
masak | :P | 21:05 | |
tadzik | . o O ( everything is a subject ) | ||
sjohnson | .oO ( fat face ) | ||
masak | "Perl gives you enough rope to shoot yourself in the foot!" | ||
sbp | ugh, I need a #perl6-overflow to pipe all my bad jokes to | 21:06 | |
("in Soviet Russia, everything *subjects* you!") | |||
somebody make things happen | |||
masak | perl6: say "things, happen" | 21:07 | |
sjohnson | 14( 13*14≖‿≖13*14) | ||
p6eval | pugs b927740, rakudo 158bd0, niecza v10-66-g71325b0: OUTPUT«things, happen» | ||
sbp | you know, I've been lurking here for about a year now hoping that one day I would feel guilty enough to actually sit down and write a whole perl6 library or weave together a whole book getting people into perl6. at least every bad joke I make does make me feel one infintesimally small step closer to that goal | 21:08 | |
programming, Zeno's way | |||
21:08
bluescreen10 left
|
|||
masak | sbp: lurkers are like neutrons. suddenly, one day they transform into a charged particle and get busy :) | 21:09 | |
sjohnson | masak: i'm a late blooping electron | ||
masak | sjohnson: :) | ||
sbp | I don't know, I'm quite thankful for my neutrons as well as my protons and other charged particles | ||
I wouldn't feel the same without them | 21:10 | ||
masak | I'm not sure my analogy landed intact. | ||
sbp | I read some article years ago about learning new natural languages, that said you have to work especially hard compared to most other tasks because if you already know a language your brain doesn't really see any particular reason to learn a new one, so it complains extra hard | 21:11 | |
I wonder if something similar is true of programming languages | |||
I learned a lot of languages more or less simultaneously, and now... hard to gather the momentum | |||
bonsaikitten | sbp: immersion | ||
sbp | what do you think I'm doing *here*? :-) | ||
bonsaikitten | if you try to learn something just to pad your resume it's hard... get forced to learn or die and you will refuse to just die :) | 21:12 | |
bonsaikitten is just starting to absorb Mandarin ... nice brain teaser | |||
masak | I'll say. | ||
sbp: for me, it was "have I tried to write X in Perl 6 yet?" -- I'm still coming up with stuff I haven't tried. ;) | 21:13 | ||
sbp | it is interesting to see how people learn programming languages. lots of different approaches. I learn most from just sitting down and tinkering by trial and error, or osmosis from places like this; but some people like strong guides | ||
bonsaikitten | masak: I get distracted too easily ... "hey, how does agetty work?" | ||
sbp | I'd like to see animated code that has two columns | ||
masak | bonsaikitten: 你住在哪里? | 21:14 | |
sbp | one column is syntax highlighted code, the other is some structure that the code is operating on. then for each step of the process, the code that performs that action, and the relevant section in the operated-upon data, are simultaneously highlighted | ||
(I did make something similar for a small bit of JavaScript once, but it wasn't really for educational purposes) | |||
but I don't know if that's too passive. it's also quite hard work to set up | 21:15 | ||
bonsaikitten | masak: not yet :) let me learn pinyin and a base vocabulary to a sane level before I escalate to hansi | ||
masak | bonsaikitten: fair enough -- don't wait too long with the hanzi, though :) | 21:16 | |
they're 1/3 of the words, besides sound and meaning. | |||
masak yawns | |||
japhb | Oh, that reminds me: every so often in the last couple years I've seen code presented on the web in some variant of literate programming: the prose goes in one column, the source next to it, and each block of code and section of text are aligned horizontally, so you can scroll down to the part you are interested in, and look directly to one side to read the commentary. Anyone remember what program does this (assuming my description was cl | ||
ear enough)? | |||
bonsaikitten | yes,one thing at a time :) | 21:17 | |
masak | 'night, bonsai butterflies | ||
cognominal_ | japhb: docco | ||
sbp | same guy who made CoffeeScript | ||
masak | jashkenas.github.com/docco/ | ||
sbp | @lazyweb p6occo! | 21:18 | |
cognominal_ | it spwaned a cottage industry cuz it has been translated in many languages. | ||
sbp | cameliocco? | ||
they should have called the Java one doccocino | 21:19 | ||
japhb | cognominal_, masak, thanks! | ||
cognominal_ | japbh: I have written some stuff to dynamically view a parse tree that is inspired from docco. It is in standby. I am waiting for nom to be fixed github.com/cognominal/code-viewer | 21:23 | |
21:24
ksi left
|
|||
im2ee | Good night! :) | 21:28 | |
o/ | |||
21:28
im2ee left
21:30
fsergot joined
21:34
kaare_ left
21:38
fod joined
21:42
fod left
21:49
abercrombie joined
21:54
icwiener left
22:04
dalek left
22:05
y3llow left
22:06
dalek joined,
ChanServ sets mode: +v dalek,
y3llow joined
22:07
drbean left,
aindilis left
22:13
drbean joined
22:16
cognominal_ left
22:18
cognominal joined
22:21
dalek left
22:22
dalek joined,
ChanServ sets mode: +v dalek
22:31
cognominal left,
cognominal joined
22:50
replore_ left
22:54
whiteknight joined
22:59
Chillance left
|
|||
jnthn | ...well, that was more than a few hours. And more than a couple of beers... :) | 23:00 | |
Hm, and I have meetingish thingy in the morning. Guess I don't get Rakudo tuits tonight then. But it was good to go and relax for a while. | 23:02 | ||
23:02
drbean left
23:09
drbean joined
23:12
molaf_ joined
23:13
molaf left
23:19
dual left
|
|||
[Coke] | jnthn: there is no problem beers more better. | 23:28 | |
23:37
donri left
23:43
worr left
23:47
benabik left
|
|||
supernovus | what is the best way to empty an array without splice? | 23:52 | |
abercrombie | @a=() | 23:56 | |
supernovus | abercrombie: thanks, that'll work just fine. I still hope splice gets fixed soon though :-) | 23:57 |